First Contentful Paint

Hvad er First Contentful Paint (FCP)?

First Contentful Paint (FCP) er en måde at måle sideindlæsningshastighed på. Du kan ikke opsummere sidehastighed som et tidspunkt, der er faktisk flere øjeblikke under indlæsningsprocessen, hvor en besøgende kan opleve siden som hurtig eller langsom. FCP måler tidsforskellen fra anmodningen om siden til det første meningsfulde indhold renderes på skærmen for første gang.

Hvad fortæller det dig egentlig? Det fortæller dig, at FCP primært er en "brugercentreret metrik", fordi den siger noget om den indlæsningshastighed, en besøgende oplever. Den siger noget om user experience. På FCP-tidspunktet kan du være sikker på, at en besøgende faktisk ser "noget" på skærmen.

Lad os opdele ordene: 'First','Contentful' og 'Paint'.

1. First:  Med First mener vi selvfølgelig det første præcise øjeblik, hvor noget væsentligt vises i din browser.
2. Contentful: Med contentful mener vi et HTML-element med indhold. Altså ikke et layoutelement som et tomt element eller baggrundsfarve, men snarere noget tekst, et billede (inklusive baggrundsbillede), SVG eller canvas.
   
3. Paint: Paint betyder (mere eller mindre), at browseren er klar til at sætte noget på skærmen. Det lyder simpelt, men det er faktisk browserens mest komplicerede opgave. For at sætte noget på skærmen skal en browser være klar til at beregne alle egenskaber ved et element. Nedenfor er et eksempel på renderingsprocessen, der er nødvendig, før noget kan tilføjes på skærmen.

Hvad er en god First Contentful Paint score?

En god FCP-score er alt under 0 og 1,8 sekunder. Hvis din FCP-score er mellem 1,8 og 3 sekunder, kræver den forbedring. Enhver FCP-score over 3 sekunder betragtes som dårlig. For at bestå Core Web Vitals for Largest Contentful Paint skal mindst 75% af dine besøgende have en 'god' FCP-score.

Som altid med Core Web Vitals er en hurtigere First Contentful Paint score bedre end en langsommere. 

Hvordan måler du din First Contentful Paint (FCP)?

FCP måles af Google ved at indsamle data fra rigtige brugere. Disse data gemmes i CrUX-datasættet. Disse data er offentligt tilgængelige via CrUX API eller Google BigQuery. FCP kan også måles gennem såkaldte lab-tests. Den mest almindelige lab-test hedder Lighthouse.

Hent First Contentful Paint fra CrUX-datasættet

First Contentful Paint kan aflæses fra CrUX-datasættet via pagespeed.web.dev, CrUX API eller gennem Google BigQuery.

Måling af First Contentful Paint gennem Real User Monitoring (RUM) 

RUM Tracking står for Real User Monitoring. Med Real User Monitoring kan du spore First Contentful Paint gennem rigtige brugerinteraktioner. Fordelen ved RUM Tracking er, at du ikke behøver at vente 28 dage på friske data, og dataene kan forespørges og analyseres i langt større detalje.

Måling af FCP i Lighthouse

1. Åbn siden – i Chrome – hvis FCP du vil måle. Sørg for at gøre dette i inkognito, så plugins ikke forstyrrer dig og muligvis bremser FCP på din side.
2. Højreklik på siden og vælg Undersøg element. På denne måde åbner du Chrome-udviklerkonsollen.
3. Øverst i konsollen ser du fanen Lighthouse. Klik på den. Vælg derefter Performance under Kategorier (lad andre være tomme) og vælg Mobile under Enhed.
4. Klik nu på Generer rapport. Lighthouse opretter en hastighedsrapport for din side. I øverste venstre hjørne af rapporten kan du se, hvad FCP for din side er.

Dette er et skærmbillede af Lighthouse-rapporten for denne side. FCP for denne side på en mobilenhed er 0,8 sekunder! Ikke dårligt, vel?

Måling af FCP med et onlineværktøj

Du kan også måle FCP med en række onlineværktøjer. De mest kendte er GTMetrix, pingdom og pagespeed.web.dev. Disse værktøjer er nemme at arbejde med og giver nogle data om LCP under specifikke lab-omstændigheder.

Forbedring af First Contentful Paint

Nu hvor du ved, hvad First Contentful Paint er, kan vi gå i gang med at gøre den hurtigere. Idéen bag en hurtig FCP er faktisk ret simpel: sørg for, at en browser kan begynde at rendere med det samme. Alt, der kan forsinke renderingen, vil resultere i en dårlig FCP-score.

Ligesom med Largest Contentful Paint kan First Contentful Paint opdeles i 2 eller 4 kategorier:

1. Time to First Byte (TTFB) - Tiden fra siden begynder at indlæse, til browseren modtager den første byte af HTML. 
2. Ressource-indlæsningsforsinkelse - Tiden mellem TTFB og det tidspunkt, hvor browseren begynder at indlæse FCP-ressourcen
   
3. Ressource-indlæsningstid - Den tid det tager at indlæse selve FCP-ressourcen.
   
4. Element-renderingsforsinkelse - Tiden mellem FCP-ressourcen er færdig med at indlæse, og LCP-elementet er fuldt renderet
   

Hastighedstip: Du kan nemt eliminere trin 2 & 3 ved at sikre, at LCP-elementet ikke kræver en netværksressource. I tilfælde af et tekstelement, overvej at bruge font-display:swap. I tilfælde af et lille billedelement, overvej at placere billedet inline.

Det efterlader os med Time to First Byte og Element-renderingsforsinkelsen at optimere.

Nedenfor er 14 løsninger, jeg ofte bruger til at forbedre FCP. Men vær forsigtig, brug af en løsning på det forkerte sted kan faktisk skabe forsinkelser. Derfor er det bedst at konsultere en pagespeed-ekspert, før du begynder selv.

1. Hurtig serverrespons (TTFB)

TTFB (tiden mellem anmodningen og den første byte, serveren sender) er altid det første trin i renderingsprocessen. Fra det tidspunkt begynder din browser at multitaske, og effekten af yderligere optimeringer begynder at falde. HTML-koden er den eneste anmodning, der direkte påvirker alle hastighedsmetrikker.

Hastigheden, hvormed HTML-koden sendes fra serveren, måles ofte som Time to First Byte (TTFB). Det er vigtigt at gøre dette så hurtigt som muligt. Ofte gør du dette ved at aktivere server-side caching.

Når det kommer til Time to First Byte, er lavere altid bedre. 

Du kan nemt måle Time to First Byte selv. Det gøres som følger:

1. Brug genvejen Ctrl-Shift-I til at åbne udviklerkonsollen i Google Chrome.
   
2. Øverst i konsollen ser du en Network-fane. Klik på den.
3. Genindlæs siden med Ctrl-R.
   
4. Du vil nu se alle netværksanmodninger, som Chrome har sendt til din server.
5. Klik på den øverste netværksanmodning, som er anmodningen for selve din side.
6. Nu får du mere information om denne netværksanmodning.  Klik på timing-fanen øverst i denne information for at se, hvad TTFB er for din side.

2. HTTP/3

HTTP/3 er den tredje version af HTTP-protokollen. HTTP/3 løser mange af de problemer, der findes i de ældre HTTP/1.1- og HTTP/2-protokoller. For eksempel kan du siden HTTP/2 sende flere filer på samme tid gennem den samme forbindelse. HTTP/3 giver en hurtigere indledende forbindelse og færre problemer med mindre netværksafbrydelser.

Uden at gå for meget i detaljer giver HTTP/3 mulighed for en betydelig hastighedsgevinst, især på et langsommere netværk som et mobilnetværk. Din netværksadministrator kan fortælle dig, om din webserver allerede er klar til den hurtigere HTTP/3-protokol.

Du kan selv tjekke, om din hjemmeside allerede bruger den hurtigere HTTP/3-protokol. Brug genvejen Ctrl-Shift-I til at åbne netværksinspektøren i Google Chrome. Højreklik på tabeloverskriften og vælg Protocol. Genindlæs nu siden for at se, hvilken protokol din side bruger.

3. Browser-caching

Netværksforbindelsen er ofte et svagt led, når det kommer til sidehastighed. Ville det ikke være så meget nemmere at springe netværket helt over?

Når en besøgende har været på din side før, kan du angive, om og hvor længe netværksressourcerne  (for eksempel et stylesheet)  kan gemmes af den besøgendes browser. Hver gang den besøgende har brug for en af disse filer igen, dukker de op fra browserens cache på ingen tid. Som resultat kan browseren begynde at rendere meget hurtigere og fremskynde FCP.

4. Komprimering

Netværkshastigheden er i næsten alle tilfælde et svagt led. For en god First Contentful Paint er det så vigtigt, at filerne sendes gennem netværket så hurtigt som muligt. Komprimering reducerer antallet af bytes, der skal sendes fra serveren – færre bytes betyder mindre ventetid på en netværksressource. Komprimering er efter min mening en teknik, der ikke får den opmærksomhed, den fortjener. Desværre "tænder" for mange webmastere komprimering og kigger så ikke på det igen. Og det er en skam, fordi det bare er en nem måde at gøre tingene lidt hurtigere.

Der er to populære komprimeringsteknikker: Gzip og Brotli. Gzip er den mest brugte komprimeringsteknik, men Brotli er hurtigt ved at indhente det. Brotli er skabt af Google selv og har 15 til 20% bedre resultater, når det kommer til HTML-, JavaScript- eller CSS-filer. Brotli er derfor ideel til nettet.

Der er også forskel på dynamisk komprimering og statisk komprimering. Med dynamisk komprimering komprimerer du filen lige inden du sender den gennem din webserver; med statisk komprimering gemmes den komprimerede fil på serveren. Dette er ofte en meget smartere måde at komprimere på, men det bruges sjældent.

5. Tidlige webskrifttyper med resource hints

Resource hints starter en download eller netværksforbindelse, før browseren ville gøre det på egen hånd. Nogle netværksressourcer, som webskrifttyper eller billeder, downloades først, når browseren er sikker på, at den skal vise dem.

Hvis du er sikker på, at du har brug for en ressource til at rendere den synlige del af siden, er det næsten altid en god idé at inkludere en "resource hint". Dette sikrer, at browseren straks begynder at downloade eller oprette forbindelse til ressourcen. Som resultat er ressourcen tilgængelig hurtigere, og browseren kan begynde at rendere hurtigere.

Men vær forsigtig med resource hints, hvis du bruger dem forkert, kan de faktisk gøre din side langsommere.

Tidlig download med "preloading"

<link rel="preload" href="/static/font/opensans600.woff2" as="font" type="font/woff2" crossorigin>

Preload-linket er et af de mest kraftfulde værktøjer i pagespeed-arsenalet. Gennem preload-linket downloader du en netværksressource, du får brug for senere. Dette er ofte en meget god idé med skrifttyper, kritiske scripts og billeder på den synlige del af siden.

Forbind på forhånd med preconnect

Preconnect-linket forbinder allerede til en server. Dette er nyttigt, når du hoster filer på en tredjepartsserver som et CDN eller Google Analytics.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

6. Forhåndshent den næste side med prefetch

<link rel="prefetch" href="/page2.html">

Med prefetch kan du hente ressourcer med lav prioritet. Dette er en nyttig måde at hente ressourcer, som du tror, du får brug for senere – når du forventer, at nogen klikker på næste side-linket, for eksempel.

7. Undgå omdirigeringer

En almindelig fejl er at have en omdirigeringskæde, der er for lang. Lad mig forklare: Din side kører sandsynligvis gennem en sikker forbindelse. Når en besøgende skriver din side ind uden at tilføje https, vil vedkommende blive omdirigeret til den ikke-sikrede version af din hjemmeside. Men hvis alt er sat rigtigt op, vil den besøgende blive omdirigeret til den sikre hjemmeside. Du kan se dette i det grønne eksempel nedenfor.

Men nogle gange foregår omdirigeringen via et eller flere mellemtrin, som vist i det røde eksempel. Det er disse mellemtrin, der får hjemmesiden til at køre langsomt, hvilket resulterer i en dårlig First Contentful Paint score. Hvert mellemtrin koster ekstra tid, hvilket hurtigt kan lægge sig sammen. Sørg derfor altid for at nå den rigtige side inden for én omdirigering.

8. Minimer CSS

En ekstern CSS-fil er altid renderingsblokerende. Det betyder, at en browser normalt ikke kan begynde at vise indhold, før alle stylesheets er downloadet og analyseret. Derfor er det bedst at holde stylesheets så små som muligt. På denne måde behøver du ikke vente så længe på, at stylesheetet downloades.

Reducer CSS-størrelsen med shortcode

En af måderne at reducere CSS-størrelsen er ved at bruge shortcodes. Disse er one-liners, der giver dig mulighed for at skrive de vigtigste egenskaber for en CSS-selector ned på én linje.

body{
    font-style: normal;
    font-weight: 400;
    font-stretch: normal;
    font-size: 0.94rem;
    line-height: 1.6;
    font-family: "Segoe UI", "Segoe UI", system-ui, -apple-system, sans-serif;
}

Du kan også skrive det som:

body{font: 400 .94rem/1.6 Segoe UI,Segoe UI,system-ui,-apple-system, sans-serif;}

Reducer størrelsen af CSS yderligere

Det er muligt at reducere CSS-størrelsen endnu mere ved at flette selectors sammen med et komma,  fjerne linjeskift og mellemrum og skrive kortere farvekoder.

h1{
  color : #000000;
}
h2{
  color : #000000;
}
h3{
  color : #000000;
}
h4{
  color : #000000;
}
h5{
  color : #000000;
}

Kunne forkortes til

h1,h2,h3,h4,h5{color:#000}

9. Critical CSS

Vi kan tage CSS et skridt videre ved at bruge critical CSS. Critical CSS er et must-have for en hurtig hjemmeside og en hurtig First Contentful Paint.

Critical CSS er en samling af alle selectors (som body, p, h1 osv.), du har brug for til at vise den synlige del af siden. Læg ikke denne critical CSS i et separat stylesheet; tilføj den i stedet direkte i <head> på siden. På denne måde behøver du ikke downloade en ny fil, og browseren kan begynde at rendere med lynhastighed. Dette giver en hurtigere FCP. Den CSS, du ikke direkte har brug for til den synlige del af siden, indlæses efter den første renderingscyklus er afsluttet. For din besøgende er siden allerede færdig – ingen vil bemærke de nye stilarter, der stadig tilføjes i baggrunden.

Critical CSS kan nemt genereres med vores eget critical CSS-værktøj. Indsæt bare URL'en til din webside i værktøjet, og vi klarer resten for dig!

10. Udskyd indlæsning af JavaScript

En af de mest almindelige årsager til en langsom First Contentful Paint er JavaScript. Afhængigt af hvordan du bruger JavaScript, kan det blokere renderingen af siden. Normalt downloades og eksekveres JavaScript, før render-træet bygges. Uden render-træet kan en browser ikke sætte noget på skærmen – dette inkluderer FCP.

Vi kan omgå dette ved at udskyde JavaScript. Du kan gøre dette på tre måder

Async JavaScript

<script async src="async.js"></script>

Ved at tilføje async-attributten til et script-tag blokeres opbygningen af siden ikke længere, mens JavaScript downloades. Async-attributten angiver, at download og opbygning af render-træet kan ske på samme tid.

Når scriptet eksekveres, blokeres siden. I de fleste tilfælde har browseren takket være async-attributten haft nok tid til at bygge en vigtig del af siden, med First Contentful Paint allerede på siden.

Defer JavaScript

<script defer src="async.js"></script>

Defer-attributten fungerer mere eller mindre på samme måde som async-attributten. Ved at tilføje defer-attributten til et script-tag kan scriptet også downloades samtidig med opbygningen af siden. Når alle scripts er downloadet, eksekveres de i den rækkefølge, de blev fundet i HTML-koden. Dette kan også blokere visningen af siden, men i mange tilfælde er First Contentful Paint allerede på skærmen.

11. Stol ikke på eksterne ressourcer

Eksterne ressourcer, som eksterne skrifttyper, eksterne billeder, eksterne stylesheets eller eksterne scripts, er en potentiel flaskehals, når det kommer til First Contentful Paint. Da du ikke har kontrol over serveren, hvor filerne hostes, ved du ikke, hvor hurtigt de sendes. Derudover kan du ikke bruge den eksisterende forbindelse til webserveren. En ny forbindelse til en ny server skal oprettes – og det tager tid.

Blokerende eksterne ressourcer

Ingen eksterne ressourcer

12. Brug det rigtige skrifttypeformat

Skrifttyper fortjener ekstra opmærksomhed, når det kommer til First Contentful Paint. På cirka 99% af de sider, vi kigger på, er FCP-elementet en tekstlinje. Når du bruger eksterne webskrifttyper, skal du først downloade disse skrifttyper fra en server, hvilket – selvfølgelig – tager tid. 

For nylig har webskrifttyper fået mere opmærksomhed, og der er flere nye, hurtigere skrifttypeformater. Det hurtigste skrifttypeformat i øjeblikket er woff2, efterfulgt af woff. Woff2 understøttes af enhver moderne browser. 

Du kan angive den foretrukne rækkefølge af din webskrifttype i CSS font-face-deklarationen. Det gør du som følger:

 @font-face {  
   font-family: 'myFont';  
   font-weight: 400;  
   font-style: normal;  
   font-display: swap;
   unicode-range: U+000-5FF 
   src: local('myFont'),
        url('/fonts/myFont.woff2') format('woff2'),
        url('/fonts/myFont.woff') format('woff');
}

13. Font display:swap

Når du bruger webskrifttyper, er standardadfærden for disse skrifttyper ikke at vise teksten på siden, før skrifttypen er indlæst. Dette går normalt direkte på bekostning af First Contentful Paint. 

Du kan løse dette ved at bruge font-display:swap. Med dette kan du vælge at vise teksten på siden alligevel, i en skrifttype browseren kender, mens webskrifttypen indlæses i baggrunden.

Uden font-display:swap

Med font-display:swap

Læs vores komplette artikel  Sørg for at tekst forbliver synlig under indlæsning af webskrifttype

14. Minimer DOM-størrelsen

En webside består af HTML. Det første en browser gør, er at konvertere HTML til DOM-noder. Det er en træstruktur af HTML-elementer, der senere bruges til at bygge render-træet. Fra render-træet begynder en browser at rendere; til sidst vises websiden på skærmen. 

Hvor mange DOM-noder (HTML-elementer) du har, og hvor dybt disse DOM-noder er i træstrukturen, bestemmer, hvor kompliceret det er for en browser at bygge din side. CSS og JavaScript tager også mere tid at analysere, når du har for mange DOM-noder. Dette går igen direkte på bekostning af FCP.

Løs dette ved at:

• Lazy load dele af din webside
  For at fremskynde den indledende visning, overvej at indlæse dele af din hjemmeside, som footeren, via AJAX på et senere tidspunkt.
• Brug content-visibility
  CSS-egenskaben content-visibility fortæller en browser at springe style, layout og paint over under renderingen. Den gør dette lige inden elementet bliver synligt.
•  Opdel store sider i flere sider
  Antallet af DOM-noder kan reduceres ved at opdele store sider i flere sider.
•  Implementer uendelig scroll
  Uendelig scroll er grundlæggende lazy loading: når du scroller gennem gentagne elementer som billeder (pinterest) eller store datatabeller, kan uendelig scroll markant fremskynde din side.
• Undgå JavaScript DOM-interaktion
  Vær ekstra forsigtig med JavaScript, når du har et stort antal DOM-noder på din side. En kommando som kan derefter indlæse et stort antal DOM-noder, hvilket øger hukommelsesforbruget.
• Undgå komplicerede CSS-deklarationer
  Vær ekstra forsigtig med komplicerede CSS-kommandoer med et stort antal DOM-noder. For eksempel skal du kontrollere last-child-status for hvert div-element på din side.
• Brug web workers til at spare din browsers hovedtråd
  Web workers er JavaScript, der kan køre parallelt med din webside. Du kan give disse web workers kommandoer, der udføres i baggrunden. Når web workeren har udført kommandoen, sender den den videre til den originale side. Fordelen ved dette er, at du stadig kan udføre kompleks JavaScript, uden at siden fryser.