Magento-2-TTFB senken: ein Core-Web-Vitals-Playbook für die Praxis

Um die Magento-2-TTFB zu senken: Varnish-Full-Page-Cache aktivieren, Sessions und Cache auf Redis legen, PHP 8.x mit OPcache und JIT betreiben und die Seite hinter ein CDN stellen. Die meisten langsamen Shops sind langsam, weil der Full-Page-Cache aus, falsch konfiguriert oder zu aggressiv invalidiert ist — beheben Sie zuerst das Caching.

Das Wichtigste

• Varnish-Full-Page-Cache ist der größte TTFB-Hebel — ein Cache-HIT sollte in zweistelligen Millisekunden ausgeliefert werden.
• Redis für Sessions und Cache entfernt Dateisystem- und DB-Konkurrenz.
• PHP 8.x + OPcache + JIT senkt die CPU-Zeit pro Request deutlich gegenüber PHP 7.4.
• Der versteckte Killer ist die Cache-Invalidierung: häufige Reindex/Cron-Flushes machen jeden Request zum MISS.
• Ein CDN liefert statische Assets und verkürzt den Netzwerkweg für globalen Traffic.

Schritt 1 — Prüfen, ob der Full-Page-Cache wirklich greift

Betreiben Sie die Seite hinter Varnish und verifizieren Sie Cache-HITs in Produktion (Response-Header prüfen). Überraschend viele „langsames Magento"-Fälle sind Shops, deren FPC auf den eingebauten Cache zeigt, durch einen falschen Header umgangen oder ständig geflusht wird. Messen Sie die HIT-Rate vor allem anderen.

Schritt 2 — Redis für Sessions und Cache

Legen Sie Magentos Default-Cache, das FPC-Backend und die Session-Speicherung auf Redis (idealerweise getrennte Instanzen/Datenbanken). Das entfernt Datei-Locking und Datenbank-Roundtrips aus dem heißen Pfad.

Schritt 3 — PHP 8.x, OPcache, JIT

Betreiben Sie PHP 8.1+ mit OPcache und realistischem opcache.memory_consumption. Aktivieren Sie JIT für CPU-lastige Workloads. Setzen Sie in Produktion zudem opcache.validate_timestamps=0 und reloaden Sie PHP-FPM beim Deploy, damit die Engine nicht bei jedem Request Dateien statet.

Schritt 4 — Nicht gegen den eigenen Cache kämpfen

Häufigste Regression: Cron, Indexer oder ein Drittmodul flusht den Full-Page-Cache im engen Takt. Stellen Sie Indexer auf „Update on Schedule", bündeln Sie Katalog-Updates und prüfen Sie, welche Events Cache-Leerungen auslösen. Eine periodisch hochschießende TTFB ist fast immer Invalidierung, nicht reine Rechenlast.

Schritt 5 — CDN und Asset-Disziplin

Liefern Sie statische Assets und Bilder über ein CDN, aktivieren Sie HTTP/2+ und kombinieren Sie das mit einem schnellen Frontend-Theme (Hyvä), damit das ausgelieferte, gecachte HTML auch leicht zu rendern ist.

Wie „gut" aussieht

Bei einem Cache-HIT eine TTFB deutlich unter 200 ms und einen mobilen LCP unter 2,5 s anstreben. Ist die TTFB gut, aber die Core Web Vitals scheitern weiterhin, hat sich der Engpass ins Frontend verlagert — das ist ein Theme-Problem, kein Server-Problem.

Den Engpass finden und quantifizieren lassen? System-Architektur-Audit oder Angebot anfordern.

Häufig gestellte Fragen

Was verursacht hohe TTFB in Magento 2?

Die häufigste Ursache ist ein Full-Page-Cache, der deaktiviert, falsch konfiguriert oder zu oft invalidiert ist, sodass Requests von Grund auf berechnet werden. Weitere Ursachen sind fehlendes Redis für Sessions/Cache, eine alte PHP-Version ohne OPcache und ein fehlendes CDN.

Verbessert Varnish die Magento-2-Performance?

Ja, erheblich. Varnish liefert gecachte Seiten in zweistelligen Millisekunden aus, statt den vollen Magento-PHP-Stack auszuführen. Es ist für die meisten Shops die größte TTFB-Verbesserung, sofern die Cache-Trefferrate wirklich hoch ist.

Sollte Magento 2 Redis verwenden?

Ja. Default-Cache, FPC-Backend und Session-Speicherung auf Redis zu legen entfernt Datei-Locking und Datenbank-Konkurrenz aus dem Request-Pfad und senkt sowie stabilisiert die Antwortzeiten.

Was ist eine gute TTFB für Magento 2?

Bei einem Full-Page-Cache-Hit eine TTFB unter etwa 200 Millisekunden und ein mobiler LCP unter 2,5 Sekunden. Ist die TTFB schnell, aber die Core Web Vitals scheitern, liegt der Engpass im Frontend-Theme, nicht am Server.