Was ist LCP? Largest Contentful Paint verbessern

Was ist LCP (Largest Contentful Paint)?
LCP steht für Largest Contentful Paint und ist eine Core Web Vitals Metrik. Sie misst, wie lange das größte Bild oder der größte Textblock im sichtbaren Bereich braucht, bis er nach dem Aufruf einer Seite vollständig dargestellt ist. Kurz gesagt, LCP beschreibt die gefühlte Ladegeschwindigkeit.
Die Metrik zeigt nicht, wann die Seite technisch fertig ist. Stattdessen zeigt sie, wann Besucher den Eindruck haben, dass der Inhalt da ist. Deshalb bildet sie die echte Erfahrung besser ab als ältere Kennzahlen. Der Browser lädt im Hintergrund vielleicht Dutzende Dateien, aber Menschen achten nur auf das große Hauptbild.
Unser Team schaut bei Performance Analysen daher zuerst auf LCP. Denn die Kennzahl verbindet Nutzererlebnis, Sichtbarkeit in der Suche und Umsatz. Einen Überblick über alle Metriken finden Sie in unserem Core Web Vitals Leitfaden. In diesem Artikel konzentrieren wir uns allein auf LCP.
Warum ist LCP für SEO und Conversions wichtig?
LCP gehört zu den Page Experience Signalen von Google. Ein schlechter Wert allein ruiniert Ihr Ranking nicht. Allerdings kann die Geschwindigkeit den Ausschlag geben, wenn zwei Seiten inhaltlich ähnlich gut sind. Der größere Effekt zeigt sich im Nutzerverhalten.
Wenn eine Seite spät erscheint, warten Besucher nicht. Dann klicken sie zurück. Folglich steigt die Absprungrate und die Conversion sinkt, vor allem auf dem Smartphone und bei langsamen Verbindungen.
Zudem leidet bezahlter Traffic darunter. Bei Google Ads zahlen Sie für den Klick, deshalb verpufft bei einer langsamen Zielseite ein Teil des Budgets. Den Zusammenhang zwischen Tempo und Ranking erklären wir in unserem Artikel, wie die Ladezeit SEO beeinflusst.
- Organische Sichtbarkeit: Page Experience liefert ein kleines, aber echtes Signal.
- Conversion: Erscheint das Produktbild spät, verlassen Besucher die Seite vor dem Kauf.
- Werbeeffizienz: Eine schnellere Zielseite macht aus demselben Budget mehr echte Besuche.
Kurz gesagt, LCP ist nicht nur ein technischer Wert. Er hängt direkt mit dem Umsatz zusammen.
Welche LCP Grenzwerte gelten? Was ist ein guter LCP Wert?
Google nennt klare Grenzwerte. Konkret gilt laut web.dev Leitfaden zu LCP ein LCP von 2,5 Sekunden oder weniger als gut. Werte über 4 Sekunden gelten dagegen als schlecht. Dazwischen besteht also Verbesserungsbedarf.
| Bewertung | LCP Zeit | Was Sie tun sollten |
|---|---|---|
| Gut | 2,5 Sekunden oder weniger | Setup beibehalten und regelmäßig beobachten |
| Verbesserungsbedarf | Zwischen 2,5 und 4 Sekunden | Die größte Verzögerung finden und beheben |
| Schlecht | Über 4 Sekunden | Sofort angehen und alle Teilphasen prüfen |
Wichtig ist das Perzentil. Google bewertet das 75. Perzentil aller Seitenaufrufe. Das heißt, mindestens 75 Prozent Ihrer Besuche sollten einen LCP unter 2,5 Sekunden haben. Ein einzelner schneller Test reicht also nicht.
Außerdem werden Mobilgeräte und Desktop getrennt bewertet. Mobile Werte fallen meist schlechter aus, daher empfehlen wir, zunächst den mobilen Wert zu verbessern.
Welche Elemente zählen als LCP Element?
Das LCP Element ist der größte Inhaltsteil im sichtbaren Bereich zum Zeitpunkt der Messung. Es unterscheidet sich daher von Seite zu Seite. Zum Beispiel ist es manchmal das Hauptbild, manchmal ein großer Überschriftenblock.
Die Spezifikation lässt nur bestimmte Elementtypen als Kandidaten zu. Der web.dev Leitfaden zu LCP nennt diese:
- img Elemente.
- image Elemente innerhalb eines SVG.
- Das Posterbild oder das erste Bild eines video Elements.
- Elemente mit einem Hintergrundbild, das über die CSS Funktion url() geladen wird.
- Blockelemente, die Text oder andere Textelemente enthalten.
In der Praxis ist das LCP Element auf dem Smartphone oft ein Bild. Bei manchen Blog Vorlagen ist es dagegen der Titelblock. Raten Sie deshalb nicht, welcher Fall bei Ihnen zutrifft, sondern messen Sie.
Außerdem kann sich der Kandidat während des Ladens ändern. Zunächst zählt vielleicht ein Textblock, dann übernimmt ein großes Bild, sobald es gerendert ist. Der Browser beobachtet den größten Kandidaten, bis der Nutzer mit der Seite interagiert.
Wie finden Sie das LCP Element Ihrer Seite?
Bevor Sie etwas beheben, müssen Sie wissen, welches Element das LCP Element ist. Das falsche Element zu optimieren, ist daher der häufigste Zeitfresser, den wir sehen. Zum Glück finden Sie es aber schnell.
- Öffnen Sie die Seite in Chrome und drücken Sie F12, um die DevTools zu starten.
- Zunächst zeichnen Sie im Performance Tab einen Seitenaufruf auf und laden Sie neu.
- Klicken Sie auf die LCP Markierung in der Zeitleiste, dann sehen Sie das zugehörige DOM Element.
- Alternativ öffnen Sie das PageSpeed Insights Ergebnis und suchen den Eintrag zum LCP Element.
- Lighthouse zeigt dieselbe Information im Bereich Diagnose.
Testen Sie Mobilgerät und Desktop getrennt, denn bei responsiven Designs kann jedes Gerät ein anderes LCP Element haben. Zum Beispiel zeigt die Desktop Version ein großes Bild, während die mobile Version eine Überschrift zeigt.
Eine ausführliche Anleitung zum Werkzeug finden Sie in unserem Lighthouse Leitfaden.
Was ist der Unterschied zwischen Labordaten und Felddaten?
LCP sehen Sie in zwei Arten von Daten. Labordaten, etwa aus Lighthouse, stammen aus einem einzelnen Ladevorgang in einer kontrollierten Umgebung. Felddaten, etwa aus dem Chrome UX Report, stammen von echten Besuchern.
Beide widersprechen sich oft. Zum Beispiel kann eine Seite mit 1,8 Sekunden im Labor im Feld 3,2 Sekunden zeigen. Der Grund ist einfach, denn echte Nutzer haben andere Geräte, Netze und Standorte.
Deshalb sollten Sie Entscheidungen auf Felddaten stützen. Labordaten nutzen Sie dagegen zur Fehlersuche.
| Merkmal | Labordaten | Felddaten |
|---|---|---|
| Quelle | Lighthouse, Laborbereich von PageSpeed | Chrome UX Report (CrUX) |
| Beste Nutzung | Problem nachstellen und beheben | Echte Ergebnisse und Googles Bewertung sehen |
| Schwankung | Gering, kontrollierte Umgebung | Hoch, echte Vielfalt der Nutzer |
| Aktualisierung | Sofort | Meist nach einigen Wochen gesammelter Daten |
Nach einer Korrektur ändern sich Felddaten nicht sofort. Weil sie sich über Zeit aufbauen, dauert es, bis die Verbesserung sichtbar wird.
Aus welchen vier Teilphasen besteht LCP?
LCP ist also kein einzelner Zeitblock. Der web.dev Leitfaden zur LCP Optimierung teilt ihn in vier Teilphasen. Daher macht diese Aufteilung aus Raten eine Diagnose.
| Teilphase | Bedeutung | Idealer Anteil |
|---|---|---|
| Time to First Byte (TTFB) | Zeit, bis der Server zu antworten beginnt | Etwa 40 Prozent |
| Verzögerung beim Laden der Ressource | Zeit, bis der Download der LCP Ressource startet | Unter 10 Prozent |
| Dauer des Ladens der Ressource | Zeit, die der Download der LCP Ressource braucht | Etwa 40 Prozent |
| Verzögerung beim Rendern des Elements | Zeit vom Ende des Downloads bis zur Darstellung | Unter 10 Prozent |
Diese Prozentwerte zeigen die ideale Verteilung. Liegt eine Teilphase bei Ihnen deutlich darüber, sitzt dort folglich das Problem.
Zum Beispiel: Beträgt die Verzögerung beim Laden 35 Prozent, entdeckt der Browser das Bild zu spät. Dann hilft es nicht, die Datei zu verkleinern. Stattdessen muss das Bild früher auffindbar sein.
Genau so beginnen wir unsere Analysen: Zunächst messen wir die Teilphasen, danach gehen wir die größte Abweichung an.
Was sind die häufigsten Ursachen für einen schlechten LCP?
Hinter einem langsamen LCP stecken meist ein paar bekannte Ursachen. Der web.dev Leitfaden zu LCP hebt nicht optimierte Bilder, spät geladene Ressourcen, Verzögerungen durch Schriften, eine hohe TTFB und blockierende Ressourcen hervor.
In der Praxis sehen wir am häufigsten dieses Muster:
- Das Hauptbild ist riesig und liegt in einem alten Format vor, etwa als unkomprimiertes JPEG oder PNG.
- Das LCP Bild wurde versehentlich per Lazy Loading geladen.
- Ein Skript fügt das Bild ein, deshalb findet der Browser es spät.
- Der Server antwortet langsam und die Seiten sind nicht gecacht.
- Große CSS oder JS Dateien im oberen Bereich blockieren das Rendern.
- Die Überschrift bleibt unsichtbar, bis eine Webschrift geladen ist.
Allerdings treten selten alle Ursachen gleichzeitig auf. Installieren Sie daher nicht wahllos ein Speed Plugin. Schauen Sie stattdessen zuerst auf die Teilphasen und finden Sie heraus, welche Ursache bei Ihnen überwiegt.
Wie laden Sie das LCP Bild schneller?
Auf den meisten Seiten ist das LCP Element ein Bild. Die Bildoptimierung bringt deshalb den größten Nutzen. Allerdings gibt es zwei getrennte Aufgaben: die Datei zu verkleinern und dafür zu sorgen, dass der Browser sie früher findet.
Für die Dateigröße setzen Sie Folgendes um:
- Nutzen Sie ein modernes Format. WebP oder AVIF erzeugen meist kleinere Dateien als JPEG und PNG.
- Skalieren Sie das Bild auf die angezeigte Größe. Zeigen Sie kein Bild mit 3000 Pixeln in einem Platz von 800 Pixeln.
- Liefern Sie mit srcset und sizes die passende Größe je Gerät.
- Komprimieren Sie und prüfen Sie die Qualität mit dem Auge. Ein nicht sichtbarer Verlust ist kein Problem.
Ausführliche Methoden finden Sie in unserem Leitfaden zur Bildoptimierung für Ladezeit und SEO.
Komprimierung allein genügt allerdings nicht. Entdeckt der Browser das Bild spät, kommt selbst eine kleine Datei spät an.
Wie setzen Sie fetchpriority und Preload für das LCP Bild ein?
Der Browser behandelt nicht alle Bilder gleich. Also müssen Sie ihm sagen, dass das LCP Bild am wichtigsten ist. Dafür helfen konkret zwei Werkzeuge.
Das erste ist das Attribut fetchpriority="high". Der web.dev Leitfaden empfiehlt, es dem LCP Bild zu geben und "high" nicht an viele Elemente zu vergeben. Anders gesagt: Ist alles wichtig, ist nichts wichtig.
Das zweite ist der Preload Hinweis. Kommt das Bild aus einem CSS Hintergrund oder aus einem Skript, findet der Browser es spät. Mit Preload geben Sie ihm dann früh Bescheid.
- Steht das Bild als normales img Element im HTML, reicht meist fetchpriority allein.
- Kommt es aus einem CSS Hintergrund, nutzen Sie Preload oder wechseln besser zu einem img Element.
- Bei responsiven Bildern nutzen Sie Preload mit imagesrcset, damit die passende Größe geladen wird.
Diese zwei kleinen Änderungen verkürzen die Verzögerung beim Laden oft deutlich. Trotzdem gilt: erst messen, dann umsetzen, dann erneut messen.
Warum sollten Sie das LCP Bild nie per Lazy Loading laden?
Lazy Loading ist ideal für Bilder unterhalb des sichtbaren Bereichs. Beim LCP Bild kehrt sich der Effekt allerdings um. Der web.dev Leitfaden sagt es klar: Laden Sie Ihr LCP Bild niemals per Lazy Loading, denn das erzeugt immer eine unnötige Verzögerung.
Das Problem ist folgendes: Der Browser wartet auf die Layoutberechnung, bevor er ein Lazy Bild lädt. Somit kommt Ihr wichtigstes Bild als letztes an.
Häufig liegt die Ursache nämlich in einem Theme oder Plugin, das automatisch jedes Bild mit Lazy Loading versieht. Dann ist das Hauptbild betroffen, ohne dass Sie es merken.
- Entfernen Sie das Lazy Attribut vom ersten sichtbaren Bild.
- Nutzen Sie loading="lazy" nur für Bilder unterhalb des sichtbaren Bereichs.
- Prüfen Sie in den Einstellungen von Theme oder Plugin, ob es eine Ausnahme für das erste Bild gibt.
Mehr dazu lesen Sie in unserer Erklärung, was Lazy Loading für SEO und Ladezeit bedeutet.
Welche Größe und welches Format sollte das Hauptbild haben?
Das Hauptbild ist das Bild, das auf dem ersten Bildschirm am meisten Platz einnimmt. Bei der Vorbereitung treffen Sie daher drei Entscheidungen: Größe, Format und Kompressionsgrad.
Die Regel für die Größe ist zum Beispiel einfach. Erstellen Sie das Bild für die größte Breite, in der es auf der Seite erscheint. Für hochauflösende Bildschirme genügt das Doppelte. Alles darüber bläht somit nur die Datei auf.
- Format: WebP oder AVIF für Fotos, SVG für einfache Grafiken.
- Kompression: Senken Sie die Qualität im Vergleich am Bildschirm und vertrauen Sie keiner Zahl blind.
- Fallback: Bieten Sie in einem picture Element eine JPEG Alternative für ältere Browser an.
- Maße: Geben Sie width und height an, damit sich das Layout nicht verschiebt.
Fragen Sie außerdem, ob das Bild auf dem ersten Bildschirm wirklich nötig ist. Ein dekoratives Hintergrundfoto bremst die Seite zum Beispiel oft, ohne Conversions zu bringen.
Anders gesagt: Die beste Optimierung ist manchmal die Vereinfachung, nicht die Kompression. An dieser Stelle treffen sich Design und Tempo.
Wie beeinflusst die Serverantwortzeit (TTFB) den LCP?
Die TTFB kann etwa 40 Prozent des LCP ausmachen. Sendet der Server das erste Byte spät, baut alles Weitere auf dieser Verzögerung auf. Deshalb retten selbst perfekte Bilder einen langsamen Server nicht.
Mehrere Faktoren beeinflussen die TTFB:
- Langsames oder überlastetes Shared Hosting.
- Dynamische Seiten, die bei jeder Anfrage Datenbankabfragen ausführen und kein Caching nutzen.
- Unnötige Weiterleitungsketten.
- Ein Server weit vom Besucher entfernt und kein CDN.
Zur Lösung nutzen Sie Seiten Caching und Caching auf dem Server. Hintergründe erklärt unser Artikel Caching erklärt. Außerdem zählt auch die Hosting Qualität. Die Kriterien haben wir in unserem Beitrag zur Auswahl des Webhostings gesammelt.
Der web.dev Leitfaden weist außerdem darauf hin, dass Server Side Rendering Ressourcen schon im ersten HTML auffindbar macht. Es kann die TTFB erhöhen, lohnt sich aber für die meisten Seiten.
Hilft ein CDN dabei, den LCP zu verbessern?
In den meisten Fällen ja, denn ein CDN liefert Ihre Dateien von Servern in der Nähe des Besuchers aus. Dadurch sinken also sowohl die TTFB als auch die Ladedauer der Ressource.
Ein CDN löst allerdings nicht jedes Problem. Wird das Bild zum Beispiel spät entdeckt, lädt das CDN nur das spät entdeckte Bild schneller. Darum beheben Sie zuerst die Auffindbarkeit.
- Ein CDN eignet sich ideal für statische Dateien wie Bilder, CSS, JS und Schriften.
- Setzen Sie Cache Header korrekt, sonst schrumpft der Nutzen.
- Bietet Ihr CDN Bildkonvertierung, lassen Sie WebP oder AVIF automatisch erzeugen.
- Sitzen Ihre Besucher in einem Land, fällt der Gewinn kleiner aus.
Sehen Sie ein CDN daher als Ergänzung. Behalten Sie die Reihenfolge bei: zuerst Auffindbarkeit und Render Verzögerung, dann Dateigröße, zuletzt die Infrastruktur.
Wie verzögern blockierendes CSS und JavaScript den LCP?
Selbst wenn das Bild schnell lädt, kann der Browser es nicht immer sofort zeichnen. Die Ursache sind blockierende Ressourcen. Somit vergrößern sie die Teilphase der Render Verzögerung.
CSS blockiert das Rendern standardmäßig. Deshalb zeichnet der Browser nichts, bis ein großes Stylesheet da ist. JavaScript kann zudem das Parsen anhalten.
- Binden Sie kritisches CSS inline ein und halten Sie das übrige CSS klein.
- Entfernen Sie ungenutztes CSS.
- Laden Sie nicht notwendige Skripte mit defer oder async.
- Schieben Sie Drittanbieter Widgets wie Chat, Kommentare und Tracking hinter den ersten Ladevorgang.
Eine weitere Falle sind Seiten, die Inhalte nach dem Laden per JavaScript zeichnen. Dann existiert das LCP Element erst, wenn das Skript läuft. Somit ist HTML vom Server ein Vorteil.
Mehr dazu lesen Sie in unserem Artikel, wie JavaScript die Ladezeit beeinflusst.
Wann schaden Webschriften dem LCP?
Ist das LCP Element ein Textblock, spielt die Schrift direkt mit. Dabei kann der Browser Text verbergen, bis die eigene Schrift geladen ist. Diese Blockierphase verzögert den LCP.
Die Lösungen sind simpel, werden aber oft übersehen:
- Setzen Sie die CSS Eigenschaft font display auf swap, damit der Text zuerst in einer Ersatzschrift erscheint.
- Laden Sie nur die Schnitte, die Sie wirklich brauchen. Zwei Schnitte genügen oft statt sechs.
- Liefern Sie die Hauptschrift von Ihrem eigenen Server aus, um die Verbindung zu Dritten zu sparen.
- Laden Sie die kritische Schriftdatei per Preload vor.
- Entfernen Sie Sprachteilmengen, die Sie nicht brauchen.
Es gibt allerdings ein Gleichgewicht. Ein Größenunterschied zwischen Ersatzschrift und echter Schrift kann Layoutverschiebungen (CLS) auslösen. CLS ist hier nicht das Thema, doch Sie finden es in unserem Core Web Vitals Artikel erklärt.
Trotzdem empfehlen wir, bei der Schriftwahl beide Metriken zu bedenken.
Warum ist LCP mobil schlechter als auf dem Desktop?
Auf Mobilgeräten liegt der LCP meist höher. Dafür gibt es konkret ein paar klare Gründe. Erstens sind die Prozessoren schwächer, daher dauern JavaScript und Rendering länger. Zweitens ist die Latenz im Mobilfunk höher.
Außerdem sehen wir bei responsiven Bildern oft denselben Fehler: Das Mobilgerät erhält eine Datei in Desktop Größe. Somit laden Nutzer unnötig viele Megabyte herunter.
- Liefern Sie kleinen Bildschirmen mit srcset kleine Bilder.
- Laden Sie große Komponenten nicht, die mobil ohnehin ausgeblendet sind.
- Testen Sie das LCP Element der mobilen Startseite getrennt.
- Probieren Sie eine Simulation mit langsamem Netz, etwa das mobile Profil von Lighthouse.
Google bewertet mobile und Desktop Daten getrennt, deshalb sollten Sie beide Berichte nicht vermischen. Kurz gesagt: Verbessern Sie zuerst mobil. Der Desktop zieht meist mit.
In welcher Reihenfolge optimieren Sie LCP?
Zufällige Optimierung kostet daher nur Zeit. Der web.dev Leitfaden zur LCP Optimierung schlägt eine Reihenfolge vor. Sie stellt die günstigsten und wirksamsten Schritte nach vorn.
- Erstens: Bringen Sie die Verzögerung beim Laden der Ressource nahe null, damit die LCP Ressource sofort entdeckt wird.
- Zweitens: Verringern Sie die Render Verzögerung, indem Sie alles Blockierende entfernen.
- Drittens: Senken Sie die Ladedauer durch Kompression, passende Größe und passendes Format.
- Viertens: Verbessern Sie die TTFB mit Caching, Hosting und CDN.
- Schließlich: Prüfen Sie das Ergebnis mit Felddaten.
Web.dev erinnert außerdem daran, dass die Ladedauer auf den meisten Seiten kein großer Engpass ist. Ihr erster Reflex sollte also nicht sein, das Bild noch kleiner zu machen.
Aus diesem Grund prüfen wir zuerst die Verzögerungen. Dann gehen wir zur Dateigröße über. Schließlich kümmern wir uns um den Server.
In der Praxis ändern Sie jeweils eine Sache und messen nach jedem Schritt erneut. Sonst wissen Sie nicht, welche Änderung gewirkt hat.
Wie verbessern Sie LCP bei WordPress und Onlineshops?
Bei fertigen Systemen folgen LCP Probleme nämlich festen Mustern. Ob WordPress, Shopify oder ein individueller Shop: Wir sehen ähnliche Fehler.
| Problem | Typisches System | Richtung der Lösung |
|---|---|---|
| Hauptslider lädt schwere Bilder | WordPress Themes | Ein optimiertes Bild statt Slider |
| Produktbild kommt per Lazy Loading | Shop Vorlagen | Erstes Produktbild ausnehmen |
| Viele CSS und JS Dateien durch Plugins | WordPress | Plugins reduzieren und Unnötiges entfernen |
| Kein Seiten Cache | Alle Systeme | Seiten und Objekt Caching ergänzen |
Auf Produktseiten ist das LCP Element meist das Hauptbild des Produkts. Dagegen wird auf Kategorieseiten das erste Produktbild der ersten Reihe zum Kandidaten. Diese Seiten hängen direkt am Umsatz, daher verdienen sie Vorrang.
Auch die Wahl des Systems beeinflusst das Ergebnis. Denn eine auf Tempo geplante Seite macht weniger Mühe als eine nachträglich geflickte. Deshalb berücksichtigt unser Webdesign die Performance schon in der Designphase.
Welche Seiten sollten Sie beim LCP zuerst angehen?
Sie müssen allerdings nicht alle Seiten gleichzeitig optimieren. Eine Reihenfolge hilft Ihnen, begrenzte Ressourcen am richtigen Ort einzusetzen.
Stellen Sie diese Fragen: Welche Seiten erhalten den meisten organischen Traffic? Welche bekommen Anzeigen Traffic? Welche liegen am nächsten an einer Conversion?
- Zielseiten, auf die Ihre Anzeigen verweisen.
- Startseite und die stärksten Kategorieseiten.
- Produkt oder Leistungsseiten.
- Blogartikel mit viel Traffic.
Diese Reihenfolge ist also ein Ausgangspunkt aus unseren Analysen. Sie kann je nach Branche abweichen und ist keine Garantie.
Zudem verbessern sich Seiten mit gleicher Vorlage gemeinsam. Eine einzige Korrektur an der Vorlage kann den LCP auf Hunderten Seiten senken. Zum Beispiel wirkt das Titelbild der Blog Vorlage auf jeden Artikel.
Wie überwachen und berichten Sie LCP?
Einmal korrigieren genügt allerdings nicht. Denn neue Bilder, neue Plugins und neue Werbeskripte können den Wert wieder verschlechtern. Richten Sie deshalb eine regelmäßige Kontrolle ein.
Diese Quellen stehen Ihnen zur Verfügung:
- Google Search Console: Der Core Web Vitals Bericht zeigt Felddaten nach URL Gruppen.
- PageSpeed Insights: liefert für dieselbe Seite Feld und Labordaten.
- Lighthouse: ideal für Fehlersuche und Diagnose.
- Chrome DevTools: Sie prüfen das LCP Element und seine Teilphasen.
Schauen Sie daher beim Berichten auf Seitengruppen statt auf eine einzelne Zahl. Beobachten Sie zum Beispiel Blogartikel, Produktseiten und Startseite getrennt.
Möchten Sie die Performance Kontrolle in Ihre SEO Strategie einbinden, enthält unsere SEO Beratung auch technische Analysen.
Welche Fehler passieren bei der LCP Optimierung am häufigsten?
Die Fehler, die wir seit Jahren sehen, ändern sich kaum. Deshalb spart Zeit und Budget, wer sie kennt.
- Das falsche Element optimieren: Bilder komprimieren, ohne das LCP Element zu kennen.
- Nur auf den Laborwert schauen, obwohl das Feldergebnis abweicht.
- Lazy Loading auf alle Bilder legen, auch auf das Hauptbild.
- fetchpriority high für jedes Element setzen, sodass die Priorität bedeutungslos wird.
- Den Desktop korrigieren und das Mobilgerät vergessen.
- Ein Speed Plugin installieren und ohne Messung für erledigt halten.
- Nur einmal messen und die natürliche Schwankung ignorieren.
Gemeinsam ist diesen Fehlern die Behandlung ohne Diagnose. Dabei dauert die Messung der vier Teilphasen nur etwa zwanzig Minuten.
Lesen Sie zudem das Ziel richtig. Unter 2,5 Sekunden ist zwar ein guter Grenzwert. Überspringen Sie die Perzentil Logik, täuscht Sie ein Durchschnitt. Die meisten Ihrer Nutzer müssen unter dem Grenzwert liegen.
Am einfachsten beugen Sie also mit einer Checkliste vor. Prüfen Sie vor jeder neuen Seite oder Kampagne das erste Bild auf Größe, Priorität und Ladeart. So fallen Probleme dann auf, bevor sie live gehen.
Wie sieht ein Beispielplan für die LCP Verbesserung aus?
Der folgende Plan ist also keine Beispielrechnung, sondern eine Reihenfolge zum Abhaken. Er beruht auf unserer Erfahrung aus der Praxis als Ausgangspunkt und ist keine Garantie.
- Schlechte LCP Gruppen in der Search Console ermitteln.
- Pro Gruppe eine repräsentative Seite in PageSpeed Insights öffnen.
- LCP Element und die vier Teilphasen notieren.
- Eine Maßnahme passend zur Teilphase mit dem größten Anteil wählen.
- Die Änderung einzeln umsetzen und erneut messen.
- Das Ergebnis bestätigen, sobald die Felddaten aktualisiert sind.
Zum Beispiel: Ist die Verzögerung beim Laden hoch, machen Sie das Bild zuerst im HTML auffindbar und ergänzen fetchpriority. Ist die TTFB hoch, haben Hosting und Caching Vorrang.
Viele Korrekturen sind zudem einfach. Ein Bild komprimieren, ein Lazy Attribut entfernen und Plugins aufräumen erfordert kein tiefes Fachwissen. Rendert Ihre Seite im Browser, hilft ein Hostingwechsel nicht oder bremsen Werbeskripte die Seite, brauchen Sie eine genauere Prüfung. Deshalb führt unser Team solche Analysen zusammen mit SEO und Design durch. Nehmen Sie dazu gern Kontakt mit uns auf.




