2022 landete eine Hosting-Vergleichsseite in meinem Posteingang. Großer Katalog, rund 4.000 Seiten, tief verschachtelte Kategoriestruktur, Affiliate-Links überall verstreut, Hero-Images in der Größe kleiner Kontinente. Ihre Google Search Console war ein Alptraum. LCP lag bei 4,2 Sekunden auf Mobile. INP (damals noch FID genannt) war grenzwertig. Der Kunde hatte bereits £6.000 bei einer anderen Agentur ausgegeben, die ein CDN draufgeworfen und es dabei belassen hatte.
Dieses Projekt hat letztendlich geprägt, wie wir bei Seahawk über Performance bei hochseitigen Websites denken – Directory-Sites, Listing-Plattformen, Hosting-Review-Properties wie HostList-artige Builds. Was folgt, ist das tatsächliche Playbook.
---
Warum große Websites LCP anders kaputtmachen
Kleine Websites haben einfache Probleme. Ein Hero-Image, ein Theme, ein Plugin das zu viel tut. Beheben Sie diese drei Dinge und Sie sind unter 2 Sekunden.
Große Websites? Ein ganz anderes Tier. Das LCP-Element ändert sich je nachdem, auf welcher Seite du bist. Ein Kategorieindex hat einen anderen LCP-Kandidaten als eine Produktdetailseite, die einen anderen hat als die Startseite. Die meisten Performance-Tools berichten einen einzelnen Score. Diese Zahl ist eine Lüge – es ist ein Durchschnitt einer wild variierenden Menge von Seiten, und die Startseite zu optimieren während man die 3.800 Listenseiten darunter ignoriert, ist genau das, wofür Agenturen sich einen schlechten Ruf verdienen.
Googles Core Web Vitals-Dokumentation ist da deutlich: Field Data zählt. Das sind die echten Nutzererfahrungen, gemessen im Chrome User Experience Report. Das ist, worauf Google bei Rankings schaut. Lab Data aus PageSpeed Insights? Das gibt dir Hinweise. Mehr nicht. Ich habe Websites erlebt, die 95 Punkte auf PSI erreicht haben und trotzdem Poor LCP in den CrUX-Daten aufweisen. Verwechsle das nicht. Die beiden sind unterschiedlich.
Die drei echten Verursacher auf Listing-Websites
Bei jeder großen Website, die ich auditiert habe (und ich habe inzwischen Hunderte durchgesehen), lassen sich LCP-Fehler fast jedes Mal auf drei Grundursachen zurückführen:
- Unoptimierte Hero- oder Card-Images, oft in voller Auflösung served, falsches Format, kein
fetchpriority-Hinweis - Render-blockierende Third-Party-Scripts, Affiliate-Tracker, Ad-Netzwerke, Vergleichs-Widgets, die laden, bevor der Browser etwas rendern kann
- TTFB, das das LCP-Budget aufbläht, langsame Serverantwort, die 600–900ms frisst, bevor die Seite überhaupt anfängt zu laden
Das dritte ist das, das Leute unterschätzen. Wenn dein TTFB 700ms ist, hast du bereits fast die Hälfte deines „Good"-LCP-Budgets ausgegeben, bevor der Browser ein einziges Pixel gerendert hat. Hosting-Wahl und serverseitiges Caching sind keine DevOps-Anliegen, sie sind SEO-Anliegen.
---
Beginne mit TTFB: Das ist zuerst ein Hosting- und Caching-Problem
Das HostList-ähnliche Projekt, das ich oben erwähnt habe? Das erste, was ich tat, war WebPageTest von fünf verschiedenen geografischen Standorten ausführen. TTFB war durchgehend 680-820ms. Die Website lief auf einem Shared Host in Virginia. Der Großteil des organischen Traffics kam aus dem UK und Deutschland.
Ich habe sie zu einem verwalteten WordPress-Host mit Edge-Knoten in London und Frankfurt migriert. Full-Page-Caching mit Cache-Lifetimes von 12 Stunden auf Listing-Seiten konfiguriert (die Daten ändern sich ohnehin nicht so oft). TTFB fiel auf 120–180ms bei wiederholten Anfragen, 280–350ms bei Cache-Misses beim ersten Zugriff. Diese einzelne Änderung reduzierte das LCP um ungefähr 500ms, bevor ich ein einziges Bild angetastet habe.
Es gibt ein paar Dinge, die ich auf der Hosting-Seite immer überprüfe:
- Funktioniert Full-Page-Caching tatsächlich? Überprüfe den
X-Cache-Response-Header. Falls er bei jeder einzelnen AnfrageMISSanzeigt, funktioniert deine Caching-Schicht nicht. - Liegt der Origin-Server geografisch nah bei deinem primären Publikum? Das klingt offensichtlich. Du wärst überrascht, wie oft das nicht stimmt.
- Ist Keep-Alive aktiviert? Einige günstigere Hosts deaktivieren immer noch persistente Verbindungen. Verrückt im Jahr 2024, aber es passiert.
- Ist HTTP/2 oder HTTP/3 aktiv? Führe
curl -I --http2 https://yourdomain.comaus und überprüfe das Protokoll in der Antwort.
Kümmere dich nicht um Bildoptimierung, bis du TTFB gelöst hast. Bilder auf einem langsamen Server zu optimieren ist wie ein Haus anzumalen, das in Flammen steht.
---
Das LCP-Image-Problem (Und warum `fetchpriority` alles verändert)
Richtig. Images. Auf einer Listing-Site mit Card-Grid-Layouts ist das LCP-Element fast immer das erste above-the-fold Card-Image oder das Hero-Banner. Der Browser muss es entdecken, fetchen, dekodieren und rendern. Jeder dieser Schritte kann verzögert werden.
Hier ist, was wir beim HostList-Projekt tatsächlich getan haben, der Reihe nach:
- Alle Kartenenbilder in WebP konvertiert, mit Imagify's Massenkonvertierung. Die durchschnittliche Dateigröße sank um 58%, ohne sichtbaren Qualitätsverlust bei den Kartenminiaturgrößen, die wir verwendeten (280×180px Anzeige, mit 2x für Retina bereitgestellt).
- `fetchpriority="high"` zum ersten Kartenbild hinzugefügt. Diese eine Änderung allein reduzierte die gemessene LCP um etwa 200ms in WebPageTest. Der Browser hört auf, es wie ein normales verzögertes Bild zu behandeln, und reiht es sofort in den Preload-Scanner ein.
- `loading="lazy"` aus den ersten zwei Reihen von Kartenenbildern entfernt. Lazy Loading ist großartig für Bilder unterhalb des Falzes. In der ersten sichtbaren Reihe schadet es dir aktiv. Es teilt dem Browser mit, das Bild nicht zu laden, bis es sich dem Viewport nähert, was es bereits tut.
- Ein `<link rel="preload">`-Tag für das Hero-Bild im `
<head>` auf dem Homepage-Template hinzugefügt.
Diese Abfolge brachte die Homepage-LCP von 3,1s auf 1,4s unter Laborbedingungen. Field-Daten folgten innerhalb von etwa 28 Tagen (das ist ungefähr die Zeit, die CrUX-Daten brauchen, um Änderungen in großem Maßstab widerzuspiegeln).
Eine Anmerkung zu responsiven Bildern
Wenn du dasselbe 1400px breite Bild auf einem Mobilgerät bereitstellst, verschleudert du Bandbreite und erhöhst die Dekodierungszeit. Nutze srcset richtig. Ich weiß, das klingt wie ein Gespräch aus 2016, aber ich sehe es immer noch auf wahrscheinlich 40% der Sites, die Seahawk durchlaufen. Die WordPress-Funktion wp_get_attachment_image() generiert srcset automatisch, aber nur, wenn das Bild mit ausreichender Auflösung hochgeladen wurde und das Theme es nicht mit add_filter('max_srcset_width', ...) unterdrückt hat.
---
Render-blockierende Skripte: Die Affiliate-Site-Steuer
Hosting-Vergleichssites und Listing-Plattformen leben vom Affiliate-Umsatz. Das bedeutet Third-Party-Tracking-Skripte. Commission Junction, Impact, Awin, benutzerdefinierte Pixel-Tracker, sie sammeln sich an. Ich habe 14 separate Third-Party-Skript-Ursprünge auf einer einzelnen Listing-Site gezählt. Jeder ist ein separater DNS-Lookup, eine TCP-Verbindung und ein TLS-Handshake, bevor ein einziges Byte dieses Skripts empfangen wird.
Die Lösung ist nicht, die Skripte zu entfernen. Das kannst du nicht, der Umsatz hängt davon ab. Die Lösung ist die Abfolge.
Kein Third-Party-Skript sollte jemals das initiale Rendering des LCP-Elements blockieren. Punkt.
Praktisch bedeutet das:
- Verschiebe alle Affiliate- und Analytics-Skripte so, dass sie nach dem
DOMContentLoaded-Event geladen werden, nicht in<head>. - Verwende
async- oderdefer-Attribute auf jedem Skript, das du kontrollierst. - Für Skripte, die du nicht kontrollierst (injiziert durch Tag Manager), lade Google Tag Manager selbst mit
defer, ja, das ist sicher für die meisten Affiliate-Tracking-Anwendungsfälle, und GTMs eigene Dokumentation bestätigt diesen Ansatz. - Verwende einen Script Manager wie Asset CleanUp Pro oder WP Rockets Script-Verzögerungsfunktion, um nicht wesentliche Third Parties bis zur Benutzerinteraktion (erstes Scrollen oder erster Klick) zu verschieben.
Beim HostList-Rebuild hat das Verschieben von Third-Party-Skripten die Total Blocking Time von 1.840 ms auf 290 ms gebracht. TBT ist zwar kein Core Web Vital selbst, hängt aber eng mit INP zusammen, und INP ist eines.
---
Font Loading: Der stille LCP-Killer, über den niemand spricht
Custom Fonts führen zu einem spezifischen Fehlermodus. Der Browser rendert dein Layout, erreicht das LCP-Textelement (manchmal ist LCP eine Überschrift, kein Bild), und wartet dann auf die Schriftdatei, bevor er sie zeichnet. Das nennt sich Flash of Invisible Text und verzögert LCP um irgendwo zwischen 200ms und über eine Sekunde, abhängig von der Schriftdateigröße und der Servernähe.
Zwei Dinge beheben dies:
- `
font-display: swap` in deiner@font-face-Deklaration, der Browser rendert sofort in einer Fallback-Schriftart und wechselt, wenn die benutzerdefinierte Schriftart lädt. Der LCP-Kandidat wird rechtzeitig gezeichnet. - Hoste deine Fonts selbst. Google Fonts fügt eine Cross-Origin-Anfrage hinzu. Self-Hosting mit dem google-webfonts-helper Tool lässt dich Fonts von deiner eigenen Domain servieren und spart diese zusätzliche Verbindung.
Ich habe ein großes Verzeichnis-Portal in etwa 45 Minuten von Google Fonts weg konvertiert, mit diesem Tool. LCP verbesserte sich um 180ms. Nicht transformativ allein, aber kombiniert mit allem anderen summieren sich diese Spielräume.
---
Messen, was wirklich zählt im Feld
CrUX-Daten sind die Grundwahrheit. Aber sie werden nur monatlich aktualisiert und nur für URLs mit ausreichend Traffic. Bei großen Sites mit Tausenden von Seiten brauchst du etwas Granulares.
Ich verwende PageSpeed Insights API über eine repräsentative Stichprobe von URLs, typischerweise die Top 100 Seiten nach Traffic, 50 Kategorieseiten und 20 "dünne" tiefe Katalogseiten. Diese monatliche Ausführung gibt eine richtige Leistungsverteilung, nicht einen einzelnen Punktwert.
In Lighthouse CI (das wir in CI/CD-Pipelines für Kunden mit Entwicklungszyklen ausführen) validieren wir gegen:
- LCP ≤ 2,5s im Lab (konservatives Ziel, da Field in der Regel um 10–15% hinter Lab hinterherhinkt)
- TBT ≤ 300ms
- CLS ≤ 0,1
Aber ehrlich gesagt, für einen HostList-ähnlichen Build, wo das Ziel eine LCP unter 1,5s ist, müssen die Lab-Ziele enger sein. Wir setzen LCP ≤ 1,8s in Lighthouse CI für diese Projekte, was typischerweise 1,3–1,5s in Field-Daten erzeugt, sobald CrUX aufgeholt hat.
---
Alles Zusammenfassen: Das HostList-Ergebnis
Nach der Durchführung aller oben genannten Punkte – Hosting-Migration, Full-Page-Caching, Bildformat-Konvertierung, fetchpriority bei LCP-Kandidaten, Lazy-Load-Entfernung aus oberflächennahen Zeilen, Script-Deferral und Font-Self-Hosting – sah die Bilanz wie folgt aus:
- TTFB: 780ms → 160ms (Median, Besucher aus UK)
- LCP (Lab, Mobile): 4,2s → 1,4s
- LCP (Field, CrUX, 75. Perzentil): 3,8s → 1,6s (gemessen 60 Tage nach der Migration)
- TBT: 1.840ms → 290ms
- CLS: war bereits mit 0,03 in Ordnung, unverändert
Nicht jede Website wird eine 2,8-Sekunden-Verbesserung erzielen. Aber fast jede große Listing-Site, an der ich gearbeitet habe, hatte all diese Probleme gleichzeitig, was bedeutet, dass sich die Gewinne addieren. Behebe ein Problem und du erhältst 300ms. Behebe alle und du erhältst 2,5 Sekunden.
---
FAQ
Ist Hosting wirklich so wichtig für LCP?
Ja, wahrscheinlich mehr als alles andere am Anfang. Wenn dein TTFB über 500ms liegt, wird keine noch so gute Bildoptimierung dir zu einem „Good" LCP verhelfen. TTFB ist das Fundament, auf dem alles andere aufbaut. Bring es zuerst unter 200ms, dann kümmere dich um den Rest.
Sollte ich einen CDN verwenden, anstatt den Host zu wechseln?
Ein CDN hilft bei der Auslieferung statischer Assets und kann die TTFB für gecachtes vollständiges HTML reduzieren, wenn es richtig konfiguriert ist. Aber viele CDN-Setups cachen nur Assets, nicht vollständige HTML-Responses. Prüfe, ob dein CDN tatsächlich gecachtes HTML ausliefert oder nur Images auslagert. Wenn letzteres, wird ein besserer Origin Host mehr für LCP tun.
Wird `fetchpriority="high"` jetzt weit verbreitet unterstützt?
Ab 2024 ja, es wird in Chrome, Edge und Safari unterstützt (seit Safari 17.2). Firefox-Unterstützung kam mit Firefox 132. Browser, die es nicht unterstützen, ignorieren es einfach. Es gibt keinen Nachteil, es deinem LCP-Bildelement hinzuzufügen.
Wie lange dauert es, bis CrUX-Daten Verbesserungen widerspiegeln?
Ungefähr 28 Tage, nachdem echte Benutzer die schnellere Version der Website erleben. CrUX nutzt ein rollendes 28-Tage-Fenster. Wenn du also Änderungen heute bereitstellst, werden deine Field-Data-Scores sie für etwa einen Monat nicht vollständig widerspiegeln. Keine Panik, wenn PageSpeed Insights am Tag nach deinem Optimierungs-Sprint immer noch „Verbesserung erforderlich" anzeigt.
Was ist die Änderung mit der höchsten Auswirkung auf eine Listing-Website?
Bei fast jedem Projekt war es TTFB. Aber das zweithäufigste war konsequent das Entfernen von loading="lazy" aus Above-Fold-Card-Images und das Hinzufügen von fetchpriority="high". Diese zwei Dinge zusammen machen normalerweise 40–60% der gesamten LCP-Verbesserung aus. Alles andere sind komponierende Gewinne auf diesem Fundament.
---
Performance-Arbeit auf großen Websites ist größtenteils Rohrleitungsbau. Unspektakulär, methodisch und zutiefst befriedigend, wenn du ein LCP von 4 Sekunden auf 1,4 Sekunden drückst und zwei Monate später den organischen Traffic ansteigen siehst. Es gibt keine einzelne magische Einstellung, nur eine Abfolge spezifischer Entscheidungen in der richtigen Reihenfolge.
Mach den Server schnell. Dann sorge dafür, dass das LCP-Element früh erkannt und abgerufen wird. Dann räum alles andere aus dem Weg.