PageSpeed-Optimierung in 10 Maßnahmen

PageSpeed-Optimierung heißt meist, drei Dinge kleiner oder schneller zu machen: das größte Bild, die Antwort des Servers und die fremden Skripte. Google misst das Ergebnis mit den Core Web Vitals und nutzt sie in seinen Rankingsystemen, als eines von vielen Signalen. Viele Websites schaffen die Werte nicht. Laut Web Almanac 2025 des HTTP Archive bestanden auf dem Smartphone nur 48 Prozent der Websites alle drei Core Web Vitals, am Desktop 56 Prozent.

Wenn Sie gleich anfangen wollen, nehmen Sie die fünf Schritte zum Einstieg nach den zehn Maßnahmen.

Welche Maßnahmen gehören zur PageSpeed-Optimierung?

Zur PageSpeed-Optimierung gehören vor allem kleinere Bilder, ein schnell antwortender Server und weniger Code, besonders von Drittanbietern. Die zehn Maßnahmen stehen in der Reihenfolge, in der sie nach unserer Einschätzung bei den meisten Seiten am meisten bringen.

1. Bilder verkleinern und in WebP oder AVIF ausliefern

Auf 76 Prozent der mobilen Seiten ist das größte sichtbare Element ein Bild (Web Almanac 2025). Wer Bilder kleiner macht, verbessert deshalb meist direkt den LCP (Largest Contentful Paint), also die Zeit, bis dieses größte Element dasteht. Ein unbearbeitetes Foto aus Kamera oder Smartphone ist schnell mehrere Megabyte groß. Viel zu viel für eine Webseite.

• Modernes Format verwenden. WebP komprimiert laut Google im Schnitt rund 30 Prozent stärker als JPEG, ohne dass die Bildqualität leidet. Verlustbehaftete AVIF-Bilder sind laut MDN etwa 50 Prozent kleiner als vergleichbare JPEGs. AVIF zeigen die aktuellen Versionen von Chrome, Edge, Firefox und Safari an. Binden Sie AVIF und WebP über das picture-Element ein, dann bekommt jeder Browser das beste Format, das er darstellen kann.
• Richtige Größe. Ein Bild, das auf der Seite 800 Pixel breit angezeigt wird, muss nicht 4000 Pixel breit sein. Liefern Sie jedes Bild in der Größe aus, in der es angezeigt wird, am besten responsiv mit srcset.
• Komprimierung. Exportieren Sie mit der niedrigsten Qualitätsstufe, bei der Sie noch keinen Unterschied sehen. Legen Sie dafür zwei oder drei Stufen nebeneinander. Gegenüber der höchsten Stufe ist der Unterschied oft kaum zu erkennen, die Datei aber deutlich kleiner.
• Lazy Loading. Bilder weiter unten auf der Seite lädt der Browser mit dem Attribut loading="lazy" erst beim Scrollen, ganz ohne JavaScript. Das Bild im sichtbaren Bereich gehört nicht dazu. Laut Web Almanac 2025 laden trotzdem rund 16 Prozent der Seiten ausgerechnet ihr LCP-Bild verzögert.

2. Die Server-Antwortzeit (TTFB) senken

Die Time to First Byte misst, wie lange der Server braucht, bis er auf eine Anfrage antwortet. Diese Zeit kommt vor allem anderen und steckt deshalb in jedem späteren Messwert. Meist helfen serverseitiges Caching, eine aktuelle PHP-Version (WordPress empfiehlt 8.3 oder neuer) und eine aufgeräumte Datenbank.

Google bewertet eine TTFB bis 0,8 Sekunden als gut, bis 1,8 Sekunden als verbesserungswürdig und alles darüber als schlecht. Lighthouse meldet schon ab 600 Millisekunden Wartezeit auf das Hauptdokument Handlungsbedarf. Bleibt der Server trotz Caching langsam, ist oft der Tarif der Engpass, gerade ein günstiges Shared Hosting. Dann hilft ein größerer Tarif oder ein anderer Anbieter.

3. Drittanbieter-Skripte prüfen

Jedes eingebundene Tool, ob Statistik, Tag Manager, Chat-Widget, Social-Media-Button oder Werbetracker, bringt eigenes JavaScript mit und baut Verbindungen zu fremden Servern auf. Häufig lädt die Seite selbst schnell, und erst diese Skripte ziehen den Ladevorgang in die Länge. Tag Manager, Pixel, Heatmap-Tool, Chat-Widget und mehrere Statistikdienste gleichzeitig sind selten alle nötig.

Gehen Sie die Liste regelmäßig durch. Stellen Sie bei jedem Skript drei Fragen. Wird es genutzt? Gibt es eine leichtere Alternative? Kann es später laden? Was niemand auswertet, fliegt raus.

Auf Seiten mit Einwilligungsbanner klickt Lighthouse nicht auf „Akzeptieren“. Alles, was erst nach der Zustimmung lädt, fehlt deshalb im Labortest. Ihre Besucher, die zustimmen, laden es trotzdem, und das landet in den Felddaten. Liegen Laborwert und Felddaten weit auseinander, schauen Sie zuerst hier nach.

4. CSS und JavaScript verkleinern und komprimieren

Jedes Kilobyte an CSS und JavaScript muss der Browser herunterladen und verarbeiten. Minimierung entfernt Leerzeichen, Kommentare und Zeilenumbrüche aus dem Code. Komprimierung mit Gzip oder Brotli verkleinert Textdateien bei der Übertragung zusätzlich deutlich. Ob Ihr Server das tut, sehen Sie in den Chrome DevTools im Reiter Netzwerk. Steht bei einer CSS- oder JS-Datei im Antwort-Header content-encoding der Wert „br“ oder „gzip“, ist die Komprimierung aktiv.

Entfernen Sie außerdem CSS und JavaScript, das niemand braucht. Der Bereich Coverage in den Chrome DevTools zeigt, welcher Code auf einer Seite ausgeführt wird und welcher nur mitgeladen wird.

5. Render-Blocking vermeiden und Critical CSS einbetten

Critical CSS ist der kleinste Teil des CSS, den der Browser für den sichtbaren Bereich der Seite braucht. Steht dieser Teil direkt im HTML-Head, kann der Browser sofort zeichnen, ohne auf externe CSS-Dateien zu warten.

CSS- und JavaScript-Dateien, die das Rendern blockieren, verzögern den LCP direkt, denn der Browser zeichnet erst, wenn sie geladen sind. Laden Sie nicht kritisches CSS asynchron oder über media-Attribute nach und JavaScript mit async oder defer.

6. Nur den Code laden, den die Seite braucht

Unter HTTP/2 und HTTP/3 laufen viele Anfragen parallel über dieselbe Verbindung. Die reine Zahl der Dateien bremst deshalb kaum noch. Teuer bleibt jeder zusätzliche fremde Server, denn dafür fallen DNS-Auflösung und TLS-Handshake erneut an. Wichtig ist heute, wie viel Code geladen wird und in welcher Reihenfolge.

Liefern Sie nur den Code aus, den die jeweilige Seite braucht (Code-Splitting statt eines großen Pakets). Icons bauen Sie besser als Inline-SVG ein. Ein Icon-Font lädt ein ganzes Schriftpaket für wenige Symbole und wird von Screenreadern häufig falsch vorgelesen. Was vorgezogen gehört, steht unter Maßnahme 5, welche fremden Skripte bleiben dürfen, unter Maßnahme 3.

7. Browser-Caching einrichten

Wer Ihre Seite ein zweites Mal aufruft, muss nicht alles neu herunterladen, wenn das Browser-Caching stimmt. Setzen Sie Cache-Control-Header für statische Dateien. CSS, JavaScript, Bilder und Schriften dürfen Monate oder ein Jahr im Cache bleiben. Hängen Sie einen Inhalts-Hash an die Dateinamen, dann lädt der Browser nach einer Änderung automatisch die neue Version.

8. Webschriften schlank laden

Eine Schriftfamilie in sechs Schnitten sind bis zu sechs Dateien, die der Browser holen muss, bevor der Text in der richtigen Schrift erscheint.

• Nur benötigte Schnitte laden. Wenn Sie nur Regular und Bold verwenden, laden Sie nicht auch Light, Medium, SemiBold und ExtraBold.
• Subset erstellen. Laden Sie nur die Zeichen, die Sie brauchen. Für deutsche Seiten reicht meist der lateinische Zeichensatz.
• font-display: swap oder optional. Mit swap zeigt der Browser sofort eine Systemschrift und tauscht sie später gegen die Webschrift. Dabei kann der Text springen. Mit optional bleibt es bei der Systemschrift, wenn die Webschrift nicht rechtzeitig da ist. Wem ein ruhiges Layout wichtiger ist als die Schrift beim ersten Aufruf, nimmt optional.
• Schriften selbst hosten. Liegen die Schriftdateien auf Ihrem eigenen Server statt bei Google Fonts, spart das einen DNS-Lookup, und die IP-Adresse Ihrer Besucher geht beim Seitenaufruf nicht an Google.
• Variable Fonts prüfen. Brauchen Sie drei oder mehr Schnitte, ersetzt eine Variable-Font-Datei mehrere statische und ist dann meist kleiner. Bei nur zwei Schnitten vergleichen Sie vorher die Dateigrößen.

9. Ein Content Delivery Network (CDN) nutzen

Ein CDN verteilt Ihre statischen Dateien auf Server an vielen Standorten, und jeder Besucher bekommt sie vom nächstgelegenen. Stehen Ihr Server und fast alle Besucher in Deutschland, ist der Gewinn klein. Es lohnt sich, wenn Kunden aus Österreich, der Schweiz oder von weiter her kommen.

Bedenken Sie bei der Auswahl, dass auch der CDN-Anbieter die IP-Adressen Ihrer Besucher erhält, wie bei extern geladenen Schriften.

10. Die Technik passend wählen

Die Technik legt fest, wie schnell eine Seite höchstens werden kann. Seiten, die vorab als fertiges HTML erzeugt werden (Static Site Generation, etwa mit Next.js oder Astro), liefert der Server ohne Rechenarbeit aus. Bei WordPress kommt ein Seiten-Cache-Plugin dem nahe. Ein WordPress mit schwerem Page Builder auf knapp bemessenem Shared Hosting startet dagegen mit viel Code und langsamer Serverantwort. Das lässt sich verbessern, aber nur bis zu einer Grenze.

Wie Websites mit einem bestimmten CMS oder Framework in der Praxis abschneiden, können Sie selbst nachsehen. Der Tech Report des HTTP Archive weist je Technologie aus, welcher Anteil der Websites alle drei Core Web Vitals besteht, mit Felddaten aus dem Chrome User Experience Report und getrennt nach Mobil und Desktop. Sehen Sie die Zahlen dort selbst nach, denn sie verschieben sich von Monat zu Monat. Wir bauen Websites mit WordPress und mit Next.js, haben also an beiden ein geschäftliches Interesse. Einen ausführlichen Vergleich finden Sie im Ratgeber WordPress oder Next.js.

In welcher Reihenfolge gehen Sie am besten vor?

Fangen Sie bei Bildern, Server und Drittanbieter-Skripten an. Dort liegt nach unserer Einschätzung bei den meisten Seiten der größte Gewinn für den geringsten Aufwand. Für die Bilder sprechen auch die Zahlen. Das größte Element ist meist ein Bild, und am LCP scheitern Websites häufiger als an INP und CLS (Zahlen im nächsten Abschnitt).

1. Das LCP-Element finden. PageSpeed Insights zeigt im Diagnoseteil, welches Element den LCP bestimmt. Ist es ein Bild, exportieren Sie es in Anzeigegröße als WebP oder AVIF und entfernen Sie loading="lazy".
2. Die TTFB ablesen. Liegt sie über 0,8 Sekunden, schalten Sie das Seiten-Caching ein oder sprechen Sie mit Ihrem Hoster.
3. Jedes externe Skript prüfen. Nehmen Sie die drei Fragen von oben und entfernen Sie, was niemand auswertet.
4. CSS und JavaScript minimieren. Bei WordPress erledigt das meist ein Cache- oder Optimierungs-Plugin, bei Next.js der Build. Prüfen Sie danach im Reiter Netzwerk, ob die Komprimierung greift.
5. Render-blockierende Dateien auflösen. Lighthouse nennt die Dateien, die das erste Zeichnen aufhalten. Kritisches CSS kommt in den Head, der Rest lädt später.

Caching, Schriften und CDN kommen danach, sie bringen nach unserer Einschätzung meist weniger. Meldet PageSpeed Insights einen schlechten INP oder CLS, ziehen Sie die Punkte aus dem jeweiligen Abschnitt weiter unten vor.

Was sind Core Web Vitals und welche Werte gelten als gut?

Core Web Vitals sind drei Messwerte von Google für das Erlebnis auf einer Seite. LCP misst, wann das größte Element sichtbar ist (gut bis 2,5 Sekunden), INP, wie schnell die Seite auf Eingaben reagiert (gut bis 200 Millisekunden), und CLS, wie stark sich das Layout verschiebt (gut bis 0,1).

• Largest Contentful Paint (LCP). Das größte sichtbare Element kann ein Bild sein, ein Video-Poster, ein Hintergrundbild oder ein großer Textblock.
• Interaction to Next Paint (INP). Gewertet werden Mausklicks, Antippen auf dem Touchscreen und Tastatureingaben während des ganzen Besuchs, Scrollen zählt nicht. Maßgeblich ist die langsamste Interaktion. Nur bei sehr vielen Interaktionen lässt Google Ausreißer weg, je 50 Interaktionen fällt die langsamste heraus. INP hat am 12. März 2024 den Vorgänger FID (First Input Delay) abgelöst, der nur die Verzögerung der ersten Interaktion gemessen hat. Anleitungen, die noch FID nennen, sind in diesem Punkt veraltet.
• Cumulative Layout Shift (CLS). Elemente springen oft, wenn Bilder ohne Größenangaben laden oder Werbebanner nachträglich erscheinen. Gewertet wird das schlechteste Sitzungsfenster. Das ist eine Folge von Verschiebungen mit weniger als einer Sekunde Abstand und höchstens fünf Sekunden Gesamtdauer.

Google bewertet die drei Werte an echten Besuchen im 75. Perzentil, getrennt für Mobil und Desktop, und stuft die Seite danach als „gut“, „verbesserungswürdig“ oder „schlecht“ ein. Am häufigsten scheitert es am LCP. Mobil hatten 2025 nur 62 Prozent der Websites einen guten LCP, beim INP waren es 77 und beim CLS 81 Prozent (Web Almanac 2025).

Wie verbessern Sie LCP, INP und CLS gezielt?

Setzen Sie bei der Kennzahl an, die PageSpeed Insights oder die Search Console als verbesserungswürdig oder schlecht ausweist. Beim LCP sind das Server und größtes Bild, beim INP lange JavaScript-Aufgaben und beim CLS Elemente ohne reservierten Platz.

LCP verbessern

Der LCP hängt vor allem daran, wie schnell der Server antwortet und wie schnell danach das größte Element geladen ist.

• Serverantwort zuerst. Die Time to First Byte ist kein Core Web Vital, steckt aber in jedem LCP-Wert. Antwortet der Server langsam, bleibt jede Bildoptimierung Stückwerk (siehe Server-Antwortzeit oben).
• Das LCP-Element nicht bremsen. Ist das größte sichtbare Element ein Bild, gehört es nicht ins Lazy Loading. Geben Sie ihm fetchpriority="high" oder laden Sie es per preload vor. Laut Web Almanac 2025 setzen erst 17 Prozent der mobilen Seiten mit LCP-Bild fetchpriority="high", preload nur rund 2 Prozent.
• Inhalt nicht erst per JavaScript aufbauen. Single-Page-Anwendungen, die den gesamten Inhalt im Browser per JavaScript erzeugen, kommen oft auf schlechte LCP-Werte. Server-Side Rendering (SSR) oder Static Site Generation (SSG) liefern den Inhalt als fertiges HTML aus.

INP verbessern

Der Browser erledigt JavaScript und Darstellung in einem einzigen Arbeitsstrang, dem Main Thread. Ist der belegt, bleibt Ihr Klick liegen.

• Lange Tasks aufbrechen. Solange eine lange JavaScript-Aufgabe den Main Thread belegt, kann der Browser nicht auf Klicks reagieren. Teilen Sie lange Tasks in kleinere Abschnitte, verlagern Sie rechenintensive Arbeit in Web Worker und entfernen Sie ungenutzten Code.
• Event-Handler schlank halten. Nach einem Klick sollte zuerst die sichtbare Rückmeldung erscheinen. Alles, was für diese Rückmeldung nicht nötig ist, stellen Sie zurück, bis der Browser sie gezeichnet hat.
• Fremde Skripte später laden. Statistik, Chat-Widgets und Tracking belegen ebenfalls den Main Thread. Laden Sie sie mit defer oder erst, wenn der Besucher sie benutzt.
• DOM klein halten. Je mehr Elemente eine Seite enthält, desto aufwendiger werden Stil- und Layoutberechnungen, sobald eine Interaktion etwas ändert. Eine schlanke HTML-Struktur hält diese Arbeit klein.

CLS verbessern

Reservieren Sie Platz für alles, was später nachlädt.

• Platz für Bilder und Videos reservieren. Geben Sie width und height an oder nutzen Sie die CSS-Eigenschaft aspect-ratio. Dann hält der Browser den Platz frei, bevor das Medium geladen ist. Laut Web Almanac 2025 hat auf 62 Prozent der mobilen Seiten mindestens ein Bild keine festen Maße.
• Nachgeladene Inhalte mit festen Maßen. Werbeflächen, eingebettete Inhalte und dynamische Komponenten bekommen ihren Platz vorab, statt beim Erscheinen den Text zu verschieben.
• Nichts über sichtbaren Inhalt schieben. Ein Element, das oberhalb bereits sichtbarer Inhalte eingefügt wird, drückt alles nach unten und treibt den CLS in die Höhe. Ein Cookie-Hinweis, der als Overlay über der Seite liegt, verschiebt dagegen nichts.
• Webschriften ohne Sprung. Hat eine nachgeladene Webschrift andere Maße als die Ersatzschrift, springt der Text beim Wechsel. Laden Sie wichtige Schriftdateien per preload vor, dann kommen sie früher an. Ganz ohne Sprung geht es mit font-display: optional (siehe Webschriften oben).

Mit welchen Werkzeugen messen Sie PageSpeed?

Den Stand bei echten Besuchern zeigen PageSpeed Insights und der Core-Web-Vitals-Bericht der Search Console. Die Ursachen finden Sie mit Lighthouse und den Live-Metriken der Chrome DevTools. Alle vier sind kostenlos.

Wichtig ist der Unterschied zwischen Labordaten und Felddaten. Labordaten sind simulierte Messungen unter festen Bedingungen. Sie helfen, Ursachen zu finden und eine Änderung vorher und nachher zu vergleichen. Felddaten stammen von echten Besuchern und zeigen, was Ihre Kunden erleben. Die Schwellenwerte der Core Web Vitals beziehen sich auf die Felddaten. Ein guter Lighthouse-Score allein heißt also noch nicht, dass Ihre Seite sie besteht.

Wie Ihre Seite im Vergleich zu Wettbewerbern dasteht, zeigt der Ladezeit-Check auf dieser Website. Er misst Ihre Seite und bis zu drei Wettbewerber in einem Durchgang und zeigt dabei die Felddaten echter Besucher, soweit Google für die Seite welche hat. Er ist kostenlos und braucht keine Anmeldung.

Sind Core Web Vitals ein Rankingfaktor?

Ja, Google nutzt die Core Web Vitals in seinen Rankingsystemen, aber als eines von vielen Signalen und nicht als Ersatz für relevanten Inhalt.

Google schreibt selbst, dass es kein einzelnes entscheidendes Signal gibt. Gute Werte in Berichten wie dem Core-Web-Vitals-Bericht der Search Console bringen eine Seite nicht automatisch ganz nach oben. Die Suche zeigt die relevanteste Seite auch dann, wenn sie langsam ist. Ins Gewicht fällt die Nutzerfreundlichkeit vor allem, wenn mehrere Seiten die Frage gleich gut beantworten. Ein schneller Auftritt mit dünnem Inhalt hat deshalb in der Regel das Nachsehen gegen einen langsameren mit der besseren Antwort.

Was bringt PageSpeed-Optimierung für Ihre Website?

Sie macht die Seite für Besucher spürbar schneller und kann bei Google helfen, wenn mehrere gleich relevante Seiten konkurrieren. Einen bestimmten Platz sichert sie nicht.

Wie viele Anfragen das bringt, lässt sich nicht pauschal sagen. Eine oft zitierte Untersuchung hat Deloitte im Auftrag von Google 2020 veröffentlicht. Ausgewertet wurden über 30 Millionen Sitzungen auf den mobilen Websites von 37 Marken. Bei Seiten zur Lead-Generierung ging eine um 0,1 Sekunden bessere Ladezeit damit einher, dass 21,6 Prozent mehr Nutzer bis zur Formularseite kamen. Das zeigt die Richtung. Auf Ihre Seite hochrechnen lässt sich die Zahl nicht.

Messen Sie vorher und nachher mit denselben Werkzeugen. Scheitert Ihre Seite nur am LCP, setzen Sie bei Bild und Server an. Ob das reicht, zeigt der Labortest sofort und die Felddaten nach rund vier Wochen. Die Ladezeit ist ein Baustein der technischen Suchmaschinenoptimierung. Was sonst dazugehört, beschreibt die Seite zur SEO-Betreuung.

Wollen Sie die Maßnahmen nicht selbst umsetzen, klären wir im kostenlosen Erstgespräch per Video, was bei Ihrer Seite ansteht. Vorher zeigt der Ladezeit-Check, wo sie steht. Steht ohnehin ein Neubau an, finden Sie Ablauf und Preise unter Webdesign.