Schnelle Websites, die bei Google ranken: Core Web Vitals 2026

Ich mache das regelmäßig: Abends auf der Couch, Handy in der Hand, und ich google lokale Unternehmen in der Eifel. Nicht weil ich was brauche. Sondern weil ich sehen will, wie deren Websites performen.

Letzte Woche habe ich mir zehn Handwerksbetriebe aus dem Kreis Euskirchen angeschaut. Das Ergebnis war ernüchternd. Sieben Seiten haben länger als vier Sekunden zum Laden gebraucht. Drei hatten Layout-Verschiebungen, die den Content beim Scrollen wild herumspringen ließen. Und bei fünf Seiten hat es über eine Sekunde gedauert, bis ein Klick auf den "Kontakt"-Button irgendeine Reaktion gezeigt hat.

Das sind keine Kleinigkeiten. Das sind Ranking-Killer.

Was sich 2024 geändert hat: INP statt FID

Im März 2024 hat Google eine Änderung an den Core Web Vitals vorgenommen, die vielen entgangen ist. FID (First Input Delay) wurde durch INP (Interaction to Next Paint) ersetzt. Das klingt technisch. Ist es auch. Aber die Auswirkung ist groß.

FID hat nur die Verzögerung der allerersten Interaktion gemessen. Einmal. Danach war die Metrik fertig. INP ist da deutlich strenger: Es misst die Reaktionszeit über den gesamten Besuch hinweg und nimmt den schlechtesten Wert (mit einer statistischen Glättung). Wenn Ihre Seite beim ersten Klick schnell reagiert, aber beim dritten oder vierten hakt, fällt das jetzt auf.

Warum das für Sie relevant ist: Viele Websites, die unter FID grüne Werte hatten, fallen bei INP durch. Vor allem Seiten mit komplexen Formularen, Slider-Elementen oder umfangreichen JavaScript-Frameworks. Die rote Ampel in der Google Search Console kommt dann oft überraschend.

Die drei Core Web Vitals 2026

Google bewertet Ihre Website anhand von drei Metriken. Jede misst einen anderen Aspekt der Nutzererfahrung.

LCP: Largest Contentful Paint

Ziel: unter 2,5 Sekunden

LCP misst, wie lange es dauert, bis der größte sichtbare Inhalt im Viewport geladen ist. Das ist meistens ein Bild, eine Überschrift oder ein Videovorschaubild. Der Nutzer sieht in dieser Zeit quasi eine leere oder halbfertige Seite. Je länger das dauert, desto wahrscheinlicher springt der Besucher ab.

Was LCP nach oben treibt:

• Unkomprimierte Bilder (der häufigste Grund)
• Langsame Server-Antwortzeiten
• Render-blockierendes CSS oder JavaScript
• Fehlende Priorisierung des Hauptinhalts

INP: Interaction to Next Paint

Ziel: unter 200 Millisekunden

INP misst die Reaktionszeit Ihrer Seite auf Nutzerinteraktionen. Jeder Klick, jeder Tap, jede Tastatureingabe. Die Metrik erfasst die gesamte Kette: vom Input-Event über die JavaScript-Verarbeitung bis zur nächsten visuellen Aktualisierung im Browser.

200 Millisekunden sind die Grenze. Das klingt nach viel, ist es aber nicht. Wenn bei einem Klick auf "In den Warenkorb" erst ein Analytics-Script läuft, dann ein Cookie-Check, dann die Animation, sind Sie schnell drüber.

CLS: Cumulative Layout Shift

Ziel: unter 0,1

CLS misst, wie stark sich das Layout während des Ladens verschiebt. Kennen Sie das? Sie wollen auf einen Button klicken, und im letzten Moment rutscht alles nach unten, weil ein Werbebanner oder ein Bild eingeblendet wird. Das ist ein Layout Shift.

Die häufigsten Verursacher:

• Bilder ohne definierte Breite und Höhe
• Werbebanner, die nachträglich geladen werden
• Web Fonts, die den Text beim Laden umformatieren
• Dynamisch eingefügte Inhalte oberhalb des aktuellen Viewports

Die Rendering-Pipeline: Vom Request zum Erlebnis

Um zu verstehen, wo Performance verloren geht, hilft ein Blick auf den Weg, den jeder Seitenaufruf nimmt. Jeder Schritt in dieser Kette kann zum Flaschenhals werden.

DNS Lookup, TLS Handshake, Server Response: Das sind die Netzwerk-Schritte, bevor der Browser überhaupt anfängt zu arbeiten. Dann kommt das Parsen des HTML, das Laden von CSS und JavaScript, der Layout-Aufbau und schließlich die Interaktivität. Jeder dieser Schritte bietet Stellschrauben.

Aus meiner Zeit bei New Relic weiß ich: Die meisten Performance-Probleme sind nicht dort, wo man sie vermutet. Wir haben damals Observability-Tools gebaut, die genau diese Pipeline sichtbar machen. Was mich immer wieder überrascht hat: Entwickler optimierten stundenlang an der falschen Stelle, weil sie nicht gemessen haben. Das gilt für Fortune-500-Unternehmen genauso wie für die Bäckerei-Website aus Schleiden.

Warum das für regionale Unternehmen besonders wichtig ist

Bei einer Google-Suche nach "Heizungsbauer Eifel" oder "Friseur Mechernich" konkurrieren Sie nicht mit Amazon. Sie konkurrieren mit fünf bis fünfzehn anderen lokalen Anbietern. Und bei dieser Handvoll Ergebnisse können die Core Web Vitals den Unterschied machen. (Wenn Sie wissen wollen, was eine performante Website für Ihr Unternehmen im Rheinland konkret bedeutet, schauen Sie sich unsere Seite zu Websites für Unternehmen in Köln an.)

Google hat seit 2021 bestätigt, dass die Core Web Vitals als Ranking-Signal einfließen. Bei zwei inhaltlich gleichwertigen Seiten bevorzugt der Algorithmus die schnellere. In einem lokalen Markt, wo die inhaltlichen Unterschiede oft gering sind, wird Performance zum Tiebreaker.

Dazu kommt das Nutzerverhalten. Eine Studie von Google aus 2023 zeigt: Wenn eine mobile Seite länger als drei Sekunden lädt, springen 53% der Besucher ab. Bei lokalen Suchen ist die Ungeduld noch größer. Jemand, der unterwegs "Pizzeria in der Nähe" sucht, wartet keine fünf Sekunden.

Ich habe das bei einem Kunden aus der Region selbst erlebt. Ein mittelständischer Betrieb, gute Arbeit, guter Ruf, aber die Website lud auf dem Handy über sechs Sekunden. Nach einer gezielten Performance-Verbesserung, Bilder komprimiert, JavaScript aufgeräumt, Server-Standort nach Frankfurt verlegt, lag die Ladezeit unter zwei Sekunden. Innerhalb von acht Wochen stieg die Sichtbarkeit in der Google Search Console um 40%.

Das ist kein Zaubertrick. Das ist Physik. Und Algorithmus.

Performance-Verbesserung in der Praxis

Jetzt wird es konkret. Die folgenden Techniken sind kein theoretisches Lehrbuch. Das sind die Dinge, die wir bei Plexito bei jedem Projekt umsetzen und die in unseren Dienstleistungen Standard sind.

Bilder: Der größte Hebel

Bilder machen auf den meisten Websites 50-70% des übertragenen Datenvolumens aus. Hier liegt der größte Hebel für schnellere Ladezeiten.

• WebP und AVIF statt JPEG und PNG. WebP spart im Schnitt 25-35% gegenüber JPEG bei gleicher Qualität. AVIF geht noch weiter, bis zu 50% kleiner. Beide Formate werden von allen modernen Browsern unterstützt
• Responsive Images mit srcset. Warum soll ein Smartphone ein 2400px breites Bild laden, wenn der Bildschirm nur 390px breit ist? Mit srcset und sizes liefert der Browser genau die passende Größe aus
• Lazy Loading für alles unterhalb des Viewports. Das loading="lazy" Attribut ist mittlerweile nativer HTML-Standard. Bilder, die der Nutzer noch nicht sehen kann, werden erst geladen, wenn er nach unten scrollt. Das Hero-Bild oben bekommt dagegen ein loading="eager" und idealerweise ein fetchpriority="high"
• Feste Dimensionen im HTML. Jedes <img> Tag braucht width und height Attribute. Sonst weiß der Browser nicht, wie viel Platz er reservieren soll, und Sie produzieren Layout Shifts

Code: Weniger ist schneller

JavaScript ist der häufigste Grund für schlechte INP-Werte. Jedes Script, das im Hauptthread läuft, blockiert die Interaktivität.

• Code Splitting. Laden Sie nur den Code, den die aktuelle Seite braucht. Bei Next.js passiert das automatisch pro Route, aber Bibliotheken wie Chart.js oder Moment.js sollten separat geladen werden
• Tree Shaking. Wenn Sie aus einer Bibliothek nur eine Funktion nutzen, sollte auch nur diese Funktion im Bundle landen. Moderne Bundler wie Turbopack machen das automatisch, aber nur bei ES-Modulen
• defer und async für Third-Party-Scripts. Analytics, Chat-Widgets, Tracking-Pixel: All das gehört nicht in den kritischen Rendering-Pfad. defer lädt das Script parallel und führt es erst nach dem HTML-Parsing aus

Ein Punkt, den ich aus meiner Arbeit bei New Relic kenne: Die schlimmsten Performance-Killer sind oft nicht der eigene Code, sondern Third-Party-Scripts. Ein einziges schlecht geladenes Chat-Widget kann Ihre INP-Werte verdoppeln. Messen Sie das. Immer.

Server und Netzwerk: Die unsichtbare Grundlage

Auf der Client-Seite können Sie noch so viel tunen. Wenn der Server langsam antwortet, hilft das alles nichts.

• Edge Hosting in Frankfurt. Für DACH-Kunden ist ein Server in Frankfurt am Main der beste Standort. Die Latenz zu einem Nutzer in der Eifel beträgt dann 5-15ms statt 80-120ms bei einem Server in den USA. Das klingt nach wenig, aber bei mehreren Requests summiert sich das
• CDN für statische Assets. CSS, JavaScript, Bilder, Fonts: All das sollte über ein Content Delivery Network wie Vercel Edge, Cloudflare oder AWS CloudFront ausgeliefert werden. Der Nutzer bekommt die Daten dann vom nächstgelegenen Edge-Standort
• Brotli-Kompression. Brotli komprimiert 15-20% besser als Gzip. Die meisten modernen Server und CDNs unterstützen es. Aktivieren. Sofort
• Cache-Header richtig setzen. Statische Assets (CSS, JS, Bilder) bekommen ein Cache-Control: public, max-age=31536000, immutable. Dadurch lädt der Browser sie beim zweiten Besuch direkt aus dem lokalen Cache. Null Netzwerk-Requests
• HTTP/2 oder HTTP/3. Multiplexing erlaubt dem Browser, viele Dateien gleichzeitig über eine einzige Verbindung zu laden. Das eliminiert das Head-of-Line-Blocking von HTTP/1.1

Performance-Budget: So behalten Sie die Kontrolle

Eine einmalige Performance-Verbesserung reicht nicht. Ohne Disziplin schleicht sich der Verfall ein. Ein neues Tracking-Script hier, ein unoptimiertes Bild da, und nach drei Monaten sind Sie wieder im roten Bereich.

Die Lösung: ein Performance-Budget.

Ein Performance-Budget definiert Grenzwerte, die nicht überschritten werden dürfen. Das Team einigt sich auf konkrete Zahlen und integriert die Prüfung in den Entwicklungsprozess. Bei Plexito sieht das so aus:

| Metrik | Budget | Begründung | | ------------ | ------------------ | -------------------------------- | | LCP | < 1,8s | Google-Grüner Bereich mit Puffer | | INP | < 150ms | Deutlich unter dem 200ms-Limit | | CLS | < 0,05 | Halber Google-Grenzwert | | Total JS | < 200 KB (gzip) | Hält den Hauptthread frei | | Total Images | < 500 KB pro Seite | Schont mobile Datenvolumen |

Wenn ein neues Feature oder eine Änderung das Budget sprengt, wird nicht deployed. Punkt. Das klingt streng, aber es funktioniert. Wir prüfen das bei jedem Build automatisch mit Lighthouse CI.

Der Trick ist, das Budget von Anfang an festzulegen. Nicht nachträglich. Wenn die Website schon langsam ist, ist es viel schwerer, sie wieder schnell zu bekommen, als sie von Beginn an schnell zu halten.

Häufige Fehler, die ich in der Region sehe

Aus der Arbeit mit Unternehmen aus der Eifel und dem Rheinland kenne ich die typischen Muster.

Homepage-Slider mit fünf hochauflösenden Bildern. Jedes Bild 2 MB groß, alle werden beim Seitenaufruf geladen, obwohl der Nutzer nur das erste sieht. Das sind 10 MB für einen einzigen Seitenaufruf. Auf dem Handy mit LTE dauert das ewig.

WordPress mit 30 Plugins. Jedes Plugin bringt eigenes CSS und JavaScript mit. Die meisten davon werden auf der aktuellen Seite gar nicht gebraucht, aber trotzdem geladen. Ich habe Seiten gesehen, die über 3 MB JavaScript ausgeliefert haben. Zum Vergleich: Unsere Seiten bei Plexito liegen bei unter 200 KB. Das ist auch der Grund, warum wir bei jedem Projekt auf moderne Webentwicklung statt Baukastensysteme setzen.

Kein Caching, kein CDN. Der Server steht bei einem günstigen Hosting-Anbieter irgendwo in Europa. Jeder Seitenaufruf wird vom Server frisch gerendert, inklusive Datenbankabfragen. Kein Browser-Caching, kein CDN. Jeder Besucher wartet die volle Ladezeit ab.

Google Fonts falsch eingebunden. Statt die Schriftart lokal zu hosten, wird sie über einen externen Google-Server geladen. Das kostet einen zusätzlichen DNS Lookup, einen TLS Handshake und einen HTTP-Request. Und wenn der Google-Server mal langsam ist, blockiert er das gesamte Rendering.

Was Sie am Montag tun können

Genug Theorie. Hier sind konkrete Schritte, die Sie diese Woche umsetzen können:

1. Messen. Öffnen Sie PageSpeed Insights und geben Sie Ihre URL ein. Schauen Sie sich die drei Core Web Vitals an. Grün, gelb oder rot? Notieren Sie die Werte. Das ist Ihre Baseline

2. Die größten Bilder identifizieren. Im PageSpeed-Report gibt es den Abschnitt "Bilder in zeitgemäßen Formaten bereitstellen". Dort sehen Sie, welche Bilder am meisten Daten verschwenden. Oft reicht es, die drei größten zu komprimieren, um LCP deutlich zu verbessern

3. Third-Party-Scripts prüfen. Öffnen Sie in Chrome die DevTools (F12), gehen Sie auf den Tab "Network" und sortieren Sie nach Größe. Welche externen Scripts werden geladen? Brauchen Sie wirklich alle?

4. Google Search Console checken. Unter "Core Web Vitals" sehen Sie, wie Google Ihre Seiten bewertet. Die Daten dort basieren auf echten Nutzerdaten (CrUX), nicht auf Labormessungen. Das ist die Wahrheit.

5. Hosting-Standort prüfen. Wo steht Ihr Server? Nutzen Sie ein Tool wie DNS Checker oder den Befehl ping in der Kommandozeile. Wenn die Latenz über 50ms liegt, lohnt sich ein Wechsel zu einem Anbieter mit Standort in Frankfurt

Wenn Sie nach der Analyse feststellen, dass Ihre Werte im roten Bereich liegen: Keine Panik. Das geht den meisten so. Und es ist lösbar.

Der Unterschied zwischen messen und raten

Ein Satz, den ich von meiner Zeit bei New Relic mitgenommen habe: "If you can't measure it, you can't improve it." Das gilt für Enterprise-Software genauso wie für die Website Ihres Unternehmens.

Zu viele Agenturen und Webdesigner arbeiten nach Bauchgefühl. "Die Seite fühlt sich schnell an." Das reicht nicht. Google misst in Millisekunden. Und Google entscheidet, ob Sie auf Seite eins landen oder nicht.

Die gute Nachricht: Die Werkzeuge sind kostenlos. PageSpeed Insights, Lighthouse, die Search Console, Chrome DevTools. Sie brauchen keine teure Software. Sie brauchen jemanden, der die Zahlen liest und die richtigen Schlüsse daraus zieht.

Wenn Sie Ihre Core Web Vitals in den grünen Bereich bringen wollen und nicht sicher sind, wo Sie anfangen sollen: Sprechen Sie uns an. Wir schauen uns Ihre Website an und sagen Ihnen ehrlich, wo die größten Hebel liegen. Kein Marketing-Sprech, nur Zahlen und konkrete Maßnahmen.