Core Web Vitals paaiškinta: LCP, INP ir CLS paprastai

Core Web Vitals nėra jūsų svetainės asmenybės testas

Core Web Vitals dažnai traktuojami kaip paslaptinga rezultatų kortelė. Puslapis gauna raudoną skaičių, kažkas įkelia ekrano nuotrauką į Slack, ir komanda pradeda ginčytis dėl JavaScript karkasų.

Tai nėra ypač naudinga.

Geresnis būdas galvoti apie Core Web Vitals yra paprastesnis: tai trys matavimai, rodantys, ar puslapis tikram žmogui tikrame įrenginyje atrodo patogus naudoti. Jie neapima kiekvieno našumo, prieinamumo ar kokybės aspekto. Tačiau jie užfiksuoja tris dažnus nusivylimo šaltinius:

• Pagrindinis turinys pasirodo per lėtai.
• Puslapis lėtai reaguoja, kai naudotojas bando ką nors padaryti.
• Maketas šokinėja, kol naudotojas skaito arba baksteli.

Tai ir yra trys Core Web Vitals: LCP, INP ir CLS.

Google naudoja juos kaip savo puslapio patirties signalų dalį, tačiau SEO aspektas nėra geriausia priežastis tuo rūpintis. Geresnė priežastis yra ta, kad lėti, šokinėjantys ir nereaguojantys puslapiai švaisto naudotojų laiką. Jie taip pat dažniausiai prasčiau konvertuoja, sunkiau aptarnaujami ir prasčiau sensta.

Trys metrikos po vieną sakinį

Prieš pereinant prie detalių, štai paprastas paaiškinimas:

• LCP, arba Largest Contentful Paint, matuoja, kiek laiko užtrunka įkelti pagrindinį matomą turinį.
• INP, arba Interaction to Next Paint, matuoja, kaip greitai puslapis reaguoja į naudotojo sąveikas per apsilankymą.
• CLS, arba Cumulative Layout Shift, matuoja, kiek puslapis netikėtai juda.

Įprasti slenksčiai yra:

| Metric | Good | Needs improvement | Poor | |---|---:|---:|---:| | LCP | 2.5s or faster | 2.5s–4.0s | Over 4.0s | | INP | 200ms or faster | 200ms–500ms | Over 500ms | | CLS | 0.1 or lower | 0.1–0.25 | Over 0.25 |

Šie skaičiai paprastai vertinami pagal realių naudotojų apsilankymų 75-ąjį procentilį. Tai svarbu. Jūs nesiekiate sukurti vieno tobulo laboratorinio paleidimo. Jūs siekiate, kad patirtis būtų gera daugumai naudotojų, įskaitant žmones su lėtesniais telefonais ir netvarkingesniais tinklais.

Jei žiūrite į automatizuotą ataskaitą ir nežinote, nuo ko pradėti, padeda atskirti diagnostiką nuo panikos. Turime atskirą gidą, kaip skaityti Lighthouse ataskaitą nepanikuojant, kuriame šis procesas aptariamas išsamiau.

LCP: kada puslapis atrodo įkeltas?

Largest Contentful Paint matuoja didžiausio matomo turinio elemento atvaizdavimo laiką peržiūros srityje. Praktikoje tai dažnai būna:

• pagrindinis herojinis paveikslėlis,
• didelė antraštė,
• išskirtinio straipsnio paveikslėlis,
• produkto paveikslėlis,
• didelis teksto blokas.

LCP neklausia, kada baigė krautis kiekvienas scenarijus, sekimo pikselis ir žemiau matomos srities esantis paveikslėlis. Jis klausia: kada pagrindinis dalykas, kurio naudotojas atėjo pamatyti, tapo matomas?

Dėl to LCP yra žmogiškesnė metrika nei senamadiškas „puslapio įkėlimo laikas“. Puslapis techniškai gali baigti krautis vėlai, bet vis tiek atrodyti greitas, jei pagrindinis turinys pasirodo greitai. Galioja ir priešingai: puslapis gali paleisti įkėlimo įvykį, kai hero sritis vis dar tuščia, sulieta arba blokuojama atvaizdavimo delsos.

Dažnos prasto LCP priežastys

Dauguma blogo LCP problemų kyla iš kelių nuspėjamų vietų:

1. Lėtas serverio atsakas

Jei HTML dokumentas atkeliauja vėlai, visa kita prasideda vėlai.

1. Atvaizdavimą blokuojantis CSS arba JavaScript

Naršyklė turi turinį, bet dar negali jo nupiešti.

1. Neoptimizuoti hero paveikslėliai

Didžiausias elementas yra per didelis, netinkamo formato, jam nesuteiktas prioritetas arba jis per klaidą kraunamas tingiai.

1. Web fonts, atidėliojantys teksto atvaizdavimą

Didelė antraštė gali būti LCP elementas, o šriftų įkėlimas gali ją pavėlinti arba vizualiai pakeisti.

1. Kliento pusės atvaizdavimo delsos

Jei puslapiui reikia didelio JavaScript paketo, kad jis galėtų parodyti prasmingą turinį, LCP nukenčia.

Kaip pagerinti LCP

Pradėkite nuo tikrojo LCP elemento. Neoptimizuokite atsitiktinių išteklių, kol nežinote, ką naršyklė matuoja.

Praktiniai pataisymai:

• Greitai pateikite HTML: kur tinka, naudokite talpyklą, mažinkite backend darbą, venkite lėtų peradresavimų.
• Optimizuokite LCP paveikslėlį: naudokite tinkamus matmenis, suspaudimą ir formatą.
• Nenaudokite tingaus įkėlimo above-the-fold hero paveikslėliui.
• Atsargiai naudokite fetchpriority="high" pagrindiniam paveikslėliui, kai jis iš tiesų yra prioritetas.
• Įterpkite kritinį CSS tik tada, kai tai reikšmingai sumažina atvaizdavimo delsą.
• Sumažinkite JavaScript kiekį, reikalingą prieš pirmą prasmingą atvaizdavimą.
• Naudokite font-display: swap arba kitą apgalvotą šriftų strategiją.

Paveikslėliai ir šriftai yra dažni kaltininkai. Paveikslėlių atveju kompromisas nėra vien „mažas failas gerai“. Svarbu ir formato pasirinkimas, kodavimo pastangos bei naršyklių palaikymas, todėl turime praktinį sprendimų medį apie tai, kada AVIF pranoksta WebP, o kada ne. Puslapiams, kuriuose daug teksto, web fonts vis dar yra vienas lengviausių našumo laimėjimų, nes daugelis svetainių siunčia daugiau šriftų failų, nei iš tikrųjų naudoja.

INP: ar puslapis reaguoja, kai jį paliečiate?

Interaction to Next Paint matuoja reagavimą. Tiksliau, ji žiūri į delsą tarp naudotojo sąveikos ir kito vizualinio atnaujinimo po to, kai naršyklė apdoroja tą sąveiką.

Sąveikos apima tokius veiksmus kaip:

• mygtuko paspaudimas,
• meniu bakstelėjimas,
• žymimojo langelio pasirinkimas,
• rašymas formos lauke,
• akordeono atidarymas.

2024 m. INP pakeitė First Input Delay kaip Core Web Vital. Tai buvo geras pakeitimas. First Input Delay vertino tik pirmąją sąveiką. INP yra platesnė: ji vertina sąveikas per visą apsilankymą puslapyje ir pateikia didelės delsos sąveiką kaip puslapio reagavimo balą.

Paprastai tariant: INP pagauna puslapius, kurie atrodo įkelti, bet jaučiasi užstrigę.

Tikriausiai esate naudoję tokį puslapį. Jis atrodo paruoštas. Bakstelite meniu. Pusę sekundės nieko nevyksta. Bakstelite dar kartą. Tada du dalykai įvyksta vienu metu. Tai yra INP problema.

Dažnos prasto INP priežastys

INP paprastai yra pagrindinės gijos problema. Naršyklė nori reaguoti, bet jai trukdo JavaScript, atvaizdavimo darbas arba maketo skaičiavimas.

Tipinės priežastys:

• dideli JavaScript paketai,
• brangūs įvykių apdorokliai,
• hidratacijos darbas kliento pusėje atvaizduojamose programose,
• trečiųjų šalių scenarijai, konkuruojantys dėl pagrindinės gijos,
• ilgai trunkančios užduotys po puslapio įkėlimo,
• sudėtingi DOM atnaujinimai, kuriuos sukelia mažos sąveikos,
• maketo thrashing, kai kodas pakartotinai skaito ir rašo maketo reikšmes.

Rinkodaros žymos, analitika, pokalbių valdikliai ir sutikimo juostos gali prisidėti. Tai nereiškia „pašalinkite viską“. Tai reiškia, kad kiekvienas scenarijus puslapyje turi kainą, o sąveikos delsa dažnai yra vieta, kur ši kaina tampa matoma.

Kaip pagerinti INP

INP gerinimas mažiau susijęs su vienu stebuklingu atributu ir daugiau su pagrindinės gijos apkrovos mažinimu.

Naudingi metodai:

• Suskaidykite ilgas JavaScript užduotis į mažesnes dalis.
• Atidėkite nebūtiną darbą, kol puslapis taps tinkamas naudoti.
• Pašalinkite nenaudojamą JavaScript, o ne vien jį sumažinkite.
• Įvykių apdoroklius laikykite mažus ir nuspėjamus.
• Venkite iš naujo atvaizduoti dideles sąsajos dalis dėl mažų būsenos pokyčių.
• Paprastoms vizualinėms būsenoms, kur įmanoma, naudokite CSS.
• Audituokite trečiųjų šalių scenarijus ir įkelkite juos tik ten, kur reikia.

Taip pat pažiūrėkite į sąveikos dizainą. Mygtukas, suteikiantis momentinį vizualinį grįžtamąjį ryšį, gali atrodyti reaguojantis greičiau, net jei tolesnis darbas trunka ilgiau. Tai nėra našumo pakaitalas, bet tai yra geros sąsajos inžinerijos dalis. Mūsų prieinamų žiniatinklio mygtukų kontrolinis sąrašas su tuo persidengia: aiškios būsenos, tinkama semantika ir nuspėjamas elgesys padeda ir naudotojams, ir naršyklėms.

CLS: ar puslapis lieka ten, kur naudotojas tikisi?

Cumulative Layout Shift matuoja netikėtą matomų elementų judėjimą. Jei naudotojas pradeda skaityti pastraipą, o virš jos įsikrauna reklama, paveikslėlis ar juosta ir nustumia tekstą žemyn, tai prisideda prie CLS.

CLS nematuojamas sekundėmis. Tai balas, paremtas tuo, kiek turinio pajudėjo ir kaip toli jis pajudėjo. Kuo mažesnis, tuo geriau.

Svarbiausias žodis yra netikėtas. Maketo pokyčiai, kuriuos sukelia naudotojo veiksmas, paprastai neskaičiuojami taip pat. Jei kas nors baksteli „rodyti daugiau“ ir turinys išsiplečia, tai tikėtina. Jei po trijų sekundžių viršuje pasirodo naujienlaiškio juosta ir nustumia viską žemyn, tai netikėta.

Dažnos prasto CLS priežastys

CLS nesėkmės dažnai būna žemiškos:

• paveikslėliai be width ir height atributų,
• reklamos arba įterpiniai be rezervuotos vietos,
• slapukų juostos, įterptos virš turinio,
• web fonts, kurie persijungia su kitokiomis metrikomis,
• vėlai įsikraunančios reklaminės juostos,
• dinamiškai įterptas turinys netoli puslapio viršaus.

Pataisymas paprastai yra rezervuoti vietą prieš turiniui atvykstant. Naršyklė turėtų žinoti puslapio formą kuo anksčiau.

Kaip pagerinti CLS

Pradėkite nuo matomų poslinkių. Peržiūrėkite įrašą arba naudokite naršyklės įrankius, kad nustatytumėte, kurie elementai juda.

Tada pritaikykite nuobodžius pataisymus:

• Pridėkite aiškius width ir height atributus paveikslėliams.
• Naudokite CSS aspect-ratio responsyviems medijos konteineriams.
• Rezervuokite fiksuotą arba minimalią vietą reklamoms, įterpiniams ir iframe.
• Venkite po įkėlimo įterpti juostas virš esamo turinio.
• Rinkitės šriftų pakaitalus su panašiomis metrikomis į galutinį šriftą.
• Venkite animacijų, kurios keičia maketo savybes, tokias kaip top, left, width ar height; pirmenybę teikite transformacijoms.

CLS yra viena iš nedaugelio našumo metrikų, kur disciplina pranoksta gudrumą. Jei puslapio dėžutės stabilios, jis paprastai gauna gerą įvertinimą.

Lauko duomenys ir laboratoriniai duomenys abu naudingi, bet atsako į skirtingus klausimus

Dažnas painiavos šaltinis yra tai, kad skirtingi įrankiai rodo skirtingus skaičius. Tai normalu.

Lauko duomenys gaunami iš tikrų naudotojų. Jie atspindi realius įrenginius, tinklus, vietas ir naršyklės sąlygas. Google Chrome User Experience Report yra lauko duomenų pavyzdys.

Laboratoriniai duomenys gaunami iš kontroliuojamos testavimo aplinkos. Lighthouse yra gerai žinomas pavyzdys. Jis pakartojamas ir naudingas derinimui, bet tai nėra tas pats, kas jūsų naudotojų reali patirtis.

Naudokite lauko duomenis, kad nuspręstumėte, ar naudotojai turi realią problemą. Naudokite laboratorinius duomenis, kad tą problemą atkurtumėte ir derintumėte.

Taip pat prisiminkite, kad Core Web Vitals paprastai vertinami pagal URL arba URL grupę, o ne kaip viena abstrakti jūsų prekės ženklo savybė. Jūsų pagrindinis puslapis, tinklaraščio straipsnis, kainodaros puslapis ir atsiskaitymas gali turėti labai skirtingus siauruosius taškus.

Protinga darbų tvarka

Jei visos trys metrikos prastos, kyla pagunda pradėti visur. Atsispirkite tam.

Praktinė tvarka:

1. Pirmiausia pataisykite akivaizdų CLS

Trūkstami paveikslėlių matmenys ir nestabilios juostos dažnai yra greiti laimėjimai.

1. Pagerinkite LCP svarbiems šablonams

Susitelkite į puslapius, kurie svarbūs: produktų puslapius, nukreipimo puslapius, straipsnius, registracijos srautus.

1. Tirkite INP su tikromis sąveikomis

Spauskite tai, ką naudotojai iš tikrųjų spaudžia. Meniu, filtrai, formos ir atsiskaitymo valdikliai dažnai atskleidžia daugiau nei pradinio įkėlimo pėdsakas.

1. Audituokite trečiųjų šalių scenarijus

Palikite tuos, kurie pateisina savo kainą. Pašalinkite arba atidėkite tuos, kurie nepateisina.

1. Nustatykite našumo biudžetą

Be biudžeto našumo patobulinimai nyksta. Nauji scenarijai, paveikslėliai ir dizaino komponentai tyliai panaikins atliktą darbą.

Svarbiausia: neoptimizuokite dėl ženklelio. Optimizuokite naudotojo kelionei. Nedidelis balo pagerėjimas mažo srauto puslapyje gali būti mažiau svarbus nei šiek tiek netobula, bet daug greitesnė atsiskaitymo sąveika.

<!-- tool-cta:start -->

💡 Išbandykite tai: Kadangi LCP paprastai yra vaizdo problema, sumažinkite savo pagrindinį vaizdinį elementą su Image Compressor kaip pirmą lengvą laimėjimą.

<!-- tool-cta:end -->

Ko Core Web Vitals jums nepasako

Core Web Vitals yra naudingi, bet neišsamūs.

Jie nepasako, ar jūsų turinys geras. Jie nepasako, ar jūsų navigacija logiška. Jie negarantuoja prieinamumo. Jie nematuoja privatumo, saugumo, pasitikėjimo, skaitomumo ar to, ar puslapis atsako į naudotojo klausimą.

Jie taip pat nepakeičia sprendimo. Puslapis gali atitikti Core Web Vitals ir vis tiek būti nemalonus. Sudėtinga programa gali nepasiekti slenksčio, bet vis tiek būti atsakingai sukurta atsižvelgiant į savo apribojimus.

LCP, INP ir CLS vertinkite kaip dūmų signalizatorius. Kai jie suveikia, tirkit. Kai jie tyli, toliau prižiūrėkite pastatą.