Wer den eigenen PageSpeed-Bericht öffnet, sieht meist eine lange Liste mit Meldungen wie “Renderblockierende Ressourcen eliminieren” oder “Nicht verwendetes JavaScript reduzieren”. Jede einzelne Meldung klingt nach einem eigenen Problem, das gelöst werden muss. Dieser Artikel ordnet die häufigsten Ursachen ein, erklärt, was dahintersteckt, und zeigt, warum aus vielen kleinen Punkten in Summe ein Projekt mit echtem Umfang wird.
Wo diese Meldungen überhaupt herkommen
Die genannten Meldungen stammen aus PageSpeed Insights beziehungsweise dem zugrunde liegenden Lighthouse-Report von Google, demselben Tool, mit dem sich auch die Core Web Vitals einer Website prüfen lassen.
Wie Du diesen Bericht aufrufst und was LCP, INP und CLS dabei bedeuten, erkläre ich hier."Core Web Vitals einfach erklärt"
Die folgenden Punkte gehören zu den Meldungen, die am häufigsten auftauchen, unabhängig von Branche oder Unternehmensgröße.
Renderblockierende Ressourcen
Bevor ein Browser eine Seite anzeigen kann, muss er zunächst CSS- und teils auch JavaScript-Dateien laden und verarbeiten. Liegen diese Dateien im Kopfbereich der Seite und sind groß oder zahlreich, verzögert sich die erste sichtbare Darstellung der Seite, obwohl der eigentliche Inhalt längst geladen wäre.
Die Lösung besteht meist darin, nur das CSS zu laden, das für den sichtbaren Bereich beim ersten Aufruf tatsächlich gebraucht wird, und den Rest erst nachzuladen. Bei JavaScript hilft häufig, Skripte mit den Attributen defer oder async einzubinden, damit sie die Darstellung der Seite nicht blockieren.
Ungenutztes CSS und JavaScript
Viele Websites laden vollständige CSS- und JavaScript-Dateien, dabei wird oft nur ein Bruchteil davon auf der jeweiligen Seite gebraucht. Besonders bei WordPress-Themes und Page-Buildern sammeln sich über die Zeit Styles und Skripte für Funktionen an, die auf der aktuellen Seite gar nicht vorkommen, aber trotzdem mitgeladen werden.
Das lässt sich beheben, indem nicht genutzter Code entfernt oder zumindest so aufgeteilt wird, dass jede Seite nur das lädt, was sie tatsächlich braucht. Bei gewachsenen WordPress-Seiten mit vielen Plugins ist das oft der aufwendigste Punkt auf dieser Liste.
Zu viele Drittanbieter-Skripte
Chat-Widgets, Tracking-Pixel von Werbeplattformen, eingebettete Videos und Social-Media-Buttons laden jeweils eigenen Code von externen Servern nach. Jedes einzelne Skript wirkt für sich harmlos, in Summe bremsen mehrere solcher Einbindungen eine Seite aber spürbar, gerade beim INP-Wert, also der Reaktionszeit auf Interaktionen.
In der Praxis hilft eine ehrliche Bestandsaufnahme: Welche dieser Skripte werden wirklich gebraucht, welche laufen nur noch mit, weil sie vor Jahren einmal eingebaut wurden. Nicht mehr genutzte Tools lassen sich in der Regel ohne Funktionsverlust entfernen.
Fehlendes Preload für wichtige Ressourcen
Preload ist ein Hinweis an den Browser, eine bestimmte Ressource, etwa das Hauptbild oder eine Schriftart, bevorzugt und möglichst früh zu laden, statt sie erst zu entdecken, nachdem der restliche Code verarbeitet wurde. Fehlt dieser Hinweis, lädt der Browser wichtige Elemente teils später als nötig.
Sinnvoll eingesetzt wird Preload meist für das größte sichtbare Element der Seite, das direkt den LCP-Wert beeinflusst, sowie für Schriftdateien, die sonst erst spät im Ladevorgang angefragt werden.
Google Fonts und Textdarstellung
Werden Schriftarten von einem externen Server wie Google Fonts geladen, entsteht dafür eine zusätzliche Verbindung zu einem fremden Server, die Zeit kostet, bevor die Schrift überhaupt zur Verfügung steht. Ohne die richtige Einstellung bleibt Text in dieser Zeit teils unsichtbar, statt zumindest in einer Ersatzschrift angezeigt zu werden.
Zwei gängige Lösungen: Schriftarten lokal auf dem eigenen Server statt bei Google einbinden, und die CSS-Eigenschaft font-display auf swap setzen, damit Text sofort in einer Systemschrift erscheint und erst danach zur eigentlichen Schriftart wechselt.
Fehlendes Lazy Loading
Lazy Loading bedeutet, dass Bilder und Videos außerhalb des sichtbaren Bereichs erst geladen werden, wenn ein Besucher tatsächlich dorthin scrollt, statt bereits beim ersten Seitenaufruf. Fehlt dieser Mechanismus, lädt der Browser unter Umständen zehn oder mehr Bilder gleichzeitig, obwohl anfangs nur zwei davon sichtbar sind.
Wichtig dabei: Das erste, sofort sichtbare Bild sollte bewusst von Lazy Loading ausgenommen werden, da es sonst selbst durch die Verzögerung des Mechanismus langsamer erscheint als nötig.
Alles rund um Format, Größe und Komprimierung von Bildern selbst behandle ich separat."Bilder richtig optimieren"
Serverantwortzeit und Komprimierung
Bevor überhaupt eine einzige Ressource geladen werden kann, muss der Server auf die erste Anfrage antworten. Diese Zeit, die sogenannte Time to First Byte, hängt stark vom Hosting ab. Ein überlasteter oder technisch veralteter Server kostet hier bereits wertvolle Zeit, bevor die eigentliche Seite überhaupt zu laden beginnt.
Zusätzlich sollte der Server Textinhalte wie HTML, CSS und JavaScript komprimiert ausliefern, üblicherweise über Gzip oder das modernere Brotli. Ohne diese Komprimierung werden unnötig große Dateien über die Leitung geschickt, die sich mit wenig Aufwand serverseitig deutlich reduzieren ließen.
Browser-Caching
Ohne passende Cache-Regeln lädt ein Browser bei jedem erneuten Besuch sämtliche Dateien komplett neu, selbst wenn sich seit dem letzten Besuch nichts geändert hat. Richtig eingerichtetes Caching weist den Browser dagegen an, unveränderte Dateien wie Logo, Schriftarten oder CSS für einen festgelegten Zeitraum lokal zu speichern.
Das wirkt sich zwar nicht auf den allerersten Besuch aus, beschleunigt aber jeden weiteren Seitenaufruf einer wiederkehrenden Besucherin spürbar.
Zu große DOM-Struktur
Der DOM ist die Struktur aus HTML-Elementen, aus denen eine Seite im Browser aufgebaut wird. Page-Builder und verschachtelte Layout-Systeme erzeugen dabei oft deutlich mehr Elemente, als für die sichtbare Gestaltung eigentlich nötig wären. Ein einfacher Textblock kann so leicht in einem Dutzend ineinander verschachtelter Container landen.
Eine zu große oder zu tief verschachtelte DOM-Struktur verlangsamt, wie schnell der Browser eine Seite berechnen und darstellen kann, und wirkt sich zusätzlich auf die Reaktionszeit bei Interaktionen aus.
Weiterleitungsketten
Jede Weiterleitung von einer URL zur nächsten kostet zusätzliche Zeit, da der Browser zunächst die erste Antwort abwarten muss, bevor er der nächsten Adresse folgen kann. Besonders bei mehrfachen Weiterleitungen hintereinander, etwa von http auf https und von dort auf eine Version mit www, summiert sich das spürbar.
Checkliste: Welche Punkte betreffen Deine Website?
Wer diese Liste einmal komplett durchgeht, merkt schnell: Jeder einzelne Punkt lässt sich für sich genommen lösen, in Summe berühren sie aber Hosting, Code, eingebundene Tools und die Struktur der Seite gleichzeitig. Genau deshalb bleibt PageSpeed bei den meisten Websites über Jahre hinweg ein Dauerthema statt einer einmal erledigten Aufgabe.
FAQ
Was ist ein guter PageSpeed-Score?
Ab etwa 90 Punkten gilt eine Seite als schnell, zwischen 50 und 89 Punkten besteht spürbarer Optimierungsbedarf, unter 50 Punkten liegt in der Regel eines oder mehrere der oben genannten Probleme vor. Der Score allein sagt aber wenig darüber aus, welches konkrete Problem dahintersteckt, dafür lohnt sich der Blick in die einzelnen Meldungen.
Muss ich wirklich alle Punkte dieser Liste umsetzen?
Nein. Die Punkte wirken sich unterschiedlich stark aus, je nach Website. Eine Seite mit vielen Drittanbieter-Skripten profitiert am meisten davon, genau dort anzusetzen, während bei einer anderen Seite die Serverantwortzeit oder ungenutztes CSS das größere Problem ist. Sinnvoll ist, mit den Punkten zu beginnen, die laut PageSpeed-Bericht den größten Effekt versprechen.
Wirkt sich PageSpeed direkt auf das Google-Ranking aus?
Ladezeit ist einer von mehreren Rankingfaktoren, aber kein isolierter Hebel, der allein über die Position entscheidet. Der stärkere Effekt zeigt sich meist indirekt: Eine langsame Seite verliert Besucher und das wirkt sich wiederum auf Absprungrate und Verweildauer aus, zwei Signale, die Google durchaus beachtet.
Wie oft sollte ich meine Website auf PageSpeed prüfen?
Nach jedem größeren Update, etwa neuen Plugins, einem neuen Theme oder zusätzlichen Skripten, lohnt sich ein erneuter Check. Unabhängig davon reicht bei den meisten Websites eine Prüfung alle paar Monate aus, um schleichende Verschlechterungen frühzeitig zu bemerken.
Kann ich diese Punkte selbst umsetzen, oder brauche ich dafür Hilfe?
Einzelne Punkte wie Bildkomprimierung oder das Setzen von font-display lassen sich mit etwas technischem Verständnis oft selbst lösen. Punkte wie ungenutztes CSS, eine zu tiefe DOM-Struktur oder die Serverkonfiguration betreffen dagegen meist den Code oder das Hosting direkt und erfordern entsprechende Erfahrung, um sie ohne neue Folgeprobleme umzusetzen.
