FCP

Kort fortalt: FCP (First Contentful Paint) er tidspunktet hvor browseren første gang viser noget “rigtigt” indhold (tekst, billede, SVG, canvas) på skærmen.

Hvad måler det?

• Hvornår browseren viser det første tekst/billede/svg/canvas fra DOM.

FCP fortæller ikke om siden er “færdig” eller interaktiv. Den fortæller bare om brugeren ser noget, der bryder følelsen af en tom side.

Hvad er en “god” FCP?

Der findes ikke én universel grænse, fordi FCP er en lab-måling og afhænger af testmiljø. Men som tommelfingerregel på content-sites:

• hvis FCP er meget langsom, er der ofte et tydeligt render-blocking eller TTFB-problem
• hvis FCP er hurtig, men LCP er dårlig, er problemet ofte hero-billede, CSS discovery eller prioritering

Det vigtige er ikke at optimere “for tallet”, men at bruge FCP til at se om brugeren får visuel feedback tidligt.

Hvilken indflydelse har FCP?

FCP påvirker oplevet hastighed:

• Hvis FCP er hurtig, føles siden ofte “i gang”.
• Hvis FCP er langsom, føler brugeren at intet sker, selv hvis LCP senere bliver god.

På content-sites kan FCP være vigtig fordi:

• brugeren forventer at se tekst tidligt
• man ofte har store CSS bundles eller render-blocking der kan skubbe første paint

Hvornår blev FCP relevant?

FCP blev udbredt som en mere meningsfuld måling end gamle “onload”-målinger, fordi den fokuserer på den første visuelle feedback. Senere kom Core Web Vitals med LCP/INP/CLS, men FCP er stadig nyttig i diagnosticering, især når du vil forstå render-blocking og tidlig rendering.

Hvad FCP ikke fortæller dig (vigtige begrænsninger)

FCP er et tidligt signal, men det kan være “misvisende” hvis du bruger det alene:

• FCP kan være hurtig, selvom siden stadig er tung og uinteraktiv (dårlig INP)
• FCP kan være hurtig med en lille tekst, selvom LCP er dårlig (hero-billede loader sent)
• FCP kan være ok i lab, men dårligere i virkeligheden hvis TTFB varierer over dagen

Derfor giver det bedst mening at bruge FCP sammen med:

• LCP (hvad blev det vigtigste?)
• INP (føles siden responsiv ved klik?)
• CLS (hopper layout?)
• waterfall (hvad blokerer?)

Typiske årsager til høj FCP

• Render-blocking CSS/JS
• Lang TTFB
• Tunge fonts/billeder i toppen

Typiske forbedringer

• Fjern/udskyd render-blocking ressourcer
• Brug critical CSS og preload af relevante assets

Konkrete optimeringer (praktisk)

1) Reducér render-blocking

• split CSS (critical + resten)
• brug defer på ikke-kritisk JavaScript
• fjern unused CSS/JS

2) Forbedr TTFB

Hvis HTML kommer sent, kommer alt sent. Brug caching/edge hvor det er muligt.

3) Fonts: vis tekst tidligt

• font-display: swap
• begræns fontfiler og weights
• preload kun det der er kritisk

4) Sørg for at “above the fold” er simpelt

Hvis første viewport er tung (store baggrunde, komplekse layout, mange scripts), bliver første paint ofte senere.

Et praktisk “FCP-first” debug-flow

Hvis du vil debugge hurtigt, kan du bruge denne rækkefølge:

1. Kig på TTFB: kommer HTML sent?
2. Kig på render-blocking: ligger der stor CSS/JS i head?
3. Kig på fonts: bliver tekst først synlig sent?
4. Kig på main thread: kører der store scripts før første paint?

FCP-problemer er ofte ikke “mystiske” – de er typisk en konsekvens af at browseren må vente på noget.

Sådan måler du FCP

• Lighthouse/PageSpeed Insights
• WebPageTest (video + timings)
• DevTools Performance (se paints og hvad der blokerer)