Google Lighthouse Test: Website Performance messen und den Score verbessern

Ein Lighthouse Test ist oft das Erste, was mir Kunden im Erstgespräch zeigen. Jemand hat PageSpeed Insights geöffnet, eine rote 41 auf dem Smartphone gesehen und möchte bis Freitag eine grüne Zahl. Das verstehe ich gut, denn eine rote Zahl wirkt bedrohlich. Allerdings führt ein Score ohne Kontext fast immer zu den falschen Maßnahmen in der falschen Reihenfolge. In diesem Leitfaden zeige ich Ihnen, wie Sie den Test sauber durchführen, den Bericht lesen und die wichtigsten Empfehlungen umsetzen.

Was ist ein Lighthouse Test und was misst er?

Ein Lighthouse Test ist eine Labormessung, bei der das quelloffene Google Tool Lighthouse eine Seite unter festen, gedrosselten Bedingungen lädt und anhand von fünf Metriken mit 0 bis 100 Punkten bewertet. Das Ergebnis zeigt einen simulierten Seitenaufruf, nicht das Erlebnis Ihrer echten Besucher.

Die fünf Metriken heißen First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time und Cumulative Layout Shift. Zunächst bekommt jede Metrik eine eigene Punktzahl. Danach bildet Lighthouse daraus einen gewichteten Durchschnitt, und genau diese Zahl steht groß oben im Bericht.

Zusätzlich prüft Lighthouse drei weitere Kategorien: Barrierefreiheit, Best Practices und SEO. Dieser Leitfaden konzentriert sich auf die Performance, denn dort verlieren die meisten Teams ihre Zeit. Außerdem bewertet Lighthouse nicht nur, sondern nennt zu jedem Problem die betroffenen Dateien und eine geschätzte Ersparnis. Lesen Sie den Bericht deshalb wie einen ärztlichen Befund und nicht wie ein Zeugnis. Ein Zeugnis sagt nur, ob Sie bestanden haben. Ein Befund zeigt, wo es wehtut und warum.

Worin unterscheiden sich Lighthouse und PageSpeed Insights?

Beide nutzen dieselbe Engine, also liefern sie im Kern dieselben Messungen. Der Unterschied liegt darin, wo der Test läuft und welche Daten dazukommen. Lighthouse läuft auf Ihrem eigenen Rechner in den Chrome DevTools, über die Kommandozeile oder über Lighthouse CI. PageSpeed Insights startet Lighthouse dagegen auf Servern von Google und ergänzt echte Nutzerdaten aus dem Chrome User Experience Report (CrUX).

In der Praxis nutze ich beide. Zunächst prüfe ich in PageSpeed Insights die Felddaten der Live Seite. Dann stelle ich das Problem lokal in den DevTools nach, weil ich dort Code ändern und sofort erneut messen kann.

Ein Hinweis noch: Vergleichen Sie Werte nie zwischen verschiedenen Tools. PageSpeed Insights simuliert ein Smartphone der Mittelklasse in einem gedrosselten Mobilfunknetz. Die DevTools drosseln ähnlich, trotzdem beeinflusst Ihr eigener Prozessor das Ergebnis. Vergleichen Sie also immer mit demselben Tool, denselben Einstellungen und demselben Gerät.

Warum weichen Labordaten und Felddaten voneinander ab?

Labordaten stammen aus einem simulierten Gerät mit einer simulierten Verbindung. Felddaten stammen von echten Chrome Nutzern, die der Übermittlung von Nutzungsstatistiken zugestimmt haben. Laut der Dokumentation von PageSpeed Insights decken Felddaten die letzten 28 Tage ab, und Google bewertet sie am 75. Perzentil.

Deshalb erzählen beide Quellen manchmal unterschiedliche Geschichten über dieselbe URL. Ihr LCP im Labor wirkt langsam, im Feld aber gut, weil die meisten Besucher aktuelle Smartphones im schnellen WLAN nutzen. Das Gegenteil kommt ebenfalls vor. Zum Beispiel sieht der Labortest sauber aus, während die INP im Feld schlecht ist, denn im Labor klickt niemand auf einen Button.

Welcher Quelle sollten Sie also vertrauen? Für Entscheidungen zählen die Felddaten, weil sie das echte Erlebnis abbilden. Für die Fehlersuche zählen die Labordaten, denn Sie sehen das Ergebnis sofort. Bedenken Sie zudem: Felddaten brauchen Zeit. Nach einer Korrektur muss das 28 Tage Fenster erst durchlaufen, bevor die Verbesserung vollständig sichtbar ist. Seiten mit wenig Traffic haben außerdem oft gar keine Felddaten. Dann bleibt Ihnen nur das Laborergebnis.

Welche Wege gibt es, einen Lighthouse Test durchzuführen?

Sie haben vier Möglichkeiten. Welche passt, hängt davon ab, wer testet und wie oft:

• PageSpeed Insights: Sie fügen eine URL ein und lesen das Ergebnis im Browser. Es gibt nichts zu installieren, daher eignet sich dieser Weg für Marketing und Geschäftsführung.
• Chrome DevTools: Sie öffnen die DevTools, wechseln in den Bereich Lighthouse und erstellen einen Bericht. Das funktioniert auch in Testumgebungen und hinter einem Login.
• Kommandozeile: Mit dem Befehl "npm install -g lighthouse" installieren Sie das Paket und messen beliebige URLs. So lassen sich wiederholte Messungen bequem automatisieren.
• Lighthouse CI: Das Tool läuft bei jedem Deployment und stoppt die Veröffentlichung, wenn eine Metrik unter Ihr Budget fällt.

Für eine kleine Unternehmenswebsite reichen die ersten beiden Wege. Veröffentlicht Ihr Team allerdings mehrmals pro Woche Änderungen im Shop, brauchen Sie die Kommandozeile oder Lighthouse CI. Sonst rutschen Verschlechterungen unbemerkt durch, bis der Umsatz sinkt.

Wie führen Sie den Test Schritt für Schritt in den Chrome DevTools aus?

Die DevTools geben Ihnen die meiste Kontrolle. Diese Routine nutze ich in jedem Projekt:

1. Öffnen Sie Chrome im Inkognito Fenster. Erweiterungen verfälschen Ergebnisse, und der Inkognito Modus schaltet die meisten ab.
2. Laden Sie die Zielseite, drücken Sie F12 und öffnen Sie den Bereich Lighthouse.
3. Wählen Sie den Modus Navigation. Er misst den ersten Seitenaufruf.
4. Wählen Sie zuerst Mobile, denn Google nutzt für die Indexierung die mobile Version.
5. Aktivieren Sie nur die Kategorie Performance. So läuft der Test schneller.
6. Klicken Sie auf "Analyze page load" und nutzen Sie den Tab bis zum Ende nicht.
7. Wiederholen Sie die Messung mindestens dreimal und notieren Sie den Median.

Speichern Sie außerdem jeden Lighthouse Test als JSON oder HTML. Nach einer Korrektur legen Sie dann beide Berichte nebeneinander und sehen genau, was sich verändert hat. Auch der Modus Timespan ist nützlich. Er zeichnet auf, was passiert, während Sie durch die Seite klicken, und hilft deshalb bei der Suche nach Problemen mit der Interaktion.

Wie berechnet Lighthouse den Performance Score?

Der Score im Lighthouse Test ist ein gewichteter Durchschnitt aus fünf Metriken. Der Leitfaden von Chrome for Developers nennt die aktuellen Gewichte:

• Total Blocking Time: 30 Prozent.
• Largest Contentful Paint: 25 Prozent.
• Cumulative Layout Shift: 25 Prozent.
• First Contentful Paint: 10 Prozent.
• Speed Index: 10 Prozent.

Jeder Rohwert landet auf einer Bewertungskurve, die Google aus echten Websitedaten des HTTP Archive ableitet. Derselbe Leitfaden definiert auch die Farben. Ein Wert von 0 bis 49 ist rot, 50 bis 89 ist orange und 90 bis 100 ist grün.

Die praktische Lehre daraus ist einfach. Drei Metriken tragen 80 Prozent des Scores. Anders gesagt: Ohne bessere Werte bei TBT, LCP und CLS steigt der Score nicht dauerhaft. Zudem verläuft die Kurve nicht linear. Der Sprung von 50 auf 70 gelingt meist schnell. Von 90 auf 100 kostet dagegen oft unverhältnismäßig viel Arbeit.

Warum schwankt der Score bei jeder Messung?

Wenn Sie dieselbe Seite zweimal per Lighthouse Test messen und erst 71, dann 78 sehen, ist das normal. Der Leitfaden von Chrome nennt die üblichen Gründe: A/B Tests, wechselnde Werbeanzeigen, Änderungen im Internetrouting, unterschiedliche Geräte, Browsererweiterungen und Antivirensoftware.

In meiner Arbeit sind die Ursachen oft banaler. Zum Beispiel ist der Server gerade ausgelastet. Der Seitencache ist noch nicht warm. Externe Skripte antworten bei jedem Aufruf unterschiedlich schnell. Und Programme im Hintergrund konkurrieren auf dem Testrechner um den Prozessor.

Deshalb entscheide ich nie auf Basis einer einzigen Messung. Meine Regel lautet: mindestens drei, besser fünf Durchläufe unter gleichen Bedingungen und dann den Median notieren. Wenn ich den Effekt einer Änderung messe, teste ich vorher und nachher am selben Tag, im selben Netz und auf demselben Gerät. So erkennen Sie, ob der Unterschied von Ihrer Korrektur stammt oder nur Rauschen ist. Unterschiede unter fünf Punkten behandle ich als Rauschen. Diese Schwelle ist eine Faustregel aus der Praxis, keine Garantie.

Wie lesen Sie den Bericht eines Lighthouse Tests richtig?

Lesen Sie den Bericht nach Wichtigkeit, nicht von oben nach unten. Beginnen Sie mit dem Abschnitt Metrics. Welche der fünf Metriken sind rot oder orange? Diese Tabelle verrät Ihnen mehr als der Gesamtscore, denn sie zeigt die Art des Problems.

Danach wechseln Sie zum Abschnitt Insights. Mit Lighthouse 13 hat Google viele ältere Audits mit den Insights aus dem Performance Bereich der DevTools zusammengeführt. Zum Beispiel erscheinen einzelne Hinweise zu Bildformat, Komprimierung und Bildgröße jetzt gemeinsam unter "Improve image delivery". Jeder Insight nennt eine geschätzte Ersparnis und die betroffenen Ressourcen.

Anschließend prüfen Sie die Diagnostics. Diese Punkte verändern den Score nicht direkt, erklären aber die Ursache: Last auf dem Hauptthread, Größe des DOM, Cachedauer und ähnliche Details. Den Bereich Passed audits können Sie beim ersten Lesen überspringen.

Schließlich hilft der Filter "Show audits relevant to". Klicken Sie auf LCP, dann zeigt der Bericht nur Punkte, die den LCP beeinflussen. So finden Sie den größten Hebel, ohne in Warnungen zu versinken.

Was tun Sie, wenn der LCP zu langsam ist?

Der LCP markiert den Moment, in dem das größte sichtbare Element erscheint. Als gut gilt ein Wert bis 2,5 Sekunden. Auf Unternehmensseiten ist dieses Element meist ein großes Titelbild, die erste Folie eines Sliders oder eine große Überschrift. Der Insight "LCP breakdown" teilt die Zeit in vier Teile: Serverantwort, Verzögerung bis zum Laden der Ressource, Ladedauer der Ressource und Verzögerung bis zur Darstellung.

Der größte Teil zeigt Ihnen dann die Lösung. Diese drei Fälle sehe ich am häufigsten:

• Der Browser entdeckt das Bild zu spät. Ein CSS Hintergrund oder ein JavaScript Slider versteckt das Bild. Nutzen Sie stattdessen ein normales img Tag und ergänzen Sie fetchpriority="high".
• Das Titelbild nutzt Lazy Loading. Das Attribut loading="lazy" verzögert bei einem Bild im sichtbaren Bereich direkt den LCP. Setzen Sie es nur bei Bildern weiter unten ein.
• Die Datei ist viel zu groß. Ein Foto mit 3000 Pixeln Breite in einem Bereich mit 400 Pixeln verschwendet Bandbreite. Verkleinern Sie es und wandeln Sie es in WebP oder AVIF um.

Für schnelle Korrekturen hilft der Bildverkleinerer. Dauerhaft löst das Problem allerdings nur ein System, das Bilder beim Hochladen automatisch anpasst.

Warum ist die Total Blocking Time so hoch?

Die TBT summiert die Zeit während des Ladens, in der lange Aufgaben den Hauptthread jeweils länger als 50 Millisekunden blockieren. In diesen Momenten reagiert der Browser nicht auf Klicks. Mit 30 Prozent Gewicht ist sie die einflussreichste Einzelmetrik im Score.

Die Ursache ist fast immer JavaScript. Page Builder, schwere Themes, Chatfenster, Consent Banner und mehrere Analyse Tags konkurrieren um denselben Thread. Zum Beispiel finde ich oft ein Formular Plugin in WordPress, das auf jeder Seite lädt, obwohl es nur auf der Kontaktseite ein Formular gibt.

Meine Reihenfolge ist klar. Zuerst entferne ich Skripte, die niemand nutzt. Dann lade ich die übrigen mit defer oder async. Danach lade ich schwere Komponenten erst, wenn Nutzer mit ihnen interagieren. Die Punkte "Reduce JavaScript execution time" und "Minimize main thread work" zeigen, welche Dateien am meisten Zeit kosten.

Noch ein wichtiger Punkt: Im Modus Navigation kann Lighthouse die INP nicht messen, denn niemand interagiert mit der Seite. Deshalb dient die TBT im Labor als Ersatzgröße für die Reaktionsfähigkeit. Sinkt die TBT, verbessert sich meist auch die INP im Feld.

Wie beheben Sie Layoutverschiebungen und einen hohen CLS?

Der CLS misst, wie stark sich sichtbare Inhalte während des Ladens unerwartet verschieben. Als gut gilt ein Wert bis 0,1. Jeder kennt den Moment, in dem ein Button genau beim Tippen wegspringt. Das frustriert Nutzer und führt zudem zu falschen Klicks.

Der Insight "Layout shift culprits" nennt die verantwortlichen Elemente. Das sind die typischen Ursachen und Lösungen:

• Bilder ohne Maße: Geben Sie im img Tag width und height an oder legen Sie das Seitenverhältnis per CSS fest.
• Spät geladene Anzeigen und Einbettungen: Reservieren Sie vorab einen festen Platz dafür.
• Webfonts, die spät ankommen: Prüfen Sie die Einstellung zur Schriftanzeige und wählen Sie eine Ersatzschrift mit ähnlichen Maßen.
• Consent Banner und Hinweisleisten, die Inhalte nach unten schieben: Blenden Sie diese stattdessen fest positioniert über dem Inhalt ein.

Unterschätzen Sie den Consent Banner nicht. Gerade in Deutschland hat fast jede Website einen, und bei vielen geprüften Seiten verursachte er allein den Großteil des CLS. Die Lösung bestand dann meist aus wenigen Zeilen CSS.

Wie setzen Sie die Empfehlungen zur Bildauslieferung um?

In Lighthouse 13 stehen alle Bildhinweise im Insight "Improve image delivery". Er prüft drei Dinge. Ist das Format modern? Ist die Komprimierung ausreichend? Passt die Dateigröße zum Platz auf dem Bildschirm?

Die Lösung hat daher drei Schritte. Erstens wandeln Sie JPEG und PNG in WebP oder AVIF um; alle aktuellen Browser unterstützen WebP. Zweitens senken Sie die Qualität auf ein Niveau, das niemand bemerkt. Drittens nutzen Sie srcset, damit jede Bildschirmgröße eine passende Datei lädt und Smartphones keine Desktopbilder herunterladen.

Statt das von Hand zu erledigen, bauen Sie besser ein System auf. In WordPress übernimmt das ein Plugin zur Bildoptimierung. Bei individueller Software erledigt eine Bildpipeline die Anpassung direkt beim Hochladen. Ich richte diese Pipeline in jedem Webdesign Projekt am ersten Tag ein, weil Redaktionen das manuelle Verkleinern nach wenigen Monaten aufgeben. Bei Shops mit Tausenden Produktfotos ist das Thema noch wichtiger. Es gehört zu den ersten Punkten, die ich in der E-Commerce Beratung prüfe.

Wie beeinflussen Webfonts und Caching den Score?

Markenschriften sind den meisten Unternehmen wichtig. Allerdings ist jede Schriftstärke eine eigene Datei. Ein Theme mit zwei Schriftfamilien in je vier Stärken lädt beim ersten Aufruf schnell acht Fontdateien. Der Insight "Font display" markiert Fälle, in denen Text unsichtbar bleibt, bis die Schrift ankommt.

Mein Rat: Reduzieren Sie die Zahl der Schriftstärken auf zwei oder drei, hosten Sie die Fonts selbst im Format WOFF2 und stellen Sie die Schriftanzeige auf swap oder optional. So erscheint Text sofort in einer Ersatzschrift und wechselt, sobald die Markenschrift bereit ist. Das lokale Hosten hat in Deutschland zudem einen rechtlichen Hintergrund, denn das Landgericht München I hat im Januar 2022 die dynamische Einbindung von Google Fonts ohne Einwilligung beanstandet.

Beim Caching zeigt der Insight "Use efficient cache lifetimes" Dateien, die der Browser bei jedem Besuch neu lädt. Geben Sie CSS, JavaScript, Bildern und Fonts eine lange Cachedauer und hängen Sie eine Versionsnummer an den Dateinamen. Das verändert den Score für den ersten Aufruf kaum. Trotzdem wirkt die Website für alle, die mehrere Seiten besuchen, deutlich schneller.

Prüfen Sie schließlich, ob Brotli oder Gzip auf dem Server aktiv ist. Bei älteren Hostingpaketen finde ich die Komprimierung noch immer abgeschaltet.

Wie entfernen Sie blockierende Ressourcen und ungenutzten Code?

Der Browser zeichnet nichts, bevor er das CSS und das synchrone JavaScript im Kopf der Seite geladen und verarbeitet hat. Der Insight "Render blocking requests" listet diese Dateien und die mögliche Zeitersparnis auf.

Gehen Sie so vor. Zunächst trennen Sie das kritische CSS für den ersten Bildschirm ab, binden es direkt im HTML ein und laden den Rest später. Dann ergänzen Sie bei Skripten das Attribut defer; so lädt das Skript, ohne die Darstellung aufzuhalten. Danach prüfen Sie "Reduce unused JavaScript" und "Reduce unused CSS". Bei gekauften Themes bleibt oft der größte Teil des Stylesheets auf einer bestimmten Seite ungenutzt.

Seien Sie hier allerdings vorsichtig. Trennen Sie das kritische CSS falsch ab, blitzt die Seite kurz ohne Gestaltung auf, und das stört das Erlebnis. Prüfen Sie deshalb nach jeder Änderung die Seite mit Ihren eigenen Augen bei langsamer Verbindung. Der Bereich Coverage in den DevTools zeigt Zeile für Zeile, welcher Code tatsächlich läuft. Er ist ein guter Startpunkt für das Aufräumen.

Wie wirken sich externe Skripte auf den Score aus?

Externe Skripte laden von fremden Domains: Analyse Tags, Werbepixel, Chattools, Karten, Videoeinbettungen und Bewertungswidgets. Der Insight "3rd parties" zeigt für jedes Skript die Übertragungsgröße und die Zeit auf dem Hauptthread.

Das Marketing braucht viele dieser Skripte, also ist Löschen keine Lösung. Stellen Sie stattdessen zu jedem Tag eine Frage: Welche Entscheidung stützt diese Messung heute? Heatmap Skripte, die seit Jahren niemand öffnet, Pixel für längst beendete Werbekonten und doppelt geladene Analysecodes sind die Reste, die ich am häufigsten finde.

Für die verbleibenden Skripte ändern Sie den Zeitpunkt. Laden Sie das Chatfenster erst nach der ersten Interaktion. Zeigen Sie statt eines YouTube Players zuerst ein Vorschaubild, das den Player erst per Klick lädt. Nutzen Sie statt einer interaktiven Karte ein statisches Bild mit Link. Das hat in Deutschland einen doppelten Vorteil, denn viele dieser Dienste brauchen ohnehin eine Einwilligung. Somit behalten Sie Ihre Messung und senken die Last beim ersten Laden deutlich. Wenn Sie den Google Tag Manager nutzen, prüfen Sie außerdem die Trigger.

Warum beeinflusst die Antwortzeit des Servers den Score?

Schickt der Server das erste Byte spät, startet alles Weitere ebenfalls spät. Die Dokumentation von PageSpeed Insights nennt für die Time to First Byte 800 Millisekunden als guten Wert. In Lighthouse 13 finden Sie das Thema im Insight "Document request latency", der Weiterleitungen, Serverzeit und Komprimierung gemeinsam betrachtet.

Typische Ursachen sind vor allem schwaches Shared Hosting, fehlender Seitencache, eine veraltete PHP Version, langsame Datenbankabfragen und Ketten von Weiterleitungen. Konkret kostet eine Kette von http zu https, dann zu www und schließlich zur URL mit Schrägstrich am Ende Hunderte Millisekunden, bevor Besucher überhaupt etwas sehen.

Solche Ketten erkennen Sie schnell mit dem Redirect Checker. Auf Serverseite bringen Seitencache, eine aktuelle PHP Version und ein CDN für die meisten Unternehmensseiten genug Verbesserung. Planen Sie einen Umzug, gehören diese Einstellungen auf Ihre Checkliste. Den größeren Rahmen beschreibe ich im Beitrag SEO beim Website Relaunch schützen.

Was sagen die Kategorien Barrierefreiheit, Best Practices und SEO aus?

Die drei Kategorien außerhalb der Performance prüfen die technische Grundhygiene. Beachten Sie, dass Lighthouse 12 die Kategorie PWA entfernt hat. Ältere Anleitungen mit einem fünften Kreis sind daher überholt.

Die Barrierefreiheit prüft zum Beispiel Farbkontraste, Alternativtexte, Formularbeschriftungen und die Reihenfolge der Überschriften. Das ist nicht nur Kosmetik, denn für viele Onlineangebote gilt seit Juni 2025 das Barrierefreiheitsstärkungsgesetz. Best Practices umfasst HTTPS, Fehler in der Konsole, unsichere Bibliotheken und korrekte Seitenverhältnisse von Bildern. SEO prüft die Grundlagen: Title und Meta Description, Indexierbarkeit, aussagekräftige Linktexte und eine gültige robots.txt.

Fehlende Tags erstellen Sie mit dem Meta Tag Generator, eine saubere Datei mit dem robots.txt Generator. Ein perfekter SEO Wert in Lighthouse bedeutet allerdings keine guten Rankings. Die Kategorie bestätigt nur, dass nichts Technisches die Seite blockiert. Über Inhaltsqualität, Suchintention oder Autorität sagt sie nichts. Für eine breitere technische Prüfung lesen Sie meinen Beitrag zu technischem SEO nach der KI Wende.

Wie priorisieren Sie Maßnahmen nach einem Lighthouse Test?

Ein Lighthouse Test liefert oft Dutzende Empfehlungen, und nicht alle sind gleich wichtig. Die Reihenfolge lege ich mit drei Fragen fest. Welche Metrik betrifft der Punkt? Wie groß ist die geschätzte Ersparnis? Wie viel Aufwand kostet die Korrektur?

Diese Reihenfolge funktioniert für die meisten Websites:

1. Suchen Sie die Metrik, die in den Felddaten rot ist, und beginnen Sie dort.
2. Nehmen Sie die günstigen, großen Gewinne mit: falsches Lazy Loading, Bilder ohne Maße, ungenutzte Skripte.
3. Korrigieren Sie Server und Cache, denn das hilft allen Seiten gleichzeitig.
4. Reduzieren Sie dann das JavaScript aus Themes und Plugins.
5. Heben Sie Architekturfragen für den Schluss auf: neues Theme, Neuentwicklung oder Plattformwechsel.

Denken Sie außerdem in Vorlagen statt in Einzelseiten. Eine Korrektur an der Vorlage für Produktseiten verbessert Hunderte URLs gleichzeitig. Testen Sie deshalb je ein Beispiel von Startseite, Kategorieseite, Produkt oder Leistungsseite und Blogbeitrag. Wie ich Vorlagen auf größeren Websites gruppiere, erkläre ich im Beitrag zur Kategoriestruktur für große Websites.

Muss der Score im Lighthouse Test bei 100 liegen?

Nein. Der Score ist ein Indikator, kein Ziel. Die Dokumentation von Google Search Central zu Core Web Vitals empfiehlt gute Werte und stützt sich dabei auf echte Nutzerdaten. Der Laborscore von Lighthouse selbst ist nicht das, worauf die Suche schaut.

In der Praxis sehe ich Folgendes, weil ich solche Projekte regelmäßig begleite. Steigt der mobile Score von 65 auf 85, spüren Nutzer den Unterschied. Steigt er von 92 auf 99, müssen Sie oft auf ein Analyse Tag, ein Chattool oder einen gewünschten visuellen Effekt verzichten. Ob sich dieser Tausch geschäftlich lohnt, ist eine eigene Entscheidung.

Mein Zielvorschlag lautet: alle drei Core Web Vitals im Feld grün und ein mobiler Laborscore möglichst über 70. Betrachten Sie diesen Bereich als Startpunkt aus der Praxis, nicht als Garantie. Sind Sie deutlich langsamer als Ihre Wettbewerber, hat Geschwindigkeit klar Vorrang. Sind Sie dagegen schon schnell, bringen Arbeit an Inhalten und Conversion mehr als ein paar zusätzliche Punkte. Wenn Sie unsicher sind, wo Sie ansetzen sollen, finden wir diese Balance gemeinsam in einer SEO Beratung.

Wie messen und sichern Sie Ihre Verbesserungen?

Arbeit an der Geschwindigkeit ist nie abgeschlossen. Denn ein neues Plugin, ein neues Kampagnenpixel oder ein schweres Banner machen Erfolge oft innerhalb weniger Wochen zunichte. Machen Sie die Messung daher zur Gewohnheit.

Deshalb arbeite ich mit drei Ebenen. Die erste ist der Bericht zu Core Web Vitals in der Search Console. Er gruppiert URLs nach ihrem Status im Feld und erlaubt Ihnen, nach einer Korrektur eine Validierung zu starten. Die zweite ist eine monatliche Prüfung in PageSpeed Insights, bei der ich die wichtigsten Vorlagen am selben Tag teste und die Werte in einer Tabelle festhalte. Die dritte ist Lighthouse CI mit einem Performance Budget für Websites, die häufig veröffentlichen.

Führen Sie zudem ein Änderungsprotokoll. Notieren Sie konkret das Datum jedes neuen Plugins, jedes entfernten Skripts und jedes neuen Tags. Sinkt der Score, finden Sie über dieses Protokoll am schnellsten die Ursache. Kurz gesagt: Ein fester Messrhythmus bringt mehr als ein einmaliges Projekt zur Beschleunigung.

Zusammenfassung: Checkliste für Ihren nächsten Lighthouse Test

Wenn Sie den ganzen Leitfaden auf eine Karte bringen wollen, dann folgen Sie bei der nächsten Messung dieser Reihenfolge:

• Prüfen Sie zuerst die Felddaten in PageSpeed Insights und beginnen Sie bei roten Metriken.
• Führen Sie Labortests im Inkognito Fenster, mobil und mindestens dreimal durch.
• Achten Sie auf einzelne Metriken und geschätzte Ersparnisse, nicht auf die große Zahl.
• Prüfen Sie beim LCP das Titelbild, bei der TBT das JavaScript und beim CLS Elemente ohne Maße.
• Setzen Sie Änderungen auf Ebene der Vorlagen um und halten Sie jede im Protokoll fest.
• Bestätigen Sie die Ergebnisse mit 28 Tagen Felddaten in der Search Console.

Planen Sie eine neue Website, kostet es deutlich weniger, diese Regeln von Anfang an einzuplanen, als sie später nachzurüsten. Typische Budgets finden Sie auf der Seite Website erstellen lassen: Kosten. Und wenn Sie Ihren aktuellen Bericht gemeinsam lesen möchten, schreiben Sie mir.