Core Web Vitals: mikä oikeasti liikuttaa lukuja
Core Web Vitals ovat kolme kenttämittausta siitä miltä sivu tuntuu: kauanko kestää ennen kuin pääsisältö ilmestyy, kuinka paljon se hyppii latauksen aikana, ja kuinka nopeasti sivu reagoi syötteeseen.
Tämä opas käy läpi mitä kukin mittari mittaa, konkreettiset syyt huonojen arvojen taustalla, ja korjaukset jotka liikuttavat kenttädataa eivätkä pelkkiä labrapisteitä.
Mitä kolme mittaria mittaavat#
Kullakin on «hyvä»-kynnys ja pieni joukko tavanomaisia syitä. Huomaa että sijoituksiin vaikuttava luku on kenttädata oikeilta kävijöiltä, ei pisteet läppäriltäsi.
| Mittari | Hyvä | Mittaa | Tavanomainen syy huonoon arvoon |
|---|---|---|---|
| LCP | Alle 2,5 s | Aika suurimman näkyvän elementin piirtymiseen | Optimoimaton pääkuva, hidas palvelin, estävä CSS |
| CLS | Alle 0,1 | Kuinka paljon asettelu hyppii latauksessa | Kuvat ilman mittoja, työnnetyt bannerit, myöhään ladatut kirjasimet |
| INP | Alle 200 ms | Vasteaika käyttäjän toimintoon | Pitkät JavaScript-tehtävät jotka estävät päälangan |
Labratyökalut mittaavat yhden latauksen yhdellä koneella. Kenttädata on 75. prosenttipiste oikeista käynneistä, mukaan lukien vanhat puhelimet huonoissa verkoissa — juuri ne kävijät jotka poistuvat nopeimmin.
LCP:n korjaaminen#
LCP on lähes aina kuva tai otsikko jonka jokin muu estää. Käy kohdat läpi järjestyksessä; kaksi ensimmäistä ratkaisee useimmat sivustot.
- Selvitä mikä elementti oikeasti on LCP-elementti kenttädatassa. Väärän kuvan optimointi on yleisin hukkatyö.
- Älä koskaan lataa LCP-kuvaa viivästetysti. Anna sille sen sijaan fetchpriority="high".
- Tarjoile se modernissa formaatissa siinä koossa jossa se näytetään, srcset-määritteellä pienemmille näytöille.
- Esilataa LCP-tekstin kirjasin ja käytä font-display: swap.
- Poista estävä CSS ja JavaScript head-osiosta; upota kriittinen CSS jos sivu on riittävän pieni.
- Laske Time to First Byte -arvoa välimuistilla ja CDN:llä — mikään käyttöliittymätyö ei korvaa hidasta palvelinta.
- Karsi kolmannen osapuolen skriptit kriittiseltä polulta. Kukin on DNS-haku, yhteys ja arvaamaton tiedosto.
CLS:n korjaaminen#
Hyppivä asettelu on lähes täysin vältettävissä ja korjaukset ovat halpoja. Se on myös mittari jonka kävijät tuntevat voimakkaimmin — se saa ihmiset napauttamaan väärää asiaa.
- Aseta width ja height jokaiseen kuvaan ja videoon, jotta selain varaa tilan.
- Varaa tila mainoksille, upotuksille ja kehyksille säiliöllä jolla on kiinteä kuvasuhde.
- Älä koskaan työnnä sisältöä olemassa olevan yläpuolelle latauksen jälkeen — evästebanneri kuuluu alas tai peittokerrokseksi.
- Sovita varakirjasimen mitat verkkokirjasimeen tai käytä size-adjust, jottei vaihto järjestä sivua uudelleen.
- Vältä asetteluominaisuuksien animointia. Animoi transform ja opacity, jotka eivät pakota uudelleenlaskentaa.
- Anna dynaamisesti ladatuille osioille min-height, jotteivät ne aukea nollasta.
INP:n korjaaminen#
INP korvasi First Input Delayn ja on vaikeampi, koska se mittaa jokaista vuorovaikutusta käynnin aikana eikä vain ensimmäistä. Huono INP johtuu lähes aina liiasta JavaScriptistä päälangalla.
| Syy | Korjaus |
|---|---|
| Iso paketti käsiteltävänä latauksessa | Pilko koodi; lataa vain se mitä sivu käyttää |
| Pitkät tehtävät yli 50 ms | Pilko työ ja palauta lanka |
| Kalliit tapahtumakäsittelijät | Debounce ja siirrä raskas työ pois vuorovaikutuspolulta |
| Raskaat kolmannen osapuolen merkinnät | Lataa vuorovaikutuksen jälkeen tai poista — tarkista mitä kukin tuo |
| Iso DOM, yli 10 000 solmua | Virtualisoi pitkät listat; yksinkertaista syvää sisäkkäisyyttä |
| Vuorottelevat asettelun luvut ja kirjoitukset | Ryhmittele luvut ja kirjoitukset vuorottelun sijaan |
Sisältösivustoilla arvokkain INP-toimenpide on yleensä JavaScriptin poistaminen sen optimoinnin sijaan. Kysy mitä kukin skripti tuo; tunnistehallinnat keräävät skriptejä joiden lisäämistä kukaan ei muista.
Usein kysytyt kysymykset
Kuinka paljon Core Web Vitals vaikuttaa sijoitukseen?
Ne ovat todellinen mutta maltillinen signaali, joka toimii enemmän tasapelin ratkaisijana kuin osuvuuden korvaajana. Nopea sivu väärästä aiheesta ei voita hitaampaa joka vastaa kysymykseen. Vahvempi peruste niiden korjaamiseen on käyttäytyminen: hitaat ja hyppivät sivut menettävät kävijöitä ennen kuin sijoitus edes tulee peliin.
Miksi minulla on hyvä Lighthouse-tulos ja huono kenttädata?
Koska Lighthouse simuloi yhden latauksen sinun koneellasi ja yhteydelläsi, kun taas kenttädata on 75. prosenttipiste oikeista käynneistä — mukaan lukien kolme vuotta vanhat puhelimet ruuhkaisissa mobiiliverkoissa. Kun nämä kaksi ovat ristiriidassa, kenttädata ratkaisee. Käytä labratyökaluja diagnosointiin, ei pisteytykseen.
Pitääkö kaikki kolme mittaria korjata?
Korjaa ne jotka pettävät, siinä järjestyksessä miten kävijät kokevat ne. CLS on yleensä halvin korjata ja käyttäjälle ärsyttävin, joten se on hyvä aloituspiste. LCP:llä on suurin vaikutus siihen odottavatko ihmiset. INP merkitsee eniten vuorovaikutteisilla sivustoilla ja vähiten staattisissa artikkeleissa.
Kauanko parannusten näkymiseen menee?
Kenttädata on liukuva 28 päivän ikkuna, joten merkittävä liike vie noin neljä viikkoa siitä kun korjaus on tavoittanut kaikki kävijät. Älä arvioi muutosta kolmen päivän jälkeen. Tarkista sen sijaan labra-arvot heti varmistaaksesi että korjaus teki sen mitä odotit.
core web vitalslcpclsinpsivun nopeusverkkosuorituskyky
