Siden introduksjonen av Lighthouse har nye parametere knyttet til sidehastighet dukket opp. En av de viktigste av disse parameterne er First Contentful Paint (FCP). I Lighthouse versjon 10, gjeldende fra juni 2024, er FCPs innvirkning på den totale poengsummen 10 %.
For å ta i bruk og forstå FCP som en metrikk, er det viktig først å undersøke psykologien bak den. Konseptet ligner på speil montert i heiser:
For å oppsummere kort: I første halvdel av 1900-tallet økte bruken av heis i høye bygninger betydelig, men heissystemer var primitive sammenlignet med i dag. Derfor dukket ideen om å installere speil i heis opp for å få tiden tilbrakt i heisen til å føles kortere.
Tilbake til emnet vårt: Poenget som perseptuelt får deg til å vente under lastetiden når du prøver å få tilgang til en side, er FCP. Definisjonen av First Contentful Paint er tiden det tar før den første teksten, bildet, ikke-hvitt lerret, etc., vises for brukeren. Enheten til FCP er sekunder.
I Lighthouse bestemmes fargeskalaen for FCP som følger:
- 0-2 sekunder: Grønn => Rask
- 2-4 sekunder: Oransje => Trenger forbedring
- 4+ sekunder: Rød => Sakte
I følge HTTP-arkivdata, antall nettsteder som kan vurderes rask er 25%, og 50 % av eksisterende nettsteder er klassifisert som trege.
Hva kan gjøres for å forbedre FCP?
Reduser serverens responstid
Generelt kan dette tolkes som nødvendige forbedringer på serversiden av serveren og programvaren. For å liste opp problemene som negativt påvirker serverens responstid:
- Serverens deling, konfigurasjon (dvs. serverinnstillinger) og serverressurser kan være problemet. Kapasiteten til serveren din bør økes i henhold til trafikken din. I noen tilfeller kan dårlig skrevet databasespørringer og svært komplekse programvarekomponenter alvorlig påvirke serverens responstid.
- Hvis du ikke bruker et CDN (Content Delivery Network) kan det føre til forsinkelser i tilgangen til innhold, noe som påvirker FCP. Ettersom innholdsstørrelsen øker, for eksempel hvis en stor animert GIF eller video blir forsøkt kalt uten CDN og hovedserveren er på et annet kontinent, må du kanskje vurdere CDN-løsninger for å løse FCP.
- Å ikke vise statisk innhold med en riktig og konsistent bufferpolicy kan overbelaste serveren din unødvendig ettersom antall besøkende øker. For eksempel, hvis du ikke oppbevarer logoen din i langtidsbuffer mens du laster den på hver side, skader du serverens responstid unødvendig.
- Unødvendige sideviderekoblinger mens tilgang til siden kan påvirke FCP unødvendig.
For eksempel, tidligere, pleide det å være oppsett som dette: når en bruker ønsket å gå inn på et nettsted, var det en HTTP til HTTPS omdirigering, så hvis det var mobil, en HTTPS til mobil omdirigering (f.eks. https:// www til https://m), og hvis siden ble fjernet og omdirigert andre steder med en 301, føltes det som om brukeren ble sendt fra skrivebord til skrivebord på et skattekontor. Dette er et ekstremt eksempel for bedre forståelse, men hvis du omdirigerer en side til en annen URL med en 301-viderekobling og deretter omdirigerer den siden til en annen med en 301, kan det hende du gjør det samme ulogiske oppsettet.
- Hvis du ikke bruk preconnect eller DNS-prefetch prefikser når du kobler til tredjepartstjenester og kobler til mange tredjepartstjenester, gjør du ikke noe fordelaktig for FCP.
Reduser ressurser for gjengivelsesblokkering
Jeg må innrømme at dette enkeltpunktet skrevet som en linjepost kan ta måneder å adressere.
For å oppnå dette finnes det en løsningsmetode hvor alle JS, CSS og lignende ressurser som blokkerer sidegjengivelsen lastes inn etter at siden ble opprettet, men den opprinnelig synlige delen av nettstedet lastes først mens nettstedet lastes inn. For å gjøre dette må alle JS, CSS og lignende ressurser undersøkes, og de mest tidkrevende prosessene må skilles. I tillegg hjelper det å optimalisere FCP ved å bruke så få tredjepartstjenester som mulig.
