Din hjemmeside føles tung. Siderne er længe om at komme frem, og måske har du prøvet en hastighedstest, som gav en rød score. Så melder spørgsmålet sig: Hvad er der galt?
Det ærlige svar er, at der sjældent kun er én årsag. WordPress’ egen dokumentation nævner blandt andet hostingmiljøet, opsætningen af WordPress og softwareversionerne som forhold, der påvirker hastigheden. Derfor giver det mening at finde årsagen, før du køber en større server, installerer endnu et plugin eller bestiller en helt ny hjemmeside.
Her gennemgår jeg de typiske årsager i den rækkefølge, jeg vil råde dig til at undersøge dem, og hvordan du selv kan få et første overblik.
Mål først, og mål det rigtige
Googles gratis værktøj PageSpeed Insights er et fint sted at starte. Det viser to slags tal, og forskellen på dem er vigtig.
Feltdata
- Kommer fra
- Rigtige besøgende i Chrome.
- Dækker
- De seneste 28 dage.
- Bedst til
- At prioritere, fordi tallene viser, hvad dine besøgende faktisk oplever.
- Vær opmærksom på
- Sider med få besøg har ikke altid nok data.
Laboratoriedata
- Kommer fra
- Én test i et kontrolleret miljø.
- Dækker
- Én enhed og én forbindelse, lige nu.
- Bedst til
- Fejlfinding, og til at se med det samme, om en ændring gjorde en forskel.
- Vær opmærksom på
- Resultatet varierer fra test til test.
Har du begge slags tal for en side, anbefaler Googles vejledning på web.dev som hovedregel, at du prioriterer ud fra feltdata. Laboratorietesten bruger du bagefter til at finde årsagen.
Har siden få besøgende, er der ikke altid feltdata nok. Så viser værktøjet tal for hele webstedet eller slet ingen feltdata. I det tilfælde har du kun laboratorietesten, og den skal læses som et pejlemærke, ikke som sandheden om alle besøg.
Google bruger tre mål, Core Web Vitals, til at beskrive en god oplevelse:
- LCP (Largest Contentful Paint): Det største indholdselement skal være vist inden for 2,5 sekunder.
- INP (Interaction to Next Paint): Siden skal reagere på klik og tryk inden for 200 millisekunder.
- CLS (Cumulative Layout Shift): Indholdet må ikke hoppe rundt, mens siden indlæses. Målet er 0,1 eller derunder.
Målet er, at mindst 75 % af sidevisningerne holder sig inden for grænserne, opgjort hver for sig for mobil og computer.
Mit råd er ikke kun at teste forsiden. En produktside, en kategoriside og et blogindlæg kan være bygget vidt forskelligt, og det er ikke sikkert, at problemet ligger det samme sted.
Fra klik til vist side: her kan tiden gå
Når du ved, at siden er langsom, er næste spørgsmål, hvor ventetiden opstår. Det hjælper at kende vejen fra et klik til en færdig side. Resten af artiklen følger den vej.
-
Browseren spørger
Den besøgende klikker, og browseren beder din server om siden.
-
Serveren svarer
WordPress bygger siden med PHP og databasen, eller sender en færdig kopi fra cachen.
Se på: hosting, PHP-version og cache.
-
Filerne hentes
Browseren henter billeder, skrifter og scripts, også dem fra andre servere.
Se på: billeder, plugins, tema og scripts udefra.
-
Siden kan bruges
Det største element er vist, og siden reagerer, når man trykker.
Måles med: LCP og INP.
Serveren er længe om at svare
Før browseren kan vise noget som helst, skal serveren sende det første svar. Den ventetid kaldes TTFB (Time to First Byte). web.dev nævner 0,8 sekunder eller derunder som en grov rettesnor. TTFB er ikke selv en af de tre Core Web Vitals, men Googles vejledning om LCP skriver, at en høj TTFB kan gøre det svært eller ligefrem umuligt at nå en LCP på 2,5 sekunder.
Det er værd at hæfte sig ved. Er det første svar langsomt, hjælper det kun lidt at komprimere billeder. Så er det hosting, cache og softwareversioner, du skal se på først.
På et delt webhotel ligger din side på en server sammen med mange andre, og WordPress’ dokumentation gør opmærksom på, at hostingen har betydning for, hvilke optimeringer der er mulige. Det betyder ikke, at svaret altid er en dyrere server. Det betyder, at hosting hører med i undersøgelsen. Jeg har skrevet mere om, hvad jeg selv tilbyder, på siden om serverhosting.
WordPress-versionen og PHP-versionen er to forskellige ting
Softwareversioner er nævnt flere gange ovenfor, og der er to, som ofte bliver blandet sammen.
WordPress-versionen
- Hvad det er
- Selve systemet, du logger ind i.
- Hvor den opdateres
- Inde i WordPress. Det samme gælder tema og plugins.
- Hvor du ser den
- I WordPress under Værktøjer, i Site Health på fanen Info.
PHP-versionen
- Hvad det er
- Programmeringssproget, WordPress er skrevet i. Det kører på serveren.
- Hvor den skiftes
- Hos din hostingudbyder, ikke inde i WordPress.
- Hvor du ser den
- Samme sted, i afsnittet Server.
WordPress skriver, at det er din hostingudbyder, der bestemmer, hvilke PHP-versioner du kan vælge, og at mange udbydere lader dig skifte selv.
WordPress’ dokumentation skriver, at softwareopdateringer ofte retter fejl og forbedrer ydeevnen, og kalder det afgørende at køre de nyeste udgaver af blandt andet PHP og databasen. PHP’s udviklere understøtter hver udgave i fire år: to år med fejlrettelser og derefter to år, hvor kun kritiske sikkerhedsfejl bliver rettet. Når de fire år er gået, er udgaven ikke længere understøttet, og PHP anbefaler at opgradere så hurtigt som muligt.
De to hænger sammen. WordPress vedligeholder en oversigt over, hvilke PHP-versioner hver WordPress-version er testet med. Mit råd er at se på den oversigt og på dine plugins, før PHP-versionen bliver skiftet, og at prøve skiftet på en kopi af siden først. Jeg nævner bevidst ingen versionsnumre her, for de ændrer sig. Se de aktuelle i kilderne nederst.
Siden bliver bygget forfra ved hvert besøg
WordPress sammensætter som udgangspunkt en side med PHP og opslag i databasen, når nogen beder om den. En cache gemmer det færdige resultat. WordPress’ dokumentation beskriver, hvordan cache-plugins gemmer indlæg og sider som statiske filer, der sendes til de besøgende, så serveren skal arbejde mindre.
Dokumentationen peger på cache som det sted, hvor en hurtig indsats giver størst gevinst for mindst besvær. Men den skal sættes rigtigt op. Har du en webshop, må kurven, kassen og Min konto ikke caches. WooCommerce skriver i sin dokumentation, at de sider skal blive ved med at være dynamiske, fordi de viser oplysninger om den enkelte kunde og kundens kurv.
En forkert opsat cache kan altså give fejl, der er værre end en langsom side. Mit råd er derfor at teste et køb fra ende til anden, hver gang cachen er ændret.
Billederne er tungere end nødvendigt
På mange sider er det største element et billede, og så er det billedet, der afgør LCP. Et topbillede, der vises i større opløsning end nødvendigt, kan fylde langt mere, end skærmen har brug for.
WordPress’ dokumentation anbefaler at vælge det rigtige format og den rigtige komprimering til hvert billede og at overveje et moderne format som WebP, der fylder mindre.
Der er også en fælde den anden vej. Lazy loading, hvor billeder først hentes, når de er ved at komme ind på skærmen, er nyttigt længere nede på siden. Men web.dev er meget direkte: LCP-billedet må aldrig lazy-loades, fordi det forsinker netop det billede, der skal vises først.
Plugins og tema gør for meget
Ifølge WordPress’ dokumentation har temaet stor betydning for hastigheden, og det samme har antallet af plugins og hvor tungt de arbejder. Rådet derfra er enkelt: Deaktivér og slet de plugins, du ikke bruger, og prøv at slå udvalgte plugins fra for at måle, om de trækker siden ned.
Mit råd er at gøre det på en kopi af siden, hvis du har en. At slå plugins fra på en webshop, mens kunderne handler, er ikke en test, du har lyst til at lave.
Antallet er ikke hele forklaringen. Et enkelt plugin, der indlæser sine filer på alle sider, selv om det kun bruges på kontaktsiden, kan betyde mere end flere små. Det er en tommelfingerregel og ikke et måltal; hvad der gælder på din side, ser du ved at måle med og uden. Oprydning af den slags hører naturligt sammen med vedligehold af siden.
Scripts udefra bremser siden
Statistik, annoncer, delingsknapper til sociale medier og indlejrede videoafspillere bliver hentet fra andre servere end din egen. web.dev beskriver, hvordan den slags tredjepartsscripts kan gøre en side langsommere, blandt andet fordi de udløser mange netværkskald og sender meget JavaScript, der holder browseren beskæftiget.
Gå listen igennem, og spørg for hvert script, om det stadig bliver brugt. Et sporingsscript fra en kampagne, der sluttede for længe siden, koster stadig tid ved hvert besøg.
Hvad en god score ikke fortæller
Google anbefaler gode Core Web Vitals, både af hensyn til søgning og til brugeroplevelsen generelt. På siden om sideoplevelse oplyser Google, at Core Web Vitals bruges af rangeringssystemerne, men også, at søgemaskinen altid forsøger at vise det mest relevante indhold, også når sideoplevelsen ikke er i top. Gode tal er altså ikke i sig selv en garanti for en topplacering.
Målet er derfor ikke 100 i laboratorietesten. Målet er, at dine besøgende ikke skal vente, og at siden bliver ved med at fungere, mens den bliver hurtigere.
Hvor skal du begynde?
Vil du selv i gang, er det her den rækkefølge, jeg vil foreslå:
- Mål to eller tre vigtige sidetyper Brug PageSpeed Insights, og notér, om tallene er feltdata eller laboratoriedata.
- Se på serverens svartid Er den høj, så begynd med hosting, cache og softwareversioner.
- Find ud af, hvad LCP-elementet er Er det et billede, så se på størrelse, format og indlæsning.
- Gennemgå plugins og scripts udefra Fjern det, der ikke bliver brugt.
- Ret én ting ad gangen Mål igen på samme måde. Ellers ved du ikke, hvad der virkede.
Noget af det kan du selv klare. Andet kræver adgang til server, tema og kode, og nogle gange viser det sig, at en mindre rettelse ikke er nok, og at der skal en større forbedring til. Er du i tvivl om, hvor grænsen går, har jeg skrevet om det i Ny hjemmeside, eller kan den gamle forbedres?
Vil du hellere have mig til at se på det, kan du læse om hastighedsoptimering. Du er også velkommen til at skrive til mig via kontaktsiden. Send et link til siden, og fortæl, hvor du oplever, at den er langsom, så vender jeg tilbage på mail.