Ein Lighthouse-Score von 100 bedeutet nicht, dass eine Website gut ist. Es bedeutet, dass Googles Audit-Tool an diesem Tag, zu dieser Zeit, unter diesen Bedingungen keine Punkte abzieht. Das ist ein Unterschied, den wir öfter machen sollten.
Trotzdem lohnt sich der Score als Orientierung - wenn man versteht, was dahintersteckt. Dieser Post erklärt, was Lighthouse wirklich misst, welche Metriken tatsächlich zählen, und warum ein 100er-Score ein Mittel ist, kein Ziel.
Was Lighthouse misst
Lighthouse besteht aus vier Kategorien: Performance, Accessibility, Best Practices und SEO. Jede wird separat bewertet, ein Gesamtergebnis gibt es nicht. Wer von "Lighthouse 100" spricht, meint meistens alle vier Kategorien auf 100 - oder zumindest die Performance-Kategorie.
Die Performance-Kategorie ist die technisch anspruchsvollste und die, die am direktesten mit dem Nutzererlebnis zusammenhängt. Hier steckt der größte Hebel.
Die drei Metriken, die wirklich zählen
LCP - Largest Contentful Paint: Wie lange dauert es, bis das größte sichtbare Element der Seite geladen ist? Meistens ist das ein Hero-Bild, ein großer Textblock oder ein Video-Thumbnail. Google empfiehlt unter 2,5 Sekunden. Über 4 Sekunden gilt als schlecht.
Für LCP entscheidend: Das LCP-Element sollte so früh wie möglich im HTML stehen, sollte loading="eager" haben (nicht lazy!), und das Bild sollte in einem modernen Format wie WebP oder AVIF vorliegen. Wer sein LCP-Bild lazy lädt, hat ein Problem gebaut, das völlig unnötig ist.
CLS - Cumulative Layout Shift: Wie viel verschiebt sich das Layout beim Laden? Wenn Text erscheint, dann ein Bild nachlädt und alles nach unten schiebt - das ist CLS. Für Nutzer ist das frustrierend und lässt einen im schlimmsten Fall auf den falschen Link klicken. Google misst das akkumuliert über den gesamten Seitenbesuch.
CLS entsteht oft durch Bilder und Videos ohne definierte Dimensionen, durch dynamisch eingebettete Inhalte (Ads, Social-Embeds), und durch Webfonts, die spät laden und die Textbreite verändern.
FCP - First Contentful Paint: Wann erscheint das erste sichtbare Element überhaupt? FCP ist der Moment, in dem der Nutzer merkt, dass die Seite lädt. Je kürzer, desto besser - und je länger der Server braucht zu antworten, desto schlechter wird dieser Wert.
Das Fonts-Problem
Google Fonts ist praktisch. Aber es ist ein Datenschutzproblem (jede Anfrage geht an Google-Server und enthält die IP-Adresse des Nutzers) und ein Performance-Problem. Externe Font-Anfragen blockieren oder verzögern das Rendering - selbst mit font-display:swap.
Die Lösung ist direkt: Fonts lokal hosten. WOFF2-Dateien selbst ablegen und per @font-face einbinden. Das beseitigt die externe Abhängigkeit vollständig und eliminiert einen Netzwerk-Roundtrip beim ersten Laden.
Aber selbst lokale Fonts können CLS verursachen, wenn der Browser zuerst einen Systemfont anzeigt und dann auf den geladenen Custom-Font wechselt. Hier kommen metrisch angeglichene Fallback-Fonts ins Spiel.
Metrisch angeglichene Fallback-Fonts
Die Idee dahinter ist elegant: Statt dem Browser zu erlauben, ein beliebiges Arial als Fallback zu nutzen, passen wir den Fallback so an, dass er fast identische Zeichenbreiten, Zeilenhöhen und Abstände hat wie der eigentliche Custom-Font. Wenn der Custom-Font dann lädt, springt nichts - weil der Fallback schon fast gleich aussieht.
Das funktioniert über CSS-Eigenschaften wie size-adjust, ascent-override, descent-override und line-gap-override. Diese Werte berechnet man einmalig - entweder mit Tools wie fontpie oder capsize - und bindet sie in eine separate @font-face-Regel mit src:local("Arial") ein.
Das Ergebnis: kein sichtbarer Sprung beim Font-Wechsel, besserer CLS-Wert, und der Nutzer bemerkt vom Font-Loading kaum noch etwas. Die Fonts für diese Website sind genau so konfiguriert.
font-display: swap - richtig verstehen
font-display:swap bedeutet: Zeig zuerst einen Fallback-Font, dann tausche ihn gegen den Custom-Font aus. Das verhindert unsichtbaren Text (FOIT - Flash of Invisible Text), erzeugt aber möglicherweise einen sichtbaren Tausch (FOUT - Flash of Unstyled Text).
In Kombination mit metrisch angeglichenen Fallbacks ist FOUT kaum noch wahrnehmbar. Die Kombination aus font-display:swap und sorgfältig kalibriertem Fallback-Font ist deshalb der Stand der Technik für performante Websites.
Lazy Loading: wo es hilft und wo nicht
Lazy Loading für Bilder ist sinnvoll - für Bilder, die unterhalb der sichtbaren Fläche liegen. Für alles, was above the fold ist, ist es kontraproduktiv.
Ein häufiger Fehler: alle Bilder bekommen pauschal loading="lazy", auch das Hero-Bild. Das verzögert LCP deutlich, weil der Browser erst die Seite parsen muss, bevor er weiß, welche Bilder er dringend braucht.
Die Regel ist einfach: Das LCP-Element bekommt immer loading="eager" (oder gar kein loading-Attribut, was dasselbe ist). Alles, was sicher unter dem sichtbaren Bereich liegt, kann loading="lazy" bekommen.
Keine externen Tracking-Scripts
Google Analytics, Facebook Pixel, Hotjar, Intercom - jedes dieser Scripts fügt externe Anfragen hinzu, kann die Seite verlangsamen, und erzeugt Datenschutzfragen. Nicht jedes dieser Tools ist zwingend notwendig, und viele werden eingebunden, weil "man das so macht", nicht weil die Daten aktiv genutzt werden.
Wer Daten erfassen will, ohne Performance zu opfern, kann auf selbst gehostete Lösungen wie Plausible, Umami oder Fathom setzen. Sie liefern die wichtigsten Metriken, blockieren nicht, und schicken keine Daten an Dritte. Google Tag Manager ist übrigens kein Allheilmittel: Er verzögert das Laden der Scripts, löst aber das Grundproblem nicht.
Accessibility: mehr als ARIA
Lighthouse prüft Accessibility mit automatisierten Tests und findet dabei schätzungsweise 30 bis 40 Prozent aller tatsächlichen Probleme. Ein 100er Accessibility-Score bedeutet also nicht, dass die Seite für alle Nutzer zugänglich ist.
Was Lighthouse prüft: Kontrastverhältnisse, Alt-Texte, Formular-Labels, ARIA-Attribute, grobe Tastaturnavigation. Was es nicht prüft: ob die Screenreader-Erfahrung wirklich gut ist, ob komplexe Interaktionsmuster funktionieren, ob die Sprache und Struktur verständlich sind.
Der 100er Score ist der Mindeststandard. Echte Barrierefreiheit erfordert manuelle Tests - am besten mit Screenreadern und echten Nutzern aus der Zielgruppe.
Warum Performance konvertiert
Google hat das mehrfach dokumentiert: Jede Sekunde Ladezeit kostet Conversion. Für E-Commerce gilt als Faustregel: eine Sekunde mehr Ladezeit bedeutet rund 7 Prozent weniger Conversion Rate. Das gilt auch für Landingpages, Kontaktseiten und Blog-Posts.
Schnelle Seiten ranken besser (Googles Core Web Vitals sind ein Ranking-Faktor), sie konvertieren besser, und sie wirken professioneller. Ein Nutzer, der eine Seite schnell und flüssig erlebt, nimmt das Unternehmen dahinter unbewusst als kompetenter wahr - auch wenn er das nicht explizit so formulieren würde.
Wir haben das in eigenen Projekten immer wieder beobachtet: Eine technisch saubere Seite hinterlässt einen anderen Eindruck als eine langsame - selbst wenn der Inhalt identisch ist.
Lighthouse 100 ist Hygiene, kein Qualitätsbeweis
Lighthouse 100 zu erreichen ist kein Hexenwerk, wenn man die richtigen Entscheidungen früh trifft: lokale Fonts, metrisch angeglichene Fallbacks, keine externen Tracking-Scripts, korrekte Bildoptimierung, kein pauschales Lazy Loading.
Aber Lighthouse 100 ist kein Qualitätsnachweis. Er ist ein Hygiene-Standard. Die eigentliche Frage ist: Löst die Website das Problem des Nutzers? Ist sie verständlich? Vertrauen weckend? Führt sie zu einer Handlung? Das misst kein automatisches Tool.
Wir bauen Websites, die beides können: technisch sauber und inhaltlich stark. Der Score ist das Fundament - nicht das Gebäude.
