Suorituskyvyn budjetointi tarkoittaa, että sivustolle sovitaan etukäteen ylärajat sivun painolle, JavaScriptin määrälle ja latausajoille. Raja asetetaan ennen kuin ensimmäinen kuva tai lisäosa lisätään, eikä vasta silloin, kun sivu on jo hidas. Artikkeli on tarkoitettu yrittäjälle tai kotisivujen tilaajalle, joka haluaa tietää, mitkä luvut sopivat esittelysivulle, verkkokaupalle tai kampanjasivulle. Valmiit rajat tekevät myös keskustelusta tekijän kanssa helpompaa: ”nopea sivusto” on toive, mutta ”alle 1 Mt ja LCP alle 2,5 sekuntia” on vaatimus, jonka toteutumisen voi tarkistaa.
Mitä suorituskykybudjetti käytännössä mittaa
Budjetti koostuu kahdenlaisista luvuista. Määrälliset rajat koskevat sitä, mitä selain joutuu lataamaan: sivun kokonaispainoa kilotavuina, JavaScriptin ja CSS:n määrää sekä HTTP-pyyntöjen lukumäärää. Ajoitusrajat koskevat sitä, mitä käyttäjä kokee: kuinka nopeasti pääsisältö näkyy ja kuinka nopeasti sivu reagoi napautukseen.
Ajoitusrajoille on valmis pohja Googlen Core Web Vitals -mittareissa. Hyvän tuloksen rajat ovat LCP enintään 2,5 sekuntia, INP enintään 200 millisekuntia ja CLS enintään 0,1. Mittareista kerrotaan tarkemmin artikkelissa Core Web Vitals -laatukriteereistä.
Kokenut kehittäjä seuraa kumpaakin tyyppiä. Pelkillä ajoitusrajoilla ei näe, mikä sivua hidastaa. Pelkät kilotavurajat taas eivät kerro, miltä sivu tuntuu vanhalla Android-puhelimella Kainuun maaseudulla.
Millä budjetilla mihinkin – suuntaa-antavat rajat sivustotyypeittäin
Rajat kannattaa suhteuttaa sivuston tarkoitukseen. Seuraavat luvut koskevat mobiililatausta ja pakattuja tiedostokokoja:
Yhden hengen yrityksen esittelysivu: enintään 500-800 kt koko sivu, alle 100 kt JavaScriptiä ja LCP alle 2 sekuntia.
Palveluyrityksen kotisivut, joissa on blogi: enintään 1-1,2 Mt, 150-200 kt JavaScriptiä ja LCP alle 2,5 sekuntia.
Verkkokaupan tuotesivu: enintään 1,5 Mt, 250-350 kt JavaScriptiä, LCP alle 2,5 sekuntia ja INP alle 200 ms.
Kampanjasivu: enintään 600 kt ja LCP alle 1,8 sekuntia, koska maksettu klikki on jo maksettu.
Portfoliosivu: kuville voi antaa enemmän tilaa, jopa 2 Mt, kunhan ne ladataan laiskasti ja ensimmäinen näkymä pysyy alle 800 kilotavun.
Luvut ovat lähtökohta eivätkä lakeja. HTTP Archiven mukaan tyypillinen mobiilisivu painaa nykyään reilusti yli 2 Mt, joten jo yllä mainituilla rajoilla sivusto on nopeampi kuin suurin osa verkosta.
Verkkokaupassa JavaScriptiä saa olla enemmän, koska ostoskori, maksutapojen valinta ja tuotevaihtoehdot tarvitsevat sitä. Sama määrä esittelysivulla on yleensä merkki siitä, että teema lataa ominaisuuksia, joita kukaan ei käytä.
Näin otat budjetin käyttöön vaiheittain
Ammattilainen ei aloita tavoiteluvuista. Hän aloittaa nykytilasta. Ensimmäiseksi ajetaan sivuston kolme tärkeintä sivua PageSpeed Insightsin läpi. Tavallisesti nämä ovat etusivu, suosituin palvelusivu ja yhteydenottosivu. Raportin kenttädatasta (Chrome UX Report) näkee, miten oikeat kävijät sivun kokevat, jos liikennettä on tarpeeksi.
Seuraavaksi selvitetään, mistä sivun paino koostuu. Selaimen kehittäjätyökalujen Network-välilehdellä tiedostot saa lajiteltua koon mukaan. Yleensä isoimmat ovat hero-kuva, fonttitiedostot ja kolmannen osapuolen skriptit.
Kolmannessa vaiheessa budjetti kirjataan näkyviin. WordPress-sivustolla kirjaus voi olla yksinkertainen taulukko ylläpitosopimuksen liitteenä. Kehittäjävetoisessa projektissa rajat kirjoitetaan Lighthousen budget.json-tiedostoon, jolloin Lighthouse CI hälyttää heti, kun jokin raja ylittyy.
Neljäs vaihe on se, joka yleensä unohtuu. Jokaiselle uudelle lisäykselle lasketaan hinta. Jos chat-widget vie 180 kt ja budjetissa on tilaa 50 kt, jostain muualta on karsittava tai widgetistä luovuttava.
Tyypillinen tilanne: hyvä sivusto, joka lihoo vähitellen
Paikallisen kampaamon tai tilitoimiston sivusto on julkaisuhetkellä usein ripeä, esimerkiksi 700 kt ja LCP 1,9 sekuntia. Vuoden aikana sivulle lisätään Instagram-syöte, ajanvarausupotus, chat, Meta Pixel ja kaksi uutta Google-fonttia. Mikään lisäys ei yksinään tunnu isolta.
Lopputuloksena sivu painaa 2,4 Mt, ja LCP on mobiilissa 4 sekunnin tuntumassa. Kukaan ei päättänyt hidastaa sivustoa. Kukaan ei vain valvonut sitä.
Juuri tähän budjetti on tarkoitettu. Se pakottaa valitsemaan. Instagram-syötteen voi korvata staattisella kuvalla, josta pääsee profiiliin, ja chat-widgetin voi ladata vasta, kun kävijä napauttaa sen kuvaketta.
Myytti: PageSpeed-pisteet ovat budjetti
Yleinen väärinkäsitys on, että tavoitteeksi riittää 90 pistettä PageSpeed Insightsissa. Pisteet ovat laboratoriotulos yhdestä simuloidusta latauksesta hidastetulla yhteydellä. Ne heittelevät ajosta toiseen jopa 5-10 pistettä, vaikka sivustoon ei olisi koskettu.
Pisteet eivät kerro, missä kohtaa sivu on lihonut. Sivu voi saada 92 pistettä ja silti ladata 400 kt käyttämätöntä JavaScriptiä, joka hidastaa vasta vuorovaikutusta. Budjetti sidotaan siksi mitattaviin suureisiin, kuten kilotavuihin ja millisekunteihin, eikä yhteen koostepisteeseen.
Toinen myytti on, että nopea 5G tekee budjetoinnin turhaksi. Pullonkaula on usein puhelimen suoritin, ei yhteys. Edullinen Android-puhelin käsittelee saman JavaScript-määrän moninkertaisesti hitaammin kuin uusi iPhone.
Yleisimmät virheet suorituskyvyn budjetoinnissa
Budjetti mitataan vain etusivulta. Etusivu on usein sivuston hiotuin sivu. Kävijät taas saapuvat Googlesta useimmiten blogikirjoitukseen tai tuotesivulle, jotka voivat olla kaksi kertaa raskaampia.
Kolmannen osapuolen skriptejä ei lasketa mukaan. Google Tag Managerin kautta lisätyt seurantakoodit eivät näy teeman koodissa, mutta selain lataa ne silti. Kun säiliöön kertyy kymmenkunta tagia, siitä tulee helposti sivun suurin yksittäinen kuorma. Tagien järkevästä hallinnasta kerrotaan oppaassa Google Tag Managerin käytöstä aloittelijalle.
Kuvat ladataan alkuperäisessä muodossa. Puhelimella otettu 4 Mt:n JPEG pienentyy oikeaan kokoon skaalattuna ja WebP- tai AVIF-muotoon pakattuna tyypillisesti 80-200 kilotavuun. Formaattien eroista kerrotaan tarkemmin WebP-, AVIF- ja JPEG-vertailussa.
Milloin tiukka budjetti ei ole järkevä
Kaikki sivut eivät hyödy tiukoista rajoista. Arkkitehtitoimiston tai valokuvaajan portfoliossa visuaalinen vaikutelma on koko sivun tarkoitus. Siellä on perusteltua antaa kuville enemmän tilaa ja kompensoida laiskalla latauksella ja kunnollisella CDN:llä.
Myös sisäänkirjautumisen takana olevat työkalut, kuten asiakasportaalit, joita käytetään päivittäin, kestävät raskaamman ensimmäisen latauksen. Selain välimuistittaa tiedostot, ja seuraavat käynnit ovat nopeita. Budjetti kannattaa silti asettaa, se vain on erilainen.
UKK
Paljonko suorituskykybudjetin laatiminen maksaa?
Pienelle sivustolle nykytilan mittaus ja rajojen kirjaaminen vie kokeneelta tekijältä noin 2-4 tuntia, eli tyypillisesti 150-400 €. Varsinainen optimointi on erillinen työ, ja sen laajuus riippuu siitä, kuinka paljon sivusto ylittää rajat.
Kuinka usein budjetin toteutumista pitää tarkistaa?
Kerran kuukaudessa sekä aina, kun sivustolle lisätään lisäosa, upotus tai seurantakoodi. Search Consolen Core Web Vitals -raportti näyttää kenttädatan muutokset viiveellä, joten nopeat laboratoriomittaukset täydentävät sitä.
Onko WordPress-sivustolla mahdollista pysyä alle 1 Mt:n?
On. Kevyellä teemalla, kuten GeneratePressillä tai Kadencella, ja maltillisella lisäosamäärällä esittelysivu jää usein 400-700 kilotavuun. Ongelmat alkavat yleensä raskaista sivunrakentajista ja niiden mukana tulevista animaatiokirjastoista.
Aloita kolmesta luvusta
Ensimmäisen budjetin ei tarvitse olla täydellinen. Kirjaa ylös sivun maksimipaino, JavaScriptin maksimimäärä ja LCP-tavoite sivustotyyppiisi sopivina, ja mittaa kolme tärkeintä sivua kerran kuussa. Kun jokaiselle uudelle ominaisuudelle lasketaan hinta kilotavuina ennen sen lisäämistä, sivusto pysyy nopeana myös vuosien päästä eikä vain julkaisupäivänä.