Warum ist Mobile-PageSpeed 2026 geschäftskritisch?
Zwei von drei Nutzern besuchen Websites heute über ein Mobile-Phone oder Tablet. Mobile-Geräte unterliegen dabei zusätzlichen Geschwindigkeitsanforderungen, da variable Netzwerkverbindungen die Performance weiter belasten, was Ladegeschwindigkeit auf mobilen Geräten zu einem entscheidenden Erfolgsfaktor macht.
Google nutzt Core-Web-Vitals (LCP, INP, CLS) als direkten Ranking-Faktor. Branchenanalysen beziffern den Conversion-Verlust pro Sekunde zusätzlicher Ladezeit auf ca. 7 %. Zwei Sekunden Verzögerung können die Absprungrate um bis zu 32 % erhöhen.
Schnelle Seiten werden von Googlebot effizienter gecrawlt, was besonders bei umfangreichen Websites relevant ist. Seiten mit konstant guten Core-Web-Vitals bauen über die Zeit eine Ranking-Stabilität auf, die Konkurrenten mit schwankender Performance nicht erreichen.
Langsame Ladezeiten sind vermutlich auch ein Grund, warum KI-Agenten wie ChatGPT oder Perplexity eine Seite nicht vollständig verarbeiten. KI-Crawler haben strikte Timeout-Grenzen. Wenn eine Seite zu lange braucht, wird sie nicht indexiert, nicht zitiert, nicht als Quelle verwendet. Für AEO (Answer-Engine-Optimization) und GEO (Generative-Engine-Optimization) gilt: Eine Seite, die technisch nicht performt, existiert für KI-Suchmaschinen nicht. PageSpeed ist damit nicht nur ein SEO-Signal, sondern eine Voraussetzung für KI-Sichtbarkeit.
Learning: Mobile-PageSpeed beeinflusst Google-Ranking, Conversion-Rate, Bounce-Rate, Crawl-Effizienz und KI-Sichtbarkeit gleichzeitig. Es ist kein isolierter technischer Wert, sondern ein Querschnitts-Faktor.
Welches Setup und welche Maßnahmen waren bei webforge.services bereits vorhanden?
Die Website webforge.services lief auf Next.js mit Static-Export (output: 'export'). Der Mobile-PageSpeed-Score lag bei 79 Punkten. Das LCP-Element war eine H1-Überschrift, die erst nach 4,2 Sekunden gerendert wurde. Der Element-Render-Delay betrug 2.240 ms.
Die Analyse zeigte, dass alle externen CSS-Dateien als Render-Blocking im <head> geladen wurden, insgesamt 81 KiB. Der Browser konnte die H1 nicht malen, bis sämtliches CSS vollständig heruntergeladen und geparst war. Bei einer langsamen Mobilverbindung (Slow 4G) dauerte das über 2 Sekunden.
Technisches Setup
- Next.js 16.1 mit React 19.2, App-Router, TypeScript
- Static-Export (
output: 'export'), alle Seiten als statisches HTML - SCSS pro Komponente, jede Komponente mit eigener SCSS-Datei für isoliertes, wartbares Styling
- Hosting: Render (Frankfurt), mit Cloudflare als CDN und Brotli-Komprimierung aktiv
Bereits getroffene Performance-Maßnahmen
- Server-Components wo möglich (Next.js 13+), um Client-seitiges JavaScript und Render-Delay vor der Hydration zu reduzieren
- Third-Party-Scripts verzögert geladen (
afterInteractive,lazyOnload) - Fonts lokal gehostet via
next/fontmitfont-display: swap - Content-Sichtbarkeit von GSAP entkoppelt, damit H1 und Subtitle via CSS sofort sichtbar sind
- Statisches Bild statt Canvas auf Mobile, um Frame-Loading zu vermeiden
Core-Web-Vitals-Ausgangswerte (Mobile, Slow 4G, Lighthouse):
Trotz dieser Grundlagen lag der Score bei 79 Punkten. Die verbleibenden Probleme:
- Static-Export (
output: 'export'): Next.js bietetexperimental: { optimizeCss: true }für automatisches Critical-CSS-Inlining an, das funktioniert aber nur mit Server-Rendering. Bei Static-Export muss Critical-CSS-Inlining manuell gelöst werden. - Tailwind v4 im Projekt: Im Laufe der Zeit wurde auf Tailwind verzichtet, es aber nie vollständig entfernt.
@import "tailwindcss"in der globalen SCSS-Datei erzeugte 55 KiB Overhead, weil Tailwind v4 den kompletten Theme-Block in jeder generierten CSS-Datei duplizierte.
Learning: Ein hoher Ausgangswert an Best-Practices reicht nicht. Der Score blieb bei 79, weil zwei spezifische Probleme (Render-Blocking-CSS und Tailwind-Overhead) die Gesamtperformance dominierten.
Maßnahme 1: Tailwind CSS entfernen (79 → 84)
Tailwind v4 erzeugte durch @import "tailwindcss" einen umfangreichen Theme-Block mit zahlreichen CSS-Variablen und Farbdefinitionen. In Kombination mit dem CSS-Splitting von Next.js wurde dieser Block in mehreren generierten CSS-Dateien dupliziert. Dadurch entstanden rund 55 KiB ungenutzter CSS-Overhead, obwohl im Projekt keine Tailwind-Utilities verwendet wurden.
Nach dem Entfernen schrumpfte die gesamte CSS-Größe von 81 KiB auf 26 KiB, eine Reduktion um 68 %. Der Element-Render-Delay blieb allerdings bei 2.240 ms, weil die CSS-Dateien weiterhin Render-Blocking waren. Weniger CSS allein löst das Render-Blocking-Problem nicht.
Learning: Tailwind entfernen war nicht der Haupthebel, sondern die Voraussetzung dafür, dass der Haupthebel (Critters) maximal wirken konnte. Weniger externes CSS bedeutet weniger Inline-CSS im <head>, sodass das HTML nicht aufgebläht wird.
Maßnahme 2: Critters-Postbuild-Script (84 → 92)
Was genau macht Critical-CSS-Inlining?
Ohne Critical-CSS-Inlining stoppt der Browser das Rendering, sobald er im <head> externe CSS-Dateien als <link rel="stylesheet">-Tags findet. Er muss alle CSS-Dateien herunterladen und parsen, bevor er auch nur ein Pixel malen darf. Die H1 steht zwar bereits im HTML, aber der Browser wartet auf CSS, bevor er sie rendert.
Das Postbuild-Script löst das in drei Schritten:
- Schritt 1:
data-precedence="next"und<noscript>-Fallbacks entfernen. Next.js markiert jeden CSS-Link-Tag mit dem Attributdata-precedence="next". Dieses Attribut ist ein internes Steuerungselement von React/Next.js, das die Ladereihenfolge von Stylesheets während der Hydration kontrolliert. Critters erkennt so markierte Tags nicht als normale Stylesheets und überspringt sie. Das Entfernen ist die Voraussetzung für alles Weitere. - Schritt 2: Critters inlined das Critical-CSS. Die CSS-Regeln für den sichtbaren Bereich (H1-Styles, Body-Background, Navbar) werden als
<style>-Block direkt ins HTML geschrieben. Der Browser hat sie sofort, ohne einen externen Request. - Schritt 3: Alle verbleibenden CSS-Link-Tags manuell auf async umstellen. Critters' eigene Option dafür (
preload: "swap") funktionierte nicht zuverlässig. Deshalb wandelt ein zusätzlicher Regex-Schritt alle<link rel="stylesheet">in<link rel="stylesheet" media="print" onload="this.media='all'">um. Das sagt dem Browser: Lade diese Dateien im Hintergrund, aber warte nicht darauf, bevor du malst.
Das Ergebnis: Der Browser sieht die Inline-Styles, malt die H1 sofort (280 ms statt 2.240 ms) und lädt die restlichen CSS-Dateien asynchron nach.
Warum funktionierte Critical-CSS-Inlining nicht beim ersten Versuch?
Der erste Versuch mit Critters brachte keine Verbesserung. Critters schrieb zwar Critical-CSS inline (HTML wuchs von 16 auf 26 KiB), aber die externen CSS-Dateien wurden nicht auf async umgestellt. Der Grund: data-precedence="next" auf den Link-Tags. Critters erkannte sie nicht als Stylesheets und ließ sie unverändert. Der Browser blockierte weiterhin.
Erst das Entfernen von data-precedence="next" vor dem Critters-Durchlauf und das manuelle Erzwingen von async Loading danach löste das Problem. Das ist ein undokumentierter Workaround, den wir durch Analyse des generierten HTML-Quelltexts identifiziert haben.
Learning: Bei Next.js Static-Export funktioniert weder experimental: { optimizeCss: true } noch Critters out-of-the-box. Das dreistufige Postbuild-Script war der Unterschied zwischen 84 und 92 Punkten.
Welche Maßnahmen haben den Score verschlechtert?
Der Versuch, Sektionen unterhalb des Viewports per next/dynamic lazy zu laden, verschlechterte den Score um 7 Punkte (83 → 76). Der Grund: CSS wird in Next.js nicht per dynamic() lazy-loaded. Die CSS-Dateien blieben Render-Blocking, aber der zusätzliche JavaScript-Overhead für das dynamische Laden kam hinzu. Nach dem Rollback stieg der Score wieder.
Eine browserslist-Konfiguration in der package.json (chrome >= 80, edge >= 80, firefox >= 80, safari >= 14) sollte 14 KiB Polyfills einsparen. Tatsächlich blieben die Polyfills bestehen, aber die JS-Chunk-Struktur änderte sich. Das erzeugte zusätzliche Main-Thread-Tasks und verschlechterte den Score um 9 Punkte (92 → 83). Nach dem Entfernen stieg der Score wieder.
Learning: Beide Maßnahmen wirkten kontraproduktiv. dynamic() verschiebt JS-Laden, aber nicht CSS-Laden. browserslist verändert die Chunk-Struktur, ohne die Polyfills tatsächlich zu entfernen. Nicht jede theoretisch sinnvolle Optimierung verbessert den Score.
Welches Ergebnis erzielte die PageSpeed-Optimierung bei webforge.services?
Der Mobile-PageSpeed-Score stieg von 79 auf 92 Punkte. Der größte Hebel war das Critters-Postbuild-Script mit einem undokumentierten Workaround für Next.js data-precedence (84 → 92). Die Voraussetzung war das Entfernen von 55 KiB ungenutztem Tailwind-CSS (79 → 84).
Welche versteckten Probleme deckt ein systematischer PageSpeed-Optimierungsprozess auf?
Learning: PageSpeed-Optimierung ist mehr als Metriken verbessern. Der Prozess zwingt dazu, das gesamte Projekt Schicht für Schicht zu durchleuchten. Ungenutzter Code, überflüssige Dependencies, falsch konfigurierte Build-Prozesse, all das wird sichtbar, wenn man systematisch den Ursachen für langsame Ladezeiten nachgeht. Am Ende steht nicht nur ein besserer Score, sondern ein schlankeres Projekt. Und weil Core-Web-Vitals direkt das Google-Ranking, die Conversion-Rate und die Crawl-Effizienz durch KI-Agenten beeinflussen, zahlt sich diese Arbeit mehrfach aus.
Learning: Die Hauptursache für schlechte PageSpeed-Scores ist selten ein einzelnes großes Problem. Bei webforge.services war es die Kombination aus Tailwind-Overhead und fehlendem Critical-CSS-Inlining. Erst die Lösung beider Probleme zusammen brachte den Score über 90.
Learning: KI-Tools sind bei der Analyse hilfreich, produzieren aber viel Rauschen. Lighthouse empfahl wiederholt Bildoptimierungen für lazy-loaded Bilder, die keinen Einfluss auf LCP hatten. Die tatsächlichen Ursachen (Tailwind-Overhead + fehlendes Critical-CSS-Inlining bei Static-Export) waren in den Reports nicht offensichtlich.