Waarom TTFB de LCP van je shop stuurt
Time to First Byte is de tijd tussen het versturen van een HTTP-verzoek en het ontvangen van de eerste byte van de HTML-response. Voor een Magento 2 shop betekent een hoge TTFB dat de browser letterlijk staat te wachten voordat hij ook maar één pixel kan renderen. LCP kan niet beter zijn dan de TTFB plus de render-tijd van het LCP-element.
Google's CrUX-drempel voor TTFB is 800 milliseconden voor 'needs improvement'. Boven de 1800 milliseconden zit je in het rode vak. Op Hypernode-shops zonder geconfigureerde full-page cache zie ik TTFB van 1,2 tot 2,4 seconden regelmatig voorbijkomen. Dat is niet een frontend-optimalisatieprobleem: geen enkele hoeveelheid JavaScript-bundeling of image compression helpt als de server er 1,8 seconden over doet om te antwoorden.
Frontend-performance is het domein van de /shop/magento-performance pagina. Wat ik hier behandel is de laag eronder: de server-stack die bepaalt hoe snel Magento HTML genereert of uit cache serveert.
De Magento server-stack: van request tot HTML
Een Magento 2 verzoek loopt door meerdere lagen voor er HTML terugkomt. Elke laag kan een bottleneck zijn.
- ▸Nginx: reverse proxy en static file server. Normaal geen TTFB-probleem, maar verkeerde worker_processes of keepalive-instellingen kosten wel tijd.
- ▸PHP-FPM: de PHP process manager. Te weinig workers betekent dat requests in de wachtrij belanden. Te veel workers op een kleine server vreet geheugen en veroorzaakt swap.
- ▸OPcache: slaat gecompileerde PHP bytecode op in geheugen. Zonder OPcache hercompileert Magento elke request tienduizenden PHP-bestanden. Met OPcache maar te weinig memory_consumption verliest het steeds weer cache-entries.
- ▸Redis (full-page cache): slaat de volledige HTML-output van pagina's op. Een cache-hit serveert binnen 5 tot 30 milliseconden in plaats van 800ms tot 2 seconden voor een PHP-genereerde response.
- ▸Redis (session): slaat user sessions op. Op drukke shops concurreert dit met de FPC voor Redis-geheugen als je niet twee aparte Redis-instanties configureert.
- ▸Varnish: HTTP-accelerator die voor Nginx zit. Op Hypernode beschikbaar via Sentia-configuratie. Serveert cached responses op nagenoeg nul milliseconden server-side.
De TTFB van een ongetuned Magento 2 shop is typisch de PHP-FPM + MySQL-tijd gecombineerd. Elke cache-laag die je correct configureert haalt een stap uit die keten.
Wat ik tune en hoe
Ik werk met een vaste volgorde: meten, knelpunt isoleren, aanpassen, verifiëren via CrUX of PSI-lab. De typische tuning-punten per laag:
- ▸PHP-FPM pm.max_children: bepaald op basis van beschikbaar RAM gedeeld door gemiddeld PHP-procesgeheugen (vaak 80 tot 120 MB per worker op Magento). Te laag = queue, te hoog = swap.
- ▸OPcache opcache.memory_consumption: op Hypernode standaard 256 MB. Voor grote Magento-installaties met veel modules is 512 MB realistischer. Ik meet via opcache_get_status() hoeveel entries verloren gaan.
- ▸Redis full-page cache: maxmemory instellen op basis van shop-grootte. Eviction-policy op allkeys-lru zodat de meest bezochte pagina's in cache blijven. Twee aparte instanties voor FPC en sessions.
- ▸Redis maxmemory-policy controleren: volatile-lru verliest sessie-keys niet onverwacht, allkeys-lru gooit alles weg bij druk. Keuze hangt af van of FPC en sessions gedeeld zijn.
- ▸Varnish VCL: hit-ratio meten via varnishstat. Typische problemen zijn cookies die caching blokkeren, verkeerde Vary-headers of te lage default_ttl voor productpagina's.
- ▸MySQL slow-query log: queries boven 1 seconde identificeren. Magento genereert bij product-lijstpagina's zonder index op category_id + status veel trage queries.
- ▸MySQL innodb_buffer_pool_size: moet groot genoeg zijn om de hot dataset in geheugen te houden. Disk-reads op elke query zijn de stille TTFB-killer.
Ik doe geen blind 'alles maximaal'-tuning. Elke aanpassing heeft een reden en ik meet het effect voor en na. Op een 2 GB Hypernode-plan is een PHP-FPM pool van 20 workers correct; op een 4 GB plan is 35 realistischer.
Hypernode-specifieke beperkingen en hoe ik daarmee omga
Hypernode is een managed platform. Dat betekent goede defaults en betrouwbare infra, maar ook beperkingen die je op een zelfbeheerde VPS niet hebt.
- ▸Geen root-toegang: PHP-FPM en Nginx zijn niet via systemd te herstarten. Configuratiewijzigingen via de hypernode-manage-vhosts CLI of het Hypernode control panel.
- ▸OPcache-tuning: sommige OPcache-parameters zijn via php.ini te overschrijven, andere niet. Ik test welke parameters effectief zijn op het betreffende Hypernode-plan.
- ▸Varnish beschikbaar via Sentia-configuratie: activeren via het control panel. De VCL is beperkt aanpasbaar maar de standaard Magento 2 VCL dekt 80 procent van de gevallen.
- ▸Redis: twee Redis-instanties beschikbaar op Hypernode Professional en hoger. Op Starter-plannen is er een gedeelde instantie; dan schei ik FPC en sessions via aparte databases (db 0 en db 1).
- ▸MySQL: geen directe innodb_buffer_pool_size-aanpassing zonder Hypernode support. Ik optimaliseer via indexen en query-herschrijving in plaats van server-parameters.
Ik werk dagelijks met Hypernode in productie en ken de grenzen van het platform. Ik adviseer geen tuning die buiten de platformmogelijkheden valt en misleid je niet met beloftes die Hypernode technisch niet toelaat.
-- Klant-casus
CarCare24 op Hypernode: TTFB van 974ms naar 390ms (CrUX)
CarCare24 is een Magento 2 webshop met circa 3400 producten op Hypernode, met Cloudflare Free. De CrUX-data toonde een TTFB van 974 milliseconden op mobiel, wat in het 'needs improvement'-vak valt. De full-page cache draaide op Redis maar was onvoldoende geconfigureerd: te kleine maxmemory, geen aparte instantie voor sessions, en een hit-ratio van 62 procent via Varnish.
Na het scheiden van de Redis-instanties voor FPC en sessions, verhogen van de maxmemory op de FPC-instantie en het corrigeren van de Varnish VCL (Vary-header cleanup, cookie-whitelist voor Cloudflare) steeg de hit-ratio naar 91 procent. De CrUX-TTFB daalde naar 390 milliseconden: groen. PHP-FPM workers zijn bijgesteld van 8 naar 14 op het 2 GB plan na meting van het gemiddeld geheugengebruik per worker. Het gecombineerde effect: de LCP van de homepage daalde mee omdat de browser de HTML eerder ontvangt en eerder kan beginnen met laden van het LCP-element.
Wat ik niet doe op server-niveau
Transparantie over wat buiten mijn scope valt voorkomt teleurstellingen.
- ✕Kernel-level TCP-tuning (BBR, socket buffers): op Hypernode geen root, niet mogelijk en niet mijn verantwoordelijkheid.
- ✕MySQL slave-replicatie of read-replica setup: dit vereist DBA-expertise en aparte infrastructuur buiten Hypernode-standaard.
- ✕PHP-FPM configureren via systemd op shared hosting zonder FPM-toegang: op hosts die PHP als Apache module draaien is FPM-tuning niet beschikbaar.
- ✕Garanties op specifieke TTFB-targets: ik geef een realistisch verwacht bereik op basis van hostingplan en shop-configuratie, geen contractuele targets.
- ✕Volledige server-migratie naar andere hosting: dat is een apart traject en valt buiten snelheids-tuning scope.
Voor frontend-performance (hero image optimalisatie, derde-partij scripts, Hyvä, JavaScript-bundeling) verwijs ik naar de magento-performance pagina. Server-side en frontend-performance zijn complementair maar gescheiden trajecten.
Scope en prijs
De scope van een server-side tuning-traject hangt af van het hostingplan, de huidige cache-configuratie en hoe ver de TTFB vandaan zit van een acceptabel niveau. Een shop op Hypernode Starter met alleen Redis-misconfiguratie is een kortere opdracht dan een shop op shared hosting zonder FPM-toegang waar ook een hosting-migratie bij komt.
Prijzen op aanvraag. Ik stuur een voorstel op basis van een eerste technische inventarisatie. Die inventarisatie is gratis als je daarna met me in gesprek gaat.