WordPress HTTP Requests reduzieren: So optimieren Sie Ihre Website Speed

WordPress HTTP Requests bestimmen, wie schnell deine Seiten erscheinen, weil jeder Abruf von CSS, JS, Bildern oder Fonts Zeit kostet. Ich zeige dir, wie du die Zahl der Anfragen senkst, Render-Blocking vermeidest und die Website sofort spürbar beschleunigst.

Zentrale Punkte

Die folgenden Schwerpunkte führen dich zügig zu einer niedrigeren Anfragezahl und besserem LCP bei stabiler Funktion:

• Caching nutzen: Browser-, Page- und Objekt-Cache senken wiederholte Abrufe deutlich.
• CSS/JS optimieren: Minifizieren, bündeln, Critical CSS einbinden, Render-Blocking vermeiden.
• Bilder modernisieren: WebP/AVIF, Lazy Loading, feste Maße, keine Hero-Slider.
• Skripte verzögern: Defer/Delay für Analytics, Pixel, externe Ressourcen.
• CDN/Hosting wählen: HTTP/3, Edge-Caching, kurze TTFB für globale Nutzer.

Was sind HTTP-Requests in WordPress?

Jede Ressource der Seite erzeugt eine eigene Anfrage, also CSS-Dateien, JavaScript, Bilder, Icons und Schriftarten. Moderne Themes und Plugins fügen schnell viele kleine Dateien hinzu, was die Zahl der Anfragen treibt. Bei jedem Abruf fallen DNS-Lookup, TCP-Handshake und Transfer an, und genau dieser Overhead summiert sich. Ohne Optimierung sehe ich oft 70+ Requests pro Seite, was die Darstellung merklich verzögert. Zielwerte liegen klar darunter: unter 50 ist gut, unter 25 spitze für Top-Speed. Eine kleine Reduktion pro Seitentyp wirkt sich breit aus, weil Templates, Header und Footer überall laden.

Warum jede Anfrage zählt

Jede zusätzliche Datei kann das Rendering blockieren, vor allem synchron geladenes CSS und JavaScript. Bleiben diese Ressourcen im Kopf der Seite render-blockierend, warten Nutzer auf weiße Flächen und springen ab. Das schlägt auf Core Web Vitals durch: LCP verzögert sich, TBT wächst, und CLS steigt ohne feste Maße bei Bildern oder Ads. Ich prüfe deshalb konsequent, welche Ressourcen wirklich kritisch sind und welche ich verzögern kann. Wenn dir unklar ist, warum Requests trotz kleiner Dateigröße bremsen, lies meinen Leitfaden warum HTTP-Requests blockieren für praxisnahe Erklärungen.

Schnellstart: Maßnahmen mit größtem Hebel

Ich starte mit Caching, Minifizierung und Lazy Loading, weil diese Schritte große Effekte liefern und schnell umsetzbar sind. Ein gutes Caching-Plugin legt statische HTML-Seiten an und spart die Datenbank. Minifizierung entfernt Leerzeichen und Kommentare, kombiniert Dateien und reduziert Downloads deutlich. Lazy Loading verschiebt Offscreen-Bilder nach hinten, was First Paint und LCP hilft. Mit wenigen Klicks lassen sich so direkte Verbesserungen erzielen, ohne das Theme zu wechseln.

Optimierungsmaßnahme	Reduzierung Requests	Tools/Plugins
Caching (Browser, Page, Objekt)	50–80% bei Wiederbesuchen	WP Rocket, LiteSpeed Cache, W3TC
Minify & Kombinieren	20–50% weniger Transfers	Autoptimize, Perfmatters
Lazy Loading Bilder	30–60% initial	WP Rocket, Core-Funktion
CDN mit HTTP/2/3	bis 40% effizienter	Cloudflare, QUIC.cloud

Caching clever einsetzen

Ich aktiviere zuerst Browser-Caching, damit wiederkehrende Nutzer Assets lokal aus dem Cache holen und nicht erneut vom Server laden. Page-Caching erzeugt statische HTML für Besucher und spart PHP-Ausführung sowie Datenbankabfragen. Mit Objekt-Caching (z. B. Redis) bleiben häufige Queries im Speicher, was Admin- und Shop-Seiten entlastet. Gzip/Brotli senken die Übertragung zusätzlich, was Transferzeit und Datenvolumen reduziert. Danach kontrolliere ich die Ablaufzeiten (Cache-Control, Expires) und ob Query-Strings Vermarktungsskripte unnötig vom Caching ausschließen.

CSS und JavaScript: Minifizieren, kombinieren, laden

Viele kleine Dateien bedeuten viele Requests, deshalb fasse ich Styles und Skripte nach Möglichkeit zu wenigen Bundles zusammen. Minifizierung reduziert die Größe, wichtig ist aber vor allem weniger Dateien für den kritischen Pfad. Critical CSS binde ich inline ein, damit Above-the-Fold-Inhalte sofort styling erhalten. Nicht-kritische Styles lade ich asynchron oder per media-Attribut nach. JavaScript setze ich auf defer oder delay, teste aber die Reihenfolge, damit Abhängigkeiten nicht brechen.

Bilder und Medien: große Einsparungen

Bilder verursachen oft den größten Anteil der Anfragen, deshalb konvertiere ich auf WebP oder AVIF und definiere feste Maße. Lazy Loading verzögert Offscreen-Bilder, doch das Hero-Bild preloade ich gezielt für einen schnellen LCP. Responsive srcset sorgt dafür, dass Mobilgeräte kleine Varianten laden. Ich vermeide Slider im Hero, weil sie viele Dateien und Repaints verursachen. Zusätzlich nutze ich moderne Formatspezifika, um Artefakte gering zu halten.

Fonts, Drittanbieter und externe Skripte

Externe Schriften lade ich lokal, damit ich volle Kontrolle über Caching und Preload habe. Ich kombiniere Schriftschnitte sparsam, häufig reichen Regular und Bold mit variablen Fonts. Für Analytics, Tag-Manager und Pixel setze ich Delay bis nach dem First Interaction oder lade sie erst nach dem Onload-Event. So bleibt der kritische Pfad frei von unnötigen Dateien. Zusätzlich prüfe ich Widgets von Social Media und ersetze sie durch statische Vorschauen, die ich bei Klick nachlade.

CDN und Hosting sinnvoll wählen

Ein CDN bringt Assets näher an Nutzer und reduziert Latenz sowie Anzahl von Roundtrips spürbar im ersten Aufruf. HTTP/2/3 ermöglicht Multiplexing, Priorisierung und schnellere TLS-Handshakes. Edge-Caching von HTML macht vor allem internationale Zielgruppen schneller. Auf dem Server achte ich auf NVMe-Storage, aktuelle PHP-Versionen und kurze TTFB. Gute Hoster bieten Tools wie Brotli, Early Hints und QUIC, die ich aktiv nutze.

Spezialfälle: REST-API und Admin-Ajax

Viele Installationen erzeugen Hintergrundanfragen durch die REST-API oder admin-ajax.php, etwa für Formulare, Suche oder dynamische Widgets. Ich identifiziere diese Calls im Netzwerk-Tab und prüfe, ob Polling-Intervalle sinken oder Requests zusammengefasst werden können. Wo möglich, cache ich API-Antworten serverseitig und lege Rate Limits fest. Für tiefere Optimierungen verweise ich auf meinen Leitfaden zur REST-API Performance, der typische Bremsen und Lösungen zeigt. So senke ich wiederholte Hintergrundanfragen, ohne Funktionen zu verlieren.

Messen und Monitoring für dauerhafte Speed

Ich teste jede Änderung mit PageSpeed Insights, Lighthouse und GTmetrix, damit ich die echte Wirkung sehe und keine Regressions einfange. Zielmarken: weniger als 50 Requests pro Seite, LCP unter 2,5 s, TBT unter 200 ms und CLS unter 0,1. Zusätzlich schaue ich ins Wasserfalldiagramm, um blockierende Ressourcen, DNS-Lookups und Queues sichtbar zu machen. Denke daran: Häufig zählt die Anzahl der Anfragen stärker als die reine Dateigröße; genau das erläutere ich im Beitrag zum Fokus auf Anfragen. Mit kontinuierlichem Monitoring bleiben Optimierungen stabil und messbar.

Fortgeschritten: HTTP/2/3, Unused CSS und DB-Pflege

Mit HTTP/2/3 profitiere ich von Multiplexing, Prioritäten und schnelleren Handshakes, was Wartezeiten bei parallel geladenen Dateien verkürzt. Ich entferne ungenutztes CSS, damit Stylesheets kleiner werden und Requests sinken. Für wiederkehrende Layouts lohnt sich kritisches CSS pro Template, nicht pro Seite. In der Datenbank lösche ich Revisionen, abgelaufene Transients und Cron-Leichen, damit Back-End und dynamische Funktionen flott bleiben. Solche Schritte bringen noch einmal spürbar Tempo, gerade bei großen Projekten mit vielen Plugins.

Plugin- und Theme-Hygiene

Ich prüfe regelmäßig, welche Plugins Funktionen doppeln oder selten genutzt werden, und ersetze schwere Pakete durch leichtere Alternativen. Schlanke Themes wie Astra oder GeneratePress erzeugen sehr wenige Requests und lassen sich sauber optimieren. Innerhalb des Themes deaktiviere ich Module, die ich nicht brauche, etwa Iconsammlungen oder Slider. Auch Page Builder konfiguriere ich minimalistisch, damit sie nur genutzte Widgets laden. Feature-Flags und modulare Enqueues helfen, Dateimüll zu vermeiden.

Ressourcenhinweise und Prioritäten gezielt einsetzen

Neben Caching und Bündelung bringen Resource Hints den entscheidenden Feinschliff. Ich nutze Preload nur für wirklich kritische Ressourcen: das LCP-Bild, das Haupt-CSS (falls nicht als Critical CSS inline) und die primäre Webfont-Datei. Zu viele Preloads blockieren die Priorisierung und können das Gegenteil bewirken. Für Schriften setze ich font-display (swap/optional), um FOIT zu vermeiden, und lege ein Preload mit korrektem as-Attribut an, damit der Browser die Datei nicht doppelt lädt.

DNS-Prefetch und Preconnect setze ich sparsam für zwingende Drittanbieter ein (z. B. Zahlungsanbieter im Checkout). Preconnect spart mir den TLS-Handshake, ist aber nur sinnvoll, wenn die Ressource sicher gebraucht wird. Prefetch nutze ich für Ressourcen, die wahrscheinlich im nächsten Schritt benötigt werden (z. B. nächste Paginierungsseite). In Verbindung mit Early Hints kann der Server Preloads früh signalisieren – das reduziert die Zeit bis zum ersten Byte bereits während der Verbindungsaufnahme.

• Preload: Nur für LCP-Bild, Haupt-CSS, kritische Font-Datei.
• Preconnect: Für sichere, unvermeidliche Dritt-Domains.
• Prefetch: Für potenziell bald benötigte Ressourcen/Seiten.
• DNS-Prefetch: Für geringe, aber günstige Vorarbeit bei externen Hosts.

Zusätzlich setze ich wo möglich Priority Hints ein (fetchpriority=“high“ für das LCP-Bild), damit der Browser versteht, was wirklich zuerst kommen muss. So lassen sich Ladezeit und Request-Reihenfolge präziser steuern.

WordPress-Assets: nur laden, was gebraucht wird

Viele Seiten laden Styles und Skripte global, obwohl sie nur auf wenigen Templates nötig sind. Ich identifiziere solche Kandidaten und lade sie konditional – etwa Formularskripte nur auf Kontaktseiten, Slider-CSS nur dort, wo Slider existieren, und WooCommerce-Assets ausschließlich auf Shop-, Produkt- und Checkout-Seiten.

Besonders lohnende Aufräumarbeiten:

• Emoji-Skripte und -Styles im Frontend deaktivieren, da moderne Systeme native Emojis haben.
• oEmbed-Funktionen einschränken, wenn keine Fremdinhalte eingebettet werden.
• Dashicons im Frontend abschalten, sofern das Theme keine benötigt.
• jQuery Migrate entfernen, wenn keine Alt-Skripte abhängen.
• Gutenberg block-library CSS nur laden, wenn Block-Styles im Frontend tatsächlich genutzt werden.

Für feingranulares Asset-Management setze ich auf modulare Enqueues (pro Template/Block) oder nutze ein Optimierungs-Plugin, das pro Seite Ressourcen deaktivieren kann. So schrumpft die Request-Liste schnell von zig Dateien auf eine Handvoll wirklich notwendiger Assets.

WooCommerce, Formulare und andere dynamische Bereiche

Shops bringen eigene Spezialfälle mit: Das bekannte cart fragments-Skript kann über admin-ajax.php viele wiederholte Requests verursachen. Ich lade diese Funktion nur in Bereichen, wo sie Sinn macht (Produkt-, Warenkorb-, Checkout-Seiten) und deaktiviere sie in Blogs oder Landingpages. Mini-Carts cache ich, wenn möglich, und aktualisiere sie nur bei echter Interaktion. Für Produktbilder setze ich konsequent auf srcset und preloade das erste, sichtbare Bild.

Bei Formularen reduziere ich Polling-Intervalle, sende Validierungen gebündelt und verwende Debouncing, um Eingaben nicht bei jedem Tastenanschlag zu übertragen. Suchen und Filter realisiere ich möglichst über gecachte Endpunkte (z. B. REST), damit wiederholte identische Anfragen aus dem Cache bedient werden. Das senkt die Serverlast, die Anzahl der HTTP Requests und verbessert wahrgenommene Geschwindigkeit.

Bilder, Iframes und Medien weiter verfeinern

Für das LCP-Bild verwende ich fetchpriority=“high“ und setze ein präzises Preload. Gleichzeitig achte ich auf width/height oder ein CSS-aspect-ratio, damit kein Layout-Shift entsteht. Bilder versehe ich mit decoding=“async“, um das Rendering nicht zu blockieren, und setze lazy nur dort, wo es sinnvoll ist: Das erste Bild sollte nicht lazy sein, alle weiteren schon.

Externe Iframes (YouTube, Maps, Social) ersetze ich durch leichte Voransichten. Statt sofort das gesamte Widget zu laden, zeige ich ein statisches Vorschaubild und lade das echte Embed erst nach Klick. So streiche ich zahlreiche initiale Requests, die für die erste Interaktion unnötig sind. Für eigene Videos nutze ich Poster-Bilder, moderne Codecs und streame adaptiv, damit keine großen Dateien synchron blockieren.

Saubere Cache-Header und Cache-Busting

Viele Anfragen entstehen, weil Browser- oder CDN-Caches nicht optimal greifen. Ich definiere für statische Assets (CSS, JS, Fonts, Bilder) lange TTLs mit Cache-Control und setze bei unveränderlichen Dateien das Flag immutable. Um Updates sicher auszurollen, verwende ich Versionierung in Dateinamen oder WordPress-ver-Parametern. Wichtig: Das CDN muss Query-Strings korrekt cachen, sonst verlieren ?ver=-Parameter ihre Wirkung und es wird unnötig neu geladen.

ETag und Last-Modified nutze ich so, dass Revalidierungen schnell ablaufen und If-None-Match/If-Modified-Since-Responses helfen, Datenvolumen zu sparen. Mit stale-while-revalidate bleibt die Seite reaktionsschnell, während im Hintergrund aktualisiert wird. Zusammen ergibt das weniger Roundtrips und sauber planbare Updates ohne Cache-Chaos.

Fehler vermeiden: Wenn Bündeln und Minify zu viel des Guten sind

Bei HTTP/2/3 muss ich nicht jedes Bit in eine einzige Datei pressen. Zu große Bundles erschweren Cache-Hits, weil jede Änderung den kompletten Block ungültig macht. Ich finde einen Mittelweg: wenige, logisch getrennte Bundles, die den kritischen Pfad klein halten und trotzdem Wiederverwendung ermöglichen (z. B. ein globales Core-Bundle, ein Template-Bundle, ein selten geändertes Vendor-Bundle).

Auch Minifizierung kann Probleme bereiten: Uglify/Minify kann bei manchen Plugins Funktionen beschädigen. Ich teste daher schrittweise und schließe kritische Skripte bei Bedarf von Minify/Combine aus (etwa Inline-JSON, Payment-Skripte, Captcha). Ziel ist ein stabiler, kurzer kritischer Pfad, kein Risko-Bündel, das bei jedem Update bricht.

Messmethodik: belastbar prüfen statt raten

Ich messe mit reproduzierbaren Profilen: Desktop und Mobil getrennt, mit realistischen Bandbreiten und CPU-Throttling. In den DevTools nutze ich Coverage, um Unused CSS/JS zu quantifizieren, und das Wasserfalldiagramm, um zu sehen, welche Requests warten, gestapelt sind oder durch Prioritäten ausgebremst werden. Ich vergleiche First View und Repeat View, um zu prüfen, ob Cache-Header wirklich greifen und ob sich die Anzahl der Requests beim Wiederbesuch tatsächlich halbiert oder besser.

Außerdem richte ich Guardrails ein: maximale Anzahl Requests pro Seitentyp, LCP-Ziel, Budget für Drittanbieter. Neue Features kommen nur live, wenn sie die Budgets einhalten. So bleibt die Seite langfristig schnell – nicht nur direkt nach einer Optimierungsrunde.

Serverseitige Feinheiten: TTFB und TLS

Neben der reinen Anzahl der Anfragen zählt auch die Serverantwortzeit. Ich halte OPcache aktiv, tune PHP-FPM, sorge für schlanke Plugins und minimiere Datenbank-Roundtrips. Bei TLS achte ich auf eine kurze Zertifikatskette, aktuelles TLS 1.3 und aktiviertes OCSP Stapling. Zusammen mit HTTP/3 reduziert das die Handshake-Zeiten und beschleunigt erste Abrufe merklich – besonders bei Mobilnutzern.

Kurz zusammengefasst

Ich reduziere die Anfragezahl, indem ich Caching aktiviere, CSS/JS bündele, Bilder modernisiere und externe Skripte verzögert lade. Fonts hoste ich lokal und preloade kritische Ressourcen sauber und gezielt. Ein CDN mit HTTP/2/3 und schnelles Hosting verkürzen Latenz und TTFB. Mit Messungen in PageSpeed, Lighthouse und GTmetrix kontrolliere ich, ob LCP, TBT und CLS in den Zielkorridor rutschen. Dieser Ablauf schafft oft in wenigen Stunden den Sprung von trägen 70+ Requests zu flotten, klar unter 50 liegenden Seiten.