Lighthouse-Score: so übertreffen Sie 2026 mobil die 95

Was Lighthouse 2026 misst

Lighthouse ist das offizielle Tool von Google, um die technische Qualität einer Website zu prüfen. Es misst 4 Dimensionen:

1. Performance: Ladegeschwindigkeit, flüssige Darstellung, Reaktionsfähigkeit (LCP, INP, CLS, FCP, TBT)
2. Barrierefreiheit: WCAG-Konformität, Lesbarkeit, Tastaturnavigation
3. Best Practices: Sicherheit (HTTPS), optimierte Bilder, Fehler in der Konsole
4. SEO: Metadaten, Indexierbarkeit, grundlegende strukturierte Daten

Jede Dimension wird auf 100 bewertet. Der Gesamtscore ist der gewichtete Durchschnitt.

Schwellenwerte von Google:

• 0 bis 49: rot (schlecht)
• 50 bis 89: orange (verbesserungsfähig)
• 90 bis 100: grün (gut)

Doch 2026 genügt 90 bei umkämpften Suchanfragen nicht mehr. Sie sollten in allen 4 Dimensionen 95+ anstreben, um sich gegen Konkurrenten durchzusetzen, die ihre Hausaufgaben gemacht haben. Dieser Artikel erklärt, wie.

Warum 95+ und nicht 90+

Drei Gründe, über 90 hinauszugehen.

Gewichtung der Core Web Vitals. Seit dem Core Update vom März 2026 fallen die Core Web Vitals (LCP, INP, CLS) beim Ranking stärker ins Gewicht. Eine Website mit 92 und eine mit 98 sind nicht gleichwertig: Die zweite hat bei knappen Suchanfragen einen konkreten SEO-Vorteil.

Mobile-First-Index. Google indexiert und bewertet vorrangig die mobile Version. Nur der mobile Lighthouse-Score zählt wirklich. Er ist aber schwieriger zu optimieren als der Desktop-Score: 4G-Verbindung, schwächerer Prozessor, kleinerer Bildschirm. Mobil 95 zu erreichen, verlangt mehr Aufwand als 95 am Desktop.

Angleichung der Konkurrenz. 2026 haben viele Agenturen verstanden, wie wichtig Lighthouse ist. Ihre direkten Konkurrenten haben ihren Score verbessert. Wenn Sie bei 75 bleiben, während sie bei 95 liegen, zeigt sich der Abstand im Ranking.

Anatomie eines schlechten Scores: die typischen Ursachen

Ein mobiler Lighthouse-Score von 65 bis 75 (der typische Fall bei KMU in der Westschweiz im Jahr 2026) vereint oft die folgenden 5 Probleme.

Problem 1: Zu schwere Bilder

Symptom: LCP > 4 Sekunden, tiefer Performance-Score.

Ursache: PNG-/JPEG-Bilder ohne Komprimierung, ohne modernes Format (WebP/AVIF), ohne Lazy Loading, ohne angegebene Abmessungen.

Lösung: alle Bilder in WebP oder AVIF umwandeln (30 bis 50 % kleinere Dateien), responsiv mit srcset ausliefern, alles unterhalb des sichtbaren Bereichs per Lazy Loading laden, width und height angeben, um CLS zu vermeiden.

Tools: Squoosh.app (manuelle Komprimierung), Imagify oder ShortPixel (automatisch für WordPress), Bilddienst von Astro/Next.js (automatisch beim Build).

Problem 2: Blockierendes JavaScript

Symptom: TBT (Total Blocking Time) > 600 ms, verschlechterter INP.

Ursache: synchron geladene Skripte von Drittanbietern (Google Tag Manager, Hotjar, Chat-Widgets), zu grosses JavaScript-Hauptbundle (> 200 KB), kein Code Splitting.

Lösung: alle Skripte von Drittanbietern auf async oder defer umstellen. Das Hauptbundle in logische Chunks aufteilen. Jedes Drittanbieter-Skript hinterfragen: Ist es wirklich nützlich?

Häufiger Fehler: Google Tag Manager auf 100 % der Website laden, nur um 3 Events zu erfassen. Wo sinnvoll, besser direkt ohne GTM tracken.

Problem 3: Blockierende Webfonts

Symptom: FOIT (Flash Of Invisible Text) zu Beginn des Ladevorgangs, tiefer Performance-Score.

Ursache: eigene Schriften, die synchron über Google Fonts oder Adobe Fonts geladen werden.

Lösung: font-display: swap in @font-face, Subsetting der Schriften (nur die verwendeten Zeichen laden).

Problem 4: Render-blockierendes CSS

Symptom: FCP (First Contentful Paint) > 1,8 s.

Ursache: das gesamte CSS der Website wird synchron im <head> geladen.

Lösung: das kritische CSS (im sichtbaren Bereich, above the fold) inline ins HTML übernehmen, den Rest nicht blockierend laden.

Tools: Critters (Astro), criticalCSS (Next.js), penthouse.

Problem 5: WordPress-Plugins, die sich anhäufen

Symptom: Performance-Score < 60 selbst bei einfachen Websites.

Ursache: 20 bis 40 geladene WordPress-Plugins, von denen jedes 10 bis 50 KB JavaScript und zusätzliche Serverlatenz mitbringt.

Lösung: Plugins prüfen, nicht wesentliche deaktivieren, Kombinationen mehrerer Plugins durch native Lösungen ersetzen. Oder auf einen modernen Stack migrieren (siehe unseren Artikel zu WordPress und SEO).

Die 9 konkreten Massnahmen, um von 70 auf 95+ zu kommen

Massnahme 1: Den aktuellen Stand prüfen

PageSpeed Insights → URL eingeben → die Scores und die von Lighthouse erkannten Verbesserungsmöglichkeiten notieren. Mobil und am Desktop messen. Mobil ist das, was zählt.

Massnahme 2: Bilder komprimieren

Die erste Massnahme mit grosser Wirkung. Konsequente Umwandlung in WebP/AVIF. In Astro/Next.js geschieht das automatisch über <Image>. In WordPress erledigen Imagify oder ShortPixel das (CHF 5 bis 10/Monat).

Massnahme 3: Lazy Loading

Für alle Bilder unterhalb des sichtbaren Bereichs: natives loading="lazy". Bei eingebetteten YouTube-Videos lite-youtube-embed statt der Standard-Einbettung verwenden.

Massnahme 4: Bildabmessungen angeben

Immer width und height für jedes Bild, entweder im HTML oder per CSS aspect-ratio. Das verhindert CLS (Layoutverschiebungen beim Laden).

Massnahme 5: Code Splitting für JavaScript

Das JavaScript-Bundle in Chunks pro Route aufteilen. In Next.js ist das nativ. In Astro ist das JavaScript standardmässig minimal (nur Islands). In WordPress mit einem schweren Theme ist es aufwendiger.

Massnahme 6: Drittanbieter-Skripte mit async oder defer

Alle nicht kritischen <script> auf async oder defer setzen. Bei jedem Drittanbieter-Skript prüfen, ob es nötig ist (Chat-Widget, Analytics, Google Tag Manager).

Massnahme 7: Optimierte Schriften

font-display: swap in allen @font-face. Wenn möglich selbst hosten. Subsetting der eigenen Schriften, um ihre Grösse zu reduzieren.

Massnahme 8: Kritisches CSS inline

Das CSS für den ersten Viewport inline im <head>. Den Rest nicht blockierend laden.

Massnahme 9: Schema.org für den Lighthouse-SEO-Score

Der SEO-Score von Lighthouse prüft, ob grundlegendes schema.org vorhanden ist. Mindestens Organization, BreadcrumbList und Article umsetzen.

Fehler, die Sie vermeiden sollten

Fehler 1: nur den Desktop optimieren. Viele KMU testen nur am Desktop und schliessen daraus: «Mein Lighthouse-Score liegt bei 95». Mobil bleibt er bei 60. Google bewertet nach der mobilen Version.

Fehler 2: nur einmal messen. Lighthouse schwankt je nach Bedingungen (Cache, Netzwerk, Serverlast). Machen Sie 3 Tests und nehmen Sie den Median.

Fehler 3: die neuen Metriken ignorieren. INP hat 2024 FID ersetzt. Viele ältere Artikel erwähnen INP nicht. Achten Sie darauf, dass Ihr Audit die Metriken von 2026 verwendet.

Fehler 4: ein durch Weglassen künstlich aufgeblähter Score. Alle Funktionen zu deaktivieren, um den Lighthouse-Score zu steigern, hilft nicht, wenn Ihre Website dadurch nutzlos wird. Behalten Sie das Nutzungserlebnis im Blick.

Was Voren liefert

Alle Websites von Voren werden mit einem mobilen Lighthouse-Score ausgeliefert, der bei der Inbetriebnahme gemessen wird. Das ist unser Lieferstandard:

• Firmenwebsite Essential: Lighthouse > 90 mobil + Desktop
• Firmenwebsite Premium: Lighthouse > 95
• Firmenwebsite Individuell: Lighthouse > 95
• E-Commerce: Lighthouse > 90 (Onlineshops sind strukturell aufwendiger zu optimieren)
• Web-App: Lighthouse > 85 je nach Komplexität

Standard-Stack: Astro 5 (redaktionelle Websites) oder Next.js 15 (interaktive Anwendungen) + optimierte Bilder + asynchrone Skripte + schema.org + kritisches CSS inline.

Weiterführend

Ein kostenloses Lighthouse-Audit anfragen: vollständige Diagnose Ihrer aktuellen Website und Massnahmenplan in 7 Tagen.

Unser Angebot Firmenwebsite ansehen: Lighthouse 90 bis 95+ angestrebt und bei der Inbetriebnahme gemessen.

Unseren Artikel zu den Core Web Vitals lesen: die 3 Metriken verstehen, die Lighthouse Performance gewichten.