Magento 2-TTFB verlagen: een Core Web Vitals-playbook voor de praktijk

Om de Magento 2-TTFB te verlagen: schakel Varnish full-page cache in, zet sessies en cache op Redis, draai PHP 8.x met OPcache en JIT en zet de site achter een CDN. De meeste trage winkels zijn traag omdat de full-page cache uit staat, verkeerd geconfigureerd is of te agressief wordt geïnvalideerd — los eerst het caching op.

Belangrijkste punten

• Varnish full-page cache is de grootste TTFB-hefboom — een cache-HIT moet in tientallen milliseconden geleverd worden.
• Redis voor sessies en cache verwijdert bestandssysteem- en DB-concurrentie.
• PHP 8.x + OPcache + JIT verlaagt de CPU-tijd per request merkbaar versus PHP 7.4.
• De verborgen killer is cache-invalidatie: frequente reindex/cron-flushes maken elke request een MISS.
• Een CDN levert statische assets en verkort het netwerktraject voor wereldwijd verkeer.

Stap 1 — Bevestig dat de full-page cache echt werkt

Draai de site achter Varnish en verifieer cache-HITs in productie (controleer de response-headers). Verrassend veel "traag Magento"-gevallen zijn winkels waar FPC op de ingebouwde cache staat, omzeild wordt door een verkeerde header of constant wordt geflusht. Meet de HIT-ratio vóór alles.

Stap 2 — Redis voor sessies en cache

Zet Magento's default cache, het full-page cache-backend en de sessie-opslag op Redis (idealiter aparte instances/databases). Dit verwijdert bestands-locking en database-roundtrips uit het hete pad.

Stap 3 — PHP 8.x, OPcache, JIT

Draai PHP 8.1+ met OPcache en een realistische opcache.memory_consumption. Schakel JIT in voor CPU-gebonden workloads. Zet in productie ook opcache.validate_timestamps=0 en reload PHP-FPM bij deploy, zodat de engine niet bij elke request bestanden statet.

Stap 4 — Stop met vechten tegen je eigen cache

Meest voorkomende regressie: cron, indexers of een externe module flusht de full-page cache in een strak schema. Zet indexers op "Update on Schedule", batch catalogusupdates en audit welke events cache-leegmaak veroorzaken. Een TTFB die periodiek piekt is bijna altijd invalidatie, geen pure rekenkracht.

Stap 5 — CDN en asset-discipline

Lever statische assets en afbeeldingen via een CDN, schakel HTTP/2+ in en combineer dit met een snel frontend-thema (Hyvä) zodat de geleverde, gecachte HTML ook licht te renderen is.

Hoe "goed" eruitziet

Streef bij een cache-HIT naar een TTFB ruim onder 200 ms en een mobiele LCP onder 2,5 s. Is de TTFB goed maar falen de Core Web Vitals nog steeds, dan is het knelpunt naar het frontend verschoven — dat is een thema-probleem, geen serverprobleem.

Het knelpunt laten vinden en kwantificeren? Systeemarchitectuur-audit of vraag een offerte aan.

Veelgestelde vragen

Wat veroorzaakt hoge TTFB in Magento 2?

De meest voorkomende oorzaak is een full-page cache die uit staat, verkeerd geconfigureerd is of te vaak wordt geïnvalideerd, waardoor requests vanaf nul worden berekend. Andere oorzaken zijn ontbrekende Redis voor sessies/cache, een oude PHP-versie zonder OPcache en geen CDN.

Verbetert Varnish de Magento 2-prestaties?

Ja, aanzienlijk. Varnish levert gecachte pagina's in tientallen milliseconden in plaats van de volledige Magento-PHP-stack uit te voeren. Het is voor de meeste winkels de grootste TTFB-verbetering, mits de cache-hitratio echt hoog is.

Moet Magento 2 Redis gebruiken?

Ja. Default cache, FPC-backend en sessie-opslag op Redis zetten verwijdert bestands-locking en database-concurrentie uit het request-pad, wat de responstijden verlaagt en stabiliseert.

Wat is een goede TTFB voor Magento 2?

Bij een full-page cache-hit een TTFB onder ongeveer 200 milliseconden en een mobiele LCP onder 2,5 seconden. Is de TTFB snel maar falen de Core Web Vitals, dan ligt het knelpunt bij het frontend-thema, niet bij de server.