gmbapi: LCP von 5 auf 1,9 Sekunden, in einem Call gefixt

 Power-Hour · gmbapi
LCP von 5 auf 1,9 Sekunden, in einem Call gefixtEin Softwareunternehmen für lokales SEO mit einer brandneuen Next.js-Website: schnell auf dem Desktop, langsam mobil.
1,9sLCP in CrUX, vorher 5s
150msINP mobil, vorher 220ms
700msServer-Antwortzeit, vorher 3s
0,00CLS in CrUX, vorher 0,08
Kundegmbapi, Software für lokales SEO
PlattformReact, Next.js, Headless-CMS
LeistungPower-Hour, August 2026
 Der Kunde
Eine neue Website: auf dem Desktop bestanden, mobil durchgefallengmbapi ist ein Softwareunternehmen für lokales SEO, und zwar ein gutes. Im Juli 2026 wechselten sie von WordPress auf eine neue Website mit React und Next.js auf einem Headless-CMS. Auf dem Desktop waren die Core Web Vitals erfüllt. Mobil schafften LCP, FCP und INP das nicht.
Michel van Luijtelaar, der das Unternehmen leitet, kenne ich seit 2021. Er bat mich 2023 und wieder 2025, mir seine WordPress-Website anzusehen. Im Juli 2026 kam er mit der neuen.
 Was wir fanden, was wir taten
Tod durch tausend NadelsticheEin einzelnes großes Problem gab es nicht – das gibt es fast nie. Wir haben in den DevTools einen mobilen Seitenaufruf aufgezeichnet, den Trace vom ersten Byte bis zum LCP durchgesehen und direkt im Gespräch gefixt.
Was nicht stimmte
Was wir getan haben
TTFB
Der Server brauchte 3 Sekunden bis zum ersten Byte. Jede Seite wurde pro Request gerendert und holte ihre Inhalte live aus dem Headless-CMS. Die Cache-Header standen auf no-store, sodass das CDN das HTML nie zwischenspeicherte.
Die Seiten wurden auf statisches Rendering mit ISR umgestellt, die CMS-Abfragen gecacht und die Header so angepasst, dass das CDN das HTML behält. Die Server-Antwortzeit sank auf 700 ms. Das geht direkt von FCP und LCP ab, noch bevor man irgendetwas anderes anfasst.
LCPINP
Tags und Analytics im Head, Drittanbieter-Widgets ganz oben auf der Seite und Komponenten, die im Browser gerendert wurden, obwohl der Server sie genauso gut rendern könnte. Das ganze JavaScript wurde gebraucht; es lief nur zu früh.
Die Tags und Widgets warten nun, bis die Seite da ist, und diese Komponenten kommen vom Server.
LCP
Das Hero-Bild wurde per Lazy Loading geladen. Es lief über next/image ohne priority, der CMS-Block setzte bei jedem Bild loading="lazy", und wo das Hero-Bild ein CSS-Hintergrund war, fand der Browser es erst spät.
Das Hero-Bild bekam priority und fetchpriority="high", der CMS-Block eine Ausnahme für das erste Bild, und aus dem CSS-Hintergrund wurde ein echtes img mit Preload. Zusammen sparte das 120 ms beim LCP.
LCP
Zwei Stylesheets mit 30 kB und 0,5 kB, auf die der erste Screen wartete.
Beide auf 15 kB umgeschrieben, was weitere 100 ms sparte.
LCP
Viele kleinere Dinge, für sich genommen keines davon groß.
Wir sind den Trace weiter durchgegangen und haben sie nacheinander direkt im Gespräch gefixt.
In CrUX
Genau diesen Chart wünscht man sich. Der LCP für mobile Besucher sank von in der Spitze 5,6 Sekunden auf 2,0 und die Server-Antwortzeit von 4,2 auf 0,8 Sekunden. Beide Linien brauchen Wochen, um zu fallen, weil jeder Punkt die langsamen Tage im 28-Tage-Fenster noch mitzählt. Seit August liegt der LCP stabil zwischen 1,9 und 2,2 Sekunden.
2,5 s4,0 sFebMärAprMaiJunJulAugSepOkt3,8 s2,0 s5,6 sLCP mobil, p75
0,8 s1,8 sFebMärAprMaiJunJulAugSepOkt2,0 s0,76 s4,2 sTTFB mobil, p75
gmbapi.com in CrUX, Januar bis Oktober 2026. Jeder Punkt steht für die 28 Tage bis zu diesem Datum. Grün ist gut, Orange braucht Verbesserung, Rot ist schlecht.
Follow-up
Nach dem Call habe ich ihnen Zugriff auf CoreDash gegeben, damit sie ihre mobilen Besucher pro Seite und pro Release sehen, und ihre Taskliste geprüft. Die Zahlen oben stammen aus CrUX, Googles eigenen Field Data.
Eine Stunde reicht, wenn die Entwickler mit im Call sind und die Fixes klein sind. Größere Punkte kommen in die Notizen, das Wichtigste zuerst.
 Was wir gelernt haben
Ihre Vermutung war ungenutztes JavaScriptBei einer neuen React-Website durchaus naheliegend. Im Trace standen aber die Server-Antwortzeit und ein Hero-Bild mit Lazy Loading ganz oben.
Ein neues Framework macht dich nicht automatisch schnellSie waren gerade erst auf Next.js umgestiegen und hatten die Standardeinstellungen übernommen: next/image lädt jedes Bild per Lazy Loading, solange du kein priority mitgibst. Ihr Hero-Bild war eines davon.
 Eine Stunde mit deinen Entwicklern im Call: €350Bring deinen Entwickler und deine langsamste Seite mit. Wir schauen sie uns gemeinsam an und fixen direkt im Gespräch, was wir können.
Power-Hour buchenWeitere Ergebnisse auf meiner Kundenseite.
Core Web Vitals gmbapi: LCP von 5 auf 1,9 Sekunden, in einem Call gefixt