De fleste besøgende venter ikke mere end to til tre sekunder på at en side loader. Bruger den mere, forlader de den, og de fleste vender ikke tilbage. Den hyppigste årsag er ikke serveren. Det er store billeder, for mange plugins og JavaScript der blokerer rendering. En custom-kodet side starter med et rent udgangspunkt. En WordPress-installation med mange plugins kræver aktivt arbejde for at nå samme niveau.
Du kan have det bedste tilbud i din branche. Hvis siden tager for lang tid om at vise det, er chancen allerede spildt. Det er ikke overdrivelse. Det er en konsekvens af, hvordan vi bruger nettet.
Men hvad er "for langsom"? Og hvad gør man ved det? Det ser vi på her.
To til tre sekunder, så er det for sent
Forskning i brugeradfærd viser det samme mønster: de fleste besøgende forlader en side, der ikke loader inden for to til tre sekunder. Jo længere tid siden bruger, jo større er frafaldet, og det sker hurtigt. Ikke over minutter. Over sekunder.
Nyhedssider med millioner af besøgende om dagen kan klare det frafaldet. En virksomhedsside med ti til hundrede besøgende om dagen kan ikke. Hvert besøg er for vigtigt.
Google bruger sidehastighed som en del af sin rankingalgoritme. En langsom side konkurrerer på ujævne vilkår med en hurtig side, selv om indholdet er ens.
Google introducerede Core Web Vitals som rankingfaktor i 2021 under betegnelsen Page Experience. Det betyder, at en sides tekniske ydeevne, herunder lastetid og interaktivitet, nu indgår direkte i, hvordan Google vurderer den. Ikke som den eneste faktor, men som én af dem.
Hvad der faktisk gør en side langsom
Det er sjældent serveren. De fleste moderne hosting-løsninger er hurtige nok. Det, der bremser en side, er det, der sendes til browseren, og i hvilken rækkefølge det sendes.
- Store billeder uden komprimering
Et fullscreen-billede i original størrelse kan alene fylde to til fem megabyte. Det er den enkeltfaktor, der oftest giver den største hastighedsforskel, og den nemmeste at løse. Brug WebP-format, skalér billedet til den størrelse det vises i, og brug lazy loading på billeder der ikke er synlige over fold.
- JavaScript der blokerer rendering
Browseren stopper med at vise indhold, mens den indlæser og tolker JavaScript. Plugins der loades tidligt, analytics-kode, chat-widgets og andre scripts kan forsinke, hvornår brugeren overhovedet ser noget. Løsningen er defer og async på scripts der ikke er kritiske, og at fjerne dem der ikke bruges.
- For mange plugins
Hvert plugin tilføjer kode. CSS, JavaScript, HTTP-forespørgsler. Installerer du tyve plugins på en WordPress-installation, læser siden ikke bare det, du faktisk bruger. Det loader en stor mængde kode fra funktioner du måske aldrig aktiverer. Over tid er det det, der sænker sider der startede hurtigt.
- Ingen caching
Uden caching genererer serveren siden fra bunden ved hvert besøg. Med caching gemmes en færdig version, og brugeren får den hurtigt uden at serveren skal arbejde. Browser-caching, server-side caching og CDN er tre lag, der tilsammen kan gøre en mærkbar forskel for ladehastighed.
Core Web Vitals: det Google måler
Google offentliggør data fra Chrome om siders ydeevne og bruger tre konkrete mål til at vurdere brugeroplevelsen. Det er de såkaldte Core Web Vitals.
Hvad det måler
- LCP (Largest Contentful Paint): tid til det største synlige element
- INP (Interaction to Next Paint): reaktionstid ved klik
- CLS (Cumulative Layout Shift): om indhold hopper rundt ved load
Hvad der er "godt"
- LCP under 2,5 sek. = god
- LCP over 4 sek. = dårlig
- INP under 200 ms = god
- CLS under 0,1 = god
Du kan måle din egen side på Googles PageSpeed Insights. Det tager to minutter og giver dig en konkret score for din side set fra rigtige Chrome-brugere i Danmark.
Custom kode og hastighed: forbindelsen
Når jeg bygger en side fra bunden, starter jeg med en tom fil. Ingen plugin-lag, ingen tema-overhead, intet CSS fra funktioner siden ikke bruger. Siden loader kun det, den faktisk har brug for.
Det er ikke en garanti for hastighed. Dårlig custom-kode kan sagtens være langsom. Men udgangspunktet er renere. Der er ingen strukturelle bremsere fra start, og der er intet der gradvist sænker siden, efterhånden som der installeres et plugin til det ene og et andet til det næste.
WordPress kan godt loade hurtigt. Men det kræver aktiv indsats: minimal plugin-brug, aggressiv caching, håndoptimerede billeder og løbende vedligeholdelse. En custom-kodet side starter der uden ekstraarbejde.
Vil du vide mere om forskellen i praksis, har jeg skrevet en mere grundig gennemgang af, hvad du faktisk vælger, når du vælger custom-kode eller skabelon.
Hvad du kan gøre nu, uanset platform
Kører du allerede på en eksisterende side og vil forbedre den, er her de trin der typisk giver mest for pengene:
- Komprimer alle billeder. Brug WebP-format og skalér til faktisk visningsstørrelse. Det er det vigtigste enkeltskridt.
- Fjern plugins du ikke bruger. Hvert inaktivt plugin er potentiel kode der loades alligevel.
- Slå browser-caching til. Returbesøgende loader siden langt hurtigere, når statiske filer gemmes lokalt.
- Brug lazy loading. Billeder under fold behøver ikke loade, før brugeren ruller derhen.
- Mål regelmæssigt. PageSpeed Insights viser dig hvad der har ændret sig, og det ændrer sig, hver gang der installeres et nyt plugin eller uploades et nyt billede.
Hastighed er ikke et teknisk argument. Det er et forretningsargument
Når folk beder mig om en hurtig side, tænker de tit på Google-placeringer. Det er en reel grund. Men den mere direkte grund er den første oplevelse, den besøgende har af din virksomhed.
En side der loader hurtigt, føles professionel. En side der loader langsomt sender et signal, uanset om det er retfærdigt. Den besøgende oplever det, som om det tager lang tid at komme igennem til jer. Og de finder en, der svarer hurtigt.
Hastighed er ikke noget du ordner, fordi Google siger du skal. Du ordner det, fordi det er respekt for den tid, folk bruger på at finde frem til din side.
Vil du have en side der starter hurtigt og forbliver det? Se mere om, hvad jeg bygger, på hjemmeside-siden, eller skriv til mig direkte.
Spørgsmål og svar
Hvad er Core Web Vitals?
Core Web Vitals er tre mål, Google bruger til at vurdere din sides brugeroplevelse. LCP (Largest Contentful Paint) måler, hvor hurtigt det største synlige indhold loader. INP (Interaction to Next Paint) måler, hvor hurtigt siden reagerer, når du klikker på noget. CLS (Cumulative Layout Shift) måler, om elementer hopper rundt, mens siden loader. Siden 2021 indgår de i Googles rankingfaktorer.
Gør sidehastighed en forskel for mine Google-placeringer?
Ja. Google bruger Core Web Vitals som en del af sin rankingalgoritme under betegnelsen Page Experience. En langsom side med dårlige scores kan blive rangeret lavere end en tilsvarende side med bedre teknisk ydeevne. Det er ikke den eneste faktor, men det er en reel en af slagsen.
Hvad er et godt LCP-tal?
Google anbefaler et LCP på under 2,5 sekunder for at blive vurderet som god. Over 4 sekunder betragtes som dårligt. LCP måles fra brugeren klikker ind på siden, til det største synlige indholdselement, typisk en overskrift eller et billede, er fuldt indlæst.
Kan en WordPress-side loade hurtigt?
Ja, med den rette opsætning. Minimal plugin-brug, aggressiv caching og håndoptimerede billeder kan bringe en WordPress-side langt. Det kræver dog løbende aktiv vedligeholdelse. En custom-kodet side starter med et renere udgangspunkt, fordi der ikke er plugin-overhead fra start.
Hvad er det vigtigste jeg kan gøre for at gøre min side hurtigere?
Komprimer dine billeder. Det er den enkeltfaktor, der oftest giver den største forskel. Brug WebP-format og sørg for, at billederne ikke er større end de vises. Derefter: fjern plugins du ikke bruger, slå browser-caching til, og brug lazy loading på billeder under fold.
Anders, Ash Media. Jeg har bygget hjemmesider siden 2010. Hastighed er ikke et ekstraudstyr jeg tilbyder: det er en del af, hvordan siden bygges fra dag ét. Hjemmeside, foto og video fra samme person, så udtrykket hænger sammen.