Das Pagespeed-Playbook

Speed-Arbeit scheitert, wenn sie einmal einen Laborscore poliert und den Sieg erklärt. Die dauerhafte Version misst echte Nutzer, behebt nach Schicht und behandelt Regression als den Normalfall, gegen den man sich wappnet.

Shop-Speed ist ein Umsatzfaktor — Conversion, Anzeigeneffizienz und Rankings preisen ihn ein — und er verfällt von selbst, während Apps, Skripte und Bilder sich ansammeln. Dieses Playbook fährt die Disziplin: Felddaten-Basislinien je Template etablieren, in Wirkungsreihenfolge auf der richtigen Schicht beheben (Edge-Konfiguration vs. Seitenstruktur) und die Stolperdrähte installieren, die die Verbesserung permanent machen statt zur vierteljährlichen Heldentat.

Stufe 1: Basislinie aus Felddaten, je Template

Laborscores täuschen in beide Richtungen. Sammeln Sie echte LCP-, INP- und CLS-Werte segmentiert nach Template — Produkt, Kategorie, Startseite, Checkout — und Gerät. Die umsatzgewichtete Sicht sagt, wo anfangen: Ein langsames Produkt-Template auf Mobilgeräten schlägt in der Wirkung meist alles andere.

  • Echte Core Web Vitals je Template und Geräteklasse

  • Template-×-Umsatz-Gewichtung zur Arbeitsreihenfolge

  • Vollständiges Drittskript-Inventar mit Kosten je Skript

  • Die Labor-Feld-Lücke — selbst schon ein Diagnosehinweis

Stufe 2: Auf der Schicht beheben, der das Problem gehört

Edge-Probleme — Cache-Regeln, Bildformate und -größen, Kompression, Auslieferung — werden in der Konfiguration behoben und wirken sofort shopweit. Seitenprobleme — renderblockierende Skripte, überdimensionierte Hero-Medien, Layout-Shift durch spät ladende Widgets, App-Ballast — werden im Template behoben. Edge-Arbeit zuerst halbiert das Problem oft, bevor ein Template angefasst wird.

Stufe 3: Dafür sorgen, dass es behoben bleibt

Jede künftige App-Installation und jedes Kampagnenskript ist eine wartende Regression. Halten Sie die Template-Basislinie live, prüfen Sie Skript-Zugänge gegen ihre gemessenen Kosten und auditieren Sie das Drittanbieter-Inventar planmäßig neu — das Skript, das letztes Jahr seinen Platz verdiente, verdient ihn vielleicht nicht mehr.

So funktioniert es

01

Basislinie und Rangfolge

Feldmetriken je Template, umsatzgewichtet, mit kostenbewertetem Skriptinventar.

02

Edge zuerst, dann Templates

Konfigurationsfixes wirken sofort shopweit; Template-Fixes folgen in Wirkungsreihenfolge.

03

Gewinne verteidigen

Live-Basislinien, Skriptkosten-Review und geplante Re-Audits verhindern das Wiederverfallen.

Das bekommen Sie

  • Speed gemessen an den Nutzern, die tatsächlich zahlen

  • Fixes auf der Schicht angewendet, der jedes Problem gehört

  • Drittskripte einzeln rechenschaftspflichtig für ihre Kosten

  • Regressionen in der Woche ihres Auftretens gefangen, nicht im Folgequartal

Häufige Fragen

Welche Core-Web-Vitals-Ziele soll ich anpeilen?

Die veröffentlichten Gut-Schwellen — LCP unter 2,5 s, INP unter 200 ms, CLS unter 0,1 — am 75. Perzentil echter Nutzer, je Template. Aber Richtung zählt mehr als Schwellen: Der Weg von schrecklich zu mittelmäßig holt den Großteil des Conversion-Gewinns.

Wie viel Speed bringt allein die Edge-Schicht?

Bei nie getunten Shops liefert Edge-Arbeit — richtiges Caching, moderne Bildformate, Kompression — häufig die größere Hälfte der Verbesserung, ohne ein Template anzufassen. Deshalb kommt sie zuerst.

Mein Theme ist das Problem. Neu bauen oder flicken?

Erst messen: Ist die Template-Fixliste kurz und begrenzt, flicken. Kämpft die Theme-Architektur gegen jeden Fix, zahlt sich der Neubau aus — aber das ist eine Entscheidung auf Evidenz, nicht aus Frust.

Welche Agenten fahren das?

Ops besitzt Basislinien, Edge-Schicht und Regressionswache; Builder liefert Template-Fixes mit angehängter Evidenz. Das Audit-Log dokumentiert, was sich änderte und was es mit den Metriken machte.

Lassen Sie das Team für Ihren Shop arbeiten

Verbinden Sie Storefront, Analytics und E-Mail-Stack, setzen Sie ein Ziel, und die Agenten erledigen die Arbeit von Anfang bis Ende. Im kostenlosen Tarif starten Sie mit Ihrem eigenen Modell-Key.