Core Web Vitals: Ladezeit ist eine Wartungsaufgabe, kein Relaunch-Projekt

Wenn eine Website langsam geworden ist, lautet der übliche Vorschlag: Relaunch. Das ist in den meisten Fällen die teuerste denkbare Antwort auf ein Problem, das schrittweise entstanden ist und sich ebenso schrittweise beheben lässt. Performance verschlechtert sich nicht durch ein Ereignis, sondern durch Ansammlung — und genau deshalb gehört sie in die laufende Wartung.

Was tatsächlich gemessen wird

Die Core Web Vitals bestehen aus drei Kennzahlen, die alle etwas über die wahrgenommene Nutzungsqualität aussagen. Der Largest Contentful Paint misst, wann das größte sichtbare Element geladen ist — vereinfacht: wann die Seite für den Nutzer „da“ ist. Der Interaction to Next Paint misst, wie schnell die Seite auf Eingaben reagiert. Der Cumulative Layout Shift misst, wie stark Inhalte nachträglich verspringen.

Wichtig ist die Unterscheidung zwischen Labor- und Felddaten. Ein Testwerkzeug misst unter definierten Bedingungen. Suchmaschinen bewerten dagegen die Werte echter Nutzer mit ihren realen Geräten und Verbindungen. Beide Messungen weichen regelmäßig voneinander ab — maßgeblich sind die Felddaten.

Die Ursachen, die wir am häufigsten finden

An erster Stelle stehen Bilder. Fotos werden in voller Kameraauflösung hochgeladen und im Browser auf Anzeigegröße verkleinert — der Nutzer lädt trotzdem die vollen Megabyte. Die Umstellung auf WebP mit passenden Größenvarianten und verzögertem Laden bringt hier regelmäßig die größte Verbesserung bei überschaubarem Aufwand.

An zweiter Stelle stehen eingebundene Drittanbieter-Skripte. Jedes Tracking-Werkzeug, jeder Chat-Assistent, jede Kartendarstellung und jedes eingebettete Video kostet Ladezeit und öffnet zusätzlich eine Verbindung zu einem fremden Server. Die unbequeme, aber wirksame Frage lautet: Wird dieses Werkzeug tatsächlich ausgewertet, oder wurde es vor drei Jahren einmal eingebaut?

An dritter Stelle steht der Plugin-Bestand. Zwanzig aktive Erweiterungen bedeuten zwanzig Mal zusätzlichen Code, oft mit eigenen Stilvorlagen und Skripten, die auf jeder Seite geladen werden — auch dort, wo die Funktion gar nicht benötigt wird. Ein Formular-Plugin, dessen Skripte auf allen 200 Unterseiten laden, obwohl nur eine Seite ein Formular enthält, ist ein typischer Befund.

Warum Caching kein Ersatz für Aufräumen ist

Caching-Plugins liefern schnelle Verbesserungen und verdecken damit die eigentliche Ursache. Ein Zwischenspeicher hilft bei wiederkehrenden Aufrufen derselben Seite, wirkt aber nicht beim ersten Aufruf, nicht bei personalisierten Inhalten und nicht im Bestellprozess eines Shops — also genau dort, wo Geschwindigkeit Umsatz beeinflusst. Wir setzen Caching deshalb ein, aber erst nachdem die Grundlast reduziert wurde.

Ein realistischer Arbeitsplan

Wir gehen in vier Schritten vor. Zuerst messen wir Labor- und Felddaten und legen einen Ausgangswert fest. Dann setzen wir die Maßnahmen mit dem besten Verhältnis von Wirkung zu Aufwand um: Bildoptimierung, Entfernen ungenutzter Erweiterungen, Verzögern nicht kritischer Skripte, saubere Serverkonfiguration. Anschließend folgt das Caching, angepasst an die Seitentypen. Zuletzt wird gemessen, verglichen und der Verlauf in die monatliche Berichterstattung aufgenommen.

Entscheidend ist der letzte Punkt. Ohne fortlaufende Messung ist der Zustand nach sechs Monaten wieder der alte, weil in der Zwischenzeit neue Bilder hochgeladen, neue Plugins installiert und neue Einbindungen ergänzt wurden. Deshalb ist die monatliche Messung fester Bestandteil unserer Website-Wartung und Teil des Berichts, den Sie erhalten.

Wann ein Relaunch doch richtig ist

Es gibt Fälle, in denen Optimierung nicht mehr trägt: wenn das eingesetzte Theme auf einem überladenen Baukasten beruht, der für jede Seite ein Vielfaches an Code erzeugt, oder wenn die Anwendung auf einer nicht mehr unterstützten Systemversion läuft. Diese Einschätzung sollte aber am Ende einer Messung stehen und nicht an ihrem Anfang. Eine Übersicht unserer Leistungen finden Sie unter Fachbereiche.