Derfor er din hjemmeside langsom — og hvad det koster

Hastighed er ikke en teknisk detalje, du kan tage senere. Google måler den direkte og bruger den i rangeringen, og besøgende forlader sider, der ikke kommer frem.

Den gode nyhed er, at næsten alle langsomme sider fejler på de samme fem ting. Her er de — og hvordan du finder din egen.

Mål først, gæt aldrig

Åbn PageSpeed Insights, indtast din adresse, og vælg mobil.

Det tal, der betyder mest, hedder LCP (Largest Contentful Paint): tiden, til det største element på skærmen er synligt. Googles grænse er 2,5 sekunder. Er du over, taber du både besøgende og placeringer.

To andre tal er værd at kigge på: CLS (hopper indholdet rundt, mens siden loader?) og INP (hvor længe om at reagere, når nogen trykker?).

Kør testen i en inkognito-fane uden udvidelser. Ellers måler du dine egne browserudvidelser.

Årsag 1: Billederne

Den absolut hyppigste. Et foto direkte fra et kamera fylder 4–8 MB. Det samme billede i det rigtige format og den rigtige størrelse fylder 80–200 kB.

Tre ting at gøre:

• Konvertér til WebP. Typisk 30–50 % mindre end JPEG ved samme kvalitet. Vi sparede 439 kB på ét enkelt gennemløb af vores eget site.
• Skalér til den viste størrelse. Et billede, der vises i 600 px bredde, skal ikke være 3.000 px bredt.
• Sæt loading="lazy" på alt under folden. Så hentes billederne først, når man scroller ned til dem.

Det her alene løser en betydelig del af tilfældene.

Årsag 2: For meget JavaScript

Chat-widgets, cookiebannere, analyseværktøjer, karruseller, animationsbiblioteker. Hver især er de små. Tilsammen er de ofte 1–2 MB, der skal hentes, læses og køres, før noget kan bruges.

Åbn udviklerværktøjernes netværksfane og sortér efter størrelse. Kig ned over listen og spørg ved hver enkelt: giver den her mig kunder?

Chat-widgets er de værste. En typisk chatløsning koster 400–900 kB. Får den dig ikke henvendelser, du ellers ikke ville have fået, betaler du med placeringer for ingenting.

Årsag 3: Skrifttyper hentet udefra

Google Fonts indlæst fra Googles servere kræver et opslag til et fremmed domæne, før teksten kan tegnes. På mobil koster det typisk 200–500 ms.

Løsningen er at hoste skrifttyperne selv, som woff2, gerne som variable fonts i latin-udgave. Og brug font-display: swap, så teksten er synlig med det samme i stedet for at vente.

Årsag 4: Din animation ER din LCP

Det her er den, der overrasker selv folk i branchen, og vi faldt selv i den.

Mange sider har entré-animationer: elementer starter med opacity: 0 og toner ind, når man scroller. Ser godt ud. Men hvis dit hero-billede eller din overskrift starter usynlig og først toner ind efter en forsinkelse — så er det dit LCP-tidspunkt.

Vi har målt en side, hvor 1,9 af 3,5 sekunders LCP var ren designbeslutning. Netværket var færdigt for længst. Elementet var bare gjort usynligt med vilje.

Vigtig detalje: en session-baseret “vis kun animationen første gang”-løsning hjælper ikke. En måling starter altid i en tom profil og ser derfor altid animationen.

Find LCP-elementet efter areal over folden, og regn dets synlighedstidspunkt ud fra CSS’en — ikke fra netværksfanen.

Årsag 5: Serveren er langsom

Er der over 600 ms, før det første byte kommer, ligger problemet på serveren.

På WordPress betyder det næsten altid enten billig delt hosting eller for mange plugins, der skal køre ved hvert kald. Caching hjælper meget. Bedre hosting hjælper mere.

En statisk side har ikke problemet — der er ingenting at generere, filen findes allerede.

Hvad langsomhed koster

To ting, begge målbare:

Placeringer. Google bruger Core Web Vitals som rangeringsfaktor. Ved ellers lige indhold vinder den hurtige side.

Konverteringer. Folk forlader sider, der ikke svarer. På mobil, hvor forbindelsen er dårligere og tålmodigheden mindre, er effekten størst. Din egen statistik kan vise det: sammenlign afvisningsprocenten på mobil og computer. Er der stor forskel, er hastighed en sandsynlig del af forklaringen.

Sådan gør du det bedre — i rækkefølge

1. Komprimér billeder. Størst effekt, mindst arbejde.
2. Fjern det JavaScript, du ikke bruger. Vær hård. Widgets, der ikke giver henvendelser, ud.
3. Hoste skrifttyper selv. En times arbejde, 200–500 ms hjem.
4. Fjern forsinkelser på det, der er synligt fra start. Animér gerne alt under folden.
5. Sæt fetchpriority="high" på LCP-billedet. Så henter browseren det først.
6. Slå caching til. Statiske filer med hash i navnet kan caches i et år.
7. Indlæs tredjeparts-indhold, når man scroller til det. Ikke ved sidestart.

En advarsel om komprimering

En specifik fælde, vi selv er faldet i: slå aldrig komprimering til på video i proxy-laget.

Både Traefik og Caddy kan sættes til at gzip’e alt, uden at filtrere på filtype. Så bliver .mp4 og .webm også komprimeret — og en videokilde med Content-Encoding: gzip kan Chrome ikke afspille, mens Safari mister den understøttelse af delvise hentninger, den kræver for overhovedet at starte.

Resultatet er en video, der ikke virker for nogen, uden en eneste fejlmeddelelse nogen steder. Gevinsten i vores tilfælde var 620 bytes ud af 1,1 MB.

Tjek det med:

curl -sI -H "Accept-Encoding: gzip" https://ditdomæne.dk/video/film.webm

Der skal stå accept-ranges: bytes og ingen content-encoding.

Ofte stillede spørgsmål

Hvad er en god hastighed? LCP under 2,5 sekunder på mobil, og en samlet sidestørrelse under 1 MB. Under 500 kB er godt.

Skal jeg have 100 i PageSpeed? Nej. Over 90 på mobil er fint. De sidste point koster ofte mere, end de giver.

Kan en WordPress-side være hurtig? Ja, med caching, få plugins og ordentlig hosting. Det kræver bare vedvarende disciplin. Se WordPress eller skræddersyet.

Hjælper det at fjerne cookiebanneret? Har du intet, der kræver samtykke, behøver du intet banner. Cookiefri statistik findes og måler fint. Det er både hurtigere og bedre for konverteringen.