Hvordan forbedrer du dine Google Core Web Vitals-resultater?

(23. august 2020)

Næste æra på websides ydeevne

Det har været et par måneder, jeg har arbejdet om strategier til forbedring af websides ydeevne på mine firmaejede websteder og for at være ærlig er det et rigtig interessant stykke arbejde at dele med jer.

Jeg forstår at arbejde på websides ydeevne ikke er et nyt ting, og folk er kommet med mange ideer og tricks til at øge din sides indlæsningshastighed. Men nu ser det ud til, at det ikke længere er nok, og du er nødt til at træde op på det næste niveau !!

Som I skal vide, om vigtigheden af ​​SEO (søgemaskineoptimering) og at frembringe dine webside-resultater ikke kun på den første side med google-resultater, men øverst på den samme første side er virkelig en hel del! Lang historie kort – lad mig garantere dig, at Google Core Web Vitals herefter vil være en af ​​disse største bidragydere til SEO-placeringen af ​​Googles søgeresultater.

Kort & Enkel forklaring på Google Core Web Vitals

Core Web Vitals, der blev introduceret i første kvartal i år, er et sæt metrics relateret til hastighed, lydhørhed og visuel stabilitet på din webside.

Google har defineret disse som Core Web Vitals:

  • Største tilfredsstillende maling : Den tid, det tager, før en sides hovedindhold indlæses. En ideel LCP-måling er 2,5 sekunder eller hurtigere.
  • First Input Delay : Den tid det tager for en side at blive interaktiv. En ideel måling er mindre end 100 ms .
  • Kumulativt layoutskift : Mængden af ​​uventet layoutforskydning af visuelt sideindhold. En ideel måling er mindre end 0,1 .

Dette sæt metrics er designet til hjælpe ejere af websteder med at måle den brugeroplevelse, de leverer, når det gælder indlæsning, interaktivitet og visuel stabilitet.

Som en helhed vil din sidepræstation herefter blive rangordnet som nedenfor.

Komplet liste over metrics, der tages i betragtning for metrics til sidens ydeevne.

Det næste afsnit taler grundlæggende om ideer eller metoder til at forbedre din sidelastningsydelse og CWV-scoringer.

Tips til forbedring af dine Core Web Vitals-resultater

Nedenfor er nogle metoder der hjalp mig med at forbedre mine Core Web Vitals-scores drastisk såvel som forbedret den samlede sidepræstation.

  1. Brug effektivt browser og CDN-cache (forbedrer FID og LCP)
    Dette er en meget enkel godkendelse ch for at forbedre dine FID- og LCP-scores. Sørg for, at dine statiske aktiver serveres fra et CDN (hvis det er AWS, kan du cache det i Cloudfront). Dette resulterer således i at få ressourcerne hurtigt ind i dine browsere. For at forbedre anden gangs belastning skal du sørge for, at de aktiver, der nåede på klientsiden, er cachelagret i din browser.
    cache-control: max-age=120 – betyder, at den returnerede ressource er gyldig i 120 sekunder, hvorefter browseren skal anmode om en nyere version.
    Du kan også cache din dynamiske sider også i dit CDN med korrekt TTL-værdi baseret på din applikationsadfærd.
  2. Indstil nøjagtige størrelsesegenskaber eller dimensioner til dine medier og annoncer (forbedrer CLS)
    Dette er noget meget vigtigt for at forbedre din CLS-score. Sørg for, at du har et ordentligt height:XXpx; width: YYpx indstillet til dit billede eller andre mediamærker. Igen er dette meget vigtigt i det mindste for de komponenter, der er over folden. En genvej til dette er, at hvis du løber tør for ideer for at få den nøjagtige højde af billedet, kan du indstille som height:auto;, hvilket virkelig hjalp for mig. Bortset fra medier, hvis dit websted viser annoncer, skal du sørge for, at du har indstillet ordentlige annoncepladser med de rigtige dimensioner, da det at skubbe op eller ned på komponenterne på siden helt sikkert vil reducere din CLS-score. Så hold også øje med annoncer!
  3. Lazy load-billeder i højre opløsning baseret på enhedstype (forbedrer LCP)
    Dette er virkelig en hurtig gevinst for dig! Der er mange dovne lastningspakker i verden, som du kan bruge på din webside til doven at indlæse alle billederne på din side.Dette reducerer den samlede sidevægt og indlæsningstid for gengivelse af din side i browseren. Et andet vigtigt stykke er, at du foruddefinerer opløsningen på det billede, du vil indlæse, baseret på enhedstype. Du skal ikke indlæse de samme opløsningsbilleder i forskellige enhedstyper.
  4. Brug effektivt SSR og CSR på din webside (forbedr FID & LCP)
    Du skal vide, at Google promoverer og opmuntrer SSR-sider (Server Side Rendered) til at få gode SEO-værdier. Men ideelt set er det en kompromis med SEO Vs Side Load Performance. Hvis din side er for stor med hensyn til indhold, og hvis du beslutter at gengive hele siden på serveren, vil det helt sikkert tage mere tid at indlæse hele siden såvel som siden Vægten vil også være høj. Lang historie kort – min anbefaling er, at det er bedre at lave SSR-gengivelsen for dine sidekomponenter, der vises over folden, og gengive resten af ​​komponenterne fra klientsiden, der vises under folden. På denne måde får brugeren siden indlæst over folden, og resten af ​​siden gengiver asynkront uden hindring af brugeroplevelsen.
  5. Brug kode Opdeling & opdele dine aktiver i klumper (forbedrer FID & LCP)
    Det er altid ikke en god ide at have store aktiver (alt over 100 KB er enorme) aktiver (specielt JS-filer) i din applikation. Så brug bedre pakker som “webpack” til at opdele tunge aktiver til små stykker, der asynkront indlæser dine aktiver ind i din browser (hvis du aktiverer h2-protokol). Du kan også udnytte kodeaddelingsfunktionerne til at opdele dine sidekomponenter til separate filer i stedet for at pakke den i en enkelt HTML-fil.
  6. Komprimer alle dine statiske aktiver med Brotli-komprimering (forbedrer LCP)
    Jeg opfordrer til at bruge Brotli til at komprimere dine statiske aktiver, hvilket giver meget bedre co impressionsforhold sammenlignet med andre biblioteker på markedet. På samme tid skal du huske på, at når du bruger Brotli med et højere kompressionsforhold, vil det helt sikkert øge din bygge- og pakketid i DevOps pipeline-rejsen. For mig var det fint at ofre applikationens opbygningstid, da jeg får en bedre værdi med hensyn til sideindlæsningsydelse.
  7. Optimer API-anmodningen og responsindhold (forbedrer FID & LCP)
    Dette er super vigtigt at blive betragtet, da hver byte betyder noget her, når vi taler om side ydeevne. Jeg stoler på, at du ikke vil fortryde at gå tilbage og kontrollere dine API-anmodninger & svar for at udfylde din side. Sørg for, at du kun får tilbage de data, du har brug for til din side til Bliv gengivet fra API-svarene. En anden dum ting, du muligvis kan lave en fejl er, at dine API-opkald påberåbes internt i stedet for at bruge offentlige slutpunkter eller via internettet – fordi det altid er dyrt med hensyn til tid, når du påkalder dine APIer via internettet, når du har dine APIer hostet i det samme undernet eller i det mindste i det samme netværk!
  8. Reducer den samlede side / dokument størrelse (forbedrer LCP)
    Ideelt set, hvis din destinationsside er tung (jeg vil kategorisere enhver side med> 80 KB som tung), vil dette helt sikkert bidrage dårligt til LCP-score da det forholdsmæssigt øger hentning og download af din side. Så sørg for, at du ikke får noget ubrugt stort stykke data fra serversiden, og indlæs kun de data, der er nødvendige for gengivelse af din side.
  9. Brug NEXT-GEN billedformater (forbedrer LCP)
    JPEG 2000, JPEG XR og WebP er billedformater, der har overlegne komprimerings- og kvalitetsegenskaber i forhold til deres ældre JPEG og PNG-kolleger. Kodning af dine billeder i disse formater i stedet for JPEG eller PNG betyder, at de indlæses hurtigere og bruger mindre mobildata. Du kan bruge ethvert værktøj på markedet til at konvertere billederne til NEXT-GEN-formaterede billeder, eller du kan endda oprette en runtime-billedtjeneste, der kan foretage en realtidskonvertering fra JPEG til WebP og tjene i browseren.
  10. Aktiver fallback til de oprindelige browserstøttede skrifttyper (forbedrer FID)
    Det er bevist, at skrifttyper kan virkelig nedbringe dine præstationsresultater, hvis browseren forsinkes for at indlæse din brugerdefinerede skrifttype, der bruges i din applikation, medmindre den er en standardskrifttype, der understøttes af browseren. I dette tilfælde er en hurtig gevinst for dig at have en tilbagefaldstilgang til indlæsning din skrifttype med de skrifttyper, der er understøttet af browseren som standard. Nedenfor er et eksempel på kodestykke om, hvordan du har en tilbagefaldstilgang med andre skrifttyper.
@font-face { 
font-family: “Open Sans Regular” "Helvetica", "Arial", sans-serif;
font-weight: 400;
font-style: normal;
src: url(“fonts/OpenSans-Regular-BasicLatin.woff2”) format(“woff2”); font-display: swap;
}

Alle de ovennævnte tip kunne trinvist implementeres i din applikation og igen som nævnt før Core Web Vitals-scorerne udvikles fra ægte bruger data og ikke længere fra nogen “Lab” -data. Således tager det tid at reflektere forbedringerne i din score, som for det meste er 28 dages tid at reflektere. Du kan stadig bruge PageSpeed-værktøjet fra google – https://developers.google.com/speed/pagespeed/insights/ for at få din CWV-score.

Håber det hjælper og ønsker dig al succes i dine værker! Skål!

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *