Ladezeit verbessern: Wie wird Ihre Website schneller?

Was sind die Core Web Vitals?

Die Core Web Vitals sind drei Messwerte von Google für das Nutzererlebnis: wie schnell der größte Inhalt erscheint (LCP), wie rasch die Seite auf Eingaben reagiert (INP) und wie ruhig das Layout bleibt (CLS). Eine Seite besteht, wenn mindestens 75 % der Aufrufe bei allen drei Werten im guten Bereich liegen.

Werte dazwischen gelten als verbesserungswürdig. INP ist seit 2024 ein fester Bestandteil der Core Web Vitals. Google bestätigt, dass seine Ranking-Systeme die Core Web Vitals verwenden. Gute Werte garantieren aber keine Spitzenposition: Google zeigt den relevantesten Inhalt auch dann, wenn das Nutzererlebnis schwächer ist.

Labor- oder Felddaten: Welche Werte zählen?

Felddaten stammen von echten Besuchern mit Chrome und zeigen, wie schnell Ihre Seite tatsächlich ist; Labordaten entstehen bei einem simulierten Aufruf, etwa mit Lighthouse. Für Prioritäten zählen die Felddaten, zur Fehlersuche die Labordaten.

• Felddaten kommen aus dem Chrome User Experience Report (CrUX). PageSpeed Insights zeigt sie für die vergangenen 28 Tage. Erfasst werden nur Chrome-Nutzer, die der Übermittlung zugestimmt haben, und nur Seiten mit genügend Besuchern – für kleinere Websites gibt es daher unter Umständen keine Felddaten.
• Labordaten misst Lighthouse unter festen Bedingungen, mobil mit einem simulierten Mittelklasse-Gerät und simuliertem Mobilfunknetz. INP lässt sich im Labor nicht messen, weil niemand klickt; als Ersatz dient die Total Blocking Time (TBT).

Auffindig misst selbst nicht im Browser, sondern wertet aus, was sich ohne Rendern feststellen lässt: Server, Dateien, Bilder, HTML. Die Felddaten fragt Auffindig optional über die CrUX-Schnittstelle ab; ohne Zugangsschlüssel oder bei zu wenig Besuchern fließt dieser Prüfpunkt nicht in die Bewertung ein. Zusätzlich lässt sich im Bericht die Messung mit Google PageSpeed zuschalten.

Was kann der Server beitragen?

Der Server bestimmt, wie schnell das erste Byte ankommt, ob Textdateien komprimiert übertragen werden und wie lange Browser Dateien zwischenspeichern dürfen. Als gut gilt eine Antwortzeit (TTFB) von höchstens 0,8 Sekunden, über 1,8 Sekunden als schlecht.

• Antwortzeit: Die TTFB umfasst Weiterleitungen, Namensauflösung (DNS), Verbindungs- und TLS-Aufbau sowie die Rechenzeit des Servers. Sie ist selbst kein Core Web Vital, aber der erste Teil des LCP. Laut web.dev hilft zuerst passendes Hosting, dann ein CDN, Zwischenspeichern fertiger Seiten (Caching) und das Vermeiden von Weiterleitungen.
• Komprimierung: Browser melden mit Accept-Encoding, welche Verfahren sie kennen; der Server antwortet mit Content-Encoding: br (Brotli) oder gzip. Laut MDN schrumpfen manche Dokumente dadurch um bis zu 70 %. Bilder, Videos und andere bereits komprimierte Dateien profitieren nicht.
• HTTP/2: Das Protokoll überträgt viele Dateien gleichzeitig über eine einzige Verbindung, statt sie nacheinander anzufordern. Ob Ihr Server HTTP/2 nutzt, können Sie beim Hoster erfragen oder selbst prüfen.
• Browser-Caching: Dateien mit Versionsnummer im Namen (z. B. style.3f9a2c.css) dürfen ein Jahr im Browser bleiben. Das HTML selbst sollte der Browser dagegen bei jedem Aufruf beim Server prüfen.
• HTML-Größe: Große HTML-Dateien entstehen etwa durch eingebettete Daten, Bilder als Base64 oder umfangreiches Inline-CSS. Der Googlebot verarbeitet für die Google Suche nur die ersten 2 MB einer HTML-Datei.

# Versionierte Dateien (CSS, JS, Bilder, Schriften)
Cache-Control: public, max-age=31536000, immutable

# HTML-Seiten: vor jeder Verwendung beim Server nachfragen
Cache-Control: no-cache

Welche Header Ihr Server tatsächlich sendet – Komprimierung, Caching, HTTP-Version –, zeigt unser HTTP-Header-Check.

Wie optimiere ich Bilder?

Liefern Sie Bilder in modernen Formaten wie WebP oder AVIF, in der tatsächlich angezeigten Größe und mit width- und height-Angaben aus. Das Hauptbild oben laden Sie sofort und mit hoher Priorität, alle Bilder weiter unten erst bei Bedarf.

• Format: Verlustbehaftete WebP-Bilder sind laut MDN im Schnitt 25–35 % kleiner als vergleichbare JPEGs, AVIF-Bilder rund 50 %. Mit <picture> erhalten ältere Browser ein JPEG als Ersatz.
• Größe: Ein Foto, das mit 800 Pixel Breite angezeigt wird, braucht keine 4 000 Pixel. Mit srcset wählt der Browser die passende Variante für den Bildschirm.
• Breite und Höhe: Mit width und height berechnet der Browser das Seitenverhältnis und reserviert den Platz, bevor das Bild geladen ist. Fehlen sie, springt der Text beim Laden nach unten – das verschlechtert den CLS.
• Lazy Loading: loading="lazy" lädt Bilder erst, wenn sie in die Nähe des sichtbaren Bereichs kommen. Beim Hauptbild verzögert das den LCP; laut web.dev sollten Sie das LCP-Bild nie lazy laden. Geben Sie ihm stattdessen fetchpriority="high", aber nur einem oder zwei Bildern pro Seite.

<img src="team.jpg" loading="lazy" alt="Unser Team in der Apotheke">

<picture>
  <source srcset="team-800.avif 800w, team-1600.avif 1600w"
          sizes="(min-width: 1000px) 800px, 100vw" type="image/avif">
  <img src="team-800.jpg" srcset="team-800.jpg 800w, team-1600.jpg 1600w"
       sizes="(min-width: 1000px) 800px, 100vw"
       width="800" height="533" fetchpriority="high"
       alt="Unser Team in der Apotheke">
</picture>

Bilder weiter unten auf der Seite erhalten dagegen loading="lazy". Die Umwandlung in WebP oder AVIF lässt sich über ein Bild-CDN oder eine Erweiterung Ihres Systems automatisieren.

Was tun gegen blockierende Dateien und Drittanbieter?

Skripte im Head ohne async oder defer und eingebundene Stylesheets halten die erste Darstellung auf, bis sie geladen sind. Laden Sie Skripte mit defer, fassen Sie CSS zusammen und prüfen Sie jedes Drittanbieter-Skript auf seinen Nutzen.

<script src="/js/slider.js"></script>

<script src="/js/slider.js" defer></script>

Skripte mit type="module" werden automatisch verzögert ausgeführt. Bei CSS hilft es, das für den ersten Bildschirm nötige CSS direkt einzubetten und den Rest später zu laden. Jede Datei ist außerdem eine eigene Anfrage – Plugins, Apps und Widgets bringen oft eigene Dateien mit, die sich summieren.

Drittanbieter – Schriften, Karten, Videos, Chat, Statistik – kosten zusätzlich je Host eine eigene Verbindung, und sie erhalten bei jedem Aufruf die IP-Adresse Ihrer Besucher. web.dev empfiehlt:

• Skripte ohne klaren Nutzen entfernen.
• Verbleibende Skripte mit async oder defer laden.
• Eingebettete Inhalte wie Karten oder Videos erst bei Bedarf laden.
• Skripte von langsamen Fremdservern selbst hosten.

Was das für den Datenschutz bedeutet, etwa bei Google Fonts, erklärt der Artikel DSGVO und Impressum.

Warum bremsen Page-Builder und große DOMs?

Je mehr HTML-Elemente eine Seite enthält (DOM-Größe), desto mehr Arbeit hat der Browser beim ersten Darstellen und bei jeder Änderung – das verschlechtert vor allem die Reaktionszeit (INP). Lighthouse warnt laut web.dev ab 800 Knoten und stuft mehr als 1 400 als übermäßig ein.

Ein großes DOM entsteht, wenn Inhalte in viele verschachtelte Container gepackt werden, wie es bei Page-Buildern vorkommen kann, oder wenn lange Listen, Mega-Menüs und versteckte Inhalte vollständig im HTML stehen. Der wichtigste Hebel laut web.dev ist eine flachere Struktur ohne überflüssige Hüll-Elemente.

• Überflüssige Zeilen, Spalten und Container im Page-Builder entfernen.
• Lange Listen auf mehrere Seiten verteilen oder erst bei Bedarf nachladen.
• Inhalte außerhalb des sichtbaren Bereichs mit der CSS-Eigenschaft content-visibility später darstellen lassen.

Wie Auffindig all diese Punkte gewichtet und ab welchen Werten eine Meldung erscheint, steht unten im Abschnitt So prüft Auffindig.