Pagespeed

Eine langsame Website kostet Besucher, Conversions und Google-Rankings – das gilt für einen Wiesbadener Steuerberater genauso wie für einen Onlineshop aus dem Frankfurter Umland. Pagespeed ist kein optionaler Bonus, sondern ein messbarer Rankingfaktor und direkter Einfluss auf die Nutzererfahrung. In diesem Ratgeber zeigt HEEY, wie Ladezeiten entstehen, wie man sie präzise misst und welche Maßnahmen wirklich etwas bringen.

Was Pagespeed bedeutet – und warum er mehr ist als eine Zahl

Pagespeed bezeichnet die Zeit, die eine Webseite benötigt, um im Browser vollständig dargestellt zu werden. Dabei geht es nicht nur um den Moment, in dem der erste Pixel erscheint, sondern um ein Bündel von Metriken: Wann kann ein Nutzer mit der Seite interagieren? Wann ist der größte sichtbare Inhalt geladen? Wann hören unkontrollierte Layoutverschiebungen auf? Google fasst diese Werte unter den Core Web Vitals zusammen.

Für Unternehmen im Rhein-Main-Gebiet, die lokale Suchbegriffe wie „Zahnarzt Mainz-Kastel“ oder „Werbeagentur Wiesbaden“ anvisieren, ist Pagespeed besonders relevant: Der lokale Wettbewerb ist dicht, und ein Unterschied von einer Sekunde Ladezeit kann darüber entscheiden, ob ein Nutzer auf der eigenen Seite bleibt oder zum Mitbewerber wechselt. Pagespeed ist damit kein rein technisches Thema, sondern ein Geschäftsfaktor.

Die wichtigsten Metriken: Core Web Vitals im Überblick

Google bewertet Seitengeschwindigkeit primär anhand der Core Web Vitals. Diese drei Kernmetriken sind seit 2021 offizieller Rankingfaktor und werden im Google Search Console Bericht „Core Web Vitals“ je nach Gerätekategorie ausgewiesen.

• Largest Contentful Paint (LCP): Misst, wann das größte sichtbare Element – oft ein Hero-Bild oder eine Überschrift – vollständig geladen ist. Zielwert: unter 2,5 Sekunden.
• Interaction to Next Paint (INP): Seit März 2024 ersetzt INP den alten FID-Wert und misst die Reaktionszeit der Seite auf Nutzereingaben. Zielwert: unter 200 Millisekunden.
• Cumulative Layout Shift (CLS): Quantifiziert unerwartete Layoutverschiebungen, etwa wenn ein Banner nachlädt und Text nach unten schiebt. Zielwert: unter 0,1.

Daneben gibt es ergänzende Metriken wie Time to First Byte (TTFB) und First Contentful Paint (FCP), die zwar keine direkten Rankingfaktoren sind, aber wichtige Diagnosewerte darstellen. Ein hoher TTFB deutet beispielsweise auf Serverprobleme oder fehlende Caching-Konfigurationen hin – ein häufiges Problem bei günstigen Shared-Hosting-Angeboten, die viele kleine Unternehmen aus Kostengründen nutzen.

Pagespeed messen: Die richtigen Werkzeuge

Bevor Maßnahmen ergriffen werden, braucht es eine solide Datenbasis. Die wichtigsten kostenlosen Werkzeuge sind Google PageSpeed Insights, Lighthouse (direkt im Chrome DevTools integriert), WebPageTest und der Core-Web-Vitals-Bericht in der Google Search Console. Jedes Tool hat seinen spezifischen Nutzen: PageSpeed Insights kombiniert Labordaten mit echten Felddaten aus dem Chrome User Experience Report (CrUX), während WebPageTest detaillierte Wasserfall-Diagramme liefert.

Ein häufiger Fehler: Nur den Desktop-Score zu prüfen und den mobilen Wert zu ignorieren. Da Google Mobile-First-Indexierung betreibt, ist der mobile Score der entscheidende. Gerade Websites von Handwerksbetrieben oder Gastronomen aus Wiesbaden-Biebrich oder Mainz, die häufig mit veralteten WordPress-Themes arbeiten, erzielen auf Mobilgeräten oft Scores unter 40 – obwohl die Desktop-Version akzeptabel aussieht. Der Score allein sagt wenig; entscheidend sind die konkreten Fehlermeldungen und Optimierungshinweise, die die Tools ausgeben.

Bilder optimieren: Der größte Hebel bei den meisten Websites

Unkomprimierte oder falsch dimensionierte Bilder sind in der Praxis der häufigste Grund für schlechte LCP-Werte. Ein Bild, das als 3.000 × 2.000 Pixel große JPEG-Datei mit 4 MB hochgeladen wurde, aber nur in einer 800-Pixel-Spalte dargestellt wird, verschwendet Bandbreite und verzögert den Seitenaufbau erheblich. Die Lösung: Bilder vor dem Upload auf die tatsächliche Darstellungsgröße skalieren, moderne Formate wie WebP oder AVIF verwenden und Lazy Loading für Bilder unterhalb des sichtbaren Bereichs aktivieren.

Für WordPress-Websites – die im Rhein-Main-Raum bei kleinen und mittelständischen Unternehmen nach wie vor dominieren – übernehmen Plugins wie ShortPixel oder Imagify die Konvertierung und Komprimierung automatisch. Wichtig: Das LCP-Element, also das erste große Bild im sichtbaren Bereich, sollte explizit nicht lazy-loaded werden, da es sonst den LCP-Wert verschlechtert. Stattdessen empfiehlt sich ein fetchpriority="high"-Attribut im HTML.

Server, Hosting und Caching: Die Basis stimmt oft nicht

Viele Pagespeed-Probleme beginnen nicht beim Frontend, sondern beim Server. Ein zu langsamer TTFB – also die Zeit bis zum ersten Byte der Serverantwort – lässt sich durch kein noch so ausgefeiltes Frontend-Optimierungskonzept vollständig kompensieren. Ursachen sind überlastete Shared-Hosting-Server, fehlende PHP-Opcode-Caches (wie OPcache), unkonfigurierte Datenbankabfragen oder ein physisch weit entfernter Serverstandort.

Für Websites, die primär Nutzer im Rhein-Main-Gebiet ansprechen, empfiehlt sich ein Hosting mit Rechenzentrum in Deutschland – idealerweise Frankfurt am Main, das zu den wichtigsten Internetknoten Europas gehört. Ein Content Delivery Network (CDN) wie Cloudflare kann statische Ressourcen zusätzlich beschleunigen, ersetzt aber kein ordentliches serverseitiges Caching. Für WordPress bieten Plugins wie WP Rocket oder W3 Total Cache eine weitgehend automatisierte Caching-Konfiguration, die für die meisten Anwendungsfälle ausreicht.

JavaScript und CSS: Render-Blocking-Ressourcen eliminieren

Browser können eine Seite erst dann vollständig rendern, wenn alle im <head> eingebundenen CSS- und JavaScript-Dateien geladen und verarbeitet wurden. Sogenannte Render-Blocking-Ressourcen verzögern also den sichtbaren Seitenaufbau, selbst wenn der eigentliche HTML-Inhalt längst übertragen wurde. Typische Verursacher sind eingebundene Schriften von Google Fonts, jQuery-Bibliotheken, Consent-Management-Skripte und Tracking-Pixel, die synchron im Kopfbereich der Seite laden.

• CSS: Kritisches CSS, das für den sichtbaren Bereich benötigt wird, inline in den <head> einbetten; restliches CSS asynchron laden.
• JavaScript: Alle nicht zwingend sofort benötigten Skripte mit defer oder async auszeichnen oder ans Ende des <body> verschieben.
• Google Fonts: Schriften lokal hosten statt von Google-Servern laden – das spart einen DNS-Lookup und einen Verbindungsaufbau zu einem externen Server.
• Drittanbieter-Skripte: Tag Manager, Chat-Widgets und Social-Media-Embeds kritisch prüfen und wo möglich verzögert laden (Lazy Load via Facade-Pattern).

Gerade Websites, die über die Jahre gewachsen sind und zahlreiche Plugins, Tracking-Tools und Marketingskripte angesammelt haben, leiden unter diesem Problem. Eine Bestandsaufnahme aller geladenen Drittanbieter-Ressourcen ist hier der erste Schritt – und führt nicht selten dazu, dass veraltete oder doppelt eingebundene Skripte entfernt werden können.

Typische Fehler und wie man sie vermeidet

In der Praxis begegnen HEEY dieselben Muster immer wieder: Ein Relaunch wird ohne Pagespeed-Anforderungen im Briefing umgesetzt, sodass die neue Website zwar optisch modern ist, aber technisch schlechter abschneidet als die alte. Oder ein Page Builder wie Elementor oder Divi wird mit Dutzenden Widgets und globalen Stilen überladen, ohne dass die generierten CSS- und JS-Dateien anschließend bereinigt werden. Auch das Einbinden von YouTube-Videos direkt per iFrame ist ein klassischer CLS- und Performance-Killer.

Ein weiterer häufiger Fehler: Optimierungsmaßnahmen werden einmalig durchgeführt und dann nicht mehr überprüft. Jedes neue Plugin, jedes neue Tracking-Pixel und jedes neue Bild kann die Pagespeed-Werte wieder verschlechtern. Sinnvoll ist daher ein regelmäßiges Monitoring – etwa monatlich über die Google Search Console oder ein automatisiertes Tool wie Screaming Frog in Kombination mit der PageSpeed Insights API. So lassen sich Regressionen früh erkennen, bevor sie sich auf Rankings auswirken.

Realistische Erwartungen: Was Pagespeed-Optimierung leistet

Ein PageSpeed-Score von 100 auf mobilen Geräten ist für die meisten produktiven Websites mit Tracking, Consent-Management und dynamischen Inhalten kein realistisches Ziel – und auch nicht notwendig. Entscheidend ist, dass die Core Web Vitals-Schwellenwerte für echte Nutzer eingehalten werden, also die Felddaten (CrUX) im grünen Bereich liegen. Ein Score von 70–85 auf Mobilgeräten kann bereits ausreichen, wenn die zugrundeliegenden Metriken stimmen.

Verbesserungen der Ladezeit wirken sich nicht über Nacht auf Rankings aus. Google benötigt Zeit, um neue Felddaten zu akkumulieren; erste Veränderungen im Core-Web-Vitals-Bericht der Search Console sind frühestens nach vier bis sechs Wochen zu erwarten. Direkt messbar sind dagegen Verbesserungen in der Absprungrate und der durchschnittlichen Sitzungsdauer – Metriken, die sich in Google Analytics 4 unmittelbar nach dem Go-live einer optimierten Version beobachten lassen.

Pagespeed im lokalen SEO-Kontext: Warum es für Rhein-Main-Unternehmen besonders zählt

Lokale Suchanfragen werden überwiegend mobil gestellt – ein Nutzer, der auf dem Weg vom Wiesbadener Hauptbahnhof zum Büro schnell einen Handwerker oder ein Restaurant sucht, wartet keine drei Sekunden auf eine Seite, die sich aufbaut. Für Unternehmen, die über Google Maps und lokale Suchergebnisse gefunden werden wollen, ist die mobile Pagespeed-Performance damit unmittelbar geschäftsrelevant. Schlechte Core Web Vitals können dazu beitragen, dass eine Seite in den lokalen Rankings hinter Wettbewerbern zurückfällt, die technisch sauberer aufgestellt sind.

Besonders in Branchen mit hohem lokalem Wettbewerb – Immobilien, Gastronomie, Gesundheitsdienstleistungen, Rechtsanwälte – kann Pagespeed ein entscheidender Differenzierungsfaktor sein. Wenn zwei Anbieter aus Wiesbaden-Erbenheim oder Darmstadt inhaltlich vergleichbar aufgestellt sind, kann die technische Performance den Ausschlag geben. HEEY empfiehlt daher, Pagespeed nicht als isoliertes Projekt, sondern als dauerhaften Bestandteil des technischen SEO-Monitorings zu behandeln.