Ga naar de inhoud 
WordPress HTTP/2 versnelt verzoeken over een enkele verbinding, maar oude optimalisaties en onjuiste serverinstellingen vertragen vaak het effect. Ik zal je laten zien waar multiplexing, headercompressie en serverpush effect hebben - en waarom merkbaar Prestaties wordt alleen geleverd met geschikte WordPress- en serverinstellingen.
Centrale punten
- Multiplexing vervangt veel verbindingen en laadt bestanden parallel.
- Aaneenschakeling en overmatige minificatie zijn vaak een belemmering onder HTTP/2.
- Server Push helpt alleen als het specifiek wordt geconfigureerd en gemeten.
- TLS-handdruk kosten tijd, goede serverinstellingen compenseren dit.
- CDN en schone activa het duidelijk winnen van pure protocolwijzigingen.
Wat HTTP/2 eigenlijk verandert in WordPress
Ik maak gebruik van de voordelen van Multiplexing, om veel kleine CSS-, JS- en afbeeldingsbestanden parallel te laden via een enkele TCP-verbinding. HTTP/2 vermindert de overhead door HPACK headercompressie en verzendt gegevens in binaire vorm, waardoor fouten tot een minimum worden beperkt en pakketten efficiënter worden. Hierdoor is het niet meer nodig om veel verbindingen te openen, wat de latentie en CPU-belasting in de browser vermindert. Als je de verschillen met HTTP/1.1 wilt begrijpen, bekijk dan de vergelijking Multiplexing vs. HTTP/1.1 en plant de activastrategie op basis hiervan. Server Push kan ook initiële bronnen activeren, maar ik gebruik het op een gerichte manier en meet het effect.
Waarom HTTP/2 niet automatisch sneller werkt
Oude HTTP/1.x trucs zoals het sterk samenvoegen van bestanden verslechteren vaak de prestaties onder HTTP/2. Eerste lak. Veel thema's bundelen alles in één groot bestand, waardoor de browser later begint met renderen. Tests laten een drastische verbetering zien, tot 85 %, maar alleen als server, assets en cache samenwerken. Op magere sites of met zwakke servers is het effect kleiner, soms zie ik maar 0,5 seconden. Tijd-tot-interactie-winst. Als je de verkeerde plugins laadt, ongecomprimeerde afbeeldingen gebruikt of langzame database queries hebt, zal HTTP/2 je vertragen.
Typische HTTP/1.x optimalisaties die de boel nu vertragen
Ik vermijd overdreven Aaneenschakeling, omdat een groot JS-bestand het parsen en cachen van fijne korrels blokkeert. Het is beter om modules apart aan te leveren: alleen wat de pagina echt nodig heeft. Overdreven minificatie heeft weinig nut omdat HTTP/2 al veel bytes bespaart door compressie; ik minifieer matig om debugging en caching vriendelijk te houden. Domain sharding moet op de proef worden gesteld omdat een enkele verbinding met multiplexing het beste gebruik oplevert. Ik kijk ook opnieuw naar oude CSS sprites, omdat moderne formaten zoals WebP samen met HTTP/2 efficiënter omgaan met verzoeken en bytes en efficiënter zijn. Cache-hit rate verbeteren.
Serverconfiguratie en TLS: een vliegende start
HTTP/2 vereist HTTPS, dus ik optimaliseer TLS 1.3, ALPN activeren en handshakes verkorten met OCSP nieten. Ik gebruik Brotli in plaats van alleen Gzip, stem Keep-Alive af en stel Nginx of Apache netjes in met h2 parameters. Een zwakke PHP-FPM configuratie of te weinig workers kosten tijd voordat de eerste byte stroomt. Caching op serverniveau - FastCGI, Object Cache, OpCache - vermindert de belasting van de backend aanzienlijk. Deze stappen doen vaak meer dan welke protocoloptie dan ook en stabiliseren de waargenomen belasting. Reactietijd.
Activastrategie voor WordPress onder HTTP/2
Ik laad stijlen en scripts modulair via wp_enqueue en stel het volgende in uitstellen of async voor niet-kritieke JS-bestanden. Kritische CSS voor boven de vouw verkort de eerste contentful paint, terwijl de resterende CSS later wordt geladen. In plaats van monsterbundels splits ik componenten verstandig op zodat caching en parallellisatie effect hebben. Ik optimaliseer afbeeldingen met moderne formaten en geschikte kwaliteit, lui laden houdt de startpagina slank. Voor minder overhead gebruik ik beproefde tips om HTTP-verzoeken verminderen, zonder de sterke punten van HTTP/2 weg te geven; dus de laadvermogen klein.
Gericht gebruik van server push
Ik push alleen bestanden die elke site echt onmiddellijk nodig heeft, bijvoorbeeld een kleine Kritische CSS-bestand of een belangrijk preload script. Ik push geen grote afbeeldingen of zelden gebruikte modules omdat ze bandbreedte kunnen vastzetten en caching kunnen verstoren. In WordPress koppel ik Push via linkheaders of geschikte plugins, maar ik controleer sowieso of de browser snel genoeg laadt. Ik gebruik webtools om te meten of Push de LCP verbetert of dat een preload header voldoende is. Als de kerncijfers stagneren, schakel ik Push weer uit en houd ik de Pijpleiding gratis.
CDN, caching en latency - wat telt echt?
Ik plaats statische activa op een CDN met HTTP/2-ondersteuning en een goede aanwezigheid dicht bij de gebruikers. Kortere paden verminderen de RTT, terwijl edge cache de belasting op de origin vermindert. Met verstandige cache control headers, ETags en gehashte bestandsnamen maak ik schone revalidatiebeslissingen. Ik minimaliseer DNS lookups en voorkom onnodige CORS preflights. Samen met een schone object cache voor WordPress neemt het effect van HTTP/2 merkbaar toe en versterkt het de Laadtijd.
Gericht gebruik van hints voor prioriteiten en middelen
HTTP/2 beslist aan de serverkant in welke volgorde de streams stromen, maar ik geef de browser duidelijke signalen. Ik gebruik voorbelasting voor kritieke CSS en het LCP-beeld, preconnect voor onvermijdelijke domeinen van derden en dns-prefetch alleen voorzichtig. Voor lettertypen gebruik ik lettertype-weergave: verwisselen en WOFF2 leveren; preload helpt hier om flash-of-invisible tekst te voorkomen. Sinds WordPress 6.x kan ik ook het attribuut haalprioriteit om belangrijke middelen prioriteit te geven en onbelangrijke middelen te beperken.
Ik volg hier twee regels: Ik preload alleen wat direct wordt gerenderd en ik meet of de prioritering effectief is. Een te brede preload verstopt de pijplijn, vooral op mobiele netwerken.
// 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);
Voor stijlen gebruik ik kleine, uitbestede kritieke CSS-bestanden (die gemakkelijk in de cache kunnen worden opgeslagen) in plaats van grote inline blokken die bij elke HTML opnieuw worden verzonden. Ik laad het bestand vooraf en laat de resterende CSS-brok asynchroon opnieuw laden - dat houdt FCP en LCP klein en respecteert de sterke punten van HTTP/2.
WordPress assets in de praktijk: netjes splitsen, slim laden
Ik registreer scripts modulair met afhankelijkheden en regel de uitvoering via uitstellen/async. Scripts van derden, analyses en kaarten worden asynchroon uitgevoerd; render-kritieke elementen blijven slank.
// stel defer/async in afhankelijk van de handle
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 ', '<scriptdefer ', $tag);
}
return $tag;
}, 10, 3);
// Overbodige plugin-activa op niet-doelpagina's loskoppelen
add_action('wp_enqueue_scripts', function () {
if (!is_page('contact')) {
wp_dequeue_script('contact-formulier-7');
wp_dequeue_style('contact-formulier-7');
}
}, 100);
Ik splits grote JS-bundels op in zinvolle brokken - headers, footers, componenten - en gebruik builds die tree-shaking mogelijk maken. Onder HTTP/2 is het goed om meerdere kleine bestanden aan te leveren zolang de afhankelijkheden duidelijk zijn en caching werkt. Voor CSS vertrouw ik op modulaire bestanden per sjabloon/component; dit maakt debuggen eenvoudiger en hergebruik efficiënter.
Ik beperk lettertypen tot een minimum: weinig uitsnedes, variabele lettertypen alleen als het echt nodig is. Ik let op gedefinieerde breedte/hoogte voor afbeeldingen zodat CLS laag blijft en laat WordPress responsieve afbeeldingen met geschikte srcset-entries zodat apparaten niet meer bytes laden dan nodig.
Server Push vandaag: Preload en vroege hints
Ik merk op dat veel browsers HTTP/2 server push in de tussentijd zijn ontmanteld of gedeactiveerd. In de praktijk lever ik daarom consequent voorlaadkoppen en gebruik ik ze waar beschikbaar, 103 Vroege hints, om kritieke bronnen aan te kondigen voor het uiteindelijke antwoord. Dit werkt stabieler en botst minder met caches.
# Voorbeeld Nginx: HTTP/2, TLS 1.3, Brotli, vroege hints
server {
listen 443 ssl http2;
ssl_protocollen TLSv1.3;
ssl_early_data aan;
add_header Link "; rel=preload; as=style" always;
brotli aan;
brotli_comp_level 5;
brotli_types text/css application/javascript application/json image/svg+xml;
}
Ik push niets dat de browser toch beweegt of dat wordt beschouwd als een late render. Als een gerichte push (of vroege hint) niet resulteert in een meetbare winst in LCP Ik verwijder het weer en laat het prioriteren over aan de browser.
Prestaties backend: PHP-FPM, objectcache en database
HTTP/2 verbergt geen trage backends. Ik stel PHP-FPM schoon (pm dynamisch, zinvol pm.max_kinderen, niet verwisselen) en activeer Opcache met voldoende geheugen. A persistente object cache (Redis/Memcached) zorgt ervoor dat terugkerende verzoeken de database nauwelijks raken. In de database let ik op indices voor wp_postmeta en wp_options, verminder ik autoload ballast en ruim ik cron jobs op.
; PHP-FPM (uittreksel)
pm = dynamisch
pm.max_kinderen = 20
pm.max_aanvragen = 500
verzoek_terminate_timeout = 60s
Ik controleer TTFB regelmatig onder belasting. Als de eerste byte te lang duurt, zijn te weinig PHP workers, ontbrekende cache-hits of trage WP-query's vaak de oorzaak. Query analyse, autoload opties > 1-2 MB en ongeremde REST/admin-ajax calls zijn typische remmen. Ik cache API responses agressief als ze zelden veranderen.
E-commerce en dynamische pagina's: Caching zonder valkuilen
Voor winkels (bijv. WooCommerce) werk ik met full-page cache plus Varieer strategie op relevante cookies. Ik sluit pagina's met winkelmandjes en kassa's uit van de cache en deactiveer winkelwagenfragmenten waar ze niet nodig zijn. Productlijsten en CMS-pagina's kunnen daarentegen heel goed worden gecached aan de rand - HTTP/2 levert dan de vele kleine assets parallel af, terwijl de HTML direct uit de cache komt.
Ik gebruik gefragmenteerde caching (ESI of server-side partials) om dynamische blokken in anders statische pagina's op te nemen. Dit houdt TTFB laag zonder personalisatie te verliezen. Voor land-/valutawisselingen gebruik ik korte cachingsleutels en compacte HTML, zodat het aantal varianten dat in de cache moet worden opgeslagen niet explodeert.
CDN-eenheden: Coalescing, hostnamen en headers
Ik vermijd extra hostnamen als ze niet echt nuttig zijn. Onder HTTP/2 kan de browser Verbindingen samenvoegen (connection coalescing) als het certificaat, IP en TLS parameters overeenkomen - dit minimaliseert het aantal TCP en TLS setups. Ik gebruik onveranderlijk en stale-while-revalidate in Cache-Control zodat clients assets langer uit de cache kunnen halen en ze vers kunnen houden.
Ik let op consistente Brotli compressie op de Edge en Origin zodat er geen dubbele coderingen zijn. Ontbrekende Variëren-kop op Accept-Encoding of een overmatig CORS-beleid kan preflightverzoeken genereren en zo de kracht van HTTP/2 tegenwerken - ik ben dit aan het ophelderen.
Meetstrategie: lab en veld, kerncijfers correct aflezen
Naast TTFB, FCP, LCP Ik observeer CLS (lay-outverschuivingen) en INP (interactieratentie). HTTP/2 verbetert vooral transport en parallellisatie; slechte waarden voor CLS/INP duiden vaak op assets, fonts en JS-belasting, niet op het protocol. Ik meet altijd mobiel met throttling, vergelijk koude vs. warme caches en houd de testomstandigheden reproduceerbaar.
- Ik lees Waterfalls: begint CSS vroeg, blokkeert een grote JS, wanneer stroomt het LCP-beeld?
- Ik controleer de prioriteiten in DevTools: Worden preloads gerespecteerd, is fetchpriority actief?
- Ik maak onderscheid tussen origin en edge hit rate: korte HTML-responses plus veel kleine assets zijn prima onder HTTP/2 - als beide caches aanwezig zijn.
Typische meetwaarden en wat ze betekenen
Ik kijk naar TTFB, FCP en LCP omdat deze ratio's de echte Perceptie reflecteren. Een puur „requests down“ doel vertekent de resultaten, omdat HTTP/2 dol is op meerdere kleine bestanden. Ik evalueer ook de verdeling: welke bron blokkeert rendering, welke wordt laat geladen? Zonder een reproduceerbare meetomgeving (koude vs. warme cache, mobiel vs. desktop) wijzen getallen al snel in de verkeerde richting. Deze voorbeeldwaarden laten typische effecten zien, dienen voor mij als startpunt voor fijnere afstemming en zorgen ervoor dat de Transparantie:
| Sleutelfiguur | Voor omschakeling | Na HTTP/2 + afstemming |
|---|---|---|
| TTFB | 450 ms | 280 ms |
| FCP | 1,8 s | 1,2 s |
| LCP | 3,2 s | 2,3 s |
| Vragen | 92 | 104 (beter geparallelliseerd) |
| Overgedragen gegevens | 1,9 MB | 1,6 MB |
Beperkingen van HTTP/2 en een blik op HTTP/3
Ik vergeet niet dat HTTP/2 head-of-line blokkering op TCP-level wordt niet volledig voorkomen. Dit kan dingen vertragen op moeilijke netwerken met pakketverlies, ook al is het protocol geparallelliseerd. HTTP/3 met QUIC vermijdt dit probleem omdat het vertrouwt op UDP en streams apart behandelt. Als je een diepere vergelijking wilt maken, lees dan mijn overzicht van HTTP/3 vs. HTTP/2 en kijk dan of een upgrade zinvol is. Voor veel sites levert HTTP/2 al grote voordelen op, maar ik houd een oogje in het zeil op QUIC open.
Hosting selecteren: waar ik op let
Ik let op Hosting voor WordPress op schone HTTP/2-implementatie, TLS 1.3, Brotli en snelle NVMe-opslag. Goede providers bieden geoptimaliseerde PHP workers, object cache en edge functies. In vergelijkingen hebben platforms met WordPress-optimalisatie vaak een duidelijke voorsprong omdat ze latency en TTFB laag houden. Overzichten van testwinnaars tonen webhoster.de met sterke HTTP/2-ondersteuning en goede resultaten voor de snelheid van het wp-protocol. Deze korte tabel vat de kern samen en maakt het voor mij gemakkelijker om een duidelijke beslissing te nemen. Keuze:
| Hostingprovider | HTTP/2-ondersteuning | WordPress optimalisatie | Plaats |
|---|---|---|---|
| webhoster.de | Compleet | Uitstekend | 1 |
Kort samengevat
Ik zie HTTP/2 als een sterke basis, maar snelheid wordt alleen gecreëerd door slimme Prioriteitenmodulaire assets, goede caching, schone TLS en serverinstellingen. Ik haal oude HTTP/1.x trucjes uit de kast en vervang ze door splitsen, preload en weloverwogen push. Met een geschikt CDN, geoptimaliseerde afbeeldingen en betrouwbare cache-headers nemen belangrijke cijfers zoals FCP en LCP aanzienlijk toe. Solide hosts met HTTP/2, TLS 1.3 en Brotli bieden de hefboom voor kortere TTFB en stabiele responstijden. Als je WordPress op deze manier uitlijnt, krijg je wordpress http2 prestaties echte voordelen in plaats van alleen een nieuwe protocolregel.
