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.performance at Seahawk for high-page-count sites, directory sites, listing platforms, hosting review properties like HostList-style builds. What follows is the actual 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.which page you're on. A category archive has a different LCP candidate than a product detail page, which has a different candidate than the homepage. Most performance tools report a single score. That number is a lie, it's an average of a wildly varied set of pages, and fixing the homepage while ignoring the 3,800 listing pages underneath it is exactly how agencies earn bad reputations.
Die Core Web Vitals-Dokumentation von Google macht klar, dass Field Data – das, was echte Nutzer erleben, gemessen im Chrome User Experience Report – das ist, was Google tatsächlich für Ranking-Signale nutzt. Lab Data von PageSpeed Insights ist richtungsweisend, nicht definitiv. Ich habe Websites gesehen, die 95 auf PSI scored haben und dennoch Poor LCP in CrUX-Daten zeigen. Verwechsle die zwei nicht.Core Web Vitals documentation from Google is clear that field data, what real users experience, measured in Chrome User Experience Report, is what Google actually uses for ranking signals. Lab data from PageSpeed Insights is directional, not definitive. I've seen sites score 95 on PSI and still have Poor LCP in CrSX data. Don't confuse the two.
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, often served at full resolution, wrong format, no
fetchpriorityhint - Render-blockierende Third-Party-Scripts, Affiliate-Tracker, Ad-Netzwerke, Vergleichs-Widgets, die laden, bevor der Browser etwas rendern kann, affiliate trackers, ad networks, comparison widgets loading before the browser can paint anything
- TTFB, das das LCP-Budget aufbläht, langsame Serverantwort, die 600–900ms frisst, bevor die Seite überhaupt anfängt zu laden, slow server response eating 600-900ms before the page even starts loading
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.WebPageTest from five different geographic locations. TTFB was consistently 680-820ms. The site was on a shared host in Virginia. Most of their organic traffic came from the UK and Germany.
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.WordPress host with edge nodes in London and Frankfurt. Configured full-page caching with cache lifetimes of 12 hours on listing pages (the data didn't change that often anyway). TTFB dropped to 120-180ms on repeat requests, 280-350ms on first-hit cache misses. That single change shaved roughly 500ms off LCP before I touched a single image.
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 Anfrage MISS anzeigt, funktioniert deine Caching-Schicht nicht. Check the
X-Cacheresponse header. If it saysMISSon every single request, your caching layer isn't functioning. - Liegt der Origin-Server geografisch nah bei deinem primären Publikum? Das klingt offensichtlich. Du wärst überrascht, wie oft das nicht stimmt. This sounds obvious. You'd be surprised how often it's wrong.
- Ist Keep-Alive aktiviert? Einige günstigere Hosts deaktivieren immer noch persistente Verbindungen. Verrückt im Jahr 2024, aber es passiert. Some cheaper hosts still disable persistent connections. Wild in 2024, but it happens.
- Ist HTTP/2 oder HTTP/3 aktiv? Führe curl -I --http2 https://yourdomain.com aus und überprüfe das Protokoll in der Antwort. Run
curl -I --http2 https://yourdomain.comand check the protocol in the response.
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)., using Imagify's bulk conversion. Average file size dropped 58% without visible quality loss at the card thumbnail sizes we were using (280×180px display, served at 2x for retina).
- `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., This one change alone knocked ~200ms off measured LCP in WebPageTest. The browser stops treating it like a regular lazy image and queues it immediately in the preload scanner.
- `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., Lazy loading is brilliant for below-fold images. On the first visible row, it actively hurts you. It tells the browser to not fetch the image until it's near the viewport, which it already is.
- Ein `<link rel="preload">`-Tag für das Hero-Bild im `<head>` auf dem Homepage-Template hinzugefügt. in the
<head>on the homepage template specifically.
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.srcset properly. I know this sounds like a 2016 conversation but I still see it on probably 40% of the sites that come through Seahawk. The WordPress wp_get_attachment_image() function generates srcset automatically, but only if the image was uploaded at sufficient resolution and the theme hasn't suppressed it with add_filter('max_srcset_width', ...).
---
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>.after the
DOMContentLoadedevent, not in<head>. - Verwende async- oder defer-Attribute auf jedem Skript, das du kontrollierst.
asyncordeferattributes on every script you control. - 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.
defer, yes, this is safe for most affiliate tracking use cases, and GTM's own documentation acknowledges this approach. - 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 reduzierte das Verschieben von Third-Party-Skripten die Total Blocking Time von 1.840 ms auf 290 ms. TBT ist nicht direkt ein Core Web Vital, korreliert aber stark mit INP, was es ist.is.
---
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.in your@font-facedeclaration, the browser renders in a fallback font immediately and swaps when the custom font loads. LCP candidate gets painted on time.- 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.google-webfonts-helper tool lets you serve fonts from your own domain, cutting that extra connection.
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.PageSpeed Insights API scripted across a representative sample of URLs, typically the top 100 pages by traffic, 50 category-level pages, and 20 "thin" deep-catalogue pages. Running this monthly gives a proper performance distribution, not a single-point score.
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:fetchpriority on LCP candidates, lazy-load removal from above-fold rows, script deferral, and font self-hosting, here's what the numbers looked like:
- TTFB: 780ms → 160ms (Median, Besucher aus UK): 780ms → 160ms (median, UK visitors)
- LCP (Lab, Mobile): 4,2s → 1,4s: 4.2s → 1.4s
- LCP (Field, CrUX, 75. Perzentil): 3,8s → 1,6s (gemessen 60 Tage nach der Migration): 3.8s → 1.6s (measured 60 days post-migration)
- TBT: 1.840ms → 290ms: 1,840ms → 290ms
- CLS: war bereits mit 0,03 in Ordnung, unverändert: was already fine at 0.03, unchanged
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.loading="lazy" from above-fold card images and adding fetchpriority="high". Together those two things usually account for 40-60% of the total LCP improvement. Everything else is compounding gains on top of that foundation.
---
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.