Website-Ladezeit verbessern: Core Web Vitals verstehen und optimieren

Um die Ladezeit Ihrer Website zu verbessern, messen Sie zuerst mit PageSpeed Insights, wo es klemmt, und setzen dann bei den grössten Bremsen an: zu grosse Bilder, fehlendes Caching, blockierende Schriften und Skripte sowie eine langsame Serverantwort. Google bewertet die Nutzererfahrung mit drei Kennzahlen, den Core Web Vitals. Dieser Artikel erklärt, was sie bedeuten, wie Sie richtig messen und welche Massnahmen am meisten bringen, mit Hinweisen speziell für WordPress.

Die drei Core Web Vitals und ihre Grenzwerte

Die Grenzwerte stammen von Google (web.dev, Stand: Oktober 2026). Eine Seite erfüllt sie, wenn mindestens 75 Prozent der Seitenaufrufe im grünen Bereich liegen, getrennt nach Mobilgeräten und Desktop. INP hat im März 2024 den früheren Wert FID (First Input Delay) abgelöst.

Ergänzend lohnt sich ein Blick auf die Time to First Byte (TTFB), also die Zeit bis zur ersten Antwort des Servers. Google nennt 0,8 Sekunden oder weniger als guten Wert. Die TTFB ist kein Core Web Vital, wirkt sich aber direkt auf den LCP aus: Was der Server spät liefert, kann der Browser nicht früh anzeigen.

Richtig messen: Labor- und Felddaten

• PageSpeed Insights (pagespeed.web.dev) zeigt oben Felddaten echter Chrome-Nutzer der letzten 28 Tage, sofern genügend Daten vorhanden sind, und darunter einen Labortest mit Lighthouse samt konkreten Verbesserungsvorschlägen.
• Der Bericht «Core Web Vitals» in der Google Search Console fasst die Felddaten für Gruppen ähnlicher Seiten zusammen und zeigt, welche URLs schlecht abschneiden. Nach einer Korrektur können Sie dort eine Validierung starten.
• Chrome DevTools mit Lighthouse und dem Performance-Tab eignen sich für Tests, während Sie an der Website arbeiten.

Für die Bewertung durch Google zählen die Felddaten, nicht die Punktzahl im Labortest. Kleinere Websites haben oft zu wenige Besuche für Felddaten; dann ist der Labortest der beste Anhaltspunkt. Testen Sie immer auch die mobile Ansicht, denn sie ist meist langsamer als Desktop.

Tipp: Messen Sie mehrere typische Seiten, nicht nur die Startseite: etwa eine Produkt- oder Angebotsseite, einen Blogartikel und das Kontaktformular. Ändern Sie danach jeweils nur eine Sache und messen Sie erneut.

Bilder: der häufigste Grund für einen schlechten LCP

Bei vielen Seiten ist das LCP-Element ein grosses Bild, zum Beispiel ein Titelbild oder ein Slider. Diese Massnahmen wirken hier am stärksten:

• Bilder in der tatsächlich angezeigten Grösse ausliefern und mit srcset verschiedene Grössen für Smartphone und Desktop anbieten.
• Moderne Formate verwenden: WebP oder AVIF sind bei vergleichbarer Qualität meist deutlich kleiner als JPEG oder PNG.
• Das Hauptbild im sichtbaren Bereich nicht verzögert laden (kein Lazy Loading) und mit fetchpriority="high" bevorzugen; Bilder weiter unten dagegen mit Lazy Loading laden.
• Bei jedem Bild Breite und Höhe angeben, damit der Browser den Platz reserviert. Das verhindert Verschiebungen und verbessert den CLS.
• Auf Slider im Kopfbereich verzichten, wenn ein einzelnes Bild genügt.

Caching und Serverantwort

Jede Seite, die der Server nicht erst zusammenbauen muss, kommt schneller bei den Besuchern an. Drei Ebenen sind wichtig:

• Seiten-Cache: speichert fertige HTML-Seiten. Auf LiteSpeed-Servern übernimmt das LSCache direkt im Webserver.
• Browser-Cache: Mit passenden Cache-Headern lädt der Browser Bilder, CSS und JavaScript beim nächsten Besuch nicht erneut herunter.
• Objekt-Cache, zum Beispiel Redis: beschleunigt dynamische Seiten wie Warenkorb oder Mitgliederbereich, die sich nicht als ganze Seite cachen lassen.

Bleibt die TTFB trotz Cache hoch, liegt es oft am Server: eine veraltete PHP-Version, zu wenig Ressourcen oder ein überlastetes Konto. Dann helfen eine aktuelle PHP-Version oder ein Hosting mit fest zugeteilten Ressourcen.

Schriften und Skripte

Webfonts

• Schriften selbst hosten statt von externen Servern laden. Das spart Verbindungen und ist auch datenschutzfreundlicher.
• Nur die benötigten Schnitte laden, etwa Regular und Bold, im Format WOFF2.
• Mit font-display: swap zeigt der Browser den Text sofort in einer Ersatzschrift an.
• Die wichtigste Schrift mit rel="preload" vorladen.

JavaScript und Drittanbieter

Der INP-Wert leidet vor allem unter viel JavaScript, das den Browser blockiert. Typische Verursacher sind Chat-Widgets, Tracking- und Werbeskripte, Cookie-Banner mit vielen eingebundenen Diensten, Social-Media-Einbettungen und schwere Page-Builder.

• Nicht benötigte Skripte entfernen, statt sie nur zu optimieren.
• Skripte mit defer oder async laden, damit sie den Seitenaufbau nicht blockieren.
• Videos und Karten erst nach einem Klick laden: zuerst ein Vorschaubild, dann die Einbettung.
• CSS und JavaScript verkleinern und zusammenfassen, aber nach jeder Änderung die Website testen.

Layout-Verschiebungen (CLS) vermeiden

Kaum etwas stört mehr als ein Button, der beim Antippen nach unten rutscht, weil weiter oben noch etwas nachgeladen wird. Genau solche Verschiebungen misst der CLS. Die häufigsten Ursachen und was dagegen hilft:

• Bilder, Videos und iframes ohne Grössenangabe: Breite und Höhe oder ein festes Seitenverhältnis (aspect-ratio) angeben.
• Nachgeladene Elemente wie Cookie-Banner, Hinweisleisten oder Werbeflächen: über dem Inhalt einblenden oder den Platz im Voraus reservieren.
• Webfonts, die beim Wechsel von der Ersatzschrift die Textbreite verändern: eine Ersatzschrift mit ähnlichen Proportionen wählen.
• Inhalte, die per JavaScript oberhalb des sichtbaren Bereichs eingefügt werden: nur nach einer Aktion der Besucherinnen und Besucher einfügen.

CDN: wann es sich lohnt

Ein Content Delivery Network (CDN) speichert statische Dateien auf Servern in vielen Ländern und liefert sie vom nächstgelegenen Standort aus. Das bringt am meisten, wenn Ihre Besucherinnen und Besucher über mehrere Kontinente verteilt sind. Richtet sich Ihre Website vor allem an Kundschaft in der Schweiz und Liechtenstein, bringen Caching, optimierte Bilder und eine schnelle Serverantwort meist mehr. Sinnvoll sein kann ein CDN trotzdem, etwa bei vielen grossen Bildern oder Downloads.

WordPress: die wichtigsten Stellschrauben

• Ein Cache-Plugin passend zum Webserver einsetzen. Auf LiteSpeed ist das LiteSpeed Cache; es kann zusätzlich CSS und JavaScript optimieren, Lazy Loading steuern und über den Dienst QUIC.cloud Bilder in WebP oder AVIF umwandeln.
• WordPress unterstützt WebP seit Version 5.8 und AVIF seit Version 6.5. Seit Version 6.3 versieht WordPress das vermutliche LCP-Bild automatisch mit fetchpriority="high".
• Ein schlankes Block-Theme statt eines schweren Page-Builders verwenden.
• Plugins regelmässig prüfen und alles entfernen, was nicht gebraucht wird.
• Die Datenbank aufräumen: alte Revisionen, Spam-Kommentare und abgelaufene Transients, vorher mit Backup.
• Eine aktuelle PHP-Version nutzen; WordPress empfiehlt derzeit PHP 8.3 oder neuer.

Tipp: Weitere Praxis-Tipps finden Sie in unserem Artikel «WordPress schneller machen: 8 Massnahmen, die wirklich wirken».

In dieser Reihenfolge vorgehen

1. Mit PageSpeed Insights und der Search Console den Ist-Zustand für mobile und Desktop-Ansicht festhalten.
2. Das LCP-Element bestimmen (PageSpeed Insights zeigt es an) und gezielt optimieren, meist das Hauptbild.
3. Seiten-Cache aktivieren und die TTFB prüfen.
4. Bilder in WebP oder AVIF umwandeln und mit Breite und Höhe versehen.
5. Schriften selbst hosten und Drittanbieter-Skripte reduzieren.
6. Nach jeder Änderung erneut messen und die Felddaten nach einigen Wochen kontrollieren.

Auf den WordPress-Paketen von HostOn ist LiteSpeed Cache vorkonfiguriert, und die Websites laufen auf LiteSpeed-Servern mit NVMe-Speicher. Seiten-Cache und Serverantwort sind damit abgedeckt; Bilder, Schriften und Skripte bleiben Aufgabe der Website selbst.