Startup performance — Hurtig app-start og time to interactive
Startup performance er kritisk: de første sekunder afgør brugerens første indtryk og påvirker bounce rate. JavaScript-parsing og tung initialisering er de hyppigste årsager til langsom start.
Startup performance dækker alt der sker fra brugeren klikker på et link til siden er fuldt interaktiv — First Contentful Paint, Largest Contentful Paint og Time to Interactive er de centrale milepæle. Det er den performance-periode der har størst indflydelse på bounce rate og første brugerindtryk, og den hyppigste årsag til dårlig startup er tung JavaScript der skal downloades, parses og eksekveres inden siden reagerer. Code splitting, udskudte tredjepartsscripts og korrekt prioritering af kritiske ressourcer er de primære tekniske indsatser der forbedrer startup performance konkret og målbart.
Hvad måles i startup
First Contentful Paint (FCP) — hvornår browseren maler det første synlige indhold. Brugeren ser at noget sker.
Largest Contentful Paint (LCP) — hvornår sidens primære indhold er synligt. Brugeren ser siden “klar”.
Time to Interactive (TTI) — hvornår siden er fuldt interaktiv. Ingen long tasks, alle handlers registreret.
Total Blocking Time (TBT) — samlet tid main thread er blokeret (long tasks over 50ms) mellem FCP og TTI. Høj TBT betyder brugeren ser en tilsyneladende klar side der ikke reagerer.
JavaScript er den primære synder
JavaScript har en unik performance-omkostning: browser skal downloade, parse, kompilere og eksekvere det — alt på main thread. Et 500 KB JavaScript-bundle kan tage 2-5 sekunder at processere på en middel Android-telefon.
Strategier:
Code splitting — del JavaScript op i chunks der kun loades når de bruges. I React/Next.js: React.lazy() og dynamiske imports. Brugere på forsiden downloader ikke kode til checkout-flowet.
Tree shaking — fjern ubrugt kode fra bundlet. Moderne bundlers (Webpack, Rollup, Vite) gør dette automatisk hvis ESM-imports bruges korrekt.
Defer og async — scripts med defer downloades parallelt men eksekveres efter DOM er bygget. Scripts med async eksekveres straks de er downloadet. Begge blokerer ikke HTML-parsing.
<!-- Blokerer rendering — undgå i <head> -->
<script src="analytics.js"></script>
<!-- Eksekveres efter DOM er klar -->
<script src="app.js" defer></script>Tredjeparts-scripts
Analytics, chat-widgets, A/B test-scripts og annoncer loades typisk fra tredjeparter og har ingen performance-garantier. De er en hyppig årsag til dårlig startup performance fordi:
- De indlæses synkront og blokerer rendering
- De initialiserer tidligt og belaster main thread
- De henter yderligere ressourcer (billeder, fonts, scripts)
Strategi: Udskyd tredjeparts-scripts til efter load-event — eller brug facade patterns der først initialiserer et script ved brugerinteraktion (klik på chat-widget aktiverer chat-scriptet).
Optimér hvad browseren ser først
Above-the-fold prioritering: Kritisk CSS inlines i <head> så over-fold indhold renderes straks uden at vente på CSS-filen. Alt under fold kan loades asynkront.
LCP-billede med fetchpriority: Fortæl browseren at LCP-billedet er kritisk:
<img src="hero.webp" fetchpriority="high" alt="Hero" width="1200" height="600">Font-optimering: Web fonts der loades sent skubber tekst (FOUT — Flash of Unstyled Text). font-display: swap viser fallback-font mens web fonten hentes, og skifter når den er klar.
Mål med Lighthouse
Lighthouse i Chrome DevTools rapporterer FCP, LCP, TBT og TTI under Performance-auditen. Opportunities og Diagnostics sektionerne giver specifikke forbedringsforslag rangeret efter estimeret gevinst.
→ 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
- Performance timings — Hvornår er det for langsomt?
- 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
- 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 Time to Interactive (TTI)?
- Time to Interactive er det tidspunkt hvor siden er visuelt klar OG responderer hurtigt på brugerinteraktion — ingen long tasks kører, og siden har registreret nødvendige event handlers. TTI er ikke en Core Web Vitals-metric men bruges stadig som diagnostisk metric. INP har delvist erstattet TTI som mål for interaktionsresponsivitet.
- Hvad er de primære årsager til dårlig startup performance?
- For meget JavaScript — download, parsing, kompilering og eksekvering blokerer main thread. Render-blocking ressourcer der forsinker første visning. Tunge tredjepartsscripts (analytics, chat, ads) der initialiseres ved load. Synkrone API-kald der blokerer rendering. Og mangel på code splitting der sender al JavaScript til alle sider.
- Hvad er Total Blocking Time (TBT) og hvorfor er det en SEO-metric?
- Total Blocking Time er den samlede tid main thread er blokeret med long tasks (opgaver over 50ms) i perioden mellem First Contentful Paint og Time to Interactive. Høj TBT resulterer i en side der ser færdig ud men ikke reagerer på klik — en frustrerende brugeroplevelse. TBT er en stærk korrelat til INP (Interaction to Next Paint), der er en Core Web Vitals-rankingfaktor. Reducer TBT ved at splitte lange tasks og udskyde tredjepartsscripts.
- Hvad er code splitting og hvornår er det nødvendigt?
- Code splitting er teknikken der deler JavaScript-bundlen i mindre chunks der kun loades når de er nødvendige — fx ved navigation til en specifik side eller ved en bestemt brugerinteraktion. I React og Next.js bruges React.lazy() og dynamiske imports. Det er nødvendigt når JavaScript-bundlen overstiger ca. 150 KB parsed — over det punkt stiger Time to Interactive markant på mobile enheder. Vite, Webpack og Rollup understøtter code splitting automatisk.
- Hvornår bør man bruge façade patterns for tredjepartsscripts?
- Façade patterns er relevante for tunge tredjepartsscripts der ikke er nødvendige ved sideload: chat-widgets, video-embeds (YouTube/Vimeo) og sociale medie-embeds. En façade viser en placeholder-version (fx et thumbnail af en video) og indlæser det rigtige script først ved brugerinteraktion (klik). Det reducerer JavaScript-payload ved startup markant. YouTube-facader kan reducere sideindlæsningstiden med 1-3 sekunder på mobile enheder med middelgod forbindelse.
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
- Performance timings — Hvornår er det for langsomt?
- 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
- 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