Magento 2 and Adobe Commerce and Hyva Theme performance optimisation
Time to First Byte (TTFB) is a foundational web performance metric that precedes every other meaningful user experience metric, such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP). This means that high TTFB values add time to the metrics that follow it. Many (if not all) magento scummers don’t measure this metric or cheat by measuring this metric only for the FPC pre-cached page. The last days scam are even worse using the speculation rule. Hiding bigger performance issues. Low Google Page Speed Insight doesn’t necessarily tell the site is slow it is just a score however, high TTFB is always telling the site is slow and has performance issues and affects user experience. The rest of the metrics are CSS, JS, and images(jpg, webp) delivery metrics. By the way, Hyva improves just those metrics but not a TTFB. With the Hyva Magento TTFB, backend performance is the same slow and has critical performance issues (Denial Of Service vulnerability)
It’s recommended that your server responds to navigation requests quickly enough so that the 75th percentile of users experience an FCP within the “good” threshold. As a rough guide, most sites should strive for a TTFB of 0.8 seconds or less. Before, Google recommended 300ms; however, it is not achievable with magento, and they increased this metric to 800ms.
Key point:
TTFB is not a Core Web Vitals metric, so it’s not absolutely necessary that the Magento 2 site meet the “good” TTFB threshold, provided that it doesn’t impede their ability to score well on the metrics that matter. Core Web Wital is built for Single-page applications where TTFB is not the main metric. For themes Like HYVA and Luma and other HYML server-rendered themes (not PWA Studio, Vue Storefront etc.) it is the main metrics. You must measure it with the FPC disabled or bypassed, or you will cheat yourself because only 25% of the pages are cached usually. 60% of the traffic is search random traffic.
A low TTFB under 300ms is crucial for getting markup out to the client as soon as possible. A server-rendered HTML site that does not require as much client-side work will have te fastest performance.
How to Measure Magento TTFB
Before you can optimize TTFB, you need to observe how it affects your website’s users. You should rely on field data as a primary source of observing TTFB as it is affected by redirects, whereas lab-based tools are usually test already cached pages when the user hits random pages.
Understanding high TTFB with Server-Timing
The Server-Timing response header can be used in your Magento backend to measure distinct backend processes that could contribute to high latency. The header value's structure is flexible, accepting, at minimum, a handle that you define. Optional values include a duration value (via dur), as well as an optional human-readable description (via desc).
Note: If measuring backend latency with Server-Timing is not feasible, then a suitable alternative may be to rely on Profiler (Tideways, New Relic, Blackfire, XDebug profiler) to detect and diagnose backend performance problems. That's why nowadays, all the agencies blindly checking Google Page speed insight. Because they don’t give a shit about profiling. It is the only tool easy to use. Just insert URL and you have some score.Serving-Timing can be used to measure many application backend processes, but there are some that you may want to pay special attention to:
- MySQL Database, Redis, ElasticSearch queries
- Bootstrapping the Magento 2 framework
- Server-side template rendering time
- Disk operation
All parts of a Server-Timing entry are colon-separated, and multiple entries can be separated by a comma:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2The header can be set using your application backend’s language of choice. In PHP, for example, you could set the header like so:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);// Perform a database query and get results...
// ...// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStarTime) / 1e+6;// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
The number and quality of plugins and server CPU impacts Magento performance. Also, it is impacted when the MAgento is customized by 1-st party Extensions.
Profiling Magento 2 PHP code issues with Tideways
Installation
You can install the extension from source:
phpize
./configure
make
sudo make installConfigure the extension to load with this PHP INI directive:
extension=tideways_xhprof.soRestart Apache or PHP-FPM.
Usage
The API is not compatible to previous xhprof extensions and forks, only the data format is compatible:
<?php
tideways_xhprof_enable();
my_application();
file_put_contents(
sys_get_temp_dir() . DIRECTORY_SEPARATOR . uniqid() . '.myapplication.xhprof',
serialize(tideways_xhprof_disable())
);By default only wall clock time is measured, you can enable there additional metrics passing the $flags bitmask to tideways_xhprof_enable:
<?php
tideways_xhprof_enable(TIDEWAYS_XHPROF_FLAGS_MEMORY | TIDEWAYS_XHPROF_FLAGS_CPU);my_application();file_put_contents(
sys_get_temp_dir() . DIRECTORY_SEPARATOR . uniqid() . '.myapplication.xhprof',
serialize(tideways_xhprof_disable())
);
Magento Server
Note: Newer use: Magento cloud, Nexcess etc. and other fency Magento specific hosings. They are overpriced and not efficient. Use Orcale, Azure, Digital Oceanm AWS Cloud servers with the fastest CPUs. Hetzner also works well.
Before you even consider other optimization approaches, server should be the first thing you consider. There’s not much in the way of specific guidance that can be offered here, but a general rule of thumb is to ensure that your Magento server is capable of handling the traffic you send to it. Some servers can handle 1 user at a time, some 20. Some 80.
However, if you’re running a larger store with many users that involves personalization, database querying, and other intensive server-side operations, your server choice becomes critical to lower TTFB in the field.
Since there are so many combinations of backend application stacks, there’s no one article that can encapsulate everything you can do to lower your website’s TTFB for Magento. However, these are some options you can explore to try and get things going just a little bit faster on the server side of things.
As with optimizing every metric, the approach is largely similar: measure your TTFB without or Bypassing FPC, use profilers to drill down into the causes, and then apply optimizations where possible. Not every single technique here may be viable for your situation, but some will be. As always, you’ll need to keep a close eye on your TTFP data, and make adjustments as needed to ensure the fastest possible user experience.
Denial of Service (DOS) Hyva Theme/MAgento 2 security vulnerability
Denial of Service is an attack that slows down or crashes our Magento 2 server.
Historically, DoS attacks typically exploited security vulnerabilities present in purely designed and written software. However, in some cases, you don’t need even attacks. Search bots, high user traffic, and flash sales can easily kill the Magento 2 website.
According to the Snyk IO security both Hyva and Magenton 2 have a high risk of Denial of service attacks.
If your competitors want to switch off your website, they can do it easily.
