Core Web Vitals: LCP, INP in CLS

Modul 4: Hitrost, mobilne naprave in https · Čas branja: 13 min

Učni cilj: Po tej lekciji boste znali razložiti tri Core Web Vitals in njihove mejne vrednosti, poimenovati razliko med terenskimi in laboratorijskimi podatki, prebrati meritev s PageSpeed Insights, odpraviti najpomembnejše vzroke za slab rezultat in pošteno oceniti, koliko hitrost šteje v rezultatih iskanja.

Ključni pojmi: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75. percentil, terenski podatki (CrUX), laboratorijski podatki (Lighthouse), PageSpeed Insights, poročilo Core Web Vitals v Search Console, TTFB, stiskanje, width in height pri slikah, loading="lazy", uporabniška izkušnja strani

Hitrost v treh številkah

»Ali je moje spletno mesto hitro?« je ohlapno vprašanje. Google in ustvarjalci brskalnika Chrome so iz njega naredili tri merljiva vprašanja, Core Web Vitals:

Nekaj stvari, ki jih je dobro razumeti:

• LCP meri trenutek, ko se prikaže največji vidni element. To je običajno velika fotografija na vrhu (t. i. »hero«) ali velik blok besedila. Pri Bloemenatelier Lotte je to fotografija cvetličnega aranžmaja na domači strani.
• INP upošteva vse klike, tapove in pritiske tipk med obiskom in poroča (skoraj) najpočasnejši odziv. INP je 12. marca 2024 nadomestil starejšo meritev FID (First Input Delay), ki je upoštevala le prvi klik in le čakanje pred obdelavo. Če v starem članku naletite na FID, je ta podatek zastarel.
• CLS ni čas, ampak ocena brez enote. Viša se, ko se stvari premikajo, medtem ko berete: želite tapniti gumb, v tistem trenutku pa se nad njim pojavi pasica in tapnete nekaj drugega.

75. percentil

Stran »izpolni« Core Web Vitals, če ima 75 odstotkov obiskov dober rezultat pri vseh treh, ločeno izmerjeno za mobilne naprave in namizne računalnike. Temu pravimo 75. percentil. To pomeni: ne šteje Vaš hiter računalnik na optičnem priključku, ampak izkušnja večine obiskovalcev, tudi tistih s starejšim telefonom na omrežju 4G.

Terenski in laboratorijski podatki

Obstajata dve vrsti meritev, ki pogosto dajeta različne številke.

• Terenski podatki prihajajo od resničnih obiskovalcev. Chrome (pri uporabnikih, ki to dovolijo) anonimno zbira, kako hitre so bile strani, v poročilu Chrome User Experience Report (CrUX). PageSpeed Insights prikazuje terenske podatke zadnjih 28 dni. Poročilo Core Web Vitals v Search Console uporablja isti vir. Če ima Vaša stran premalo obiskovalcev, PageSpeed Insights prikaže številke za celotno spletno mesto (»origin«), če jih ima premalo tudi to, terenskih podatkov ni.
• Laboratorijski podatki prihajajo iz simuliranega testa z orodjem Lighthouse: eno nalaganje na posnemanem povprečnem telefonu in povezavi. Lighthouse ne more meriti INP (nihče ne klika), zato prikaže druge številke, na primer Total Blocking Time, ki pa so namig za INP.

Za oceno štejejo terenski podatki. Laboratorijski podatki so uporabni za iskanje vzrokov in za takojšnje preverjanje, ali izboljšava deluje, ne da bi čakali 28 dni.

Koliko to šteje?

Tu se veliko pretirava. Kaj o tem pravi Google sam v dokumentaciji o uporabniški izkušnji strani:

• »Core Web Vitals are used by our ranking systems«: torej štejejo.
• Ločenega »signala uporabniške izkušnje strani« ni. Drugi deli dobre izkušnje (https, brez vsiljivih pojavnih oken, uporabnost na mobilnih napravah) Vam po Googlovih besedah ne pomagajo neposredno do višjega mesta, vendar naredijo Vaše spletno mesto prijetnejše.
• »Google Search always seeks to show the most relevant content, even if the page experience is sub-par.« Počasna stran z najboljšim odgovorom je torej lahko čisto na vrhu.
• Doseganje popolnega rezultata zgolj zaradi SEO po Googlovem mnenju »morda ni najboljša poraba Vašega časa«.

Zaključek: poskrbite, da ste v zelenem ali vsaj oranžnem območju, predvsem zato, ker obiskovalci počasno ali poskakujočo stran zapustijo. Lov s 90 na 100 točk v Lighthouse v rezultatih iskanja prinese malo.

Vzroki, ki jih lahko odpravite sami

Počasen prvi odziv (TTFB)

Vse se začne s trenutkom, ko prispe prvi bajt HTML, s Time to First Byte. TTFB sam ni Core Web Vital, vendar počasen TTFB skoraj onemogoči dober LCP. web.dev navaja kot ciljno vrednost: dobro je 0,8 sekunde ali manj, slabo je več kot 1,8 sekunde. Vzroki po web.dev: premalo računske moči pri gostovanju, ni predpomnilnika (vsaka stran se gradi znova, značilno za WordPress brez vtičnika za predpomnjenje), preusmeritve (lekcija 4.1) in oddaljen strežnik brez CDN.

Sem spada tudi stiskanje: strežnik naj HTML, CSS in JavaScript pošilja stisnjene z gzip ali Brotli. To prepoznate po glavi Content-Encoding: gzip ali br. Skoraj vsako gostovanje to privzeto počne, vendar ga lahko napačna nastavitev ali star strežnik izklopi.

Slike

Slike so najpogostejši vzrok za slab LCP in CLS:

1. Prevelike. Fotografija širine 4.000 pikslov in velikosti 5 MB za okvir širine 800 pikslov. Pomanjšajte jo pred nalaganjem in uporabite sodoben format, kot sta WebP ali AVIF.

2. Brez širine in višine. Brez width in height brskalnik ne ve, koliko prostora slika potrebuje, zato se besedilo pod njo premakne, ko slika prispe. web.dev priporoča, da width in height nastavite na vsakem <img>:

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

3. Leno nalaganje najpomembnejše fotografije. loading="lazy" naloži sliko šele, ko pride v vidno polje. To je odlično za fotografije nižje na strani, vendar web.dev jasno pravi: slik, ki so ob odprtju že vidne, in zlasti slike LCP, NE nalagajte leno. Sicer brskalnik čaka prav s fotografijo, ki določa Vaš LCP.

Premikajoča se vsebina in počasni odzivi

Drugi vzroki za CLS po web.dev: pisave, ki med nalaganjem spremenijo velikost, oglasi in vdelani gradniki, ki se sami povečajo, ter vsebina, ki se pozneje vstavi nad obstoječo vsebino (na primer pasica s piškotki, ki stran potisne navzdol, namesto da bi ležala čeznjo). Slab INP je skoraj vedno posledica preveč JavaScripta: zahtevne teme, drsniki, gradniki za klepet in sledilniki tretjih oseb. Kritično preglejte vsak vtičnik in vsako vdelano storitev; manj je tu res več.

V praksi: merjenje s PageSpeed Insights

Pojdite na pagespeed.web.dev, vnesite naslov svoje domače strani in kliknite Analyze. Dobite dva zavihka (Mobile in Desktop). Na vrhu je ocena Core Web Vitals na podlagi terenskih podatkov, če ti obstajajo. Pod njo je test Lighthouse z rezultatom in seznamom »Diagnostics« s konkretnimi točkami, na primer o slikah, ki so večje od potrebnega, ali o sliki LCP, ki se nalaga leno (natančna imena se spreminjajo z novimi različicami orodja Lighthouse). Začnite pri Mobile: tam je običajno slabše, Google pa najprej gleda mobilno različico (lekcija 4.2).

Če imate svoje spletno mesto v Search Console (modul 2), poglejte tudi pod Experience, Core Web Vitals. Tam vidite skupine podobnih strani z njihovim stanjem, tudi za strani, ki jih sami niste testirali.

Spletno mesto, izdelano z AI Builder, nastavi širino in višino pri slikah, katerih velikost je znana, prvo fotografijo strani naloži takoj in prednostno (fetchpriority="high"), ostale pa leno, ob objavi pa iz velikih fotografij ustvari različico širine 800 pikslov. V WordPressu najbolj pomagata vtičnik za predpomnjenje in pomanjšanje slik; tečaj o WordPressu se temu podrobneje posveča v modulu 6. Pri drugih orodjih za izdelavo spletnih strani in ponudnikih gostovanja deluje podobno: gumbi so drugačni, vzroki pa enaki.

Povzetek

• Core Web Vitals so LCP (dobro do 2,5 s), INP (dobro do 200 ms, od marca 2024 namesto FID) in CLS (dobro do 0,1), merjeni pri 75. percentilu za vsako vrsto naprave.
• Terenski podatki (CrUX, 28 dni) določajo oceno; laboratorijski podatki (Lighthouse) pomagajo najti vzroke.
• Google uporablja Core Web Vitals pri razvrščanju, vendar ima prednost ustreznost: popoln rezultat ni sam sebi namen.
• Največji učinek: hiter odziv strežnika s predpomnilnikom in stiskanjem, majhne slike z width in height, najpomembnejša fotografija brez lenega nalaganja, manj JavaScripta tretjih oseb.

Kviz

Naloga

Naloga A4.3: Hiter odziv in lahke slike. Vnesite naslov strani. Program trikrat izmeri čas do prvega bajta (TTFB) z našega strežnika in vzame srednjo vrednost, preveri, ali se HTML pošilja stisnjen (gzip, Brotli ali zstd), prešteje slike brez width in height ter preveri, ali se najpomembnejša slika na vrhu ne nalaga z loading="lazy". Pozor: to je meritev z enega mesta, ne meritev Vaših obiskovalcev. Nimate lastnega spletnega mesta? Uporabite www.wikipedia.org.

Naloga D4.3: Vaši Core Web Vitals. Zaženite PageSpeed Insights na svoji domači strani in na eni drugi pomembni strani, najprej na Mobile. Za vsako stran si zapišite: ali obstajajo terenski podatki (za stran ali celotno spletno mesto), LCP, INP in CLS iz terenskih podatkov, rezultat Lighthouse in element, ki ga Lighthouse označi kot element LCP. Izberite eno izboljšavo, ki po Vašem mnenju prinese največ, in pojasnite, zakaj.

Za nadaljnje branje

• 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