WordPress hastighedsoptimering, der kan måles

Det første, jeg gør ved et langsomt site, er ikke at røre noget. Jeg måler. Ellers ender man med at bruge en dag på at optimere noget, der kostede 40 millisekunder, mens den rigtige synder står urørt.

Core Web Vitals er de tal, der tæller

Google måler tre ting, og de har hver deres grænse. LCP er det øjeblik, hvor sidens største indholdselement er tegnet færdigt – typisk et heltebillede eller en overskrift. Den skal under 2,5 sekunder. INP måler, hvor lang tid der går, fra nogen klikker, til siden reagerer synligt. Den skal under 200 millisekunder. CLS måler, hvor meget indholdet hopper rundt under indlæsningen, og skal under 0,1.

INP afløste den gamle FID-måling i marts 2024, og den er markant sværere at snyde. Hvor FID kun målte første interaktion, kigger INP på hele besøget. Et site, der føles trægt at klikke rundt i, kan ikke længere gemme sig bag et pænt førstehold.

Labdata og feltdata er ikke det samme

Kører du en PageSpeed-test, får du labdata: en simuleret indlæsning på en simuleret telefon på en simuleret forbindelse. Det er nyttigt til fejlfinding, men det er ikke dit site.

Feltdata kommer fra rigtige besøgende via Chrome User Experience Report og opgøres over en rullende periode på 28 dage. Google vurderer dig på 75. percentil – altså den oplevelse, tre ud af fire besøgende får eller bedre. Det er de tal, der har med placeringer at gøre, og det er dem, jeg arbejder efter.

Forskellen er ikke akademisk. Et site kan score 95 i labtest og stadig ligge dårligt i feltdata, fordi halvdelen af besøgende kommer fra mobil på en middelmådig forbindelse, mens testen kørte på fiber.

Hvad målingen typisk afslører

• Serverens svartid: ligger TTFB over et halvt sekund, er det hosting eller manglende caching – ikke frontend.
• Det største element: næsten altid et billede. Er det ikke optimeret, er resten sekundært.
• Blokerende ressourcer: CSS og JavaScript, der skal hentes, før noget som helst kan tegnes.
• Skrifttyper: webfonts hentet fra en ekstern server koster både tid og et ekstra opslag.

Optimering har en rækkefølge, og den er næsten altid den samme. Tager man den bagfra, bruger man de fleste timer på de mindste gevinster.

1. Billederne

Det er her, de fleste sekunder ligger. Et produktbillede på 3 MB, der vises i 600 pixels bredde, kan næsten altid komme under 100 KB uden synligt tab. Moderne formater som WebP og AVIF komprimerer markant bedre end JPEG, og WordPress har haft lazy loading indbygget siden version 5.5 – men kun på billeder, der har fået de rigtige attributter med.

2. Serveren

Er svartiden høj, betyder alt andet mindre. Sidecaching løser det for de fleste sider ved at servere færdigbygget HTML i stedet for at køre PHP og databasekald ved hver eneste visning. Er den stadig høj bagefter, er det hostingen, og så siger jeg det hellere end at optimere udenom.

3. Temaet

Et tungt tema er den sværeste at gribe ind i, fordi den ligger i bunden af alting. Nogle gange kan man slå moduler fra og komme langt. Andre gange er den ærlige anbefaling et nyt tema – og så handler samtalen om WordPress themes i stedet for om optimering.

4. Scripts og tredjeparter

Chatbokse, cookiebannere, analyseværktøjer og indlejrede kort er hver for sig små. Tilsammen kan de nemt koste et helt sekund på mobil. Det er sjældent populært at røre dem, men det er ofte her, den sidste halve gevinst ligger.

Hastighed og synlighed hænger sammen

Core Web Vitals er en del af Googles vurdering, så hastighed er ikke bare komfort – det er en del af din søgemaskineoptimering. Men den vigtigste effekt er den simple: folk bliver. Et site, der reagerer med det samme, føles pålideligt, og det føles det, længe før nogen kan sætte ord på hvorfor.

Er sitet først hurtigt, giver resten også bedre mening: videreudvikling, nye sektioner og de automatiseringer, der kører bag kulisserne. Man bygger nødigt ovenpå noget, der allerede har svært ved at bære sig selv.