Ein Wert von 68 im PageSpeed-Test sagt Ihnen nicht, ob Ihre Website langsam ist. Er sagt Ihnen, wie ein simuliertes Mittelklasse-Smartphone an einer künstlich gedrosselten Leitung zurechtgekommen wäre — einmal, gerade eben. Messen Sie zehn Minuten später erneut, steht dort womöglich 81. Geändert hat sich nichts.
Der Score ist deshalb nicht falsch. Er ist nur nicht die Zahl, die Google verwendet, und fast nie die Zahl, an der sich entscheidet, ob ein Besucher bleibt.
Dieser Artikel sortiert das: welche zwei Zahlen PageSpeed Insights zeigt und welche davon zählt, welche drei Werte dahinterstehen — und warum es, wenn WordPress langsam ist, in den allermeisten Fällen nicht an „zu vielen Plugins“ liegt, sondern an einem einzigen Element auf der Seite.
Zwei Zahlen, die sich regelmäßig widersprechen
Wer eine Adresse bei PageSpeed Insights eingibt, bekommt zwei Blöcke untereinander. Sie sehen ähnlich aus und bedeuten etwas völlig Verschiedenes.
Oben stehen die Felddaten: gemessen an echten Besuchern, die Ihre Seite mit Chrome aufgerufen haben, gesammelt über die letzten 28 Tage. Unten stehen die Labordaten — eine Simulation, die Google in diesem Moment auf einem eigenen Server ausführt. Aus ihr stammt der farbige Score, den alle meinen, wenn sie „mein PageSpeed“ sagen.
| Felddaten (CrUX) | Labordaten (Lighthouse) | |
|---|---|---|
| Quelle | Echte Besucher Ihrer Seite | Eine Simulation bei Google |
| Zeitraum | Die letzten 28 Tage | Der Moment der Messung |
| Immer vorhanden | Nein — erst ab genügend Besuchern | Ja |
| Fließt ins Ranking ein | Ja, als Core Web Vitals | Nein |
| Taugt dafür | Festzustellen, ob ein Problem besteht | Herauszufinden, woran es liegt |
Die Labordaten sind, in Googles eigener Beschreibung, „based on a simulated load of a page on a single device and fixed set of network conditions“ — ein Gerät, eine festgelegte Leitung, ein Durchlauf (PageSpeed Insights-Dokumentation). Deshalb schwankt der Score zwischen zwei Messungen, ohne dass sich an der Website etwas geändert hätte. Wer diesen Wert als Erfolgskontrolle nimmt, misst zu einem guten Teil Rauschen.
Unangenehm daran ist der häufigste Fall: Bei einer neuen oder kleinen Website bleibt der obere Block leer, weil zu wenige Besucher zusammenkommen. Bei unserem eigenen Blog war das in den ersten Wochen so. Dann gibt es genau eine Zahl zu sehen — und es ist die, die nicht zählt.
Das ist kein Grund, gar nicht zu messen. Es ist ein Grund, die Labordaten als das zu nehmen, wofür sie taugen: als Diagnosewerkzeug, das Ihnen sagt, welches Element auf der Seite das Problem ist. Nicht als Note.
Die drei Werte, auf die es ankommt
Hinter den Felddaten stecken drei Messwerte, die Google als Core Web Vitals zusammenfasst. Jeder beantwortet eine Frage, die ein Besucher auch ohne Fachbegriff stellen würde.
Wichtig vorweg: Gemessen wird am 75. Perzentil — der Wert gilt als erreicht, wenn drei von vier Seitenaufrufen darunter liegen, getrennt für Mobil und Desktop. Ein guter Durchschnitt hilft also nicht, wenn jeder vierte Besucher deutlich länger wartet. Und bestanden ist nur, wer alle drei Werte schafft.
LCP — wann sieht der Besucher etwas Brauchbares?
Largest Contentful Paint misst, wann das größte sichtbare Element fertig geladen ist: meist das Bild im Kopfbereich oder die große Überschrift. Gut sind 2,5 Sekunden oder weniger.
Das ist der Wert, der auf WordPress-Seiten am häufigsten reißt — und zugleich der, bei dem sich mit einem einzigen Handgriff am meisten bewegen lässt. Warum, steht weiter unten.
INP — wie schnell reagiert die Seite auf einen Klick?
Interaction to Next Paint misst die Verzögerung zwischen einer Eingabe und der sichtbaren Reaktion: Menü antippen, Akkordeon aufklappen, Formularfeld anwählen. Gut sind 200 Millisekunden oder weniger. INP hat 2024 den früheren Wert FID abgelöst; ältere Anleitungen im Netz messen noch die falsche Größe.
Schlechte Werte kommen fast immer von JavaScript, das beim ersten Kontakt noch arbeitet — Slider, Chat-Fenster, Buchungs-Widgets, Tracking, das nicht nur zählt, sondern auch rechnet.
CLS — springt das Layout?
Cumulative Layout Shift misst, wie stark sich Inhalte während des Ladens verschieben. Gemeint ist der Moment, in dem Sie auf einen Link zielen und im letzten Augenblick ein Bild darüber aufklappt. Gut sind 0,1 oder weniger.
Die Ursachen sind banal und deshalb gut zu beheben: Bilder ohne Angabe von Höhe und Breite, eingebettete Karten und Videos ohne reservierten Platz, Schriften, die nach dem Laden eine andere Zeilenhöhe mitbringen, und Cookie-Banner, die den Inhalt nach unten schieben, statt sich darüberzulegen.
Die genauen Schwellen stehen in der Core-Web-Vitals-Dokumentation von Google.
Wenn WordPress langsam ist, liegt es meist an einem einzigen Element
„Zu viele Plugins“ ist die Standarddiagnose, und sie ist selten die richtige. Plugins kosten Serverzeit und JavaScript — das trifft TTFB und INP. Der Wert, der auf WordPress-Seiten tatsächlich reißt, ist LCP. Und LCP hängt an genau einem Element: dem größten sichtbaren Ding im ersten Bildschirm.
Google zerlegt diesen Wert in vier Abschnitte, die lückenlos aufeinander folgen:
- TTFB — bis das erste Byte der Seite ankommt.
- Ladeverzögerung — vom ersten Byte bis zu dem Moment, in dem der Browser anfängt, das Bild anzufordern.
- Ladedauer — wie lange das Bild zum Herunterladen braucht.
- Renderverzögerung — vom fertigen Bild bis zum sichtbaren Bild.
Alle optimieren Punkt 3. Sie komprimieren, sie stellen auf WebP um, sie kaufen ein Bildplugin. Das ist nicht falsch, aber es ist häufig der kleinste der vier Posten. Der große ist Punkt 2 — und der hat mit der Dateigröße nichts zu tun.
Warum der Browser Ihr wichtigstes Bild zuletzt findet
Während die Seite noch lädt, überfliegt der Browser den HTML-Code und sucht nach Dateien, die er schon mal anfordern kann. Was er dabei findet, sind <img src="…">-Angaben. Was er nicht findet, ist ein Bild, das nur in einer CSS-Datei steht.
Genau das ist der Fall, sobald das große Kopfbild als Hintergrundbild eingebunden ist — der Normalfall bei Seiten, die mit einem Page Builder gebaut wurden. Der Browser muss dann erst das Stylesheet herunterladen, es verarbeiten und erfährt erst danach, dass da überhaupt ein Bild ist. Googles eigene Anleitung zählt diesen Fall ausdrücklich auf: Der Preload-Scanner kann die Datei nicht entdecken, wenn das LCP-Element ein CSS-Hintergrundbild braucht (web.dev, Optimize LCP).
Was das in Zahlen ausmacht
Auf unserer eigenen Startseite ist das Kopfbild genau so eingebunden. Vor der Korrektur begann der Browser erst nach 1458 Millisekunden, dieses Bild überhaupt anzufordern — fast anderthalb Sekunden, in denen nichts passierte, obwohl die Datei längst hätte unterwegs sein können.
Die Lösung ist eine einzige Zeile im Kopfbereich der Seite, die dem Browser das Bild nennt, bevor er das Stylesheet gelesen hat:
<link rel="preload" as="image" fetchpriority="high" href="…/kopfbild.jpg">Danach waren es 66 Millisekunden. Dieselbe Datei, dieselbe Größe, dieselbe Leitung — nur früher angefordert. Keine Komprimierung der Welt hätte diese 1,4 Sekunden eingespart.
Ein zweiter Fall gehört in dieselbe Kategorie und ist noch häufiger: Das Kopfbild ist ein ganz normales <img>, trägt aber loading="lazy". Dann verzögert der Browser es absichtlich — ausgerechnet das Bild, auf das der LCP-Wert wartet. Viele Performance-Plugins setzen diese Angabe pauschal auf alle Bilder. Google rät davon beim LCP-Bild ausdrücklich ab.
Bevor Sie irgendetwas einschalten
PageSpeed Insights nennt Ihnen das LCP-Element beim Namen. Es steht im Bereich der Diagnose, mit Vorschaubild und der Aufschlüsselung nach den vier Abschnitten oben. Lesen Sie diese Stelle, bevor Sie ein Plugin installieren.
Meistens steht dort ein Bild. Steht dort eine Überschrift, dann liegt es nicht am Bild, sondern an der Schrift oder am Server, und alles, was Sie an Bildern optimieren, ändert nichts.
Bilder: der Zeitpunkt zählt mehr als die Größe
Damit ist die Dateigröße nicht egal — sie ist nur der zweite Schritt, nicht der erste. Drei Dinge lohnen sich, und sie kosten zusammen weniger Zeit, als die Auswahl eines Plugins dauert.
Moderne Formate. WebP ist seit Jahren von allen gängigen Browsern unterstützt und ersetzt JPEG bei vergleichbarer Qualität mit deutlich kleineren Dateien. Das Beitragsbild dieses Artikels liegt als JPEG bei rund 170 Kilobyte — als WebP ausgeliefert sind es 40.
Passende Abmessungen. Ein Bild, das mit 2000 Pixel Breite hochgeladen und in einem 600 Pixel breiten Bereich angezeigt wird, kostet die volle Übertragung und bringt null sichtbaren Gewinn. WordPress legt automatisch kleinere Varianten an — nur greifen Themes und Page Builder nicht immer darauf zu.
Höhe und Breite angeben. Zwei Attribute im HTML, die den Platz reservieren, bevor das Bild da ist. Sie ändern an der Ladezeit nichts und verhindern genau das Springen des Layouts, das den CLS-Wert ruiniert.
Der Punkt, an den beim Thema Tempo kaum jemand denkt
Viele Bildoptimierer arbeiten nicht auf Ihrem Server. Sie laden jedes Bild zu einem externen Dienst hoch, rechnen es dort um und schicken es zurück. Technisch bequem — datenschutzrechtlich eine Auftragsverarbeitung, für die Sie einen Auftragsverarbeitungsvertrag (AVV) brauchen, und zwar bevor das erste Bild das Haus verlässt.
Wir verwenden deshalb Converter for Media Pro: Das Plugin rechnet die Bilder auf dem eigenen Server um, es verlässt nichts die Installation, und die Frage nach einem AVV stellt sich gar nicht erst. Der naheliegende Konkurrent Imagify arbeitet über einen externen Dienst — auf zwei schriftliche Anfragen hat uns der Anbieter keinen AVV zur Verfügung gestellt. Für uns ist das ein Ausschlusskriterium, nicht weil das Plugin schlecht wäre, sondern weil wir Kundenwebsites betreuen und die Lieferkette dort geschlossen sein muss.
Das ist der Grund, warum wir bei der Auswahl von Performance-Plugins nicht nur auf Messwerte schauen. Ein Werkzeug, das eine halbe Sekunde bringt und dafür eine offene Flanke im Datenschutz hinterlässt, ist kein guter Tausch.
Hinweis: Wir sind keine Rechtsanwälte und leisten keine Rechtsberatung. Wir beschreiben, wie wir das technisch lösen. Ob und welche Verträge Sie in Ihrem Fall brauchen, klären Sie mit einem Anwalt oder Ihrem Datenschutzbeauftragten.
Der Fehler, den fast jede Anleitung empfiehlt
Typische Plugin-Anleitung: ein Screenshot der Einstellungsseite, alle Schalter auf An, fertig. Das funktioniert so lange, bis es nicht mehr funktioniert — und der Punkt daran ist, dass Sie es nicht merken.
Denn zwei Arten von Schaltern sehen gleich aus und sind es nicht. Die einen ändern nur, wann etwas geladen wird: Caching, Komprimierung, Bildformate. Geht dabei etwas schief, ist die Seite kaputt, Sie sehen es sofort und machen es rückgängig. Die anderen ändern, was der Browser überhaupt bekommt. Da ist nichts kaputt. Da fehlt nur etwas, an einer Stelle, die Sie heute nicht aufrufen.
Zwei Schalter, die wir bewusst ausgelassen haben
Remove Unused CSS entfernt die Stilangaben, die das Plugin auf dieser Seite für unbenötigt hält. Es kann aber nicht wissen, was nach einem Klick erscheint: das Pop-up, der Header, der beim Scrollen seine Form ändert, das Akkordeon im FAQ-Bereich. Das Ergebnis ist kein Fehler, sondern ein Pop-up ohne Gestaltung auf einer Unterseite, das jemandem in drei Wochen auffällt.
Delay JavaScript execution hält sämtliches JavaScript zurück, bis der Besucher das erste Mal etwas anfasst. Der Laborwert springt daraufhin nach oben, weil in der Simulation nie jemand etwas anfasst. In der Realität warten dann auch das Cookie-Banner, das Buchungsfenster und das Menü auf diese erste Berührung.
Wir haben beides auf unserer eigenen Website nicht eingeschaltet. Nicht aus Vorsicht, sondern weil es nichts zu gewinnen gab, das wir hätten nachweisen können: Die Felddaten waren leer, die Blockierungszeit im Labortest lag bereits bei 0 Millisekunden. Ein Eingriff ohne messbaren Gewinn, aber mit stillem Ausfallrisiko, ist kein Tausch, den man eingeht.
Ausgeschlossen ist das nicht für immer. Die Ausnahmeliste für Remove Unused CSS liegt vorbereitet; eingeschaltet wird sie, wenn genug echte Besucherdaten da sind, um den Unterschied zu sehen.
Wie ein stiller Ausfall aussieht
Ein Beispiel von unserer eigenen Seite, weil es die Sorte Fehler gut zeigt. Nach dem Einschalten der JavaScript-Komprimierung verschwand das Cookie-Banner. Nicht sichtbar kaputt — einfach weg.
Die Ursache: Das Plugin hatte das extern geladene Skript des Consent-Dienstes mitgenommen, lokal zwischengespeichert und dabei den Schlüssel abgeschnitten, der in der Adresse steckte. Zurück blieb eine leere Datei. Die Website lief weiter, der Score war gut, und die Einwilligung wurde nicht mehr eingeholt.
Gefunden haben wir es, weil wir nach jeder Umstellung die Seite einmal selbst aufrufen und in die Entwicklerkonsole schauen. Nicht, weil ein Werkzeug Alarm geschlagen hätte — keines tut das.
Die Reihenfolge, die funktioniert
Einen Schalter umlegen. Alle wichtigen Seitentypen aufrufen: Startseite, eine Unterseite, ein Blogartikel, das Kontaktformular, einmal am Handy. In die Konsole schauen. Erst dann den nächsten.
Das dauert länger als der Screenshot aus der Anleitung. Dafür wissen Sie hinterher, welcher Schalter was gebracht hat — und welcher das Pop-up zerlegt hat.
Wenn das Hosting schon einen Cache mitbringt
Bei Managed-WordPress-Hosting liegt vor Ihrer Website in der Regel bereits ein Cache auf Serverebene. Unsere Installationen laufen bei Raidboxes in Deutschland, dort ist es Varnish. Fertige Seiten werden ausgeliefert, ohne dass WordPress überhaupt startet.
Schalten Sie jetzt zusätzlich den Seiten-Cache eines Performance-Plugins ein, halten zwei Schichten eine eigene Kopie derselben Seite — jede mit eigener Logik, wann sie sie wegwirft. Das Ergebnis kennt jeder, der es einmal hatte: Sie ändern einen Preis, leeren den Plugin-Cache, prüfen die Seite, und der alte Preis steht noch da. Oder er ist für Sie weg und für den Kunden nicht.
Die Aufteilung, die funktioniert: Der Seiten-Cache gehört dem Hoster. Alles andere darf das Plugin machen — CSS und JavaScript zusammenfassen, fehlende Bildmaße ergänzen, Schriften vorladen, Verlinkungen vorbereiten. Das sind genau die Dinge, die ein Server-Cache nicht tut, und sie sind der Grund, warum sich ein Performance-Plugin auch auf gutem Hosting lohnt.
Prüfen können Sie das in zwei Sekunden. Öffnen Sie die Entwicklerwerkzeuge Ihres Browsers, laden Sie die Seite neu und sehen Sie sich beim ersten Eintrag die Antwort-Header an. Steht dort ein Treffer des Server-Caches, hat der Hoster geliefert und das Plugin war an dieser Stelle gar nicht beteiligt.
Und nach einer Änderung: Erst den Server-Cache leeren, dann prüfen. Den Plugin-Cache nur, wenn Sie an den Einstellungen des Plugins selbst etwas gedreht haben. Zwei Schichten in der falschen Reihenfolge zu leeren führt dazu, dass die obere sich den alten Stand der unteren gleich wieder abholt — und Sie dann zum zweiten Mal anfangen.
Was Tempo wirklich kostet — und was nicht
In Artikeln zu diesem Thema steht gern, jede Sekunde Ladezeit koste so und so viel Prozent Umsatz. Solche Zahlen stammen aus Auswertungen großer Online-Händler mit Millionen Besuchern. Auf einen Betrieb mit ein paar Dutzend Aufrufen am Tag lassen sie sich nicht übertragen, und wir geben sie hier deshalb nicht wieder.
Was sich belegen lässt, steht bei Google selbst. Zum Ranking heißt es dort knapp: „Core Web Vitals are used by our ranking systems.“ Im selben Dokument steht aber auch, dass Google immer die relevantesten Inhalte zeigen will — auch dann, wenn die Seitenerfahrung unterdurchschnittlich ist (Google Search Central).
Daraus folgt eine nüchterne Einordnung: Tempo entscheidet dort, wo mehrere Seiten die Frage gleich gut beantworten. Es schlägt keine bessere Antwort. Wer auf Platz 8 steht, weil die Seite zum Thema wenig hergibt, kommt durch eine schnellere Ladezeit nicht auf Platz 3.
Wo Tempo dann doch den Unterschied macht
Zwei Situationen sind real, und beide betreffen das Handy.
Die erste ist der Moment des ersten Kontakts unterwegs — jemand sucht im Auto oder in der Bahn nach einem Anbieter, mit schlechter Verbindung. Dort ist der Unterschied zwischen zwei und sechs Sekunden kein Komfortthema.
Die zweite ist der Vergleich. Wer aus der Suche kommt, hat meist mehrere Treffer in Tabs offen. Die Seite, die als letzte aufbaut, wird als erste geschlossen — nicht nach einer Bewertung, sondern reflexhaft.
Die ehrliche Reihenfolge
Aus unserer Prüfmethodik heraus: Wir schauen uns beim Website-Check den Gesamteindruck an, bevor wir die Technik messen. Der Grund ist genau dieser Punkt. Eine Seite, auf der in fünf Sekunden nicht erkennbar ist, was das Unternehmen anbietet und wie man es erreicht, verliert Anfragen unabhängig davon, ob sie in 1,8 oder 3,4 Sekunden geladen hat.
Ist Ihre Website langsam und unklar, fangen Sie bei der Klarheit an. Ist sie klar und langsam, lohnt sich die halbe Stunde für das LCP-Element. Ist sie klar und schnell, ist Tempo nicht Ihre Baustelle — dann ist es der Inhalt.
Wenn Sie es selbst machen möchten
Vier Schritte, in dieser Reihenfolge. Die ersten beiden bringen den Großteil.
- Messen und das Element finden. Ihre Startseite bei PageSpeed Insights eingeben, auf den Reiter für Mobilgeräte wechseln — dort ist die Lage fast immer schlechter als auf dem Desktop. Nach unten scrollen bis zur Angabe des LCP-Elements und notieren, was dort steht.
- Dieses eine Element in Ordnung bringen. Ist es ein
<img>mitloading="lazy": die Angabe für genau dieses Bild entfernen. Ist es ein CSS-Hintergrundbild: die Preload-Zeile von oben in den Kopfbereich der Seite setzen. Danach neu messen — das ist der Moment, in dem sich am meisten bewegt. - Die Basis nachziehen. Klären, wer bei Ihnen den Seiten-Cache stellt, und nur die andere Hälfte dem Plugin überlassen. Bilder auf WebP umstellen, Abmessungen prüfen, Höhe und Breite ergänzen lassen.
- Wieder messen — und warten. Dieselbe Adresse, zwei- bis dreimal, weil der Laborwert schwankt. Und dann die Felddaten im Blick behalten: Sie brauchen bis zu vier Wochen, bevor sie eine Veränderung zeigen.
Drei Dinge, die Sie sich sparen können: zwei Performance-Plugins gleichzeitig, weil sie sich gegenseitig die Arbeit zerlegen. Alle Schalter auf einmal, aus dem oben genannten Grund. Und das Jagen des Scores von 92 auf 97 — die Besucher merken davon nichts, der Aufwand ist höher als bei allen vorigen Schritten zusammen.
Wenn Sie es abgeben möchten
Zuerst die Abgrenzung, damit keine falsche Erwartung entsteht: Tempo ist bei uns kein eigenes Produkt, das man einmal kauft und abhakt. Eine Website wird nicht einmal schnell. Sie wird wieder langsam, sobald ein Plugin dazukommt, ein neues Bild in voller Größe hochgeladen wird oder ein Update die Einstellungen zurücksetzt.
Einmalige Performance-Optimierung — wenn Sie einen klaren Startpunkt brauchen: Wir messen, bringen das LCP-Element in Ordnung, richten Caching, Bilder und Komprimierung passend zu Ihrem Hosting ein und dokumentieren, was geändert wurde. Ab 490 €, netto zzgl. MwSt., mit festem Angebot vorab. Details unter Leistungen.
Laufende Betreuung — wenn der Zustand halten soll: wöchentliche Updates, danach eine Prüfung, dass nichts verrutscht ist, Monitoring und Backups mit echter Historie. Ab 190 € im Monat, netto zzgl. MwSt. Der Vergleich der drei Pakete steht auf Pakete & Preise.
Und wenn Sie erst einmal nur wissen möchten, wo Sie stehen: Unser kostenloser Website-Check prüft sechs Bereiche, darunter Performance und Mobilansicht, und kommt als PDF innerhalb von 48 Stunden — ohne Telefonat, ohne Verkaufsgespräch, ohne Zugangsdaten. Sie bekommen darin auch die Einordnung, ob Tempo bei Ihnen überhaupt das dringendste Thema ist. Häufig ist es das nicht.
Schreiben Sie uns über das Kontaktformular oder rufen Sie an: +49 157 54071854. Wenn Ihre Website aus unserer Sicht schnell genug ist, sagen wir Ihnen das — und wo das Geld besser aufgehoben wäre.
Häufige Fragen
Mein PageSpeed-Wert ist gut, die Seite fühlt sich trotzdem langsam an. Wie geht das?
Weil der Wert aus einer Simulation stammt, in der niemand klickt, tippt oder scrollt. Gemessen wird der Aufbau, nicht die Bedienung. Was sich langsam anfühlt, ist meist die Reaktion auf Eingaben — also INP. Diesen Wert sehen Sie nur in den Felddaten, und der Laborscore sagt dazu nichts.
Brauche ich ein Caching-Plugin, wenn mein Hoster schon einen Cache hat?
Für den Seiten-Cache nicht — der gehört in dem Fall dem Hoster, und zwei Schichten stören sich gegenseitig. Für alles andere schon: CSS und JavaScript zusammenfassen, Schriften vorladen, fehlende Bildmaße ergänzen. Das macht kein Server-Cache.
Wie viele Plugins sind zu viele?
Die Anzahl sagt wenig. Entscheidend ist, was ein Plugin im Frontend lädt. Zwanzig Erweiterungen, die nur im Backend arbeiten, kosten den Besucher nichts. Drei Slider, ein Chat-Fenster und zwei Tracking-Werkzeuge kosten ihn viel. Fragen Sie nicht nach der Zahl, sondern danach, welches Plugin auf welcher Seite tatsächlich gebraucht wird.
Bringt ein Umzug auf schnelleres Hosting etwas?
Manchmal, aber seltener als erwartet. Das Hosting bestimmt vor allem die Zeit bis zum ersten Byte — einen von vier Abschnitten des LCP-Werts. Liegt Ihr Problem bei der Entdeckung des Bildes, ändert ein schnellerer Server daran nichts. Schauen Sie sich erst die Aufschlüsselung in PageSpeed Insights an, dann wissen Sie, ob sich der Umzug lohnt.
Reicht es nicht, einfach die Bilder zu komprimieren?
Es hilft und ist schnell gemacht. Es behebt aber nur die Ladedauer, nicht die Ladeverzögerung — und die ist auf Seiten mit großem Kopfbild häufig der größere Posten. Eine halb so große Datei, die anderthalb Sekunden zu spät angefordert wird, kommt immer noch zu spät.
Wie lange dauert es, bis sich eine Verbesserung zeigt?
Im Labortest sofort. In den Felddaten nicht: Die laufen über 28 Tage und bilden eine Veränderung erst nach und nach ab. Rechnen Sie mit vier bis sechs Wochen, bevor Sie beurteilen können, ob die Maßnahme bei echten Besuchern angekommen ist. Wer früher Bilanz zieht, zieht sie aus Rauschen.
Quellen
- web.dev: Core Web Vitals — die drei Messwerte und ihre Schwellen: LCP 2,5 Sekunden, INP 200 Millisekunden, CLS 0,1; gemessen am 75. Perzentil, getrennt nach Mobil und Desktop, bestanden nur bei allen drei. INP hat FID 2024 abgelöst.
- web.dev: Optimize Largest Contentful Paint — die vier Abschnitte des LCP-Werts; der Preload-Scanner findet ein CSS-Hintergrundbild nicht und die Datei muss vorgeladen werden; kein
loading="lazy"auf dem LCP-Bild. - PageSpeed Insights-Dokumentation — Felddaten aus dem Chrome User Experience Report über die letzten 28 Tage gegenüber Labordaten aus einer Simulation auf einem Gerät bei festgelegten Netzbedingungen.
- Google Search Central: Page Experience — Core Web Vitals fließen in die Ranking-Systeme ein; es gibt kein einzelnes Signal dafür, und relevante Inhalte werden auch bei unterdurchschnittlicher Seitenerfahrung gezeigt.