Sivuk Ehi Tys — Nettisivun rakentaminen siten, että | sivukehitys.com
independent recordsivukehitys.comindependent reference record
Sivuk Ehi Tys — Nettisivun rakentaminen siten, että | sivukehitys.com

Näin teet nopean verkkosivun

Mittaus ensin: Lighthouse ajaa mobiilitestin noin 1,6 Mbit/s yhteydellä ja 150 ms viiveellä — kotiwifin luvut eivät kerro mitään.

Kolme rajaa hallussa: LCP 2,5 s, INP 200 ms ja CLS 0,1, kaikki mitattuna 75. prosenttiilista todellisia latauksia.

Paino kuriin: AVIF on noin 50 % ja WebP noin 30 % JPEG:iä pienempi samalla silmämääräisellä laadulla.

Näin rakennat nopean sivun: kuusi vaihetta

Työ etenee mittauksesta rakenteeseen, kuviin ja välimuistiin — ja päättyy uuteen mittaukseen.

Ensimmäinen sääntö: älä optimoi arvailemalla. Aja ensin Lighthouse mobiiliprofiililla, joka simuloi hidasta 4G-yhteyttä noin 1,6 Mbit/s nopeudella, 150 millisekunnin viiveellä ja nelinkertaisella prosessorin hidastuksella. Kotiverkon nopea wifi ei näy tuloksissa, ja juuri siksi testi kertoo, miltä sivu tuntuu heikommalla laitteella.

Jokaiseen vaiheeseen liittyy yksi tarkistettava luku ja yksi tyypillinen virhe. Kun virheellä on nimi — esimerkiksi kuva ilman tilavarausta tai HTML jääneenä välimuistiin — sen etsiminen käy minuuteissa eikä päivissä.

Vaiheiden järjestys ei ole sattuma. Rakenne ratkaisee, mitä selain lataa ensin; kuvat ja fontit ratkaisevat painon; välimuisti tekee toisesta latauksesta lähes ilmaisen. Lopuksi mittaus varmistaa, että kaikki kolme rajaa — LCP 2,5 s, INP 200 ms ja CLS 0,1 — täyttyvät.

  • Vaihe 1 — Mittaa lähtötilanne (n. 30 min): aja Lighthouse mobiiliprofiililla ja kirjaa LCP, INP ja CLS. Tyypillinen virhe: testata kotiwifillä ja saada liian ruusuisia lukuja.
  • Vaihe 2 — Järjestä kriittinen sisältö (1–2 h): ylälaidan teksti ja pääkuva piirrettäväksi ilman odottavia skriptejä. Tyypillinen virhe: estävä JavaScript lykkää suurimman elementin piirtoa.
  • Vaihe 3 — Optimoi kuvat (1–3 h kuvamäärästä riippuen): muunna AVIF- tai WebP-muotoon ja skaalaa näyttökokoon. Tyypillinen virhe: kymmenen 200 kt:n kuvaa eli 2 Mt, joka kestää noin 10 sekuntia hitaalla 4G-yhteydellä.
  • Vaihe 4 — Hallitse fontit (n. 30 min): pidä kirjasinten tiedostopaino samassa budjetissa kuin kuvat ja varaa teksteille tilat. Tyypillinen virhe: myöhään latautuva fontti vaihtaa tekstin ja aiheuttaa CLS-hyppäyksen.
  • Vaihe 5 — Aseta välimuisti (n. 30 min): staattiset tiedostot vuodeksi arvolla max-age=31536000, HTML arvolla max-age=0, must-revalidate. Tyypillinen virhe: HTML jää välimuistiin eikä uusi julkaisu näy.
  • Vaihe 6 — Varmista mittauksella (n. 30 min): aja testi uudelleen ja tarkista, että rajan alle mahtuu 75 % latauksista. Tyypillinen virhe: katsotaan vain yhtä onnistunutta ajoa.

Kolme rajaa, jotka ratkaisevat arvostelun

LCP kertoo latausnopeuden, INP reagointinopeuden ja CLS visuaalisen vakauden.

LCP eli suurimman sisällön piirtoaika mittaa hetkeä, jolloin sivun suurin näkyvä elementti on piirretty ruudulle — usein kyseessä on pääkuva tai pääotsikko. Raja on 2,5 sekuntia, ja se täyttyy vasta, kun vähintään 75 prosenttia sivun latauksista jää sen alle.

INP korvasi aiemman FID-mittarin. FID katsoi vain ensimmäistä vuorovaikutusta, mutta INP mittaa koko istunnon — tyypillisesti noin 5–10 sekunnin — kaikki vuorovaikutukset. Raja on 200 millisekuntia: yksi 180 millisekunnin klikkausviive alittaa sen, vaikka yksikään klikkaus ei yksinään näyttäisi hidasta.

CLS kertoo, kuinka paljon sisältö siirtyy sivun avautuessa. Luku on kahden kertoimen tulo: vaikutuskerroin kertoo liikkuvan osuuden näkymästä ja etäisyyskerroin siirtymän pituuden. Esimerkki: 1000 pikseliä korkea mainosalue kutistuu 400 pikselistä 100 pikseliin — vaikutuskerroin 1,0, etäisyyskerroin 300/1000 eli 0,3, joten CLS on 0,3 ja sivu hylätään rajan 0,1 ylittämisestä.

Kymmenen 200 kilotavun kuvaa maksaa noin kymmenen sekuntia hitaalla 4G-yhteydellä — optimointi alkaa painosta, ei koodista.
INP ei katso yhtä klikkausta vaan koko istunnon: yksi 180 millisekunnin viive mahtuu rajan alle.

Vaiheet numeroituna

Laske latausaika ennen ensimmäistä optimointia

Kilotavut muuttuvat sekunneiksi suoraan yhteyden nopeudesta.

Hitaalla 4G-yhteydellä data liikkuu noin 1,6 Mbit/s. Kymmenen 200 kilotavun kuvaa on 2 megatavua, mikä tarkoittaa noin kymmentä sekuntia pelkkää kuvien latausta — ilman että HTML, tyylit tai skriptit ovat vielä mukana laskussa.

Sama lasku toimii toiseenkin suuntaan: yksi 800 kilotavun kuva vie yhtä paljon kaistaa kuin viisi 160 kilotavun kuvaa. Jos sivun LCP-elementti on 800 kilotavun hero-kuva, pelkkä sen lataus vie noin 4 sekuntia — enemmän kuin koko 2,5 sekunnin budjetti.

Tämän vuoksi kuvien optimointi on yleensä halvin ensimmäinen muutos: se ei vaadi rakenteen muuttamista, ja hyöty näkyy suoraan LCP-luvussa. Kun paino on laskettu auki, optimoinnin järjestys on ilmeinen.

Kuvat ja fontit pienemmiksi ilman näkyvää eroa

AVIF ja WebP säilyttävät silmämääräisen laadun murto-osalla painosta.

Samalla silmämääräisellä laadulla AVIF-tiedosto on noin 50 prosenttia pienempi kuin JPEG ja WebP noin 30 prosenttia pienempi. Käytännössä 200 kilotavun JPEG vastaa laadultaan noin 140 kilotavun WebP:tä tai noin 100 kilotavun AVIF:ia.

Toinen puoli on tilan varaaminen. Kun kuvan tai mainosalueen korkeus on merkitty sivun rakenteeseen jo ennen latausta, sisältö ei hyppäydä avautuessa. Ilman varausta 1000 pikselin alueen kutistuminen 400 pikselistä 100 pikseliin antaa CLS-arvoksi 0,3 — kolminkertaisesti yli rajan 0,1.

Fontit ovat kuormana samanlaisia kuin kuvat: staattisia tiedostoja, joiden kilotavut lasketaan samaan 1,6 Mbit/s budjettiin. Myöhään latautuva fontti voi myös vaihtaa tekstin asettelun jälkeen, mikä näkyy CLS-lukemana. Tarkemmat esimerkit ja laskukaavat ovat sivulla Kuvien ja fonttien optimointi.

Välimuisti tekee toisesta latauksesta lähes ilmaisen

Staattiset tiedostot vuoteen välimuistiin, HTML tarkistamaan joka käynnille.

CSS, JavaScript, kuvat ja fontit voi antaa selaimen välimuistiin koko vuodeksi: Cache-Control: public, max-age=31536000. Palaava kävijä lataa nämä tiedostot omasta laitteestaan, eikä hitaalla yhteydellä ole enää väliä.

Itse HTML-sivu merkitään päinvastoin: max-age=0, must-revalidate. Silloin selain tarkistaa aina palvelimelta, onko uutta versiota, ja juuri julkaistu muutos näkyy heti — raskas kuorma tulee silti edelleen välimuistista.

Varmenne ei ole osa nopeutta, mutta se on osa julkaisua: Let's Encrypt -varmenne on voimassa 90 päivää, ja automaattinen uusitus käynnistyy, kun vanhentumiseen on alle 30 päivää. Kun automaatio on päällä, uusimista ei tarvitse muistuttaa käsin. Julkaisun kaikki vaiheet numeroineen löytyvät omalta sivultaan.

Rajat ja asetukset

Core Web Vitals -rajat ja keskeiset asetukset yhdessä taulukossa.
Mittari tai asetusRaja tai suositusMiten se varmistetaan
LCPenintään 2,5 s75. prosenttiili todellisista latauksista
INPenintään 200 mskoko istunnon (5–10 s) vuorovaikutukset
CLSenintään 0,1vaikutuskerroin × etäisyyskerroin
Simuloitu testiyhteys1,6 Mbit/s, 150 ms viiveLighthousen mobiilitesti, 4× CPU-hidastus
Kuvamuoto AVIFnoin 50 % JPEG:iä pienempisama silmämääräinen laatu
Kuvamuoto WebPnoin 30 % JPEG:iä pienempisama silmämääräinen laatu
Staattisten tiedostojen välimuisti31 536 000 s (1 vuosi)Cache-Control: public, max-age=31536000
HTML:n välimuisti0 s, must-revalidateuusi julkaisu näkyy heti
Core Web Vitals -rajat ja keskeiset asetukset yhdessä taulukossa.

Luvut kuvina

Kaaviot on piirretty oppaan lukujen pohjalta: yhteyden nopeus 1,6 Mbit/s, muotojen kokoerot ja välimuistin voimassaolo.

LCPINPCLS75. prosenttiili
The key terms of this guide, drawn to one scale

Lähteet ja tarkistus

Lähteinä on käytetty Core Web Vitals- ja Lighthouse-dokumentaatiota sekä Let's Encryptin varmennekäytäntöä — kaikki luvut ovat julkisesti tarkistettavissa.