Verkkosivuston nopeutta pidettiin pitkään lähinnä teknisenä ominaisuutena, josta olivat kiinnostuneita ennen kaikkea kehittäjät. Tavallisen verkkosivuston omistajan näkökulmasta asia oli yksinkertainen: jos sivusto avautuu, kaikki on kunnossa.
Käyttäjä kuitenkin kokee nopeuden aivan eri tavalla.
Kun sivu avautuu nopeasti, käyttäjä voi jatkaa lukemista, tutkia tuotteita tai täyttää lomakkeen ilman keskeytyksiä. Jos sivusto näyttää useita sekunteja tyhjää ruutua, elementit liikkuvat latauksen aikana, painike vaihtaa paikkaa tai ensin latautuu valtava banneri ja vasta sen jälkeen varsinainen sisältö, kärsivällisyys loppuu nopeasti.
Tämä näkyy erityisen selvästi mobiililaitteilla.
Siksi verkkosivuston suorituskyvystä on tullut tärkeä osa teknistä SEO-optimointia. Google ei arvioi ainoastaan sivun sisältöä ja sen vastaavuutta hakukyselyyn, vaan myös sitä, kuinka sujuvasti käyttäjä pystyy käyttämään sivustoa.
Yksi tähän liittyvistä mittareista on Core Web Vitals -kokonaisuus. Sen avulla voidaan arvioida, kuinka nopeasti sivun tärkein sisältö latautuu, kuinka nopeasti sivu reagoi käyttäjän toimintaan ja kuinka vakaana käyttöliittymä pysyy latauksen aikana.
On kuitenkin tärkeää unohtaa heti yksi yleinen väärinkäsitys.
Pelkästään vihreiden arvojen saavuttaminen yhdessä työkalussa ei automaattisesti nosta sivustoa hakutuloksissa.
SEO toimii kokonaisuutena.
Sivuston pitää olla teknisesti saavutettava, hakukoneille ymmärrettävä, käyttäjälle hyödyllinen, selkeästi rakennettu ja hakutarkoitukseen sopiva. Nopeus on yksi tämän kokonaisuuden osista.
Se on kuitenkin tärkeä osa.
Jos sivusto on hidas, hyväkin sisältö voi menettää potentiaalisia kävijöitä jo ennen kuin he ehtivät lukea sitä.
Tässä artikkelissa käymme läpi, mitä Core Web Vitals tarkoittaa, mitkä ongelmat hidastavat verkkosivustoja kaikkein useimmin, miten ongelmien todelliset syyt voidaan löytää ja millä käytännön toimilla suorituskykyä voidaan parantaa.
Miksi verkkosivuston nopeus on tärkeää SEO:n kannalta
Kuvitellaan käyttäjä, joka löytää sivun Googlesta ja siirtyy verkkosivustolle.
Hän odottaa saavansa vastauksen kysymykseensä.
Sen sijaan ruudulle ilmestyy tyhjä näkymä.
Kuluu sekunti.
Sitten toinen.
Elementit alkavat latautua.
Seuraavaksi ilmestyy banneri.
Teksti siirtyy hieman alaspäin.
Käyttäjä yrittää painaa painiketta, mutta selain ei vielä reagoi kunnolla.
Lopulta hän sulkee välilehden ja palaa hakutuloksiin.
Yritykselle tämä tarkoittaa yhden potentiaalisen asiakkaan menettämistä.
Myös hakukoneen näkökulmasta käyttökokemuksella on merkitystä. Jos sivu on teknisesti raskas ja hankala käyttää, käyttäjän kokemus heikkenee.
Nopeutta ei kuitenkaan pidä tarkastella irrallaan muusta SEO:sta.
Jos sivusto toimii teknisesti täydellisesti, mutta sisältö ei vastaa käyttäjän hakua, hyvä suorituskyky ei tee sivusta automaattisesti hakutulosten kärkisivua.
Toisaalta vahva sisältö voi menestyä, vaikka Core Web Vitals -arvot eivät olisi täydellisiä.
Siksi oikea tavoite ei ole yksinkertaisesti ”saada PageSpeed-arvoksi 100”, vaan:
tehdä verkkosivustosta nopea, vakaa ja helppokäyttöinen ilman, että sisällöstä tai tärkeistä toiminnoista joudutaan tinkimään.
Mitä Core Web Vitals tarkoittaa
Core Web Vitals on joukko mittareita, joiden tarkoituksena on arvioida todellista käyttökokemusta verkkosivustolla.
Nykyinen kokonaisuus sisältää kolme keskeistä mittaria:
- LCP eli Largest Contentful Paint
- INP eli Interaction to Next Paint
- CLS eli Cumulative Layout Shift
Jokainen mittari tarkastelee eri osaa käyttäjän kokemuksesta.
LCP kertoo, kuinka nopeasti käyttäjä näkee sivun tärkeimmän suuren sisältöelementin.
INP auttaa arvioimaan, kuinka nopeasti sivu reagoi käyttäjän toimintaan.
CLS puolestaan kertoo, kuinka paljon sivun elementit liikkuvat odottamatta latauksen aikana.
Yhdessä nämä mittarit antavat paljon paremman kuvan sivuston toimivuudesta kuin pelkkä väite siitä, että ”sivu latautuu kolmessa sekunnissa”.
Kaksi sivua voi nimittäin latautua kokonaisuudessaan yhtä nopeasti ja tuntua silti käyttäjästä täysin erilaisilta.
Ensimmäisellä sivulla teksti näkyy heti.
Toisella ensin latautuu suuri kuva, sitten valikko hyppää paikalleen, sen jälkeen varsinainen sisältö ilmestyy ja käyttäjän painaessa painiketta selain käsittelee vielä useita JavaScript-tehtäviä.
Teknisesti molemmat sivut ovat lopulta latautuneet.
Käyttökokemus on silti aivan erilainen.
LCP: kuinka nopeasti tärkein sisältö näkyy
LCP tarkoittaa Largest Contentful Paintia.
Yksinkertaistettuna mittari vastaa kysymykseen:
kuinka nopeasti käyttäjä näkee sivun tärkeimmän suuren sisältöelementin?
Se voi olla esimerkiksi:
- pääotsikko;
- suuri tekstialue;
- kuva;
- banneri;
- tuotekuva;
- sivun pääasiallinen visuaalinen elementti.
Hyvän käyttökokemuksen kannalta LCP:n olisi hyvä tapahtua noin 2,5 sekunnin sisällä sivun latauksen alkamisesta.
Jos tulos on selvästi tätä hitaampi, sivu voi tuntua käyttäjästä tahmealta.
On kuitenkin tärkeä huomioida yksi asia.
Huono LCP ei välttämättä tarkoita, että koko sivusto on hidas.
Ongelma voi olla yhdessä tietyssä elementissä, jonka selain pystyy näyttämään vasta myöhään.
Esimerkiksi ensimmäisellä näytöllä voi olla valtava valokuva.
Juuri siitä kuvasta tulee LCP-elementti.
Niin kauan kuin kuva ei ole latautunut, LCP-tulos pysyy huonona.
Tällaisessa tilanteessa koko sivustoa ei tarvitse lähteä optimoimaan kerralla.
Ensin pitää selvittää, mikä elementti toimii LCP-elementtinä ja miksi sen näyttäminen kestää niin kauan.
Miksi LCP liittyy usein kuviin
Suuret kuvat ovat yksi yleisimmistä suorituskykyongelmien aiheuttajista.
Erityisen ongelmallinen tilanne on silloin, kun palvelimelle on ladattu esimerkiksi 4000 × 3000 pikselin kuva, vaikka sivulla sitä näytetään vain noin 700 pikselin levyisenä.
Selaimelle lähetetään tällöin huomattavasti enemmän dataa kuin todellisuudessa tarvitaan.
Tilanne pahenee entisestään, jos käytössä on raskas kuvatiedostomuoto.
Siksi yksi ensimmäisistä optimointikohteista kannattaa olla ensimmäisellä näytöllä näkyvät kuvat.
Kannattaa tarkistaa:
- kuvan fyysinen koko;
- tiedostomuoto;
- tiedoston koko;
- lataustapa;
- responsiivisuus;
- modernien kuvaformaattien käyttö;
- kuvan todellinen näyttökoko.
WebP:n ja AVIF:n kaltaiset modernit formaatit voivat monissa tapauksissa pienentää tiedostokokoa merkittävästi ilman näkyvää laadun heikkenemistä.
Pelkkä kuvien muuntaminen uuteen formaattiin ei kuitenkaan riitä.
Myös eri laitteille pitää toimittaa tarkoituksenmukainen kuvakoko.
Responsiiviset kuvat ja oikean kokoiset tiedostot
Jos palvelin lähettää älypuhelimelle 2500 pikseliä leveän kuvan, vaikka laitteen näytöllä se näytetään vain noin 400–500 pikselin levyisenä, käyttäjä lataa turhaan ylimääräistä dataa.
Parempi ratkaisu on käyttää responsiivista kuvien latausta, jolloin selain voi valita tilanteeseen sopivan kuvatiedoston.
Tähän voidaan käyttää esimerkiksi srcset– ja sizes-määritteitä.
Tällöin älypuhelin voi saada kevyemmän version ja suuri näyttö puolestaan suuremman resoluution kuvan.
Tämä on erityisen tärkeää verkkokaupoissa, tuotekatalogeissa ja sivustoilla, joissa käytetään paljon visuaalista sisältöä.
Jos yhdellä sivulla on kymmeniä kuvia, väärin toteutettu kuvien lataus voi kasvattaa siirrettävän datan määrää huomattavasti.
Lazy loading: missä se auttaa ja missä se voi aiheuttaa ongelmia
Kuvien viivästetty lataus eli lazy loading on hyödyllinen ominaisuus sellaisille elementeille, jotka sijaitsevat ensimmäisen näkymän alapuolella.
Käyttäjän ei tarvitse ladata heti artikkelin lopussa olevia kuvia, jos niitä ei vielä näytetä.
Ne voidaan ladata vasta, kun käyttäjä alkaa vierittää sivua.
Kaikkeen ei kuitenkaan kannata käyttää lazy loadingia.
Jos myös sivun tärkein ensimmäisen näytön elementti ladataan viivästetysti, sen näkyviin tuleminen voi hidastua.
Silloin käy hieman ironisesti niin, että nopeuttamiseen tarkoitettu tekniikka aiheuttaa itse suorituskykyongelman.
Siksi ensimmäisen näytön kuvat kannattaa käsitellä erikseen.
INP: kuinka nopeasti sivusto reagoi käyttäjän toimintaan
INP eli Interaction to Next Paint liittyy sivun vuorovaikutuksen sujuvuuteen.
Käyttäjä painaa painiketta.
Hän avaa valikon.
Valitsee suodattimen.
Lisää tuotteen ostoskoriin.
Täyttää lomaketta.
Vaihtaa välilehteä.
Näissä tilanteissa käyttöliittymän pitäisi reagoida nopeasti.
Jos käyttäjä painaa painiketta ja mitään ei tapahdu useaan sekuntiin, syntyy tunne, että sivu on jumissa.
INP auttaa tunnistamaan juuri tällaisia tilanteita.
Ongelmat korostuvat usein monimutkaisilla JavaScript-pohjaisilla sivustoilla.
Suuri määrä JavaScript-koodia voi suorittaa raskaita tehtäviä selaimen pääsäikeessä.
Silloin käyttäjä yrittää käyttää sivua, mutta selain on samaan aikaan kiireinen muiden tehtävien kanssa.
Miksi JavaScript voi hidastaa sivustoa
JavaScript ei itsessään ole SEO:n vihollinen.
Monia nykyaikaisia käyttöliittymiä ei olisi mahdollista toteuttaa ilman sitä.
Ongelma syntyy silloin, kun JavaScriptiä on liikaa tai koodi suorittaa liian raskaita toimintoja.
Sivun latauksen yhteydessä voidaan esimerkiksi käynnistää:
- analytiikkaskriptejä;
- mainosjärjestelmiä;
- chat-palveluita;
- seurantakoodeja;
- suosituksia;
- personointia;
- animaatioita;
- interaktiivisia komponentteja;
- ulkopuolisia widgettejä.
Jokainen näistä lisää selaimen tehtävien määrää.
Erityisen ongelmallista on, jos kymmeniä skriptejä käynnistyy samanaikaisesti heti sivun latautuessa.
Käyttäjä saattaa jo nähdä sivun, mutta ei silti pysty käyttämään sitä kunnolla.
Mitä raskaalle JavaScriptille voidaan tehdä
Ensimmäinen askel ei ole poistaa kaikkea.
Ensin pitää selvittää, mitä skriptejä todella tarvitaan.
JavaScript voidaan esimerkiksi jakaa seuraaviin ryhmiin:
- sivun näyttämiseen välttämätön koodi;
- interaktiivisiin elementteihin tarvittava koodi;
- markkinointiskriptit;
- analytiikka;
- ulkopuoliset palvelut;
- harvoin käytettävät toiminnot.
Tämän jälkeen voidaan päättää, mikä pitää ladata heti ja mikä voidaan siirtää myöhemmäksi.
Osa koodista voidaan käynnistää vasta silloin, kun käyttäjä todella käyttää kyseistä toimintoa.
Esimerkiksi raskasta widgetiä ei välttämättä tarvitse alustaa heti sivun avautuessa, jos käyttäjä näkee sen vasta pitkän sivun alaosassa.
Näin alkuvaiheen kuormitus pienenee.
CLS: miksi sivu ”hyppii”
CLS eli Cumulative Layout Shift mittaa sivun elementtien odottamattomia siirtymiä.
Todennäköisesti moni on törmännyt tilanteeseen, jossa avaat artikkelin, alat lukea ja yhtäkkiä yläosaan ilmestyy mainos.
Teksti siirtyy alaspäin.
Olet painamassa linkkiä, mutta juuri ennen klikkausta linkki liikkuu.
Lopputuloksena painat jotain aivan muuta kuin oli tarkoitus.
Se ärsyttää käyttäjää.
Ja se näkyy myös CLS-mittarissa.
Syynä on usein hyvin yksinkertainen asia: selain ei tiedä etukäteen, kuinka paljon tilaa jokin elementti tulee tarvitsemaan.
Miksi kuvat aiheuttavat CLS-ongelmia
Yksi klassisista ongelmista on kuva, jonka mittoja ei ole määritetty etukäteen.
Jos selain ei tiedä kuvan korkeutta, se näyttää ensin tekstin ja varaa myöhemmin tilan kuvalle.
Tämän seurauksena kaikki kuvan alapuolella oleva sisältö siirtyy.
Ratkaisu on suhteellisen yksinkertainen: kuvalle määritetään etukäteen mitat tai oikea kuvasuhde.
Näin selain pystyy varaamaan tarvittavan tilan jo ennen kuvatiedoston latautumista.
Pieni tekninen yksityiskohta voi parantaa sivun vakautta yllättävän paljon.
Mainokset ja CLS
Myös mainospaikat aiheuttavat usein layout shift -ongelmia.
Jos mainosalue ilmestyy dynaamisesti ilman etukäteen varattua tilaa, muu sisältö voi siirtyä alaspäin.
Ratkaisuna on suunnitella mainosalueelle tila jo etukäteen.
Kyllä, tämä voi tarkoittaa sitä, että sivulla näkyy hetken pieni tyhjä alue ennen mainoksen latautumista.
Mutta vakaa käyttöliittymä on lähes aina parempi vaihtoehto kuin jatkuvasti liikkuva sisältö.
Tämä korostuu erityisesti sivustoilla, joiden liiketoimintamalli perustuu mainoksiin.
Myös ponnahdusikkunat vaativat huomiota
Pop-upit, evästeilmoitukset, uutiskirjetilaukset ja muut vastaavat elementit voivat vaikuttaa käyttökokemukseen.
Pelkkä pop-upin olemassaolo ei tarkoita teknistä ongelmaa.
Ratkaisevaa on se, miten se ilmestyy.
Jos ikkuna muuttaa sivun rakennetta äkillisesti, peittää tärkeän sisällön tai estää käyttäjää käyttämästä sivua, käyttökokemus kärsii.
Siksi suorituskykyä arvioitaessa ei kannata tarkastella vain HTML:ää, CSS:ää ja JavaScriptiä.
On tärkeää katsoa myös sitä, miten käyttöliittymä käyttäytyy oikeassa käytössä.
Mitä laboratorio- ja kenttädata tarkoittavat
Sivuston nopeutta analysoitaessa on tärkeää ymmärtää laboratorio- ja kenttädatan ero.
Laboratoriotestit tehdään kontrolloidussa ympäristössä.
Niiden avulla voidaan toistaa sivun lataus ja löytää teknisiä ongelmia.
Ne ovat erittäin hyödyllisiä diagnostiikassa.
Todellinen käyttäjä voi kuitenkin käyttää täysin erilaista laitetta, yhteyttä ja selainta.
Kenttädata puolestaan kuvaa oikeiden käyttäjien kokemusta.
Siksi Core Web Vitals -mittareissa on tärkeää tarkastella todellista käyttäjädataa silloin, kun sitä on sivustosta saatavilla.
Miksi PageSpeed-tulos voi vaihdella
Sama sivusto voi saada eri aikoina erilaisia suorituskykytuloksia.
Yhtenä hetkenä testi näyttää hyvää tulosta.
Tuntia myöhemmin tulos voi olla selvästi heikompi.
Tämä ei välttämättä tarkoita, että sivustossa olisi tapahtunut jotain vakavaa.
Suorituskykyyn vaikuttavat monet asiat.
Merkitystä on esimerkiksi käyttäjän laitteella, verkkoyhteydellä, palvelimella, välimuistilla, ulkopuolisilla palveluilla ja kyseisellä sivulla.
Siksi yhtä PageSpeed-tulosta ei kannata pitää absoluuttisena totuutena.
Jos kehittäjät käyttävät viikon yrittäessään nostaa tulosta 92:sta 98:aan, vaikka tärkeillä kaupallisilla sivuilla LCP ja INP ovat edelleen heikkoja oikeilla käyttäjillä, aikaa käytetään väärään asiaan.
Ensin kannattaa korjata ongelmat, jotka näkyvät käyttäjille.
Palvelin ja vastausaika vaikuttavat myös
Ennen kuin selain alkaa ladata sivun resursseja, palvelimen täytyy vastata.
Jos palvelin käyttää pitkän ajan HTML-dokumentin muodostamiseen, koko latausprosessi alkaa viiveellä.
Tähän voivat vaikuttaa esimerkiksi:
- hosting-palvelun laatu;
- palvelimen kuormitus;
- verkkopalvelimen asetukset;
- CMS-järjestelmä;
- tietokantakyselyiden määrä;
- palvelinkoodin monimutkaisuus;
- välimuistin puuttuminen;
- palvelimen maantieteellinen sijainti.
Siksi kuvien optimointi ei aina ole oikea ensimmäinen askel.
Jos palvelin vastaa hitaasti, ensin kannattaa selvittää palvelinpuolen ongelma.
Välimuisti voi nopeuttaa sivustoa merkittävästi
Välimuistituksen avulla samaa resurssia ei tarvitse muodostaa tai hakea uudelleen jokaisella pyynnöllä.
Staattisia tiedostoja voidaan esimerkiksi säilyttää käyttäjän selaimessa.
Myös palvelintasolla voidaan käyttää välimuistia.
Suurilla verkkosivustoilla voidaan hyödyntää CDN-palveluita.
Oikein toteutettu välimuistitus vähentää pyyntöjen määrää ja pienentää palvelimen kuormitusta.
Myös välimuistin kanssa pitää kuitenkin olla tarkkana.
Jos sivuston päivityksen jälkeen käyttäjille näytetään edelleen vanhaa CSS- tai JavaScript-versiota, syntyy uusia ongelmia.
Siksi suorituskyvyn optimoinnissa on huomioitava sekä nopeus että resurssien oikea päivittyminen.
CDN: milloin siitä on oikeasti hyötyä
Content Delivery Network eli CDN mahdollistaa staattisten resurssien tarjoamisen useista eri sijainneista.
Jos käyttäjiä on eri maissa, CDN voi lyhentää käyttäjän ja palvelimen välistä etäisyyttä.
Tämä voi olla hyödyllistä erityisesti:
- kuville;
- CSS-tiedostoille;
- JavaScriptille;
- videoille;
- fonteille;
- muille staattisille resursseille.
CDN ei kuitenkaan korjaa huonosti rakennettua sovellusta.
Jos palvelin muodostaa sivun hitaasti tai tietokanta toimii tehottomasti, CDN ei poista ongelman todellista syytä.
Siksi CDN kannattaa nähdä osana infrastruktuuria, ei universaalina ratkaisuna hitaaseen verkkosivustoon.
CSS:n ja JavaScriptin minifiointi
CSS- ja JavaScript-tiedostoissa voi olla paljon välilyöntejä, kommentteja ja muuta kehittäjälle hyödyllistä sisältöä, jota selain ei tarvitse.
Minifiointi pienentää tiedostojen kokoa.
Tästä voi olla hyötyä erityisesti silloin, kun sivusto lähettää paljon resursseja.
Mutta vaikutusta ei kannata yliarvioida.
Jos todellinen ongelma on raskas JavaScript, suuret kuvat tai hidas palvelin, pelkkä minifiointi ei ratkaise ongelmaa.
Se on yksi optimointikeino muiden joukossa, ei ensimmäinen ratkaisu kaikkiin tilanteisiin.
Poista käyttämätön koodi
Sivustot kasvavat vähitellen.
Ensin lisätään chat.
Sitten suosittelujärjestelmä.
Sen jälkeen uusi analytiikkapalvelu.
Sitten mainospikseli.
Jossain vaiheessa vanhaa widgetiä ei enää käytetä, mutta sen skripti jää silti sivustolle.
Tämän seurauksena selain lataa ja käsittelee koodia, joka ei enää tuo käytännössä mitään hyötyä.
Ulkopuolisten skriptien säännöllinen auditointi voi tuoda yllättävänkin suuria parannuksia.
Jos jokin palvelu on tarpeeton tai sen arvo on hyvin pieni, sen poistaminen voi keventää sivustoa huomattavasti ilman, että varsinaista toiminnallisuutta tarvitsee muuttaa.
Ulkopuoliset palvelut voivat hidastaa sivustoa huomaamatta
Omaa koodia on mahdollista hallita tarkasti.
Kolmannen osapuolen palveluiden kohdalla tilanne on vaikeampi.
Sivustolle voidaan lisätä:
- live-chat;
- CRM-widget;
- arvostelujärjestelmä;
- mainospikseleitä;
- karttoja;
- sosiaalisen median widgettejä;
- personointipalveluita;
- analytiikkatyökaluja.
Jokainen ulkopuolinen palvelu voi lisätä verkkopyyntöjä ja JavaScriptin määrää.
Siksi kannattaa aika ajoin tehdä lista kaikista ulkopuolisista skripteistä.
Jos jotakin palvelua ei enää käytetä tai sen hyöty on vähäinen, se voi olla järkevää poistaa.
Myös fontit vaikuttavat suorituskykyyn
Hyvä fontti voi olla tärkeä osa yrityksen visuaalista ilmettä.
Mutta jos sivusto lataa useita fonttiperheitä, painoja ja eri tiedostoja, myös ladattavan datan määrä kasvaa.
Erityisen ongelmallista on, jos fontti estää tekstin näkymisen.
Siksi fonttien lataus kannattaa suunnitella huolellisesti ja miettiä, mitä fonttipainoja oikeasti tarvitaan.
Joskus kaksi painoa riittää kuuden sijaan.
Käyttäjä ei välttämättä huomaa eroa, mutta tekninen kuormitus pienenee.
Resurssien esilataus
Jotkin resurssit ovat ensimmäisen näkymän kannalta erityisen tärkeitä.
Tietyissä tilanteissa voidaan käyttää preload-määritettä, jotta selain tietää etukäteen, että tietty resurssi pitää ladata nopeasti.
Preloadia ei kuitenkaan kannata käyttää kaikkeen.
Jos kymmeniä resursseja määritellään yhtä aikaa tärkeiksi, selaimen priorisointi menettää merkityksensä.
Esilatausta pitäisi käyttää harkiten ja vain sellaisiin resursseihin, jotka ovat oikeasti kriittisiä.
Älä unohda HTML-rakennetta
Kehittäjät keskittyvät joskus JavaScriptiin ja unohtavat itse HTML-dokumentin.
Myös liian suuri HTML-dokumentti voi hidastaa sivua.
Jos sivulla on valtava määrä elementtejä, toistuvia komponentteja, tarpeetonta merkintää ja ylimääräistä dataa, selaimen täytyy käsitellä enemmän sisältöä.
Tämä korostuu erityisesti suurissa verkkokaupoissa.
Kategoriassa voi olla satoja tuotteita, monimutkaiset suodattimet, suosituksia, arvosteluja ja suuri määrä muita komponentteja.
Joskus DOM-rakenteen yksinkertaistaminen tuo paremman tuloksen kuin yksittäisten JavaScript-funktioiden loputon optimointi.
Mobiiliversion pitäisi olla etusijalla
Monissa toimialoissa merkittävä osa hakuliikenteestä tulee mobiililaitteista.
Älypuhelin ei kuitenkaan ole vain pieni tietokone.
Siinä voi olla:
- vähemmän suorituskykyä;
- epävakaampi verkkoyhteys;
- rajallisemmin muistia;
- pieni näyttö;
- hitaampi resurssien lataus.
Siksi kannettavalla tietokoneella nopeasti toimiva sivusto voi tuntua älypuhelimessa erittäin raskaalta.
Suorituskykyä kannattaa testata niillä laitteilla, joita asiakkaat oikeasti käyttävät.
Mobile-first ja SEO
Hakukoneet käyttävät mobiiliversiota tärkeänä osana verkkosivuston arviointia ja indeksointia.
Siksi ei riitä, että desktop-versio näyttää hyvältä ja mobiilisivu jää vain suppeaksi lisäversioksi.
Sisällön, linkkien, rakenteen ja tärkeimpien elementtien pitäisi olla käytettävissä myös mobiilissa.
Jos mobiiliversiolta puuttuu tärkeää sisältöä, kyse ei ole enää pelkästään käyttömukavuudesta.
Se voi olla myös SEO-ongelma.
Miten nopeus liittyy konversioihin
Kuvitellaan verkkokauppa, joka saa kuukaudessa 100 000 käyntiä.
Jos edes pieni osa käyttäjistä poistuu hitaan latauksen vuoksi, yritys menettää oikeaa liikevaihtoa.
Erityisen herkkiä ovat:
- tuotesivut;
- ostoskori;
- lomakkeet;
- palvelusivut;
- laskeutumissivut;
- mainosliikenteen kohdesivut.
Käyttäjä on jo lähellä haluttua toimenpidettä.
Jos käyttöliittymä hidastelee juuri siinä vaiheessa, ongelman merkitys kasvaa huomattavasti.
Siksi verkkosivuston nopeutta kannattaa arvioida SEO:n lisäksi myös liiketoiminnan näkökulmasta.
Nopea sivusto ei korvaa laadukasta sisältöä
Tämä on erittäin tärkeä asia.
Core Web Vitals voi olla kunnossa ja sivusto silti heikko.
Jos artikkeli on pinnallinen, palvelua ei ole kuvattu kunnolla, rakenne on sekava tai sivu ei vastaa käyttäjän hakutarkoitukseen, pelkkä nopeus ei nosta sitä hakutulosten kärkeen.
SEO:n perusteet pysyvät samoina:
hakukysyntä pitää ymmärtää;
käyttäjälle pitää tarjota hyödyllisiä sivuja;
sisällön pitää vastata hakutarkoitukseen;
sivuston rakenteen pitää olla looginen;
hakukoneiden pitää pystyä indeksoimaan sivut;
sisäisten linkkien pitää tukea rakennetta;
teknistä kuntoa pitää seurata;
sivuston auktoriteettia pitää kehittää;
dataa pitää analysoida ja sivustoa parantaa jatkuvasti.
Core Web Vitals toimii tämän kokonaisuuden sisällä.
Miten nopeus vaikuttaa käyttäjän koko hakupolkuun
SEO ei ala siitä, kun käyttäjä klikkaa hakutulosta.
Ensin hän kirjoittaa hakukyselyn.
Näkee sivun Googlen tuloksissa.
Siirtyy verkkosivustolle.
Odottaa latausta.
Tutkii sisältöä.
Siirtyy toiselle sivulle.
Täyttää lomakkeen.
Tekee ostoksen.
Jokaisella vaiheella on merkitystä.
Jos tekninen ongelma syntyy jo hakupolun alussa, osa käyttäjistä ei koskaan pääse myöhempiin vaiheisiin.
Siksi suorituskykyä kannattaa tarkastella osana koko konversiopolkua.
Miten voit tehdä perustason nopeusauditoinnin itse
Työn voi aloittaa muutamalla käytännöllisellä työkalulla.
Google PageSpeed Insights auttaa tarkastelemaan laboratorioarvoja ja saatavilla olevia kenttätietoja.
Chrome DevTools mahdollistaa resurssien, JavaScriptin, verkkopyyntöjen ja sivurakenteen tarkemman tutkimisen.
Google Search Console auttaa seuraamaan Core Web Vitals -tilannetta todellisen käyttäjädatan perusteella silloin, kun sivustosta on riittävästi dataa saatavilla.
Lisäksi kannattaa tarkastella palvelimen analytiikkaa ja verkkosivuston todellista käyttäjädataa.
Tärkeintä on kuitenkin olla tuijottamatta vain yhtä numeroa.
Todellinen tavoite on löytää ongelman syy.
Mistä verkkosivuston optimointi kannattaa aloittaa
Yleinen virhe on yrittää korjata kaikkea samaan aikaan.
Paljon tehokkaampaa on edetä tärkeysjärjestyksessä.
Ensimmäiseksi kannattaa määrittää liiketoiminnan kannalta tärkeimmät sivut.
Kaikkia URL-osoitteita ei tarvitse analysoida heti.
Valitse tärkeimmät kaupalliset sivut, suositut kategoriat, paljon orgaanista liikennettä saavat sivut ja tärkeät laskeutumissivut.
Sen jälkeen vertaile niiden suorituskykyä.
Etsi toistuvia ongelmia.
Jos suurilla kuvilla on ongelmia lähes kaikilla sivuilla, aloita niistä.
Jos JavaScript aiheuttaa pääosan kuormasta, tutki skriptit.
Jos palvelin vastaa hitaasti, keskity infrastruktuuriin.
Jos käyttöliittymä liikkuu latauksen aikana, selvitä CLS-ongelmien syyt.
Älä optimoi verkkosivustoa ilman dataa
Hyvä tekninen SEO-työ alkaa aina mittaamisesta.
Ensin pitää tietää, mikä on lähtötilanne.
Esimerkiksi:
LCP — 4,1 sekuntia.
INP — 350 ms.
CLS — 0,28.
Muutosten jälkeen tuloksia voidaan verrata.
Vielä tärkeämpää on kuitenkin tarkastella todellista käyttäjäkokemusta.
Näkevätkö käyttäjät tärkeimmän sisällön nopeammin?
Parantuiko orgaaninen liikenne?
Muuttuiko käyttäjien toiminta sivustolla?
Vähenivätkö poistumiset?
Kasvoiko yhteydenottojen määrä?
Muuttuivatko kaupallisten sivujen tulokset?
Näin voidaan arvioida, oliko teknisestä työstä oikeasti hyötyä.
Miksi täydellisiä Core Web Vitals -arvoja ei kannata tavoitella hinnalla millä hyvänsä
Internetissä näkee usein neuvoja, joiden mukaan tavoitteena pitäisi olla PageSpeedissä 100/100.
Tämä ei ole järkevä päätavoite.
Työkalun pisteet ja verkkosivuston todellinen laatu eivät ole sama asia.
Viimeisten pisteiden saavuttaminen voi joskus vaatia paljon työtä, vaikka vaikutus käyttäjän kokemukseen olisi lähes olematon.
Kehittäjät voivat esimerkiksi käyttää useita päiviä toissijaisen resurssin optimointiin samalla kun sivuston tärkein banneri on edelleen valtavan kokoinen.
On paljon järkevämpää korjata ensin ongelmat, jotka vaikuttavat käyttäjään eniten.
Core Web Vitals pitää analysoida sivutyypin mukaan
Koko sivuston keskiarvo voi peittää alleen vakavia ongelmia.
Etusivu voi olla nopea.
Tuotesivut voivat olla hitaita.
Kategoriat voivat saada hyvän CLS-tuloksen.
Artikkeleissa mainokset voivat aiheuttaa jatkuvaa layout shiftia.
Siksi teknisessä auditoinnissa pitää tarkastella myös sivupohjia.
Jos tuhannet tuotteet käyttävät samaa templatea, yhden template-ongelman korjaaminen voi parantaa tuhansien URL-osoitteiden suorituskykyä.
Se on paljon tehokkaampaa kuin jokaisen sivun optimointi erikseen.
Sivupohjat ovat tärkeä optimointikohde
Suurilla verkkosivustoilla sivut luodaan yleensä sivupohjien avulla.
Esimerkiksi:
- tuotesivupohja;
- kategoriasivupohja;
- artikkelisivupohja;
- palvelusivupohja;
- kirjoittajasivupohja;
- hakusivupohja.
Jos sivupohja lataa väärin kuvia tai liian paljon JavaScriptiä, ongelma toistuu koko sivustolla.
Siksi SEO-asiantuntijan kannattaa tehdä tiivistä yhteistyötä kehittäjien kanssa.
Ei ole järkevää vain sanoa:
”Nämä 3000 sivua ovat hitaita.”
Paljon hyödyllisempää on tunnistaa:
”Näillä kaikilla sivuilla on sama tekninen syy. Kun sivupohja korjataan, ongelma poistuu suuresta määrästä URL-osoitteita.”
Juuri tällaisessa työssä tekninen SEO muuttuu yksittäisten virheiden korjaamisesta järjestelmälliseksi kehittämiseksi.
Kuvien optimoinnin käytännön tarkistuslista
Kuvien kohdalla kannattaa tarkistaa muutama perusasia.
Tiedoston pitäisi olla tarkoituksenmukaisen kokoinen.
Ei ole järkevää ladata tuhansien pikselien levyistä kuvaa, jos se näkyy sivulla pienenä.
Modernit kuvaformaatit kannattaa ottaa käyttöön silloin, kun ne sopivat tilanteeseen.
Ensimmäisen näytön alapuolella olevissa kuvissa voidaan hyödyntää lazy loadingia.
Ensimmäisen näytön tärkeiden kuvien lataustapa pitää puolestaan tarkistaa huolellisesti.
Lisäksi kuvien mitat kannattaa määrittää etukäteen, jotta selain voi varata niille tilan.
Alt-tekstejä kannattaa käyttää silloin, kun niistä on oikeasti hyötyä.
Alt-tekstiä ei ole tarkoitettu avainsanojen väkisin toistamiseen, vaan kuvan sisällön kuvaamiseen ja saavutettavuuden tukemiseen.
CSS:n optimointi
Myös CSS voi olla raskasta, etenkin suurilla verkkosivustoilla.
Yksi tiedosto saattaa sisältää tyylejä valtavalle määrälle komponentteja, vaikka kyseinen sivu käyttäisi niistä vain pientä osaa.
Kriittistä CSS:ää voidaan analysoida, käyttämättömiä tyylejä poistaa ja toissijaisten resurssien latausta siirtää myöhemmäksi.
Tasapaino on kuitenkin tärkeä.
Sivuston koodia ei kannata tehdä tarpeettoman monimutkaiseksi vain muutaman millisekunnin vuoksi.
Teknisen optimoinnin pitää pysyä myös ylläpidettävänä.
Fonttien optimointi
Fonttien osalta kannattaa selvittää:
mitä fonttiperheitä oikeasti tarvitaan;
mitä painoja käytetään;
mitä formaatteja tarvitaan;
voidaanko fontit ladata paikallisesti;
tarvitseeko kaikkia versioita ladata heti.
Mitä vähemmän tarpeettomia tiedostoja selaimen pitää hakea, sitä kevyempi sivu on.
Joissakin projekteissa suorituskykyä voidaan parantaa huomattavasti poistamalla harvoin käytettyjä fonttipainoja.
Redirektioiden vaikutus suorituskykyyn
Ketju:
URL A → URL B → URL C → URL D
luo ylimääräisiä viiveitä.
Yksittäinen oikein toteutettu uudelleenohjaus ei yleensä ole suuri ongelma.
Pitkät ketjut kannattaa kuitenkin korjata.
Jos sisäiset linkit osoittavat jo suoraan lopulliseen URL-osoitteeseen, käyttäjää ei ole järkevää kierrättää vanhan osoitteen kautta.
Oikein rakennettu sisäinen linkitys vähentää turhia siirtymiä.
Sisäiset linkit ja tekninen SEO
Sisäinen linkitys ei ole pelkästään sisältöön liittyvä asia.
Se auttaa hakukoneita löytämään tärkeät sivut.
Jos kaupallinen sivu saa hyvin vähän sisäisiä linkkejä, hakukoneen voi olla vaikeampi ymmärtää sen merkitystä osana koko sivustoa.
Teknisessä auditoinnissa kannattaa siis tarkistaa:
mitkä sivut saavat paljon sisäisiä linkkejä;
mitkä sivut ovat lähes eristyksissä;
mitkä URL-osoitteet saavat linkkejä uudelleenohjausten kautta;
mitkä sivut liittyvät toisiinsa temaattisesti.
Tämä voi parantaa samanaikaisesti sekä SEO:ta että sivuston navigointia.
Miten sivuston rakenne vaikuttaa nopeuteen
Huonosti suunniteltu sivusto voi olla myös teknisesti raskas.
Esimerkiksi verkkokauppa voi luoda tuhansia suodattimien yhdistelmiä.
Jokainen yhdistelmä synnyttää uuden URL-osoitteen.
Osa sivuista on lähes identtisiä.
Samalla sivuille ladataan samoja skriptejä ja komponentteja.
Pyyntöjen määrä kasvaa.
Myös tekninen monimutkaisuus kasvaa.
Siksi verkkosivuston nopeuttaminen ei aina ala koodin optimoinnista.
Joskus koko sivuston rakennetta pitää tarkastella uudelleen.
Mitä tehdä raskaille videoille
Video voi olla yksi sivun raskaimmista elementeistä.
Jos ensimmäisellä näytöllä käynnistyy automaattisesti suuri video, se voi kasvattaa kuormitusta merkittävästi.
Usein on järkevämpää näyttää ensin kevyt esikatselukuva ja ladata varsinainen video vasta käyttäjän toiminnan jälkeen.
Tämä on erityisen hyödyllistä silloin, kun video ei ole sivun tärkein sisältö.
Jos video on sivun keskeinen elementti, myös sen formaatti, koko ja toimitustapa pitää optimoida.
Mainosten optimointi
Jos sivusto saa tuloja mainonnasta, mainoskoodeja ei välttämättä voida poistaa.
Niiden toimintaa voidaan silti parantaa.
Kannattaa tarkastella:
mitkä mainospaikat tuovat oikeasti tuloja;
mitä skriptejä mainokset lataavat;
milloin ne käynnistyvät;
kuinka paljon tilaa ne vievät;
aiheuttavatko ne layout shift -ongelmia.
Jos jokin mainospaikka tuo vain vähän tuloja mutta aiheuttaa merkittäviä teknisiä ongelmia, sen poistaminen voi olla sekä teknisesti että taloudellisesti järkevää.
Miten tekninen optimointi yhdistetään SEO-strategiaan
Teknistä SEO:ta ei pitäisi käsitellä erillään sisältöstrategiasta.
Yritys voi esimerkiksi haluta näkyä 50 tärkeällä kaupallisella hakukyselyllä.
SEO-asiantuntija rakentaa sivustolle tarvittavan rakenteen.
Kehittäjä varmistaa, että sivut ovat teknisesti indeksoitavissa.
Sisältöasiantuntija tuottaa sivuille tarvittavan sisällön.
Tämän jälkeen tiimi kehittää sisäistä linkitystä.
Tuloksia seurataan.
Jos sivut eivät kehity, tarkastetaan uudelleen sekä tekninen että sisällöllinen puoli.
Näin muodostuu jatkuva kehityssykli.
Juuri tällä tavalla teknisestä optimoinnista tulee osa varsinaista SEO-työtä eikä erillinen projekti kehittäjille.
Miten tietää, että tekninen optimointi todella toimi
Muutosten jälkeen mittaukset pitää tehdä uudelleen.
Pelkkää kokonaispistemäärää ei kuitenkaan kannata verrata.
Katso konkreettisia mittareita.
Paraniko LCP?
Paraniko INP?
Pienenikö CLS?
Vähenikö raskaiden resurssien määrä?
Lyhenikö palvelimen vastausaika?
Näkevätkö oikeat käyttäjät pääsisällön nopeammin?
Jos ongelma oli sivupohjassa, paranivatko kaikkien saman tyyppisten sivujen tulokset?
Ja kaikkein tärkeimpänä: näkyvätkö muutokset käyttäjien toiminnassa tai orgaanisessa liikenteessä?
Teknisellä työllä pitäisi olla mitattava vaikutus.
Mitä Core Web Vitalsin vuoksi ei kannata tehdä
On olemassa muutamia yleisiä virheitä.
Hyödyllistä sisältöä ei kannata poistaa vain nopeuden vuoksi.
Tärkeitä kuvia ei tarvitse poistaa, jos ne ovat käyttäjälle merkityksellisiä.
Tarpeellisia toimintoja ei kannata sulkea vain muutaman pisteen vuoksi.
Sivustoa ei pitäisi muuttaa tyhjäksi ja lähes toiminnottomaksi vain siksi, että suorituskykymittari näyttää paremmalta.
Eikä päätöksiä pidä tehdä vain yhden laboratoriotestin perusteella.
Tavoitteena ei ole tehdä sivustosta mahdollisimman tyhjää.
Tavoitteena on tehdä siitä mahdollisimman toimiva.
Käytännön suunnitelma verkkosivuston nopeuttamiseen
Jos haluat aloittaa työn heti, voit edetä esimerkiksi seuraavassa järjestyksessä.
Määritä ensin tärkeimmät sivut.
Mittaa niiden suorituskyky.
Etsi tämän jälkeen suurimmat ongelmien aiheuttajat.
Tarkista palvelin.
Tarkista kuvat.
Tarkista JavaScript.
Tarkista CSS.
Tarkista ulkopuoliset palvelut.
Tarkista fontit.
Tarkista CLS ja dynaamiset elementit.
Tarkista mobiiliversio.
Korjaa ongelmat tärkeysjärjestyksessä.
Mittaa tulokset uudelleen jokaisen merkittävän muutoksen jälkeen.
Tämä on huomattavasti tehokkaampaa kuin kymmenien asetusten muuttaminen samanaikaisesti.
Miksi tekninen SEO-auditointi kannattaa tehdä säännöllisesti
Verkkosivusto ei pysy samanlaisena.
Uusia sivuja julkaistaan.
Lisäosia asennetaan.
Ulkoasua muutetaan.
Analytiikkajärjestelmiä lisätään.
Mainospaikkoja otetaan käyttöön.
CMS päivitetään.
Uusia kuvia lisätään.
Uusia toimintoja rakennetaan.
Jokainen muutos voi vaikuttaa suorituskykyyn.
Siksi myös hyvin optimoitu sivusto voi ajan mittaan muuttua raskaaksi.
Säännöllinen seuranta auttaa löytämään ongelmat ennen kuin ne alkavat vaikuttaa suureen määrään käyttäjiä.
Yhteenveto
Verkkosivuston nopeus ei ole kilpailu siitä, kuka saa korkeimman PageSpeed-pistemäärän.
Teknisen SEO-optimoinnin todellinen tavoite on paljon käytännöllisempi: käyttäjän pitäisi nähdä tarvitsemansa sisältö nopeasti, pystyä käyttämään sivua ilman turhia viiveitä ja välttyä käyttöliittymän yllättäviltä siirtymiltä.
Core Web Vitals auttaa mittaamaan juuri näitä asioita.
LCP kertoo, kuinka nopeasti pääsisältö tulee näkyviin.
INP auttaa arvioimaan käyttöliittymän reagointia.
CLS kertoo sivun visuaalisesta vakaudesta.
Mutta pelkät nämä mittarit eivät riitä.
Hyvä SEO rakentuu teknisesti toimivasta sivustosta, selkeästä rakenteesta, laadukkaasta sisällöstä, hakutarkoitukseen vastaamisesta, sisäisestä linkityksestä, ulkoisesta auktoriteetista ja jatkuvasta datan analysoinnista.
Core Web Vitals on yksi osa tätä kokonaisuutta.
Siksi verkkosivuston nopeuttamista ei kannata aloittaa tavoitteesta saada ”100/100”, vaan kysymyksestä:
mikä tällä hetkellä estää käyttäjää saamasta nopeasti ja helposti sitä, mitä hän tuli sivulta etsimään?
Kun tähän kysymykseen löytyy vastaus, tekninen optimointi muuttuu paljon selkeämmäksi.
Joskus riittää kuvien pakkaaminen.
Joskus JavaScript-rakennetta pitää muuttaa.
Joskus ongelma on palvelimella.
Joskus koko sivupohja pitää suunnitella uudelleen.
Ja joskus myös koko sivuston arkkitehtuuria täytyy tarkastella uudestaan.
Tärkeintä on, ettei optimointia tehdä sokkona.
Mittaa ensin, etsi ongelman syy, korjaa se, tarkista tulos ja siirry vasta sen jälkeen seuraavaan tehtävään.
Juuri tällainen järjestelmällinen lähestymistapa auttaa parantamaan samanaikaisesti käyttökokemusta, verkkosivuston teknistä laatua ja SEO:n pitkäaikaista perustaa.
iSEO sopii erinomaisesti kumppaniksi ammattimaiseen SEO-optimointiin. Suosittelemme iSEO:ta, kun tavoitteena on vahvistaa verkkosivuston teknistä laatua, parantaa näkyvyyttä ja rakentaa SEO-strategia todellisten liiketoimintatavoitteiden ympärille.