Magento speed at server level, not just frontend

Why TTFB drives your store's LCP

Time to First Byte is the time between sending an HTTP request and receiving the first byte of the HTML response. For a Magento 2 store, a high TTFB means the browser is literally waiting before it can render a single pixel. LCP cannot be faster than TTFB plus the render time of the LCP element.

Google's CrUX threshold for TTFB is 800 milliseconds for 'needs improvement'. Above 1800 milliseconds you are in the red zone. On Hypernode stores without a configured full-page cache I regularly see TTFB values of 1.2 to 2.4 seconds. That is not a frontend optimisation problem: no amount of JavaScript bundling or image compression helps when the server takes 1.8 seconds to respond.

Frontend performance is covered on the magento-performance page. What I cover here is the layer underneath: the server stack that determines how quickly Magento generates HTML or serves it from cache.

The Magento server stack: from request to HTML

A Magento 2 request passes through several layers before HTML comes back. Each layer can be a bottleneck.

• ▸Nginx: reverse proxy and static file server. Normally not a TTFB problem, but wrong worker_processes or keepalive settings do cost time.
• ▸PHP-FPM: the PHP process manager. Too few workers means requests queue up. Too many workers on a small server eats memory and causes swap.
• ▸OPcache: stores compiled PHP bytecode in memory. Without OPcache, Magento recompiles tens of thousands of PHP files on every request. With OPcache but too little memory_consumption, it keeps losing cache entries.
• ▸Redis (full-page cache): stores the complete HTML output of pages. A cache hit serves in 5 to 30 milliseconds instead of 800ms to 2 seconds for a PHP-generated response.
• ▸Redis (session): stores user sessions. On busy stores this competes with FPC for Redis memory if you do not configure two separate Redis instances.
• ▸Varnish: HTTP accelerator placed in front of Nginx. Available on Hypernode via Sentia configuration. Serves cached responses at near-zero milliseconds server-side.

The TTFB of an untuned Magento 2 store is typically the combined PHP-FPM and MySQL time. Each cache layer you configure correctly removes a step from that chain.

What I tune and how

I work in a fixed order: measure, isolate the bottleneck, adjust, verify via CrUX or PSI lab. Typical tuning points per layer:

• ▸PHP-FPM pm.max_children: calculated from available RAM divided by average PHP process memory (often 80 to 120 MB per worker on Magento). Too low means queue, too high means swap.
• ▸OPcache opcache.memory_consumption: 256 MB on Hypernode by default. For large Magento installations with many modules, 512 MB is more realistic. I measure via opcache_get_status() how many entries are being lost.
• ▸Redis full-page cache: set maxmemory based on store size. Eviction policy to allkeys-lru so the most visited pages stay in cache. Two separate instances for FPC and sessions.
• ▸Redis maxmemory-policy check: volatile-lru does not unexpectedly lose session keys, allkeys-lru discards everything under pressure. Choice depends on whether FPC and sessions are shared.
• ▸Varnish VCL: measure hit ratio via varnishstat. Typical issues are cookies blocking caching, incorrect Vary headers or too low default_ttl for product pages.
• ▸MySQL slow-query log: identify queries above 1 second. Magento generates many slow queries on product listing pages without an index on category_id combined with status.
• ▸MySQL innodb_buffer_pool_size: must be large enough to keep the hot dataset in memory. Disk reads on every query are the silent TTFB killer.

I do not blindly max out all settings. Every adjustment has a reason and I measure the effect before and after. On a 2 GB Hypernode plan, 20 PHP-FPM workers is correct; on a 4 GB plan, 35 is more realistic.

Hypernode-specific constraints and how I work around them

Hypernode is a managed platform. That means good defaults and reliable infrastructure, but also constraints you do not have on a self-managed VPS.

• ▸No root access: PHP-FPM and Nginx cannot be restarted via systemd. Configuration changes via the hypernode-manage-vhosts CLI or the Hypernode control panel.
• ▸OPcache tuning: some OPcache parameters can be overridden via php.ini, others cannot. I test which parameters are effective on the specific Hypernode plan.
• ▸Varnish available via Sentia configuration: activate via the control panel. The VCL has limited customisation but the standard Magento 2 VCL covers 80 percent of use cases.
• ▸Redis: two Redis instances available on Hypernode Professional and above. On Starter plans there is a shared instance; I then separate FPC and sessions via separate databases (db 0 and db 1).
• ▸MySQL: no direct innodb_buffer_pool_size adjustment without Hypernode support. I optimise via indexes and query rewriting instead of server parameters.

I work with Hypernode on a daily basis in production and know the limits of the platform. I do not advise tuning outside the platform's capabilities and will not mislead you with promises Hypernode technically does not allow.

What I do not do at server level

Transparency about what falls outside my scope prevents disappointment.

• ✕Kernel-level TCP tuning (BBR, socket buffers): no root on Hypernode, not possible and not my responsibility.
• ✕MySQL slave replication or read-replica setup: this requires DBA expertise and separate infrastructure outside Hypernode standard.
• ✕PHP-FPM configuration via systemd on shared hosting without FPM access: on hosts running PHP as an Apache module, FPM tuning is not available.
• ✕Guarantees on specific TTFB targets: I give a realistic expected range based on hosting plan and store configuration, not contractual targets.
• ✕Full server migration to different hosting: that is a separate project and falls outside speed tuning scope.

For frontend performance (hero image optimisation, third-party scripts, Hyvä, JavaScript bundling) I refer to the magento-performance page. Server-side and frontend performance are complementary but separate projects.

Related pages