Hurtig hjemmeside: hvorfor det betyder noget, og hvad der gør den langsom

En hurtig hjemmeside viser det vigtigste inden for 2,5 sekunder på en almindelig mobiltelefon på et almindeligt mobilnet, reagerer, når man trykker, og hopper ikke rundt, mens den loader. Det er ikke en teknisk ambition. Det er forskellen på, om besøgende bliver eller går: Hvert ekstra sekund koster besøgende og henvendelser, og Google bruger hastigheden, når den sorterer resultaterne. De fleste langsomme sider er langsomme af fem grunde, og de kan alle findes og rettes.

Her er, hvad hurtig betyder i tal, hvorfor det betyder noget for forretningen, de fem ting, der gør sider langsomme, og hvad I selv kan gøre ved dem. Det er indgangen; de tekniske artikler står der link til undervejs.

Hvad hurtig betyder

Google ser på tre tal fra rigtige besøg og kalder dem Core Web Vitals:

• LCP (Largest Contentful Paint): Hvornår det største element, typisk et billede eller en overskrift, er vist. Mål: 2,5 sekunder eller mindre.
• INP (Interaction to Next Paint): Hvor hurtigt siden reagerer, når man trykker, skriver eller klikker. Mål: 200 millisekunder eller mindre.
• CLS (Cumulative Layout Shift): Hvor meget siden hopper, mens den loader. Mål: 0,1 eller mindre.

En side består, når mindst 75 % af besøgene klarer grænsen. Tallene kommer fra besøgende med almindelige telefoner og forbindelser, ikke fra jeres kontor med fiber og en ny bærbar, og Google opgør mobil og computer hver for sig. Det er derfor, en side kan føles hurtig for jer og være langsom for Google, og det er næsten altid mobiltallene, der dumper. Kør jeres egen side gennem hastighedstesten, og se tallene for mobil.

Hvorfor det betyder noget

For besøgende: Selv små forskelle tæller. I et studie, Deloitte lavede for Google på 37 europæiske og amerikanske brands, steg konverteringsraten på webshops med 8,4 %, når mobilsiden blev 0,1 sekund hurtigere gennem hele købsforløbet. På en mobil med dårlig dækning er en side på 4 MB ikke langsom; den loader ikke. Og besøgende, der venter, stoler mindre på det, de til sidst ser. Hurtige sider konverterer bedre, alt andet lige, og det gælder både webshops og en tømrers kontaktformular.

For Google: Core Web Vitals er en del af Googles vurdering af sideoplevelsen, og Google skriver selv, at de bruges af rangeringssystemerne. Det er ikke den største faktor; Google viser altid det mest relevante indhold, også når sideoplevelsen er dårlig. Men når mange sider er lige relevante, kan hastigheden gøre forskellen, og i konkurrenceprægede søgninger er det ofte den forskel, der afgør det. Google viser desuden tallene i Search Console, så I kan se, hvilke sider der dumper.

For jer selv: En langsom side er typisk også en tung side at redigere, en dyr side at hoste og en side, der går ned, når der kommer trafik. Hastighed er et symptom på, hvordan siden er bygget.

De fem ting, der gør sider langsomme

1. Billeder, der er for store

Den hyppigste årsag, og den letteste at rette. Et billede fra en telefon er 3–5 MB og 4.000 pixels bredt; på siden vises det i 800 pixels. Skaleres det ikke ned og gemmes som WebP, henter hver besøgende ti gange mere, end de ser. Rettelsen: Skær billeder til den størrelse, de vises i, gem dem som WebP, og lad siden loade dem, der er længere nede, først når man scroller dertil (lazy loading). Det alene kan halvere loadtiden. Se image SEO.

Heroen og billederne længere nede skal hentes forskelligt:

<!-- Hero: hentes med det samme og med høj prioritet -->
<img src="/billeder/hero-1200.webp"
     srcset="/billeder/hero-800.webp 800w, /billeder/hero-1200.webp 1200w, /billeder/hero-1600.webp 1600w"
     sizes="100vw" width="1600" height="900"
     alt="Tømrer lægger nyt tag på parcelhus i Risskov" fetchpriority="high">

<!-- Billeder under folden: lazy loading og faste mål -->
<img src="/billeder/projekt-800.webp" width="800" height="600"
     alt="Færdigt badeværelse med klinker" loading="lazy" decoding="async">

Heroen må aldrig have loading="lazy". Det er en af de hyppigste grunde til dårlig LCP. Brug til gengæld kun fetchpriority="high" på et enkelt eller to billeder; sættes det på alle, hjælper det ikke.

2. For meget kode fra page buildere og plugins

Hver page builder, hvert plugin og hvert tema lægger sin egen CSS og JavaScript på siden, uanset om siden bruger det. En WordPress-side med Elementor og 25 plugins loader ofte over 1 MB kode, før jeres eget indhold er med. Rettelsen er sværere, fordi den sidder i, hvordan siden er bygget: Fjern plugins, I ikke bruger, vælg et letvægtstema, og overvej, om siden skal bygges om, når den alligevel skal have nyt design. Se Elementor eller kodet tema.

3. Langsom server

Hvis serveren bruger 800 millisekunder på at begynde at svare, kan intet på siden indhente det. Det er billig delt hosting, en server langt væk eller en side uden caching, hvor hver visning bygges forfra. Rettelsen: caching, og en hosting med svartid under 200 millisekunder i Danmark eller EU. Se hosting.

4. Scripts fra andre

Chatwidgets, cookiebannere, annoncepixels, indlejrede videoer, fonte fra Google, kort, anmeldelseswidgets. Hver af dem henter kode fra en anden server og kører den, før eller mens siden vises, og de er den hyppigste årsag til dårlig INP. Rettelsen: Fjern dem, I ikke bruger, load resten, når de skal bruges (videoen, når man klikker; chatten, efter siden er vist), og host fonte selv.

Fonte, I selv hoster, hentes tidligt og vises med det samme:

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
<style>
  @font-face {
    font-family: "Inter";
    src: url("/fonts/inter-var.woff2") format("woff2");
    font-weight: 100 900;
    font-display: swap;
  }
</style>

En video, der først hentes, når nogen klikker:

<button class="video" data-id="VIDEO_ID" aria-label="Afspil video">
  <img src="/billeder/video-forside.webp" width="1280" height="720" alt="" loading="lazy">
</button>
<script>
  document.querySelectorAll('.video').forEach(b => b.addEventListener('click', () => {
    b.outerHTML = `<iframe width="1280" height="720" title="Video" allow="autoplay; encrypted-media" allowfullscreen
      src="https://www.youtube-nocookie.com/embed/${b.dataset.id}?autoplay=1"></iframe>`;
  }));
</script>

5. Ting, der flytter sig

Billeder uden angivet størrelse, bannere, der skubber indholdet ned, fonte, der skifter, når de er hentet. Det er CLS, og det irriterer mere, end det forsinker: Man trykker på et link, og siden flytter sig, så man rammer noget andet. Rettelsen: Giv alle billeder og indlejringer en fast størrelse, og reservér plads til det, der kommer senere.

Reservér pladsen, før indholdet er hentet:

.cookie-bjaelke { min-height: 56px; }      /* plads til bjælken, før den er hentet */
.kort-indlejring { aspect-ratio: 16 / 9; } /* kort og videoer får deres plads fra start */

Hvad I selv kan gøre i dag

1. Kør siden gennem hastighedstesten, og notér LCP, INP og CLS for mobil. Det er jeres udgangspunkt.
2. Find de fem tungeste billeder på forsiden og ydelsessiderne, og udskift dem med WebP i rigtig størrelse. Et plugin kan gøre det for hele siden.
3. Slå caching til, hvis det ikke er gjort. Hos de fleste udbydere er det en knap i kontrolpanelet, eller et plugin.
4. Gennemgå plugins og scripts: Hvad bruger I faktisk? Slet resten.
5. Kør testen igen. Er LCP stadig over 2,5 sekunder på mobil, sidder problemet i hosting eller bygning, og så er det tid til at tale med nogen.

Hvad det koster

De første fire punkter er en dags arbejde og koster typisk 3.000–10.000 kr., hvis I køber dem. Det løser hastighedsproblemet for omkring halvdelen af de sider, vi ser. Den anden halvdel er bygget sådan, at det ikke rækker, og der er løsningen et nyt tema eller en ny side, bygget let fra starten. Det hører til i overvejelserne om redesign, og det er grunden til, at hastighed skal være et krav, når I bestiller en ny side, ikke noget, der rettes bagefter.

Tjekliste

1. LCP højst 2,5 s, INP højst 200 ms, CLS højst 0,1, for mobil.
2. Alle billeder i WebP, skåret til visningsstørrelsen, lazy-loaded under folden.
3. Caching slået til, server med svartid under 200 ms.
4. Kun de plugins og scripts, I bruger; resten slettet.
5. Fonte hostet selv; videoer og kort loader ved klik.
6. Faste størrelser på billeder og indlejringer.
7. Testet igen efter rettelser, og fulgt i Search Console.

Hastighed er en del af, hvad vi mener med en side, der er bygget rigtigt, og det er derfor, hvert tilbud fra os indeholder det. Se webudvikling. Det tekniske fundament under det hele står under teknisk SEO. Vil I have siden gjort hurtigere, er det det, vi laver under hastighedsoptimering.

Kilder

• Google, Web Vitals (grænseværdier for LCP, INP og CLS og 75. percentil), web.dev.
• Google, Optimize Largest Contentful Paint, web.dev.
• Google, Understanding page experience in Google Search results, Google Search Central.
• Google, Milliseconds make millions (Deloitte og 55 for Google, 2020), web.dev.