Kort svar: Test samme anonyme URL flere gange og gem TTFB, cacheheader og tidspunkt. Hvis første request er langsom og de næste er hurtige, er cacheopvarmning central. Hvis både cachede og uncached requests er langsomme, skal proxy, netværk og origin undersøges. Er kun uncached eller indloggede requests langsomme, skal du måle PHP-, database- og pluginarbejde. Hæv ikke servergrænser, før laget er dokumenteret.
TTFB – Time to First Byte – måler tiden fra requesten starter, til browseren modtager den første byte af svaret. Den omfatter derfor ikke kun WordPress. DNS, forbindelse, TLS, proxy, edge-cache, webserver, PHP og database kan alle bidrage.
En enkelt TTFB-værdi fortæller ikke, hvilket led der er langsomt. Denne guide bruger en kontrolleret række af requests til at skelne cachelevering fra origin-generering.
Afgrænsning: Fremgangsmåden er revideret den 28. august 2026 med WordPress 7.1, PHP 8.4.23, FlyingPress 5.6.5 og Chrome 151 som versionskontekst. Tidsværdierne i dine egne sager skal komme fra den konkrete URL og mærkes med region, protokol, cachetilstand og tidspunkt; guiden indeholder ikke et skjult benchmark af Hostious' produktion.
På denne side
Vælg én offentlig URL og notér:
Mål mindst fem gange under samme forhold. Gem rå output, ikke kun gennemsnittet. Hvis den første request er markant langsommere, er det netop en del af diagnosen.
En anvendelig måling bør kunne gennemgås af en anden person uden forklaring ved siden af. Nummerér requests fra 1 til 6. Brug den første som bevidst kold request, hvis du har purget test-URL'en, og markér de næste fem som varme. For hver række gemmer du starttid, HTTP-status, samlet tid, TTFB, cacheheader og en kort body-kontrol, eksempelvis sidens titel eller en hash af HTML'en.
Body-kontrollen forhindrer en klassisk fejl: at en meget hurtig respons viser en sikkerhedsside, en tom fejlskabelon eller gammelt indhold. Hvis status er 200, men titel og canonical ikke svarer til den ønskede side, må målingen ikke tælle som en succes.
Brug medianen af de varme requests som sammenligning, og behold samtidig højeste og laveste værdi. En serie på 180, 190, 195, 205 og 900 millisekunder fortæller noget andet end fem målinger tæt omkring 334 millisekunder, selv om gennemsnittet kan ende i samme område. Den enkelte spids kræver korrelation med log og ressourcegraf; den stabile forsinkelse peger på en vedvarende del af kæden.
Mål ikke fra en browser med en aktiv administratorsession, når den offentlige cache skal vurderes. Admincookies kan give BYPASS og sende requesten gennem WordPress, selv om almindelige besøgende får et cachet svar.
Test den endelige canonicale HTTPS-URL direkte. En kæde fra HTTP til HTTPS, fra www til ikke-www og videre til en ny slug tilføjer tid, før den rigtige side overhovedet bliver bedt om.
Gem hver status og Location-header. Ret interne links til den endelige URL ved kilden, hvis de går gennem unødvendige redirects. Fjern ikke en nødvendig historisk redirect uden at kende dens trafik og backlinks.
Kør først en anonym request efter en kontrolleret purge af kun test-URL'en, hvis systemet tillader det. Kør derefter flere identiske requests.
| Resultat | Tolkning | Næste undersøgelse |
|---|---|---|
| Første langsom, næste hurtige og dokumenteret HIT | Page cache virker, men kold generering er dyr | Origin/PHP samt preloadstrategi |
| Alle langsomme og dokumenteret MISS/BYPASS | Cachen bruges ikke for denne request | Cookies, querystrings, regler og URL-type |
| Alle langsomme trods dokumenteret HIT | Tid kan ligge før/omkring cachelaget | Edge, proxy, netværk, cachelager og geografi |
| Anonyme hurtige, indloggede langsomme | Page cache skjuler en langsom WordPress-request | PHP, database, adminhooks og personlige funktioner |
| Kun én skabelon langsom | Skabelonspecifikt arbejde | Queries, builder, widgets og eksterne kald |
Brug cacheheaderen eller et andet dokumenteret bevis fra den aktuelle stack. Gæt ikke ud fra pluginets aktive status.
Hvis et CDN eller en proxy ligger foran, skal du skelne edge fra origin. Brug hostingens eller proxyens understøttede diagnostik, fx et origin-testendpoint eller en sikker hosts-mapping i et kontrolleret miljø. Del ikke origin-IP offentligt.
Sammenlign:
Hvis origin er hurtig, men den offentlige vej er langsom, skal proxy-, edge- eller netværkslaget undersøges. Hvis origin også er langsom, går du videre til WordPress/PHP.
Server-Timing-headere kan gøre underdele synlige, hvis platformen eller applikationen måler dem. En profileringsløsning på staging kan desuden vise tid i hooks, databasequeries og eksterne HTTP-kald.
Start med tidskorrelation:
Hvis accessloggen viser lang upstreamtid, men PHP-profilen ikke gør, kan kø, workerstart eller et andet originled være involveret. Hvis én hook eller query dominerer hver gang, har du en afgrænset kandidat.
På staging med samme data og plugins:
Antallet af plugins er ikke bevis. En enkel pluginliste kan stadig indeholde et dyrt kald, og mange veldesignede plugins kan have minimal effekt på en bestemt route.
Se efter queries, der gentages, scanner mange rækker, venter på låse eller bliver genereret af den samme skabelon. Persistent object cache kan reducere nogle gentagne opslag, men den løser ikke en langsom query eller et eksternt API-kald automatisk.
Kontrollér også autoloadede options, hvis profilen viser tid eller volumen dér. Slet ikke options efter størrelse alene. Identificér ejer, læsemønster og konsekvens, og brug pluginets dokumenterede oprydning eller en backupbaseret ændring.
En request kan være hurtig alene og langsom under kø. Sammenhold TTFB-spidser med:
En fuld purge efterfulgt af aggressiv preload kan skabe en bølge af uncached PHP-requests. Hvis origin allerede er presset, skal preloadens concurrency ikke hæves som første løsning.
Vælg den mindste ændring, som passer til beviset:
Tallene her er regneeksempler, ikke resultater fra et aktivt website.
Den kolde request bruger 1.400 millisekunder, mens fem varme requests ligger mellem 120 og 155 millisekunder og viser det forventede HIT. Det beviser ikke, at alt er godt, men det afgrænser problemet. Hvis en fuld purge eller udløb sker ofte, vil mange brugere ramme den dyre generering. Næste kontrol er derfor den uncached PHP-/databaseprofil og årsagen til hyppige purges – ikke et nyt frontendplugin.
Før: en bestemt skabelon bruger en langsom query på alle kolde requests. Efter en målrettet rettelse skal den kolde serie falde, mens den varme cache stadig viser korrekt, aktuelt indhold. Kontrollér også, at purge ved redigering stadig invaliderer den rigtige side.
Alle seks requests ligger omkring 800 millisekunder, selv om cacheheaderen viser HIT, og body er korrekt. Her vil en databaseoprydning sandsynligvis ikke påvirke den målte vej, fordi WordPress-genereringen allerede er sprunget over. Sammenlign regioner, proxy-/edge-timing, cachelager og forbindelsesopbygning. Hvis direkte, godkendt originmåling er hurtig, men den offentlige vej er langsom, skal sagen sendes til det lag, som faktisk tilføjer tiden.
I begge forløb er beslutningen baseret på forskellen mellem cachetilstande. Det er mere værd end at sammenligne én tilfældig PageSpeed-kørsel før og efter.
En hurtigere HTML-respons må ikke skyldes, at personligt eller nyt indhold bliver genbrugt forkert. Test derfor mindst:
Hvis den varme TTFB falder, men en anden session ser den forkerte kurv eller en gammel pris, er rettelsen forkastet. Ydelse godkendes først sammen med korrekt indhold.
Gentag hele requestserien efter ændringen:
Rapportér median, spredning og cachetilstand. “Bedste kørsel” er ikke en stabil forbedring. Kontrollér også LCP; lavere TTFB bør ikke være købt med forældet indhold eller ødelagt personalisering.
Hvis ændringen ikke giver en reproducerbar gevinst, gendan den præcise før-værdi og purge kun det relevante lag. Genindsæt ikke slettede data manuelt, hvis en databasebackup er den sikre rollback.
Kontakt hosting med URL, tidspunkt, cachetilstand, request-id, accesslogtid og ressourcegraf, når problemet ligger i webserver, PHP-pool, databaseinfrastruktur eller disk. Kontakt pluginudvikleren med en minimal stagingreproduktion, når én komponent konsekvent dominerer requesten. Hostious WordPress-support kan samle beviserne.
Gem rå timing-output, headers, redirectkæde, request-id, accesslogvarighed og et profileringsudtræk. Brug filnavne med dato, URL-type og cachetilstand, og fjern cookies, tokens, IP'er og kundedata før materialet deles.
Under 200 ms på cachede sider og under 600 ms på ucachede er solidt. Over 1 sekund konsekvent betyder, at origin arbejder for hårdt – eller at requesten slet ikke rammer cachen.
Klassisk koldt cache-mønster: første request genererer siden, de næste får den fra cache. Løsningen er preload/crawler, så cachen er varm, før besøgende kommer – ikke en større server.
Mål en ucachet side og se serverens timing-logs: lang PHP-tid med hurtige queries peger på kode/plugins; langsomme enkeltqueries peger på databasen. Gæt aldrig – begge dele kan måles direkte.
