„Bei mir lädt die Seite sofort.“ Diesen Satz höre ich oft, und er stimmt fast immer — am Bürorechner, im eigenen WLAN, auf einer Seite, die der Browser schon zwanzigmal geladen und gespeichert hat. Ihre Kunden erleben etwas anderes: zum ersten Mal, am Handy, im Zug zwischen Graz und Wien, mit halbem Balken. Genau diesen Unterschied messen die Core Web Vitals — auf Deutsch: die drei Kennzahlen, an denen Google beurteilt, wie sich Ihre Seite für einen echten Besucher anfühlt. Sie bewerten nicht, wie flott Ihr Server ist, sondern was auf dem Bildschirm Ihres Kunden passiert. Und sie werden nicht in der Programmierung entschieden, sondern im Entwurf.
Core Web Vitals: drei Kennzahlen, die messen, was Ihr Besucher spürt
Hinter dem sperrigen Namen stecken drei Werte. Jeder steht für einen Moment, in dem ein Besucher aussteigt — und zu jedem gehört eine Frage, die Sie sich leichter merken als das Kürzel.
- LCP (Largest Contentful Paint) — „Wann sehe ich endlich etwas?“ Gemessen wird die Zeit, bis das größte sichtbare Element im ersten Bildschirmausschnitt fertig gezeichnet ist, meist das Bild oder die Überschrift ganz oben. Gut ist unter 2,5 Sekunden, ab 4 Sekunden ist der Wert schlecht.
- INP (Interaction to Next Paint) — „Reagiert die Seite auf meinen Finger?“ Gemessen wird die Zeit zwischen dem Tippen und der sichtbaren Antwort. Gut ist unter 200 Millisekunden, ab 500 Millisekunden ist der Wert schlecht.
- CLS (Cumulative Layout Shift) — „Hält die Seite still?“ Gemessen wird, wie viel Inhalt noch verrutscht, nachdem der Besucher ihn schon sehen konnte. Hier zählen keine Sekunden, sondern eine Punktezahl ohne Einheit: 0 heißt, nichts hat sich bewegt. Gut ist unter 0,1, ab 0,25 ist der Wert schlecht.
Warum Ihr eigener Eindruck nicht zählt
Ein Detail entscheidet über alles Weitere: Bewertet wird nicht der Durchschnitt, sondern das 75. Perzentil echter Besuche über 28 Tage — von hundert Aufrufen müssen 75 im grünen Bereich liegen, getrennt für Handy und Computer. Wenn 26 von 100 Besuchern warten, ist der Wert rot, auch wenn die anderen 74 zufrieden waren.
Ihr Aufruf im Büro ist darin ein einziger, besonders schneller Datenpunkt — und meist nicht einmal das, weil Ihr Browser die Seite längst gespeichert hat. Wer seine Website am eigenen Bildschirm beurteilt, misst das falsche Gerät im falschen Netz. Und falls Sie in älteren Artikeln noch die Kennzahl FID lesen: Die gibt es nicht mehr, INP hat sie 2024 abgelöst.
LCP: Warum das Bild ganz oben über die erste Sekunde entscheidet
Das große Bild ganz oben — im Fachjargon Hero, ich sage Heldenbild — ist auf den meisten Seiten das Element, an dem der LCP hängt. Und fast immer das Problem: Ein Foto kommt direkt aus der Kamera, 4.000 Pixel breit, vier Megabyte schwer, und wird am Handy auf 400 Pixel Breite angezeigt. Der Besucher lädt ein Vielfaches dessen herunter, was er sehen kann — und schaut so lange auf eine leere Fläche.
Darunter liegt eine Zeit, die kein Bildprogramm verkürzt: bis Ihr Server überhaupt antwortet. Der Fachbegriff dafür ist TTFB, „Zeit bis zum ersten Byte“ — genau danach fragen Sie Ihren Hoster. Braucht der Server dafür schon eine Sekunde, sind 2,5 Sekunden nicht mehr zu halten. Die üblichen Ursachen: ein billiger Webspace, auf dem sich Hunderte Websites einen Server teilen; ein überladenes System mit zwei Dutzend Zusatzprogrammen; eine fehlende Zwischenspeicherung — der Server baut jede Seite bei jedem Aufruf neu zusammen, statt die fertige Fassung ein paar Minuten aufzuheben. Das ist keine Design-, sondern eine Betriebsfrage: Server, Hosting und laufender Betrieb gehören ins selbe Projekt und nicht auf eine zweite Rechnung.
Antwortet der Server zügig, entscheiden vier Hebel über Ihren LCP:
- Das Format. AVIF und WebP sind neuere Bildformate, die dasselbe Foto in einem Bruchteil der Dateigröße speichern. Der Browser nimmt, was er kann, und fällt sonst auf das alte Format zurück.
- Die Größe. Von jedem Bild sollten mehrere Fassungen bereitliegen: eine kleine, eine mittlere, eine große. So lädt das Handy die kleine Fassung und der große Monitor die große — statt beide dieselbe.
- Die Reihenfolge. Bilder erst beim Hinscrollen zu laden, ist richtig — aber nur unterhalb des ersten Bildschirms. Beim Heldenbild verzögert das genau die Zeit, die gemessen wird. Es gehört sofort geladen und ausdrücklich als vorrangig markiert.
- Die Schrift. Ist die Überschrift das größte Element, wartet der LCP auf die Schriftdatei. Also: Schriften vom eigenen Server statt von einem fremden Anbieter, im kleinen Format woff2 — und mit der Anweisung, den Text sofort in einer Ersatzschrift zu zeigen.
INP: Warum die Seite auf den Klick nicht reagiert
INP misst, wie lange es dauert, bis der Bildschirm auf eine Berührung sichtbar antwortet. Unter 200 Millisekunden fühlt sich das an wie ein echter Knopf. Ab einer halben Sekunde fragt sich der Besucher, ob er getroffen hat — und tippt ein zweites Mal. Das ist der Moment, in dem Formulare doppelt abgeschickt werden.
Die Ursache ist fast immer JavaScript, also die kleinen Programme, die im Browser mitlaufen. Der Browser hat für Ihre Seite nur eine einzige Kassa: Solange er ein Programm abarbeitet, kann er nichts anderes tun — auch nicht auf Ihren Klick reagieren. In der Schlange stehen selten Ihre eigenen Dinge, sondern die zugekauften.
Der Hebel ist unbequem und einfach zugleich: weniger. Was nicht geladen wird, kann nichts blockieren. Damit wir uns richtig verstehen — ein Chat-Fenster kostet Ladezeit, spürbar. Bringt es Ihnen Anfragen, ist das ein guter Handel; Sie sollen ihn nur bewusst machen. Fünf Kandidaten stehen fast überall in der Schlange:
- Das Cookie-Banner lädt oft als Erstes und hält alles andere auf. Es muss nicht das erste Programm der Seite sein.
- Das Chat-Fenster läuft auf jeder Seite mit, auch dort, wo nie jemand chattet. Es kann nach der ersten Berührung starten statt davor.
- Zwei, drei Werkzeuge zur Besucherauswertung, oft ohne dass jemand die Zahlen noch anschaut. Streichen Sie, was seit einem Jahr niemand geöffnet hat.
- Landkarte und Video bringen jeweils ihr eigenes Programmpaket mit. Beide dürfen erst laden, wenn jemand darauf klickt — bis dahin genügen ein Standbild mit Abspielknopf und ein Bild der Karte.
- Ein Bildkarussell, das sich weiterdreht, während der Besucher tippen will. Am ehrlichsten ist: weglassen.
CLS: Wenn das Layout unter dem Finger wegspringt
Sie kennen die Situation: Sie tippen auf „Speisekarte“ und landen auf „Jetzt buchen“, weil sich im selben Moment noch ein Bild dazwischengeschoben hat. Genau das zählt der CLS. Der Grund ist immer derselbe: Der Browser kennt den Platz nicht, den ein Element brauchen wird, und räumt ihn nachträglich frei. Die Gegenmittel sind erfreulich billig — vier Handgriffe:
- Breite und Höhe in jedes Bild schreiben. Stehen die Maße im Quelltext, reserviert der Browser den Platz, bevor ein Pixel des Bildes eingetroffen ist. Das ist eine Zeile HTML — die häufigste, günstigste Reparatur überhaupt.
- Für Eingebautes von fremden Anbietern einen Platzhalter reservieren: Landkarte, Video und Bewertungssiegel bekommen eine leere Fläche in genau der Größe, die sie später einnehmen.
- Cookie-Banner und Hinweisleisten über die Seite legen, statt sie in den Textfluss zu setzen: Alles, was den Inhalt nach unten schiebt, zählt als Sprung.
- Die Ersatzschrift passend wählen. Ist sie deutlich anders breit als die endgültige Schrift, springt der Text beim Umschalten.
Wie Sie Ihre Seite in zehn Minuten selbst messen
Dafür brauchen Sie kein Werkzeug, das Geld kostet. Rufen Sie PageSpeed Insights auf — ein kostenloses Angebot von Google ohne Anmeldung; suchen Sie nach dem Namen, das erste Ergebnis ist es. Tippen Sie die Internet-Adresse Ihrer Seite ein, stellen Sie oben auf „Mobil“ und drücken Sie auf Analysieren.
Sie bekommen zwei Blöcke, und ihr Unterschied ist der wichtigste Absatz dieses Beitrags. Der erste heißt Felddaten, überschrieben mit „Daten von echten Nutzern“: Messungen tatsächlicher Besucher der letzten 28 Tage. Genau das bewertet Google. Der zweite heißt Labordaten, gemessen mit dem Werkzeug Lighthouse: eine Simulation auf einem nachgestellten Mittelklasse-Handy an gedrosselter Verbindung — kein echter Besucher, dafür sofort verfügbar und mit einer konkreten Liste dessen, was zu tun ist. Der Merksatz: Die Felddaten sagen Ihnen, ob Sie ein Problem haben. Die Labordaten sagen Ihnen, wo es steckt.
Den zweiten Blick werfen Sie in die Google Search Console — ein kostenloses Werkzeug, in dem Sie einmalig nachweisen, dass die Website Ihnen gehört; meist hat Ihre Agentur das längst eingerichtet, lassen Sie sich einen Zugang geben. Dort stehen dieselben Felddaten für alle Seiten auf einmal. So sehen Sie, ob nur ein Seitentyp klemmt — etwa alle Zimmerseiten oder die Buchungsstrecke, also die Seite, mit der Sie Geld verdienen.
Zeigt PageSpeed 95 Punkte und die Kunden warten trotzdem, hat das nüchterne Gründe: Das Labor misst unter Prüfstandsbedingungen, getestet wird meist nur die Startseite. Und fehlen Felddaten ganz, hat Ihre Seite zu wenig Verkehr für eine Messung — kein Fehler, aber der Erfolg lässt sich dann nicht im Feld nachweisen.
Was gute Werte bringen — und was ich Ihnen nicht verspreche
Hier könnte ich eine Studie zitieren, nach der so und so viel Prozent der Besucher nach drei Sekunden abspringen. Solche Zahlen schwanken je nach Branche erheblich und sagen über Ihren Betrieb wenig. Deshalb bekommen Sie von mir keine. Vergleichen Sie stattdessen in Ihrer Besucherstatistik, wie viele Leute sofort wieder weg sind — einmal am Handy, einmal am Computer. Ist die Zahl am Handy deutlich schlechter, haben Sie Ihre Antwort. Und es ist Ihre Zahl, nicht meine.
Google bezieht die Werte in das Ranking ein, aber als einen Faktor unter vielen: Der passendere Inhalt gewinnt auch mit mittelmäßigen Werten, und bei zwei gleichwertigen Seiten gibt die Geschwindigkeit den Ausschlag. Ein Effekt wird dabei oft übersehen: Dieselben Eigenschaften, die eine Seite schnell machen — wenig Ballast, klare Struktur, Inhalt, der auch ohne JavaScript im Quelltext steht —, machen sie auch für KI-Antwortsysteme leicht lesbar. Wer in Ladezeit investiert, zahlt gleichzeitig auf die Sichtbarkeit in KI-Antworten ein.
Warum die Ladezeit im Entwurf entschieden wird — nicht in der Programmierung
Jetzt der Punkt, auf den alles zuläuft. Lesen Sie die Ursachen von oben noch einmal durch: Fast keine davon ist eine Programmierfrage. Es sind Gestaltungsentscheidungen, getroffen lange bevor jemand eine Zeile Code schreibt.
- Ein Video ganz oben statt eines Heldenbildes — eine Entwurfsentscheidung.
- Fünf Schriftschnitte statt zwei — eine Entwurfsentscheidung.
- Ein Bildkarussell, das ohnehin niemand zu Ende anschaut — eine Entwurfsentscheidung.
- Eine Bildergalerie, in der jedes Foto anders hoch ist, statt alle im selben Format — die Wurzel der meisten springenden Seiten.
- Chat-Fenster, Landkarte und Bewertungssiegel auf jeder einzelnen Seite — das steht im Entwurf, nicht im Programmcode.
Reparieren oder neu bauen — woran Sie es selbst erkennen
Wer das erst am Ende „optimieren“ lässt, hat zwei Möglichkeiten: das Design zurückbauen oder mit schlechten Werten leben. Beides ist teuer, beides vermeidbar. Deshalb behandle ich Ladezeit in Webdesign und Entwicklung als Entwurfsmaterial — wie Typografie oder Farbe: Im Entwurf steht von Anfang an, welches Bild das Heldenbild ist, in welchem Format die Fotos einer Galerie liegen, wie viele Schriftschnitte es gibt und was nicht auf die Seite kommt. Eine Fessel ist das nicht: Design mit Charakter und kurze Ladezeiten schließen einander nicht aus, die Grenze ist nur früher bekannt — und dort kostet sie nichts.
Meine Zielmarke, ohne Wunderversprechen: Das Heldenbild ist am Handy im Mobilfunknetz in unter 2,5 Sekunden da, ein Klick antwortet in unter 200 Millisekunden, und nach dem ersten Zeichnen hält das Layout still. „In Millisekunden geladen“ ist es nicht — solche Sätze schreiben nur Leute, die nie gemessen haben.
Steht Ihre Seite schon, ordnen Sie sie nach der Messung in einen von drei Fällen ein:
- Handarbeit an einer gesunden Seite. Die Bilder sind zu groß, die Maßangaben fehlen, zwei Auswertungswerkzeuge laufen mit, die niemand mehr anschaut. Das lässt sich Punkt für Punkt abarbeiten, ohne die Gestaltung anzufassen — der günstigste Fall.
- Umzug oder Ausmisten. Der Server antwortet zu langsam, oder das System startet bei jedem Aufruf zwanzig Zusatzprogramme mit. Dann tauscht man den Server oder mistet aus. Das Aussehen bleibt — der Aufwand ist deutlich größer als im ersten Fall.
- Von vorne. Die Ursachen stecken im Entwurf: Video ganz oben, fünf Schriftschnitte, ein Karussell, ein Dutzend fremder Dienste. Dann heißt Optimieren: das Design zurückbauen. Wer das ablehnt, zahlt für eine Optimierung, die nichts bringt — das teuerste aller Ergebnisse.
Wie ich das auf dieser Website gebaut habe
Damit Sie mir das nicht glauben müssen: Das passiert auf dieser Website. Womit ich arbeite, steht offen auf der Seite Technologien & Partner; wie es an einem echten Kundenprojekt aussieht, zeigt die Case Study zum LeoFlex-System — dort läuft das große Bild ganz oben durch genau diese Kette.
- Jedes Bild wird beim Veröffentlichen automatisch in die sparsamen Formate AVIF und WebP umgerechnet und in drei Breiten abgelegt: 480, 960 und 1.440 Pixel. Breite und Höhe stehen immer im Quelltext, damit der Platz reserviert ist, bevor das Bild eintrifft.
- Das Bild im ersten Bildschirmausschnitt wird ausdrücklich vorrangig geladen. Alles darunter lädt erst beim Heranscrollen.
- Die Schriften für den Text liegen auf meinem Server, nicht bei einem fremden Anbieter — das spart Ladezeit und erspart die Datenschutz-Diskussion über Schriften von Google. Und zwar im kleinsten gängigen Format: Der Umstieg von TTF auf woff2 hat bei der Anzeigeschrift 134 auf 49 Kilobyte gedrückt. Der Text erscheint sofort, notfalls in der Ersatzschrift.
- Das HTML wird von überflüssigen Zeichen befreit und komprimiert übertragen — das spart bei jedem Aufruf Übertragungszeit, besonders im Mobilfunknetz.
- Die Programme, die ganz oben in der Seite geladen werden, halten den Aufbau nicht auf (im Fachjargon: async). Die Auswertungswerkzeuge starten erst nach der Zustimmung des Besuchers: gut für den Datenschutz und nebenbei für den INP.
Sieben Punkte, die Sie ohne mich prüfen können
Zum Schluss die Liste, mit der Sie allein weiterkommen: zehn Minuten, ein Handy. Bleiben drei oder mehr Punkte hängen, ist das kein Feinschliff mehr, sondern einer der drei Fälle von oben. Sind Sie unsicher, schicken Sie mir über das Kontaktformular die Adresse Ihrer Seite und einen Satz dazu, was Sie stört. Sie bekommen die drei Werte, die Ursache in verständlicher Sprache und die Einschätzung: reparieren oder neu bauen. Ist Ihre Seite in Ordnung, sage ich Ihnen auch das.
- Messen. Adresse in PageSpeed Insights eingeben, auf „Mobil“ stellen, zuerst die Felddaten ansehen. Steht einer der drei Werte auf Rot, notieren Sie ihn.
- Bild wiegen. Rechte Maustaste auf das große Bild ganz oben, „Bild speichern unter“, auf den Schreibtisch legen und im Dateimanager die Größe ansehen. Mehr als ein paar hundert Kilobyte sind für ein einzelnes Foto fast immer zu viel.
- Zusehen. Seite am Handy neu laden: Springt etwas? Dann fehlen Maßangaben oder ein Platzhalter.
- Fremde Dienste zählen. Chat, Karte, Auswertung, Bewertungssiegel, Schriften von einem fremden Server. Jeder Einzelne muss sich rechtfertigen.
- Cookie-Banner ansehen. Schiebt es den Inhalt nach unten oder legt es sich darüber? Schieben ist ein Fehler.
- Antippen. Tippen Sie auf das Menü, während die Seite noch lädt. Reagiert es sofort — oder erst am Ende?
- Nicht nur die Startseite prüfen. Die Seite, mit der Sie Geld verdienen — Buchung, Kontakt, Produkt —, gehört genauso durch den Test.