Core Web Vitals verbessern: vier Bremsen finden und lösen

Wenn Sie Ihre Core Web Vitals verbessern wollen, fangen Sie nicht bei irgendeinem Plugin an, sondern bei der Frage, warum die Seite überhaupt so langsam lädt. Vier Ursachen lohnen die erste Prüfung, weil Sie sie ohne Informatikstudium finden und beheben können: zu große Fotos, zu viele fremde Skripte, nachgeladene Schriften und Inhalte, die beim Laden springen.

Wie stark jede dieser Ursachen bei Ihnen bremst, zeigt erst eine Messung Ihrer eigenen Seite. Deshalb steht bei jedem Punkt, woran Sie ihn erkennen und was Sie tun können.

Was sind Core Web Vitals überhaupt?

Core Web Vitals sind drei Messwerte, die beschreiben, wie schnell und stabil sich Ihre Seite für echte Nutzer anfühlt. LCP misst, wann das größte Element sichtbar wird. INP zeigt, wie schnell die Seite auf Klicks und Eingaben reagiert. CLS erfasst, ob beim Laden Dinge herumspringen. Als gut gelten ein LCP bis 2,5 Sekunden, ein INP bis 200 Millisekunden und ein CLS bis 0,1, gemessen am 75. Perzentil der Seitenaufrufe (web.dev, abgerufen am 25.09.2026).

Und das Ranking? Ob schnellere Werte Ihre Position bei Google verändern, kann Ihnen niemand zusagen. Was Google selbst zur Nutzerfreundlichkeit schreibt, steht in der Dokumentation zur Seitenerfahrung (Google Search Central, abgerufen am 25.09.2026). Sicher ist nur: Tempo ersetzt keinen guten Inhalt. Ihre Besucher kennen die Abkürzungen ohnehin nicht, merken aber, ob eine Seite zäh lädt.

Warum machen riesige Fotos die Website langsam?

Weil der Browser jedes Bild vollständig herunterladen muss, bevor er es zeigen kann. Jemand lädt ein Foto direkt aus der Handykamera oder von der Spiegelreflex hoch, 5000 Pixel breit, 8 Megabyte schwer, und baut es als Titelbild ein. Bei mobilem Netz an der Bushaltestelle in Puchheim dauert das eine gefühlte Ewigkeit.

Ein Rechenbeispiel, keine Messung aus einem Kundenprojekt: Angenommen, ein Bäcker aus dem Landkreis stellt ein Brotfoto mit 8 Megabyte als Titelbild ein. Das sind 64 Megabit. Bei angenommenen 10 Megabit pro Sekunde dauert allein die Übertragung rund 6,4 Sekunden. Auf Anzeigegröße gebracht und komprimiert, sagen wir auf 200 Kilobyte, wären es rechnerisch 0,16 Sekunden. Wie klein die Datei bei Ihrem Motiv wirklich wird, sehen Sie erst beim Ausprobieren. Messen Sie vorher und nachher mit demselben Werkzeug.

Die Lösung, kurz:

• Fotos vor dem Hochladen auf die Anzeigegröße bringen. Für ein Titelbild reichen oft 1920 Pixel Breite, für Handys liefern Sie über srcset eine kleinere Variante mit.
• Modernes Format nutzen. Verlustbehaftete WebP-Bilder sind laut Google bei gleicher Bildqualität 25 bis 34 Prozent kleiner als vergleichbare JPEGs (Google for Developers, abgerufen am 25.09.2026).
• Breite und Höhe im Code fest hinterlegen und loading="lazy" nur für Bilder weiter unten setzen, nicht für das Titelbild.

Wie viele Tracking-Skripte sind zu viele?

So viele, wie Sie nicht wirklich brauchen. Über die Jahre sammelt sich einiges an: Google Analytics, dazu der Facebook-Pixel, ein Chat-Widget, ein Bewertungs-Badge, ein Cookie-Banner-Tool, vielleicht noch ein altes Newsletter-Popup. Jedes dieser Skripte lädt Code von einem fremden Server, kann den Aufbau blockieren und kostet Rechenzeit auf dem Handy Ihrer Besucher.

Zählen Sie selbst nach. Öffnen Sie Ihre Seite in Chrome, drücken Sie F12, wechseln Sie in den Tab "Netzwerk" und laden Sie neu. Sortieren Sie nach Domain: Alles, was nicht von Ihrer eigenen Adresse kommt, stammt von einem fremden Dienst. Fragen Sie sich bei jedem Eintrag ehrlich: Brauche ich das wirklich, und wenn ja, muss es sofort beim Seitenaufbau laden oder reicht später?

Warum flackert die Schrift beim Laden?

Weil die eigentliche Schriftart erst nachgeladen wird. Die Seite lädt, kurz sehen Sie Text in einer Standardschrift, dann springt alles um. Das nennt sich FOUT, und es wirkt unruhig. Kommt die Schrift von Google Fonts, also von einem fremden Server, wartet der Browser darauf.

Zwei Dinge helfen. Erstens, die Schriftdateien auf dem eigenen Server ablegen, statt sie bei Google zu holen. Nebeneffekt: Beim Laden der Schrift geht dann keine Anfrage mit der IP-Adresse Ihrer Besucher an Google. Zweitens, im Code font-display: swap setzen, damit sofort lesbarer Text erscheint. Und wenn Sie ehrlich sind: Meistens reichen ein oder zwei Schriftschnitte. Nicht sieben.

Was ist Layout Shift und warum nervt er so?

Layout Shift heißt, dass Inhalte beim Laden verrutschen. Sie wollen auf einen Button tippen, im letzten Moment lädt darüber ein Bild nach, alles rutscht runter, und Sie treffen die Werbung statt den Button. Genau das misst CLS. Gut ist ein Wert bis 0,1.

Typische Auslöser sind Bilder ohne feste Größenangabe, Werbeblöcke, die erst spät Platz einnehmen, und nachgeladene Schriften mit anderer Höhe. Die Lösung ist meist unspektakulär: Man reserviert den Platz von Anfang an, mit Höhe und Breite für jedes Bild und festen Containern für dynamische Inhalte. Nichts Wildes, nur Sorgfalt beim Bauen. Die drei Messwerte einzeln erklärt unser Glossar zu den Core Web Vitals.

Was bringt die Optimierung konkret?

Das hängt vom Ausgangszustand ab, eine seriöse Antwort gibt es erst nach einer Messung. Ist eine Seite schon ordentlich gebaut, holen Sie vielleicht ein paar Zehntelsekunden heraus. Steckt ein 8-Megabyte-Bild wie im Rechenbeispiel drin, ist der Unterschied rechnerisch deutlich größer. Ob danach mehr Anfragen kommen, kann Ihnen niemand vorher zusagen. Das sehen Sie nur, wenn Sie vorher und nachher dieselben Zahlen erheben, zum Beispiel die Anfragen über das Kontaktformular pro Monat.

Website-Pflege automatisieren: wie behalten Sie die Werte im Blick?

Sie können diesen Teil der Website-Pflege automatisieren, indem die Messung regelmäßig von selbst läuft und sich nur meldet, wenn ein Wert über den Grenzwert steigt. Das ersetzt nicht den Blick auf die Ursache, sorgt aber dafür, dass er rechtzeitig passiert.

Die Werte verschlechtern sich selten auf einen Schlag. Meist kommt ein neues Foto dazu, ein Widget, ein Skript für eine Aktion, und niemand merkt es. So gehen Sie vor:

1. Öffnen Sie in der Google Search Console den Bericht zu den drei Messwerten. Er zeigt, welche Seitengruppen die Grenzwerte reißen. Bei wenig Besuchern bleibt er womöglich leer, weil nicht genug Nutzerdaten vorliegen.
2. Suchen Sie drei bis fünf Seiten aus, auf die es ankommt, etwa Startseite, Leistungsseite und Kontakt.
3. Lassen Sie diese Seiten jede Woche über die Schnittstelle von PageSpeed Insights messen. Für häufige automatische Abfragen empfiehlt Google einen eigenen API-Schlüssel (Google for Developers, abgerufen am 25.09.2026). Auf derselben Seite kündigt Google an, die Daten echter Nutzer aus dem Chrome-Nutzerbericht künftig nicht mehr über diese Schnittstelle zu liefern, und empfiehlt dafür die CrUX-API.
4. Legen Sie fest, wann eine Meldung kommt, zum Beispiel wenn LCP über 2,5 Sekunden oder CLS über 0,1 steigt, und an wen sie geht.
5. Lassen Sie Bilder beim Hochladen automatisch verkleinern und in WebP oder AVIF umwandeln. Dann hängt die Ladezeit nicht davon ab, ob jemand im Büro daran denkt.

Angenommen, bei der Schreinerei Muster lädt jemand ein neues Titelbild direkt aus der Kamera hoch. In der nächsten Wochenmessung steigt der LCP der Startseite über den Grenzwert, und eine Meldung geht an den Inhaber, bevor es Besuchern auffällt. Wie wir solche Abläufe aufbauen, steht auf unserer Seite zu KI und Automatisierung für Unternehmen. Wir bauen dieses Angebot gerade erst auf, einen Betrieb, bei dem es bei uns schon dauerhaft läuft, gibt es noch nicht. Jeder Ablauf beginnt als Prototyp zum Festpreis ab 1.500 € mit vier Wochen Test in Ihrem Betrieb, danach folgt eine Monatspauschale, monatlich kündbar.

Häufige Fragen

Wie kann ich meine Core Web Vitals selbst testen?

Kostenlos über Googles PageSpeed Insights. Adresse eingeben, Handy-Ansicht wählen, Werte ablesen. Achten Sie auf die Felddaten oben (echte Nutzer), nicht nur auf den Labortest. Fehlen die Felddaten, bleibt der Labortest als Richtwert.

Reicht ein Caching-Plugin, um die Website schneller zu machen?

Es hilft, löst aber nicht das Kernproblem. Ein Cache liefert die Seite schneller aus, macht aber ein 8-MB-Bild nicht kleiner und entfernt kein überflüssiges Tracking-Skript. Erst die Ursachen beseitigen, dann Cache obendrauf.

Muss ich für schnelle Ladezeiten einen teureren Server mieten?

Nicht unbedingt. Prüfen Sie zuerst, wie lange der Server für die erste Antwort braucht, im Netzwerk-Tab steht das als "Warten auf Serverantwort". Ist dieser Wert klein und die Seite trotzdem langsam, liegt das Problem im Aufbau der Seite. Erst optimieren, dann schauen, ob der Server überhaupt der Flaschenhals ist.

Wir bei bytebrise bauen Websites für kleine Betriebe im Mietmodell bytebrise Sichtbar: 490 € einmalig zum Start, danach 149 € im Monat, Hosting und Pflege inklusive, kündbar zum Ende jedes Kalendermonats ohne Vorlauffrist. Wenn Sie wissen wollen, wo Ihre Seite bremst, schreiben Sie uns über das Kontaktformular.