Pagespeed 2025: Die wichtigsten Hebel

Die Ladezeit einer Website ist ein direkter Ranking-Faktor. Google misst die Nutzererfahrung über die Core Web Vitals und bevorzugt Seiten die schnell laden, stabil aufgebaut sind und schnell auf Interaktionen reagieren. Gleichzeitig verlieren langsame Websites Besucher: wer länger als drei Sekunden warten muss, springt ab. Dieser Artikel zeigt die Maßnahmen die 2025 den größten Unterschied machen – sortiert nach Wirkung.

Core Web Vitals verstehen

Google bewertet die Seitengeschwindigkeit über drei Metriken, die sogenannten Core Web Vitals. Jede misst einen anderen Aspekt der Nutzererfahrung:

Largest Contentful Paint (LCP) misst wie schnell das größte sichtbare Element geladen wird – meistens ein Hero-Bild oder eine große Überschrift. Der Zielwert liegt bei unter 2,5 Sekunden. LCP ist die Metrik die Nutzer am stärksten wahrnehmen: sie zeigt wann die Seite „fertig” aussieht.

Interaction to Next Paint (INP) hat 2024 die alte FID-Metrik abgelöst. INP misst wie schnell die Seite auf Nutzerinteraktionen reagiert – Klicks, Tippen, Tastatureingaben. Der Zielwert liegt bei unter 200 Millisekunden. Langsames INP bedeutet: der Nutzer klickt auf einen Button und nichts passiert. Das frustriert.

Cumulative Layout Shift (CLS) misst visuelle Stabilität. Kennen Sie das: Sie wollen auf einen Link klicken, und in dem Moment verschiebt sich das Layout weil ein Bild oder eine Werbung nachgeladen wird? Das ist Layout Shift. Der Zielwert liegt bei unter 0,1.

Nur etwa 40 % aller Websites bestehen alle drei Core Web Vitals gleichzeitig. Die gute Nachricht: die meisten Probleme lassen sich mit wenigen gezielten Maßnahmen beheben.

Bilder optimieren – der größte Hebel

Bilder machen bei den meisten Websites 50–70 % des Gesamtgewichts aus. Hier liegt der mit Abstand größte Hebel für schnellere Ladezeiten.

Das richtige Format wählen: WebP ist der aktuelle Standard. Es liefert bei gleicher Qualität 25–35 % kleinere Dateien als JPEG. AVIF bietet noch bessere Kompression, wird aber noch nicht von allen Browsern unterstützt. Verwenden Sie WebP als Standardformat und AVIF als progressive Verbesserung über das <picture>-Element.

Responsive Images einsetzen: Liefern Sie nicht ein 2000px breites Bild an ein Smartphone. Nutzen Sie das srcset-Attribut um verschiedene Größen anzubieten. Der Browser wählt dann automatisch die passende Variante. Ein Hero-Bild das auf Desktop 1200px breit sein muss, braucht auf einem iPhone nur 400px.

Lazy Loading aktivieren: Bilder die beim Laden der Seite nicht sichtbar sind, sollten erst geladen werden wenn der Nutzer zu ihnen scrollt. Das HTML-Attribut loading="lazy" macht das ohne JavaScript. Wichtig: das erste sichtbare Bild – typischerweise das Hero-Bild – darf nicht lazy sein, sonst verschlechtert sich der LCP.

Bildmaße im HTML angeben: Setzen Sie immer width und height im <img>-Tag. Ohne diese Angaben weiß der Browser nicht wie viel Platz er reservieren soll und verschiebt das Layout wenn das Bild geladen wird. Das verursacht CLS-Probleme.

JavaScript reduzieren und verzögern

Nach Bildern ist JavaScript der zweitgrößte Performance-Killer. Jedes Script muss heruntergeladen, geparst und ausgeführt werden – und blockiert dabei oft den Seitenaufbau.

Messen Sie zunächst wie viel JavaScript Ihre Seite lädt. Öffnen Sie Chrome DevTools, gehen Sie zum Network-Tab und filtern Sie nach JS. Bei den meisten Unternehmenswebsites finden Sie dort: Cookie-Consent-Banner, Analytics-Scripte, Chat-Widgets, Slider-Bibliotheken, Social-Media-Embeds und jQuery.

Die effektivsten Maßnahmen:

• Laden Sie Analytics und Tracking erst nach der Nutzerinteraktion (Cookie-Consent). Das allein spart oft 200–500ms beim initialen Laden.
• Ersetzen Sie schwere Bibliotheken durch leichte Alternativen. jQuery für einen einfachen Slider? Das sind 90 KB für eine Funktionalität die in 20 Zeilen nativem JavaScript umsetzbar ist.
• Nutzen Sie defer oder async für alle Scripts die nicht sofort benötigt werden. defer ist in den meisten Fällen die richtige Wahl: das Script wird parallel heruntergeladen und erst ausgeführt wenn das HTML vollständig geparst ist.
• Entfernen Sie nicht genutzte Scripts. Viele WordPress-Plugins laden JavaScript auf jeder Seite, auch wenn das Plugin dort gar nicht verwendet wird.

CSS kritisch und unkritisch trennen

CSS blockiert standardmäßig das Rendering. Der Browser wartet bis alle CSS-Dateien geladen sind, bevor er die Seite anzeigt. Bei einer einzigen großen CSS-Datei bedeutet das: der Nutzer sieht nichts, bis alles geladen ist.

Die Lösung: Critical CSS. Das sind die Styles die für den sichtbaren Bereich der Seite (above the fold) benötigt werden. Diese Styles inline im <head> einbetten, den Rest asynchron nachladen.

Für WordPress gibt es Plugins wie WP Rocket oder Autoptimize die das automatisieren. Für statische Seiten und Custom-Builds nutzen Sie Tools wie Critical von Addy Osmani oder konfigurieren Sie es in Ihrem Build-Prozess.

Eine weitere Maßnahme: ungenutzte CSS-Regeln entfernen. Die meisten WordPress-Themes laden hunderte CSS-Regeln die auf der aktuellen Seite nicht benötigt werden. PurgeCSS oder ähnliche Tools können nicht verwendete Styles automatisch entfernen und die CSS-Datei um 70–90 % verkleinern.

Server-Response-Time verbessern

Bevor irgendein Bild oder Script geladen werden kann, muss der Server erst einmal antworten. Die Time to First Byte (TTFB) misst wie lange das dauert. Der Zielwert liegt bei unter 800 Millisekunden, idealerweise unter 200ms.

Häufige Ursachen für langsame TTFB:

• Günstiges Shared Hosting mit überlasteten Servern
• WordPress ohne Caching-Plugin – jede Anfrage baut die Seite dynamisch aus der Datenbank auf
• Zu viele Datenbankabfragen durch schlecht optimierte Plugins
• Server in den USA statt in Europa (physische Distanz = Latenz)

Die effektivste Maßnahme für WordPress: ein Page-Caching-Plugin wie WP Super Cache oder WP Rocket. Statt jede Anfrage dynamisch zu verarbeiten, liefert der Server eine fertig generierte HTML-Datei. Das reduziert die TTFB typischerweise von 800ms auf unter 100ms.

Für geschäftskritische Websites lohnt sich ein Wechsel auf Managed WordPress Hosting wie Raidboxes, Cloudways oder Kinsta. Diese Anbieter haben optimierte Server-Konfigurationen und integriertes Caching.

CDN und Caching richtig einsetzen

Ein Content Delivery Network verteilt Ihre Website-Dateien auf Server weltweit. Besucher bekommen die Dateien vom nächstgelegenen Server – das reduziert die Latenz erheblich. Ein CDN kann die Ladezeit um 30–50 % verbessern, besonders für Besucher die weit vom Hosting-Server entfernt sind.

Cloudflare bietet einen kostenlosen CDN-Dienst der für die meisten Unternehmenswebsites ausreicht. Die Einrichtung dauert 15 Minuten: DNS-Einträge umleiten, und Cloudflare cached automatisch statische Dateien wie Bilder, CSS und JavaScript.

Browser-Caching konfigurieren: Setzen Sie Cache-Header so dass statische Dateien im Browser des Besuchers gespeichert werden. Ein Besucher der Ihre Website zum zweiten Mal aufruft, muss dann nicht alles neu herunterladen. Empfohlene Cache-Dauer: 1 Jahr für Bilder und Fonts, 1 Monat für CSS und JavaScript.

Fonts performant laden

Web-Fonts sind ein oft übersehener Performance-Faktor. Jeder Font-Schnitt ist eine zusätzliche Datei die heruntergeladen werden muss. Drei Schriftarten mit je zwei Schnitten (regular + bold) bedeuten sechs Font-Dateien – oft 200–400 KB insgesamt.

Effektive Maßnahmen:

• Fonts lokal hosten statt von Google Fonts zu laden. Das spart einen zusätzlichen DNS-Lookup und eine separate Verbindung. Außerdem ist es DSGVO-konform. Alle Details dazu im Artikel Font-Loading-Optimierung für bessere Web-Performance.
• WOFF2 als Format verwenden – es bietet die beste Kompression und wird von allen modernen Browsern unterstützt.
• Font-Schnitte reduzieren. Brauchen Sie wirklich Light, Regular, Medium, SemiBold und Bold? Oft reichen Regular und Bold.
• font-display: swap setzen damit Text sofort in einer Fallback-Schrift angezeigt wird während der Web-Font lädt. Das verhindert unsichtbaren Text (FOIT).
• Font-Subsetting: Wenn Sie nur lateinische Zeichen brauchen, entfernen Sie kyrillische und griechische Glyphen aus der Font-Datei. Das spart 30–50 % Dateigröße.

Ladezeit messen und monitoren

Optimierung ohne Messung ist Raten. Nutzen Sie diese Tools um Ihre aktuelle Performance zu bewerten und Fortschritte zu tracken – einen detaillierten Vergleich finden Sie im Artikel Ladezeit messen: Die besten Tools im Überblick:

PageSpeed Insights ist Googles offizielles Tool. Es zeigt sowohl Lab-Daten (simulierte Tests) als auch Field-Daten (echte Nutzerdaten aus dem Chrome User Experience Report). Die Field-Daten sind entscheidend – sie zeigen was Google tatsächlich für das Ranking verwendet.

Google Search Console hat einen eigenen Core Web Vitals Report. Er zeigt welche Seiten die Zielwerte nicht erreichen und gruppiert sie nach Problemtyp. Das ist der beste Startpunkt um zu sehen wo Handlungsbedarf besteht.

Chrome DevTools bieten die detaillierteste Analyse. Unter dem Lighthouse-Tab können Sie einen vollständigen Performance-Audit durchführen. Der Performance-Tab zeigt im Detail was beim Laden passiert: welche Ressourcen wann geladen werden, wo Engpässe sind und welche Scripts das Rendering blockieren.

Messen Sie nicht nur einmal, sondern regelmäßig. Performance kann sich schleichen verschlechtern – ein neues Plugin hier, ein größeres Bild dort, und plötzlich dauert der Seitenaufbau doppelt so lang. Ein monatlicher Check in PageSpeed Insights reicht um Verschlechterungen früh zu erkennen.

Die richtige Reihenfolge der Optimierung

Wenn Sie mit der Pagespeed-Optimierung anfangen, ist die Reihenfolge entscheidend. Beginnen Sie mit den Maßnahmen die den größten Effekt haben und am einfachsten umzusetzen sind:

1. Bilder komprimieren und in WebP konvertieren – größter Einzeleffekt, wenig Aufwand
2. Caching-Plugin installieren (WordPress) – dramatische TTFB-Verbesserung
3. Unbenutztes JavaScript entfernen oder verzögern – oft der zweitgrößte Effekt
4. Critical CSS implementieren – verbessert LCP spürbar
5. Fonts lokal hosten und optimieren – mittlerer Effekt, einmaliger Aufwand
6. CDN einrichten – besonders wichtig bei internationalem Publikum
7. Hosting evaluieren – wenn trotz aller Optimierungen die TTFB über 500ms liegt

Ergänzend hilft ein korrekt eingerichtetes SSL-Zertifikat dabei, HTTP/2 zu aktivieren, was Multiplexing ermöglicht und die Anzahl offener Verbindungen reduziert. Auch die Search Console zeigt im Core Web Vitals Report, welche Seiten Handlungsbedarf haben.

Nicht alles auf einmal machen. Optimieren Sie einen Bereich, messen Sie das Ergebnis, dann den nächsten. So sehen Sie welche Maßnahme wie viel gebracht hat – und vermeiden es, stundenlang an Stellschrauben zu drehen die in der Praxis keinen messbaren Unterschied machen.