Ga naar de inhoud 
WordPress HTTP-verzoeken bepalen hoe snel je pagina's verschijnen, omdat elk verzoek voor CSS, JS, afbeeldingen of lettertypen tijd kost. Ik laat je zien hoe je het aantal aanvragen kunt verminderen, renderblokkering kunt voorkomen en de website onmiddellijk merkbaar versnellen.
Centrale punten
De volgende aandachtspunten zullen snel leiden tot een lager aantal vragen en een beter resultaat. LCP met stabiele Functie:
- Caching gebruik: Browser-, pagina- en objectcache verminderen herhaalde aanvragen aanzienlijk.
- CSS/JS optimaliseren: Minimaliseer, bundel, integreer kritieke CSS, voorkom renderblokkering.
- foto's moderniseren: WebP/AVIF, lui laden, vaste afmetingen, geen hero sliders.
- Scripts vertragen: uitstellen/vertragen voor analytics, pixels, externe bronnen.
- CDN/Hosting kiezen: HTTP/3, edge caching, korte TTFB voor wereldwijde gebruikers.
Wat zijn HTTP-verzoeken in WordPress?
Elke bron op de pagina genereert zijn eigen verzoek, d.w.z. CSS-bestanden, JavaScript, afbeeldingen, pictogrammen en Lettertypen. Moderne thema's en plugins voegen snel veel kleine bestanden toe, waardoor het aantal Vragen schijven. Elk verzoek omvat het opzoeken van DNS, TCP-handshake en overdracht, en het is precies deze overhead die optelt. Zonder optimalisatie zie ik vaak 70+ aanvragen per pagina, wat de weergave merkbaar vertraagt. De streefwaarden liggen hier duidelijk onder: onder de 50 is goed, onder de 25 is uitstekend voor topsnelheid. Een kleine reductie per paginatype heeft een brede impact omdat sjablonen, kop- en voetteksten overal worden geladen.
Waarom elke vraag telt
Elk extra bestand kan het renderen blokkeren, vooral synchroon geladen CSS en JavaScript. Als deze bronnen render-blocking blijven in de kop van de pagina, wachten gebruikers op witruimtes en stuiteren ze. Dit heeft een impact op Core Web Vitals: LCP blijft achter, TBT groeit en CLS stijgt zonder vaste maatregelen voor afbeeldingen of advertenties. Ik controleer daarom consequent welke bronnen echt kritisch zijn en welke ik kan uitstellen. Als u niet zeker weet waarom aanvragen vertragen ondanks kleine bestandsgroottes, lees dan mijn handleiding Waarom HTTP-verzoeken blokkeren voor praktische uitleg.
Snelle start: maatregelen met de grootste hefboomwerking
Ik begin met caching, minification en lazy loading omdat deze stappen grote effecten opleveren en snel kunnen worden geïmplementeerd. zijn. Een goede caching-plugin maakt statische HTML-pagina's en slaat de Database. Minification verwijdert spaties en commentaar, voegt bestanden samen en vermindert downloads aanzienlijk. Lazy Loading verplaatst afbeeldingen buiten het scherm naar achteren, wat First Paint en LCP helpt. Met slechts een paar klikken kunnen directe verbeteringen worden bereikt zonder het thema te veranderen.
| Optimalisatiemaatregel | Verzoeken om vermindering | Gereedschappen/plugins |
|---|---|---|
| Caching (browser, pagina, object) | 50-80% voor terugkerende bezoeken | WP Rocket, LiteSpeed Cache, W3TC |
| Minimaliseren en combineren | 20-50% minder transfers | Autoptimaliseren, Perfmatters |
| Luie laadfoto's | 30-60% initieel | WP Rocket, kernfunctie |
| CDN met HTTP/2/3 | naar 40% efficiënter | Cloudflare, QUIC.cloud |
Slim gebruik van caching
Ik activeer eerst browser caching zodat terugkerende gebruikers assets lokaal kunnen opslaan vanaf de Cache en niet opnieuw van de Server laden. Pagina caching genereert statische HTML voor bezoekers en bespaart PHP-uitvoering en database queries. Met object caching (bijv. Redis) blijven frequente query's in het geheugen, waardoor de admin- en winkelpagina's minder worden belast. Gzip/Brotli verminderen bovendien de overdracht, wat de overdrachtstijd en het gegevensvolume vermindert. Vervolgens controleer ik de verlooptijden (cache control, expires) en of query strings marketingscripts niet onnodig uitsluiten van caching.
CSS en JavaScript: Minimaliseren, combineren, laden
Veel kleine bestanden betekent veel Verzoeken, Daarom vat ik stijlen en scripts zo weinig mogelijk samen. Bundels samen. Minificatie vermindert de grootte, maar het belangrijkste is minder bestanden voor het kritieke pad. Ik neem kritieke CSS inline op, zodat boven de vouw geplaatste inhoud onmiddellijk wordt gestyled. Niet-kritieke stijlen laad ik asynchroon of via het media-attribuut. Ik stel JavaScript in om uit te stellen of te vertragen, maar test de volgorde zodat afhankelijkheden niet worden verbroken.
Afbeeldingen en media: grote besparingen
Afbeeldingen veroorzaken vaak het grootste deel van Vragen, Daarom converteer ik naar WebP of AVIF en definieer ik vaste Afmetingen. Lazy loading vertraagt afbeeldingen buiten het scherm, maar ik laad de heldenafbeelding vooraf specifiek voor een snelle LCP. Responsive srcset zorgt ervoor dat mobiele apparaten kleine varianten laden. Ik vermijd sliders in de hero omdat ze veel bestanden en repaints veroorzaken. Ik gebruik ook moderne formaatspecificaties om artefacten tot een minimum te beperken.
Lettertypen, externe leveranciers en externe scripts
Ik laad externe lettertypen lokaal zodat ik volledige controle heb over Caching en Voorbelasting hebben. Ik combineer lettertypestijlen spaarzaam, vaak zijn normaal en vet met variabele lettertypen voldoende. Voor analytics, tag managers en pixels stel ik vertragingen in tot na de eerste interactie of ik laad ze pas na de onload-gebeurtenis. Dit houdt het kritieke pad vrij van onnodige bestanden. Ik controleer ook widgets voor sociale media en vervang ze door statische voorvertoningen die ik bij een klik opnieuw laad.
CDN en hosting verstandig kiezen
Een CDN brengt bedrijfsmiddelen dichter bij de gebruikers en vermindert de latentie en het aantal Retourvluchten merkbaar in de eerste oproep. HTTP/2/3 maakt multiplexing, prioritering en snellere TLS-handshakes mogelijk. Edge caching van HTML maakt vooral internationale doelgroepen sneller. Op de server let ik op NVMe-opslag, actuele PHP-versies en korte TTFB. Goede hosters bieden tools zoals Brotli, Early Hints en QUIC, die ik actief gebruik.
Speciale gevallen: REST-API en Admin-Ajax
Veel installaties genereren achtergrondverzoeken via de REST API of admin-ajax.php, bijvoorbeeld voor formulieren, zoeken of dynamisch Widgets. Ik identificeer deze oproepen op het netwerk tabblad en controleer of de polling intervallen kunnen worden gereduceerd of verzoeken kunnen worden samengevat. Waar mogelijk cache ik API-reacties op de server en stel ik snelheidslimieten in. Raadpleeg voor meer diepgaande optimalisaties mijn gids voor REST-API prestaties, die typische remmen en oplossingen laat zien. Dit is hoe ik herhaalde achtergrondquery's verminder zonder functies te verliezen.
Meten en bewaken voor aanhoudende snelheid
Ik test elke verandering met PageSpeed Insights, Lighthouse en GTmetrix, zodat ik de echte resultaten krijg. Effect zien en nee Regressies capture. Doelen: minder dan 50 aanvragen per pagina, LCP onder 2,5 s, TBT onder 200 ms en CLS onder 0,1. Ik kijk ook naar de watervalgrafiek om blokkerende bronnen, DNS lookups en wachtrijen te visualiseren. Onthoud: het aantal aanvragen telt vaak zwaarder dan de pure bestandsgrootte; ik leg dit precies uit in het artikel over de Focus op vragen. Continue monitoring houdt optimalisaties stabiel en meetbaar.
Geavanceerd: HTTP/2/3, ongebruikte CSS en DB-onderhoud
Met HTTP/2/3 profiteer ik van multiplexing, prioritering en snellere Handdrukken, wat betekent dat wachttijden voor parallel geladen Bestanden ingekort. Ik verwijder ongebruikte CSS om stylesheets kleiner te maken en het aantal aanvragen te verminderen. Voor terugkerende lay-outs is kritische CSS per sjabloon de moeite waard, niet per pagina. In de database verwijder ik revisies, verlopen transients en cron lijken zodat de backend en dynamische functies snel blijven. Zulke stappen versnellen het proces merkbaar, vooral bij grote projecten met veel plugins.
Plugin- en themahygiëne
Ik controleer regelmatig welke plugins functies dupliceren of zelden worden gebruikt. worden, en zware verpakkingen vervangen door lichtere Alternatieven. Magere thema's zoals Astra of GeneratePress genereren heel weinig aanvragen en kunnen netjes worden geoptimaliseerd. Binnen het thema schakel ik modules uit die ik niet nodig heb, zoals pictogramverzamelingen of sliders. Ik configureer page builders ook op een minimalistische manier zodat ze alleen widgets laden die worden gebruikt. Feature flags en modulaire enqueues helpen om bestandsverspilling te voorkomen.
Gericht gebruik van middelen en prioritering
Naast caching en bundeling Hulpbronnen de beslissende afwerking. Ik gebruik Preload alleen voor echt kritieke bronnen: de LCP-afbeelding, de belangrijkste CSS (indien niet inline als Kritieke CSS) en de primaire Webfont-bestand. Te veel vooraf laden blokkeert de prioritering en kan het tegenovergestelde effect hebben. Voor lettertypen stel ik lettertype-weergave (verwisselen/optioneel) om FOIT te vermijden en een voorbelasting met correcte als-attribuut zodat de browser het bestand niet twee keer laadt.
DNS-prefetch en Voorverbinding Ik gebruik het spaarzaam voor verplichte externe providers (bijv. betalingsproviders in de kassa). Preconnect bespaart me de TLS-handdruk, Dit heeft echter alleen zin als de bron echt nodig is. Prefetch Ik gebruik deze voor bronnen die waarschijnlijk nodig zijn in de volgende stap (bijv. de volgende paginapagina). In verband met Vroege hints de server kan preloads vroegtijdig signaleren - dit verkort de tijd tot de eerste byte terwijl de verbinding tot stand wordt gebracht.
- Vooraf laden: Alleen voor LCP-afbeelding, hoofd-CSS, kritisch lettertypebestand.
- Preconnect: Voor veilige, onvermijdelijke domeinen van derden.
- Prefetch: Voor bronnen/pagina's die mogelijk snel nodig zijn.
- DNS prefetch: Voor weinig maar gunstig voorbereidend werk met externe hosts.
Waar mogelijk gebruik ik ook Hints met prioriteit (fetchpriority=“high“ voor de LCP-afbeelding) zodat de browser begrijpt wat echt eerst moet komen. Dit vermindert de laadtijd en Aanvraagvolgorde controle nauwkeuriger.
WordPress assets: alleen laden wat je nodig hebt
Veel pagina's laden stijlen en scripts globaal, hoewel ze maar op een paar sjablonen nodig zijn. Ik identificeer zulke kandidaten en laad ze voorwaardelijk - Bijvoorbeeld formulierscripts alleen op contactpagina's, slider-CSS alleen waar sliders bestaan en WooCommerce-assets alleen op winkel-, product- en afrekenpagina's.
Bijzonder dankbaar opruimwerk:
- Emoji-Deactiveer scripts en stijlen in de frontend, omdat moderne systemen native emoji's hebben.
- oEmbedfuncties als er geen inhoud van derden is ingesloten.
- Dashicons in de voorkant als het thema ze niet vereist.
- jQuery migreren als er geen oude scripts hangen.
- Gutenberg blokbibliotheek Laad CSS alleen als blokstijlen daadwerkelijk worden gebruikt in de frontend.
Voor fijnkorrelig activabeheer vertrouw ik op modulaire enqueues (per sjabloon/blok) of gebruik ik een optimalisatie-plugin die bronnen per pagina kan deactiveren. Dit verkleint de Lijst aanvragen snel van talloze bestanden naar een handvol echt noodzakelijke onderdelen.
WooCommerce, formulieren en andere dynamische gebieden
Winkels hebben hun eigen speciale gevallen: De bekende kartfragmenten-script kan veel herhaalde verzoeken via admin-ajax.php veroorzaken. Ik laad deze functie alleen in gebieden waar het zinvol is (product-, winkelwagen-, kassapagina's) en deactiveer deze in blogs of landingspagina's. Ik cache minicarts waar mogelijk en werk ze alleen bij als er echte interactie is. Voor productafbeeldingen gebruik ik consequent srcset en de eerste zichtbare afbeelding vooraf laden.
Voor vormen verminder ik Polling-intervallen, stuur validaties in bundels en gebruik debouncing zodat invoer niet met elke toetsaanslag wordt verzonden. Waar mogelijk realiseer ik zoekopdrachten en filters via eindpunten in de cache (bijv. REST) zodat herhaalde identieke verzoeken vanuit de cache worden geserveerd. Dit vermindert de belasting van de server, het aantal HTTP-verzoeken en verbetert de waargenomen snelheid.
Afbeeldingen, iframes en media verder verfijnen
Voor de LCP afbeelding gebruik ik fetchpriority="hoog" en stel een nauwkeurige voorspanning in. Tegelijkertijd let ik op breedte/hoogte of een CSSbeeldverhouding, zodat de lay-out niet verschuift. Ik lever afbeeldingen met decoderen="async", om de weergave niet te blokkeren en stel luie alleen waar het zinvol is: De eerste Beeld moet niet lui zijn, alle anderen wel.
Ik vervang externe iframes (YouTube, Maps, Social) door licht previews. In plaats van de hele widget meteen te laden, laat ik een statische voorbeeldafbeelding zien en laad ik de echte embed pas nadat je erop hebt geklikt. Op deze manier elimineer ik talloze initiële verzoeken die onnodig zijn voor de eerste interactie. Voor mijn eigen video's gebruik ik posterafbeeldingen, moderne codecs en adaptieve streaming zodat grote bestanden de synchronisatie niet blokkeren.
Schone cache headers en cache busting
Veel verzoeken ontstaan omdat browser- of CDN-caches niet optimaal werken. Ik definieer voor statische activa (CSS, JS, lettertypen, afbeeldingen) lange TTL's met Cachebeheer en stel de vlag onveranderlijk. Om updates veilig uit te rollen, gebruik ik Versiebeheer in bestandsnamen of WordPressver-parameters. Belangrijk: Het CDN moet query strings correct cachen, anders verlies je ver=-parameters verliezen hun effect en het wordt onnodig herladen.
ETag en Laatst gewijzigd zodat revalidaties snel verlopen en if-none-match/if-modified-since-responses helpen om gegevensvolume te besparen. Met stale-while-revalidate blijft de site responsief terwijl updates op de achtergrond worden uitgevoerd. Samen resulteert dit in minder round trips en netjes geplande updates zonder cachechaos.
Fouten vermijden: Wanneer bundelen en minifyen te veel van het goede zijn
Op HTTP/2/3 Ik hoef niet alles in één bestand te proppen. Te grote bundels maken Cache-hits, omdat elke wijziging het hele blok ongeldig maakt. Ik vind een middenweg: een paar logisch gescheiden bundels die het kritieke pad klein houden en toch hergebruik toestaan (bijv. een globale kernbundel, een sjabloonbundel, een zelden veranderde leveranciersbundel).
Minificatie kan ook problemen veroorzaken: Uglify/Minify kan functies in sommige plugins beschadigen. Ik test daarom stap voor stap en sluit indien nodig kritieke scripts uit van Minify/Combine (bijv. inline JSON, betaalscripts, Captcha). Het doel is een stabieler, Kort kritiek pad, geen risicobundel die bij elke update stuk gaat.
Meetmethodologie: betrouwbaar testen in plaats van giswerk
Ik meet met reproduceerbare profielen: Desktop en mobiel apart, met realistische bandbreedtes en CPU throttling. In de DevTools gebruik ik Dekkingom Ongebruikte CSS/JS en het watervaldiagram om te zien welke aanvragen wachten, gestapeld zijn of vertraagd zijn door prioriteiten. Ik vergelijk Eerste Blik en Herhaalde weergave, om te controleren of cache headers echt werken en of het aantal verzoeken daadwerkelijk wordt gehalveerd of beter is bij het opnieuw bezoeken.
Ik heb ook vangrails ingesteld: maximaal aantal Verzoeken per paginatype, LCP-doel, budget voor externe leveranciers. Nieuwe functies gaan alleen live als ze voldoen aan de budgetten. Dit houdt de site snel op de lange termijn - niet alleen direct na een optimalisatieronde.
Subtiliteiten aan de serverkant: TTFB en TLS
Naast het pure aantal verzoeken telt ook de reactietijd van de server mee. Ik houd OPcache actief, stem PHP-FPM af, zorg ervoor dat plugins slank zijn en minimaliseer de databaseRetourvluchten. Met TLS zorg ik voor een korte certificaatketen, huidig TLS 1.3 en geactiveerd OCSP nieten. Samen met HTTP/3 verkort dit de handshake tijden en versnelt het de initiële verzoeken aanzienlijk - vooral voor mobiele gebruikers.
Kort samengevat
Ik verminder het aantal requests door caching te activeren, CSS/JS te bundelen, afbeeldingen te moderniseren en externe scripts te vertragen. belasting. Ik host lettertypen lokaal en laad kritieke bronnen schoon en vooraf. gericht. Een CDN met HTTP/2/3 en snelle hosting verminderen latency en TTFB. Ik gebruik metingen in PageSpeed, Lighthouse en GTmetrix om te controleren of LCP, TBT en CLS in de doelcorridor glijden. In slechts een paar uur tijd maakt dit proces vaak de sprong van trage 70+ requests naar snelle pagina's die ruim onder de 50 zitten.
