Steps to Optimize the Adobe Commerce Performance

When users experience a slow or unresponsive site, it affects conversion. We recommend
following these steps to optimize the Magento speed on Adobe Commerce cloud infrastructure implementation:

• Assess the problem
• Measure performance
• Identify the part of the system critical for performance
  improvement
• Modify part of the system to remove the
  bottleneck
• Measure the performance after modification
• If better, adopt it or revert

Shopify is renowned for its user-friendly interface, which simplifies store management and reduces the need for extensive technical expertise. Unlike Magento, which often requires a developer for complex tasks, Shopify allows merchants to handle most aspects of their store independently.

When developing pages, the initial provisioning of the two different infrastructures should be hosted within the same AWS (or Azure) Region to reduce latency between the AEM publisher and Adobe Commerce GraphQL.

The geographical location of both clouds should also be close to the majority of your customer base so that client-side GraphQL requests are provided from a location that is close to the majority of your clients.

Certain calls made by the user’s browser or AEM publisher to Adobe Commerce’s GraphQL will be cached in Fastly. Cache queries are often those that contain non-personal data and are unlikely to change frequently. For example, categories, categoryList, and products.

Those that are explicitly not cached are those that change often and, if cached, could endanger personal data and site functionality, such as cart and customerPaymentTokens inquiries.

Multiple inquiries can be made in a single GraphQL call. It is crucial to note that if you specify one question that Adobe Commerce does not cache with several other queries that are not cacheable, Adobe Commerce will skip the cache for all queries in the request.

Developers should keep this in mind while merging numerous queries to avoid accidentally bypassing potentially cacheable queries.

It is not recommended to utilize flat tables for items and categories. Because using this outdated feature can cause performance degradations and indexing concerns, the flat catalog should be disabled via the Adobe Commerce admin, in the storefront area.

Some third-party modules and customizations do require flat tables to function properly; it is advised that an evaluation be performed to understand the implications and dangers of having to use flat tables when opting to employ these extensions or customizations.

Fastly origin shielding is disabled by default. The goal of Fastly’s origin shielding is to reduce traffic to the Adobe Commerce origin: when a request is received, a Fastly edge location (or “point of presence” / POP) scans for and provides cached material.

If it isn’t cached, it moves on to the Shield POP to see if it’s cached there (if the content has previously been requested even from another global POP, it will be cached). Finally, if it is not cached on the Shield POP, it will travel only to the Origin server.

Fastly origin shielding can be activated in the Fastly configuration backend settings of your Adobe Commerce admin account. For optimal performance, select a shield location that is close to your Adobe Commerce origin data center.

When you enable Fastly origin shielding, you may also activate Fastly Image Optimizer. Where product catalog images are stored on Adobe Commerce, this service allows you to offload all resource-intensive product catalog image transformation processing onto Fastly and away from the Adobe Commerce origin.

End-user response times for page load times are also improved since pictures are changed at the edge location, which decreases latency by reducing the number of queries back to the Adobe Commerce origin.

Fastly Image optimization can be enabled by selecting “enable deep image optimization” in Fastly setup in admin, but only after your origin shield has been active. Fastly image optimization will definitely help you in Adobe Commerce SEO optimization.

Many modules become redundant and are not used when running Adobe Commerce headless, only delivering queries through the GraphQL endpoint, and no front-end shop pages are delivered directly from Adobe Commerce.

By eliminating unnecessary modules, your Adobe Commerce code base becomes smaller and less complex, perhaps improving performance. Adobe Commerce modules can be disabled using composer. Which modules can be disabled depending on the needs of your site, so no recommended list can be provided because each customer’s Adobe Commerce implementation is unique.

MySQL and Redis Slave connections are not enabled by default in Adobe Commerce on the cloud. This is due to the fact that these settings are only appropriate for customers that anticipate a heavy load.

With slave connections enabled, the cross-AZ (cross-Availability Zones) delay increases, hence this configuration actually affects the performance of an Adobe Commerce on cloud instance if the instance only receives regular demand levels.

If the Adobe Commerce instance is expecting heavy traffic, enabling master-slave for MySQL and Redis will improve performance by distributing the load on the MySQL Database or Redis across multiple nodes.

Enabling Slave Connections will, on average, slow down performance by 10-15% in circumstances with a normal load. However, in clusters with high load and traffic, there is a 10-15% performance improvement. As a result, it is critical to load-test your environment with projected traffic levels to determine whether this configuration would benefit your performance times under pressure.

To enable/disable slave connections for MySQL and Redis you should edit your
.magento.env.yaml file to include the following:

Redis slave connections should not be enabled for scaled architecture (split architecture
– see below), as this would result in errors. It is alternatively advised to create L2 caching for Redis in the case
of a split architecture.

If, after all of the preceding setups, load test results or real infrastructure performance analysis show that the load levels to Adobe Commerce are constantly maxing out CPU and other system resources, then a shift to a scaled (split) architecture should be explored.

A basic Pro architecture has three nodes, each with its own comprehensive tech stack. By moving to a split-tier design, this reduces to a minimum of 6 nodes: three for ElasticSearch, MariaDB, Redis, and other core services, and three for web traffic processing (PHP fpm and NGINX).

With split tier, there are more scaling options: core nodes containing databases can be scaled vertically; web nodes can be scaled horizontally and vertically, providing a great deal of flexibility to expand infrastructure on demand for set periods of high load activity and on nodes where extra resources are required.

Hope this post will help you in Adobe Commerce Performance Optimization. If you still need any help, Hire a Dedicated Magento Developer and get a Free Trial For 8 Hours, also you can reach us at info@vihadigitalcommerce.com.