Vaikuttaako sivuston latausnopeus hakusijoituksiin? Page speed, Core Web Vitals ja SEO selitetty
SEO- & AEO-strategi | AEOvara perustaja
Olen tekoälyajan hakukoneoptimoinnin (AEO) asiantuntija, joka auttaa yrityksiä löytymään sieltä, mistä vastauksia nykyään etsitään.
Kyllä, sivuston latausnopeus vaikuttaa hakusijoituksiin, mutta ei niin, että nopein sivu voittaisi automaattisesti. Google käyttää Core Web Vitals -mittareita osana ranking-järjestelmiään, mobiilikokemus on erityisen tärkeä mobile-first indexingin vuoksi, ja hidas palvelin voi heikentää myös crawlausta. Silti sisällön relevanssi, luotettavuus ja hakutarkoituksen osuvuus ratkaisevat edelleen eniten.
Lyhyesti
- Sivuston latausnopeus on oikea SEO-tekijä, ei pelkkä myytti.
- Google käyttää Core Web Vitals -mittareita ranking-järjestelmissään.
- Kaikkein hitaimmat sivut kärsivät todennäköisimmin, mutta nopeus ei yksin nosta sivua ykköseksi.
- Riippumaton, 11,8 miljoonan hakutuloksen Backlinko-tutkimus löysi heikon mutta todellisen yhteyden nopeuden ja sijoitusten välillä: kärkisijat latautuvat johdonmukaisesti nopeammin kuin sijat 8–10.
- PageSpeed Insightsin pistemäärä ei ole sama asia kuin ranking-signaali. Tärkeämpää on oikeiden käyttäjien kokemus eli field data.
- Mobiilin suorituskyky on erityisen tärkeä, koska Google käyttää mobiiliversiota indeksoinnissa ja rankingissa.
- Hitaus syö usein myös konversioita, ei vain näkyvyyttä.
Miten latausnopeus vaikuttaa hakusijoituksiin
Kun puhutaan page speedistä eli sivunopeudesta ja site speedistä eli sivuston nopeudesta, kyse on oikeastaan kahdesta asiasta yhtä aikaa: siitä, miten Google arvioi sivukokemusta, ja siitä, miten oikeat ihmiset kokevat sivun. Google sanoo suoraan, että Core Web Vitals on osa ranking-järjestelmiä ja että hyvä page experience on myönteinen asia haun kannalta. Se myös sanoo yhtä suoraan, ettei yksittäinen page experience -signaali ratkaise sijoitusta yksin.
Tämä on tärkeä nyanssi. Jos sivu on todella hidas, siitä voi olla näkyvää haittaa. Jos taas sivu on jo hyvällä tasolla, pelkkä viimeinen hiominen ei välttämättä ohita kilpailijaa, jonka sisältö vastaa hakuun paremmin. Google kuvasi tämän jo vuoden 2018 Speed Update -julkaisussa: päivitys osui etenkin kaikkein hitaimpiin mobiilisivuihin, mutta vahva sisältö voi edelleen pärjätä hitaammallakin sivulla. Riippumaton data tukee samaa kuvaa: sivut, joilla 75 % latauksista täyttää hyvän LCP-rajan, saavat keskimäärin enemmän orgaanista liikennettä kuin vastaavat sivut heikommalla LCP:llä — mutta ero on tasoero, ei kaikki tai ei mitään -kytkin.
Core Web Vitals: mittarit, joilla on oikeasti väliä
Googlen tärkeimmät suorituskykymittarit ovat tällä hetkellä LCP, INP ja CLS.
- LCP (Largest Contentful Paint) = suurimman näkyvän sisältöelementin latausaika. Kertoo, milloin sivun pääsisältö ilmestyy näkyviin.
- INP (Interaction to Next Paint) = vuorovaikutuksen vasteaika. Mittaa, kuinka nopeasti sivu reagoi klikkaukseen tai napautukseen.
- CLS (Cumulative Layout Shift) = visuaalinen siirtymä. Kertoo, hyppelehtiikö sisältö latauksen aikana.
Hyvät rajat ovat Googlen dokumentaation mukaan LCP enintään 2,5 sekuntia, INP enintään 200 millisekuntia ja CLS enintään 0,1. Näitä arvioidaan 75. prosenttipisteen tasolla kenttädatasta eli oikeilta käyttäjiltä kerätystä field datasta. Käytännössä et siis optimoi yhtä täydellistä testiä varten, vaan suurta osaa oikeista käyttäjistä varten — siksi yksittäinen nopeustesti omalta koneelta ei riitä, jos todellinen mobiilikokemus on huono.
Esimerkki käytännöstä: miten alustavalinta vaikuttaa latausnopeuteen
Teoria muuttuu konkreettiseksi, kun sen näkee omasta datasta. Ajoimme PageSpeed-mittauksen kahdelle AEOvaran taustalla olevalle sivustolle, jotka on rakennettu kahdelle eri alustalle — toinen WordPressillä, toinen Wixillä:
| Mittari (mobiili) | WordPress-sivusto | Wix-sivusto |
|---|---|---|
| LCP | 2,5 s (juuri rajalla) | 5,1 s (selvästi ”poor”-alueella) |
| Time to Interactive | 4,2 s | 19,2 s |
| Speed Index | 2,6 s | 7,9 s |
| CLS | 0,000 | 0,041 |
Ero ei tarkoita, että Wix olisi lähtökohtaisesti huono alusta — mutta se paljastaa jotain tärkeää: alustan oletusasetukset, teeman raskaus ja lisäosien tai appsien määrä vaikuttavat suoraan siihen, täyttääkö sivu Googlen ”hyvä”-rajat vai ei. WordPress-sivustolla mobiili-LCP on juuri rajan tuntumassa, kun taas Wix-sivusto jää selvästi Googlen ”poor”-luokkaan sekä LCP:ssä että TTI:ssä. Tämä on juuri se kohta, jossa moni yrittäjä ei tiedä, missä oma sivustonsa oikeasti seisoo — eikä pelkkä yksi PSI-testi omalla koneella riitä paljastamaan sitä, koska kenttädata (CrUX) vaatii riittävästi todellista liikennettä.
Miksi PageSpeed Insightsin piste ei yksin ratkaise mitään
PageSpeed Insights on erinomainen työkalu, mutta sen 0–100-piste ei ole sama asia kuin sijoitussignaali. Google ei dokumentoi juuri tuota yksittäistä pistettä rankingtekijäksi — sen sijaan PSI näyttää sekä lab dataa (simuloitu laboratoriodata) että field dataa (todellinen käyttäjädata), ja Google Search Console käyttää nimenomaan field dataan perustuvaa Core Web Vitals -raporttia. Käytännön johtopäätös: 100/100 ei ole tavoite itsessään, vaan oikeiden käyttäjien kokemus on tärkeämpi kuin näyttävä pistemäärä.
Entä muut työkalut, kuten GTmetrix, Lighthouse ja WebPageTest? Ne kaikki mittaavat pitkälti samoja teknisiä signaaleja (LCP, TBT/INP-approksimaatio, CLS), mutta eroavat siinä, käyttävätkö ne todellista kenttädataa vai vain simuloitua testiajoa:
- PageSpeed Insights yhdistää lab- ja field-datan ja on ainoa, joka näyttää suoraan CrUX-kenttädataa Googlen omasta lähteestä.
- Lighthouse (sama moottori kuin PSI:n lab-osiossa) antaa vain simuloidun kertatuloksen — hyvä debuggaukseen, ei rankingin ennustamiseen.
- GTmetrix ja WebPageTest ovat erinomaisia yksityiskohtaisessa vesiputousanalyysissä (mikä resurssi hidastaa mitä), mutta eivät kerro suoraan, läpäiseekö sivu Googlen kenttädataan perustuvat kynnysarvot.
Jos sivullasi ei näy CrUX-dataa PageSpeed Insightsissa, syy ei välttämättä ole ongelma vaan datan puute: Google dokumentoi, että CrUX-dataa kertyy vain julkisesti löydettävistä ja riittävän suosituista kohteista. Pienillä tai uusilla sivuilla tämä on ihan tavallista.
Suora vaikutus ja välillinen vaikutus
Suora vaikutus tulee siitä, että Google käyttää Core Web Vitals -mittareita ranking-järjestelmissään. Välillinen vaikutus tulee siitä, että hitaampi sivu turhauttaa käyttäjää, heikentää käyttökokemusta ja voi syödä konversioita. Samalla hidas palvelin voi hidastaa Googlen crawlausta, jos vasteajat alkavat kasvaa. Tässä kohtaa sivunopeus muuttuu tavallisesta teknisestä siivouksesta liiketoimintatekijäksi: Googlen oma mobiilinopeustutkimus osoittaa, että poistumisen todennäköisyys kasvaa selvästi latausajan pidentyessä muutamasta sekunnista kohti kymmentä, ja web.dev:n caseissa suorituskykyparannukset on yhdistetty parempiin konversioihin ja liikevaihtoon. AEOvaran 5-vaiheisessa metodologiassa tekninen suorituskyky on yksi neljästä kerroksesta, ei irrallinen mittari — se tarkastellaan aina yhdessä sisällön ja auktoriteetin kanssa.
Katso video: vaikuttaako latausnopeus hakusijoituksiin?
Tiivistämme yllä olevat kohdat myös lyhyeksi videoksi: mitä Google itse sanoo Core Web Vitals -mittareista, miksi PageSpeed Insightsin pistemäärä ei ole sama asia kuin ranking-signaali, ja miten latausnopeus vaikuttaa sekä suoraan että välillisesti näkyvyyteen, crawlaukseen ja konversioihin — myös AI-hakukoneiden kuten ChatGPT:n ja Perplexityn näkökulmasta.
Mitä kannattaa optimoida ensin
Jos haluat tehdä tästä käytännöllisen tietopankin eikä vain teoria-artikkelia, aloita näistä — alustakohtaisesti:
- Optimoi LCP ensin. Pääkuva, hero-alue, fontit ja renderöityvä pääsisältö ratkaisevat usein eniten. web.dev suosittelee, että LCP-resurssi on löydettävissä suoraan HTML:stä ja priorisoitu oikein.
- WordPress: ota käyttöön välimuistiliitännäinen (esim. sivuvälimuisti + selainvälimuisti), pakkaa kuvat WebP-muotoon ja karsi turhat lisäosat — jokainen ylimääräinen lisäosa lisää JavaScript-kuormaa.
- Wix: rajaa raskaita animaatioita ja kolmannen osapuolen appseja etusivulla, koska ne ladataan usein render-blocking-tyyppisesti eikä niiden koodiin pääse itse käsiksi.
- Pienennä JavaScriptin kuormaa, koska raskas JavaScript heikentää usein etenkin INP:tä.
- Varmista kuvien mitat ja tilavaraukset, jotta CLS pysyy kurissa.
- Paranna palvelimen vasteaikaa ja käytä tarvittaessa CDN:ää — huono TTFB (Time to First Byte) vaikuttaa sekä käyttökokemukseen että crawlaustehokkuuteen.
- Seuraa oikeaa käyttäjädataa Search Consolesta ja CrUXista, älä vain yksittäisiä testejä.
Jos et ole varma, missä oma sivustosi seisoo näiden rajojen suhteen, AEOvaran AI-auditointi tarkistaa LCP-, INP- ja CLS-arvot osana laajempaa SEO- ja AI-näkyvyystarkastusta — samalla periaatteella kuin yllä olevan esimerkin mittaukset on tehty.
Mitä opimme tästä artikkelista
Tärkein oppi on, ettei sivuston latausnopeus ole SEO:ssa sivurooli eikä myöskään yksinään ratkaiseva supervoima. Oikea tapa ymmärtää asia: nopeus on kilpailukykytekijä. Se voi suoraan tukea näkyvyyttä Core Web Vitalsin kautta, epäsuorasti tukea indeksointia ja crawlausta, parantaa käyttäjäkokemusta ja nostaa konversioita. Mutta jos sisältö ei ole hyödyllistä, luotettavaa ja oikeaan kysymykseen vastaavaa, nopeus ei yksin pelasta mitään.
AEOvaran näkökulmasta paras strategia on rakentaa sivu, joka vastaa yhteen ydinkysymykseen suoraan, purkaa siihen liittyvät alakysymykset selkeästi ja perustaa väitteet lähteisiin. Juuri tällainen rakenne toimii hyvin sekä tavallisessa haussa että AI-pohjaisissa lainauksissa. Jos latausnopeus on jo kunnossa mutta sijoitukset silti takkuavat, kannattaa seuraavaksi katsoa laajempaa kokonaisuutta: AEOvaran SEO-analyysi käy läpi sisällön, teknisen toteutuksen ja AI-näkyvyyden yhtä aikaa, ei pelkkää nopeutta irrallisena lukuna.
UKK
Vaikuttaako latausnopeus Googlen hakusijoituksiin suoraan?
Kyllä. Google käyttää Core Web Vitals -mittareita ranking-järjestelmissään, ja sivunopeus on vahvistettu rankingtekijäksi mobiilihaussa.
Voiko hidas sivu silti päästä hyville sijoille?
Voi. Google on sanonut, että hakutarkoitus on edelleen vahva signaali, joten erittäin osuva ja hyödyllinen sisältö voi rankata hyvin, vaikka sivu ei olisi kilpailijoista nopein.
Onko PageSpeed Insightsin 100/100 pakollinen?
Ei ole. PSI on hyödyllinen kehitystyökalu, mutta se näyttää laboratoriotestien ja kenttädatan yhdistelmää. Tärkeintä on oikeiden käyttäjien kokemus ja se, läpäisevätkö tärkeimmät sivut Core Web Vitals -rajat.
Mitkä arvot ovat hyvä tavoite?
LCP enintään 2,5 s, INP enintään 200 ms ja CLS enintään 0,1. Näitä kannattaa tarkastella 75. prosenttipisteen tasolla, erikseen mobiilille ja desktopille silloin kun dataa on saatavilla.
Onko PageSpeed Insights sama asia kuin GTmetrix tai Lighthouse?
Ei täysin. Kaikki mittaavat samankaltaisia teknisiä signaaleja, mutta vain PSI näyttää suoraan Googlen omaa CrUX-kenttädataa. Lighthouse, GTmetrix ja WebPageTest ovat vahvempia yksityiskohtaisessa vianetsinnässä, eivät suorana rankingennusteena.
Vaikuttaako latausnopeus myös AI-hakukoneisiin kuten ChatGPT, Claude ja Perplexity?
Täsmälleen samanlaista julkista rankingkaavaa ei ole julkaistu kaikilta toimijoilta, mutta peruslogiikka on selvä: sivun pitää olla julkinen, crawlattava ja ymmärrettävä. Google sanoo, että AI Overviews- ja AI Mode -näkyvyyteen ei ole erillisiä uusia vaatimuksia tavallisen SEO:n lisäksi. OpenAI dokumentoi, että mikä tahansa julkinen sivusto voi näkyä ChatGPT Searchissä, jos sitä ei estetä OAI-SearchBotilta. Perplexity suosittelee sallimaan PerplexityBotin, jos haluat sivustosi näkyvän sen hauissa. Siksi nopeus auttaa AI-haussa ennen kaikkea käytettävyyden, crawlattavuuden ja laadukkaan käyttökokemuksen kautta — samat perusteet, jotka AEOvaran AEO vs. SEO -vertailu käy tarkemmin läpi.
Lähteet ja taustadata
Tämän artikkelin taustalla on käytetty Googlen, web.dev:n ja riippumattomien SEO-tutkimusten julkisia lähteitä sivunopeuden, Core Web Vitalsin ja hakukonenäkyvyyden yhteydestä. Lähteitä ei ole käytetty suorina lainauksina, vaan artikkelin väitteet on tiivistetty ja sovellettu AEOvaran omaan asiantuntijanäkemykseen.
- Google Search Central — Understanding page experience in Google Search results
Käytetty taustana sille, että Core Web Vitals on osa ranking-järjestelmiä, mutta ei yksin ratkaiseva signaali.
URL: https://developers.google.com/search/docs/appearance/page-experience - Google Search Central — Using page speed in mobile search ranking (Speed Update)
Käytetty taustana sivunopeuden vahvistamiselle mobiilihaun rankingtekijäksi vuonna 2018.
URL: https://developers.google.com/search/blog/2018/01/using-page-speed-in-mobile-search - Backlinko — Google Ranking Factors
Käytetty taustana riippumattomalle, 11,8 miljoonan hakutuloksen aineistoon perustuvalle analyysille nopeuden ja sijoitusten yhteydestä.
URL: https://backlinko.com/google-ranking-factors - Google — About PageSpeed Insights
Käytetty taustana PageSpeed Insightsin lab- ja field-datan erolle sekä pistemäärän ja rankingsignaalin väliselle erolle.
URL: https://developers.google.com/speed/docs/insights/v5/about - Google Search Central — Mobile-first Indexing Best Practices
Käytetty taustana mobiilikokemuksen merkitykselle mobile-first-indeksoinnissa.
URL: https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing - Google — New Industry Benchmarks for Mobile Page Speed
Käytetty taustana poistumisprosentin ja latausajan yhteydelle sekä sivunopeuden liiketoimintavaikutukselle.
URL: https://business.google.com/ca-en/think/marketing-strategies/mobile-page-speed-new-industry-benchmarks/ - web.dev — Web Vitals
Käytetty taustana LCP-, INP- ja CLS-mittareiden määritelmille ja hyville raja-arvoille.
URL: https://web.dev/articles/vitals - Chrome for Developers — CrUX methodology
Käytetty taustana sille, miksi kaikilta sivustoilta ei löydy CrUX-kenttädataa PageSpeed Insightsista.
URL: https://developer.chrome.com/docs/crux/methodology - web.dev — The most effective ways to improve Core Web Vitals
Käytetty taustana optimointisuosituksille (LCP-priorisointi, JavaScript-kuorma, palvelimen vasteaika).
URL: https://web.dev/articles/top-cwv - web.dev — Cumulative Layout Shift (CLS)
Käytetty taustana kuvien mittojen ja tilavarausten merkitykselle CLS:n hallinnassa.
URL: https://web.dev/articles/cls - Google Search Central — Core Web Vitals report
Käytetty taustana sille, että Search Console raportoi Core Web Vitals -tiedot field datan perusteella.
URL: https://support.google.com/webmasters/answer/9205520 - Google Search Central — AI Features and Your Website
Käytetty taustana sille, ettei Google vaadi AI Overviews- tai AI Mode -näkyvyyteen erillisiä teknisiä vaatimuksia tavallisen hakukonenäkyvyyden lisäksi.
URL: https://developers.google.com/search/docs/appearance/ai-features
Miltä yrityksesi näyttää AI-haussa?
Tilaa 15 minuutin maksuton AI-auditointi ja selvitä nykytilanteesi.
Varaa auditointi tästä →