Performance timings — Hvornår er det for langsomt?
Google anbefaler: LCP under 2,5s, INP under 200ms, CLS under 0,1. Generelle tommelfingerregler: indlæsning under 1s, idle tasks under 50ms, animationer 16,7ms per frame.
Performance timings er de kvantitative grænser der definerer hvad der er hurtig nok web performance. Der er ingen universel definition af “for langsomt” — men der er et veldokumenteret sæt tærskler baseret på brugeradfærd, psykologi og Googles Core Web Vitals-framework. Disse grænser er direkte SEO-relevante fordi Google bruger Core Web Vitals som en bevist rankingfaktor — sider der ikke opfylder tærskler risikerer ranking-straf på mobilsøgninger.
Core Web Vitals — Googles officielle tærskler
| Metric | God | Skal forbedres | Dårlig |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2,5s | 2,5–4,0s | > 4,0s |
| INP (Interaction to Next Paint) | ≤ 200ms | 200–500ms | > 500ms |
| CLS (Cumulative Layout Shift) | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Disse tærskler måles på 75. percentil af field data — det vil sige at 75% af en sides besøg skal nå “god”-niveauet.
Generelle performance-tommelfingerregler
Ud over Core Web Vitals er der etablerede tommelfingerregler for hvornår brugere mærker forsinkelse:
100 millisekunder — øjeblikkelig. Brugeren oplever ingen forsinkelse. Dette er målsætningen for interaktiv respons (INP er mere lempelig, men under 100ms er ideelt).
1 sekund — notice. Brugeren bemærker forsinkelsen men bibeholder tankestrømmen. Under 1 sekund er målet for initial sideindlæsning.
10 sekunder — abandon. Brugeren mister fokus og afbryder typisk handlingen. Over 10 sekunder er praktisk talt alle brugere tabt.
16,7 millisekunder per frame — animationer. 60 fps kræver at browseren renderer et nyt frame hvert 16,7ms. Over denne grænse opstår jank.
50 millisekunder — long task. RAIL-modellen definerer tasks over 50ms som “long tasks” der potentielt forringer responsivitet.
TTFB-grænser
Time to First Byte (TTFB) er ikke en Core Web Vitals-metric men er tæt relateret til LCP:
- Under 200ms — fremragende
- 200–500ms — acceptabelt
- Over 800ms — problematisk og vil næsten altid resultere i dårlig LCP
FCP som brugerforventnings-anker
First Contentful Paint er det tidspunkt brugeren ser at “noget sker”. Selv om FCP ikke er en direkte rankingfaktor, er den kritisk for opfattet performance:
- Under 1,8s — god
- 1,8–3,0s — skal forbedres
- Over 3,0s — dårlig
Sider med langsom FCP har markant højere bounce rate selv hvis den endelige LCP er hurtig — brugeren ser en tom side og navigerer væk.
Total Blocking Time (TBT)
TBT er et lab-metric der korrelerer med INP:
- Under 150ms — god
- 150–350ms — skal forbedres
- Over 350ms — dårlig
Kontekst-justering
Disse tærskler er baseret på gennemsnitlige brugeroplevelser. Justér dine mål baseret på din brugergruppe:
- E-commerce: hvert 100ms ekstra har direkte konverteringsimpact — vær mere aggressiv end minimumsgrænser
- B2B SaaS med primært desktop-brug: mobilgrænser er mindre kritiske, men desktop-performance skal stadig holdes
- Globalt site: test fra relevante geografier — TTFB fra Asien til europæisk server kan alene koste 300-500ms → Denne artikel er en del af Web Performance — Core Web Vitals og teknisk hastighed.
Andre artikler i samme emne
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- Browser rendering pipeline — Fra HTML til pixels
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- CSS containment — Isolér rendering og accelerér layout
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- Responsivt design — Mobile-first og SEO
- RUM vs. syntetisk monitoring — To syn på web performance
- Service Workers — Offline caching og PWA performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- TTFB og hosting — Server response time og SEO
- Video performance — Lazy loading, formater og indlæsningsstrategi
- Viewport tag — Meta viewport og mobil-rendering
- Web Workers — Parallel JavaScript uden main thread-blokning
Ofte stillede spørgsmål
- Hvad er Googles anbefalede grænser for Core Web Vitals?
- God: LCP under 2,5 sekunder, INP under 200 millisekunder, CLS under 0,1. Disse tærskler er baseret på 75. percentil-data fra CrUX. At nå 'god' på alle tre på mobildata er minimumsstandarden for at undgå performance-relaterede ranking-sanktioner.
- Hvornår begynder brugere at bouncer pga. hastighed?
- Research fra Google viser at bounce rate stiger markant ved indlæsningstider over 3 sekunder på mobil. 53% af mobilbesøg afbrydes hvis siden tager mere end 3 sekunder at loade. Hvert ekstra sekund forsinkelse resulterer i typisk 7% konverteringsrate-reduktion ifølge Akamai-studier.
- Er LCP-grænsen på 2,5 sekunder den samme for desktop og mobil?
- Googles Core Web Vitals-tærskler er de samme for desktop og mobil, men CrUX-data segmenteres per enhedstype. Din mobilscore og desktop-score vises separat i Google Search Console. Mobilscores er typisk sværere at opfylde fordi netværkshastighed og CPU er lavere på gennemsnitlige mobilenheder. Google bruger mobildata som den primære signal under mobile-first indexing.
- Hvad er sammenhængen mellem TTFB og LCP?
- TTFB er den første komponent i LCP. Høj TTFB = højt minimum for LCP, uanset hvor optimerede øvrige ressourcer er. Google anbefaler TTFB under 800ms for at nå 'god' LCP. En server der bruger 1 sekund på at svare kan i praksis aldrig opnå LCP under 2,5 sekunder, fordi LCP-billedet ikke kan begynde at downloade før HTML-dokumentet er modtaget.
- Hvilke performance-tærskler er vigtigst for SEO-ranking specifikt?
- Core Web Vitals er de eneste performance-metrics Google har bekræftet som rankingfaktorer: LCP, INP og CLS målt på 75. percentil i CrUX-data. TTFB og FCP er ikke direkte rankingfaktorer men påvirker LCP indirekte. Prioritér altid Core Web Vitals-tærsklerne ('god'-niveau) som minimumsmål — andre performance-metrics er vigtige for brugeroplevelsen men ikke for algoritmisk ranking i Googles søgeresultater.
Placering i ordbogen
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- Browser rendering pipeline — Fra HTML til pixels
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- CSS containment — Isolér rendering og accelerér layout
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- Responsivt design — Mobile-first og SEO
- RUM vs. syntetisk monitoring — To syn på web performance
- Service Workers — Offline caching og PWA performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- TTFB og hosting — Server response time og SEO
- Video performance — Lazy loading, formater og indlæsningsstrategi
- Viewport tag — Meta viewport og mobil-rendering
- Web Workers — Parallel JavaScript uden main thread-blokning