PageSpeed optimieren: Ladezeit und Core Web Vitals richtig verbessern

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 setzt der RankScan-Insight „Langsame LadezeitPageSpeed bezeichnet die Ladezeit und Reaktionsfähigkeit einer Website. PageSpeed-Optimierung umfasst Massnahmen, die Ladezeit, Reaktionsfähigkeit und visuelle Stabilität verbessern.Zum Glossareintrag →“ an.

Der Insight bedeutet: RankScan hat Hinweise gefunden, dass eine Website oder URL-Gruppe zu langsam lädt oder wichtige Performance-Metriken nicht erfüllt. Das ist ein Website-Health-Thema mit Priorität Mittel – nicht, weil Ladezeit unwichtig wäre, sondern weil sie immer im Kontext von Content, SuchintentionDie 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 →, Seitentyp und Geschäftswert bewertet werden sollte.

Wichtig ist die richtige Einordnung:

PageSpeed Optimierung bedeutet nicht, einen perfekten Lighthouse-ScoreLighthouse 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, wie du Ladezeit, PageSpeed und Core Web VitalsCore 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 → richtig misst, welche Metriken wichtig sind und welche Massnahmen den grössten Effekt haben.

Was bedeutet „Langsame Ladezeit“? #

Der RankScan-Insight „Langsame Ladezeit“ bedeutet: Eine Seite oder URL-Gruppe lädt zu langsam oder zeigt Performance-Probleme, die Nutzererlebnis, CrawlingBeim 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 → oder Search VisibilitySuchsichtbarkeit 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 → beeinträchtigen können.

Das kann verschiedene Ursachen haben:

• langsame Serverantwort,
• grosse Bilder,
• unkomprimierte Assets,
• render-blockierendes CSSRender-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 →,
• zu viel JavaScript,
• langsame Drittanbieter-Skripte,
• Webfonts,
• Layout-Verschiebungen,
• fehlendes CachingCaching speichert bereits abgerufene Inhalte zwischen, sodass sie bei erneuten Aufrufen schneller bereitstehen und Server sowie Netzwerk entlastet werden.Zum Glossareintrag →,
• kein Content Delivery NetworkEin 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,
• clientseitiges RenderingBeim 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: „Langsame Ladezeit“ sollte nicht als isolierter Score stehen, sondern mit Seitentyp und Relevanz verbunden werden.

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 hilfreiche InhalteHilfreicher 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, Suchintention, 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.

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 H1Die 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 LoadingLazy 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 RenderingJavaScript-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,
• WebPWebP 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 BilderResponsive 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:

<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 HydrationHydration 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:

<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.

Für RankScan ist deshalb wichtig, nicht nur eine Laborzahl zu melden, sondern echte Nutzererfahrung und URL-Gruppen zu berücksichtigen.

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,
• Real User MonitoringFelddaten 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 und werden nach URL-Gruppen dargestellt.
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,
• schlechte URL-Gruppen,
• betroffene Metrik,
• Anzahl betroffener URLs,
• Seitentypen,
• Entwicklung über Zeit.

2. PageSpeed Insights nutzen #

Teste repräsentative URLs pro URL-Gruppe.

Prüfe:

• Felddaten,
• Labordaten,
• LCP-Element,
• render-blockierende Ressourcen,
• nicht genutztes JavaScript,
• Bildgrössen,
• ServerantwortzeitTime 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 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:

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

wenn dieses Bild das LCP-Element ist.

Besser:

<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,
• Hypertext Transfer ProtocolHTTP (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 RedirectsEine 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 CMSEin 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,
• BildoptimierungBild-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,
• Server-Side RenderingBeim 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 Application Programming Interface (API)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? #

Wenn RankScan „Langsame Ladezeit“ meldet, solltest du strukturiert vorgehen.

Schritt 1: Betroffene URL-Gruppe bestimmen #

Prüfe:

• einzelne URL,
• alle Blogartikel,
• alle Produktseiten,
• alle Kategorien,
• Startseite,
• Landingpages,
• mobile oder desktop,
• bestimmte Länder oder Geräte.

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?
Welche URL-Gruppe 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 #

Schritt 5: Massnahmen umsetzen #

Beginne mit dem grössten Hebel.

Nicht sinnvoll:

20 kleine Optimierungen ohne Messbasis

Besser:

eine URL-Gruppe
eine Hauptmetrik
ein klarer technischer Engpass
eine messbare Massnahme

Schritt 6: Validieren #

Nach Umsetzung:

• erneut Lighthouse testen,
• Validierung in der Google Search Console (GSC) starten,
• RUM-Daten beobachten,
• 28-Tage-Fenster berücksichtigen,
• Rankings und Conversion nicht isoliert bewerten,
• RankScan erneut crawlen.

Core-Web-Vitals-Felddaten reagieren nicht sofort. Je nach Datenlage dauert es mehrere Wochen, bis Verbesserungen in Search Console und CrUX stabil sichtbar werden.

Worauf ein guter PageSpeed-Check achtet #

Ein guter PageSpeed-Check sollte mehr leisten als eine einzelne Ladezeit zu melden.

Ein guter Check prüft:

• 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,
• URL-Gruppen,
• Seitentypen,
• organischer Traffic,
• Conversion-Relevanz,
• Template-Muster,
• Zusammenhang mit JavaScript-SEO.

So wird „Langsame Ladezeit“ zu einem priorisierbaren Website-Health-Workflow.

Beispiel: Schlechter LCP durch Hero-Bild #

Ausgangslage #

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

„Langsame Ladezeit“

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

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 Deploy erneut messen.

Ergebnis #

Der LCP verbessert sich deutlich. 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: Ohne URL-Gruppen arbeiten #

Wenn ein Template betroffen ist, muss das Template optimiert werden – nicht nur eine einzelne URL.

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-CrawlerKI-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?
• Welche URL-Gruppe 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?

Ergänzend dazu helfen AI Readiness Score, Google Ranking verbessern und 404-Fehler, um die Ursache sauber einzugrenzen und die nächsten SEO-Massnahmen zu priorisieren.

Frequently Asked Questions (FAQ), also häufig gestellte Fragen, zu 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 betroffener URL-Gruppe 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.

Was bedeutet „Langsame Ladezeit“ in RankScan? #

Der Insight bedeutet, dass RankScan Performance-Probleme erkannt hat, die Ladezeit, Nutzererlebnis oder Core Web Vitals beeinträchtigen können.

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

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

Der RankScan-Insight „Langsame Ladezeit“ zeigt, wo Ladezeit oder Core Web Vitals wahrscheinlich ein Problem darstellen. Entscheidend ist danach nicht ein perfekter Score, sondern die richtige Diagnose:

1. Felddaten prüfen,
2. betroffene URL-Gruppen 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 Search Visibility.

Quellen und weiterführende Informationen #

• Google Search Central – Understanding Core Web Vitals and Google Search results
• Google Search Central – Understanding page experience in Google Search results
• Google Search Console Help – Core Web Vitals report
• web.dev – Web Vitals
• web.dev – How Core Web Vitals thresholds were defined