Verkkokaupan nopeus: Core Web Vitals, latausaika ja mittaaminen

Core Web Vitals ja muut nopeusmittarit

Google mittaa sivun käyttökokemusta joukolla mittareita, joita kutsutaan nimellä Web Vitals. Niistä kolme tärkeintä on nimetty Core Web Vitals -mittareiksi. Taulukossa ovat ne sekä kaksi apumittaria, joita käytetään hitauden syiden etsimiseen.

Miten raja-arvoja luetaan

Core Web Vitals -mittarit kuvaavat latautumista, reagointia ja sivun vakautta. INP korvasi aiemman FID-mittarin Core Web Vitals -mittarina maaliskuussa 2024. TTFB ja FCP eivät kuulu Core Web Vitals -mittareihin, mutta ne auttavat löytämään syyn, jos LCP on hidas. Hidas TTFB viittaa yleensä palvelimeen, välimuisteihin tai uudelleenohjauksiin. Googlen mukaan TTFB:n rajat ovat suuntaa antavia.

Raja-arvoja verrataan 75. persentiiliin. Sivun tulos on hyvä, kun vähintään kolme neljästä sivulatauksesta alittaa hyvän rajan. Mobiili ja tietokone arvioidaan erikseen, ja sivu läpäisee Core Web Vitals -arvion, kun kaikki kolme mittaria ovat hyviä. Mobiilitulos on lähes aina heikompi, ja verkkokaupassa juuri se ratkaisee, koska usein suurin osa kävijöistä tulee puhelimella.

Mittareista ja raja-arvoista lisää Googlen web.dev-sivustolla: Web Vitals -yleiskatsaus (web.dev).

Miten nopeutta mitataan oikein

Nopeutta kannattaa mitata jatkuvasti. Kun kauppaa kehitetään, uusi lisäosa, kampanjabanneri tai seurantakoodi voi hidastaa sitä huomaamatta, ja pienet hidastukset kasautuvat ajan myötä.

Kenttädata ja laboratoriodata

Nopeustuloksia on kahta lajia. Kenttädata kertoo, miten sivu on oikeasti toiminut kävijöillesi. Google kerää sen Chrome-selaimen käyttäjiltä Chrome User Experience Report (CrUX) -aineistoon, ja sitä käyttävät sekä PageSpeed Insights että Search Console. Kenttädataa on vain sivuille ja sivustoille, joilla on riittävästi Chrome-kävijöitä. Laboratoriodata syntyy, kun työkalu lataa sivun kerran simuloidulla laitteella ja yhteydellä. Se sopii vikojen etsimiseen ja muutosten testaamiseen heti, mutta se ei kerro, mitä kävijäsi kokevat.

Siksi eri työkalut antavat eri tuloksia. Laboratoriotestin tulos riippuu testipalvelimen sijainnista, simuloidusta laitteesta ja siitä, tuliko sivu välimuistista. Kenttädataan vaikuttavat kävijöiden omat laitteet ja yhteydet. Kun tulokset ovat ristiriidassa, kenttädata kertoo todellisen tilanteen ja laboratoriotesti auttaa löytämään syyn.

Näin luet PageSpeed Insightsia

PageSpeed Insightsin raportissa on kaksi osaa. Ylempi osa näyttää todellisten Chrome-käyttäjien kokemukset viimeisen 28 päivän ajalta, eli se on kenttädataa. Sen valitsimesta näet joko juuri tämän sivun tuloksen (englanninkielisessä näkymässä ”This URL”) tai koko sivuston tuloksen (”Origin”). Molemmat ovat kävijöiden toteutuneita tuloksia, eivät juuri tehdyn testin tuloksia. Jos sivulla on liian vähän kävijöitä, työkalu näyttää koko sivuston tuloksen tai ei kenttädataa lainkaan.

Alempi osa (”Diagnose performance issues”) on juuri tehty laboratoriotesti, joka ajetaan Googlen Lighthouse-työkalulla. Sen 0 ja 100 välinen pistemäärä on suuntaa antava, eikä se ole sama asia kuin Core Web Vitals -arvio. Testin alta löytyvät myös konkreettiset parannusehdotukset.

Koska kenttädata on 28 päivän liukuva jakso, muutoksen vaikutus näkyy siinä vähitellen ja kokonaan noin neljän viikon kuluttua. Laboratoriotestissä vaikutuksen näkee heti. Tarkista aina mobiili- ja tietokonetulos erikseen.

Työkalut

• PageSpeed Insights: kenttädata ja Lighthouse-testi samassa raportissa, yksi sivu kerrallaan.
• Search Consolen Core Web Vitals -raportti: koko sivuston tilanne sivuryhmittäin, mobiili ja tietokone erikseen. Paras paikka seurata kehitystä pitkällä aikavälillä.
• GTmetrix: Lighthouseen perustuva laboratoriotesti, jonka vesiputouskaavio näyttää selkeästi, missä järjestyksessä ja kuinka kauan tiedostot latautuvat. Suomessa ei ole testipalvelinta, joten valitse lähin sijainti. GTmetrix laskee oman arvosanansa, joka huomioi suorituskyvyn lisäksi sivun rakenteen, joten se ei ole suoraan verrattavissa PageSpeed Insightsin pisteisiin.

Mistä verkkokaupan hitaus yleensä johtuu

Hitaudella on harvoin vain yksi syy. Yleisimmät syyt ovat nämä:

• Palvelin ja hosting. Liian pieni tai jaettu palvelin, huonosti säädetty PHP tai tietokanta ja kaukana asiakkaista sijaitseva palvelinsali näkyvät suoraan TTFB-ajassa.
• Välimuistit. Kun sivu tulee valmiista välimuistista, palvelimen ei tarvitse rakentaa sitä uudelleen. Jos välimuisti tyhjenee jatkuvasti tai osa sivuista ohittaa sen, kauppa hidastuu juuri kiireisimpinä aikoina.
• Kuvat. Liian suuret kuvat ja vanhat tiedostomuodot ovat yleisin syy hitaaseen LCP-arvoon. Modernit kuvaformaatit, kuten WebP ja AVIF, oikea kuvakoko eri näytöille ja näkymän ulkopuolisten kuvien viivästetty lataus auttavat paljon.
• Kolmannen osapuolen skriptit. Analytiikka, mainospikselit, chatit, arvostelut ja tagienhallintaan vuosien varrella kertyneet tagit kuormittavat selainta ja heikentävät erityisesti INP-arvoa.
• Raskas teema ja JavaScript. Mitä enemmän koodia selaimen pitää ladata ja suorittaa, sitä hitaammin sivu reagoi, varsinkin edullisilla puhelimilla.
• Fontit, bannerit ja evästeilmoitukset. Jos niille ei ole varattu tilaa, myöhään latautuvat elementit siirtävät sisältöä ja heikentävät CLS-arvoa.
• Lisäosat ja muokkaukset. Huonosti tehty laajennus voi hidastaa jokaista sivulatausta. Jatkuvasti kehitettävässä kaupassa hidastuminen tapahtuu usein vähitellen, ja siksi seuranta on tärkeää.

Mitä voit tarkistaa itse ja mihin tarvitset kehittäjää

Itse voit tarkistaa

• Search Consolen Core Web Vitals -raportista, onko ongelma mobiilissa, tietokoneella vai molemmissa ja mitkä sivuryhmät ovat heikkoja.
• PageSpeed Insightsilla etusivun, tuotelistauksen, tuotesivun ja ostoskorin erikseen. Ne ovat eri sivupohjia, ja ongelma on usein vain yhdessä niistä.
• Ladataanko kauppaan kuvia, jotka ovat paljon suurempia kuin niiden näyttökoko.
• Mitä kaikkea tagienhallinnassa on ja ovatko kaikki tagit vielä tarpeen.
• Hidastuiko kauppa jonkin julkaisun, uuden lisäosan tai kampanjan jälkeen.

Kehittäjää tarvitset, kun

• TTFB on yli 0,8 sekuntia tai vaihtelee paljon.
• Välimuisti, hakupalvelin tai indeksointi ei toimi niin kuin pitäisi.
• INP on heikko, eli sivun JavaScript tai teema on liian raskas.
• Lisäosien tai omien muokkausten vaikutus pitää mitata ja korjata.

Nopeus Magento-verkkokaupassa

Magento on tehty suurille tuotevalikoimille, mutta se on nopea vain, kun ympäristö on rakennettu oikein. Tärkeimmät kohdat ovat nämä:

• Tuotantotila (production mode), jossa tiedostot on käännetty ja koottu valmiiksi.
• Kokosivuvälimuisti, tuotantokäytössä yleensä Varnish, joka palauttaa valmiit sivut ilman, että Magento rakentaa niitä joka kerta.
• Redis tai Valkey sovelluksen välimuisteille ja istunnoille.
• OpenSearch tuotehakuun ja suodatukseen.
• Ajastettu indeksointi (Update by Schedule), jotta tuotetietojen tallentaminen ylläpidossa ei hidasta kauppaa.
• Sisällönjakeluverkko (CDN) kuville ja staattisille tiedostoille, kun asiakkaita on laajalla alueella.
• Kuvat ja skriptit: kuvien koon ja formaatin optimointi sekä kolmannen osapuolen skriptien karsiminen.

Magenton oletusteema Luma ei itsessään ole hidas. Codaonen kokemuksen mukaan hyvin toteutetulla ja optimoidulla Luma-teemalla voi saavuttaa Googlen nopeustesteissä täydet 100 pistettä sekä mobiilissa että työpöydällä. Heikot INP- ja LCP-arvot johtuvat yleensä siitä, mitä teeman päälle on rakennettu: raskaista lisäosista, kolmannen osapuolen skripteistä, optimoimattomista kuvista ja vuosien aikana kertyneestä JavaScriptistä. Siksi olemassa olevan teeman karsiminen ja optimointi tuo usein suurimman osan hyödystä. Hyvä-teema on yksi vaihtoehto, ja se on ollut marraskuusta 2025 alkaen maksuton ja avointa lähdekoodia. Teeman vaihtaminen ei kuitenkaan yksin ratkaise nopeusongelmia: jos hitaus johtuu palvelimesta, välimuistista, raskaista lisäosista tai kolmannen osapuolen skripteistä, se seuraa mukana myös uuteen teemaan. Siksi valinta tehdään kaupan lisäosien, kehityssuunnitelmien ja budjetin perusteella.

WooCommerce ja Shopify. Periaate on sama: palvelin tai alusta, välimuisti, kuvat, kolmannen osapuolen skriptit ja teeman paino ratkaisevat. WooCommercessa korostuvat hostingin laatu, välimuistin asetukset ja lisäosien määrä. Shopifyssa palvelinpuoli on alustan vastuulla, joten parannukset tehdään teemassa, sovelluksissa ja sisällössä. Alustojen eroista lisää vertailussamme Magento vs. WooCommerce.

Nopeus, hakukoneet ja tekoälyhaut

Google ottaa Core Web Vitals -mittarit huomioon osana sivukokemusta, jota sen hakujärjestelmät arvioivat. Yksittäistä nopeussignaalia ei kuitenkaan ole. Googlen mukaan hyvät tulokset eivät takaa kärkisijoja, ja relevanttia sisältöä näytetään, vaikka sivukokemus olisi heikko. Käytännössä nopeus ratkaisee harvoin yksin, mutta se voi olla ero kahden yhtä hyvän sivun välillä.

Googlen tekoälyominaisuudet, kuten tekoälyn tuottamat yhteenvedot (AI Overviews) ja AI Mode, eivät Googlen mukaan vaadi erityisiä optimointeja. Samat perusasiat pätevät: sivu on indeksoitavissa, sisältö on selkeää tekstiä ja sivukokemus on hyvä.

Nopeuden suurin hyöty näkyy kuitenkin asiakkaissa. Nopea kauppa on miellyttävämpi käyttää, ja se voi näkyä myynnissä. Esimerkiksi Deloitten Googlen toimeksiannosta tekemässä tutkimuksessa (2020) 0,1 sekunnin parannus mobiilisivuston nopeudessa oli yhteydessä 8,4 % parempaan konversioon vähittäiskaupassa. Tutkimus näyttää yhteyden, ei lupaa samaa tulosta jokaiselle kaupalle.

Näin Codaone seuraa nopeutta

Nopeuden seuranta kuuluu Codaonen ylläpitopalveluun. Seuraamme erityisesti TTFB-aikaa, koska se kertoo nopeasti, jos palvelimessa, välimuisteissa tai uudessa julkaisussa on jotain vialla. Muita mittareita seuraamme PageSpeed Insightsin kautta. Jos jokin mittari muuttuu selvästi tai siirtyy hyvältä alueelta heikommalle, saamme hälytyksen ja selvitämme, mikä muutos sen aiheutti.

Olemme kehittäneet palvelinympäristöä ja Magento-moduuleja niin, että myös vahvasti muokattu Magento-kauppa voi olla nopea. Hyvin viritetyssä ympäristössä Codaonen rakentaman, vahvasti muokatun Magento-kaupan TTFB on noin 0,5 sekuntia myös silloin, kun sivua ei ole välimuistissa, esimerkiksi ostoskorissa, kassalla, haussa tai juuri päivitetyillä tuote- ja kategoriasivuilla, selvästi alle Googlen 0,8 sekunnin rajan. Luku kuvaa hyvin viritettyä ympäristöä, ei lupausta jokaiselle kaupalle: tulokseen vaikuttavat esimerkiksi palvelin, lisäosat ja kävijän yhteys.

Tarkistuslista: verkkokaupan nopeus

• Core Web Vitals on tarkistettu Search Consolesta erikseen mobiilille ja tietokoneelle.
• Etusivu, tuotelistaus, tuotesivu ja ostoskori on testattu erikseen.
• TTFB on enintään 0,8 sekuntia, ja myös välimuistin ohittavat sivut, kuten haku ja ostoskori, toimivat sujuvasti.
• Kokosivuvälimuisti on käytössä, ja suurin osa sivulatauksista tulee siitä.
• Kuvat ovat oikean kokoisia ja moderneissa formaateissa, ja näkymän ulkopuoliset kuvat ladataan viiveellä.
• Tagienhallinta ja kolmannen osapuolen skriptit on käyty läpi viimeisen vuoden aikana.
• Kuville, bannereille ja upotuksille on varattu tila, jotta sisältö ei hypi.
• Alusta, teema ja lisäosat ovat ajan tasalla.
• Nopeutta seurataan jatkuvasti, ja hidastumisesta tulee hälytys.

Jos listasta jää avoimia kohtia, tilaa verkkokaupallesi maksuton kuntotarkastus. Lisää oppaita verkkokaupan kehittämiseen löydät Magento FAQ -sivulta.