Core Web Vitals: LCP, INP un CLS

4. modulis: Ātrums, mobilās ierīces un https · Lasīšanas laiks: 13 minūtes

Mērķis: Pēc šīs nodarbības Jūs varēsiet izskaidrot trīs Core Web Vitals rādītājus un to robežvērtības, nosaukt atšķirību starp lauka datiem un laboratorijas datiem, nolasīt PageSpeed Insights mērījumu, novērst galvenos sliktu rezultātu cēloņus un godīgi novērtēt, cik liela nozīme ātrumam ir meklēšanas rezultātos.

Pamatjēdzieni: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75. procentile, lauka dati (CrUX), laboratorijas dati (Lighthouse), PageSpeed Insights, Search Console pārskats Core Web Vitals, TTFB, saspiešana, width un height attēliem, loading="lazy", lapas pieredze

Ātrums trīs skaitļos

"Vai mana vietne ir ātra?" ir neskaidrs jautājums. Google un Chrome veidotāji to ir pārvērtuši trīs izmērāmos jautājumos, ko sauc par Core Web Vitals:

Dažas lietas, kas jāsaprot pareizi:

• LCP mēra brīdi, kad parādās lielākais redzamais elements. Parasti tas ir liels foto lapas augšā (tā sauktais "hero") vai liels teksta bloks. Bloemenatelier Lotte gadījumā tas ir ziedu kompozīcijas foto sākumlapā.
• INP ņem vērā visus klikšķus, pieskārienus un taustiņu nospiedienus apmeklējuma laikā un ziņo (gandrīz) lēnāko reakciju. INP 2024. gada 12. martā aizstāja veco mērījumu FID (First Input Delay), kas skatījās tikai uz pirmo klikšķi un tikai uz gaidīšanu pirms apstrādes. Ja vecā rakstā redzat FID, šī informācija ir novecojusi.
• CLS nav laiks, bet rādītājs bez mērvienības. Tas pieaug, ja lasīšanas laikā kaut kas pārvietojas: Jūs gribat pieskarties pogai, bet tajā brīdī augšā parādās reklāmjosla, un Jūs nospiežat ko citu.

75. procentile

Lapa "izpilda" Core Web Vitals prasības, ja 75 procentos apmeklējumu visi trīs rādītāji ir labi, mērot atsevišķi mobilajām ierīcēm un datoriem. To sauc par 75. procentili. Tas nozīmē: svarīgs nav Jūsu ātrais dators ar optisko internetu, bet lielākās daļas apmeklētāju pieredze, arī to, kuriem ir vecāks tālrunis ar 4G savienojumu.

Lauka dati un laboratorijas dati

Ir divu veidu mērījumi, un tie bieži uzrāda atšķirīgus skaitļus.

• Lauka dati nāk no īstiem apmeklētājiem. Chrome (no lietotājiem, kas to atļauj) anonīmi apkopo, cik ātras bija lapas, pārskatā Chrome User Experience Report (CrUX). PageSpeed Insights rāda pēdējo 28 dienu lauka datus. Search Console pārskats Core Web Vitals izmanto to pašu avotu. Ja Jūsu lapai ir par maz apmeklētāju, PageSpeed Insights rāda visas vietnes ("origin") datus, un, ja arī to ir par maz, lauka datu nav.
• Laboratorijas dati nāk no simulēta testa ar Lighthouse: viena ielāde uz imitēta vidēja līmeņa tālruņa un savienojuma. Lighthouse nevar izmērīt INP (neviens neklikšķina), tāpēc tas rāda citus skaitļus, piemēram, Total Blocking Time, kas tomēr norāda uz INP.

Novērtējumam svarīgi ir lauka dati. Laboratorijas dati noder, lai atrastu cēloņus un pēc uzlabojuma uzreiz redzētu, vai tas palīdz, negaidot 28 dienas.

Cik liela ir tā nozīme?

Šeit bieži tiek pārspīlēts. Ko par to saka pats Google dokumentācijā par lapas pieredzi:

• "Core Web Vitals are used by our ranking systems": tātad tie tiek ņemti vērā.
• Atsevišķa "lapas pieredzes signāla" nav. Citi labas lapas pieredzes aspekti (https, nav uzbāzīgu uznirstošo logu, ērta lietošana mobilajā ierīcē) pēc Google teiktā tieši nepalīdz ierindoties augstāk, taču padara Jūsu vietni patīkamāku.
• "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." Tātad lēna lapa ar labāko atbildi var būt pašā augšā.
• Pēc Google domām, tiekties pēc ideāla rezultāta tikai SEO dēļ "varbūt nav labākais veids, kā izmantot savu laiku".

Secinājums: parūpējieties, lai Jūs būtu zaļajā vai vismaz oranžajā zonā, galvenokārt tāpēc, ka apmeklētāji pamet lēnu vai lēkājošu lapu. Cīņa par 100, nevis 90 punktiem Lighthouse meklēšanas rezultātos dod maz.

Cēloņi, ko varat novērst paši

Lēna pirmā atbilde (TTFB)

Viss sākas ar brīdi, kad pienāk HTML pirmais baits, Time to First Byte. TTFB pats nav Core Web Vitals rādītājs, taču lēns TTFB padara labu LCP gandrīz neiespējamu. web.dev kā orientieri min: labi ir 0,8 sekundes vai mazāk, slikti ir vairāk nekā 1,8 sekundes. Cēloņi pēc web.dev: hostingam trūkst skaitļošanas jaudas, nav kešatmiņas (katra lapa tiek veidota no jauna, tipiski WordPress bez kešatmiņas spraudņa), pāradresācijas (nodarbība 4.1) un tāls serveris bez CDN.

Tam pieder arī saspiešana: serverim HTML, CSS un JavaScript jāsūta saspiestā veidā ar gzip vai Brotli. To var redzēt galvenes rindā Content-Encoding: gzip vai br. Gandrīz katrs hostings to dara pēc noklusējuma, taču nepareizs iestatījums vai vecs serveris to var izslēgt.

Attēli

Attēli ir biežākais slikta LCP un CLS cēlonis:

1. Pārāk lieli. Foto 4000 pikseļu platumā un 5 MB apjomā 800 pikseļu laukumam. Samaziniet attēlu pirms augšupielādes un izmantojiet modernu formātu, piemēram, WebP vai AVIF.

2. Nav platuma un augstuma. Bez width un height pārlūks nezina, cik daudz vietas attēlam vajag, un teksts zem tā pārlec, tiklīdz attēls ielādējas. web.dev iesaka norādīt width un height katram <img>:

   <img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">

3. Svarīgākā foto slinkā ielāde. loading="lazy" ielādē attēlu tikai tad, kad tas parādās ekrānā. Tas ir labi attēliem tālāk lapā, taču web.dev skaidri saka: attēlus, kas redzami jau atverot lapu, un īpaši LCP attēlu, NEielādējiet slinki. Citādi pārlūks kavējas tieši ar to foto, kas nosaka Jūsu LCP.

Lēkājošs saturs un lēnas reakcijas

Citi CLS cēloņi pēc web.dev: fonti, kas ielādes laikā maina izmēru, reklāmas un iegulti logrīki, kas paši sevi palielina, un saturs, kas vēlāk tiek ievietots virs esošā satura (piemēram, sīkdatņu josla, kas nobīda lapu uz leju, nevis atrodas tai pāri). Slikts INP gandrīz vienmēr rodas no pārāk liela JavaScript apjoma: smagas tēmas, slīdrādes, tērzēšanas logrīki un trešo pušu izsekotāji. Kritiski izvērtējiet katru spraudni vai iegulto pakalpojumu; šeit mazāk tiešām nozīmē vairāk.

Praksē: mērīšana ar PageSpeed Insights

Atveriet pagespeed.web.dev, ievadiet savas sākumlapas adresi un noklikšķiniet uz Analyze. Jūs redzēsiet divas cilnes (Mobile un Desktop). Augšā ir Core Web Vitals novērtējums, kas balstīts uz lauka datiem, ja tādi ir. Zem tā ir Lighthouse tests ar rezultātu un sarakstu "Diagnostics" ar konkrētiem punktiem, piemēram, par attēliem, kas ir lielāki nekā nepieciešams, vai par LCP attēlu, kas tiek ielādēts slinki (precīzie nosaukumi mainās līdz ar jaunām Lighthouse versijām). Sāciet ar Mobile: tur rezultāts parasti ir sliktāks, un Google vispirms skatās mobilo versiju (nodarbība 4.2).

Ja Jūsu vietne ir pievienota Search Console (modulis 2), apskatiet arī sadaļu Experience, Core Web Vitals. Tur redzamas līdzīgu lapu grupas ar to statusu, arī lapām, kuras paši neesat testējuši.

AI Builder veidota vietne norāda platumu un augstumu attēliem, kuru izmērs ir zināms, ielādē lapas pirmo foto uzreiz un ar prioritāti (fetchpriority="high"), pārējos slinki, un publicējot izveido lieliem foto 800 pikseļu platu variantu. WordPress vislabāk palīdz kešatmiņas spraudnis un attēlu samazināšana; WordPress kursa modulī 6 tas aplūkots sīkāk. Citiem vietņu veidotājiem un hostinga uzņēmumiem tas darbojas līdzīgi: pogas atšķiras, cēloņi ir tie paši.

Kopsavilkums

• Core Web Vitals ir LCP (labi līdz 2,5 s), INP (labi līdz 200 ms, kopš 2024. gada marta FID vietā) un CLS (labi līdz 0,1), mērot 75. procentilē katram ierīces veidam.
• Novērtējumu nosaka lauka dati (CrUX, 28 dienas); laboratorijas dati (Lighthouse) palīdz atrast cēloņus.
• Google izmanto Core Web Vitals ranžēšanā, taču svarīgāka ir atbilstība: ideāls rezultāts nav pašmērķis.
• Lielākais ieguvums: ātra servera atbilde ar kešatmiņu un saspiešanu, nelieli attēli ar width un height, svarīgākā foto ielāde bez slinkās ielādes, mazāk trešo pušu JavaScript.

Tests (quiz)

Uzdevums

Uzdevums A4.3: Ātra atbilde un viegli attēli. Ievadiet lapas adresi. Programma trīs reizes no mūsu servera izmēra laiku līdz pirmajam baitam (TTFB) un ņem vidējo skaitli, pārbauda, vai HTML tiek sūtīts saspiests (gzip, Brotli vai zstd), saskaita attēlus bez width un height un pārbauda, vai svarīgākais attēls lapas augšā netiek ielādēts ar loading="lazy". Ievērojiet: tas ir mērījums no vienas vietas, nevis Jūsu apmeklētāju mērījums. Nav savas vietnes? Izmantojiet www.wikipedia.org.

Uzdevums D4.3: Jūsu Core Web Vitals. Palaidiet PageSpeed Insights savai sākumlapai un vienai citai svarīgai lapai, vispirms cilnē Mobile. Katrai lapai pierakstiet: vai ir lauka dati (lapai vai visai vietnei), LCP, INP un CLS no lauka datiem, Lighthouse rezultātu un elementu, ko Lighthouse norāda kā LCP elementu. Izvēlieties vienu uzlabojumu, kas, pēc Jūsu domām, dos visvairāk, un paskaidrojiet, kāpēc.

Vairāk lasīt

• web.dev, Web Vitals: https://web.dev/articles/vitals
• web.dev, Largest Contentful Paint (LCP): https://web.dev/articles/lcp
• web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
• web.dev, Cumulative Layout Shift (CLS): https://web.dev/articles/cls
• web.dev, Time to First Byte (TTFB): https://web.dev/articles/ttfb
• web.dev, Browser-level image lazy loading: https://web.dev/articles/browser-level-image-lazy-loading
• Google Search Central, Understanding page experience in Google Search results: https://developers.google.com/search/docs/appearance/page-experience
• PageSpeed Insights, About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
• Search Console Help, Core Web Vitals report: https://support.google.com/webmasters/answer/9205520