Was macht eine schnelle Website aus? Core Web Vitals, Hosting und Bilder verständlich erklärt.
Eine schnelle Website fühlt sich an, als wäre sie einfach da. Dahinter stecken messbare Werte, ein passender Server, sorgfältig vorbereitete Bilder und Code, der nur lädt, was er wirklich braucht. Hier erfahren Sie, worauf es ankommt und wie Sie es selbst prüfen.
Von Luca Röhrl, Gründer von Röhrl Media
Inhalt dieses Artikels
Kurz gesagt
Eine Website gilt nach Google als schnell, wenn der größte sichtbare Inhalt innerhalb von 2,5 Sekunden erscheint (LCP), sie innerhalb von 200 Millisekunden auf Eingaben reagiert (INP) und das Layout beim Laden kaum springt (CLS unter 0,1). Erreicht wird das durch schnelles Hosting, optimierte Bilder in modernen Formaten, wenig JavaScript und sauber eingebundene Schriften.
Warum Ladezeit wichtig ist
Ladezeit ist kein technisches Detail, sondern Teil des ersten Eindrucks. Wer Ihre Seite auf dem Handy im Mobilfunknetz öffnet, merkt jede Verzögerung. Springt dazu noch der Text, weil ein Bild nachlädt, tippt man auf den falschen Link. Das kostet Vertrauen und am Ende Anfragen, wie wir in Warum bringt meine Website keine Anfragen? beschreiben.
Google berücksichtigt die Nutzererfahrung über die Core Web Vitals. Gleichzeitig stellt Google klar, dass gute Werte allein kein gutes Ranking garantieren und relevante Inhalte wichtiger sind (Google Search Central). Schnelligkeit ist also Voraussetzung, nicht Ersatz für Inhalt.
Die Core Web Vitals und ihre Grenzwerte
Google misst drei Kennzahlen, die zusammen beschreiben, wie sich eine Seite für Besucher anfühlt. Als gut gilt eine Seite, wenn mindestens 75 Prozent der Seitenaufrufe die Grenzwerte erreichen, getrennt nach Handy und Computer (web.dev).
- LCP
- ≤ 2,5 sLargest Contentful Paint: Bis der größte sichtbare Inhalt erscheint.
- INP
- ≤ 200 msInteraction to Next Paint: Wie schnell die Seite auf Tippen und Klicks reagiert.
- CLS
- ≤ 0,1Cumulative Layout Shift: Wie stark das Layout beim Laden verrutscht.
- Largest Contentful Paint (LCP) Ladegeschwindigkeit
- Die Zeit, bis das größte Bild oder der größte Textblock im sichtbaren Bereich dargestellt ist. Meist ist das das Titelbild oder die Hauptüberschrift (web.dev).
- Interaction to Next Paint (INP) Reaktionszeit
- Misst, wie lange es nach einer Eingabe dauert, bis die Seite sichtbar reagiert. INP hat am 12. März 2024 den früheren Wert First Input Delay abgelöst (web.dev).
- Cumulative Layout Shift (CLS) Stabilität
- Ein Maß dafür, wie stark sich Inhalte unerwartet verschieben, etwa wenn ein Bild ohne reservierten Platz nachlädt (web.dev).
Hosting: das Fundament
Bevor der Browser irgendetwas zeigen kann, muss der Server antworten. Diese Zeit heißt Time to First Byte (TTFB). Google nennt als Orientierung einen Wert von höchstens 0,8 Sekunden (web.dev). Ein langsamer Server verzögert alles, was danach kommt.
- Serverstandort: Für Kunden in Deutschland ist ein Rechenzentrum in Deutschland oder der EU sinnvoll, auch wegen des Datenschutzes.
- Caching: Seiten, die nicht bei jedem Aufruf neu berechnet werden müssen, antworten schneller. Statische Websites sind hier im Vorteil.
- Aktuelle Protokolle: HTTPS mit HTTP/2 oder HTTP/3 und Kompression wie Brotli oder gzip gehören heute zum Standard.
- Ausreichende Leistung: Günstige Pakete teilen sich einen Server mit sehr vielen anderen Seiten. Das kann zu Stoßzeiten bremsen.
Bilder: der größte Hebel
Auf vielen Websites machen Bilder den größten Teil der übertragenen Daten aus. Gleichzeitig ist das Titelbild oft genau das Element, an dem der LCP gemessen wird. Hier liegt deshalb meist das größte Potenzial (web.dev).
| Maßnahme | Was sie bewirkt |
|---|---|
| Moderne Formate | WebP und AVIF sind bei gleicher Qualität meist deutlich kleiner als JPEG oder PNG. |
| Passende Größen | Mit srcset und sizes lädt das Handy ein kleines, der große Bildschirm ein großes Bild. |
| Breite und Höhe angeben | Der Browser reserviert den Platz, nichts springt beim Laden (besserer CLS). |
| Lazy Loading | Bilder weiter unten laden erst, wenn sie gebraucht werden (web.dev). |
| Titelbild priorisieren | Das wichtigste Bild nie verzögert laden, sondern mit hoher Priorität anfordern (web.dev). |
Code, Schriften und externe Dienste
JavaScript sparsam einsetzen
Jedes Skript muss geladen, gelesen und ausgeführt werden. Viel JavaScript verschlechtert vor allem die Reaktionszeit (INP) auf schwächeren Handys. Slider, Animationsbibliotheken und große Pagebuilder sind häufige Ursachen. Fragen Sie sich bei jedem Element: Braucht die Seite das wirklich?
Schriften selbst hosten
Selbst gehostete Schriften im Format WOFF2 sparen Verbindungen zu fremden Servern und sind datenschutzfreundlicher. Mit font-display: swap ist der Text sofort lesbar, auch bevor die Schrift geladen ist.
Externe Dienste prüfen
Chat-Fenster, Karten, eingebettete Videos, Tracking und Cookie-Banner laden oft eigenen Code nach. Binden Sie Karten und Videos erst nach einem Klick ein und prüfen Sie regelmäßig, welche Dienste noch nötig sind.
Wie schnell ist Ihre Website auf dem Handy?Wir messen die wichtigsten Seiten und zeigen, welche Maßnahmen sich lohnen.
Erstgespräch anfragenSo messen Sie selbst
-
PageSpeed Insights öffnen
Geben Sie die Adresse Ihrer wichtigsten Seite bei PageSpeed Insights ein und wählen Sie die Ansicht für Mobilgeräte.
-
Echte Nutzerdaten lesen
Oben stehen, sofern genug Besuche vorhanden sind, Daten echter Chrome-Nutzer aus dem Chrome UX Report. Diese Werte zählen für die Bewertung durch Google.
-
Labordiagnose nutzen
Der untere Teil zeigt eine simulierte Messung mit konkreten Hinweisen, etwa zu großen Bildern oder blockierendem Code.
-
Search Console beobachten
Der Bericht zu den Core Web Vitals in der Google Search Console zeigt, welche Gruppen von Seiten Probleme haben, und bestätigt Verbesserungen über die Zeit.
Checkliste für eine schnelle Website
Was eine schnelle Website ausmacht
- Server mit kurzer Antwortzeit, Standort in der EU, Caching aktiv
- Bilder in WebP oder AVIF, in passenden Größen, mit Breite und Höhe
- Titelbild ohne Lazy Loading und mit hoher Priorität
- Wenig JavaScript, keine schweren Slider im sichtbaren Bereich
- Schriften selbst gehostet, im Format WOFF2
- Karten und Videos erst nach Klick laden
- Core Web Vitals in den echten Nutzerdaten im grünen Bereich
- Regelmäßige Kontrolle nach Änderungen und Updates
Wie stark das gewählte System die Ladezeit beeinflusst, lesen Sie in WordPress oder individuelle Website? Schnelle Technik ist bei uns Teil jeder Website, nicht ein Zusatzpaket. Mehr dazu bei unseren Leistungen.
Häufige Fragen
Ist die Ladezeit ein Rankingfaktor bei Google?
Die Core Web Vitals fließen in die Bewertung der Seitennutzung ein, die Googles Systeme berücksichtigen. Google betont aber, dass relevante, hilfreiche Inhalte wichtiger sind. Eine schnelle Seite allein bringt Sie nicht nach oben, eine langsame kann Besucher und Anfragen kosten.
Warum zeigt PageSpeed Insights bei jedem Test andere Werte?
Der obere Teil zeigt echte Nutzerdaten der letzten 28 Tage, sofern genug vorhanden sind. Der untere Teil ist eine Labormessung unter simulierten Bedingungen, die von Netz und Serverlast abhängt. Für die Bewertung durch Google zählen die echten Nutzerdaten.
Muss ich 100 Punkte bei PageSpeed erreichen?
Nein. Die Punktzahl ist eine Orientierung für die Labormessung. Wichtiger ist, dass die Core Web Vitals in den echten Nutzerdaten im grünen Bereich liegen und sich die Seite auf dem Handy flüssig anfühlt.
Was ist der Unterschied zwischen WebP und AVIF?
Beides sind moderne Bildformate, die bei gleicher Qualität meist deutlich kleinere Dateien als JPEG erzeugen. AVIF komprimiert oft noch stärker, braucht aber länger zum Erzeugen. Aktuelle Browser unterstützen beide Formate.
Hilft ein Caching-Plugin bei WordPress?
Ja, Caching kann die Antwortzeit des Servers deutlich verbessern, weil Seiten nicht bei jedem Aufruf neu zusammengesetzt werden. Es ersetzt aber nicht das Aufräumen: zu große Bilder, viele Erweiterungen und schwere Themes bleiben trotzdem langsam.
Wie schnell ist diese Website?
Diese Website ist statisch gebaut, lädt Schriften selbst gehostet und Bilder in WebP mit passenden Größen. Prüfen Sie es gern selbst mit PageSpeed Insights.
Quellen und weiterführende Links
- Web Vitals web.dev (Google)
- Largest Contentful Paint (LCP) web.dev (Google)
- Interaction to Next Paint (INP) web.dev (Google)
- Cumulative Layout Shift (CLS) web.dev (Google)
- INP wird am 12. März ein Core Web Vital web.dev (Google)
- Time to First Byte (TTFB) web.dev (Google)
- LCP optimieren web.dev (Google)
- Learn Images web.dev (Google)
- Lazy Loading von Bildern auf Browserebene web.dev (Google)
- Ressourcen mit der Fetch Priority API optimieren web.dev (Google)
- Seitennutzung in den Google-Suchergebnissen Google Search Central
- Chrome UX Report (CrUX) Chrome for Developers
- PageSpeed Insights Google
Stand: 10. November 2026. Wir prüfen diesen Artikel regelmäßig und passen ihn an, wenn sich Regeln, Werkzeuge oder Empfehlungen ändern.
