PageSpeed-Empfehlungsbaum: Fehlerbild und System auswählen
So funktioniert der Klickpfad: Öffne zuerst das Fehlerbild, das deinen Messwerten oder Beobachtungen am nächsten kommt. Wähle darunter dein System. Die aufklappbare Best-Case-Empfehlung zeigt sinnvolle erste Prüfungen und Maßnahmen.
Die Vorschläge sind eine Orientierung nach typischen Fehlerbildern, keine Garantie für einen bestimmten Messwert. Erst Messungen an deiner Website zeigen, welche Änderung tatsächlich hilft. Wenn du dein System oder den Befund nicht sicher zuordnen kannst, nutze die Beratung am Ende des Artikels.
1. Der sichtbare Hauptinhalt erscheint spät (LCP)
Typisch: großes Titel- oder Produktbild, Überschrift oder Hero-Bereich wird spät sichtbar. Prüfe in PSI, welches Element als LCP erkannt wurde.
WordPress / WooCommerce
Best Case: LCP-Bild passend skalieren und als WebP/AVIF ausliefern, das sichtbare Hauptbild nicht lazy-loaden und unnötige Slider entfernen. Danach Cache/CDN und Mobilansicht messen; bei WooCommerce dynamische Warenkorbseiten separat behandeln.
Shopify
Best Case: das LCP-Element im Theme prüfen, Hero-Bild richtig dimensionieren und nicht verzögert laden. App-Embeds, große Slider und Theme-Reste reduzieren; anschließend Web-Performance-Bericht und PSI für denselben Seitentyp vergleichen.
TYPO3
Best Case: Bildvarianten und Bildgrößen für den Viewport prüfen, das sichtbare LCP-Bild priorisieren und Caching der betroffenen Seite kontrollieren. Bei langsamen dynamischen Seiten zusätzlich Extension- und Serverantwort untersuchen.
Shopware 6
Best Case: Produkt-/Kategorievorlage, Bildausgabe und HTTP-Cache gemeinsam prüfen. Große Hero-Medien und unnötige Storefront-Skripte optimieren; Änderung auf Produkt-, Kategorie- und mobilen Ansichten testen.
Wix / Webflow / Squarespace
Best Case: Titelbild passend zuschneiden, große Hintergrundvideos und Animationen reduzieren und das sichtbare Bild nicht durch unnötige Effekte verzögern. Plattformoptimierung ersetzt nicht den Test des tatsächlichen LCP-Elements.
Anderes System oder unsicher
Erster Schritt: PSI öffnen, LCP-Element und Ladepriorität ermitteln. Bild, HTML, CSS und Serverantwort entlang des Wasserfalls prüfen; nicht pauschal ein Cache- oder Lazy-Load-Plugin installieren.
2. Klicks und Eingaben reagieren träge (INP)
Typisch: Menü, Suche, Filter oder Warenkorb fühlt sich nach dem Klick blockiert an. INP betrifft Interaktionen während des Besuchs, nicht nur den ersten Seitenaufbau.
WordPress / WooCommerce
Best Case: lange JavaScript-Aufgaben in DevTools finden und Plugin-Skripte, Tag-Manager-Tags sowie Drittanbieter-Widgets einzeln prüfen. Nur nach Messung verzögern oder entfernen; Suche, Filter, Warenkorb und Checkout danach funktional testen.
Shopify
Best Case: App-Embeds, Tracking-Pixel und Theme-JavaScript auf tatsächliche Nutzung prüfen. Nicht benötigte Apps entfernen und verbliebene Theme-Skripte kontrollieren; anschließend Interaktionen auf Produktseite, Suche und Warenkorb messen.
TYPO3
Best Case: Erweiterungen und Frontend-Bundles identifizieren, die den Hauptthread blockieren. Nicht benötigte Funktionen entfernen oder gezielt laden lassen; Änderungen versions- und templategerecht testen.
Shopware 6
Best Case: Storefront-JavaScript und Plugins anhand einer echten Interaktion profilieren. Drittanbieter-Skripte und Erweiterungen priorisieren, die lange Aufgaben verursachen; Produktvarianten, Suche, Warenkorb und Checkout nach Änderungen durchspielen.
Wix / Webflow / Squarespace
Best Case: eingebettete Tools, Chat-Widgets, Animationen und eigene Skripte schrittweise deaktivieren oder ersetzen, um den Verursacher zu finden. Plattforminterne Funktionen weiter testen, denn unnötiges JavaScript kann auch von Integrationen kommen.
Anderes System oder unsicher
Erster Schritt: betroffene Interaktion in Chrome DevTools aufzeichnen und lange Main-Thread-Aufgaben untersuchen. Ein allgemeiner Lighthouse-Score reicht nicht aus, um den konkreten INP-Verursacher festzustellen.
3. Elemente springen oder verschieben sich (CLS)
Typisch: Buttons oder Text rutschen beim Laden nach unten. Suche nach Elementen, die ohne reservierten Platz später eingefügt werden.
WordPress / WooCommerce
Best Case: Bildabmessungen festlegen und Banner, Cookie-Hinweise, Fonts sowie Produkt-Widgets auf späte Einblendungen prüfen. Platz für dynamische Module reservieren; Änderungen mit und ohne Cache auf Mobilgeräten testen.
Shopify
Best Case: Theme-Bilder und Produktmedien mit festen Dimensionen ausgeben und nachträgliche App-Banner oder Bewertungswidgets lokalisieren. Cookie-Banner und Aktionsleisten dürfen den Inhalt beim Erscheinen nicht unerwartet verschieben.
TYPO3
Best Case: Bild- und Medienelemente in den Templates mit Platzhaltern bzw. Dimensionen versehen. Späte Extensions, eingebettete Inhalte und Schriftwechsel prüfen; Änderungen an der zuständigen Fluid-Vorlage testen.
Shopware 6
Best Case: Produktbilder, Teaser und Storefront-Widgets auf reservierte Fläche prüfen. Nachladende Preis-/Promo-Banner und Drittanbieter-Module kontrollieren und die betroffenen Shopware-Templates mobil wie Desktop testen.
Wix / Webflow / Squarespace
Best Case: Bild- und Video-Container in der Gestaltung vorab dimensionieren und Pop-ups, Cookie-Banner, Fonts sowie eingebettete Inhalte auf Layoutsprünge prüfen. Animationen nicht erst nachträglich über den Hauptinhalt legen.
Anderes System oder unsicher
Erster Schritt: im Lighthouse-Bericht und in DevTools die verschobenen Elemente identifizieren. Für jedes dynamische Element vor dem Laden Platz reservieren und danach erneut messen.
4. Serverantwort / TTFB ist langsam oder fast alles startet spät
TTFB ist eine Diagnosegröße, kein Core Web Vital. Prüfe Hosting, Cache, Datenbank und dynamische Requests; bei gehosteten Baukastensystemen ist die Serverebene nur begrenzt beeinflussbar.
WordPress / WooCommerce
Best Case: ungecachete Antwortzeit, Hosting/PHP, Datenbankabfragen und Objektcache getrennt prüfen. Einen Page-Cache nutzen, aber Warenkorb, Checkout und personalisierte Seiten korrekt ausnehmen; ein Plugin allein behebt keine langsamen Serverabfragen.
Shopify
Best Case: Hosting- und Serverkonfiguration liegen weitgehend bei Shopify. Deshalb Theme, Apps, externe Requests und Seitengröße untersuchen und den Shopify-Performancebericht nutzen; bei einem Verdacht auf Plattformprobleme konkrete URLs und Zeitpunkte dokumentieren.
TYPO3
Best Case: Cache-Hits und ungecachete Seiten vergleichen, TYPO3-Caching, PHP-OPcache, Datenbank und Hosting gemeinsam prüfen. Langsame Extensions und personalisierte Inhalte isolieren; Konfiguration an TYPO3-Version und Deployment anpassen.
Shopware 6
Best Case: HTTP-Cache, Cache-Warm-up, Produktionsmodus und gegebenenfalls Reverse Proxy kontrollieren. Langsame Plugins und dynamische Produkt-/Kategorieseiten identifizieren; Server-Tuning mit dem Hosting- oder Entwicklungsteam abstimmen.
Wix / Webflow / Squarespace
Best Case: Servereinstellungen sind in der Regel nicht direkt zugänglich. Drittanbieter-Integrationen und unnötig schwere Seitenbestandteile reduzieren, mehrere Läufe vergleichen und bei anhaltend hoher Antwortzeit die Messbedingungen sowie den Plattformstatus prüfen.
Anderes System oder unsicher
Erster Schritt: TTFB für gecachte und ungecachete URLs vergleichen und Network-Wasserfall prüfen. Der Crawl-Wert eines Bots ist nur ein Hinweis; bestätige die Ursache über wiederholbare Tests und Serverlogs.
5. Werte schwanken, es gibt keine Felddaten oder nur ein schlechter Lighthouse-Score
Typisch: PSI-Läufe unterscheiden sich oder es fehlen CrUX-Werte. Labordaten sind ein Debugging-Werkzeug; Felddaten beschreiben aggregierte reale Besuche, sofern ausreichend Daten vorliegen.
WordPress / WooCommerce
Best Case: PSI mobil/desktop mehrfach auf gleichen Seitentypen ausführen und Search Console für Felddaten ergänzen. Cache-Zustand dokumentieren, repräsentative Kategorie-/Produktseiten wählen und nach Änderungen reale Feldwerte abwarten.
Shopify
Best Case: Shopify Web-Performance-Bericht und PSI nicht als dieselbe Messung behandeln. Gleiche Seitentypen und Zeiträume vergleichen; fehlende Felddaten bedeuten nicht automatisch „bestanden“ und ein einzelner Score ist keine Garantie.
TYPO3
Best Case: URLs nach Templates gruppieren und Labortests mit Search-Console-Felddaten abgleichen. Staging- und Live-Messungen trennen; nicht aus einem einzelnen TYPO3-Test auf sämtliche Seitentypen schließen.
Shopware 6
Best Case: repräsentative Produkt-, Kategorie- und Content-Seiten mehrfach testen und Felddaten nach Mobil/Desktop prüfen. Nach Release Cache leeren bzw. aufwärmen und Messzeitpunkt notieren, damit Vorher-Nachher-Werte vergleichbar sind.
Wix / Webflow / Squarespace
Best Case: PageSpeed Insights für mehrere repräsentative Seiten und Geräte wiederholen und mit verfügbaren Plattform- oder Search-Console-Daten ergänzen. Einen Score nie als alleinige Freigabe verwenden; wichtige Formulare und Kontaktwege praktisch testen.
Anderes System oder unsicher
Erster Schritt: URL, Gerät, Testzeit und Laborwert festhalten; Search Console bzw. PSI-Felddaten separat auswerten. Ohne Felddaten eine repräsentative Stichprobe und echte Geräte prüfen, statt eine fehlende Anzeige als positives Ergebnis zu werten.
Kurz zusammengefasst
PageSpeed ist kein einzelner Wert und es gibt keine allgemeingültige Google-Regel „Eine Website muss in unter drei Sekunden laden“. Für die Nutzererfahrung zählen vor allem die Core Web Vitals: LCP für sichtbaren Hauptinhalt, INP für Reaktionsfähigkeit und CLS für Layoutstabilität. Google PageSpeed Insights kombiniert – sofern Daten verfügbar sind – reale Chrome-Nutzungsdaten mit einem simulierten Lighthouse-Test. Die Search Console zeigt, welche URL-Gruppen im Alltag Probleme haben. Für Ursachenanalyse, Seitentypen und Verbesserungen braucht es anschließend Browser-Entwicklertools und bei größeren Websites einen Crawl.
Stand der Recherche: 16. Oktober 2026. Das Titelbild und die erklärenden Prozessgrafiken sind KI-generierte Illustrationen; sie werden als solche gekennzeichnet und zeigen keine Messung deiner Website. Die Abbildung zur Messwertverteilung stammt aus der offiziellen Google-Dokumentation.
Inhaltsverzeichnis
- Klickbarer Empfehlungsbaum
- Was PageSpeed heute bedeutet
- Core Web Vitals und Zielwerte
- Labortest und Felddaten unterscheiden
- PageSpeed richtig analysieren
- Tools im Vergleich
- Die häufigsten Bremsen beheben
- PageSpeed nach Shopsystem und CMS
- Prioritäten und Kontrollplan
- Häufige Fragen
- Quellen und weiterführende Dokumentation
Was PageSpeed heute bedeutet
„PageSpeed“ wird im Alltag für mehrere Dinge verwendet: die Zeit bis Inhalte erscheinen, die Reaktionszeit auf Eingaben, die Stabilität des Layouts, einen Lighthouse-Score oder schlicht das Gefühl, dass sich eine Seite schnell anfühlt. Diese Größen hängen zusammen, sind aber nicht austauschbar. Ein einzelner Score beantwortet weder, wie sich alle Besuche anfühlen, noch welcher Codefehler die Ursache ist.
Für die Web-Nutzererfahrung verwendet Google derzeit drei Core Web Vitals. Die Kennzahlen werden bei Felddaten am 75. Perzentil bewertet und getrennt nach Mobilgeräten und Desktop betrachtet. Das bedeutet: Der Zielwert soll bei mindestens 75 Prozent der erfassten Seitenbesuche erreicht werden – nicht nur bei einem besonders günstigen Testlauf.[1]
Core Web Vitals: die aktuellen Zielwerte
LCP · Laden
Misst, wann das größte sichtbare Inhaltselement im Darstellungsbereich gerendert ist – oft ein Titel, ein Hero-Bild oder ein großes Produktbild.
Gut: höchstens 2,5 Sekunden
Verbesserungswürdig: über 2,5 bis 4 Sekunden
Schlecht: über 4 Sekunden
INP · Reaktion
Bewertet die Verzögerung zwischen Nutzerinteraktionen – etwa Tippen, Klick oder Tastatureingabe – und der nächsten sichtbaren Reaktion der Seite über den Besuch hinweg.
Gut: höchstens 200 Millisekunden
Verbesserungswürdig: über 200 bis 500 Millisekunden
Schlecht: über 500 Millisekunden
CLS · Stabilität
Misst unerwartete Verschiebungen sichtbarer Elemente. Ein typischer Fehler ist ein Button, der beim Laden nach unten springt, weil ein Bild oder Werbemodul keinen reservierten Platz hat.
Gut: höchstens 0,1
Verbesserungswürdig: über 0,1 bis 0,25
Schlecht: über 0,25
Die drei Zielwerte gelten am 75. Perzentil; für eine insgesamt bestandene Core-Web-Vitals-Bewertung müssen alle drei Kennzahlen den guten Bereich erreichen. „Verbesserungswürdig“ ist kein weiterer Core Web Vital, sondern eine Zwischenstufe zur Einordnung.[1]
Achtung bei älteren Ratgebern: First Input Delay (FID) wurde am 12. März 2024 durch INP als Core Web Vital abgelöst. FID erfasst nur die erste Interaktion, INP dagegen die Reaktionsfähigkeit über den Besuch hinweg. Seiten, die FID noch als aktuellen Zielwert nennen, sind an dieser Stelle veraltet.[5]
Diagnosewerte, die zusätzlich helfen
TTFB (Time to First Byte) zeigt, wie schnell der Server mit der ersten Antwort beginnt. FCP (First Contentful Paint), Total Blocking Time, Speed Index, Dateigröße und Zahl der Anfragen helfen beim Debugging. Sie sind nützlich, aber keine zusätzlichen Core Web Vitals. Auch ein Lighthouse-Performance-Score von 90 oder 100 ist kein Feldmesswert und kein eigenständiges Google-Rankingziel.
Labortest und Felddaten: warum beide wichtig sind
Labordaten: reproduzierbarer Test
Lighthouse lädt eine Seite unter festgelegten Bedingungen auf einem simulierten Gerät und Netzwerk. Der Test lässt sich schnell wiederholen und zeigt konkrete Hinweise, etwa render-blockierende Dateien, große Bilder oder JavaScript, das den Hauptthread beschäftigt. Er ist ideal, um Änderungen gegeneinander zu testen. Ein einzelner Lauf bildet aber nicht die Vielfalt realer Geräte, Verbindungen, Standorte und Besuche ab.
Felddaten: reale Besuche
PageSpeed Insights und die Search Console nutzen – sofern genügend Daten vorliegen – den Chrome User Experience Report (CrUX). Das sind aggregierte reale Chrome-Nutzungsdaten aus einem rollierenden Zeitraum von 28 Tagen. Sie zeigen, was Besucherinnen und Besucher tatsächlich erleben; sie erklären jedoch nicht automatisch, welcher Code dafür verantwortlich ist. Daten können auf URL- oder Ursprungsebene angezeigt werden und im Search-Console-Bericht zu ähnlichen URL-Gruppen zusammengefasst sein.[2][3]
Wenn PageSpeed Insights keine Felddaten für eine URL anzeigt, heißt das nicht automatisch, dass die Seite schnell oder langsam ist. Häufig reicht die Datenmenge für die URL nicht aus. Dann kann PSI auf Daten der gesamten Herkunft (Origin) zurückgreifen oder es stehen überhaupt keine Felddaten zur Verfügung. In diesem Fall mit Labortests und eigenen Messungen arbeiten und die fehlenden Felddaten nicht als „bestanden“ interpretieren.[1]
PageSpeed richtig analysieren: ein wiederholbarer Ablauf
Analysiere nicht nur die Startseite. Prüfe pro Seitentyp repräsentative Beispiele: Startseite, Kategorie, Produktdetail, Warenkorb/Checkout, Blogbeitrag und wichtige Landingpage. Bei einem CMS teilen sich viele Seiten dieselbe Vorlage; wird ein Fehler in dieser Vorlage behoben, profitieren häufig mehrere URLs.
1. Search Console: Problemumfang finden
Öffne den Core-Web-Vitals-Bericht der Google Search Console. Prüfe Mobilgeräte und Desktop getrennt, sortiere zuerst nach „Schlecht“ und beachte die URL-Gruppen. Der Bericht verwendet Felddaten und zeigt den Umfang des Problems; er ist kein Code-Debugger. Die Beispiel-URLs zuerst prüfen, weil sie die Gruppe repräsentieren können.[3]
2. PageSpeed Insights: Feld und Labor vergleichen
Rufe PageSpeed Insights auf und teste eine konkrete URL auf Mobilgeräten und Desktop. Lies zuerst den Feldbereich, dann den Lighthouse-Bericht. Notiere den LCP-Wert und das ermittelte Hauptelement, die Interaktionsdiagnosen für INP sowie Layoutverschiebungen. Nutze „Diagnosen“ und „Möglichkeiten“ als Ansatzpunkte – nicht als ungeprüfte To-do-Liste.[1]
3. Chrome DevTools: Ursache verifizieren
Mit Lighthouse erhältst du einen Labortest; mit dem Performance- und Network-Panel kannst du genauer sehen, wann Ressourcen geladen werden, welche Aufgabe den Hauptthread blockiert und welches Element den LCP auslöst. Wiederhole den Test in einem sauberen Browserprofil und nach Möglichkeit mehrfach. Teste auch echte Mobilgeräte und die wichtigsten Abläufe wie Suche, Filter, Warenkorb und Formular.
4. Crawl: Seitentypen und Ausreißer finden
Ein Crawl ergänzt den Einzeltest um viele URLs. Er zeigt, ob ein Problem auf der gesamten Produktvorlage, nur in einer Kategorie oder auf einzelnen Seiten auftritt. Für große Sites empfiehlt sich eine repräsentative Stichprobe oder ein Crawl mit kontrollierter Geschwindigkeit, statt ungebremst möglichst viele Anfragen an den Server zu senden.
Screaming Frog: Ladezeit für viele URLs kontrollieren
Der Screaming Frog SEO Spider ist ein Desktop-Crawler. In der kostenlosen Version lassen sich bis zu 500 URLs crawlen; für größere Crawls und erweiterte Funktionen ist eine Lizenz nötig. Der Anbieter nennt zum Recherchezeitpunkt 245 € pro Nutzer und Jahr für eine Lizenz mit Einzelplatz-Nutzung; Mengenrabatte gelten ab fünf Lizenzen. Preise und Steuern können sich ändern.[6][7]
- Website im Spider-Modus starten und Domain eingeben.
- Unter Configuration → API Access → PageSpeed Insights die kostenlose PSI-API verbinden, Messwerte auswählen und einen Crawl starten. Screaming Frog kann die API remote aufrufen und dadurch Lighthouse-Labordaten sowie verfügbare CrUX-Felddaten zu URLs in den Crawl aufnehmen. Ein lokaler Lighthouse-Lauf kann dagegen geschützte Testseiten erreichen, liefert aber keine CrUX-Felddaten.
- In den PageSpeed-, Mobile- und Lighthouse-Details die Kennzahlen, Einsparpotenziale und betroffenen URL-Muster vergleichen. Für die Feldperspektive die CrUX-Werte heranziehen, nicht nur den Lighthouse-Score.
- Unter Response Times die Antwortzeiten beim Crawl prüfen. Diese Werte zeigen die HTTP-Antwortzeit aus Sicht des Crawlers und helfen bei der Serverdiagnose. Sie sind keine vollständige Browser-Ladezeit und ersetzen weder PSI noch Felddaten.
Screaming Frog empfiehlt, Crawl-Geschwindigkeit und Zeitpunkt mit dem Website-Verantwortlichen abzustimmen und die Antwortzeiten zu überwachen. Das ist besonders wichtig bei Shops, großen CMS und Shared Hosting: Ein aggressiver Crawl kann zusätzliche Serverlast erzeugen.[6]
Tools im Vergleich: Einzeltest, Crawl oder laufendes Monitoring?
Ein häufiger Fehlkauf ist, ein einzelnes Tool zu suchen, das gleichzeitig Felddaten, Browserdiagnose, vollständigen Website-Crawl und Dauerüberwachung perfekt abdeckt. In der Praxis ergänzen sich die Werkzeuge. Entscheidend ist, ob du eine URL debuggen, tausende URLs priorisieren oder Veränderungen laufend überwachen möchtest.
Google PageSpeed Insights · kostenlos
Stärken: Labordiagnose plus CrUX-Felddaten in einer Ansicht; schnell für einzelne URLs, mobil und Desktop.
Grenzen: kein vollständiger Website-Crawl; Ursachen müssen mit DevTools oder weiteren Prüfungen validiert werden; Felddaten sind nicht für jede URL verfügbar.
Google Search Console · kostenlos
Stärken: reale Nutzungsdaten, mobile/Desktop-Trennung, Gruppen ähnlicher URLs und ein Überblick über betroffene Seiten.
Grenzen: begrenzte Beispiel-URLs und keine tiefe Code-Wasserfallanalyse; eine URL-Gruppe ist keine Liste sämtlicher Einzelseiten.
Chrome Lighthouse / DevTools · kostenlos
Stärken: kontrollierter Labortest, für eigene und teilweise geschützte Entwicklungsseiten geeignet; Performance- und Network-Panel helfen bei der Fehlersuche.
Grenzen: simuliertes Gerät und Netzwerk; ein Score ist keine Aussage darüber, was jeder echte Besucher erlebt.
Screaming Frog SEO Spider · kostenlos bis 500 URLs, danach Lizenz
Stärken: technischer SEO-Crawl, PSI-/CrUX-Daten auf URL-Ebene, Filter und Exporte; nützlich, um Seitentemplates und Ausreißer zu erkennen.
Grenzen: Desktop-Software, benötigt Ressourcen des eigenen Rechners; PSI-API-Limits und eine sinnvolle Crawl-Rate beachten. Keine dauerhafte Real-User-Überwachung.
Sitebulb · kostenpflichtiger Crawl
Stärken: verständliche, priorisierte technische Audits; Performance-Bericht kann Labordaten und Diagnosen über viele gecrawlte Seiten hinweg auswerten. Die Lite-Lizenz ist für kleine Audits begrenzt, Pro bietet zusätzliche Performance- und Mobilberichte; Cloud-Optionen ermöglichen wiederkehrende Crawl-Läufe.
Grenzen: kostenpflichtige Lizenz und weiterhin kein Ersatz für CrUX-/RUM-Felddaten. Die Preisstufe hängt von Plan und Abrechnung ab.[8][9]
GTmetrix · kostenloser Einstieg und kostenpflichtige Pläne
Stärken: detaillierte Einzelseitenberichte mit Wasserfall, Standort- und Geräteeinstellungen sowie geplanten Tests und Alarmen in bezahlten Tarifen.
Grenzen: primär Test- und Monitoring-Dienst für ausgewählte URLs, kein technischer SEO-Crawler für die gesamte Domain. Umfang und Retention richten sich nach Tarif; die Anbieter-Preise werden dynamisch ausgewiesen.[10]
DebugBear / SpeedCurve · Monitoring für Teams
Stärken: synthetische Tests können mit Real User Monitoring kombiniert werden; hilfreich, wenn Performance-Regressionen nach Releases automatisch auffallen sollen.
Grenzen: laufende Kosten abhängig von Tests, Seitenaufrufen, Projekten oder Teamumfang; RUM erfordert eine zusätzliche Einbindung und Datenschutzprüfung. Kein Ersatz für einen technischen SEO-Crawl.[11]
WebPageTest · kostenloser Testdienst und optionale Angebote
Stärken: wiederholbare Labortests, Wasserfall und detaillierte Ladeabläufe aus verschiedenen Testumgebungen; gut für technische Ursachenanalyse.
Grenzen: kein Ersatz für Felddaten oder eine Website-weite SEO-Auditlösung; Ergebnisse hängen von Standort, Gerät, Verbindung und Testkonfiguration ab.
Empfehlung: Für ein kleines Unternehmen reicht oft die Kombination aus Search Console, PSI und Chrome DevTools. Für eine Domain mit vielen Templates ergänzen Screaming Frog oder Sitebulb den Überblick. Für Teams, die nach jedem Release Regressionen erkennen müssen, sind synthetisches Monitoring und RUM sinnvoll. Weitere Website- und Tracking-Werkzeuge vergleichen wir im Beitrag „Die Top 10 Tools für Website-Analysen“.
Die häufigsten PageSpeed-Bremsen gezielt beheben
Wenn der LCP schlecht ist
- Das größte sichtbare Bild passend skalieren und komprimieren; moderne Formate wie WebP oder AVIF nutzen, wenn die Plattform sie unterstützt.
- Das LCP-Bild nicht mit pauschalem Lazy Loading verzögern. Bilder unterhalb des sichtbaren Bereichs dagegen bedarfsgerecht laden.
- Serverantwort, Bild-CDN, Cache, Bildpriorität und render-blockierende Ressourcen prüfen.
Wenn der INP schlecht ist
- Schwere JavaScript-Aufgaben und lange Main-Thread-Blockaden in DevTools lokalisieren.
- Unnötige Apps, Widgets, Tag-Manager-Tags und Drittanbieter-Skripte reduzieren oder später laden.
- Interaktionen auf der Seite messen: Suche, Filter, Varianten, Menü, Cookie-Dialog, Warenkorb und Checkout.
Wenn der CLS schlecht ist
- Für Bilder, Banner, Werbung und eingebettete Inhalte Platz reservieren.
- Schriften möglichst stabil laden und Layoutänderungen nach dem ersten Rendern vermeiden.
- Cookie-Banner, Empfehlungsleisten und Pop-ups auf spätes Einblenden ohne Layoutsprung prüfen.
Weitere häufige Ursachen sind zu langsames Hosting, dynamische Datenbankabfragen, unnötig große CSS- und JavaScript-Bundles sowie ungecachte Seiten. Bündeln, Minifizieren oder das verzögerte Laden aller Skripte ist jedoch keine automatische Lösung: Solche Einstellungen können Bedienung, Tracking, Filter oder Checkout beschädigen. Immer eine Änderung einzeln testen und anschließend die wichtigsten Conversion-Pfade prüfen.
PageSpeed nach Shopsystem und CMS optimieren
Ein System hat keinen festen PageSpeed-Wert. Hosting, Theme, Erweiterungen, Templates, Inhalte und die konkrete Konfiguration bestimmen das Ergebnis. Auch die mobile Ansicht kann deutlich anders ausfallen als der Desktop. Die folgenden Punkte sind Startpunkte für eine Diagnose, keine pauschale Garantie.
WordPress und WooCommerce
Gut geeignet für: redaktionelle Websites und Shops, deren Team viele Inhalte selbst pflegt.
Optimieren: gutes Hosting und PHP-/Objektcache als Basis; nur ein Page-Cache-Plugin verwenden; Plugins und Theme-Funktionen regelmäßig ausmisten; Bildabmessungen und responsive Varianten prüfen; LCP-Bild priorisieren; Datenbank und WooCommerce-Abfragen nur gezielt optimieren.
Werkzeuge: WP Rocket bietet unter anderem Page-Caching, Preload und JavaScript-Optimierung. Der Single-Tarif kostet laut Hersteller derzeit 49,95 € pro Jahr für eine Website. WP Rocket komprimiert Bilder nicht selbst; Imagify kann Bilder optimieren und WebP/AVIF-Varianten bereitstellen. Imagify hat einen kostenlosen Einstieg und kostenpflichtige Tarife nach Nutzung. Bei WooCommerce müssen Warenkorb, Checkout, eingeloggte Ansichten und personalisierte Seiten von Cache-Regeln ausgenommen oder gezielt getestet werden. Keine zwei Cache-/Minify-Plugins parallel betreiben.[12][13]
TYPO3
Gut geeignet für: umfangreiche Unternehmens- und Organisationsseiten mit anspruchsvollen Redaktions- und Rechtekonzepten.
Optimieren: TYPO3-Caching und Cache-Konfiguration für dynamische Plugins korrekt einsetzen; nicht benötigte Extensions und Frontend-Assets prüfen; Bilder in passende Größen ausgeben; Servercache, PHP-OPcache und CDN mit der Hosting-Konfiguration abstimmen. Fehler bei ungecachten Seiten separat messen.
Wichtig: Einstellungen hängen von TYPO3-Version und Deployment ab. Ältere Anleitungen zum pauschalen Zusammenfassen von Assets nicht blind übernehmen: In aktueller TYPO3-Dokumentation sind Asset-Verarbeitung und Caching versionsabhängig, und zusätzliche Verarbeitung kann ungecachte Requests verteuern. Für Template- und Extension-Änderungen ist häufig technische Unterstützung sinnvoll.[14][15]
Shopify
Gut geeignet für: Teams, die Hosting, Plattformbetrieb und Shopverwaltung möglichst weitgehend als Dienst nutzen möchten.
Optimieren: die Web-Performance-Berichte im Shopify-Admin nutzen und Ergebnisse nach Core Web Vital, Seitentyp, Gerät und Zeitraum vergleichen. Unnötige Apps, App-Embeds, externe Pixel, große Hero-Bilder, Karussells und Animationen prüfen. Wichtig: Das Deinstallieren einer App entfernt ihren Code nicht zwingend aus dem Theme. Nach App- oder Theme-Änderungen den Verlauf beobachten und betroffene Skripte beziehungsweise Theme-Reste kontrollieren.
Shopify stellt für reale Besuche Core-Web-Vitals-Berichte bereit; Daten können verzögert eintreffen und sind nur für einen begrenzten Zeitraum verfügbar. Ein möglichst hoher Score um jeden Preis ist kein sinnvolles Ziel – wichtig ist eine gute echte Nutzererfahrung auf den umsatzrelevanten Seiten.[16][17]
Shopware 6
Gut geeignet für: mittelgroße bis umfangreiche Shops mit konfigurierbaren Verkaufsprozessen und Produktkatalogen.
Optimieren: den eingebauten HTTP-Cache und gegebenenfalls einen Reverse Proxy sinnvoll konfigurieren; Cache-Warm-up und Produktionsmodus prüfen; Theme, Storefront-JavaScript, Plugins, Bildgrößen und Drittanbieter-Integrationen kritisch durchgehen. Caches nach Änderungen gezielt leeren und anschließend echte Produkt-, Such-, Warenkorb- und Checkout-Wege prüfen.
Viele redaktionelle und kaufmännische Aufgaben sind im Admin bedienbar. Server-, Cache- und Storefront-Tuning kann je nach Hosting und Erweiterungen aber Entwicklerwissen erfordern. Shopware beschreibt HTTP-Cache und Reverse-Proxy-Einsatz in der offiziellen Dokumentation.[18]
Wix, Webflow und Squarespace
Gut geeignet für: kleinere Websites und Teams, die Seiten visuell pflegen möchten, ohne Server und CMS selbst zu betreiben.
Optimieren: große Titelbilder passend zuschneiden, Videos und Animationen sparsam einsetzen, Schriftfamilien reduzieren, eingebettete Apps und eigenes Tracking kontrollieren. Wix wandelt hochgeladene Bilder laut Hilfezentrum automatisch in optimierte Formate um; Squarespace erstellt Bildvarianten und liefert WebP aus; Webflow bietet responsive Bilder und Empfehlungen zur Reduktion von Seitencode.
Der Plattformbetrieb ist einfacher, aber nicht jede technische Ebene ist frei konfigurierbar. Wenn ein Skript oder eine App den INP verschlechtert, muss oft die Funktion entfernt, ersetzt oder vom Anbieter angepasst werden. Auch hier messen: automatische Optimierung bedeutet nicht automatisch gute Core Web Vitals.[19][20][21]
Ein pragmatischer Fahrplan für Unternehmen
1. Basis ohne Zusatzkosten
Search Console und PSI prüfen, wichtige Seitentypen auswählen, Mobilgeräte und Desktop getrennt notieren.
2. Ursachen bestätigen
Lighthouse, DevTools und Netzwerk-Wasserfall einsetzen. Eine Ursache pro Änderung angehen, nicht zehn Performance-Optionen gleichzeitig umschalten.
3. Website-weit priorisieren
Bei vielen URLs Screaming Frog oder Sitebulb nutzen. Beginne mit wichtigen Templates und URLs mit viel Such- oder Umsatzpotenzial.
4. Ergebnis nachhalten
Labortest nach dem Release wiederholen, reale Felddaten weiter beobachten und Such-, Formular-, Kauf- und Checkout-Abläufe kontrollieren.
Kosten grob einordnen: Der Einstieg kann mit Google PSI, Search Console und DevTools ohne zusätzliche Lizenzkosten erfolgen. Ein Screaming-Frog-Einzelplatz kostet laut aktueller Preisseite 245 € pro Jahr; WP Rocket für eine WordPress-Website 49,95 € pro Jahr. Sitebulb, GTmetrix und RUM-/Monitoring-Dienste arbeiten mit gestaffelten Abos oder nutzungsabhängigen Plänen. Imagify bietet kostenlose und kostenpflichtige Bildoptimierung nach Nutzungsumfang. Die Preise beziehen sich auf die Anbieterangaben zum Recherchezeitpunkt; Steuern, Wechselkurse, Funktionsumfang und Tarifmodelle können sich ändern. Für die Optimierung selbst kommen – abhängig von Befund und CMS – interne Arbeitszeit, Hosting oder Entwicklungsleistung hinzu. Eine Lizenz ersetzt keine technische Umsetzung.
Nicht jede Warnung ist ein Projekt – aber jedes Problem braucht einen Besitzer.
Lege für jede Maßnahme fest, welche URL-Vorlage betroffen ist, welche Kennzahl verbessert werden soll und wie du die Änderung überprüfst. So wird aus einem Score ein konkreter Arbeitsplan.
Häufige Fragen zu PageSpeed
Muss eine Website in weniger als drei Sekunden laden?
Es gibt keine universelle Google-Vorgabe „unter drei Sekunden“. Für die Core Web Vitals gelten die genannten Schwellenwerte bei LCP, INP und CLS. Zusätzlich können Ladezeit und wahrgenommene Geschwindigkeit je nach Seite, Nutzung und Gerät anders bewertet werden. Entscheidend ist ein verlässlicher Feldwert am 75. Perzentil und ein funktionierender Nutzungspfad.
Ist ein PageSpeed-Score von 90 Pflicht?
Nein. Der Lighthouse-Score fasst Labormesswerte in einer veränderlichen Bewertung zusammen. Er eignet sich für reproduzierbare Tests, ist aber weder ein Core-Web-Vitals-Feldwert noch eine Rankinggarantie. Google empfiehlt, die Nutzererfahrung insgesamt zu betrachten; gute Core Web Vitals allein garantieren keine Spitzenpositionen.[4]
Warum ist mein PSI-Ergebnis beim nächsten Test anders?
Labormessungen können wegen Testserver, Netzwerk, Auslastung, Cache-Zustand und Drittanbieter-Skripten schwanken. Führe mehrere vergleichbare Läufe durch und vergleiche Felddaten getrennt davon. Feldwerte ändern sich langsamer, weil sie aggregierte reale Besuche über einen Zeitraum abbilden.
Warum zeigt die Search Console nicht jede einzelne URL?
Der Core-Web-Vitals-Bericht gruppiert ähnliche URLs und benötigt eine Mindestmenge an Felddaten. Eine Beispiel-URL kann eine Gruppe vertreten; fehlende Einzel-URLs bedeuten nicht automatisch, dass diese Seite fehlerfrei ist. Mit einem Crawl und gezielten PSI-Tests lässt sich die technische Stichprobe ergänzen.[3]
Was ist wichtiger: Mobil oder Desktop?
Beides ist getrennt zu betrachten. Mobilgeräte haben oft weniger Rechenleistung und langsamere Verbindungen, deshalb sind mobile Felddaten häufig besonders aufschlussreich. Bei einem Shop müssen zugleich Desktop-Nutzung und der gesamte Kaufprozess funktionieren.
Weiterführende Beiträge
Mehr zu Analysewerkzeugen findest du in unserem Beitrag „Die Top 10 Tools für Website-Analysen“. Für die Planung eines technischen Umbaus hilft außerdem unsere Relaunch-Checkliste.
Quellen und weiterführende Dokumentation
Für die fachlichen Grundlagen und Produktmerkmale wurden vorrangig offizielle Dokumentationen von Google, Browser- und Plattformanbietern verwendet. Preise und Funktionen können sich ändern; geprüft am 16. Oktober 2026.
- Google Developers: Über PageSpeed Insights – Feld- und Labordaten, Perzentil und Grenzen der Messungen.
- Google Search Central: Core Web Vitals und Google-Suchergebnisse – aktuelle Kennzahlen und Empfehlungen.
- Google Search Console-Hilfe: Core-Web-Vitals-Bericht – Felddaten, URL-Gruppen und Validierung.
- Google Search Central: Page Experience verstehen – Einordnung von Core Web Vitals im Suchranking.
- Chrome UX Report: Versionshinweise – Umstellung von FID auf INP.
- Screaming Frog: Konfiguration und PageSpeed-Insights-Integration – API, Remote-/Local-Modus und Crawl-Geschwindigkeit.
- Screaming Frog: Lizenz und Preise in Euro.
- Sitebulb Support: Performance Report – siteweite Performance-Audits.
- Sitebulb: Preis- und Lizenzmodelle.
- GTmetrix: Tarifübersicht und Monitoring-Funktionen.
- DebugBear: Dokumentation zu synthetischen Tests und Real User Monitoring.
- WP Rocket: Preise und enthaltene Performance-Funktionen.
- Imagify: Tarife für Bildoptimierung; ergänzend WP Rocket-Dokumentation zur Bildauslieferung.
- TYPO3-Dokumentation: Caching Framework.
- TYPO3-Dokumentation: Frontend-Assets.
- Shopify-Hilfe: Web-Performance-Berichte.
- Shopify-Hilfe: Leistung des Onlineshops verbessern.
- Shopware-Dokumentation: Performance-Tweaks, HTTP-Cache und Reverse Proxy.
- Wix-Hilfe: Bilder und Website-Performance.
- Webflow-Hilfe: Website-Geschwindigkeit optimieren.
- Squarespace-Hilfe: Seitengröße reduzieren und schnellere Ladezeiten.
Hinweis zur Einordnung: Empfehlungen wie „erst das LCP-Element identifizieren“ oder „Änderungen einzeln prüfen“ leiten sich aus den beschriebenen Messverfahren ab. Welche Maßnahme am meisten bringt, ist eine technische Einzelfallentscheidung und muss an Website, Seitentyp, Gerät und Geschäftsprozess gemessen werden.
Noch unsicher, welcher Weg für deine Website passt?
Wir unterstützen dich dabei, Messwerte richtig einzuordnen, die Ursache im jeweiligen System zu finden und die nächsten Schritte nach Wirkung und Aufwand zu priorisieren. Die Beratung startet mit deiner konkreten Website und ihren wichtigsten Seitentypen.