Siirry suoraan sisältöön

Evästeasetukset

Valitse, mitä evästetyyppejä sallit. Voit muuttaa valintaasi milloin tahansa jokaisen sivun alareunassa olevasta kohdasta Evästeasetukset. Tietosuojaseloste

Välttämättömät

Aina käytössä

Tarvitaan sisäänkirjautumiseen, ostoskorin säilyttämiseen ja valintojesi muistamiseen. Nämä ovat aina käytössä.

Mitkä evästeet?
  • weboke_sessie, weboke_klant, weboke_remember: istuntosi ja sisäänkirjautuneena pysyminen
  • weboke_basket: ostoskorisi
  • wkBtwIncl: hintojen näyttäminen verollisina tai verottomina
  • wok_cookies: evästevalintasi, 12 kuukautta

Mittaa, mikä mainos johtaa käyntiin tai tilaukseen, jotta emme maksa mainoksista, joista ei ole hyötyä.

Mitkä evästeet?
  • Google Ads Google Tag Managerin kautta (_gcl_au, _gcl_aw), enintään 90 päivää
  • OpenAI Ads, mainokset ChatGPT-palvelussa
  • wok_aff: minkä kumppanin kautta tulit meille (kumppaniohjelma), 60 päivää

4,6

Maa ja kieli

Jokaisella maalla on oma sivustonsa, jossa on kyseisen maan hinnat ja ALV.

Näytä

Core Web Vitals: LCP, INP ja CLS

Moduuli 4: Nopeus, mobiili ja https · Lukuaika: 13 minuuttia

Oppimistavoite: Tämän oppitunnin jälkeen osaat selittää kolme Core Web Vitals -mittaria ja niiden raja-arvot, kertoa kenttädatan ja laboratoriodatan eron, lukea PageSpeed Insightsin mittaustuloksen, korjata huonon tuloksen tärkeimmät syyt ja arvioida rehellisesti, kuinka paljon nopeus painaa hakutuloksissa.

Keskeiset käsitteet: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75. persentiili, kenttädata (CrUX), laboratoriodata (Lighthouse), PageSpeed Insights, Search Consolen Core Web Vitals -raportti, TTFB, pakkaus, kuvien width ja height, loading="lazy", sivukokemus

Nopeus kolmena lukuna

”Onko sivustoni nopea?” on epämääräinen kysymys. Google ja Chromen kehittäjät ovat tehneet siitä kolme mitattavaa kysymystä, Core Web Vitals -mittarit:

MittariKysymysHyväKaipaa parannustaHuono
LCP, Largest Contentful PaintKuinka nopeasti suurin sisältöosa näkyy ruudulla?enintään 2,5 s2,5-4 syli 4 s
INP, Interaction to Next PaintKuinka nopeasti sivu reagoi, kun klikkaat, napautat tai kirjoitat?enintään 200 ms200-500 msyli 500 ms
CLS, Cumulative Layout ShiftKuinka paljon sivu hyppii latautuessaan?enintään 0,10,1-0,25yli 0,25

Muutama asia, jotka kannattaa ymmärtää hyvin:

  • LCP mittaa hetkeä, jolloin suurin näkyvä elementti ilmestyy. Se on yleensä iso kuva sivun yläosassa (niin sanottu hero-kuva) tai suuri tekstilohko. Bloemenatelier Lotten sivustolla se on kotisivun kukka-asetelman kuva.
  • INP tarkastelee kaikkia käynnin aikaisia klikkauksia, napautuksia ja näppäinpainalluksia ja raportoi (lähes) hitaimman reaktion. INP korvasi 12. maaliskuuta 2024 vanhemman mittarin FID (First Input Delay), joka katsoi vain ensimmäistä klikkausta ja vain odotusaikaa ennen käsittelyä. Jos vanhassa artikkelissa puhutaan FID:stä, tieto on vanhentunut.
  • CLS ei ole aika vaan yksikötön pistemäärä. Se kasvaa, jos asiat siirtyvät lukemisen aikana: aiot napauttaa painiketta, ja juuri silloin yläpuolelle ilmestyy banneri, jolloin napautatkin jotain muuta.

75. persentiili

Sivu ”läpäisee” Core Web Vitals -mittarit, kun 75 prosenttia käynneistä saa hyvän tuloksen kaikissa kolmessa, erikseen mitattuna mobiilissa ja tietokoneella. Tätä kutsutaan 75. persentiiliksi. Se tarkoittaa, että ratkaisevaa ei ole oma nopea tietokoneesi valokuituyhteydellä vaan useimpien kävijöiden kokemus, myös niiden, joilla on vanhempi puhelin 4G-yhteydellä.

Kenttädata ja laboratoriodata

Mittauksia on kahdenlaisia, ja ne antavat usein eri lukuja.

  • Kenttädata tulee oikeilta kävijöiltä. Chrome kerää (sen sallivilta käyttäjiltä) nimettömästi tietoa sivujen nopeudesta Chrome User Experience Report (CrUX) -raporttiin. PageSpeed Insights näyttää viimeisten 28 päivän kenttädatan. Search Consolen Core Web Vitals -raportti käyttää samaa lähdettä. Jos sivullasi on liian vähän kävijöitä, PageSpeed Insights näyttää koko sivustosi (niin sanotun originin) luvut, ja jos niitäkin on liian vähän, kenttädataa ei ole lainkaan.
  • Laboratoriodata tulee Lighthousen simuloidusta testistä: yksi lataus jäljitellyllä keskitason puhelimella ja yhteydellä. Lighthouse ei pysty mittaamaan INP:tä (kukaan ei klikkaa), joten se antaa muita lukuja, kuten Total Blocking Time, jotka antavat kuitenkin vihjeen INP:stä.

Arvioinnissa ratkaisee kenttädata. Laboratoriodatasta on hyötyä syiden etsimisessä ja kun haluat korjauksen jälkeen nähdä heti, auttoiko se, odottamatta 28 päivää.

Kuinka paljon se painaa?

Tätä liioitellaan paljon. Näin Google itse kertoo sivukokemusta käsittelevässä dokumentaatiossaan:

  • ”Core Web Vitals are used by our ranking systems”: ne siis vaikuttavat järjestykseen.
  • Erillistä ”sivukokemussignaalia” ei ole. Googlen mukaan hyvän sivukokemuksen muut osat (https, ei tunkeilevia ponnahdusikkunoita, mobiilikäytettävyys) eivät suoraan nosta sinua ylemmäs, mutta ne tekevät sivustostasi miellyttävämmän.
  • ”Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (Google pyrkii aina näyttämään osuvimman sisällön, vaikka sivukokemus olisi heikko.) Hidas sivu, jolla on paras vastaus, voi siis hyvin olla kärjessä.
  • Täydellisen tuloksen tavoittelu pelkästään hakukoneoptimoinnin vuoksi ei Googlen mukaan ”ehkä ole paras tapa käyttää aikaasi”.

Johtopäätös: huolehdi, että olet vihreällä tai vähintään oranssilla alueella, ennen kaikkea siksi, että kävijät luopuvat hitaasta tai hyppivästä sivusta. Lighthousen pisteiden jahtaaminen 90:stä 100:aan ei juuri näy hakutuloksissa.

Syyt, joihin voit itse vaikuttaa

Hidas ensimmäinen vastaus (TTFB)

Kaikki alkaa hetkestä, jolloin HTML:n ensimmäinen tavu saapuu, eli Time to First Byte -ajasta. TTFB ei itse ole Core Web Vitals -mittari, mutta hidas TTFB tekee hyvästä LCP:stä lähes mahdottoman. web.dev antaa ohjearvoksi: hyvä on enintään 0,8 sekuntia, huono yli 1,8 sekuntia. Syitä web.devin mukaan ovat webhotellin liian vähäinen laskentateho, välimuistin puuttuminen (jokainen sivu rakennetaan aina uudelleen, tyypillistä WordPressissä ilman välimuistilisäosaa), uudelleenohjaukset (oppitunti 4.1) ja kaukana sijaitseva palvelin ilman CDN:ää.

Pakkaus kuuluu asiaan: palvelimen pitäisi lähettää HTML, CSS ja JavaScript pakattuina gzipillä tai Brotlilla. Sen näkee otsakerivistä Content-Encoding: gzip tai br. Lähes kaikki webhotellit tekevät tämän oletuksena, mutta väärä asetus tai vanha palvelin voi kytkeä sen pois.

Kuvat

Kuvat ovat yleisin syy huonoon LCP:hen ja CLS:ään:

  1. Liian suuret. 4 000 pikseliä leveä ja 5 Mt:n kuva 800 pikselin alueelle. Pienennä kuva ennen lataamista ja käytä modernia muotoa, kuten WebP tai AVIF.
  2. Ei leveyttä ja korkeutta. Ilman width- ja height-määritteitä selain ei tiedä, kuinka paljon tilaa kuva tarvitsee, ja kuvan alla oleva teksti hyppää, kun kuva latautuu. web.dev suosittelee lisäämään width- ja height-määritteet jokaiseen <img>-elementtiin:

    <img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">
  3. Tärkeimmän kuvan laiska lataus. loading="lazy" lataa kuvan vasta, kun se tulee näkyviin. Se sopii hyvin alempana oleville kuville, mutta web.dev sanoo selvästi: älä lataa laiskasti kuvia, jotka näkyvät jo sivua avattaessa, ja varsinkaan LCP-kuvaa. Muuten selain viivyttää juuri sitä kuvaa, joka ratkaisee LCP:si.

Hyppivä sisältö ja hitaat reaktiot

Muita CLS:n syitä web.devin mukaan ovat fontit, joiden koko muuttuu latauksen aikana, mainokset ja upotetut widgetit, jotka kasvattavat itseään, sekä sisältö, joka lisätään myöhemmin olemassa olevan sisällön yläpuolelle (kuten evästepalkki, joka työntää sivua alaspäin sen sijaan, että se olisi sivun päällä). Huono INP johtuu lähes aina liiasta JavaScriptistä: raskaista teemoista, kuvakaruselleista, chat-widgeteistä ja kolmansien osapuolten seurantakoodeista. Tarkastele jokaista lisäosaa ja upotettua palvelua kriittisesti; tässä vähemmän on todella enemmän.

Käytännössä: mittaus PageSpeed Insightsilla

Mene osoitteeseen pagespeed.web.dev, kirjoita kotisivusi osoite ja valitse Analyze. Saat kaksi välilehteä (Mobile ja Desktop). Ylimpänä on Core Web Vitals -arvio kenttädatan perusteella, jos sitä on. Sen alla on Lighthouse-testi pistemäärineen ja Diagnostics-luettelo konkreettisine huomioineen, esimerkiksi tarpeettoman suurista kuvista tai laiskasti ladattavasta LCP-kuvasta (tarkat nimet muuttuvat Lighthousen uusissa versioissa). Aloita Mobile-välilehdestä: siellä tulokset ovat yleensä huonompia, ja Google katsoo ensin mobiiliversiota (oppitunti 4.2).

Jos sivustosi on Search Consolessa (moduuli 2), katso myös kohta Experience, Core Web Vitals. Siellä näet samankaltaisten sivujen ryhmät tiloineen, myös sivuille, joita et ole itse testannut.

AI Builderilla tehty sivusto lisää leveyden ja korkeuden kuviin, joiden koko tiedetään, lataa sivun ensimmäisen kuvan heti ja etusijalla (fetchpriority="high") ja muut laiskasti, ja tekee julkaisun yhteydessä suurista kuvista 800 pikseliä leveän version. WordPressissä eniten auttavat välimuistilisäosa ja kuvien pienentäminen; WordPress-kurssin moduuli 6 käsittelee tätä tarkemmin. Muissa sivustotyökaluissa ja webhotelleissa toimitaan samaan tapaan: painikkeet ovat erilaisia, mutta syyt ovat samat.

Yhteenveto

  • Core Web Vitals -mittarit ovat LCP (hyvä enintään 2,5 s), INP (hyvä enintään 200 ms, maaliskuusta 2024 FID:n tilalla) ja CLS (hyvä enintään 0,1), ja ne mitataan 75. persentiilillä laitetyypeittäin.
  • Kenttädata (CrUX, 28 päivää) ratkaisee arvion; laboratoriodata (Lighthouse) auttaa löytämään syyt.
  • Google käyttää Core Web Vitals -mittareita järjestyksessä, mutta osuvuus menee edelle: täydellinen tulos ei ole itsetarkoitus.
  • Suurin hyöty: nopea palvelinvastaus välimuistilla ja pakkauksella, pienet kuvat width- ja height-määritteillä, tärkeimmän kuvan lataus ilman laiskaa latausta ja vähemmän kolmansien osapuolten JavaScriptiä.

Tietovisa

1. Mikä on hyvän LCP:n raja?



2. Mikä mittari korvasi FID:n Core Web Vitals -mittarina?



3. PageSpeed Insights näyttää hyvän Lighthouse-pistemäärän, mutta kenttädata on huono. Kumpi ratkaisee Core Web Vitals -arvion?



4. Latauksen aikana teksti hyppää jatkuvasti alaspäin, kun kuvat saapuvat. Mikä auttaa eniten?



5. Mitä Google sanoo sivukokemuksen merkityksestä hakutulosten järjestykselle?



Tehtävä

Tehtävä A4.3: Nopea vastaus ja kevyet kuvat. Kirjoita sivun osoite. Ohjelma mittaa palvelimeltamme kolme kertaa ajan ensimmäiseen tavuun (TTFB) ja ottaa keskimmäisen luvun, tarkistaa, lähetetäänkö HTML pakattuna (gzip, Brotli tai zstd), laskee kuvat, joilta puuttuvat width ja height, ja tarkistaa, ettei sivun yläosan tärkeintä kuvaa ladata loading="lazy"-määritteellä. Huomaa: tämä on mittaus yhdestä paikasta, ei kävijöidesi mittaus. Eikö sinulla ole omaa sivustoa? Käytä osoitetta www.wikipedia.org.

Tehtävä A4.3: Nopea vastaus ja kevyet kuvat


Sitä, mitä kirjoitat ja mitä löydämme, ei tallenneta. Selaimesi muistaa vastauksesi ja sen, oletko suorittanut tehtävän. Jos olet kirjautunut sisään, tallennamme kohtaan Omat kurssit vain sen, että tehtävä oli (lähes) oikein; voit poistaa sen myös sieltä.

Tehtävä D4.3: Sivustosi Core Web Vitals. Aja PageSpeed Insights kotisivullesi ja yhdelle muulle tärkeälle sivulle, ensin Mobile-välilehdellä. Kirjaa jokaisesta sivusta: onko kenttädataa (sivulta vai koko sivustolta), kenttädatan LCP, INP ja CLS, Lighthouse-pistemäärä sekä elementti, jonka Lighthouse ilmoittaa LCP-elementiksi. Valitse yksi parannus, joka on mielestäsi hyödyllisin, ja perustele valintasi.

Tehtävä D4.3: Sivustosi Core Web Vitals

Tämän tehtävän teet itse, kukaan ei tarkista sitä. Merkitse tekemäsi kohdat ja merkitse tehtävä tehdyksi.





Merkintäsi ja muistiinpanosi pysyvät vain tässä selaimessa, emme lähetä niitä minnekään. Jos olet kirjautunut sisään, tallennamme kohtaan Omat kurssit vain sen, että olet tehnyt tehtävän.

Lisälukemista

Hetkinen…

Määritä verkkotunnuksesi

Määritä kullekin verkkotunnukselle nimipalvelimet, liitos webhotelliin ja se, kuka tulee omistajaksi.

Ladataan verkkotunnuksia…