Langsame Websites kosten Aufmerksamkeit. Nutzer warten nicht gerne, Crawler verschwenden Zeit auf schwerfälligen Seiten, und wichtige Inhalte erscheinen später als nötig. Trotzdem ist PageSpeed kein Selbstzweck.

Eine schnelle Seite mit schlechtem Inhalt wird nicht automatisch sichtbar. Eine langsame Seite mit sehr gutem Inhalt verschenkt aber Nutzererlebnis, Conversion-Potenzial und technische Qualität.

Genau hier setzen drei RankScan-Massnahmen an: «Langsam ladende Seiten», «Schwache Core Web Vitals sind ein Set von Google-Metriken, die die reale Nutzererfahrung einer Website in den Bereichen Ladeleistung, Interaktivität und visuelle Stabilität messen.Zum Glossareintrag →» und «Langsame Seiten mit Suchtraffic». Alle drei gehören zur Kategorie Website Health. Jede stützt sich auf eine eigene Datenquelle. Die erste misst RankScan im eigenen Beim Crawling ruft ein Suchmaschinen-Bot eine URL ab und lädt deren Inhalte herunter. Es ist der erste Schritt, bevor eine Seite indexiert werden kann.Zum Glossareintrag →. Die zweite und die dritte lesen Real User Monitoring (RUM) erfasst Leistungs- und Erlebnisdaten von echten Nutzern während ihres tatsächlichen Seitenbesuchs. Es liefert sogenannte Felddaten aus der realen Nutzung.Zum Glossareintrag → echter Chrome-Nutzer aus dem Chrome UX Report (CrUX).

Wichtig ist die richtige Einordnung:

PageSpeed Optimierung bedeutet nicht, einen perfekten Lighthouse ist ein quelloffenes Diagnosewerkzeug von Google, das Performance, Barrierefreiheit und weitere Qualitätsaspekte einer Seite in einer simulierten Laborumgebung prüft.Zum Glossareintrag → zu jagen. Ziel ist eine schnelle, stabile und nutzerfreundliche Seite auf Basis echter Nutzerdaten.

In diesem Artikel erfährst du, was jede der drei Massnahmen misst, wie du PageSpeed bezeichnet die Ladezeit und Reaktionsfähigkeit einer Website. PageSpeed-Optimierung umfasst Massnahmen, die Ladezeit, Reaktionsfähigkeit und visuelle Stabilität verbessern.Zum Glossareintrag → und Core Web Vitals selbst prüfst und welche Hebel den grössten Effekt haben.

Key Takeaways sind die wichtigsten Erkenntnisse eines Artikels als kurze, gut scanbare Liste. Sie helfen Nutzern, zentrale Aussagen schnell zu erfassen.Zum Glossareintrag →
  • Drei Massnahmen, drei Datenquellen: «Langsam ladende Seiten» misst den Abruf des HyperText Markup Language (HTML) ist die Auszeichnungssprache für Webseiten. Mit ihr werden Struktur und Inhalt einer Seite definiert, etwa Überschriften, Absätze, Links und Bilder.Zum Glossareintrag → im Crawl. «Schwache Core Web Vitals» liest die CrUX-Werte der ganzen Domain. «Langsame Seiten mit Suchtraffic» verbindet die CrUX-Werte einzelner Seiten mit ihren Klicks aus der Google Die Google Search Console (GSC) ist ein kostenloses Google-Tool, das zeigt, wie eine Website in der organischen Suche performt, mit Daten zu Impressionen, Klicks, Klickrate und durchschnittlicher Position sowie zu Indexierung und technischen Problemen.Zum Glossareintrag →.
  • Einstufung in RankScan: «Langsam ladende Seiten» und «Schwache Core Web Vitals»: Schwere mittel · Aufwand hoch · Arbeitsart Entwicklung. «Langsame Seiten mit Suchtraffic»: Schwere hoch · Aufwand hoch · Arbeitsart Entwicklung.
  • Prüfweg: «Langsam ladende Seiten» prüft der nächste vollständige Crawl. Die beiden CrUX-Massnahmen prüft RankScan mit den nächsten neuen CrUX-Daten.
  • PageSpeed Optimierung verbessert Ladezeit, Interaction to Next Paint (INP) misst, wie schnell eine Seite über alle Interaktionen hinweg auf Nutzereingaben reagiert, und steht für die Interaktivität.Zum Glossareintrag → und Cumulative Layout Shift (CLS) misst, wie stark sich Layout-Elemente während des Ladens unerwartet verschieben, und steht für die visuelle Stabilität einer Seite.Zum Glossareintrag →.
  • Die wichtigsten Core Web Vitals sind Largest Contentful Paint (LCP) misst, wann das grösste sichtbare Inhaltselement im sichtbaren Bereich geladen ist, und steht damit für die wahrgenommene Ladegeschwindigkeit.Zum Glossareintrag →, also der Zeitpunkt, zu dem der grösste sichtbare Inhalt geladen ist, Interaction to Next Paint (INP), also die Reaktionsschnelligkeit auf Nutzerinteraktionen, und Cumulative Layout Shift (CLS), also das unerwartete Verschieben von Layout-Elementen.
  • Google empfiehlt gute Core Web Vitals für Erfolg in Search und allgemein für eine gute Nutzererfahrung.
  • Core Web Vitals werden anhand echter Nutzerdaten bewertet, nicht nur anhand eines Labortests.
  • Entscheidend ist das Das 75. Perzentil ist der Schwellenwert, bei dem mindestens 75 % der Seitenaufrufe den guten Wert erreichen. Core Web Vitals werden an diesem Punkt bewertet, nicht am Durchschnitt.Zum Glossareintrag →: Mindestens 75 % der Seitenaufrufe sollten den guten Schwellenwert erreichen.
  • Labordaten entstehen in einer simulierten Testumgebung mit festgelegten Geräte- und Netzwerkbedingungen. Sie helfen, technische Ursachen von Performance-Problemen zu finden.Zum Glossareintrag → aus Lighthouse helfen bei der Fehlersuche, ersetzen aber keine Felddaten.
  • Häufige Ursachen sind zu grosse Bilder, langsame Serverantworten, Render-blockierende Ressourcen sind Dateien wie CSS oder JavaScript, die der Browser laden und verarbeiten muss, bevor er die Seite darstellen kann, und so das Rendering verzögern.Zum Glossareintrag → (Cascading Style Sheets (CSS) ist die Sprache, mit der das Layout und die Gestaltung von Webseiten festgelegt werden. CSS bestimmt unter anderem Farben, Schriften, Abstände und Anordnung.Zum Glossareintrag →, die Sprache für das Layout von Webseiten), zu viel JavaScript (JS), externe Skripte und Layout-Shifts.
  • Der beste Workflow lautet: erst Felddaten prüfen, dann Seitentypen priorisieren, dann Labordaten zur Diagnose nutzen.
  • Das Ziel ist «gut genug für Nutzer und Business», nicht technische Perfektion.
  • Priorisiere langsame Seiten nach Seitentyp, Suchtraffic, Conversion-Wert und betroffener Metrik.

Drei Massnahmen, drei Datenquellen #

RankScan trennt Ladezeit und Core Web Vitals in drei Massnahmen. Jede misst etwas anderes. Eine Seite kann darum in einer Massnahme auftauchen und in einer anderen nicht.

MassnahmeDatenquelleWas zähltEinstufung
«Langsam ladende Seiten»eigener Crawl von RankScanSeiten, deren HTML-Abruf länger als 3 Sekunden dauertSchwere mittel · Aufwand hoch · Arbeitsart Entwicklung
«Schwache Core Web Vitals»CrUX, Werte der ganzen DomainMetriken (LCP, INP, CLS) im roten BereichSchwere mittel · Aufwand hoch · Arbeitsart Entwicklung
«Langsame Seiten mit Suchtraffic»CrUX je Seite plus Klicks aus der Google Search ConsoleSeiten mit Klicks und mindestens einer Metrik im roten BereichSchwere hoch · Aufwand hoch · Arbeitsart Entwicklung

«Langsam ladende Seiten»: der Abruf im Crawl #

RankScan ruft im Crawl jede Seite ab. Gemessen wird die Zeit von der Anfrage bis zur vollständig geladenen HTML-Antwort. Die Wartezeit in der Warteschlange des Crawlers zählt nicht. Dauert der Abruf länger als 3 Sekunden, zählt die Seite als langsam.

Der Crawl lädt dabei keine Bilder, Skripte oder Schriften. Er stellt die Seite auch nicht im Browser dar. Der Wert hängt darum vor allem von der Serverantwort, vom Caching speichert bereits abgerufene Inhalte zwischen, sodass sie bei erneuten Aufrufen schneller bereitstehen und Server sowie Netzwerk entlastet werden.Zum Glossareintrag → und von der Grösse des HTML ab.

Bestätigungsseiten zählen nicht, auch nicht in der Gesamtzahl der Seiten. Ein Beispiel ist die Danke-Seite nach einem Formular. Dort wartet niemand auf Inhalt.

«Schwache Core Web Vitals»: die Werte der ganzen Domain #

Diese Massnahme liest die Felddaten echter Chrome-Nutzer aus dem Chrome UX Report. RankScan holt die Werte jede Nacht, für Mobilgeräte. Bewertet wird der Wert der ganzen Domain, nicht der einzelnen Seite.

Eine Metrik zählt, wenn ihr 75. Perzentil im roten Bereich liegt:

  • LCP über 4 Sekunden,
  • INP über 500 Millisekunden,
  • CLS über 0,25.

Die Schwellen entsprechen der Einteilung von Google in der Search Console.
Quelle: Google Search Console Help: Core Web Vitals report

Die Massnahme zählt Metriken, nicht Seiten. Hat Google für deine Domain keine Felddaten, misst RankScan diese Massnahme nicht. Das betrifft vor allem kleine Websites mit wenigen Chrome-Besuchern.

«Langsame Seiten mit Suchtraffic»: einzelne Seiten mit Klicks #

Diese Massnahme verbindet zwei Quellen: die Klicks aus der Google Search Console und die CrUX-Werte der einzelnen Seite. Eine Seite zählt, wenn beides zutrifft:

  • Sie hat in den letzten 30 Tagen mindestens 10 Klicks aus der Google-Suche.
  • Mindestens eine ihrer Metriken (LCP, INP oder CLS) liegt auf Mobilgeräten im roten Bereich.

Die CrUX-Werte je Seite fragt RankScan jede Nacht ab. Dabei kommen bis zu 100 Seiten an die Reihe, die Seiten mit den meisten Impressionen geben an, wie oft das Suchergebnis einer Website in der Google-Suche eingeblendet wurde, unabhängig davon, ob darauf geklickt wurde. Sie sind eine Kernmetrik der Google Search Console und zeigen die reine Sichtbarkeit einer Seite für bestimmte Suchanfragen.Zum Glossareintrag → in der Search Console zuerst. Google liefert Werte für eine einzelne Seite nur, wenn genug Chrome-Nutzer sie besucht haben. Fehlen diese Werte, fehlt die Seite auch in dieser Massnahme.

RankScan sortiert die Liste nach Klicks und zeigt höchstens 50 Seiten. Die Massnahme hat die höchste Schwere der drei. Diese Seiten bringen schon Besucher aus der Suche. Ein relevanter Anteil der gemessenen mobilen Besuche hat ein schlechtes Lade-, Interaktions- oder Stabilitätserlebnis. Das zeigt der CrUX-Wert am 75. Perzentil für Mobilgeräte. Ein schlechter INP oder CLS ist dabei nicht dasselbe wie eine langsame Ladezeit. Die Ladezeit der HTML-Datei im Crawl misst dagegen nur «Langsam ladende Seiten».

Typische Bremsen #

Langsame Seiten haben meist mehrere Ursachen. Nur ein Teil davon zeigt sich im HTML-Abruf des Crawls. Die übrigen treffen die Besucher und damit die Core Web Vitals.

  • langsame Serverantwort,
  • grosse Bilder,
  • unkomprimierte Assets,
  • render-blockierendes CSS,
  • zu viel JavaScript,
  • langsame Drittanbieter-Skripte,
  • Webfonts,
  • Layout-Verschiebungen,
  • fehlendes Caching,
  • kein Ein Content Delivery Network (CDN) ist ein Netzwerk verteilter Server, das statische Inhalte näher beim Nutzer ausliefert und so Ladezeiten verkürzt.Zum Glossareintrag → (CDN, ein Netzwerk verteilter Server zur schnelleren Auslieferung),
  • schweres Theme,
  • Plugin-Wildwuchs,
  • Beim Client-Side Rendering (CSR) liefert der Server nur ein nahezu leeres HTML-Grundgerüst. Der eigentliche Inhalt wird erst im Browser durch JavaScript erzeugt.Zum Glossareintrag →.

Wichtig: Bewerte eine langsame Seite immer zusammen mit ihrem Seitentyp und ihrer Relevanz.

Eine langsame Produktkategorie mit Umsatzpotenzial ist wichtiger als eine selten besuchte Archivseite.

Warum Ladezeit für Suchmaschinenoptimierung (SEO) und Nutzer wichtig ist #

Google beschreibt Core Web Vitals als Metriken, die reale Nutzererfahrung in den Bereichen Ladeleistung, Interaktivität und visuelle Stabilität messen. Google empfiehlt Website-Betreibern, gute Core Web Vitals zu erreichen, sowohl für Search als auch für eine gute Nutzererfahrung allgemein.
Quelle: Google Search Central: Understanding Core Web Vitals and Google Search results

Die realistische Einordnung:

  • PageSpeed ist Teil der Page Experience.
  • Page Experience kann beeinflussen, wie Seiten in Google Search performen.
  • Sie ersetzt aber nicht Hilfreicher Content (Helpful Content) bezeichnet Inhalte, die primär für Menschen erstellt werden, eine klare Antwort liefern und Substanz, Originalität und Vertrauen zeigen, statt vor allem für Suchmaschinen optimiert zu sein.Zum Glossareintrag →, Relevanz, Die Suchintention ist die Absicht, die hinter einer Suchanfrage steht: Will der Nutzer etwas wissen, etwas kaufen oder eine bestimmte Seite ansteuern? Inhalte ranken nur gut, wenn sie diese Absicht treffen.Zum Glossareintrag →, Autorität oder technische Indexierbarkeit.
  • Gute Ladezeit hilft besonders dort, wo Nutzererlebnis und Conversion wichtig sind.

Google erklärt in der Page-Experience-Dokumentation, dass Page Experience ein Faktor für gute Inhalte und Sucherfahrung ist, aber nicht wichtiger als hilfreiche, relevante Inhalte.
Quelle: Google Search Central: Understanding page experience in Google Search results

Für RankScan bedeutet das:

Langsame Seiten sind kein automatischer Rankingverlust, aber ein messbares Qualitäts- und Nutzerproblem.

Core Web Vitals: LCP, INP und CLS #

Die Core Web Vitals messen drei zentrale Aspekte der Nutzererfahrung.

MetrikBedeutungGuter Wert
LCPLadeleistung: Wann ist das grösste sichtbare Inhaltselement geladen?≤ 2,5 s
INPInteraktivität: Wie schnell reagiert die Seite auf Nutzerinteraktionen?≤ 200 ms
CLSVisuelle Stabilität: Wie stark verschiebt sich das Layout?≤ 0,1

web.dev beschreibt Core Web Vitals als Set von Metriken für Ladeerlebnis, Interaktivität und visuelle Stabilität. Die empfohlenen Schwellenwerte werden am 75. Perzentil bewertet.
Quelle: web.dev: Web Vitals

LCP: Hauptinhalt schneller sichtbar machen #

Largest Contentful Paint misst, wann das grösste sichtbare Element im Viewport geladen ist.

Häufig ist das:

  • Hero-Bild,
  • Artikelbild,
  • grosse Die H1 ist die Hauptüberschrift einer Webseite. Sie benennt das zentrale Thema, ist für Nutzer sichtbar und sollte pro Seite in der Regel nur einmal vorkommen.Zum Glossareintrag →,
  • Produktbild,
  • Banner,
  • grosser Textblock.

Ein schlechter LCP entsteht oft durch:

  • grosses Hero-Bild,
  • langsamer Server,
  • render-blockierendes CSS,
  • Lazy Loading bezeichnet das verzögerte Nachladen von Inhalten wie Bildern erst dann, wenn sie in den sichtbaren Bereich gelangen, um die anfängliche Ladezeit zu reduzieren.Zum Glossareintrag → auf dem wichtigsten Bild,
  • fehlende Bildpriorisierung,
  • langsame Fonts,
  • Client-Side JavaScript-Rendering bezeichnet den Vorgang, bei dem ein Browser oder Crawler JavaScript-Code ausführt, um daraus die fertige, sichtbare Seite zu erzeugen. Erst nach diesem Schritt entstehen Inhalte, die nicht bereits im ausgelieferten HTML stehen.Zum Glossareintrag →,
  • Third-Party-Skripte.

LCP verbessern #

Wichtige Massnahmen:

  • Hero-Bild komprimieren,
  • WebP und AVIF sind moderne, platzsparende Bildformate, die bei vergleichbarer Qualität deutlich kleinere Dateien als JPEG oder PNG ermöglichen und so die Ladezeit verbessern.Zum Glossareintrag → oder AVIF nutzen (moderne, platzsparende Bildformate),
  • Responsive Bilder liefern je nach Bildschirmgrösse und Auflösung des Geräts eine passend dimensionierte Bildvariante aus, damit nicht unnötig grosse Dateien geladen werden.Zum Glossareintrag → mit srcset ausliefern,
  • LCP-Bild nicht lazy-loaden,
  • LCP-Bild mit fetchpriority="high" priorisieren,
  • kritisches CSS früh laden,
  • Serverantwort verbessern,
  • unnötige Skripte verzögern,
  • CDN für statische Assets nutzen.

Beispiel:

html
<img
  src="/images/hero.webp"
  srcset="/images/hero-800.webp 800w, /images/hero-1600.webp 1600w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width="1200"
  height="675"
  fetchpriority="high"
  alt="..."
>

INP: Reaktionsfähigkeit verbessern #

Interaction to Next Paint misst, wie schnell eine Seite auf Nutzerinteraktionen reagiert.

INP hat die ältere Metrik FID ersetzt. Während FID nur die erste Interaktion betrachtete, bewertet INP die Reaktionsfähigkeit über alle Interaktionen einer Seite hinweg.

Ein schlechter INP entsteht häufig durch:

  • zu viel JavaScript,
  • lange Main-Thread-Tasks,
  • schwere Frameworks,
  • viele Third-Party-Skripte,
  • komplexe Event-Handler,
  • grosse Bundles,
  • Chat-Widgets,
  • Tracking-Skripte,
  • clientseitige Suche oder Filter,
  • nicht optimierte Hydration bezeichnet den Vorgang, bei dem serverseitig geliefertes HTML im Browser durch JavaScript interaktiv gemacht wird. Das Markup ist bereits vorhanden, JavaScript fügt nur noch das Verhalten hinzu.Zum Glossareintrag →.

INP verbessern #

Wichtige Massnahmen:

  • JavaScript reduzieren,
  • Code Splitting einsetzen,
  • nicht kritische Skripte verzögern,
  • Third-Party-Skripte prüfen,
  • lange Tasks aufteilen,
  • Event-Handler optimieren,
  • unnötige Re-Renders vermeiden,
  • Hydration reduzieren,
  • interaktive Komponenten gezielt laden.

Für JavaScript-intensive Websites ist INP oft der wichtigste Performance-Hebel.

CLS: Layout-Verschiebungen vermeiden #

Cumulative Layout Shift misst, wie stark sich Elemente während des Ladens unerwartet verschieben.

Ein schlechter CLS entsteht oft durch:

  • Bilder ohne width und height,
  • Ads ohne reservierten Platz,
  • eingebettete Videos ohne Platzhalter,
  • nachladende Banner,
  • Cookie-Banner,
  • Webfonts,
  • dynamische Inhalte über dem sichtbaren Bereich.

CLS verbessern #

Wichtige Massnahmen:

  • Breite und Höhe bei Bildern angeben,
  • Platz für Ads und Embeds reservieren,
  • Cookie-Banner stabil positionieren,
  • Font-Loading optimieren,
  • nachladende Inhalte nicht oberhalb bestehender Inhalte einfügen,
  • Skeletons oder Platzhalter nutzen.

Beispiel:

html
<img src="/produkt.webp" width="800" height="600" alt="Produkt">

So kann der Browser Platz reservieren, bevor das Bild geladen ist.

Das 75. Perzentil: Warum Durchschnittswerte täuschen #

Core Web Vitals werden nicht nach einem einfachen Durchschnitt bewertet.

Die empfohlenen Schwellenwerte gelten am 75. Perzentil. Das bedeutet: Mindestens 75 % der Seitenaufrufe sollten den guten Wert erreichen.

web.dev erklärt, dass Tools zur Bewertung der Core Web Vitals eine Seite als bestanden betrachten sollten, wenn die empfohlenen Ziele am 75. Perzentil der Seitenaufrufe erreicht werden.
Quelle: web.dev: How Core Web Vitals thresholds were defined

Warum das wichtig ist:

  • Eine Seite kann für schnelle Desktop-Nutzer gut wirken.
  • Mobile Nutzer mit schwacher Verbindung können trotzdem schlechte Werte haben.
  • Einzelne sehr langsame Nutzer werden nicht allein entscheidend, aber die Mehrheit muss eine gute Erfahrung haben.
  • Mobile und Desktop sollten getrennt analysiert werden.

Darum bewerten «Schwache Core Web Vitals» und «Langsame Seiten mit Suchtraffic» das 75. Perzentil der Felddaten. RankScan liest dafür die Werte für Mobilgeräte.

Felddaten vs. Labordaten #

Bei PageSpeed Optimierung gibt es zwei Datenwelten.

Felddaten #

Felddaten basieren auf echten Nutzern.

Quellen:

  • Chrome UX Report,
  • PageSpeed Insights,
  • Google Search Console Core Web Vitals,
  • Felddaten sind Performance-Messwerte, die auf echten Nutzern und ihren realen Geräten und Verbindungen basieren. Sie zeigen, ob ein Performance-Problem tatsächlich relevant ist.Zum Glossareintrag →,
  • Analytics mit Web-Vitals-Tracking.

Google Search Console beschreibt den Core-Web-Vitals-Bericht als Auswertung realer Nutzungsdaten. Die Daten stammen aus dem Chrome UX Report. Der Bericht fasst ähnliche Seiten zu Gruppen zusammen.
Quelle: Google Search Console Help: Core Web Vitals report

Felddaten sagen dir:

Haben echte Nutzer ein Problem?

Labordaten #

Labordaten entstehen in einer simulierten Testumgebung.

Quellen:

  • Lighthouse,
  • Chrome DevTools,
  • WebPageTest,
  • PageSpeed Insights Lab-Bereich,
  • lokale Performance-Tests.

Labordaten sagen dir:

Wo könnte das Problem technisch liegen?

Die wichtigste Regel #

Felddaten zeigen, ob ein Problem relevant ist. Labordaten helfen, die Ursache zu finden.

PageSpeed richtig messen #

Ein sinnvoller Mess-Workflow sieht so aus.

1. Google Search Console prüfen #

Starte mit dem Core-Web-Vitals-Bericht.

Prüfe:

  • Mobile und Desktop getrennt,
  • Gruppen ähnlicher Seiten mit schlechtem Wert,
  • betroffene Metrik,
  • Anzahl betroffener URLs,
  • Seitentypen,
  • Entwicklung über Zeit.

2. PageSpeed Insights nutzen #

Teste je Seitentyp eine typische Seite, ohne Parameter in der Adresse.

Prüfe:

  • Felddaten,
  • Labordaten,
  • LCP-Element,
  • render-blockierende Ressourcen,
  • nicht genutztes JavaScript,
  • Bildgrössen,
  • Time to First Byte (TTFB) ist die Zeit, bis der Browser das erste Byte der Serverantwort erhält, und beschreibt damit, wie schnell der Server reagiert.Zum Glossareintrag →,
  • Layout-Shifts.

3. Lighthouse zur Diagnose nutzen #

Nutze Lighthouse nicht als einziges Ziel, sondern als Diagnosewerkzeug.

Ein 100/100-Score ist nicht immer wirtschaftlich sinnvoll. Wichtiger ist, reale Nutzerprobleme auf wichtigen Seiten zu beheben.

4. WebPageTest oder DevTools für Details #

Für technische Teams sind hilfreich:

  • Wasserfallanalyse,
  • Time to First Byte (TTFB), also die Zeit bis zum ersten Byte der Serverantwort,
  • Resource Timing,
  • Main-Thread-Arbeit,
  • Third-Party-Skripte,
  • Filmstrip,
  • CPU-Throttling,
  • Netzwerkbedingungen.

5. Real User Monitoring aufsetzen #

Bei grösseren Websites lohnt sich RUM.

Damit erkennst du:

  • echte Nutzergeräte,
  • langsame Länder/Regionen,
  • Browser-Unterschiede,
  • Seiten-Templates,
  • Ausreisser,
  • Conversion-Auswirkungen.

Priorisierung: Welche langsamen Seiten sind wichtig? #

Nicht jede langsame URL muss sofort optimiert werden.

Die folgende Tabelle ist eine allgemeine fachliche Einordnung. RankScan zeigt je Massnahme eine feste Schwere.

SituationDringlichkeitWarum
wichtige Produkt- oder Kategorieseite langsamHochUmsatz- und Suchmaschinenoptimierung (SEO) umfasst alle Maßnahmen, mit denen eine Website in den unbezahlten (organischen) Suchergebnissen besser sichtbar wird.Zum Glossareintrag →-Relevanz
Landingpage mit Kampagnen-Traffic langsamHochdirekte Conversion-Kosten
Seiten mit vielen organischen Klicks langsamHochNutzererlebnis und Sichtbarkeit, in RankScan «Langsame Seiten mit Suchtraffic»
ganzer Seitentyp mit schlechtem LCPHochProblem der Vorlage
schlechter INP durch globales SkriptHochbetrifft viele Seiten
CLS auf allen TemplatesMittel bis hochUser-Experience-Problem (UX), also ein Problem beim Nutzererlebnis, auf breiter Basis
selten besuchte Archivseite langsamNiedriggeringe Wirkung
noindex ist eine Robots-Anweisung, die Suchmaschinen mitteilt, dass eine Seite nicht in den Suchergebnissen erscheinen soll. Die Seite muss dafür crawlbar bleiben.Zum Glossareintrag →-Seite langsamNiedrigmeist kein SEO-Fokus
einzelne Labordaten-Warnung ohne FelddatenproblemNiedrig bis mittelprüfen, aber nicht überreagieren

Die wichtigste Regel:

Optimierung dort beginnen, wo viele echte Nutzer, wichtige Rankings oder Conversion-Ziele betroffen sind.

Die grössten PageSpeed-Hebel #

1. Bilder optimieren #

Bilder sind oft der grösste LCP-Hebel.

Massnahmen:

  • WebP oder AVIF nutzen,
  • Bilder richtig dimensionieren,
  • responsive Bilder mit srcset,
  • Bildkompression,
  • LCP-Bild priorisieren,
  • Lazy Loading nur unterhalb des sichtbaren Bereichs,
  • sinnvolle Platzhalter,
  • Alt-Texte nicht vergessen.

Häufiger Fehler:

html
<img src="hero.jpg" loading="lazy">

wenn dieses Bild das LCP-Element ist.

Besser:

html
<img src="hero.webp" fetchpriority="high">

2. Serverantwort verbessern #

TTFB ist nicht direkt ein Core Web Vital, beeinflusst aber LCP stark.

Massnahmen:

  • gutes Hosting,
  • Page Caching,
  • Object Cache,
  • OPcache,
  • Datenbankoptimierung,
  • CDN,
  • HTTP (Hypertext Transfer Protocol) ist das Protokoll, über das Browser und Server Webinhalte austauschen. HTTPS ist die verschlüsselte, sichere Variante dieses Protokolls.Zum Glossareintrag → (HTTP) in Version HTTP/2 oder HTTP/3,
  • Kompression,
  • unnötige Eine Weiterleitung (Redirect) leitet Nutzer und Suchmaschinen von einer URL auf eine andere um. Sie kann dauerhaft (301) oder temporär (302) sein und überträgt Signale auf die Ziel-URL.Zum Glossareintrag → vermeiden,
  • Edge Caching.

Wenn der Server langsam antwortet, kann keine Frontend-Optimierung den LCP vollständig retten.

3. CSS optimieren #

CSS kann Rendering blockieren.

Massnahmen:

  • kritisches CSS priorisieren,
  • ungenutztes CSS entfernen,
  • CSS minifizieren,
  • grosse Framework-Dateien reduzieren,
  • CSS sauber bündeln oder gezielt splitten,
  • Fonts und CSS nicht unnötig verschachteln.

4. JavaScript reduzieren #

Zu viel JavaScript ist häufig die Ursache für schlechten INP und LCP.

Massnahmen:

  • nicht benötigte Skripte entfernen,
  • Code Splitting,
  • defer oder async nutzen,
  • Third-Party-Skripte kritisch prüfen,
  • Chat-Widgets verzögert laden,
  • Tracking-Tags bereinigen,
  • Framework-Hydration reduzieren,
  • Long Tasks aufteilen.

Bei JavaScript-lastigen Seiten ist auch der Artikel JavaScript-SEO: Rendering-Probleme erkennen relevant.

5. Fonts optimieren #

Webfonts können Ladezeit und CLS beeinflussen.

Massnahmen:

  • nur benötigte Schriftschnitte laden,
  • Fonts lokal hosten oder effizient ausliefern,
  • font-display: swap oder passende Strategie nutzen,
  • Preload für zentrale Fonts prüfen,
  • variable Fonts sinnvoll einsetzen,
  • Fallback-Fonts mit ähnlicher Metrik wählen.

6. Third-Party-Skripte kontrollieren #

Viele Seiten sind nicht wegen eigener Inhalte langsam, sondern wegen Drittanbietern.

Typische Skripte:

  • Tracking,
  • Tag Manager,
  • Chat,
  • Heatmaps,
  • A/B-Testing,
  • Cookie-Banner,
  • Ads,
  • Social Widgets,
  • Bewertungs-Widgets.

Prüfe:

  • Wird das Skript wirklich gebraucht?
  • Muss es sofort laden?
  • Kann es nach Consent oder Interaktion laden?
  • Gibt es schlankere Alternativen?
  • Verursacht es Long Tasks?
  • Beeinflusst es INP?

PageSpeed Optimierung in WordPress und Content-Management-System (CMS) #

Viele Performance-Probleme entstehen im Ein Content-Management-System (CMS) ist eine Software zur Erstellung, Verwaltung und Veröffentlichung von Webinhalten, meist ohne Programmierkenntnisse. Bekannte Beispiele sind WordPress oder Shopify.Zum Glossareintrag →-Setup.

WordPress #

Häufige Ursachen:

  • zu viele Plugins,
  • schweres Theme,
  • Page Builder,
  • unoptimierte Bilder,
  • kein Caching,
  • viele externe Skripte,
  • nicht optimierte Datenbank,
  • ungenutzte CSS-/JS-Dateien,
  • schlecht konfigurierte Fonts.

Wichtige Massnahmen:

  • Plugin-Audit,
  • serverseitiges Caching,
  • Bild-SEO umfasst alle Massnahmen, die Bilder für Suchmaschinen, die Bildersuche und maschinelle Systeme verständlicher machen. Dazu gehören Alt-Texte, sprechende Dateinamen und passender Kontext.Zum Glossareintrag →,
  • Datenbank bereinigen,
  • unnötige Page-Builder-Module entfernen,
  • Critical CSS prüfen,
  • CDN nutzen,
  • Theme-Gewicht reduzieren.

Craft CMS, TYPO3, Laravel, Headless #

Bei individuellen Setups liegen die Hebel oft woanders:

  • Template-Caching,
  • Query-Optimierung,
  • eager loading,
  • Asset-Transformations,
  • CDN,
  • Beim Server-Side Rendering (SSR) erzeugt der Server das fertige HTML, bevor die Seite an Browser oder Crawler ausgeliefert wird. Inhalte sind dadurch sofort im Quelltext vorhanden.Zum Glossareintrag → (SSR), also serverseitiges Rendern, und Static Site Generation (SSG), also statische Seitengenerierung,
  • Antwortzeiten der Eine Application Programming Interface (API) ist eine Programmierschnittstelle, über die Software-Systeme miteinander kommunizieren und Daten austauschen. Sie definiert, wie Anfragen gestellt und beantwortet werden.Zum Glossareintrag →, also der Programmierschnittstelle,
  • Frontend-Bundle-Grösse,
  • Bild-Pipelines,
  • Edge-Caching.

Performance-Funde sollten deshalb möglichst nach Template oder Seitentyp gruppiert werden.

Was tun nach einem RankScan-Fund? #

Jede der drei Massnahmen hat in RankScan eigene Schritte. Sie nutzen dieselben Werkzeuge: PageSpeed Insights für die Diagnose, Entwicklung oder Agentur für die Umsetzung. RankScan startet den nächsten Lauf selbst. Du meldest die Massnahme nur als umgesetzt.

«Langsam ladende Seiten» #

  1. Wähle drei bis vier typische Seitentypen aus der Liste, etwa Startseite, Angebot und Galerie.
  2. Miss je eine Seite davon ohne Parameter mit PageSpeed Insights. Notiere die grössten Bremsen. Achte besonders auf die Serverantwortzeit. Sie bestimmt den Wert im Crawl am stärksten.
  3. Verkleinere Bilder und Dateien, die du selbst hochlädst. Sie zählen nicht im HTML-Abruf des Crawls, bremsen aber deine Besucher.
  4. Gib die übrigen Bremsen an Entwicklung oder Agentur weiter. Sie liegen meist in der Vorlage der Seiten.
  5. Eine Korrektur in der Vorlage beschleunigt alle Seiten dieses Typs.
  6. Melde die Massnahme als umgesetzt, sobald die Seiten schneller laden.

Prüfweg: Der nächste vollständige Crawl prüft alle betroffenen Seiten. RankScan meldet dann «Behoben» oder «Noch nicht behoben» mit der Zahl der Seiten, die noch fehlen.

«Schwache Core Web Vitals» #

  1. Öffne PageSpeed Insights und notiere, welche Metrik im roten Bereich liegt: LCP, CLS oder INP. Die Massnahme in RankScan nennt dieselben Metriken.
  2. Notiere, was jede Metrik braucht. LCP: grösstes Bild komprimieren, Server-Antwortzeit verbessern.
  3. CLS: Platz mit festen Bildgrössen reservieren. INP: schwere JavaScript-Last reduzieren.
  4. Gib die Liste an Entwicklung oder Agentur weiter und melde die Massnahme danach als umgesetzt.

Prüfweg: RankScan prüft die Massnahme mit den nächsten neuen CrUX-Daten. Liegt keine Metrik der Domain mehr im roten Bereich, meldet RankScan «Behoben». Sonst bleibt die Massnahme gemeldet.

«Langsame Seiten mit Suchtraffic» #

  1. Sortiere die betroffenen Seiten nach Suchtraffic.
  2. Notiere je Seite die schwachen Metriken aus PageSpeed Insights.
  3. Gib die Liste an Entwicklung oder Agentur weiter, die Seite mit dem meisten Traffic zuerst. Teilen mehrere Seiten eine Vorlage, wirkt die Korrektur in der Vorlage auf alle.
  4. Melde die Massnahme als umgesetzt, sobald die Seiten schneller laden.

Prüfweg: RankScan prüft die Massnahme mit den nächsten neuen CrUX-Daten je Seite. Hat keine Seite mit Suchtraffic mehr eine Metrik im roten Bereich, meldet RankScan «Behoben». Sonst bleibt die Massnahme gemeldet.

Warum die CrUX-Prüfung Zeit braucht #

Der Chrome UX Report ist ein gleitender Durchschnitt über 28 Tage. Google aktualisiert die Daten täglich.
Quelle: Chrome for Developers: CrUX API

Eine Verbesserung zeigt sich darum Tag für Tag nur zum Teil. Vollständig sichtbar ist sie erst rund vier Wochen nach der Umsetzung. Bis dahin bleibt die Massnahme in RankScan gemeldet.

Diagnose: So findest du die Ursache #

Die folgenden Schritte vertiefen die Diagnose. Sie passen zu allen drei Massnahmen.

Schritt 1: Seitentypen bestimmen #

Prüfe, welche Seiten betroffen sind:

  • einzelne Seite,
  • alle Blogartikel,
  • alle Produktseiten,
  • alle Kategorien,
  • Startseite,
  • Landingpages,
  • mobile oder desktop.

Schritt 2: Felddaten prüfen #

Nutze:

  • Google Search Console,
  • PageSpeed Insights,
  • CrUX,
  • Real User Monitoring.

Frage:

Ist das Problem bei echten Nutzern sichtbar?
Welche Metrik fällt durch?
Mobile oder Desktop?
Welcher Seitentyp ist betroffen?

Schritt 3: Labordiagnose durchführen #

Für repräsentative URLs:

  • Lighthouse,
  • PageSpeed Insights,
  • WebPageTest,
  • Chrome DevTools.

Prüfe:

  • LCP-Element,
  • TTFB,
  • Bildgrösse,
  • CSS/JS-Blockaden,
  • Main-Thread-Zeit,
  • Third-Party-Skripte,
  • Layout-Shifts.

Schritt 4: Ursache je Metrik priorisieren #

ProblemErste Massnahme
schlechter LCPHero-Bild, TTFB, CSS, LCP-Priorisierung prüfen
schlechter INPJavaScript, Long Tasks, Third-Party-Skripte prüfen
schlechter CLSBildgrössen, Ads, Fonts, nachladende Elemente prüfen
langsamer ServerHosting, Cache, Datenbank, CDN prüfen
schlechte Mobile-WerteBildgrössen, JS, Netzwerk, CPU prüfen

Schritt 5: Massnahmen umsetzen #

Beginne mit dem grössten Hebel.

Nicht sinnvoll:

20 kleine Optimierungen ohne Messbasis

Besser:

ein Seitentyp
eine Hauptmetrik
ein klarer technischer Engpass
eine messbare Massnahme

Schritt 6: Validieren #

Nach Umsetzung:

  • erneut mit Lighthouse oder PageSpeed Insights testen,
  • Validierung in der Google Search Console (GSC) starten,
  • RUM-Daten beobachten,
  • 28-Tage-Fenster berücksichtigen,
  • Rankings und Conversion nicht isoliert bewerten,
  • die Massnahme in RankScan als umgesetzt melden.

Core-Web-Vitals-Felddaten reagieren nicht sofort. Bis Verbesserungen in Search Console und CrUX stabil sichtbar werden, vergehen rund vier Wochen.

Worauf ein guter PageSpeed-Check achtet #

Das ist eine allgemeine Checkliste. Nicht alles davon misst RankScan.

RankScan misst drei Dinge:

  • den HTML-Abruf jeder Seite im Crawl, Schwelle 3 Sekunden,
  • LCP, INP und CLS der ganzen Domain aus dem Chrome UX Report, für Mobilgeräte,
  • LCP, INP und CLS einzelner Seiten mit mindestens 10 Klicks aus der Google Search Console in 30 Tagen.

Für die Diagnose prüft ein guter Check zusätzlich:

  • LCP,
  • INP,
  • CLS,
  • TTFB,
  • Gesamtgewicht der Seite,
  • Bildgewicht,
  • unoptimierte Bilder,
  • render-blockierendes CSS,
  • unnötiges JavaScript,
  • Third-Party-Skripte,
  • Font-Ladeverhalten,
  • fehlende Bilddimensionen,
  • Lazy Loading auf LCP-Elementen,
  • Caching-Header,
  • Kompression,
  • CDN-Nutzung,
  • mobile vs. desktop,
  • Seitentypen,
  • organischer Traffic,
  • Conversion-Relevanz,
  • Muster in der Vorlage,
  • Zusammenhang mit JavaScript-SEO.

So wird aus einzelnen Messwerten ein priorisierbarer Website-Health-Workflow.

Beispiel: Schlechter LCP durch Hero-Bild #

Ausgangslage #

Ein B2B-Blog hat gute Inhalte, aber schlechte mobile Core Web Vitals. RankScan meldet zwei Massnahmen:

«Schwache Core Web Vitals»: LCP im roten Bereich
«Langsame Seiten mit Suchtraffic»: mehrere Blogartikel mit Klicks

Die Google Search Console zeigt für Blogartikel ebenfalls schlechten LCP.

«Langsam ladende Seiten» meldet RankScan nicht. Der Server liefert das HTML schnell aus. Das Hero-Bild zählt im HTML-Abruf des Crawls nicht. Es bremst aber die Besucher, und genau das zeigen die CrUX-Werte.

Analyse #

PageSpeed Insights zeigt:

  • LCP-Element ist das Hero-Bild,
  • Bild ist 2,8 MB gross,
  • Bild wird im PNG-Format ausgeliefert,
  • Bild ist grösser als nötig,
  • loading="lazy" ist auf dem Hero-Bild aktiv,
  • ein Chat-Widget lädt sofort.

Lösung #

  1. Hero-Bild in WebP/AVIF umwandeln.
  2. Responsive Bildgrössen ausliefern.
  3. Lazy Loading für das LCP-Bild entfernen.
  4. fetchpriority="high" setzen.
  5. Chat-Widget erst nach Interaktion laden.
  6. Page Cache prüfen.
  7. Nach dem Deploy mit PageSpeed Insights erneut messen.
  8. Beide Massnahmen in RankScan als umgesetzt melden.

Ergebnis #

Die Labordaten zeigen den besseren LCP sofort. Die CrUX-Werte folgen über das 28-Tage-Fenster. Liegt der LCP der Domain und der Blogartikel nicht mehr im roten Bereich, meldet RankScan beide Massnahmen als «Behoben». Ob sich Rankings verändern, hängt von weiteren Faktoren ab. Sicher verbessert sich aber die Nutzererfahrung auf den betroffenen Seiten.

Häufige Fehler bei PageSpeed Optimierung #

Fehler 1: Lighthouse 100/100 jagen #

Ein perfekter Laborscore ist nicht das Ziel. Entscheidend sind echte Nutzerdaten und geschäftlich relevante Seiten.

Fehler 2: LCP-Bild lazy-loaden #

Das wichtigste Above-the-Fold-Bild sollte nicht verzögert geladen werden.

Fehler 3: Nur Desktop testen #

Viele Probleme entstehen auf Mobile durch schwächere CPU, langsamere Verbindung und grössere JS-Kosten.

Fehler 4: Third-Party-Skripte ignorieren #

Chat, Tracking, Consent und A/B-Testing können Performance massiv beeinflussen.

Fehler 5: Seite für Seite statt Vorlage optimieren #

Wenn eine Vorlage betroffen ist, muss die Vorlage optimiert werden, nicht nur eine einzelne Seite.

Fehler 6: PageSpeed als Ranking-Hack verkaufen #

Schnelle Seiten helfen, aber sie ersetzen keine Suchintention, keine Inhalte und keine technische Indexierbarkeit.

Fehler 7: KI-Crawler (Künstliche Intelligenz) pauschal mit PageSpeed begründen #

Schnelle, serverseitig verfügbare Inhalte sind für Crawler hilfreich. Aber es gibt keine allgemeine Garantie, dass KI-Crawler sind automatisierte Bots, die Webseiten für KI-Anbieter abrufen, um Inhalte zu finden, für Suchfunktionen bereitzustellen, für Antworten abzurufen oder je nach Anbieter für Modelltraining zu verwenden.Zum Glossareintrag → langsame Seiten «schlicht ignorieren». Wichtiger sind Erreichbarkeit, initiale Hypertext Markup Language (HTML), also der Auszeichnungssprache für Webseiten, Statuscodes, robots.txt und Rendering.

Checkliste: PageSpeed und Core Web Vitals optimieren #

Nutze diese Checkliste:

  • Sind Felddaten in Search Console oder PageSpeed Insights verfügbar?
  • Ist Mobile oder Desktop betroffen?
  • Welcher Seitentyp ist betroffen?
  • Welche Metrik ist schlecht: LCP, INP oder CLS?
  • Was ist das LCP-Element?
  • Ist das LCP-Bild optimiert und priorisiert?
  • Gibt es render-blockierendes CSS?
  • Gibt es zu viel JavaScript?
  • Gibt es Long Tasks?
  • Sind Third-Party-Skripte nötig?
  • Sind Bilder korrekt dimensioniert?
  • Sind width und height gesetzt?
  • Gibt es Layout-Shifts durch Ads, Banner oder Fonts?
  • Ist Caching aktiv?
  • Ist Kompression aktiv?
  • Ist der Server schnell genug?
  • Werden wichtige Seiten erneut validiert?
  • Wird die Wirkung über Felddaten geprüft?
  • Hast du die Massnahme in RankScan als umgesetzt gemeldet?

Ergänzend dazu helfen KI-Crawler und robots.txt, Verlorenes Ranking und 404-Fehler, um die Ursache sauber einzugrenzen und die nächsten SEO-Massnahmen zu priorisieren.

Häufige Fragen zur PageSpeed-Optimierung #

Was ist PageSpeed Optimierung?

PageSpeed Optimierung umfasst Massnahmen, die Ladezeit, Reaktionsfähigkeit und Layout-Stabilität einer Website verbessern.

Was sind Core Web Vitals?

Core Web Vitals sind Google-Metriken für reale Nutzererfahrung: LCP für Ladeleistung, INP für Interaktivität und CLS für visuelle Stabilität.

Welche Core Web Vitals Werte sind gut?

LCP sollte höchstens 2,5 Sekunden betragen, INP höchstens 200 Millisekunden und CLS höchstens 0,1.

Sind Core Web Vitals ein Rankingfaktor?

Core Web Vitals sind Teil der Page Experience und können in Google Search eine Rolle spielen. Sie sind aber nicht wichtiger als hilfreiche, relevante Inhalte.

Warum unterscheiden sich Lighthouse und Search Console?

Lighthouse misst in einer simulierten Laborumgebung. Search Console nutzt echte Nutzerdaten aus dem Chrome UX Report. Deshalb können die Werte deutlich abweichen.

Was ist wichtiger: Felddaten oder Labordaten?

Felddaten zeigen, ob echte Nutzer betroffen sind. Labordaten helfen, technische Ursachen zu finden. Für die Priorisierung sind Felddaten wichtiger.

Was ist das 75. Perzentil?

Es bedeutet, dass mindestens 75 % der Seitenaufrufe den guten Schwellenwert erreichen sollten.

Wie kann ich die Ladezeit meiner Website verbessern?

Beginne mit Bildern, Serverantwort, Caching, CSS, JavaScript, Fonts und Third-Party-Skripten. Priorisiere nach betroffenem Seitentyp und Metrik.

Sollte ich alle Bilder lazy-loaden?

Nein. Bilder unterhalb des sichtbaren Bereichs können lazy geladen werden. Das wichtigste Above-the-Fold-Bild sollte nicht lazy-loaden.

Welche RankScan-Massnahmen gehören zu Ladezeit und Core Web Vitals?

Drei Massnahmen. «Langsam ladende Seiten» meldet Seiten, deren HTML-Abruf im Crawl länger als 3 Sekunden dauert. «Schwache Core Web Vitals» meldet Metriken der ganzen Domain im roten Bereich, gemessen im Chrome UX Report. «Langsame Seiten mit Suchtraffic» meldet Seiten mit mindestens 10 Klicks in 30 Tagen, deren CrUX-Werte im roten Bereich liegen.

Warum meldet RankScan schwache Core Web Vitals, aber keine langsam ladenden Seiten?

Die beiden Massnahmen messen Verschiedenes. Der Crawl misst nur den Abruf des HTML. Die Core Web Vitals messen, was Besucher im Browser erleben, also auch Bilder, Skripte und Layout. Ein grosses Hero-Bild bremst darum den LCP, aber nicht den HTML-Abruf.

Wann meldet RankScan «Behoben»?

«Langsam ladende Seiten» prüft der nächste vollständige Crawl. Die beiden CrUX-Massnahmen prüft RankScan mit den nächsten neuen CrUX-Daten. Weil CrUX über 28 Tage mittelt, dauert das rund vier Wochen.

Fazit: PageSpeed ist ein Nutzer- und Qualitätshebel, kein Perfektionsspiel #

PageSpeed Optimierung ist wichtig, aber sie sollte messbar und priorisiert erfolgen.

Die drei RankScan-Massnahmen «Langsam ladende Seiten», «Schwache Core Web Vitals» und «Langsame Seiten mit Suchtraffic» zeigen, wo Ladezeit oder Core Web Vitals ein Problem sind. Entscheidend ist danach nicht ein perfekter Score, sondern die richtige Diagnose:

  1. Felddaten prüfen,
  2. betroffene Seitentypen identifizieren,
  3. LCP, INP oder CLS als Hauptproblem bestimmen,
  4. technische Ursache im Labor analysieren,
  5. grössten Hebel zuerst beheben,
  6. wichtige Seiten und Templates priorisieren,
  7. Wirkung über echte Nutzerdaten validieren.

So wird PageSpeed nicht zur endlosen Entwickleraufgabe, sondern zu einem kontrollierten Website-Health-Prozess für bessere Nutzererfahrung, stabilere technische Qualität und bessere Voraussetzungen für Suchsichtbarkeit beschreibt, wie präsent und auffindbar eine Website in den organischen Suchergebnissen ist. Sie ist nicht dasselbe wie Traffic, sondern beschreibt die theoretische Auffindbarkeit.Zum Glossareintrag →.

Quellen und weiterführende Informationen #