Kort svar: Mål først, om tiden forsvinder før HTML-svaret, ved det største synlige element, under en brugerinteraktion eller i layoutskift. Det peger på henholdsvis TTFB, LCP, INP eller CLS. Ret derefter én dokumenteret flaskehals ad gangen, og sammenlign under samme cache- og netværksforhold. Flere optimeringsplugins gør ikke automatisk WordPress hurtigere; de kan skjule årsagen og skabe nye fejl.
“WordPress er langsom” er ikke en diagnose. En side kan svare sent fra serveren og derefter tegne hurtigt. En anden kan levere HTML med det samme, men vente på et hero-billede. En tredje ser hurtig ud, men reagerer trægt, når brugeren åbner menuen. De tre problemer kræver forskellige løsninger.
Denne guide begynder derfor med fire målinger og en funktionsbaseline. Målet er en hurtig side, der stadig viser korrekt indhold, reagerer på input og kan vedligeholdes efter næste opdatering.
Målegrundlag: Den 28. august 2026 var arbejdsrammen WordPress 7.1, PHP 8.4.23, FlyingPress 5.6.5 og Chrome 151. Det er versionskontekst, ikke et løfte om et bestemt hastighedstal. Egne før/efter-resultater skal altid mærkes med URL, dato, cachetilstand, enhed og netværksprofil.
På denne side
Test ikke kun forsiden. Vælg mindst én URL fra hver skabelon, som har betydning for besøgende eller omsætning:
En optimering kan hjælpe en enkel artikel og samtidig skade en produktside med variationer. Skriv derfor skabelontype ved hver måling.
En brugbar baseline indeholder mere end en score:
| Data | Hvorfor den er nødvendig |
|---|---|
| URL, tidspunkt og testplacering | Gør målingen reproducerbar |
| Enhed og netværksprofil | Mobil og desktop har forskellig CPU- og netværksbelastning |
| Kold eller varm cache | Skelner generering fra cachelevering |
| TTFB og response headers | Viser tid før første byte og cachelag |
| LCP-element og underdele | Viser hvad der faktisk forsinker hovedindholdet |
| Interaktion og INP-spor | Viser hvilken handling der reagerer langsomt |
| Layout shifts | Viser hvornår og hvorfor indhold flytter sig |
| Requestliste og konsol | Afslører store assets, fejl og blokeringer |
Feltdata og laboratoriedata besvarer forskellige spørgsmål. Feltdata viser rigtige besøgendes oplevelse over tid. En labtest hjælper dig med at reproducere og forklare et problem. Brug feltdata til prioritering og labdata til fejlfinding.
Skriv én række pr. URL og én kolonne pr. observation. En landingsside kan eksempelvis have normal varm TTFB, men sen LCP, fordi hero-billedet først opdages fra en CSS-fil. En produktside kan have fin LCP ved indlæsning, men en langsom variantvælger. De to rækker skal ikke ende med den samme “optimer alt”-handling.
Tilføj en kolonne med næste beslutning:
Den sidste mulighed er vigtig. At rulle en ændring tilbage er et kvalificeret resultat, når den ikke løser den målte flaskehals.
TTFB er tiden frem til den første byte. Den omfatter mere end PHP: forbindelse, proxy, cache og origin kan alle bidrage. Test samme anonyme URL flere gange.
Kontrollér cachebeviset i response headers eller den dokumenterede cachemekanisme. En hurtig respons er ikke i sig selv bevis på et HIT. Brug guiden til høj TTFB for et fuldt cached/uncached beslutningstræ.
Vælg ikke et nyt plugin, før du ved, hvilket lag der mangler. To page-cacheplugins kan gøre purge uforudsigelig. Se sammenligningen af WP Rocket, FlyingPress og LiteSpeed Cache.
LCP fortæller, hvornår det største synlige indholdselement er færdigt. Find det faktiske element på både mobil og desktop; det kan være et billede, en overskrift eller et andet blok-element.
Del problemet op i:
Hvis hero-billedet først indsættes af JavaScript eller gemmes i CSS, opdages det senere end et almindeligt <img> i HTML. Hvis det lazy-loades, kan hentningen blive forsinket. Hvis download er hurtig, men elementet vises sent, skal du se på CSS, JavaScript, font eller animation, der holder renderingen tilbage.
Komprimér og dimensionér billeder efter deres faktiske visning, men preload ikke alle billeder. De konkurrerer om båndbredden. LCP-guiden viser, hvordan du vælger den ene kritiske ressource.
INP handler om reaktionen på brugerinput over sidens levetid. En side kan få en flot indlæsningsscore og stadig fryse, når brugeren åbner menu, vælger en variant eller skriver i et søgefelt.
Start med feltdata: hvilken URL-type og interaktion er dårlig? Reproducer derefter med en performanceoptagelse. Del hændelsen i:
Se efter lange main-thread-opgaver, tunge event handlers, gentagne layoutberegninger og et unødigt stort DOM. Delay JavaScript kan reducere startarbejde, men må ikke udskyde koden, som selve interaktionen behøver. Brug INP-guiden til en konkret optagelse.
CLS måler uventede layoutskift. Find ikke kun det element, der flyttede sig; find det element, der skubbede til det.
Hyppige årsager er:
Labtesten under indlæsning kan overse skift efter scroll og klik. Gennemfør derfor hele brugerrejsen. CLS-guiden beskriver, hvordan skiftet isoleres.
Antallet af plugins er ikke en præcis hastighedsmåling. Et lille plugin kan køre en dyr query på hver request, mens et større plugin kan have minimal effekt på den testede side.
Brug staging og en profilerings- eller querymåling til at finde:
Deaktivér den mistænkte komponent målrettet på staging og gentag samme test. Hvis problemet kun opstår under belastning, skal du bruge ressourcegraf og tidsstemplede logs – ikke en enkelt hurtig sidevisning.
En sikker rækkefølge er:
Aktivér Remove Unused CSS og Delay JavaScript én funktion ad gangen. Test alle dynamiske tilstande, før gevinsten accepteres. Et skjult menu-panel kan have selectors, som ikke er synlige for optimizerens første sidevisning, og en formular kan være afhængig af et forsinket script.
Databaser skal undersøges, ikke masseopryddes på mistanke. Tag en backup og mål:
Slet ikke revisionsdata, transients eller plugin-tabeller alene for at reducere et tal i et dashboard. Transients kan blive genopbygget, og ukendte tabeller kan være nødvendige. Brug pluginets egen afinstallation eller en dokumenteret, målrettet procedure.
Efter hver ændring:
Tag mindst flere ens målinger; netværk og kø kan variere. Sammenlign median og mønster, ikke kun den bedste kørsel.
Antag, at tre varme anonyme requests har ens og lav TTFB, mens LCP-sporet viser, at hero-billedet først begynder at hente sent. Billedfilen er moderat, og render delay er kort. Her peger beviset på resource load delay – ikke på mere serverkapacitet eller databaserens.
Før ændringen gemmer du HTML-kilden, requeststarten og hvilken billedkandidat mobilen valgte. På staging gør du billedet synligt direkte i det native hero-element og undtager kun denne ressource fra lazy load. Efter ændringen skal requesten starte tidligere, den samme mobile kandidat må ikke hentes to gange, og menu samt layout skal stadig fungere. Hvis LCP-kandidaten skifter til overskriften, dokumenterer du skiftet i stedet for at sammenligne to tal, der beskriver forskellige elementer.
Et syntetisk Article Lab-scenarie kan bruges til at øve denne læsning, men det er hverken CrUX-, Lighthouse- eller produktionsdata. Det afgørende bevis kommer fra den faktiske side under en beskrevet testprofil.
Gem før-værdien for hver indstilling. Ved regression gendanner du den seneste ændring, rydder den berørte cache og kontrollerer, at den oprindelige funktion og assetkæde er tilbage. Undgå en samlet “nulstil alt”, fordi den fjerner din mulighed for at finde årsagen.
Eskalér til hosting ved dokumenteret origin-, PHP-, database-, disk- eller workerproblem. Eskalér til tema- eller pluginudvikleren, når en minimal stagingreproduktion peger på deres kode. Hostious WordPress-support kan hjælpe med at samle måling, log og rollback til en afgrænset sag.
Gem rå headers, HAR, performance trace, layout-shift-data og tidsstemplede servermålinger sammen med din før/efter-log. Skjul cookies, tokens, IP'er, kundeoplysninger og interne stier.
Fordi cache kun hjælper på gentagne besøg af samme side. Høj TTFB på første besøg, tunge billeder (LCP) og langsom JavaScript (INP) skal løses ved kilden – mål først, så du ved hvilken af dem, der bremser.
PageSpeed Insights til Core Web Vitals med felt-data, og browserens DevTools til at se, HVAD der er langsomt. Brug samme URL, enhed og cachetilstand ved hver måling, ellers sammenligner du æbler og pærer.
Kun hvis målingerne peger på serveren – typisk høj TTFB på uncachede sider. Er problemet billeder eller JavaScript, flytter problemet bare med over på den nye server.
