Wordpress

WordPress HTTP/2 Performance: Warum es nicht automatisch schneller wird

WordPress HTTP/2 beschleunigt Anfragen über eine einzige Verbindung, doch alte Optimierungen und falsche Server-Setups bremsen den Effekt oft aus. Ich zeige, wo Multiplexing, Header-Kompression und Server Push wirken – und warum spürbare Performance erst mit passenden WordPress- und Server-Einstellungen kommt.

Zentrale Punkte

Multiplexing ersetzt viele Verbindungen und lädt Dateien parallel.
Concatenation und zu starke Minifizierung wirken unter HTTP/2 oft hinderlich.
Server Push hilft nur gezielt konfiguriert und gemessen.
TLS-Handshake kostet Zeit, gute Servereinstellungen gleichen das aus.
CDN und saubere Assets schlagen reine Protokollwechsel deutlich.

Was HTTP/2 in WordPress tatsächlich ändert

Ich nutze die Vorteile von Multiplexing, um viele kleine CSS-, JS- und Bilddateien parallel über eine einzelne TCP-Verbindung zu laden. HTTP/2 reduziert Overhead durch HPACK-Header-Kompression und überträgt Daten binär, was Fehler minimiert und Pakete effizienter macht. Dadurch entfällt das alte Öffnen vieler Verbindungen, was Latenz und CPU-Last im Browser senkt. Wer die Unterschiede zu HTTP/1.1 verstehen will, schaut sich den Vergleich Multiplexing vs. HTTP/1.1 an und plant darauf aufbauend die Asset-Strategie. Server Push kann zusätzlich erste Ressourcen anstoßen, doch ich setze ihn gezielt ein und messe die Wirkung.

Warum HTTP/2 nicht automatisch schneller wirkt

Alte HTTP/1.x-Tricks wie starkes Zusammenführen von Dateien verschlechtern unter HTTP/2 oft den First Paint. Viele Themes bündeln alles in eine große Datei, wodurch der Browser später mit Rendering beginnt. Tests zeigen teils drastische Zugewinne, bis zu 85 %, aber nur wenn Server, Assets und Cache zusammenspielen. Auf schlanken Seiten oder bei schwachen Servern fällt der Effekt kleiner aus, manchmal sehe ich nur 0,5 Sekunden Time-to-Interactive-Gewinn. Wer die falschen Plugins lädt, unkomprimierte Bilder nutzt oder langsame Datenbankabfragen hat, bremst HTTP/2 aus.

Typische HTTP/1.x-Optimierungen, die jetzt bremsen

Ich vermeide übertriebene Concatenation, denn eine große JS-Datei blockiert Parsing und Caching feiner Granulate. Besser liefere ich Module getrennt aus: nur das, was die Seite wirklich braucht. Übermäßige Minifizierung bringt wenig, weil HTTP/2 durch Kompression bereits viele Bytes spart; ich minifiziere moderat, um Debugging und Caching freundlich zu halten. Domain Sharding gehört auf den Prüfstand, weil eine einzelne Verbindung mit Multiplexing die beste Auslastung bringt. Auch alte CSS-Sprites prüfe ich neu, da moderne Formate wie WebP zusammen mit HTTP/2 Anfragen und Bytes effizienter handhaben und Cache-Hitrate verbessern.

Serverkonfiguration und TLS: so hole ich den Vorsprung

HTTP/2 setzt HTTPS voraus, also optimiere ich TLS 1.3, aktiviere ALPN und kürze Handshakes mit OCSP Stapling. Ich setze auf Brotli statt nur Gzip, tune Keep-Alive und stelle Nginx oder Apache mit h2-Parametern sauber ein. Eine schwache PHP-FPM-Konfiguration oder zu wenige Worker kosten Zeit, bevor der erste Byte fließt. Caching auf Server-Ebene – FastCGI, Object Cache, OpCache – reduziert Backend-Last spürbar. Diese Schritte bringen oft mehr als jede Protokolloption und stabilisieren die gefühlte Reaktionszeit.

Asset-Strategie für WordPress unter HTTP/2

Ich lade Styles und Scripts modular per wp_enqueue und setze defer oder async für nicht-kritische JS-Dateien ein. Critical CSS für Above-the-Fold verkürzt den First Contentful Paint, während Rest-CSS später nachlädt. Statt Monster-Bundles splitte ich Komponenten sinnvoll, damit Caching und Parallelisierung greifen. Bilder optimiere ich mit modernen Formaten und passender Qualität, Lazy Loading hält die Startseite schlank. Für weniger Overhead nutze ich bewährte Tipps, um HTTP-Requests zu reduzieren, ohne die Stärken von HTTP/2 zu verschenken; so bleibt die Nutzlast klein.

Server Push gezielt einsetzen

Ich pushe nur Dateien, die wirklich jede Seite sofort braucht, zum Beispiel eine kleine Critical-CSS-Datei oder ein wichtiges Preload-Script. Große Bilder oder selten genutzte Module pushe ich nicht, weil sie Bandbreite binden und Caching stören können. In WordPress verknüpfe ich Push über Link-Header oder passende Plugins, prüfe aber, ob der Browser ohnehin schnell genug lädt. Ich messe mit Web-Tools, ob Push den LCP verbessert oder ob ein Preload-Header reicht. Wenn Kennzahlen stagnieren, schalte ich Push wieder ab und halte die Pipeline frei.

CDN, Caching und Latenz – was wirklich zählt

Ich lege statische Assets auf ein CDN mit HTTP/2-Support und guter Präsenz nahe an den Nutzern. Kürzere Wege senken RTT, während Edge-Cache die Last des Origins reduziert. Mit sinnvollen Cache-Control-Headern, ETags und hashed Filenamen treffe ich saubere Revalidation-Entscheidungen. Ich minimiere DNS-Lookups und verhindere unnötige CORS-Preflights. Zusammen mit sauberem Object Cache für WordPress wächst der Effekt von HTTP/2 spürbar und stärkt die Ladezeit.

Priorisierung und Resource Hints gezielt einsetzen

HTTP/2 entscheidet serverseitig, in welcher Reihenfolge Streams fließen, doch ich gebe dem Browser klare Signale. Ich nutze preload für kritische CSS und das LCP-Bild, preconnect für unvermeidbare Drittdomains und dns-prefetch nur vorsichtig. Für Fonts setze ich font-display: swap und liefere WOFF2; Preload hilft hier, Flash-of-Invisible-Text zu vermeiden. Seit WordPress 6.x kann ich zusätzlich das Attribut fetchpriority nutzen, um entscheidende Ressourcen hochzustufen und Unwichtiges gezielt zu drosseln.

Dabei beachte ich zwei Regeln: Ich preloade nur, was unmittelbar gerendert wird, und ich messe, ob die Priorisierung greift. Ein zu breites Preload verstopft die Pipeline, gerade auf Mobilfunknetzen.

// LCP-Bild priorisieren und nicht lazy-loaden
add_filter('wp_get_attachment_image_attributes', function ($attr, $attachment, $size) {
    if (is_front_page() && !empty($attr['class']) && strpos($attr['class'], 'hero') !== false) {
        $attr['fetchpriority'] = 'high';
        $attr['decoding'] = 'async';
        $attr['loading'] = 'eager';
    }
    return $attr;
}, 10, 3);

// Preconnect/Preload-Hints gezielt setzen
add_filter('wp_resource_hints', function ($hints, $relation_type) {
    if ('preconnect' === $relation_type) {
        $hints[] = 'https://cdn.example.com';
    }
    return array_unique($hints);
}, 10, 2);

Für Styles nutze ich kleine, ausgelagerte Critical-CSS-Dateien (leicht cachebar) statt große Inline-Blöcke, die bei jedem HTML neu übertragen werden. Ich preloade die Datei und lasse den Rest-CSS-Chunk asynchron nachladen – das hält FCP und LCP klein und respektiert die Stärken von HTTP/2.

WordPress-Assets in der Praxis: sauber splitten, klug laden

Ich registriere Skripte modular mit Abhängigkeiten und steuere die Ausführung per defer/async. Drittanbieter-Skripte, Analytics und Maps laufen asynchron; Render-kritisches bleibt bloß schlank.

// defer/async je nach Handle setzen
add_filter('script_loader_tag', function ($tag, $handle, $src) {
    $async = ['analytics', 'maps'];
    $defer = ['theme-vendor', 'theme-main'];

    if (in_array($handle, $async, true)) {
        return str_replace('<script ', '<script async ', $tag);
    }
    if (in_array($handle, $defer, true)) {
        return str_replace('<script ', '<script defer ', $tag);
    }
    return $tag;
}, 10, 3);

// Überflüssige Plugin-Assets auf Nicht-Zielseiten abklemmen
add_action('wp_enqueue_scripts', function () {
    if (!is_page('kontakt')) {
        wp_dequeue_script('contact-form-7');
        wp_dequeue_style('contact-form-7');
    }
}, 100);

Ich zerlege große JS-Bundles in sinnvolle Chunks – Header, Footer, Komponenten – und nutze dabei Tree-Shaking-fähige Builds. Unter HTTP/2 ist es okay, mehrere kleine Dateien zu liefern, solange Abhängigkeiten klar sind und Caching greift. Für CSS setze ich auf modulare Dateien pro Template/Komponente; das macht Debugging leichter und Wiederverwendung effizienter.

Fonts halte ich minimal: wenige Schnitte, Variable Fonts nur wenn wirklich gebraucht. Ich achte auf definierte width/height bei Bildern, damit CLS niedrig bleibt, und lasse WordPress Responsive-Images mit passenden srcset-Einträgen ausspielen, damit Geräte nicht mehr Bytes als nötig laden.

Server Push heute: Preload und Early Hints

Ich beachte, dass viele Browser HTTP/2 Server Push mittlerweile abgebaut oder deaktiviert haben. In der Praxis liefere ich daher konsequent Preload-Header und nutze, wo verfügbar, 103 Early Hints, um kritische Ressourcen noch vor der finalen Antwort anzukündigen. Das funktioniert stabiler und kollidiert weniger mit Caches.

# Beispiel-Nginx: HTTP/2, TLS 1.3, Brotli, Early Hints
server {
    listen 443 ssl http2;
    ssl_protocols TLSv1.3;
    ssl_early_data on;
    add_header Link "</assets/critical.css>; rel=preload; as=style" always;

    brotli on;
    brotli_comp_level 5;
    brotli_types text/css application/javascript application/json image/svg+xml;
}

Ich pushe nichts, was der Browser ohnehin verschiebt oder was als Late-Render gilt. Wenn ein gezielter Push (oder Early Hint) keinen messbaren Gewinn bei LCP bringt, entferne ich ihn wieder und lasse Priorisierung dem Browser.

Backend-Leistung: PHP-FPM, Object Cache und Datenbank

HTTP/2 kaschiert keine langsamen Backends. Ich stelle PHP-FPM sauber ein (pm dynamic, sinnvolle pm.max_children, kein Swapping) und aktiviere Opcache mit ausreichend Speicher. Ein persistenter Object Cache (Redis/Memcached) sorgt dafür, dass wiederkehrende Anfragen kaum noch die Datenbank treffen. Bei der DB achte ich auf Indizes für wp_postmeta und wp_options, reduziere Autoload-Ballast und räume Cron-Jobs auf.

; PHP-FPM (Ausschnitt)
pm = dynamic
pm.max_children = 20
pm.max_requests = 500
request_terminate_timeout = 60s

Ich prüfe regelmäßig TTFB unter Last. Wenn der erste Byte zu lange braucht, sind oft zu wenige PHP-Worker, fehlende Cache-Hits oder langsame WP-Queries schuld. Query-Analyse, Autoload-Optionen > 1–2 MB und ungebremste REST-/admin-ajax-Aufrufe sind typische Bremsen. Ich cache API-Antworten aggressiv, wenn sie sich selten ändern.

E-Commerce und dynamische Seiten: Caching ohne Fallstricke

Bei Shops (z. B. WooCommerce) arbeite ich mit Full-Page-Cache plus Vary-Strategie auf relevante Cookies. Ich schließe Warenkorb- und Checkout-Seiten vom Cache aus und deaktiviere Cart-Fragments, wo sie nicht gebraucht werden. Produktlisten und CMS-Seiten lassen sich dagegen sehr gut am Edge cachen – HTTP/2 liefert die vielen kleinen Assets dann parallel, während das HTML sofort aus dem Cache kommt.

Ich nutze fragmentiertes Caching (ESI oder serverseitige Partials), um dynamische Blöcke in sonst statische Seiten einzubauen. So bleibt TTFB niedrig, ohne Personalisierung zu verlieren. Für Länder-/Währungswechsel setze ich knappe Cache-Keys und kompaktes HTML ein, damit die Menge an zu cachenden Varianten nicht explodiert.

CDN-Feinheiten: Coalescing, Hostnames und Header

Ich vermeide zusätzliche Hostnamen, wenn sie keinen echten Nutzen bringen. Unter HTTP/2 kann der Browser Verbindungen zusammenlegen (Connection Coalescing), wenn Zertifikat, IP und TLS-Parameter passen – so bleibt die Zahl der TCP- und TLS-Setups minimal. Ich nutze immutable und stale-while-revalidate in Cache-Control, damit Clients Assets länger aus dem Cache holen und nebenbei frisch halten.

Ich achte auf konsistente Brotli-Kompression am Edge und am Origin, damit es keine doppelten Encodings gibt. Fehlende Vary-Header auf Accept-Encoding oder übertriebene CORS-Policies können Preflight-Anfragen erzeugen und so die Stärke von HTTP/2 konterkarieren – das räume ich auf.

Messstrategie: Lab und Field, Kennzahlen richtig lesen

Neben TTFB, FCP, LCP beobachte ich CLS (Layout-Verschiebungen) und INP (Interaktionslatenz). HTTP/2 verbessert primär Transport und Parallelisierung; schlechte Werte bei CLS/INP deuten oft auf Assets, Fonts und JS-Last hin, nicht auf das Protokoll. Ich messe stets mobil mit Throttling, vergleiche kalte vs. warme Caches und halte Testbedingungen reproduzierbar.

Ich lese Waterfalls: Startet CSS früh, blockiert ein großes JS, wann fließt das LCP-Bild?
Ich prüfe Prioritäten in DevTools: Werden Preloads respektiert, ist fetchpriority aktiv?
Ich unterscheide Origin- und Edge-Hitrate: Knappe HTML-Antworten plus viele kleine Assets sind unter HTTP/2 in Ordnung – wenn beide Caches sitzen.

Typische Messwerte und was sie bedeuten

Ich beobachte TTFB, FCP und LCP, weil diese Kennzahlen die reale Wahrnehmung widerspiegeln. Ein reines „Requests runter“-Ziel verfälscht Ergebnisse, denn HTTP/2 liebt mehrere kleine Dateien. Ich bewerte zudem die Verteilung: Welche Ressource blockiert Rendering, welche lädt spät? Ohne reproduzierbare Messumgebung (kalter vs. warmer Cache, mobile vs. Desktop) deuten Zahlen schnell in die falsche Richtung. Diese Beispielwerte zeigen typische Effekte, dienen mir als Startpunkt für feineres Tuning und sichern die Transparenz:

Kennzahl	Vor Umstellung	Nach HTTP/2 + Tuning
TTFB	450 ms	280 ms
FCP	1,8 s	1,2 s
LCP	3,2 s	2,3 s
Anfragen	92	104 (besser parallelisiert)
Übertragene Daten	1,9 MB	1,6 MB

Grenzen von HTTP/2 und Blick auf HTTP/3

Ich vergesse nicht, dass HTTP/2 Head-of-Line-Blocking auf TCP-Ebene nicht vollständig verhindert. Auf schwierigen Netzen mit Paketverlust kann das bremsen, obwohl das Protokoll parallelisiert. HTTP/3 mit QUIC umgeht dieses Problem, weil es auf UDP setzt und Streams separat behandelt. Wer tiefer vergleichen möchte, liest meinen Überblick zu HTTP/3 vs. HTTP/2 und prüft dann, ob ein Upgrade sinnvoll ist. Für viele Seiten liefert HTTP/2 bereits starke Gewinne, doch ich halte den Blick auf QUIC offen.

Hosting-Auswahl: worauf ich achte

Ich achte bei Hosting für WordPress auf saubere HTTP/2-Implementierung, TLS 1.3, Brotli und schnelle NVMe-Storage. Gute Anbieter stellen optimierte PHP-Worker, Object Cache und Edge-Funktionen bereit. In Vergleichen führen Plattformen mit WordPress-Optimierung oft deutlich, weil sie Latenz und TTFB klein halten. Testsieger-Übersichten zeigen webhoster.de mit starkem HTTP/2-Support und guten Ergebnissen für wp protocol speed. Diese kurze Tabelle fasst den Kern zusammen und erleichtert mir eine klare Wahl:

Hosting-Anbieter	HTTP/2-Support	WordPress-Optimierung	Platz
webhoster.de	Vollständig	Exzellent	1

Kurz zusammengefasst

Ich sehe HTTP/2 als starke Grundlage, doch Tempo entsteht erst durch kluge Prioritäten: modulare Assets, gutes Caching, saubere TLS- und Server-Settings. Alte HTTP/1.x-Tricks sortiere ich aus und ersetze sie durch Splitten, Preload und bedachtes Push. Mit einem passenden CDN, optimierten Bildern und zielsicheren Cache-Headern wachsen Kennzahlen wie FCP und LCP deutlich. Solide Hosts mit HTTP/2, TLS 1.3 und Brotli bilden den Hebel für kürzere TTFB und stabile Antwortzeiten. Wer WordPress so ausrichtet, holt aus wordpress http2 performance reale Vorteile statt nur eine neue Protokollzeile.