Ihre Website ist langsam, und GTMetrix zeigt über 130 HTTP-Requests pro Seite an?

Dabei handelt es sich nicht um eine abstrakte Zahl aus einem Bericht. Jeder Request ist ein Browser-Aufruf an den Server für eine Datei: ein Skript, ein Stylesheet, ein Bild oder eine Schriftart. Je mehr Requests es gibt, desto länger starren Besucher auf einen leeren Bildschirm. Laut Portent reduziert eine Ladeverzögerung von 0 auf 3 Sekunden die Conversion um 2,5%. Und jede weitere Sekunde darüber hinaus kostet weitere 4,4%.

Das Problem mit HTTP-Requests ist nicht, dass sie existieren. Es ist, dass die meisten WordPress-Seiten weit mehr davon erzeugen als nötig. Im Folgenden finden Sie fünf konkrete Schritte, die die Anzahl der Requests reduzieren, ohne dass Sie Ihre Seite von Grund auf neu entwickeln müssen.

💡 Kurzübersicht:

• Entfernen Sie ungenutzte Plugins und Themes, die auf jeder Seite zusätzliche Requests erzeugen
• Optimieren Sie Bilder: Dateien komprimieren, ungenutzte Bilder entfernen, Icons zu Sprites zusammenfassen
• Führen Sie CSS und JavaScript in 1-2 Dateien zusammen und aktivieren Sie die Minifizierung
• Richten Sie verzögertes Laden für Skripte ein, die das Rendern der Seite blockieren
• Aktivieren Sie Caching und CDN, damit wiederkehrende Besucher nicht die gesamte Seite neu laden müssen

Schritt 1. Ballast entfernen

Jedes installierte Plugin bringt Dateien mit sich. PHP, CSS, JavaScript: Jede dieser Dateien erzeugt einen HTTP-Request, wenn die Seite geladen wird. Zwanzig Plugins bedeuten fast hundert Requests allein beim Start, noch bevor irgendein Inhalt erscheint.

Das Erste, was zu tun ist, ist ein Audit. Öffnen Sie Plugins → Installierte Plugins und fragen Sie sich ehrlich: Welche sind für die Funktion der Seite entscheidend und welche liegen nur „für alle Fälle" herum? Der SEO-Analyzer, den Sie vor einem Jahr installiert und zweimal geöffnet haben, ist ein Kandidat für die Entfernung. Das Social-Icons-Plugin ebenfalls, wenn Sie die Links bereits im Footer eingefügt haben.

Eine eigene Kategorie sind Plugins, die sich mit Servern von Drittanbietern verbinden. Live-Chat, Streaming-Radio, Push-Benachrichtigungen. Jedes dieser Plugins erzeugt zusätzliche externe HTTP-Requests an Drittserver. Löschen Sie alles, ohne das die Seite funktionieren kann. Brauchen Sie es einmal im Monat? Installieren Sie es für einen Tag und entfernen Sie es dann wieder.

Dieselbe Regel gilt für Themes. Behalten Sie unter Design → Themes nur Ihr aktives Theme und ein Backup (zum Beispiel das Standard-Theme Twenty Twenty-Five). Löschen Sie den Rest.

Wenn ein Plugin benötigt wird, aber nur auf einer bestimmten Seite, laden Sie es selektiv. Asset CleanUp: Page Speed Booster macht genau das. Es ist ein kostenloses Plugin mit über 100.000 aktiven Installationen und einer Bewertung von 4,7 auf WordPress.org.

Das Plugin scannt die Seite, zeigt eine Liste der geladenen CSS- und JS-Dateien an und ermöglicht es Ihnen, bestimmte Dateien auf bestimmten Seiten, Beitragstypen oder seitenweit zu deaktivieren. Brauchen Sie Contact Form 7 nur auf der Kontaktseite? Deaktivieren Sie es überall sonst, und die Skripte werden nicht geladen, wo das Formular nicht verwendet wird.

🔗 Asset CleanUp auf WordPress.org

Optimieren Sie bei der Gelegenheit auch Ihre Datenbank. Nach der Bereinigung von Plugins verbleiben deren Einstellungen und Datensätze in den Tabellen und sollten ebenfalls entfernt werden. Prüfen Sie auch auf defekte Links: Jede Weiterleitung ist ein zusätzlicher HTTP-Request.

Um das Ausmaß des Problems vorher und nachher klar zu sehen, testen Sie Ihre Seite in GTMetrix:

Der erste Durchlauf zeigt die Basislinie: Anzahl der Requests, gesamte Seitengröße, Ladezeit. Führen Sie nach jedem Schritt in diesem Artikel den Test erneut aus. So sehen Sie, welche Änderungen die größte Wirkung hatten.

Schritt 2. Bilder optimieren

Bilder sind das größte „Gewicht" auf einer durchschnittlichen WordPress-Seite. Laut HTTP Archive machen Bilder auf Desktop-Seiten etwa 44% der gesamten Seitengröße aus. Und jedes Bild ist ein HTTP-Request.

Beginnen Sie damit, ungenutzte Dateien zu entfernen. Filtern Sie unter Medien → Mediathek nach „Nicht angehängt". Dies sind Bilder, die keinem Beitrag zugeordnet sind. Wenn sie nicht im Theme oder Footer verwendet werden, löschen Sie sie.

Als Nächstes kommt die Komprimierung. Plugins wie WP Compress erledigen dies automatisch: Wenn Sie ein Bild hochladen, durchläuft es einen Cloud-Optimierer, wird ohne sichtbaren Qualitätsverlust komprimiert und in WebP oder AVIF konvertiert. Diese Formate sind bei gleicher visueller Qualität deutlich leichter als JPEG. Laut Google reduziert WebP die Dateigröße im Vergleich zu JPEG um durchschnittlich 25-35%.

WP Compress hat über 10.000 aktive Installationen, eine Bewertung von 4,5 von 5 und über 1,1 Millionen Downloads auf WordPress.org. Die ersten 100 Bilder sind kostenlos, genug, um den Unterschied zu sehen.

🔗 WP Compress auf WordPress.org

Komprimierung allein reduziert nicht die Anzahl der HTTP-Requests. Aber sie reduziert die Größe jeder Datei, was weniger Übertragungszeit bedeutet. In Kombination mit den anderen Schritten ergibt sich ein spürbarer Geschwindigkeitsschub.

CSS-Sprites: eine Datei statt zehn

Wenn Sie ein Dutzend kleiner Icons auf einer Seite haben (soziale Netzwerke, Pfeile, Bewertungssterne), lädt jedes als separater Request. Ein CSS-Sprite löst das: Alle Icons werden in einer Datei zusammengefasst, und CSS zeigt den benötigten Ausschnitt an.

So funktioniert es: Fünf Bilder bedeuten fünf Server-Requests. Dieselben fünf Bilder, zu einem Sprite kombiniert, bedeuten einen Request. Online-Tools wie CSS Sprite Generator können Sprites für Sie erstellen. Grundlegende CSS-Kenntnisse sind erforderlich, um die background-position für jedes Icon festzulegen.

Hinweis: Wenn Ihr Server HTTP/2 unterstützt, laden Dateien asynchron innerhalb einer einzigen Verbindung. In diesem Fall sind die Einsparungen durch Sprites weniger auffällig. In der Praxis lädt ein Dutzend Icons in einer Datei jedoch immer noch schneller als zehn separate.

Schritt 3. CSS und JavaScript zusammenführen und minifizieren

Eine typische WordPress-Seite hat über 40 JS-Dateien und über 20 CSS-Dateien. Jede einzelne ist ein separater HTTP-Request. Das summiert sich auf über 60 Server-Aufrufe allein für Skripte und Styles, die alle laden, bevor irgendein Inhalt erscheint.

Minifizierung entfernt alles Unnötige aus Dateien: Leerzeichen, Zeilenumbrüche, Kommentare. Die Datei wird leichter, aber die Anzahl der HTTP-Requests bleibt gleich.

Zusammenführung fasst mehrere Dateien zu einer zusammen. Aus fünf CSS-Dateien werden zwei (eine für den sichtbaren Bereich, eine für alles andere). Aus fünf JS-Dateien ebenso. Und statt zehn Requests sind es nur noch zwei oder drei.

Das beliebteste kostenlose Tool dafür ist Autoptimize. Ein Plugin mit einer Million aktiven Installationen und einer Bewertung von 4,7. In den Einstellungen gibt es drei Kontrollkästchen: HTML, CSS und JS optimieren. Aktivieren Sie alle drei und sehen Sie sofortige Ergebnisse.

Für eine feinere Steuerung gibt es WP Rocket, eine Premium-Lösung, die Dateien zusammenführt, minifiziert und Caching in einer Oberfläche hinzufügt.

Prüfen Sie Ihre Website nach dem Zusammenführen stets im Inkognito-Modus: Gelegentlich zerstört das Zusammenführen von Dateien das Layout. Sollte etwas nicht korrekt aussehen, deaktivieren Sie das Zusammenführen für die problematische Datei und belassen Sie es bei der Minifizierung.

🔗 Offizielle Website von WP Rocket

Ein wichtiger Hinweis noch: Das Zusammenführen von Dateien ist kein Allheilmittel. Wenn ein Plugin externe Skripte von einem CDN lädt (Google Fonts, reCAPTCHA, YouTube-Player), können Sie diese nicht zusammenführen. Sie können sie lediglich verzögern oder asynchron laden, womit wir beim nächsten Schritt wären.

Schritt 4: Render-blockierende Skripte behandeln

Der Browser liest eine Seite von oben nach unten. Wenn er auf <script src="..."> im <head> trifft, stoppt er das Rendering, lädt das Skript vollständig herunter und fährt erst dann fort. Besucher sehen in dieser Zeit eine leere Seite.

Die Lösung besteht darin, Skripte, die für das Rendern des ersten Bildschirms nicht benötigt werden, an das Ende der Seite zu verschieben oder das Attribut async/defer hinzuzufügen. Der Unterschied:

• defer: Das Skript lädt im Hintergrund, wird aber strikt nach Abschluss des HTML-Parsings und in der Reihenfolge ausgeführt, in der es eingebunden wurde;
• async: Das Skript lädt und wird bei der ersten Gelegenheit ausgeführt, ohne garantierte Reihenfolge.

Für WordPress gibt es ein kostenloses Plugin namens Async JavaScript. Es fügt ausgewählten Skripten über eine übersichtliche Oberfläche async oder defer hinzu. Es funktioniert direkt nach der Installation, erfordert aber Vorsicht: Wenn ein mit async hinzugefügtes Skript vor einem anderen ausgeführt werden muss, kann die Seite kaputtgehen.

Ein sicherer Ansatz ist, mit einem Skript zu testen, die Seite im Inkognito-Modus zu prüfen und dann zum nächsten überzugehen.

WP Rocket kann Skripte ebenfalls zurückstellen: Gehen Sie zu Dateioptimierung → JavaScript verzögert laden. Wählen Sie „Verzögert" und fügen Sie jQuery zu den Ausnahmen hinzu, da die meisten WordPress-Themes und -Plugins davon abhängen.

Ergebnis: Die Seite beginnt früher mit dem Rendern, auch wenn sich die Gesamtzahl der HTTP-Requests nicht geändert hat. Besucher sehen Inhalte, während die restlichen Skripte im Hintergrund laden.

Schritt 5: Caching und CDN aktivieren

Caching reduziert HTTP-Requests bei wiederholten Besuchen direkt. Die Mechanik ist einfach: Der Browser speichert statische Dateien (CSS, JS, Bilder, Schriftarten) lokal. Beim nächsten Seitenaufruf holt er die Datei aus dem Cache, anstatt sie vom Server anzufordern. Null HTTP-Requests für diese Datei.

Serverseitiges Caching ist die nächste Stufe: Der Server liefert eine bereits zusammengestellte HTML-Seite aus, anstatt Dutzende PHP-Abfragen an die Datenbank auszuführen. Caching-Plugins (WP Rocket, Flying Press, W3 Total Cache) erledigen das automatisch.

Ein CDN (Content Delivery Network) ist ein weltweites Netzwerk von Servern. Anstatt Dateien für einen Besucher in Brasilien von Ihrem Hosting in den Niederlanden zu laden, liefert das CDN sie vom nächstgelegenen Knotenpunkt aus. Zudem bieten CDN-Anbieter oft Komprimierung, Minifizierung und Bildoptimierung direkt ab Werk.

Cloudflare ist eine kostenlose Option, die grundlegende Anforderungen abdeckt: CDN, DDoS-Schutz, kostenloses SSL.

Installieren Sie das Cloudflare-Plugin für WordPress. Es verbindet Ihre Seite mit dem CDN und bietet grundlegende Einstellungen direkt aus dem Admin-Bereich. Für eine feinere Steuerung gehen Sie zum Cloudflare-Dashboard: Aktivieren Sie Auto Minify für CSS/JS/HTML, Brotli-Komprimierung und Rocket Loader für asynchrones Laden von Skripten.

🔗 Cloudflare auf WordPress.org

Mit Caching und CDN sinkt die Anzahl der HTTP-Requests für wiederkehrende Besucher drastisch. Erster Besuch: vollständiger Ladevorgang. Zweiter Besuch: Die meisten Dateien kommen aus dem Browser-Cache und dem nächstgelegenen CDN-Knoten, ohne jegliche Aufrufe an Ihren Server.

Bonus: Prüfen, ob Ihr Server HTTP/2 unterstützt

HTTP/2 ist ein Protokoll, das mehrere Dateien über eine einzige TCP-Verbindung überträgt. Der Browser wartet nicht, bis Datei Nr. 1 fertig heruntergeladen ist, bevor er Datei Nr. 2 anfordert; sie laden parallel. Dies reduziert die Auswirkungen einer hohen Anzahl von HTTP-Requests: 60 Dateien über HTTP/2 laden schneller als dieselben 60 über HTTP/1.1.

Prüfen Sie Ihren Server mit dem KeyCDN HTTP/2 Test-Tool. Geben Sie Ihre Domain ein und klicken Sie auf „Test". Das Ergebnis „HTTP/2 is supported" bedeutet, dass Multiplexing funktioniert.

Zeigt der Test HTTP/1.1 an, kontaktieren Sie Ihren Hoster. Die meisten modernen Hosting-Anbieter (SiteGround, Cloudways, Kinsta) aktivieren HTTP/2 standardmäßig. Bei Shared Hosting aus den 2010er-Jahren ist das möglicherweise nicht der Fall. Prüfen Sie auch Ihre PHP-Version: Ein Upgrade auf eine moderne PHP-Version bringt einen spürbaren Leistungsschub, während veraltete Versionen Anfragen deutlich langsamer verarbeiten. Wenn Ihr Hoster weder das Protokoll noch die PHP-Version aktualisiert, könnte es an der Zeit sein, einen Hosterwechsel in Betracht zu ziehen.

Wenn Sie das Videoformat bevorzugen, finden Sie hier eine visuelle Anleitung zur Reduzierung von HTTP-Requests in WordPress (12 Minuten).

⁉️🤔 Häufig gestellte Fragen

Wie viele HTTP-Requests gelten für WordPress als normal?

Ein Zielbereich liegt bei 30 bis 60 pro Seite. Alles über 80-90 erfordert Optimierung. GTMetrix und Pingdom zeigen in ihren Berichten konkrete Zahlen an. Nach Anwendung der fünf Schritte in diesem Artikel ist es realistisch, von 130 auf 35-45 Requests zu sinken.

„Ich habe eine Seite mit Elementor, und sie hat bereits über 100 Requests. Ist das normal?"

Page Builder erzeugen von Natur aus viel CSS und JS. Elementor und Divi fügen allein 30-50 Requests hinzu. Das bedeutet nicht „akzeptieren Sie es"; es bedeutet, dass der Rest Ihrer Seite so sauber wie möglich sein sollte. Entfernen Sie alles, was nichts mit dem Builder zu tun hat: unnötige Plugins, externe Schriftarten, nicht optimierte Bilder. Behalten Sie nur, was Ihren Besuchern tatsächlich dient.

Was ist wichtiger: Anzahl der Requests oder gesamte Seitengröße?

Beides. 20 Requests zu je 1 MB bedeuten eine Ladezeit von 20 Sekunden. 100 Requests zu je 5 KB laden möglicherweise schneller, aber jeder Request verursacht Overhead für DNS-Lookup, TCP-Verbindung und TLS-Handshake. Bei HTTP/2 wird dieser Unterschied ausgeglichen. Bei HTTP/1.1 ist er kritisch. Optimieren Sie beides: Reduzieren Sie die Request-Anzahl durch Dateizusammenführung und Sprites, reduzieren Sie die Größe durch Komprimierung und Minifizierung.

Komme ich ohne Plugins aus?

Teilweise, ja. CSS/JS-Minifizierung kann während der Theme-Entwicklung über Gulp oder Webpack eingerichtet werden. HTTP/2 wird auf Serverebene aktiviert (Nginx/Apache-Konfiguration). Caching kann über Serverregeln erfolgen. Aber für die meisten WordPress-Seitenbetreiber sind Plugins der praktikabelste Weg: Die Einrichtung dauert Minuten, die Ergebnisse sind sofort sichtbar und das Risiko, die Seite zu beschädigen, ist geringer.

Wie oft sollte ich die Anzahl der HTTP-Requests erneut prüfen?

Nach jeder größeren Plugin-Installation oder -Aktualisierung. Ein neues Plugin könnte sein CSS/JS auf allen Seiten hinzufügen, und Sie bemerken es erst, wenn die Seite anfängt zu träge zu werden. Einmal im Monat ist für Routineprüfungen ausreichend. GTMetrix ermöglicht es Ihnen, eine automatische Überwachung mit Warnmeldungen bei Leistungseinbußen einzurichten.

Brauche ich diesen Leitfaden überhaupt, wenn ich bereits schnelles Hosting habe?

Hosting löst einen Teil des Problems auf Serverebene, aber nicht auf Codeebene. Wenn ein Plugin 15 Skripte in den <head> der Seite einfügt, werden selbst erstklassige Server diese nicht sofort laden können. Der Browser wartet trotzdem. Schnelles Hosting verschafft Ihnen einen Vorsprung, aber der eigentliche Gewinner ist derjenige, der auch die Client-Seite aufräumt.

Was reduziert HTTP-Requests tatsächlich, und was nicht?

Gehen wir die einzelnen Maßnahmen illusionsfrei durch:

• Aufräumen von Plugins und Themes bringt die spürbarste Verbesserung. Jedes entfernte Plugin eliminiert sein CSS, JS und externe Aufrufe. In der Praxis verschwinden nach einem Audit 10 bis 30 Requests.
• Bildkomprimierung reduziert die Dateigrößen, aber die Anzahl der Requests bleibt gleich. Die gesamte Ladezeit sinkt jedoch merklich.
• Kombinieren von CSS und JS senkt die Request-Anzahl deutlich. Nachteil: Es kann Layouts zerstören, prüfen Sie daher nach jeder Änderung.
• Verzögertes Laden von Skripten: gleiche Anzahl an Requests, aber die Seite wird schneller sichtbar.
• Caching und CDN: Für neue Besucher ist der Unterschied minimal. Bei wiederkehrenden Besuchern laufen wiederholte Seitenaufrufe ohne einen einzigen Request an den Server ab.

Müssten wir genau drei Maßnahmen auswählen, die auf einer typischen WordPress-Seite die größte Wirkung erzielen: (1) unnötige Plugins entfernen, (2) CSS/JS-Kombinierung über Autoptimize aktivieren, (3) Cloudflare einrichten. Das sind drei Schritte, die eher einen Abend als eine Woche dauern und deren Ergebnisse Sie bereits am nächsten Tag in den GTMetrix-Zahlen sehen.