Das Wichtigste in Kürze
- Grenzwerte laut web.dev: LCP bis 2,5 s, INP bis 200 ms, CLS bis 0,1 – gemessen am 75. Perzentil.
- Das Hauptbild oben auf der Seite darf nie verzögert (lazy) geladen werden.
- Bilder in passender Größe und modernem Format sparen bei kleinen Seiten oft am meisten.
- Labordaten zeigen Ursachen, Felddaten echter Nutzer gibt es bei kleinen Seiten oft nicht.
Welche Werte zählen
Google bündelt das Ladeerlebnis in den Core Web Vitals. Laut web.dev sind das drei Werte, jeweils gemessen am 75. Perzentil der Seitenaufrufe, getrennt nach Handy und Computer:
| Wert | Was er misst | Gut |
|---|---|---|
| LCP (Largest Contentful Paint) | Wann das größte sichtbare Element, oft ein Foto oder die Überschrift, erscheint | höchstens 2,5 Sekunden |
| INP (Interaction to Next Paint) | Wie schnell die Seite auf Tippen und Klicken reagiert | höchstens 200 Millisekunden |
| CLS (Cumulative Layout Shift) | Wie stark Inhalte beim Laden verrutschen | höchstens 0,1 |
Labor oder echte Besucher?
PageSpeed Insights zeigt zwei Arten von Daten. Labordaten entstehen bei einem simulierten Aufruf und eignen sich gut, um Ursachen zu finden. Felddaten stammen von echten Chrome-Nutzern der letzten 28 Tage; für kleine Seiten mit wenig Besuchern gibt es sie oft gar nicht. Ein LCP über 4 Sekunden gilt laut web.dev als schlecht, alles zwischen 2,5 und 4 Sekunden als verbesserungswürdig.
Schritt 1: Bilder verkleinern
Das häufigste Problem auf Handwerker-Seiten ist ein Foto direkt aus der Kamera oder vom Handy: mehrere Megabyte groß, 4.000 Pixel breit, angezeigt in 1.200 Pixeln. Das kostet auf dem Handy unterwegs spürbar Zeit.
- Bilder vor dem Hochladen auf die tatsächlich angezeigte Breite bringen, für das große Titelbild meist 1.600 bis 2.000 Pixel, für Galeriebilder deutlich weniger.
- Moderne Formate wie WebP oder AVIF nutzen; viele Systeme können das automatisch.
- Für Handys kleinere Varianten bereitstellen (srcset), damit das Telefon nicht das Desktop-Bild lädt.
- Breite und Höhe im HTML angeben, damit der Platz reserviert ist und nichts verrutscht – das verbessert den CLS.
Schritt 2: Das Hauptbild zuerst laden
Lazy Loading, also das verzögerte Laden von Bildern, ist für Bilder weiter unten sinnvoll. Für das große Bild ganz oben ist es ein Fehler: web.dev warnt ausdrücklich davor, das LCP-Bild verzögert zu laden. Stattdessen sollte es direkt im HTML stehen und mit fetchpriority=high als wichtig markiert werden – laut web.dev aber nur bei ein oder zwei Bildern. Steckt das Titelbild nur in einer CSS-Datei oder einem Slider-Skript, findet der Browser es spät; ein preload-Hinweis im Kopf der Seite hilft.
Slider mit fünf großen Bildern am Seitenanfang sind ein Klassiker: Sie laden viel, und die meisten Besucher sehen nur das erste Bild. Ein starkes Foto reicht fast immer.
Schritt 3: Skripte ausmisten
Jedes Plugin, jedes Chat-Fenster, jede eingebettete Karte und jedes Tracking-Skript lädt Code, den der Browser verarbeiten muss. Das bremst den Seitenaufbau und die Reaktion auf Eingaben.
- Eine Liste aller eingebundenen Dienste machen und fragen: Nutzen wir das wirklich?
- Google Maps nicht direkt laden, sondern erst nach Klick auf ein Vorschaubild – das hilft auch beim Datenschutz.
- Schriften sparsam einsetzen: zwei Schriftschnitte statt acht.
- Skripte, die nicht für den ersten Bildschirm nötig sind, mit defer oder erst später laden.
Schritt 4: Den Server schneller machen
Bevor der Browser irgendetwas zeigen kann, muss der Server antworten. Laut web.dev entfällt bei einer gut optimierten Seite grob 40 % des LCP auf diese erste Antwortzeit (Time to First Byte) – als Richtwert, nicht als feste Regel. Typische Bremsen bei kleinen Seiten sind günstige Hosting-Tarife, fehlendes Caching und Weiterleitungsketten.
- Seiten-Caching aktivieren, bei WordPress etwa über ein Cache-Plugin oder den Hoster.
- Unnötige Weiterleitungen vermeiden: http nach https nach www sollte ein Schritt sein, nicht drei – mehr dazu im Ratgeber Weiterleitungen richtig einrichten.
- Ein Rechenzentrum in der Nähe Ihrer Kunden oder ein CDN nutzen.
- CMS, Theme und Plugins aktuell halten; neue Versionen sind oft schneller.
Schritt 5: Messen, ändern, wieder messen
Ändern Sie nicht alles auf einmal. Messen Sie zuerst, beheben Sie den größten Posten und messen Sie erneut. Labormessungen schwanken etwas; vergleichen Sie deshalb lieber zwei oder drei Durchläufe als einen einzelnen Wert.
Der Ladezeit-Test fragt dafür Google PageSpeed Insights für Ihre Startseite ab, mobil und am Computer, und zeigt LCP, CLS, Blockierzeit und weitere Werte samt der größten Einsparmöglichkeiten. Mobil zählt in unserer Bewertung deutlich stärker, weil Google die Handy-Version bewertet. Felddaten zeigen wir nur, wenn Google welche hat. Andere Seiten als die Startseite misst der kostenlose Check nicht; Details in der Methodik.
Eine schnelle Seite allein bringt noch keine Anfragen. Was danach zählt, lesen Sie unter mehr Anfragen über die Website. Wenn Sie die technische Optimierung abgeben möchten, hilft die Webagentur Scherzinger unter webagentur-scherzinger.com.
Häufige Fragen
Welcher PageSpeed-Wert ist gut?
PageSpeed Insights wertet 90 bis 100 als gut, 50 bis 89 als verbesserungswürdig und 0 bis 49 als schlecht. Wichtiger sind die einzelnen Werte wie LCP.
Warum fehlen bei mir die Felddaten?
Google veröffentlicht Felddaten aus dem Chrome UX Report nur bei genügend Besuchern. Bei kleinen Seiten fehlen sie deshalb oft; dann bleiben die Labordaten.
Soll ich alle Bilder lazy laden?
Nein. Bilder weiter unten ja, das große Bild im sichtbaren Bereich nie – laut web.dev verzögert das den LCP.
Hilft ein teurerer Hoster?
Nur, wenn die Server-Antwortzeit das Problem ist. Sind Bilder und Skripte schuld, ändert ein neuer Tarif wenig.
Quellen
- web.dev: Web Vitals abgerufen am 17.10.2026
- web.dev: Largest Contentful Paint (LCP) abgerufen am 17.10.2026
- web.dev: LCP optimieren abgerufen am 17.10.2026
- Google: Über PageSpeed Insights abgerufen am 17.10.2026