Web performance
Når en bruger klikker på jeres link i Google, har I omkring 2-3 sekunder før hovedparten begynder at klikke tilbage. Det er ikke en holdning — det er hvordan browsere, mobiler og tålmodighed virker i 2026. Et langsomt website koster jer altså to ting på samme tid: brugerne der aldrig når at se det, og placeringen i søgeresultaterne der aldrig får dem dertil.
Det her er en kort, brugbar guide til hvorfor sidehastighed reelt påvirker Google-rangering, hvad der typisk gør sider langsomme, og hvordan I selv kan måle det inden I bruger en krone på at gøre noget ved det.
TL;DR
De vigtigste pointer
- Google bruger Core Web Vitals (LCP, INP, CLS) som direkte rangsignaler — ikke som en bonus, men som en del af page experience-vurderingen.
- Hastighed påvirker bouncerate, konvertering og crawl-budget. Det er den samme investering der trækker tre vigtige greb på én gang.
- Mobil er målestokken. Google vurderer Core Web Vitals fra rigtige besøg på mobiler med almindelig 4G — ikke fra jeres MacBook på fiber.
- De typiske syndere er forudsigelige: tunge billeder, ubrugt JavaScript, blokerende tredjeparts-scripts, og sider der bygges hver gang nogen besøger dem.
- I kan selv teste på under et minut med PageSpeed Insights. Mål før I optimerer — ellers ender I med at gætte på det forkerte.
Hvorfor hastighed reelt rangerer jer på Google
Google siger det selv åbent siden 2021: Core Web Vitals er en del af deres page experience-rangsignaler. Det er tre konkrete tal, alle målt fra rigtige brugeres besøg på jeres site (det de kalder field data fra Chrome User Experience Report). Largest Contentful Paint (LCP) måler hvor hurtigt det største synlige element rendrer — i praksis: hvor hurtigt brugeren føler at siden er der. Interaction to Next Paint (INP) måler hvor responsivt siden reagerer når man rør den. Cumulative Layout Shift (CLS) måler om indholdet hopper omkring under load — det irriterende fænomen hvor en knap flytter sig lige før du klikker.
Google rangerer ikke alene på hastighed — relevans, links og indhold er stadig de tunge faktorer. Men når to sider svarer lige godt på samme søgning, vælger Google den der giver brugeren den bedste oplevelse. Og hastighed er den mest målbare del af den oplevelse. Det er også den del Google nemmest kan måle objektivt på tværs af milliarder af besøg.
Lige så vigtigt: hastighed påvirker hvor meget af jeres site Google overhovedet crawler. Crawl-budgettet — hvor mange sider Googlebot besøger i en given periode — bliver mindre når serveren er langsom. Et lille marketing-site mærker det knap, men et e-commerce site med tusindvis af produkter eller en knowledge base med mange artikler kan reelt få indekseret færre sider hvis sitet er sløvt.
Hastighed er også konvertering — ikke kun ranking
Selvom Google ikke rangerede på hastighed overhovedet, ville det stadig være den hurtigste vej til bedre tal i jeres analytics. Hvert sekund ekstra på loadtid koster brugere — det er konsistent på tværs af alle store studier, og det rammer mobil hårdest, fordi de fleste mobilbesøg sker uden tid og uden tålmodighed.
Det handler ikke kun om bouncerate. På et website hvor brugere skal udfylde en formular, downloade en hvidbog, eller klikke videre i en købsflow, så reducerer langsomme transitioner antallet af mennesker der overhovedet kommer videre. En langsom side er en utæthed der løber gennem hele tragten — og den er fuldstændig synlig for de brugere der oplever den.
Det her er den uerkendte fordel ved at investere i hastighed: I optimerer SEO og konvertering med samme arbejde. Det er sjældent at en teknisk investering rammer to KPI'er på én gang så cleant.
Et hurtigt vs. et langsomt website — i praksis
Hurtigt website
LCP under 2,5s, INP under 200ms, CLS under 0,1 på mobil.
- Side bliver brugbar inden brugeren har fattet at den loader
- Page experience-signal trækker rankingen i positiv retning
- Crawl-budget bliver brugt på indhold, ikke på at vente
- Konvertering er højere fordi flow ikke afbrydes af venten
- Mobile besøg konverterer på linje med desktop
- Mindre infrastruktur til at bære det samme antal besøg
Langsomt website
LCP over 4s, mærkbar lag på interaktion, layout shifts.
- Brugeren ser blank skærm eller halvt-loaded indhold for længe
- Google nedprioriterer page experience i konkurrence-søgninger
- Færre sider indekseret når sitet er stort
- Konvertering falder med hvert sekund af loadtid
- Mobil-trafik bouncer markant hårdere end desktop
- Reklamekroner kanaliserer trafik ind i en utæt tragt
Det der typisk gør et website langsomt
I 9 ud af 10 tilfælde er det de samme syndere. Mange af dem kan løses uden at skifte platform.
- 01
Billeder der vejer for meget
Den absolut hyppigste årsag. Et hero-billede på 2 MB i fuld opløsning, leveret i JPG eller PNG i stedet for AVIF/WebP, uden bredde-/højde-attributter og uden lazy-loading af billeder under fold. Bare det at servere billeder i moderne formater og rigtig størrelse halverer ofte LCP.
- 02
JavaScript I ikke har brug for
WordPress-temaer, page builders og analytics-snippets der laster jQuery, animations-libs og syv tredjeparts-scripts før indholdet overhovedet kan rendre. Hvert KB JavaScript er en lille skat på CPU'en — og mobilens CPU er den langsomste del af hele kæden.
- 03
Tredjeparts-scripts der blokerer rendering
Chat-widgets, A/B-test-værktøjer, cookie-bannere og marketing-pixels der hentes synkront. Selv et hurtigt website bliver langsomt hvis det venter på en sløv tredjepartsserver i Boston før det må vise tekst i Aarhus.
- 04
Sider der bygges fra bunden ved hvert besøg
Klassisk WordPress eller en Node-app uden caching skal bygge HTML på serveren for hvert eneste request. Det betyder venten på database, plugins og rendering. Statisk HTML på et CDN serveres på under 50ms — fra Danmark og fra Australien.
- 05
Hosting der står langt væk fra brugerne
En server i Tyskland er ikke langt fra Danmark — men den er langt nok. Et CDN (Content Delivery Network) som Cloudflare placerer indholdet tæt på brugeren og fjerner sekunder af ventetid på første request. For et globalt site er det ikke en luksus, det er en grundvilkår.
Hurtige greb der typisk flytter Core Web Vitals
Ikke en udtømmende liste — men de greb vi tager først, fordi de typisk har det bedste forhold mellem indsats og effekt.
- Konverter alle hero- og above-the-fold-billeder til AVIF eller WebP, og specificér bredde og højde i HTML.
- Lazy-load alle billeder der ligger under fold med loading="lazy".
- Defer eller fjern tredjeparts-scripts der ikke er kritiske for første render — chat, analytics, A/B-test.
- Skift til statisk eller pre-renderet HTML hvor sider ikke ændrer sig per bruger (next build, ISR, eller en static site generator).
- Sæt et CDN foran sitet — Cloudflare, Fastly eller Vercel's edge — og caching-headers på alt der ikke er personligt.
- Vis en stabil layout fra første render: brug skeleton-loaders eller faste dimensioner, så CLS ikke springer når billeder dukker op.
- Auditér jeres font-loading: brug font-display: swap, preload kun den vægt I bruger above-the-fold, og overvej variable fonts.
Spørgsmål vi får igen og igen
Hvor stor er rankingen-effekten af Core Web Vitals reelt?
Ikke gigantisk i isolation, men reel. Google har beskrevet det som en "tiebreaker" — når andre signaler er sammenlignelige, vinder den hurtigere side. I konkurrence-søgninger hvor jeres relevans og links er på linje med konkurrenternes, kan det være forskellen mellem position 3 og position 7. Og fordi det også påvirker konvertering, er ROI på et hastighedsfix typisk solidt selv hvis Google ikke rangerede på det.
Vores site er bygget på WordPress. Kan vi gøre noget uden at skifte platform?
Ja, en del. Caching-plugins (WP Rocket, FlyingPress), et CDN foran (Cloudflare), billed-optimering (Imagify, ShortPixel) og at fjerne tunge plugins løser ofte 60-70% af problemet. Men hvis I kører en page builder med tunge templates og mange plugins, og I planlægger at skalere indhold eller trafik, så er det værd at overveje en mere moderne stack. Vi har et separat indlæg på vej om hvornår WordPress bliver den forkerte løsning.
Vi har en SPA (React/Vue) — er den automatisk hurtig?
Nej. En klassisk client-side SPA er ofte langsommere på første load fordi browseren skal hente, parse og eksekvere store JavaScript-bundles før den kan vise noget. Det giver dårlig LCP og dårlig SEO. Løsningen er server-side rendering eller static generation — Next.js, Remix, Nuxt — så den første HTML er der med det samme, og JavaScript hydrerer bagefter.
Hvor ofte skal vi monitorere Core Web Vitals?
Sæt det op én gang og lad det køre. Google Search Console har en gratis Core Web Vitals-rapport der viser jeres faktiske field data over tid og fortæller når noget regresserer. Det er det vigtigste værktøj — vigtigere end at køre PageSpeed Insights manuelt — fordi det viser hvad jeres rigtige brugere oplever, ikke hvad et lab-værktøj måler under ideelle forhold.
Hvor hurtigt er flaretech.dk?
Det kan I selv teste på pagespeed.web.dev — det er hele pointen ved at have en åben benchmark. Sitet er bygget på Next.js på edge med statisk HTML, billeder i AVIF, og minimalt JavaScript above-the-fold. Vi sigter efter grøn på alle tre Core Web Vitals (LCP, INP, CLS) på både mobil og desktop. Hvis I kører testen og finder noget vi kan gøre bedre, så hør gerne fra jer.
Hvis I står med et langsomt site
Vi laver gerne en hurtig audit — uden salgstaler.
Send os jeres URL og vi vender tilbage med en konkret liste af de største vindere. I får en uforpligtende vurdering, ikke et tilbud — og I kan bruge listen selv hvis I vil løse det in-house.