Tempo und Core Web Vitals
Ich behebe die Ursache einer langsamen Website. Nicht das Symptom.
Die meiste Tempo-Arbeit besteht aus einem Caching-Plugin, einem Minifier und einem hoffnungsvollen neuen Test. Das bewegt den Laborwert und lässt das eigentliche Problem, wo es ist. Ich messe, wohin die Zeit wirklich geht, behebe genau das und gebe Ihnen ein Vorher und Nachher, das Sie auf Ihrem eigenen Rechner nachvollziehen können.
01VorführungLive aus Ihrem Browser
Diese Seite, gemessen, während Sie sie lesen.
Wer Tempo-Optimierung verkauft, kann Ihnen einen Screenshot eines guten Durchlaufs zeigen. Das hier sind die Werte, die Ihr eigener Browser beim Laden dieser Seite gemessen hat, verglichen mit den Schwellen, die Google verwendet. Öffnen Sie den Netzwerk-Tab und prüfen Sie sie.
Markup, Styles, Skript und drei Schriften – alles, was nötig ist, um darzustellen, was Sie gerade lesen.
Das mittlere Seitengewicht laut HTTP Archive.
02DiagnoseWohin die Zeit wirklich geht
Langsamkeit ist ein Symptom. Das sind die Ursachen.
Fast jede langsame Website, die mir geschickt wird, ist aus zwei oder drei der folgenden Gründe langsam. Die Diagnose soll herausfinden, welche es sind, denn die Lösung ist für jeden völlig anders – und die falsche Lösung zu kaufen ist der Weg, auf dem man am Ende zweimal für Tempo-Arbeit bezahlt.
Der Server denkt zu lange nach
Eine hohe Time to First Byte bedeutet, dass die Arbeit erledigt wird, bevor ein einziges Byte den Browser erreicht. Bei WordPress sind das meist ungecachte Abfragen in einer Template-Schleife, eine per autoload geladene Optionstabelle, die auf mehrere Megabyte angewachsen ist, oder ein Plugin, das beim Rendern eine externe API aufruft. Keine Front-End-Optimierung ändert daran etwas.
Das größte Element auf dem Bildschirm ist riesig
Ein Hero-Bild, mit 4000 Pixeln Breite exportiert und als PNG ausgeliefert, lässt den Largest Contentful Paint allein scheitern. Die Lösung ist unspektakulär: richtige Abmessungen, moderne Formate, ein srcset, damit Handys nicht die Desktop-Version laden, explizite Breite und Höhe und fetchpriority für das eine Bild, auf das es ankommt.
Skripte blockieren das Rendern
Jedes synchrone Skript im Head ist ein Stoppschild, bevor der Browser zeichnen kann. Tag-Manager, Chat-Widgets, A/B-Test-Werkzeuge und Font-Loader sind die üblichen Verdächtigen, und sie werden oft auf jeder Seite geladen, für eine Funktion, die nur auf einer genutzt wird.
Die Seite springt beim Laden
Cumulative Layout Shift entsteht durch Dinge, die spät ankommen, ohne dass Platz für sie reserviert ist – Bilder ohne Abmessungen, Webfonts, die mit anderer Größe nachladen, Cookie-Banner und Anzeigen, die über bestehende Inhalte geschoben werden. Das ist meist das Günstigste der drei zu beheben und das Ärgerlichste zu erleben.
Interaktionen fühlen sich zäh an
Interaction to Next Paint hat First Input Delay im März 2024 abgelöst und ist eine deutlich strengere Metrik. Sie misst, wie lange eine Interaktion braucht, bis eine sichtbare Reaktion erscheint, über den gesamten Besuch – nicht nur bei der ersten. Websites scheitern daran, weil zu viel JavaScript um den Hauptthread konkurriert.
03AblaufWirklich eine Reihenfolge
Wie die Arbeit abläuft.
- 01
Diagnose, vor jedem Angebot
- Ich analysiere die Website und schicke Ihnen eine schriftliche Aufstellung, wohin die Zeit geht, geordnet danach, was es Sie kostet und wie schwer es zu beheben ist. Dieses Dokument behalten Sie, ob Sie mich beauftragen oder nicht.
- 02
Felddaten als Ausgangswert
- Laborwerte schwanken zwischen den Durchläufen. Ich halte zuerst die Felddaten aus dem Chrome UX Report fest, damit wir am Ende vergleichen, was echte Besucher erlebt haben, und nicht zwei Labordurchläufe an verschiedenen Nachmittagen.
- 03
Ursachen beheben, die größten zuerst
- Die Arbeit passiert auf Staging, eine Änderung nach der anderen, jede einzeln gemessen. Zehn Änderungen auf einmal verraten Ihnen nichts darüber, welche gewirkt hat, und Sie können die schädliche nicht zurücknehmen.
- 04
Prüfen, dann die Methode übergeben
- Sie erhalten das Vorher und Nachher, die Schritte, um beides nachzuvollziehen, und einen Hinweis darauf, was die Arbeit langsam wieder zunichtemachen wird – meist das nächste Plugin, das jemand installiert.
04FragenOft gestellt, klar beantwortet
Was Menschen fragen, bevor sie mich beauftragen.
Behebt ein Caching-Plugin meine Core Web Vitals?
Bestenfalls teilweise. Caching verbessert die Antwortzeit des Servers, was der Time to First Byte hilft. Für einen Largest Contentful Paint, der durch ein zu großes Hero-Bild verursacht wird, bewirkt es sehr wenig, für Layout-Verschiebungen durch Elemente ohne Größenangabe nichts und für eine Interaction to Next Paint durch schweres JavaScript ebenfalls nichts. Die meisten Websites erreichen mich mit bereits installiertem Caching-Plugin und fallen trotzdem durch.
Warum ändert sich mein PageSpeed-Insights-Wert ständig?
Die große Zahl oben ist ein Labortest auf einem simulierten langsamen Gerät, und sie schwankt zwischen den Durchläufen. Der Abschnitt darunter – Felddaten aus dem Chrome UX Report – ist das, was Google tatsächlich verwendet, und er ist ein gleitender 28-Tage-Durchschnitt echter Besucher. Orientieren Sie sich an den Felddaten und ignorieren Sie kleine Bewegungen im Laborwert.
Wie lange dauert es, bis die Verbesserung bei Google sichtbar wird?
Da die Felddaten ein gleitendes 28-Tage-Fenster sind, rechnen Sie mit etwa vier Wochen, bis die Änderung vollständig abgebildet ist – bei Websites mit wenig Traffic, die länger für genügend Messwerte brauchen, auch länger. Wer eine sofortige Ranking-Änderung verspricht, redet vom Laborwert, nicht von dem, der zählt.
Welche Verbesserung können Sie versprechen?
Keine, bevor ich mir die Website angesehen habe – deshalb kommt zuerst die Diagnose und dann das Angebot. Eine Plugin-lastige Website mit unoptimiertem Hero-Bild hat viel leicht erreichbaren Spielraum. Eine Website, die im Front-End bereits schlank, aber in der Datenbank langsam ist, ist ein anderer Auftrag zu einem anderen Preis. Ich gebe Ihnen lieber nach einer Stunde Analyse eine echte Zahl als jetzt eine beeindruckende.
Muss ich die Website neu bauen?
Meistens nicht. Die meisten Tempo-Probleme sind eine Handvoll konkreter Ursachen statt eines grundlegenden Fehlers, und sie zu beheben ist weit günstiger als ein Neubau. Wenn ich glaube, dass Sie an die Grenze dessen gestoßen sind, was die aktuelle Umsetzung leisten kann, sage ich es – aber das ist die Ausnahme, und es liegt nicht in Ihrem Interesse, dass ich als Erstes danach greife.
Was ist INP, und hat es FID ersetzt?
Interaction to Next Paint hat First Input Delay im März 2024 als Core Web Vital abgelöst. FID hat nur die Verzögerung gemessen, bevor der Browser mit der Verarbeitung Ihrer ersten Interaktion begann. INP misst, wie lange die gesamte Interaktion bis zu einer sichtbaren Reaktion gedauert hat, über den ganzen Besuch. Es ist deutlich schwerer zu bestehen, und man fällt meist aus einem Grund durch: zu viel JavaScript auf dem Hauptthread.
Meine Website war schnell und ist langsam geworden. Was hat sich geändert?
Meiner Erfahrung nach fast immer eines von drei Dingen: ein Plugin oder Tracking-Skript, das seitdem hinzugekommen ist, ein Content-Team, das Bilder in voller Auflösung direkt von der Kamera hochlädt, oder eine Datenbank, die still gewachsen ist – Beitragsrevisionen, abgelaufene Transients, eine per autoload geladene Optionstabelle. Alle drei sind günstig zu beheben, sobald sie erkannt sind.
Nächster Schritt
Schicken Sie mir die URL. Ich sage Ihnen, was nicht stimmt.
Als Erstes erhalten Sie eine schriftliche Diagnose, die Sie in jedem Fall behalten. Wenn die ehrliche Antwort lautet, dass Ihre Website bereits in Ordnung ist, steht genau das im Dokument.