PageSpeed Insights 100/100 – tarvitaanko täydellistä tulosta?

Ajoin tämän sivuston etusivulle PageSpeed Insightsin ja sain 100/100 kaikissa kategorioissa sekä mobiilissa että työpöydällä. Täydellinen tulos ei ole pakollinen eikä se yksin nosta sivua hakutuloksissa, mutta se kertoo, ettei sivu häiritse kävijää hitaudella tai hyppivällä sisällöllä. Tässä artikkelissa käyn läpi, mitä luvut tarkoittavat, saako saman WordPress-sivustolla ja mitä tällä sivustolla piti tehdä.

Mitkä tulokset sivusto sai?

Mittaus on tehty etusivulle 24.10.2026. Performance, Accessibility, Best Practices ja SEO saivat kaikki 100 pistettä ja Agentic Browsing 2/2 sekä mobiilissa että työpöydällä.

Mittari	Mobiili	Työpöytä
First Contentful Paint (FCP)	0,9 s	0,2 s
Largest Contentful Paint (LCP)	1,4 s	0,3 s
Total Blocking Time (TBT)	0 ms	0 ms
Cumulative Layout Shift (CLS)	0	0
Speed Index	0,9 s	0,5 s

Mitä Agentic Browsing 2/2 tarkoittaa?

Agentic Browsing on Lighthousen uusi ja vielä kokeellinen kategoria. Se tarkistaa, pystyvätkö tekoälyagentit lukemaan ja käyttämään sivua samaan tapaan kuin ihminen: löytämään painikkeet, täyttämään lomakkeet ja klikkaamaan oikeaa kohtaa. Kategorialla ei ole pisteitä 0–100. Tulos on murtoluku, joka kertoo, montako tarkistusta sivu läpäisi.

Lighthousen oletusasetuksissa tarkistuksia on seitsemän:

• Saavutettavuuspuu: osa axe-säännöistä, esimerkiksi painikkeiden ja linkkien nimet, lomakekenttien nimilaput ja ARIA-määreet
• CLS: sama asettelun vakaus kuin Performance-osiossa, koska agentti klikkaa ohi, jos painike siirtyy
• WebMCP: kolme tarkistusta työkaluille, joilla sivu voi kertoa agentille, mitä toimintoja sillä on
• llms.txt: tekoälylle tarkoitettu tiivistelmä sivuston juuressa
• ARD-manifesti: koneluettava kuvaus agenteille tarjotuista resursseista

Tarkistus, jota ei voi soveltaa, jätetään laskusta pois. Tavallinen selain ei vielä tue WebMCP:tä, ja jos llms.txt-tiedostoa ei ole, Lighthouse merkitsee tarkistuksen ei sovellettavaksi eikä hylätyksi. Mittaushetkellä sivustolla ei ollut WebMCP-työkaluja, llms.txt-tiedostoa eikä ARD-manifestia, joten mukaan jäivät saavutettavuuspuu ja CLS. 2/2 tarkoittaa, että molemmat menivät läpi.

Mittauksen jälkeen lisäsin sivustolle llms.txt-tiedoston. Build tekee sen samoista tiedoista kuin sivukartan: palvelut, artikkelit ja referenssit. Lighthouse tarkistaa, että tiedostossa on pääotsikko ja ainakin yksi linkki. Nyt tarkistuksia on kolme, ja tulos on 3/3.

Agentti lukee sivua samasta saavutettavuuspuusta kuin ruudunlukija. Saavutettavuustyö tekee siis sivusta käyttökelpoisen myös agenteille ilman erillistä tekoälyoptimointia.

Onko 100/100 edes tarpeen?

Ei ole. Performance-pisteet tulevat Lighthousesta, joka lataa sivun kerran simuloidussa ympäristössä. Mobiilitesti hidastaa yhteyden 1,6 Mbit/s nopeuteen 150 ms viiveellä ja suorittimen neljäsosaan. Pisteet lasketaan viidestä mittarista: Lighthouse 10:ssä TBT painaa 30 %, LCP ja CLS 25 % kumpikin, FCP ja Speed Index 10 % kumpikin. Vihreä alkaa 90 pisteestä.

Tämä on laboratoriodataa. Se sopii vianetsintään, koska testi on toistettava, mutta yksittäinen ajo voi vaihdella verkon ja testipalvelimen mukaan.

Mitä Google oikeasti käyttää?

Google käyttää oikeiden käyttäjien kenttädataa, ei Lighthouse-pisteitä. Core Web Vitals -mittarit ja niiden hyvät raja-arvot ovat:

• LCP enintään 2,5 s: suurin näkyvä elementti piirtyy ruudulle
• INP enintään 200 ms: sivu reagoi klikkauksiin ja näppäilyihin
• CLS enintään 0,1: sisältö ei hypi latautuessa

Data tulee Chromen käyttäjiltä kerättävästä Chrome User Experience Reportista (CrUX), ja PageSpeed Insights näyttää edellisen 28 päivän tilanteen. Jos sivulla tai koko sivustolla ei ole tarpeeksi kävijöitä, kenttädataa ei näytetä lainkaan. Tämä sivusto julkaistiin lokakuussa, joten 28 päivän dataa ei ole vielä kertynyt.

INP korvasi FID:n vuonna 2024. Lighthouse ei pysty mittaamaan INP:tä, koska se ei klikkaa sivua. TBT on sen lähin vastine laboratoriossa.

Hyvät Core Web Vitals -tulokset eivät takaa, että sivu nousee hakutulosten kärkeen. Täydellisen tuloksen tavoittelu pelkästään hakukoneoptimoinnin takia ei välttämättä ole paras tapa käyttää aikaa.

Samassa ohjeessa Google kertoo näyttävänsä relevantin sisällön, vaikka sivukokemus olisi heikko. Nopeus ratkaisee lähinnä silloin, kun kilpailevat sivut ovat sisällöltään yhtä hyviä. Kävijälle se merkitsee enemmän: hidas sivu ja hyppivä painike ärsyttävät, vaikka sijoitus ei muuttuisi.

Sama koskee muita kategorioita. Accessibility 100 tarkoittaa, ettei automaattinen testi löytänyt virheitä. Se ei tarkoita, että sivu on saavutettava, kuten kirjoitin oman sivuston WCAG-auditista.

Saako saman tuloksen WordPress-sivustolla?

Saa, mutta se vaatii valintoja heti alussa. Jälkikäteen korjaaminen on hitaampaa kuin kevyen pohjan tekeminen. Nämä vaikuttavat eniten:

• Teema ja sivunrakentaja. Raskas sivunrakentaja tuottaa syvän HTML-rakenteen sekä omat CSS- ja JavaScript-tiedostonsa joka sivulle. Kevyt lohkoteema tai räätälöity teema lähtee paljon paremmasta tilanteesta.
• Lisäosat. Ratkaisevaa ei ole määrä vaan se, lataako lisäosa tiedostojaan sivuilla, joilla sitä ei käytetä. Lomakelisäosan skriptit kuuluvat vain lomakesivulle.
• Kuvat. WordPress tekee kuvista eri kokoja ja lisää loading="lazy"-määreen. Versiosta 6.3 lähtien se merkitsee todennäköisen LCP-kuvan fetchpriority="high"-määreellä. Liukuri tai video heron taustana kumoaa nämä helposti.
• Fontit. Google Fonts kannattaa siirtää omalle palvelimelle, käyttää WOFF2-muotoa ja ladata vain tarvittavat painot. WordPressin oma fonttikirjasto (6.5) tekee tämän ilman lisäosaa.
• Kolmannen osapuolen skriptit. Chat-ikkunat, tag manager, mainosseuranta ja upotetut videot ovat yleisin syy huonoon TBT:hen ja INP:hen. Jokainen niistä kannattaa perustella erikseen.
• Evästebanneri. Banneri voi olla sivun suurin elementti eli LCP, ja raskas suostumustyökalu lataa omaa koodiaan ennen muuta sisältöä. Kevyt banneri, joka ei siirrä sisältöä, on parempi kuin näyttävä.
• Välimuisti ja hosting. Valmiiksi välimuistissa oleva HTML ja CDN lyhentävät ensimmäisen tavun aikaa. Ilman niitä PHP ja tietokanta tekevät jokaisen sivun alusta.

Verkkokaupassa tilanne on vaikeampi, koska ostoskoria ja kassaa ei voi tallentaa välimuistiin. Kävin syitä läpi artikkelissa miksi WooCommerce-kauppa hidastuu. WordPressillä 100 pistettä on mahdollinen, mutta 90+ ja hyvät kenttäarvot ovat järkevämpi tavoite. Autan tässä WordPress- ja WooCommerce-palvelussa, ja nopeus on osa SEO-, GEO- ja saavutettavuusauditteja.

Mitä tällä sivustolla piti tehdä?

Lähtökohta oli helppo: sivusto on staattista HTML:ää, joka generoidaan Markdownista, eikä siinä ole tietokantaa, sivunrakentajaa tai JavaScript-kehystä. Kerroin rakentamisesta tarkemmin artikkelissa sivusto tekoälyn avustuksella. Silti 100 pistettä ei tullut ilmaiseksi:

• CSS upotettiin sivuun. Erillinen tyylitiedosto esti piirtämisen, ja mobiilin LCP-kuva löytyi vasta sen sisältä. Nyt etusivu on pakattuna noin 13 kt.
• Heron sumu muutettiin kuviksi. Sumu oli SVG-kuvia, joiden sumennus laskettiin pääsäikeellä ensimmäisessä ruudussa, mikä kasvatti TBT:tä. Nyt kerrokset ovat 96 pikselin WebP-kuvia. Mobiilissa sumu peittää ison osan heroa, ja se on ollut sivun suurin näkyvä elementti. LCP mittaa juuri sen piirtymistä, joten sumu ratkaisi koko luvun. Kerrokset ovat CSS-taustakuvia, ja selain löytää ne vasta luettuaan tyylit. Siksi etusivun alussa on <link rel="preload">, joka käskee selainta hakemaan kuvat heti.
• Layout shift korjattiin. Yläpalkki irrotetaan sivun virrasta vasta, kun sen tila on varattu, ja mobiilivalikon nappi on valmiina HTML:ssä. Mitat luetaan ResizeObserverilla, ettei selain joudu laskemaan asettelua uudelleen kesken latauksen.
• Fontit ovat omalla palvelimella. Kolme fonttitiedostoa esiladataan ja teksti näkyy varafontilla, kunnes ne ovat valmiina.
• Välimuisti. Firebasen CDN pitää sivut välimuistissa ja tyhjentää sen jokaisella julkaisulla, ja selain tarkistaa sivun joka latauksella.
• Analytiikka vasta suostumuksen jälkeen. Google Analytics ladataan vasta, kun kävijä hyväksyy sen. Testi ei hyväksy evästeitä, joten mittauksessa on mukana vain banneri.
• Raskaat kirjastot vasta tarvittaessa. Blogin three.js-demo latautuu vasta, kun se vieritetään näkyviin.

Kompromisseja tuli vähän. Sumu on nyt rasterikuva eikä vektori, mutta voimakkaasti sumennettuna eroa ei näe. Upotettu CSS ladataan jokaisen sivun mukana eikä selain voi käyttää sitä uudelleen, mutta pakattuna se on pieni. Suurin rajoitus on kurinalaisuus: jokainen uusi skripti tai upotus pitää miettiä erikseen.

Voiko lukuja vielä parantaa?

Voi, mutta hyöty olisi pieni. Mobiilin LCP 1,4 s ja Speed Index 0,9 s on mitattu hidastetulla yhteydellä, jossa jokainen pyyntö maksaa viiveen. Pienempiin lukuihin pääsisi vähentämällä pyyntöjä ennen ensimmäistä piirtoa: yhdistämällä sumun neljä kerrosta yhdeksi kuvaksi tai korvaamalla ne CSS-liukuväreillä ja esilataamalla vähemmän fonttitiedostoja. Molemmat muuttaisivat ulkoasua tai tekstin piirtymistä, joten en tee niitä pelkän mittarin takia. Pisteet ovat jo 100, ja oikeiden kävijöiden luvut kertovat enemmän, kun kenttädataa kertyy.

Usein kysyttyä

Vaikuttaako PageSpeed-pistemäärä Google-sijoitukseen?

Ei suoraan. Google käyttää oikeiden käyttäjien Core Web Vitals -kenttädataa, ja sekin on vain yksi tekijä sisällön relevanssin rinnalla.

Miksi tulos vaihtelee ajokerrasta toiseen?

Lighthouse lataa sivun kerran testipalvelimelta, ja verkon tilanne ja palvelimen kuorma vaihtelevat. Muutaman pisteen ero ajojen välillä on normaali.

Mikä on realistinen tavoite WordPress-sivustolle?

Performance 90 tai enemmän mobiilissa ja kaikki Core Web Vitals -mittarit hyvällä tasolla kenttädatassa. Se onnistuu useimmille sivustoille, kun teema, lisäosat ja kolmannen osapuolen skriptit on valittu harkiten.