Website beschleunigen und Core Web Vitals verbessern

Drei Kennzahlen, mit denen Google misst, wie schnell und stabil eine Website bei echten Chrome-Nutzern läuft: LCP (wie schnell der Hauptinhalt erscheint), INP (wie schnell die Seite auf einen Klick reagiert) und CLS (ob das Layout beim Laden springt). Die Werte sehen Sie in der Search Console und in PageSpeed Insights. Sie gehören zu den Signalen, die Google berücksichtigt, sind aber nicht das einzige.

Den Preis nenne ich nach dem Speed-Audit, als festen Umfang schriftlich, nicht als Stundenzähler. Er hängt von der Plattform, der Zahl der Vorlagen (Startseite, Kategorie, Produkt, Beitrag), der Zahl der Plugins und Skripte ab und davon, ob das Problem im Code oder im Server liegt. Die meisten Korrekturen setze ich innerhalb weniger Wochen um, und die ersten, günstigsten Änderungen gehen meist als Erstes live.

Sie hilft, aber ehrlich gesagt: Geschwindigkeit ist eines von vielen Ranking-Signalen und kein Zauberhebel. Core Web Vitals sind ein bestätigter Teil der Page-Experience-Signale von Google; eine Website, die sie nicht besteht, geht also mit einem Handicap ins Rennen. Die Optimierung beseitigt dieses Handicap und verbessert die Crawling-Effizienz, überholt aber allein keine besseren Inhalte. Deshalb behandle ich sie als eine Disziplin neben dem technischen SEO und sage Ihnen vorab, wenn Ihr größeres Problem woanders liegt.

WordPress selbst ist selten das Problem, meist ist es der angesammelte Ballast obendrauf: Themes aus Page Buildern, ein Dutzend Plugins mit eigenen Skripten, nicht optimierte Bilder und langsame Datenbankabfragen. Die meisten WordPress- und WooCommerce-Websites, die ich sehe, haben ohne Plattformwechsel viel Luft nach oben. Wenn sich Theme oder Plugin-Stack wirklich nicht retten lassen, sage ich es und zeige zum Vergleich, was ein Neubau kosten würde, sodass Sie anhand echter Zahlen entscheiden.

In den meisten Fällen ist die Optimierung der bestehenden Website der richtige erste Schritt: Sie ist günstiger, schneller, und die Messungen zeigen genau, wie weit sie reicht. Ein Neubau lohnt sich nur, wenn das Fundament selbst der Engpass ist, also ein Theme, das gegen jede Optimierung arbeitet, oder ein Stack, dem Sie entwachsen sind. Der Audit beantwortet diese Frage mit Daten, bevor Sie sich für einen Weg entscheiden, und ich habe kein Interesse daran, Sie in ein größeres Projekt zu drängen.

Jeder Auftrag beginnt mit dokumentierten Ausgangsmessungen: Labordaten aus Lighthouse und Felddaten aus dem Chrome UX Report (CrUX) von Google, dazu Tests auf echten Geräten und Verbindungen, nicht nur im Desktop-Simulator. Nach jeder Korrekturrunde messe ich dieselben Unterseiten auf dieselbe Weise und übergebe einen Vorher-nachher-Bericht. Wenn eine Korrektur die Zahlen nicht bewegt, sehen Sie auch das. CrUX-Daten umfassen die letzten 28 Tage, die volle Wirkung zeigt sich dort also verzögert, und bei wenig Traffic gibt es sie eventuell gar nicht; dann vermerke ich das im Bericht.

Das ist ein reales Risiko bei aggressivem Caching und verschobenen Skripten, deshalb arbeite ich vorsichtig: Änderungen prüfe ich zuerst auf einer Kopie der Website, setze sie schrittweise um und kontrolliere Ihre zentralen Abläufe (Formulare, Checkout, Tracking) vor und nach jedem Schritt. Alles ist dokumentiert und umkehrbar. Die gesamte Arbeit gehört Ihnen, und nichts geht in die Produktion, ohne dieselben Tests zu bestehen, die der Browser eines echten Kunden durchlaufen würde.

Nein. Das Ergebnis hängt auch von Dingen außerhalb des Codes ab: Hosting, externe Skripte, die Sie nicht entfernen möchten, und die Geräte Ihrer Kunden. Ich verspreche eine dokumentierte Messung vor den Änderungen, Korrekturen nach ihrer Wirkung auf das Ergebnis und dieselbe Messung danach. Wenn ein Ziel ohne Neubau unrealistisch ist, sage ich es vor dem Angebot.