Im Jahr 2022 landete eine Hosting-Vergleichswebsite in meinem Posteingang. Großer Katalog — etwa 4.000 Seiten, tief verschachtelte Kategoriestruktur, Affiliate-Links überall verstreut, Hero-Images so groß wie kleine Kontinente. Ihre Google Search Console war ein Albtraum. LCP bei 4,2 Sekunden auf mobil. INP (damals noch FID genannt) grenzwertig. Der Kunde hatte bereits £6.000 bei einer vorherigen Agentur ausgegeben, die einen CDN drübergeworfen hatte und es dabei belassen hatte.
Dieses Projekt hat letztendlich geprägt, wie wir bei Seahawk über Performance bei hochseitenzähligen Websites denken — Directory-Sites, Listing-Plattformen, Hosting-Review-Properties wie HostList-ähnliche Builds. Das Folgende ist das echte Playbook.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 Kaliber. Das LCP-Element ändert sich je nachdem, auf welcher Seite du dich befindest. Ein Kategorie-Archiv hat einen anderen LCP-Kandidaten als eine Produktdetailseite, die wiederum einen anderen hat als die Startseite. Die meisten Performance-Tools geben einen einzelnen Score aus. Diese Zahl ist eine Lüge — es ist ein Durchschnitt einer wild durcheinander gewürfelten Menge von Seiten, und die Startseite zu optimieren, während man die 3.800 Listenseiten darunter ignoriert, ist genau der Weg, wie 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 ist klar: Field Data — das, was echte Nutzer erleben und was im Chrome User Experience Report gemessen wird — ist das, was Google tatsächlich für Ranking-Signale nutzt. Lab Data aus PageSpeed Insights ist richtungsweisend, nicht maßgeblich. Ich habe Websites gesehen, die in PSI 95 Punkte erreichen und dennoch schlechte LCP in CrSX-Daten aufweisen. Verwechsle die beiden 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-Bilder — oft in voller Auflösung bedient, falsches Format, kein fetchpriority-Hinweis — often served at full resolution, wrong format, no
fetchpriorityhint - Render-blockierende Third-Party-Scripts — Affiliate-Tracker, Ad Networks, Vergleichs-Widgets, die laden, bevor der Browser etwas darstellen kann — affiliate trackers, ad networks, comparison widgets loading before the browser can paint anything
- TTFB belastet das LCP-Budget — langsame Server-Antwort konsumiert 600–900ms, bevor die Seite überhaupt anfängt zu laden — slow server response eating 600–900ms before the page even starts loading
Diese dritte ist diejenige, die Menschen unterschätzen. Wenn dein TTFB 700ms beträgt, hast du bereits fast die Hälfte deines „Good"-LCP-Budgets aufgebraucht, bevor der Browser auch nur ein einzelnes Pixel gerendert hat. Die Wahl des Hostings und Server-seitiges Caching sind keine DevOps-Sorgen — sie sind SEO-Sorgen.
---
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 aus auszuführen. TTFB lag durchgehend zwischen 680–820ms. Die Website lief auf einem Shared Host in Virginia. Der Großteil ihres organischen Traffics kam aus Großbritannien 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 verlagerte sie auf einen verwalteten WordPress-Host mit Edge-Nodes in London und Frankfurt. Ich konfigurierte Full-Page-Caching mit Cache-Lifetimes von 12 Stunden auf Listing-Seiten (die Daten änderten sich ohnehin nicht so häufig). TTFB sank auf 120–180ms bei wiederholten Anfragen, 280–350ms bei First-Hit-Cache-Misses. Diese einzelne Änderung reduzierte das LCP um etwa 500ms, bevor ich ein einziges Bild angerührt hatte.
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. Bilder. Bei einer Listing-Site mit Card-Grid-Layouts ist das LCP-Element fast immer das erste Card-Bild über der Faltkante — oder das Hero-Banner. Der Browser muss es entdecken, abrufen, 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 Card-Bilder in WebP konvertiert — mit Imagify's Bulk-Konvertierung. Die durchschnittliche Dateigröße sank um 58%, ohne sichtbaren Qualitätsverlust bei den Card-Thumbnail-Größen, die wir verwendet haben (280×180px Display, bei 2x für Retina serviert). — 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 Card-Bild hinzugefügt — Diese eine Änderung allein sparte ~200ms bei der gemessenen LCP in WebPageTest. Der Browser behandelt es nicht mehr wie ein reguläres Lazy-Loading-Bild 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 Zeilen von Card-Bildern entfernt — Lazy Loading ist großartig für Bilder unterhalb der Faltkante. In der ersten sichtbaren Zeile schadet es dir aktiv. Es sagt dem Browser, das Bild nicht zu laden, bis es in der Nähe des Viewports ist — was es bereits ist. — 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 das gleiche 1400px breite Bild auf einem Mobilgerät servierst, verschwendest du Bandbreite und addierst Dekodierungszeit. Nutze srcset richtig. Ich weiß, das klingt wie ein Gespräch von 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-Vergleichsseiten und Listing-Plattformen leben von Affiliate-Einnahmen. Das bedeutet Third-Party-Tracking-Skripte. Commission Junction, Impact, Awin, benutzerdefinierte Pixel-Tracker — sie häufen sich an. Ich habe 14 separate Third-Party-Skript-Ursprünge auf einer einzelnen Listing-Site gezählt. Jeder ist eine separate DNS-Abfrage, TCP-Verbindung und TLS-Handshake, bevor ein einziges Byte dieses Skripts empfangen wird.
Die Lösung ist nicht, die Skripte zu entfernen. Das kannst du nicht — die Einnahmen hängen davon ab. Die Lösung ist die Sequenzierung.
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 von Tag Managern), lade Google Tag Manager selbst mit defer — ja, das ist sicher für die meisten Affiliate-Tracking-Use-Cases, 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-Schrift und tauscht aus, wenn die Custom Font 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 nutze die PageSpeed Insights API, die über eine repräsentative Stichprobe von URLs läuft — typischerweise die Top-100-Seiten nach Traffic, 50 Category-Level-Seiten und 20 „dünne" Deep-Catalogue-Seiten. Eine monatliche Ausführung liefert eine angemessene Performance-Verteilung, keine einzelne Punktbewertung.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 üblicherweise 10–15% hinter Lab zurückbleibt)
- TBT ≤ 300ms
- CLS ≤ 0,1
Aber ehrlich — bei einem HostList-typischen Build, wo das Ziel sub-1,5s LCP ist, müssen 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 produziert, sobald CrUX aufgeholt hat.
---
Alles Zusammenfassen: Das HostList-Ergebnis
Nach Durchlaufen all der oben genannten Schritte — Hosting-Migration, Full-Page-Caching, Bildformat-Konvertierung, fetchpriority auf LCP-Kandidaten, Lazy-Load-Entfernung aus Above-Fold-Zeilen, Script-Deferral und Font-Self-Hosting — sah die Bilanz folgendermaßen 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 wichtiger als fast alles andere am Anfang. Wenn dein TTFB über 500ms liegt, wird keine Menge an Bildoptimierung dir zu einem „guten" 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?
Stand 2024: ja — es wird in Chrome, Edge und Safari unterstützt (seit Safari 17.2). Firefox-Unterstützung kam in Firefox 132. In Browsern, die es nicht unterstützen, wird es sicher ignoriert. Es gibt keinen Nachteil, es deinem LCP-Image-Element 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 die TTFB. Aber das Zweithöchste war durchweg das Entfernen von `loading="lazy"` von 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 ist Gewinn auf dieser Grundlage.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 hauptsächlich Rohbau. Unglamourös, methodisch und zutiefst befriedigend, wenn du eine 4-Sekunden-LCP auf 1,4 Sekunden senken kannst und zwei Monate später der organische Traffic steigt. Es gibt keine 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.