...
logotyp för webbhotell

Minska WordPress HTTP-förfrågningar: Så här optimerar du hastigheten på din webbplats

WordPress HTTP-förfrågningar avgör hur snabbt dina sidor visas eftersom varje begäran om CSS, JS, bilder eller teckensnitt tar tid. Jag ska visa dig hur du kan minska antalet förfrågningar, undvika renderingsblockering och minimera Webbplats omedelbart märkbar accelerera.

Centrala punkter

Följande fokuspunkter kommer snabbt att leda dig till ett lägre antal förfrågningar och ett bättre LCP med stabil Funktion:

  • Caching användning: Webbläsar-, sid- och objektcache minskar antalet upprepade förfrågningar avsevärt.
  • CSS/JS optimera: Minifiera, paketera, integrera kritisk CSS, undvik renderingsblockering.
  • Bilder modernisera: WebP/AVIF, lazy loading, fasta dimensioner, inga hero sliders.
  • Skript delay: skjuta upp/fördröja för analys, pixlar, externa resurser.
  • CDN/Hosting välja: HTTP/3, edge caching, kort TTFB för globala användare.

Vad är HTTP-förfrågningar i WordPress?

Varje resurs på sidan genererar sin egen begäran, t.ex. CSS-filer, JavaScript, bilder, ikoner och Typsnitt. Moderna teman och plugins lägger snabbt till många små filer, vilket ökar antalet Förfrågningar enheter. Varje förfrågan innebär DNS-uppslagning, TCP-handskakning och överföring, och det är just denna overhead som räknas upp. Utan optimering ser jag ofta 70+ förfrågningar per sida, vilket märkbart fördröjer visningen. Målvärdena ligger klart under detta: under 50 är bra, under 25 är utmärkt för topphastighet. En liten minskning per sidtyp har stor inverkan eftersom mallar, sidhuvud och sidfot laddas överallt.

Varför varje förfrågan räknas

Varje ytterligare fil kan blockera rendering, särskilt synkront laddade CSS och JavaScript. Om dessa resurser förblir renderingsblockerande i sidhuvudet väntar användarna på vita fläckar och hoppar av. Detta har en inverkan på Core Web Vitals: LCP släpar efter, TBT växer och CLS ökar utan fasta åtgärder för bilder eller annonser. Jag kontrollerar därför konsekvent vilka resurser som verkligen är kritiska och vilka jag kan fördröja. Om du inte är säker på varför förfrågningar går långsammare trots små filstorlekar kan du läsa min guide Varför blockera HTTP-förfrågningar för praktiska förklaringar.

Snabbstart: åtgärder med störst hävstångseffekt

Jag börjar med caching, minifiering och lazy loading eftersom dessa steg ger stora effekter och kan implementeras snabbt. är. Ett bra cachningsplugin skapar statiska HTML-sidor och sparar Databas. Minifiering tar bort mellanslag och kommentarer, kombinerar filer och minskar nedladdningen avsevärt. Lazy Loading flyttar bilder utanför skärmen till baksidan, vilket hjälper First Paint och LCP. Med bara några klick kan direkta förbättringar uppnås utan att ändra temat.

Optimeringsåtgärd Begäran om nedsättning Verktyg/Plugins
Caching (webbläsare, sida, objekt) 50-80% för återbesök WP Rocket, LiteSpeed Cache, W3TC
Minifiera och kombinera 20-50% färre överföringar Autoptimera, Perfmatters
Lazy Loading-bilder 30-60% initial WP Rocket, kärnfunktion
CDN med HTTP/2/3 till 40% mer effektiv Cloudflare, QUIC.cloud

Smart användning av cachelagring

Först aktiverar jag webbläsarens cachelagring så att återvändande användare kan spara tillgångar lokalt från Cache och inte igen från Server belastning. Sidcaching genererar statisk HTML för besökare och sparar PHP-körning och databasfrågor. Med objektcaching (t.ex. Redis) förblir frekventa frågor i minnet, vilket minskar belastningen på admin- och butikssidor. Gzip/Brotli minskar dessutom överföringen, vilket minskar överföringstiden och datavolymen. Jag kontrollerar sedan utgångstiderna (cache control, expires) och om frågesträngar i onödan utesluter marknadsföringsskript från cachelagring.

CSS och JavaScript: Minifiera, kombinera, ladda

Många små filer innebär många Förfrågningar, därför sammanfattar jag stilar och skript så få som möjligt. Paket tillsammans. Minifiering minskar storleken, men det viktigaste är färre filer för den kritiska vägen. Jag inkluderar kritisk CSS inline så att innehåll som visas ovanför sidorna stylas omedelbart. Jag laddar icke-kritiska stilar asynkront eller via mediaattribut. Jag ställer in JavaScript för att skjuta upp eller fördröja, men testar sekvensen så att beroenden inte går sönder.

Bilder och media: stora besparingar

Bilder orsakar ofta den största andelen av Förfrågningar, därför konverterar jag till WebP eller AVIF och definierar fast Mått och dimensioner. Lazy loading fördröjer bilder utanför skärmen, men jag förladdar hjältebilden specifikt för en snabb LCP. Responsiv srcset säkerställer att mobila enheter laddar små varianter. Jag undviker sliders i hjältebilden eftersom de orsakar en massa filer och ommålningar. Jag använder också moderna formatspecifikationer för att hålla artefakterna till ett minimum.

Typsnitt, tredjepartsleverantörer och externa skript

Jag laddar externa teckensnitt lokalt så att jag har full kontroll över Caching och Förspänning har. Jag kombinerar typsnitt sparsamt, ofta räcker det med normal och fet stil med variabla typsnitt. För analysverktyg, tagghanterare och pixlar fördröjer jag laddningen till efter den första interaktionen eller laddar dem först efter onload-händelsen. Detta håller den kritiska vägen fri från onödiga filer. Jag kontrollerar också widgets för sociala medier och ersätter dem med statiska förhandsvisningar som jag laddar om vid klick.

Välja CDN och hosting på ett klokt sätt

Ett CDN för tillgångarna närmare användarna och minskar latenstiden och antalet Rundresor märkbar i den första uppmaning. HTTP/2/3 möjliggör multiplexering, prioritering och snabbare TLS-handskakningar. Edge-caching av HTML gör framför allt internationella målgrupper snabbare. På servern är jag uppmärksam på NVMe-lagring, aktuella PHP-versioner och kort TTFB. Bra hostar erbjuder verktyg som Brotli, Early Hints och QUIC, som jag aktivt använder.

Särskilda fall: REST-API och Admin-Ajax

Många installationer genererar bakgrundsförfrågningar via REST API eller admin-ajax.php, t.ex. för formulär, sökning eller dynamiska Widgets. Jag identifierar dessa anrop i nätverksfliken och kontrollerar om pollningsintervallen kan minskas eller förfrågningar sammanfattas. Om möjligt cachar jag API-svar på serversidan och ställer in hastighetsgränser. För mer djupgående optimeringar hänvisar jag till min guide till REST-API-prestanda, som visar typiska bromsar och lösningar. Så här minskar jag upprepade bakgrundsfrågor utan att förlora funktioner.

Mätning och övervakning för bibehållen hastighet

Jag testar varje ändring med PageSpeed Insights, Lighthouse och GTmetrix så att jag får den verkliga Effekt se och nej Regression capture. Mål: mindre än 50 förfrågningar per sida, LCP under 2,5 s, TBT under 200 ms och CLS under 0,1. Jag tittar också på vattenfallsdiagrammet för att visualisera blockering av resurser, DNS-uppslagningar och köer. Kom ihåg: antalet förfrågningar räknas ofta mer än den rena filstorleken; det är precis vad jag förklarar i artikeln om Fokus på förfrågningar. Kontinuerlig övervakning håller optimeringarna stabila och mätbara.

Avancerat: HTTP/2/3, oanvänd CSS och DB-underhåll

Med HTTP/2/3 drar jag nytta av multiplexering, prioritering och snabbare Handskakningar, vilket innebär väntetider för parallelladdade Filer förkortad. Jag tar bort oanvänd CSS för att göra stylesheets mindre och minska antalet förfrågningar. För återkommande layouter lönar det sig att använda kritisk CSS per mall, inte per sida. I databasen tar jag bort revisioner, utgångna transienter och cron-kroppar så att backend och dynamiska funktioner förblir snabba. Sådana steg påskyndar processen märkbart, särskilt för stora projekt med många plugins.

Plugin- och temahygien

Jag kontrollerar regelbundet vilka plugins som duplicerar funktioner eller sällan används. bli, och ersätta tunga paket med lättare Alternativa lösningar. Lean-teman som Astra eller GeneratePress genererar mycket få förfrågningar och kan optimeras på ett snyggt sätt. Inom temat avaktiverar jag moduler som jag inte behöver, t.ex. ikonsamlingar eller sliders. Jag konfigurerar också sidbyggare på ett minimalistiskt sätt så att de bara laddar widgets som används. Funktionsflaggor och modulära köer hjälper till att undvika filslöseri.

Målinriktad resursanvändning och prioritering

Förutom cachelagring och paketering Resurs tips de avgörande sista detaljerna. Jag använder bara Preload för riktigt kritiska resurser: LCP-bilden, den huvudsakliga CSS:en (om den inte är inline som Critical CSS) och den primära Webfont-fil. För många förladdningar blockerar prioriteringen och kan ha motsatt effekt. För typsnitt ställer jag in teckensnittsvisning (swap/optional) för att undvika FOIT, och skapa en förladdning med korrekt som-attribut så att webbläsaren inte laddar filen två gånger.

DNS-förhämtning och Förkoppla Jag använder det sparsamt för obligatoriska tredjepartsleverantörer (t.ex. betalningsleverantörer i kassan). Preconnect sparar mig TLS-handskakning, Detta är dock bara meningsfullt om resursen verkligen behövs. Förhämtning Jag använder för resurser som förmodligen kommer att behövas i nästa steg (t.ex. nästa pagineringssida). I samband med Tidiga tips servern kan signalera förladdningar tidigt - detta minskar tiden till den första byten medan anslutningen upprättas.

  • Förhandsladdning: Endast för LCP-bild, huvud-CSS, kritisk teckensnittsfil.
  • Preconnect: För säkra, oundvikliga tredjepartsdomäner.
  • Prefetch: För resurser/sidor som kan komma att behövas snart.
  • DNS prefetch: För lågt men gynnsamt förberedande arbete med externa värdar.

Där det är möjligt använder jag också Prioriterade tips (fetchpriority=“high“ för LCP-bilden) så att webbläsaren förstår vad som verkligen måste komma först. Detta minskar laddningstiden och Sekvens för begäran kontroll mer exakt.

WordPress-tillgångar: ladda bara det du behöver

Många sidor laddar stilar och skript globalt, även om de bara är nödvändiga på ett fåtal mallar. Jag identifierar sådana kandidater och laddar dem villkorlig - Till exempel formulärskript endast på kontaktsidor, slider CSS endast där sliders finns och WooCommerce-tillgångar endast på butiks-, produkt- och kassasidor.

Särskilt givande saneringsarbete:

  • Emoji-Deaktivera skript och stilar i frontend, eftersom moderna system har inbyggda emojis.
  • oEmbedfungerar om inget innehåll från tredje part är inbäddat.
  • Dashicons i frontend om temat inte kräver dem.
  • jQuery Migrera om inga gamla skript hänger kvar.
  • Gutenberg block-bibliotek Ladda bara CSS om blockstilarna faktiskt används i frontend.

För finkornig tillgångshantering förlitar jag mig på modulära köer (per mall/block) eller använder ett optimeringsplugin som kan avaktivera resurser per sida. Detta krymper Lista över förfrågningar snabbt från ett stort antal filer till en handfull riktigt nödvändiga tillgångar.

WooCommerce, formulär och andra dynamiska områden

Butiker har sina egna specialfall: Den välkända vagnsfragment-script kan orsaka många upprepade förfrågningar via admin-ajax.php. Jag laddar bara den här funktionen i områden där det är meningsfullt (produkt-, kundkorgs-, kassasidor) och avaktiverar den i bloggar eller landningssidor. Jag cachar minikorgar där det är möjligt och uppdaterar dem bara när det finns verklig interaktion. För produktbilder använder jag konsekvent srcset och preloade den första synliga bilden.

För formulär reducerar jag Opinionsundersökningar-intervall, skicka valideringar i buntar och använda avbouncing så att indata inte överförs med varje tangenttryckning. Där det är möjligt genomför jag sökningar och filter via cachade slutpunkter (t.ex. REST) så att upprepade identiska förfrågningar serveras från cacheminnet. Detta minskar serverbelastningen, antalet HTTP-förfrågningar och förbättrar den upplevda hastigheten.

Förbättra bilder, iframes och media ytterligare

För LCP-bilden använder jag hämtningsprioritet="hög" och ställa in en exakt förspänning. Samtidigt är jag uppmärksam på bredd/höjd eller en CSSAspect-ratio, så att det inte blir någon layoutförskjutning. Jag förser bilder med avkodning="async", för att undvika blockering av renderingen, och ställ in Lata endast där det är meningsfullt: The första Bild ska inte vara lat, alla andra ska vara det.

Jag ersätter externa iframes (YouTube, Maps, Social) med förhandsgranskning av ljus. Istället för att ladda hela widgeten omedelbart visar jag en statisk förhandsgranskningsbild och laddar den riktiga inbäddningen först efter klick. På så sätt eliminerar jag många initiala förfrågningar som är onödiga för den första interaktionen. För mina egna videor använder jag affischbilder, moderna codecs och adaptiv streaming så att inga stora filer blockerar synkroniseringen.

Rena cache-rubriker och cache-busting

Många förfrågningar beror på att webbläsarens eller CDN:s cacheminnen inte fungerar optimalt. Jag definierar för statiska tillgångar (CSS, JS, typsnitt, bilder) långa TTL:er med Cache-kontroll och sätta flaggan oföränderlig. För att rulla ut uppdateringar på ett säkert sätt använder jag Versionering i filnamn eller WordPressver-parametrar. Viktigt: CDN måste cachelagra frågesträngar på rätt sätt, annars kommer du att förlora ?ver=-parametrar förlorar sin effekt och den laddas om i onödan.

ETag och Senast modifierad så att revalideringar går snabbt och if-none-match/if-modified-since-svar bidrar till att spara datavolym. Med stale-under-validering webbplatsen förblir responsiv medan uppdateringar utförs i bakgrunden. Tillsammans resulterar detta i färre rundresor och rent schemalagda uppdateringar utan cache-kaos.

Undvik misstag: När bundling och minify är för mycket av det goda

Med HTTP/2/3 Jag behöver inte pressa in varje bit i en enda fil. För stora buntar gör att Cache-träffar, eftersom varje förändring ogiltigförklarar hela blocket. Jag hittar en medelväg: ett fåtal, logiskt separerade paket som håller den kritiska vägen liten och ändå tillåter återanvändning (t.ex. ett globalt kärnpaket, ett mallpaket, ett sällan ändrat leverantörspaket).

Minifiering kan också orsaka problem: Uglify/Minify kan skada funktioner i vissa plugins. Jag testar därför steg för steg och utesluter kritiska skript från Minify/Combine om det behövs (t.ex. inline JSON, betalningsskript, Captcha). Målet är en mer stabil, kort kritisk väg, inget riskpaket som går sönder vid varje uppdatering.

Mätmetodik: tillförlitliga tester i stället för gissningar

Jag mäter med reproducerbara profiler: Skrivbord och mobil separat, med realistiska bandbredder och CPU-strypning. I DevTools använder jag Täckningtill Oanvänd CSS/JS och vattenfallsdiagrammet för att se vilka förfrågningar som väntar, staplas eller saktas ner av prioriteringar. Jag jämför Första utsikten och Upprepa vy, för att kontrollera om cache-headers verkligen fungerar och om antalet förfrågningar faktiskt halveras eller förbättras vid återbesök.

Jag har också satt upp skyddsräcken: maximalt antal Förfrågningar per sidtyp, LCP-mål, budget för tredjepartsleverantörer. Nya funktioner tas bara i drift om de överensstämmer med budgetarna. På så sätt hålls webbplatsen snabb på lång sikt - inte bara direkt efter en optimeringsrunda.

Finesser på serversidan: TTFB och TLS

Förutom det rena antalet förfrågningar räknas också serverns svarstid. Jag håller OPcache aktiv, justera PHP-FPM, se till att det finns få plug-ins och minimera databasRundresor. Med TLS säkerställer jag en kort certifikatkedja, aktuell TLS 1.3 och aktiverad OCSP-häftning. Tillsammans med HTTP/3 minskar detta handskakningstiderna och snabbar upp de första förfrågningarna avsevärt - särskilt för mobila användare.

Kortfattat sammanfattat

Jag minskar antalet förfrågningar genom att aktivera cachelagring, paketera CSS/JS, modernisera bilder och fördröja externa skript. belastning. Jag hostar teckensnitt lokalt och förladdar kritiska resurser på ett rent och riktade. Ett CDN med HTTP/2/3 och snabb hosting minskar latensen och TTFB. Jag använder mätningar i PageSpeed, Lighthouse och GTmetrix för att kontrollera om LCP, TBT och CLS glider in i målkorridoren. På bara några timmar tar denna process ofta språnget från tröga 70+ förfrågningar till snabba sidor som ligger långt under 50.

Aktuella artiklar