Ich komme in dein Team und wir machen deine Seite schnell

Das hängt davon ab, wie viel Umsatz über deine Seite läuft. Loop Earplugs wurde auf Mobile etwa 800 ms schneller und die Checkout-Conversion stieg um 7 %. Ich kann dir keine 7 % versprechen. Aber RUM zeigt, was jeder Fix mit der Metrik gemacht hat. Deine Analytics zeigen, was es mit dem Umsatz gemacht hat. Du wirst beides haben.

Ein wenig. Core Web Vitals sind ein Ranking-Faktor, aber ein kleiner: Relevanter Content steht an erster Stelle. Geschwindigkeit ist der Tiebreaker zwischen Seiten, die nah beieinander liegen. Der größere Gewinn passiert nach dem Klick. Eine schnellere Seite verliert weniger Besucher und konvertiert mehr von denen, die bleiben. Das zeigt sich in deinem Umsatz, egal ob Google dich nach oben schiebt oder nicht.

Für Unternehmen mit eigenen Entwicklern, echtem Traffic und einer Seite, bei der Geschwindigkeit sich im Umsatz zeigt. Meistens E-Commerce, SaaS-Apps, bei denen Klicks sich langsam anfühlen, und Publisher mit vielen Anzeigen. Keine eigenen Entwickler und keine Agentur, die für euch baut? Dann ist ein Audit oder ein Quick Fix der bessere Start.

Nein. Jeder, der einen Wert garantiert, ohne deine Seite gesehen zu haben, rät. Mein Ziel ist es, die Core Web Vitals beim 75. Perzentil auf den Seiten zu bestehen, die euch Geld bringen. Genau das misst Google und genau das spüren eure Besucher.

Die meisten Agenturen machen von allem ein bisschen. Performance ist nur ein Punkt auf der Liste. Es ist das Einzige, was ich mache. Die harten Probleme stehen selten auf einer Checkliste: Hydration in Next.js, Dutzende von Drittanbieter-Skripten auf einer Medienseite, Anzeigen, die beim Laden das Layout verschieben. Wir alle haben unsere Spezialität. Das hier ist meine.

Ja, es ist in der Beratung enthalten. Wenn euer eigenes RUM bereits zeigt, welches Element oder Skript langsam ist, können wir stattdessen das nutzen.

So ziemlich alle. Next.js, Nuxt, Magento, Salesforce Commerce Cloud, Shopify, WordPress oder eine PHP-Seite, die jemand 2012 gebaut hat. Dem Browser ist es egal, womit die Seite gebaut wurde. Und der Browser ist der Ort, an dem ich arbeite. Auf einer gehosteten Plattform wie Shopify kannst du die Plattform selbst nicht ändern. Aber das Theme, die Apps und die Skripte, die sie hinzufügen, gehören dir. Dort stecken die meisten Probleme.

Dieser Score stammt von Lighthouse: ein Labortest auf einem simulierten langsamen Handy. Google schaut auf die field data. Das ist das, was deine echten Besucher beim 75. Perzentil erleben. Daran arbeite ich. Der Score in Lighthouse steigt meistens nebenbei, aber ich jage ihn nicht. Eine Seite kann 95 erreichen und trotzdem die Core Web Vitals nicht bestehen, und umgekehrt.

Ich finde heraus, was auf dem main thread läuft, wenn jemand klickt. Die Long Animation Frames (LoAF) API sagt mir, welches Skript und welche Funktion. Dann teilen wir diese Arbeit auf, räumen sie aus dem Weg oder entfernen sie komplett.

Fast nie. Meistens sind es ein paar schwere Komponenten, die Ladereihenfolge von Skripten oder wie die Seite hydratisiert. Das zu ändern kostet viel weniger als ein Rewrite und du siehst das Ergebnis viel schneller.

Ihr habt noch kein RUM, oder eures zeigt nicht, welches Element oder Skript langsam ist? Dann baue ich CoreDash ein. Es ist genau für diese Arbeit gemacht. Für jedes LCP-, INP- und CLS-Event zeigt es, welches Element, Skript oder welche Ressource es verursacht hat. Du siehst innerhalb eines Tages, was ein Fix bei echten Besuchern bewirkt hat, statt auf den 28-Tage-Durchschnitt von Google zu warten. Und es gibt kein Limit, wie viele URLs du trackst oder wie lange du die Daten behältst.

Ja. Ich arbeite gerne mit Agenturen und allen anderen Beteiligten zusammen. Die Agentur baut. Ich finde die Probleme, priorisiere sie und prüfe jeden Fix. Genau wie mit deinem eigenen Team. Seid ihr selbst die Agentur? Dann seht ihr hier, wie ich mit Agenturen zusammenarbeite.

Erkenntnisse als Tickets in eurem eigenen System, Fixes, die live sind, Performance-Budgets in eurer CI/CD-Pipeline, Monitoring und Alerts für eure RUM-Daten. Und Entwickler, die wissen, warum das alles funktioniert.

Auf zwei Arten. Performance-Budgets in eurer Deployment-Pipeline markieren einen Build, der Layout Shifts hinzufügt oder den main thread blockiert, bevor er live geht. Und Alerts auf euren RUM-Daten sagen dir, wenn etwas schlechter wird. CoreDash prüft stündlich. Es schlägt aber erst Alarm, wenn es genug Daten gibt, um sicher zu sein. So jagst du keine False Positives. Du weißt trotzdem Wochen vor der Search Console Bescheid.

Ein Audit sagt dir, was falsch ist und in welcher Reihenfolge du es beheben musst. Die Beratung bleibt, bis es repariert ist.

Dein Team übernimmt. Es gibt auch einen Retainer, ab 1.500 € im Monat für etwa einen Tag meiner Zeit: Ich beobachte eure RUM-Daten, sage dir, wenn etwas langsamer wird, und jedes Quartal entscheiden wir, was als Nächstes ansteht.

Zugriff auf euer Repository (GitHub, GitLab, was auch immer ihr nutzt), eine Staging-Umgebung und eure Analytics. Keine wochenlangen Onboarding-Meetings. Sobald ich drin bin, fange ich an. Die ersten Ergebnisse bekommst du meistens innerhalb von 5 Arbeitstagen.

Irgendwo zwischen einer Woche und sechs Monaten. Es hängt davon ab, wie viel im Argen liegt und wie schnell dein Team releast. Meistens dauert es kürzer als erwartet: 60 % meiner Projekte sind in einem Monat abgeschlossen. Die genaue Dauer steht im Scope, bevor wir anfangen.

Du siehst Änderungen in euren RUM-Daten innerhalb eines Tages nach dem Deployment. Die Zahlen brauchen genug Besuche, um aussagekräftig zu sein. Gut besuchte Seiten zeigen es also früher als ruhigere. So oder so weißt du es Wochen bevor der CrUX-Report von Google aufholt.

Ja. Wir entfernen deine Tags nicht, wir ändern nur wie und wann sie laden. Anzeigen können weiterhin ihre Viewability-Anforderungen erfüllen, ohne den main thread zu blockieren oder das Layout zu verschieben. DPG Media, Aleteia und Who What Wear haben ihre Anzeigenumsätze behalten und die Core Web Vitals bestanden.