Auf einen Blick
Lighthouse misst vier Dimensionen einer Website — Performance, Barrierefreiheit, Best Practices und SEO. Aber nur die Core Web Vitals fließen direkt in das Google-Ranking. Performance-Optimierung ist messbarer SEO-Hebel, nicht nur UX-Disziplin. Die meisten Sites scheitern an Architektur-Entscheidungen, nicht an Detail-Optimierung. Calvarius bringt seine Mandate-Sites methodisch in den 90-plus-Bereich aller vier Dimensionen — die Calvarius-Site selbst liegt aktuell bei 99/100/100/100, mit First Contentful Paint 0,7 Sekunden, Largest Contentful Paint 0,7 Sekunden, Total Blocking Time 70 Millisekunden und Cumulative Layout Shift 0.
Was Lighthouse misst — und was nicht
Lighthouse ist ein Open-Source-Tool von Google, das eine Website in vier Dimensionen bewertet. Jede Dimension bekommt einen Score zwischen 0 und 100, dargestellt im bekannten Donut-Chart in Grün, Orange oder Rot.
Performance misst Ladegeschwindigkeit und Renderzeit. Hier fließen Metriken wie First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift und Speed Index zusammen zu einem gewichteten Gesamtwert. Performance ist die einzige der vier Dimensionen, in der Lighthouse synthetische Tests durchführt — die Werte werden im Browser unter simulierten Bedingungen ermittelt, nicht von echten Nutzern gemessen.
Barrierefreiheit prüft die Konformität mit den Web Content Accessibility Guidelines, kurz WCAG. Dazu zählen ausreichende Farbkontraste, semantisch korrekte HTML-Struktur, alternative Texte für Bilder, Tastaturbedienbarkeit aller interaktiven Elemente, ausreichende Touch-Target-Größen. Lighthouse kann etwa 30 bis 35 Prozent der Barrierefreiheits-Probleme automatisch erkennen — der Rest bleibt manuellen Audits vorbehalten.
Best Practices prüft technische Hygiene: HTTPS, sichere Library-Versionen, korrekte Bild-Dimensionierung, keine Browser-Konsolen-Fehler, keine veralteten APIs. Diese Dimension ist meist die einfachste — wer modern entwickelt, erreicht hier oft 100 ohne expliziten Optimierungs-Aufwand.
SEO prüft technische Auffindbarkeit: Meta-Tags, strukturierte Daten, Crawlability, Mobile-Tauglichkeit, korrekte HTTP-Status-Codes. Wichtig zu verstehen — die SEO-Dimension misst technische Voraussetzungen, nicht Content-Qualität oder Backlink-Profile. Ein Lighthouse-SEO-Score von 100 garantiert keine gute Google-Position. Er garantiert nur, dass keine technischen Hindernisse das Ranking behindern.
Das ist die zentrale Einschränkung von Lighthouse-Scores als Marketing-Metrik: Sie sind synthetisch ermittelt, nicht aus echtem Nutzer-Verhalten abgeleitet. Sie messen das Potenzial, nicht die Realität. Die Realität misst Google selbst mit den Core Web Vitals.
Core Web Vitals — die Metriken, die wirklich zählen
Während Lighthouse vier Dimensionen bewertet, nutzt Google für das Ranking nur drei spezifische Metriken — die Core Web Vitals. Sie werden nicht im Lighthouse-Browser ermittelt, sondern aus echten Nutzer-Daten der Chrome User Experience Report Datenbank, kurz CrUX. Das ist der entscheidende Unterschied: Lighthouse zeigt, was theoretisch möglich ist. CrUX zeigt, was Nutzer tatsächlich erleben.
Drei Metriken bilden die Core Web Vitals.
Largest Contentful Paint (LCP) misst die Ladezeit. Konkret: wie lange dauert es, bis das größte sichtbare Element above-the-fold gerendert ist? Das kann ein Hero-Bild sein, eine Headline oder ein Hintergrund-Element. Google bewertet LCP unter 2,5 Sekunden als gut, 2,5 bis 4 Sekunden als verbesserungswürdig, über 4 Sekunden als schlecht. Laut Web Almanac 2025 erreichen nur 62 Prozent der mobilen Seiten weltweit einen guten LCP-Wert — das macht LCP zur schwierigsten der drei Core Web Vitals.
Interaction to Next Paint (INP) misst Reaktionsschnelligkeit. Wie lange dauert es zwischen einer Nutzer-Interaktion — Klick, Tap, Tastatureingabe — und der nächsten visuellen Reaktion der Seite? INP hat im März 2024 First Input Delay (FID) als Core Web Vital abgelöst. Der Wechsel war substantiell strenger: FID maß nur die erste Interaktion einer Sitzung, INP misst praktisch alle Interaktionen. Google bewertet INP unter 200 Millisekunden als gut. Weltweit erreichen das 77 Prozent der mobilen Seiten — bei den 1.000 meistbesuchten Websites aber nur 53 Prozent. Hochfrequentierte Sites mit komplexer JavaScript-Logik haben oft INP-Probleme, die unter dem alten FID-Maß unsichtbar geblieben sind.
Cumulative Layout Shift (CLS) misst visuelle Stabilität. Springt der Inhalt während des Ladens, weil sich Bilder, Anzeigen oder Schriften nachträglich einfügen? CLS unter 0,1 gilt als gut. CLS ist die einfachste der drei Metriken zu lösen, weil sie sich vor allem auf strukturelle Vorgaben zurückführen lässt: Bilder brauchen Width- und Height-Attribute, Anzeigen-Slots brauchen reservierte Höhen, Schriften brauchen Font-Display-Strategien.
Diese drei Metriken sind seit 2021 Bestandteil des Google-Ranking-Signals „Page Experience". Sie ersetzen keine Content-Relevanz und keine Backlink-Autorität — aber sie sind ein eigenständiges Ranking-Signal, das bei sonst vergleichbaren Sites den Ausschlag gibt. Google selbst formuliert es so: „Wenn Sie ähnlichen Content wie ein Wettbewerber haben, kann Performance den Unterschied im Ranking machen."
Warum die meisten Sites scheitern — drei Architektur-Anti-Patterns
Wer einen Lighthouse-Audit auf einer durchschnittlichen Marketing-Site fährt, sieht regelmäßig Scores zwischen 40 und 70 in der Performance-Dimension. Die Versuchung ist groß, auf die Lighthouse-Empfehlungen direkt zu reagieren — Bilder komprimieren, JavaScript minimieren, Browser-Caching aktivieren. Diese Detail-Optimierung greift in den meisten Fällen zu kurz, weil die eigentlichen Probleme weiter oben liegen: in der Architektur, in den fundamentalen Bauentscheidungen der Site.
Drei Architektur-Anti-Patterns dominieren in der Praxis.
Erstens, fehlendes Server-Side-Rendering bei JavaScript-Frameworks. Eine moderne React- oder Vue-Site, die ausschließlich client-seitig rendert, sendet zunächst eine fast leere HTML-Hülle und lädt dann das JavaScript-Bundle. Erst nach dem Download, Parse und Execute der JavaScript-Datei beginnt das eigentliche Rendering. Das verschiebt LCP und FCP um Sekunden — auf Mobile bei langsamen Verbindungen oft auf 5 bis 8 Sekunden. Server-Side-Rendering oder Static Site Generation lösen das fundamental: der HTML-Inhalt ist schon im ersten Response, das JavaScript-Bundle hydriert die Seite anschließend für Interaktivität.
Zweitens, monolithische JavaScript-Bundles ohne Code-Splitting. Wenn jede Seite das gesamte Anwendungs-JavaScript lädt — inklusive Code für Blog-Beiträge, Kontaktformular-Logik, Analytics-Pipelines, Drittanbieter-Integrationen — wird die Homepage künstlich verlangsamt. Aktuelle Calvarius-Erfahrung aus der eigenen Optimierungs-Iteration: ein vermeintlich harmloser Import in der Site-weiten Navigations-Komponente zog die gesamte Blog-Pipeline mit Markdown-Parser, YAML-Bibliothek und allen vorgerenderten Beiträgen als statische Strings ins Haupt-Bundle. Das Resultat: 1,1 Megabyte JavaScript auf jeder Seite, auch wenn der Nutzer nie einen Blog-Beitrag öffnet. Saubere Code-Splitting-Architektur reduziert das auf 400 Kilobyte oder weniger — drei Viertel des Volumens werden lazy geladen, wenn sie tatsächlich gebraucht werden.
Drittens, unoptimierte Bild-Pipelines. Bilder sind statistisch der häufigste Performance-Hebel — und gleichzeitig der am häufigsten übersehene. Eine typische Marketing-Site lädt 1 bis 2 Megabyte Bilddaten beim ersten Aufruf der Homepage, weil Logos, Hero-Bilder und Sektion-Illustrationen ohne moderne Formate, ohne responsives srcSet, ohne Lazy-Loading ausgeliefert werden. Aus der Calvarius-Optimierung: 18 Logo-Bilder in der Marquee-Slider-Komponente lieferten über ein Megabyte Bilddaten, bei einer Anzeigegröße von 200 mal 72 Pixel und Original-Auflösungen von 1000 mal 500 — eine Fünffach-Überdimensionierung. WebP-Konvertierung plus srcSet plus Lazy-Loading reduziert das auf 80 bis 120 Kilobyte. Faktor zehn weniger, optisch nicht unterscheidbar.
Diese drei Anti-Patterns sind kumulativ. Sie wirken nicht einzeln, sondern verstärken sich gegenseitig. Eine Site mit clientseitigem Rendering plus monolithischem Bundle plus unoptimierten Bildern produziert LCP-Werte von 5 bis 10 Sekunden und Performance-Scores zwischen 30 und 50. Detail-Optimierung kann das nicht reparieren. Architektur-Korrektur kann es.
Performance als SEO-Disziplin — Googles Core Web Vitals im Ranking
Die direkte Korrelation zwischen Core Web Vitals und Google-Ranking ist seit 2021 durch das Page Experience Update Teil der offiziellen Ranking-Faktoren. Was sich seitdem verändert hat: Google misst strenger, wertet konsistenter, und die Gewichtung im Algorithmus ist gewachsen.
Aktuelle Studiendaten zeigen den wirtschaftlichen Effekt. Eine Vodafone-Studie aus 2024 dokumentierte: eine LCP-Verbesserung um 31 Prozent führte zu einer 15 Prozent besseren Lead-zu-Visit-Rate und 8 Prozent höheren Verkaufszahlen. Eine Deloitte-Google-Studie aus 2020 zeigte: eine Verbesserung der mobilen Ladezeit um nur 0,1 Sekunden steigerte Konversionsraten im Einzelhandel um 8,4 Prozent und den durchschnittlichen Bestellwert um 9,2 Prozent.
Die Daten zur Abbruch-Wahrscheinlichkeit sind ebenfalls eindeutig. Eine Pingdom-Analyse aus 2025 zeigte: 53 Prozent der mobilen Nutzer in den USA brechen ihren Besuch ab, wenn eine Seite länger als 3 Sekunden zum Reagieren braucht. Akamai-Daten dokumentieren: eine Zunahme der Ladezeit von 2 auf 3 Sekunden reduziert Konversionsraten um 7 Prozent. Bei mobilen Sites, die in 1 Sekunde laden, ist der Umsatz pro Nutzer 2,5-mal höher als bei Sites, die 5 Sekunden brauchen.
Diese Daten zeigen einen Mechanismus, der weit über das reine Google-Ranking hinausgeht. Performance wirkt auf das Ranking direkt, weil Google die Core Web Vitals als Signal nutzt — und indirekt, weil schnellere Sites niedrigere Bounce-Raten und höhere Engagement-Werte produzieren, die wiederum als Behavioral-Ranking-Signale wirken. Wer Performance optimiert, optimiert nicht ein Detail. Er optimiert die Grundlage seiner gesamten organischen Sichtbarkeit.
Barrierefreiheit ist kein Compliance-Thema. Sondern Reichweite.
Seit dem 28. Juni 2025 ist das Barrierefreiheitsstärkungsgesetz (BFSG) in Deutschland vollständig in Kraft. Es setzt die EU-Richtlinie 2019/882 — den European Accessibility Act — in nationales Recht um und verpflichtet Unternehmen, ihre digitalen Produkte und Dienstleistungen barrierefrei zu gestalten. Die rechtlichen Anforderungen orientieren sich an den WCAG 2.1 auf Level A und AA, mit dringender Empfehlung der strengeren WCAG 2.2.
Die Compliance-Pflicht ist real. Bei Verstößen drohen Bußgelder, Abmahnungen, Verbraucher-Klagen. Bestimmte Kleinstunternehmen mit weniger als 10 Mitarbeitern und unter 2 Millionen Euro Jahresumsatz sind von Teilen der Pflicht ausgenommen — die Online-Shop-Pflicht trifft aber praktisch alle B2C-Unternehmen.
Wichtiger als die Compliance ist aber das wirtschaftliche Argument. Etwa 15 bis 20 Prozent der Bevölkerung in industrialisierten Ländern haben Einschränkungen, die ohne Barrierefreiheit die Nutzung digitaler Angebote erschweren oder unmöglich machen — von dauerhaften Beeinträchtigungen wie Sehschwäche oder motorischen Einschränkungen bis zu situativen Einschränkungen wie der Bedienung eines Smartphones mit nur einer Hand. Wer auf Barrierefreiheit verzichtet, verzichtet auf bis zu einem Fünftel seiner potenziellen Reichweite.
Plus: barrierefreie Sites sind nachweislich besser indexierbar. Korrekte semantische HTML-Struktur, sinnvolle Alt-Texte, klare Heading-Hierarchien — das sind genau die Strukturen, die Google für das Verstehen von Inhalten nutzt. Barrierefreiheit ist nicht Cost-Center neben SEO. Sie ist Teil der SEO-Architektur.
Calvarius bringt seine Mandate-Sites methodisch in die WCAG-2.2-AA-Konformität — nicht als nachträglich aufgesetzte Schicht, sondern als integraler Teil der Bauentscheidungen. Touch-Target-Größen ab 48 Pixel, Farbkontraste über 4,5:1, semantische Heading-Struktur, vollständige Tastaturnavigation, ARIA-Attribute nur dort, wo HTML-Semantik nicht ausreicht. Diese Disziplin ist Teil jedes Calvarius-Mandates, nicht optionales Add-On.
Methodische Disziplin in der Optimierung — Lessons aus eigener Praxis
Die Calvarius-Site selbst war über mehrere Wochen Schauplatz einer methodischen Optimierungs-Iteration. Der Score begann bei 77, fiel zwischenzeitlich auf 68, stieg auf 89, schwankte zwischen 76 und 89 in mehreren Audits, und erreichte schließlich stabil 99. Diese Volatilität ist methodisch lehrreich, weil sie zeigt, wo typische Performance-Optimierung scheitert.
Vier Disziplin-Punkte haben sich als entscheidend herausgestellt — Punkte, die in jeder Calvarius-Mandate-Praxis seitdem als Standard gelten.
Erstens, incrementelle Vorgehensweise statt Multi-Maßnahmen-Stapel. Der Score-Verfall von 77 auf 68 entstand, als sechs Optimierungs-Maßnahmen gleichzeitig umgesetzt wurden — Schrift-Optimierung, CSS-Reorganisation, Slider-Refactor, Vendor-Chunks-Aufteilung, Bild-srcSet-Vorbereitung, Tree-Shaking-Audit. Als der Score fiel, war nicht zuzuordnen, welche der sechs Maßnahmen den Regress verursacht hatte. Die Konsequenz: blinder Rollback aller Maßnahmen, dann incrementelle Neu-Implementation. Eine Maßnahme, ein Audit, dann nächste Maßnahme. Diese Disziplin verlangsamt die einzelne Iteration, beschleunigt aber das Gesamt-Ergebnis substantiell.
Zweitens, Diagnose vor Eingriff cross-checken. In einer Diagnose-Runde wurde behauptet, die Slider-CSS-Komponente fehle komplett im Code. Tatsächlich existierte sie an einer anderen Stelle als gesucht — der ursprüngliche Suchbefehl hatte die Klassen-Namen nicht korrekt erfasst. Hätte die Optimierung blind auf die vermeintlich fehlende CSS reagiert und neue Klassen geschrieben, wären 140-Pixel-hohe Logo-Cards gegen 56-Pixel-Bare-Images getauscht worden — eine fundamentale Design-Änderung ohne Performance-Begründung. Die methodische Lektion: bei jeder Diagnose-Behauptung mit File-Inspektion gegenchecken, bevor Code-Eingriffe folgen.
Drittens, architektonische Beweisführung schlägt Score-Wert. Nach einer Bundle-Optimierung mit dynamic imports zeigte ein zwischenzeitlicher Audit einen Score-Verfall von 89 auf 77 — bei gleichzeitig verifizierter Bundle-Reduktion. Das Symptom-Profil — gleichzeitiger Anstieg von FCP und LCP bei kleinerem JavaScript-Volumen — war architektonisch unmöglich als Folge der Maßnahme. Die Diagnose: kalter Edge-Cache-Hit nach Deployment, ein Cloudflare-typisches Artefakt. Multi-Run-Median über 3 bis 5 Audits zeigte den stabilen Wert bei 89, nicht bei 77. Lighthouse-Streuung kann bei kalten CDN-Caches 15 oder mehr Punkte umfassen — Einzel-Werte sind methodisch nicht belastbar genug für Optimierungs-Entscheidungen.
Viertens, Image-Payload ist der häufigste Performance-Hebel. Die größte einzelne Verbesserung im gesamten Iterations-Verlauf kam nicht von JavaScript-Optimierung oder Render-Architektur — sondern von der WebP-Konvertierung der 18 Logo-Bilder im Marquee-Slider. 1.057 Kilobyte JPG-Payload wurden zu 80 bis 120 Kilobyte WebP-Payload, der Score sprang von 68 auf 89. In statistischen Auswertungen über viele Audits zeigt sich: Bild-Optimierung ist in 60 bis 70 Prozent der Fälle der größte Performance-Hebel — vor JS-Bundle-Größe, CSS-Optimierung oder Font-Loading. Wer Performance optimiert, muss zuerst die Bild-Pipeline prüfen.
Wirtschaftliche Bedeutung — was 99 vs. 75 für Conversion und Ranking bedeutet
Die Differenz zwischen einem Lighthouse-Score von 99 und einem von 75 ist nicht akademisch. Sie ist wirtschaftlich messbar — in Konversionsraten, in organischer Sichtbarkeit, in Bounce-Raten.
Drei wirtschaftliche Effekte sind quantifizierbar.
Direkter Konversions-Effekt. Die Amazon-Studie aus 2006 — seitdem über mehrere Jahrzehnte mehrfach von Walmart, Mobify, Trainline, Zalando bestätigt — zeigt: 100 Millisekunden schnellere Ladezeit erhöhen den Umsatz um 1 Prozent. Eine Site, die ihre LCP von 2,5 Sekunden auf 1,5 Sekunden reduziert, kann mit 8 bis 10 Prozent höherer Konversionsrate rechnen. Bei einem mittelständischen Online-Shop mit 2 Millionen Euro Jahresumsatz entspricht das 160.000 bis 200.000 Euro zusätzlichem Jahresumsatz, allein durch Performance-Optimierung.
Indirekter SEO-Effekt durch Behavioral Signals. Sites mit besseren Core Web Vitals haben niedrigere Bounce-Raten — die Bounce-Wahrscheinlichkeit steigt um 32 Prozent, wenn die Ladezeit von 1 auf 3 Sekunden wächst, und um 90 Prozent zwischen 1 und 5 Sekunden. Niedrigere Bounce-Raten und höhere Verweildauer sind Behavioral Signals, die Google in das Ranking einrechnet. Das ist ein selbstverstärkender Mechanismus: schnelle Site, bessere Nutzer-Signale, besseres Ranking, mehr Traffic, mehr Konversionen.
Direkter Ranking-Effekt durch Core Web Vitals. Bei wettbewerbsintensiven Suchanfragen, wo mehrere Anbieter ähnlich relevanten Content haben, entscheidet die Page Experience über die Reihenfolge in den Suchergebnissen. Eine Site mit grünen Core Web Vitals (LCP unter 2,5s, INP unter 200ms, CLS unter 0,1) hat strukturell bessere Ranking-Chancen als eine Site mit gelben Werten — bei sonst identischer Content-Qualität. Das ist nicht ein 1:1-Effekt, sondern eine Mit-Gewichtung im Algorithmus, die bei knappen Entscheidungen kippen kann.
Diese drei Effekte kumulieren sich. Eine Performance-Optimierung von Score 75 auf Score 99 ist nicht ein „Nice-to-have" — sie ist ein substantieller Hebel auf Umsatz, Sichtbarkeit und langfristige Wettbewerbsposition.
Was bei Calvarius-Mandaten anders ist
Performance-Optimierung wird in den meisten Agentur-Praxen als nachgelagerter Schritt behandelt: Site bauen, launchen, dann optimieren. Diese Reihenfolge ist methodisch der Kern des Problems. Architektonische Performance-Entscheidungen — Server-Side-Rendering, Code-Splitting-Strategie, Asset-Pipeline, Bild-Pipeline, Font-Loading — müssen am Anfang eines Projektes stehen, nicht am Ende.
Calvarius arbeitet methodisch anders. Drei Disziplinen sind in jedem Mandat Standard, nicht Add-On.
Performance-by-Design. Schon in der Architektur-Phase werden Bauentscheidungen unter Performance-Gesichtspunkten getroffen. Welches Framework? Welcher Hosting-Stack? Welche CDN-Strategie? Welche Bild-Pipeline? Diese Entscheidungen sind später kaum noch korrigierbar — und sie entscheiden über das Performance-Potenzial der gesamten Site. Calvarius wählt Stacks wie TanStack Start mit Full SSR, Cloudflare als Edge-Layer, vite-imagetools für die Bild-Pipeline, Variable Fonts mit korrekten Fallback-Metrics. Diese Entscheidungen werden vor dem ersten Pixel gemacht, nicht nach dem Launch.
Methodische Audit-Disziplin. Lighthouse-Audits werden nicht als Score-Spiel betrieben, sondern als methodische Diagnose. Multi-Run-Median statt Einzel-Werte. Incrementelle Optimierung mit Audit zwischen jeder Maßnahme. Architektonische Beweisführung bei unklaren Befunden. Diese Disziplin verhindert das in der Praxis sehr häufige Anti-Muster, dass Sites zwar in einem Audit-Lauf 95 zeigen, aber in der Praxis durch CDN-Volatilität, Edge-Cache-Effekte und reale Nutzer-Geräte deutlich schwächere Werte produzieren.
Barrierefreiheit als Architektur-Frage. Touch-Targets, Farbkontraste, semantische HTML-Struktur, Tastaturbedienbarkeit — das sind keine nachträglichen Korrekturen, sondern Design-System-Entscheidungen. Die Calvarius-Site setzt Touch-Targets standardmäßig auf 48 Pixel, nutzt eine zentrale ContactLink-Komponente für Telefon- und E-Mail-Links mit korrektem Padding, achtet auf semantische Heading-Struktur in jedem Pillar-Beitrag. WCAG 2.2 AA ist Standard, nicht Ziel.
Die wirtschaftliche Konsequenz: Calvarius-Mandate-Sites erreichen typische Lighthouse-Werte zwischen 90 und 99 in allen vier Dimensionen — nicht durch nachträglichen Audit-Optimierungs-Aufwand, sondern durch die Bauentscheidungen am Anfang. Das schließt langwierige und teure Nachoptimierungs-Phasen aus.
Praxis-Checkliste — sieben Punkte, die jeder Site-Betreiber prüfen sollte
Wer einen Lighthouse-Audit seiner eigenen Site fährt und ein orange- oder rot-dominiertes Donut-Chart sieht, kann mit folgenden sieben Prüf-Punkten einen ersten methodischen Überblick gewinnen.
Erstens, Server-Side-Rendering aktiv? View Source auf der Startseite. Wenn der HTML-Body praktisch leer ist und nur ein <div id="root"> enthält, läuft die Site clientseitig — das ist der größte Performance-Hebel. SSR oder Static Generation sind die strukturelle Antwort.
Zweitens, Bild-Pipeline optimiert? Network-Tab im Browser, Filter auf Bild-Requests. Gesamt-Übertragungsgröße aller Bilder bei Initial-Load berechnen. Wenn das über 500 Kilobyte liegt, ist Bild-Optimierung der wahrscheinlichste größte Hebel. WebP-Konvertierung, srcSet für responsive Auslieferung, Lazy-Loading für below-the-fold-Bilder.
Drittens, JavaScript-Bundle-Größe vertretbar? Im Network-Tab den größten JS-Bundle suchen. Für statische Marketing-Sites sollten 80 bis 150 Kilobyte gzip als Richtwert dienen. Über 300 Kilobyte gzip ist überdimensioniert. Diagnose über npx vite-bundle-visualizer oder ähnliche Tools — was steckt im Bundle?
Viertens, Fonts korrekt eingebunden? Google Fonts via fonts.googleapis.com produzieren Render-blocking Requests. Self-hosted Variable Fonts mit Preload und korrekten Fallback-Font-Metrics sind methodisch sauberer und schneller. Plus: separate Italic-Schriftschnitte einbinden, statt synthetische Italic über CSS-Slant zu rendern.
Fünftens, Cache-Header gesetzt? Self-hosted Assets — Fonts, Bilder, JS-Bundles — sollten Cache-Control: public, max-age=31536000, immutable Header bekommen. Lighthouse-Bericht „Effiziente Verweildauer im Cache verwenden" zeigt, wo Cache-Header fehlen. Cloudflare-Headers-File oder Server-Middleware lösen das in unter einer Stunde.
Sechstens, Touch-Targets prüfen? Auf Mobile alle interaktiven Elemente testen. Lighthouse-Barrierefreiheit zeigt unter „Berührungszielbereiche" konkret, wo Targets zu klein sind. 48 mal 48 Pixel ist die Lighthouse-Empfehlung, 24 mal 24 Pixel das WCAG-2.5.8-Minimum.
Siebtens, Multi-Run-Audit fahren. Einzelne Lighthouse-Werte sind nicht belastbar — Streuung zwischen Audits kann 15 oder mehr Punkte umfassen. Drei bis fünf Audits über pagespeed.web.dev mit jeweils 60 Sekunden Pause. Median nehmen, nicht Einzelwert. Wenn Streuung über 7 Punkte: Edge-Cache-Problem, separate Diagnose nötig.
Möchten Sie Ihre eigene Site prüfen?
Calvarius bietet einen kostenlosen Lighthouse-Live-Check an, der direkt über die Google PageSpeed Insights API läuft. Sie geben eine URL ein, das Tool fährt einen Audit und zeigt Ihnen die vier Lighthouse-Scores plus Core Web Vitals plus drei konkrete Verbesserungs-Hebel in unserer methodischen Einordnung — die gleichen Werte, die Sie zu Beginn dieses Beitrags für calvarius.com selbst gesehen haben, aber für Ihre Site.
→ Lighthouse-Live-Check starten
Dieser Beitrag ist Teil der Calvarius-Pillar-Reihe zu SEO und Web-Performance. Verwandte Beiträge: Lovable, TanStack Start und die SEO-Frage · FAQ-Schema nach Googles Mai-2026-Abschaffung.