Wenn die Marketingabteilung über Core Web Vitals spricht, meint sie meist Google-Positionen. Das ist nur halb richtig. Für einen Mid-Market-Shop ist die Geschwindigkeit der Seite vor allem ein Konversionshebel und erst danach ein Ranking-Signal. Der Kunde sieht Ihren Lighthouse-Wert nicht. Er sieht, dass die Produktseite in einer Sekunde statt in drei lädt, und erreicht häufiger den Warenkorb.
Dieser Text erklärt die drei Core-Web-Vitals-Metriken in einfacher Sprache und geht dann tiefer auf die eine Zahl ein, die den Rest regiert: TTFB. Wir zeigen, was sie antreibt, warum wir unter 200 ms zielen und was konkret auf Shopify Plus, PrestaShop, WooCommerce und Sylius zu tun ist. Am Ende finden Sie eine Checkliste, die Sie noch heute bei sich durchgehen können.
Core Web Vitals in einem Absatz: LCP, INP, CLS
Core Web Vitals sind die drei Metriken, mit denen Google die reale Nutzererfahrung beschreibt — gemessen nicht im Labor, sondern an echtem Traffic aus den Browsern Ihrer Kunden. Man sollte sie kennen, denn das ist die Sprache, in der über Performance sowohl mit dem technischen Team als auch mit der Geschäftsführung gesprochen wird.
LCP — wie schnell der wichtigste Inhalt sichtbar wird
Largest Contentful Paint misst, nach welcher Zeit das größte Inhaltselement auf dem Bildschirm erscheint: meist das Produktfoto oder die Überschrift. Es ist die Metrik, die dem am nächsten kommt, was ein Nutzer schlicht „die Seite ist geladen" nennen würde. Ziel: unter 2,5 Sekunden. Über 4 Sekunden beginnt der Kunde zu überlegen, ob er nicht zu den Suchergebnissen zurückkehrt.
INP — wie schnell die Seite auf eine Berührung reagiert
Interaction to Next Paint misst die Verzögerung zwischen einem Klick und einer sichtbaren Reaktion der Seite — dem Aufklappen eines Menüs, dem Hinzufügen zum Warenkorb, dem Öffnen einer Produktvariante. 2024 hat es die ältere Metrik FID ersetzt und ist deutlich anspruchsvoller, weil es die gesamte Verarbeitungszeit umfasst und nicht nur die erste Reaktion. Ziel: unter 200 ms. Ein hoher INP ist meist die Schuld zu schweren JavaScripts — eines überlasteten Haupt-Threads des Browsers.
CLS — springt der Inhalt unter dem Finger
Cumulative Layout Shift misst, wie stark sich das Layout der Seite beim Laden verschiebt. Jeder kennt den Moment: Sie wollen „jetzt kaufen" klicken, und in der letzten Sekunde lädt ein Banner nach und Sie klicken etwas anderes. Ziel: unter 0,1. Die Schuldigen sind meist Bilder ohne reservierte Abmessungen, Werbung und spät geladene Schriften.
Diese drei Metriken beschreiben, was man sieht. Aber bevor der Browser überhaupt beginnt, etwas zu rendern, muss er das erste Byte der Antwort vom Server erhalten. Und hier kommt eine Zahl ins Spiel, die auf der offiziellen Core-Web-Vitals-Liste nicht steht und dennoch entscheidet, ob die anderen überhaupt eine Chance haben, gut auszufallen.
TTFB: die Zahl außerhalb der Liste, die den ganzen Rest regiert
TTFB (Time to First Byte) ist die Zeit von dem Moment, in dem der Browser eine Anfrage sendet, bis zu dem Augenblick, in dem das erste Byte der Serverantwort zurückkommt. Sie besteht aus mehreren Etappen: DNS-Auflösung, Aufbau der TCP-Verbindung, Verhandlung der TLS-Verschlüsselung und dann — und das ist meist der größte, kontrollierbare Teil — der Zeit, in der der Applikationsserver die Antwort tatsächlich aufbaut.
TTFB ist keine der drei offiziellen Core-Web-Vitals-Metriken. Sie ist etwas Wichtigeres: sie ist ihr Fundament. LCP kann nicht schneller sein als TTFB, denn man kann keine Inhalte rendern, bevor das erste Byte eintrifft. Wenn das Backend 900 ms braucht, um das HTML zu generieren, ist ein LCP unter 2,5 Sekunden noch erreichbar, aber Sie kämpfen darum mit einer auf dem Rücken gefesselten Hand. Wenn das Backend in 150 ms antwortet, hat die gesamte übrige Frontend-Optimierung etwas, worauf sie aufbauen kann.
Jede Millisekunde TTFB ist eine Millisekunde, die LCP nie mehr zurückholt. Frontend-Optimierung auf einem langsamen Backend ist, als würde man Gras grün anmalen.
Deshalb behandeln wir TTFB in technischen Audits als erste Messung und nicht als Fußnote. Sie sagt, ob das Performanceproblem auf Serverseite oder im Browser liegt — und wo man überhaupt anfangen sollte.
Felddaten, nicht Daten vom Laptop
Eine Falle verdirbt die meisten Gespräche über TTFB: die Messung unter falschen Bedingungen. Ein Lighthouse-Ergebnis auf Ihrem Laptop, angeschlossen an die Firmenglasfaser und mit aufgewärmtem Cache, sind Labordaten — nützlich zum Debuggen, aber unbrauchbar als Abbild der Realität. Google bewertet eine Seite anhand von Felddaten, also echten Messungen aus den Browsern der Nutzer, gesammelt im CrUX-Report. Das sind zwei verschiedene Zahlen und sie weichen regelmäßig voneinander ab.
Die praktische Konsequenz: Messen Sie TTFB dort, wo Ihre Kunden sind, auf der Hardware und den Leitungen, die sie real nutzen, und beim ersten, nicht gecachten Treffer. Eine einzelne Messung ist eine Anekdote — Sie brauchen eine Verteilung, und man betrachtet meist das 75. Perzentil, weil dieses über die Bewertung entscheidet und darüber, wie viele Kunden tatsächlich warten. Ein dauerhaftes Real-User-Monitoring (RUM) sagt Ihnen, was ein einmaliger Test nie zeigt: dass TTFB in den Spitzenstunden steigt, wenn die Datenbank unter Last steht — also genau dann, wenn Sie am meisten Warenkörbe verlieren.
Was TTFB wirklich antreibt
Wenn TTFB hoch ist, liegt die Ursache fast immer in einem von vier Bereichen. Man sollte sie beim Namen kennen, denn „die Seite ist langsam" ist eine unbrauchbare Diagnose — „das Backend rendert die Produktseite in 700 ms, weil der Katalog 40 nicht indexierte Abfragen ausführt" hingegen nicht.
Backend-Zeit und Datenbankabfragen
Das ist der häufigste Schuldige in Mid-Market-Shops. Der Anwendungscode baut die Seite: Er holt Produkt, Preise, Verfügbarkeit, Empfehlungen, Warenkorbdaten. Wenn er das ineffizient tut — das klassische N+1-Problem, bei dem eine Schleife über 30 Produkte 30 separate Abfragen auslöst, fehlende Indizes, schwere Abfragen auf Statistiktabellen — wächst die Backend-Zeit linear mit dem Katalog. In einem unserer Legacy-Projekte konnten Abfragen gegen die monolithische Datenbank mehrere Sekunden dauern. Kein CDN behebt das, denn das Problem liegt im Code und im Datenbankschema.
Cache — auf jeder Ebene
Cache ist der günstigste Weg, TTFB zu senken, denn die schnellste Abfrage ist die, die Sie nicht ausführen. Er wirkt auf mehreren Ebenen gleichzeitig: OPcache hält kompilierten PHP-Bytecode, damit der Code nicht bei jeder Anfrage kompiliert wird; Object Cache (Redis, Memcached) hält die Ergebnisse wiederkehrender Datenbankabfragen; Full-Page-Cache (z. B. Varnish) liefert fertiges HTML für anonymen Traffic und berührt die Anwendung gar nicht. Ein Shop ohne Object Cache wiederholt dieselben Abfragen meist tausende Male pro Tag.
Hosting und PHP-Version
Shared Hosting für 30 PLN im Monat und ein dedizierter Server mit korrekt konfiguriertem PHP-FPM sind zwei verschiedene TTFB-Welten. Die Zahl der PHP-FPM-Worker, verfügbare CPU und I/O sowie die PHP-Version selbst wirken sich direkt aus. Der Sprung von PHP 7.4 auf 8.2 bedeutet oft einige Dutzend Millisekunden zurückgewonnen, ohne eine einzige Codezeile zu ändern — neuere Versionen führen denselben Code einfach schneller aus.
TLS, Netzwerk und CDN
Auch der TLS-Handshake und die physische Entfernung zum Server kosten. Ein Kunde aus Krakau, der sich mit einem Server in Frankfurt verbindet, zahlt eine Steuer auf jeden Kilometer. Ein CDN verkürzt diese Distanz, indem es Inhalte von einem Knoten näher am Nutzer ausliefert, und moderne Protokolle (HTTP/2, HTTP/3, TLS-Session-Resumption) reduzieren den Overhead des Verbindungsaufbaus. Für statische Inhalte und manchmal auch für das gesamte HTML sind das einige Dutzend Millisekunden gratis.
Warum unter 200 ms das richtige Ziel ist
Warum genau 200 ms? Weil das die Schwelle ist, an der das Backend aufhört, der Engpass zu sein. Unter 200 ms gibt der Server das erste Byte praktisch sofort heraus und überlässt das gesamte restliche Zeitbudget — jene 2,5 Sekunden für ein gutes LCP — dem, was das Frontend real beeinflusst: Bilder, Schriften, JavaScript. Das ist ein Ingenieursziel und kein Marketingziel: Es gibt dem Team Reserve, statt es zu zwingen, ab der ersten Millisekunde Verluste aufzuholen.
Die andere Seite der Medaille ist finanziell hart. In unseren Projekten und in Branchendaten korreliert ein TTFB über 500 ms mit einem Konversionsrückgang von 5–10%. Das ist kein linearer Abfall der Google-Positionen — das sind Kunden, die den Tab schließen, bevor die Seite antwortet. Für einen Shop mit einigen Dutzend Millionen Złoty Jahresumsatz sind diese wenigen Prozent ein Betrag, bei dem sich die Investition in Redis und Abfrageoptimierung in Wochen und nicht in Jahren rechnet.
Ehrlich gesagt: Nicht jeder Shop sollte alles stehen lassen, um von 250 auf 180 ms zu kommen. Wenn Ihr reales Problem ein hoher INP durch überlastetes JavaScript oder ein schwaches LCP durch unkomprimierte Hero-Bilder ist, dann liegt dort Ihr Geld und nicht im Backend. Deshalb ist die Reihenfolge immer dieselbe: Messen Sie zuerst, wo die Millisekunden tatsächlich verloren gehen, und investieren Sie erst danach. Aber wenn TTFB regelmäßig 500 ms überschreitet, ist das fast sicher Ihre günstigste und am schnellsten rentable Verbesserung.
Ein TTFB unter 200 ms ist kein Prahlen mit einer Zahl im Report. Es ist ein Zeitbudget, das Sie dem Kunden zurückgeben — und der Konversion.
Bogart Meble: der Beweis, dass das keine Theorie ist
Konkretes statt Theorie. Bei der Migration des Möbelshops Bogart von 12 Jahre altem Legacy (PHP 5.4, Custom-Framework, monolithische Datenbank) auf Symfony 6.4 war der Ausgangspunkt: Datenbankabfragen, die jeweils mehrere Sekunden dauerten. Die Ladezeit der Produktseite, gemessen als LCP, betrug mehrere Sekunden.
Nach dem Neuschreiben der Logik, dem Hinzufügen von Redis als Cache- und Session-Schicht, der Auslagerung der Produktsuche nach Elasticsearch und der Optimierung der Abfragen fiel der LCP auf unter eine Sekunde — mehrfach schneller. Es gab dabei keine Magie und keine einzige Silberkugel: Es gab einen Object Cache dort, wo sich dieselben Abfragen wiederholten, verbesserte Abfragen mit Indizes und die Entlastung der Datenbank von Operationen, die das Rendern der Seite nicht blockieren müssen. Der geschäftliche Effekt nach drei Monaten: ein deutlicher Anstieg der Konversion (in Kombination mit einem neuen Checkout). Den ganzen Case haben wir in unseren Projekten beschrieben.
Konkrete Schritte, Plattform für Plattform
TTFB optimiert man auf jeder Plattform anders, denn auf jeder kontrollieren Sie etwas anderes. Nachfolgend eine Karte: wo der Engpass meist liegt und womit man beginnt.
PlattformTypischer TTFB-EngpassErster Schritt mit dem größten ErtragShopify PlusApp-Bloat und schweres Liquid; den Server kontrollieren Sie nichtAudit der Apps und Third-Party-Skripte, Vereinfachung des TemplatesPrestaShopKein OPcache, schwaches Hosting, nicht optimale AbfragenOPcache + PHP-FPM + Full-Page-CacheWooCommerceKein Object Cache, Plugin-Bloat, langsame DatenbankRedis als Object Cache + Durchsicht der PluginsSylius / SymfonyDoctrine-Abfragen (N+1), kein Cache und keine WarteschlangenRedis + Abfrageoptimierung + Messenger für Async-Aufgaben
Shopify Plus
Bei Shopify berühren Sie den Server nicht — das HTML wird vom globalen Edge/CDN der Plattform ausgeliefert, der rohe TTFB ist also meist von Haus aus gut. Ihr Engpass liegt anderswo: im App-Bloat und im Template. Jede installierte App bringt ihr eigenes JavaScript, CSS und häufig externe Skripte mit; schwere, verschachtelte Schleifen in Liquid können die Renderzeit aufblähen. Schritte: Prüfen Sie die App-Liste und entfernen Sie ungenutzte (bedenken Sie, dass bezahlte oft 80–300 USD monatlich kosten — Bloat kostet doppelt), verschieben Sie Third-Party-Skripte nach hinten, vereinfachen Sie Liquid und vermeiden Sie Schleifen über große Kollektionen. Wenn das Template an seine Grenzen stößt, ist die Lösung Hydrogen — ein Headless-Frontend in React, am Edge gerendert, mit voller Kontrolle darüber, was wann geladen wird. Ein realistisches Ziel für eine gut gemachte Umsetzung sind Core Web Vitals von 90+. Mehr zur Architektur auf der Seite der Plattform Shopify Plus.
PrestaShop
PrestaShop hosten Sie selbst, TTFB liegt also zu 100% in Ihren Händen — und das ist eine gute Nachricht. In der Reihenfolge des größten Ertrags: Aktivieren und konfigurieren Sie OPcache (und prüfen Sie seine Hit Rate), stimmen Sie die Zahl der PHP-FPM-Worker auf die verfügbare CPU ab, aktivieren Sie den eingebauten Smarty-Template-Cache und das Zusammenfassen von Assets (CCC), und ergänzen Sie für anonymen Traffic einen Full-Page-Cache oder Varnish. Auf der Datenbankseite: Finden Sie langsame Abfragen im Slow Query Log, ergänzen Sie fehlende Indizes, räumen Sie aufgeblähte Statistik- und Verbindungstabellen auf. Stellen Sie zuletzt sicher, dass Sie auf PHP 8.x stehen und auf Hosting, das nicht mit tausend anderen Seiten geteilt wird.
WooCommerce
In WooCommerce (also WordPress plus Shop-Schicht) ist der größte Hebel der Object Cache. Redis hinzuzufügen, das wiederkehrende Abfragen abfängt — Optionen, Transients, Produkt-Meta —, kann TTFB dramatisch senken, zumal Warenkorb und Checkout nicht vollständig gecacht werden können und dort jede Datenbankabfrage zählt. Die zweite Front ist Plugin-Bloat: Jedes Plugin bringt Abfragen und Einträge in autoloaded options; prüfen Sie die Liste ohne Sentimentalität und räumen Sie abgelaufene Transients und eine ausgewucherte wp_options auf. Die dritte: Hosting. Managed Hosting für WooCommerce mit PHP 8.x, OPcache und PHP-FPM ist ein anderes Niveau als ein universelles Shared-Paket. Für anonymen Traffic ergänzen Sie einen Full-Page-Cache; für eingeloggte Nutzer setzen Sie auf ein schnelles Backend und den Object Cache.
Sylius / Symfony
Bei Custom-Builds auf Symfony kontrollieren Sie alles — und der ganze Werkzeugkasten steht offen. Redis als Cache-Pool und Session-Speicher ist der Startpunkt (genau diesen Schritt haben wir bei Bogart gemacht). Auf der Doctrine-Seite: Spüren Sie N+1-Abfragen auf, aktivieren Sie den Second-Level-Cache dort, wo es Sinn hat, steuern Sie Eager und Lazy Loading bewusst. Schwere Operationen — Mailversand, Indexierung, Webhooks, ERP-Synchronisation — verlagern Sie über Messenger in Warteschlangen, damit die Anfrage sofort zum Kunden zurückkehrt, statt auf Arbeit zu warten, die warten kann. Dazu die Produktionsgrundlagen, die man leicht vergisst: APP_ENV=prod, optimierter Autoloader, aufgewärmter Cache und OPcache mit Preloading. Die Produktsuche sollte man Elasticsearch überlassen, um die Hauptdatenbank nicht zu belasten.
Checkliste: was Sie bei sich prüfen sollten
Eine Kontrollliste zum Durchgehen, unabhängig von der Plattform. Lautet die Antwort an einem Punkt „ich weiß nicht" — genau dort sollten Sie anfangen.
Messen Sie TTFB unter Produktionsbedingungen, von den Standorten Ihrer Kunden aus, und nicht aus dem Browser-Cache auf dem eigenen Laptop.
Prüfen Sie, wie lange allein das Rendern im Backend dauert. Über 500 ms suchen Sie die Ursache in Datenbank und Cache, nicht im Frontend.
Stellen Sie sicher, dass OPcache aktiviert ist, und prüfen Sie seine Hit Rate.
Ergänzen Sie einen Object Cache (Redis oder Memcached) dort, wo sich dieselben Abfragen wiederholen.
Finden Sie N+1-Abfragen und langsame Abfragen im Slow Query Log; ergänzen Sie fehlende Indizes.
Verlagern Sie schwere Operationen (Mails, Indexierung, Webhooks, Synchronisationen) in asynchrone Warteschlangen.
Liefern Sie statische Assets — und wenn möglich auch das HTML — von einem CDN nahe am Kunden aus.
Prüfen Sie die PHP-Version. Der Sprung von 7.x auf 8.x bringt oft einige Dutzend Millisekunden gratis.
Begrenzen Sie die Zahl der Plugins, Apps und Third-Party-Skripte auf jene, die real arbeiten.
Richten Sie ein dauerhaftes Monitoring von TTFB und Core Web Vitals mit Alarmen ein. Einmal pro Quartal messen ist kein Monitoring.
Fazit
Core Web Vitals sind keine SEO-Checkbox, sondern ein Konversionshebel — und TTFB ist sein Fundament, denn er regiert alles, was später auf der Seite passiert. Zielen Sie unter 200 ms, behandeln Sie 500 ms als Alarmsignal, und suchen Sie die größten Erträge dort, wo sie immer sind: in der Datenbank und im Cache. Das Beispiel Bogart zeigt, dass der Sprung von mehreren Sekunden auf unter eine Sekunde keine Esoterik ist, sondern geordnete Ingenieursarbeit.
Wenn Sie wissen möchten, wo genau Ihre Millisekunden liegen und wie viel sie real an Konversion kosten, damit beginnen wir jedes Projekt — unser Shop-Audit misst TTFB, LCP, CLS und INP im Kontext Ihrer Branche und Konkurrenz, mit einer Prognose der Wirkung auf den Umsatz. Gern zeigen wir, wie das bei Ihnen aussieht — schreiben Sie uns über unsere Kontaktseite.