Siden introduktionen af Lighthouse er nye parametre relateret til sidehastighed dukket op. En af de vigtigste af disse parametre er First Contentful Paint (FCP). I Lighthouse version 10, gældende fra juni 2024, er FCP's indvirkning på den samlede score 10 %.
For at adoptere og forstå FCP som en metrik, er det vigtigt først at undersøge psykologien bag det. Konceptet ligner spejle installeret i elevatorer:
For at opsummere kort: I første halvdel af 1900-tallet steg brugen af elevatorer i høje bygninger markant, men elevatorsystemer var primitive i forhold til i dag. Derfor opstod ideen om at installere spejle i elevatorer for at få tiden tilbragt i elevatoren til at føles kortere.
Tilbage til vores emne: Det punkt, der perceptuelt får dig til at vente under indlæsningstiden, når du forsøger at få adgang til en side, er FCP. Definitionen af First Contentful Paint er den tid, det tager for den første tekst, billede, ikke-hvidt lærred osv. at blive vist for brugeren. Enheden for FCP er sekunder.
I Lighthouse bestemmes farveskalaen for FCP som følger:
- 0-2 sekunder: Grøn => Hurtig
- 2-4 sekunder: Orange => Trænger til forbedring
- 4+ sekunder: Rød => Langsom
Ifølge HTTP-arkivdata er antallet af websteder, der kan overvejes hurtig er 25%, og 50 % af eksisterende websteder er klassificeret som langsomme.
Hvad kan der gøres for at forbedre FCP?
Reducer svartiden for serveren
Generelt kan dette tolkes som nødvendige forbedringer på serversiden af serveren og softwaren. Sådan angiver du de problemer, der negativt påvirker serverens responstid:
- Serverens deling, konfiguration (dvs. serverindstillinger) og serverressourcer kan være problemet. Kapaciteten på din server bør øges i henhold til din trafik. I nogle tilfælde kan dårligt skrevne databaseforespørgsler og meget komplekse softwarekomponenter alvorligt påvirke serverens responstid.
- Ikke brug af et CDN (Content Delivery Network) kan forårsage forsinkelser i adgangen til indhold, hvilket påvirker FCP. Da indholdsstørrelsen øges, for eksempel, hvis en stor animeret GIF eller video forsøges kaldet uden et CDN, og hovedserveren er på et andet kontinent, skal du muligvis overveje CDN-løsninger for at løse FCP.
- Ikke at vise statisk indhold med en ordentlig og konsekvent cachepolitik kan overbelaste din server unødigt i takt med at antallet af besøgende stiger. For eksempel, hvis du ikke opbevarer dit logo i langtidscache, mens du indlæser det på hver side, skader du unødigt din servers responstid.
- Unødvendige sideomdirigeringer mens adgang til siden kan påvirke din FCP unødigt.
For eksempel plejede der tidligere at være opsætninger som dette: når en bruger ønskede at komme ind på et websted, var der en HTTP til HTTPS-omdirigering, og hvis den var mobil, en HTTPS til mobil-omdirigering (f.eks. https:// www til https://m), og hvis siden blev fjernet og omdirigeret et andet sted med en 301, føltes det som om brugeren blev 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 anden URL med en 301-omdirigering og derefter omdirigerer siden til en anden med en 301, laver du måske den samme ulogiske opsætning.
- Hvis du Brug ikke preconnect eller DNS-prefetch præfikser, når du opretter forbindelse til dine tredjepartstjenester og opretter forbindelse til mange tredjepartstjenester, gør du ikke noget gavnligt for FCP.
Reducer ressourcer til gengivelsesblokering
Jeg må indrømme, at dette enkelte punkt skrevet som en linjepost kan tage måneder at behandle.
For at opnå dette er der en løsningsmetode, hvor alle JS, CSS og lignende ressourcer, der blokerer sidegengivelsen, indlæses efter sidens oprettelsestid, men den oprindeligt synlige del af webstedet indlæses først, mens webstedet indlæses. For at gøre dette skal alle JS, CSS og lignende ressourcer undersøges, og de mest tidskrævende processer skal adskilles. Derudover hjælper brugen af så få tredjepartstjenester som muligt med at optimere FCP.
