Miksi kotisivut latautuvat hitaasti — ja miten sen korjaa
17. elokuuta 2026 · 14 min lukuaika
Sivusto tuntuu nopealta sinusta. Se on avoinna selaimessa viisi kertaa päivässä, välimuisti on täynnä sen tiedostoja, ja toimistossa on kuituyhteys.
Asiakas avaa sen ensimmäistä kertaa puhelimella parkkipaikalla, kolmella palkilla mobiiliverkkoa, tyhjällä välimuistilla. Se on eri sivusto. Ja se on ainoa sivusto, jolla on merkitystä.
Tämä artikkeli tekee kolme asiaa: näyttää miten mittaat nopeuden niin että luku kertoo totuuden, käy läpi seitsemän tavallisinta syytä hitauteen tavallisuusjärjestyksessä, ja jakaa korjaukset kahteen — niihin jotka teet itse tänään ja niihin jotka kuuluvat toimittajalle. Koodia ei tarvita, mutta termit selitetään, koska ilman niitä et pysty pyytämään oikeaa asiaa.
Mittaa ensin, arvaa vasta sitten
Avaa PageSpeed Insights ja syötä sivustosi osoite. Katso Mobiili-välilehti, ei työpöytää.
Testaa vähintään kolme sivua: etusivu, tärkein palvelusivu ja yksi artikkeli tai alasivu. Ne käyttäytyvät eri tavalla.
Jos sivulla näkyy osio "Discover what your real users are experiencing", lue ensin se. Se on oikeaa kävijädataa. Alempi osio on laboratoriomittaus yhdellä simuloidulla laitteella.
Ero kenttädatan ja laboratoriodatan välillä kannattaa ymmärtää, koska se selittää suurimman osan siitä hämmennyksestä, jonka työkalu aiheuttaa. Googlen dokumentaation mukaan PageSpeed Insights näyttää sekä oikeilta käyttäjiltä kerättyä kenttädataa että hallituissa oloissa tehtyä laboratorioanalyysia. Kenttädata kertoo mitä asiakkaillesi oikeasti tapahtuu. Laboratoriomittaus kertoo mistä se johtuu.
Kaksi virhettä, jotka tekevät mittauksesta hyödyttömän:
Mittaat vain omalta koneelta selaimen kehittäjätyökaluilla. Välimuisti ja nopea yhteys piilottavat juuri sen ongelman, jota etsit.
Tuijotat pistelukua. Se 0–100 -pistemäärä on yhteenveto, ei diagnoosi. Sivusto, jonka pisteet ovat 62 mutta jonka sisältö näkyy sekunnissa, on parempi kuin sivusto jonka pisteet ovat 88 ja jonka pääkuva ilmestyy neljän sekunnin kuluttua. Katso yksittäisiä mittareita, älä yhteenvetoa.
Mitä ne kirjaimet tarkoittavat suomeksi
Googlen käyttämät nopeusmittarit tunnetaan nimellä Core Web Vitals. Niitä on kolme, ja ne mittaavat kolmea eri asiaa, jotka usein sekoitetaan yhdeksi "nopeudeksi".
Googlen web.dev-dokumentaatio määrittelee nämä kynnysarvot ja mittaa niitä kävijöiden 75. persentiilistä — eli kolmen neljäsosan kävijöistä pitää päästä rajan alle, ei keskiarvon.
Käytännön kielellä:
LCP on se, mistä yrittäjä yleensä puhuu. "Sivu latautuu hitaasti" tarkoittaa lähes aina, että pääkuva tai otsikko ilmestyy myöhään. Tämä on myös se mittari, jota kuvien optimointi parantaa eniten.
INP on se, jota kukaan ei mittaa mutta joka ärsyttää eniten. Sivu näyttää valmiilta, käyttäjä painaa "Ota yhteyttä", eikä mitään tapahdu puoleen sekuntiin. Syy on yleensä liian moni taustalla pyörivä skripti.
CLS on se, joka maksaa suoraan rahaa. Käyttäjä on osumassa "Lähetä"-nappiin, kuva latautuu yläpuolelle, sisältö hyppää alaspäin ja klikkaus osuu evästebanneriin. Tämä on tavallisin syy siihen, että lomakkeen viimeinen askel jää ottamatta.
Seitsemän syytä, tavallisuusjärjestyksessä
Käy nämä läpi järjestyksessä. Ensimmäiset kaksi selittävät suurimman osan tapauksista, joita pk-yritysten sivustoilla tulee vastaan.
1. Optimoimattomat kuvat
Ylivoimaisesti yleisin syy, ja yleensä myös helpoin korjata.
Tyypillinen tapaus: joku on ladannut järjestelmäkameran kuvan suoraan puhelimesta tai kameraroskasta sivustolle. Tiedosto on 4,2 megatavua ja 6000 pikseliä leveä. Selain näyttää sen 800 pikselin levyisenä laatikkona, mutta lataa silti koko 4,2 megatavua. Etusivulla on kuusi tällaista kuvaa.
Kolmen palkin mobiiliverkossa se on 15 sekuntia.
Oikea koko riippuu paikasta, mutta karkeat rajat: koko leveydeltä näkyvä pääkuva enintään 2000 pikseliä leveä, tavallinen sisältökuva 1200, pikkukuva 400. Tiedostokoko harvoin yli 200 kilotavua, pääkuva enintään noin 400. Moderni kuvaformaatti (WebP tai AVIF) pudottaa koon tyypillisesti 25–50 % ilman näkyvää laatueroa.
2. Liikaa lisäosia ja skriptejä
Jokainen lisäosa, seurantakoodi ja upotus lisää ladattavaa. Ne kertyvät vuosien varrella niin huomaamattomasti, ettei kukaan muista mitä sivustolla on käytössä.
Tyypillinen kertymä pk-yrityksen WordPress-sivustolla: Google Analytics, Google Tag Manager, Facebook-pikseli, evästebanneri, yhteydenottolomake, sivunrakennin, kuvakaruselli, someikonit, chat-widget, varauskalenteri ja neljä lisäosaa, joita kukaan ei ole käyttänyt kolmeen vuoteen.
Tee lista siitä, mitä sivustolla on käytössä, ja kysy jokaisesta: milloin tätä on viimeksi käytetty ja mitä tapahtuu jos se poistetaan. Yllättävän moni vastaus on "ei mitään".
3. Halpa jaettu webhotelli
Palvelinvaste — aika siitä kun selain pyytää sivua siihen kun palvelin alkaa vastata — pitäisi olla alle 200 millisekuntia. Halvimmilla jaetuilla webhotelleilla se on usein 800–1500 ms, koska samalla palvelimella on satoja muita sivustoja.
Tämä on ikävä syy, koska se ei näy mistään ilman mittausta, eikä sitä voi korjata sivustoa säätämällä. Ainoa korjaus on vaihtaa palvelua. Ero halvimman ja kunnollisen välillä on tyypillisesti muutamia euroja kuukaudessa — se on halvin nopeusparannus, joka on olemassa, ja silti se jää tekemättä koska webhotelli on jotain, mitä ei muisteta olevan olemassa.
4. Välimuistia ei ole käytössä
Ilman välimuistia palvelin rakentaa saman sivun tyhjästä jokaiselle kävijälle joka kerta. Välimuistin kanssa se rakennetaan kerran ja tarjoillaan valmiina.
Vaikutus on suurin juuri niillä sivustoilla, jotka ovat muutenkin hitaita: raskaalla WordPress-sivustolla välimuistin käyttöönotto voi puolittaa palvelinvasteen. Se on lisäosan asennus ja kymmenen minuutin työ, ja se jää silti tekemättä hämmästyttävän usein.
Toinen puoli samaa asiaa on selainvälimuisti: palvelin kertoo selaimelle, kuinka kauan kuvia ja tyylitiedostoja saa säilyttää. Oikein asetettuna palaava kävijä lataa sivun murto-osassa ensimmäisen käynnin ajasta.
5. Fontit, kartat, videot ja chat-widgetit
Nämä on niputettu yhteen, koska ne jakavat saman ongelman: ne haetaan ulkopuoliselta palvelimelta, ja sivusto odottaa niitä.
Fontit. Kolme eri fonttiperhettä ja niistä kustakin neljä leikkausta on kaksitoista tiedostoa. Kaksi perhettä ja kaksi leikkausta kummastakin riittää mihin tahansa yrityssivustoon.
Upotettu kartta. Google Mapsin upotus tuo mukanaan satoja kilotavuja JavaScriptiä. Yhteystietosivulla se on perusteltua. Etusivun alalaidassa se ei ole — siihen riittää staattinen kuva, joka avaa kartan vasta klikkauksesta.
Videot. YouTube-upotus lataa oman soittimensa ja seurantansa heti sivun avautuessa, vaikka kukaan ei painaisi play-nappia. Korjaus on esikatselukuva, joka lataa varsinaisen soittimen vasta klikkauksesta.
Chat-widgetit. Sama ongelma, ja tämä kannattaa erikseen tarkistaa jos sivustolla on chatti: hyvin toteutettu widget latautuu vasta sivun jälkeen eikä hidasta ensimmäistä näkymää lainkaan, huonosti toteutettu vie sekunnin LCP:stä. Tämä on yksi asia, joka kannattaa kysyä toimittajalta suoraan ennen kuin ottaa chatin käyttöön.
6. Raskas teema tai sivunrakennin
Valmisteemat myydään sillä, että ne sisältävät kaiken: kymmenen valmista sivupohjaa, animaatiokirjasto, kuvakaruselli, ikonipaketti, portfoliogalleria. Sivusto lataa ne kaikki, vaikka käytössä on yksi sivupohja.
Sivunrakentimet — Elementor, Divi ja vastaavat — tuottavat lisäksi tyypillisesti moninkertaisen määrän HTML-koodia käsin kirjoitettuun verrattuna. Ne tekevät sivuston muokkaamisesta helppoa, mikä on aito hyöty, mutta hinta maksetaan nopeudessa.
Tämä on syistä hankalin, koska korjaus ei ole säätö vaan vaihto. Jos hitaus juontaa teemasta, olet käytännössä alustapäätöksen äärellä — vertailu on artikkelissa WordPress vai räätälöity kotisivu.
7. JavaScript-vetoinen rakenne
Osa moderneista sivustoista lähettää selaimelle lähes tyhjän HTML-sivun ja rakentaa koko sisällön JavaScriptillä vasta selaimessa. Käyttäjä katsoo tyhjää ruutua siihen asti.
Testaa näin: avaa sivun lähdekoodi (hiiren oikea → "näytä sivun lähdekoodi") ja etsi leipätekstiäsi. Jos sitä ei näy vaan tilalla on tyhjä <div> ja kasa skriptejä, sisältö syntyy vasta selaimessa.
Korjaus on tekninen — esirenderöinti tai palvelinrenderöinti — ja se kuuluu toimittajalle. Sama ongelma haittaa myös hakukone- ja tekoälynäkyvyyttä, mitä käsittelimme artikkelissa AI-optimoidut verkkosivut.
Mistä latausaika koostuu
Kaavio auttaa hahmottamaan, mihin kohtaan mikin korjaus osuu. Sama sekunti säästettynä eri kohdasta ei tunnu käyttäjästä samalta.
Mitkä korjaat itse tänään
Nämä eivät vaadi kehittäjää. Varaa kaksi tuntia.
- Aja PageSpeed Insights kolmelle sivulle ja kirjoita LCP-, INP- ja CLS-luvut ylös. Ilman lähtötilannetta et tiedä auttoiko mikään.
- Etsi suurimmat kuvat. Selaimen kehittäjätyökaluissa Verkko-välilehti järjestää tiedostot koon mukaan. Kaikki yli 500 kilotavun kuvat ovat korjattavia.
- Pakkaa ja mitoita ne uudelleen. Squoosh, TinyPNG tai mikä tahansa kuvankäsittelyohjelma. Tallenna WebP-muodossa ja lataa uudelleen samalla nimellä.
- Poista lisäosat, joita ei käytetä. Ota varmuuskopio ensin. Poista yksi kerrallaan ja tarkista sivusto välissä.
- Karsi fontit. Jos käytössä on yli kaksi fonttiperhettä, valitse kaksi.
- Poista upotettu kartta etusivulta. Jätä se yhteystiedoille.
- Asenna välimuistilisäosa, jos alusta on WordPress eikä sellaista ole. Tyhjennä välimuisti jokaisen sisältömuutoksen jälkeen, tai ihmettelet miksi muutokset eivät näy.
- Mittaa uudelleen ja vertaa lukuja lähtötilanteeseen.
Kuvat yksin riittävät usein pudottamaan LCP:n puoleen. Se on tylsä vastaus, mutta se on se, joka toistuu.
Mitkä kuuluvat toimittajalle
Loput vaativat pääsyn koodiin. Nämä kannattaa lähettää sellaisenaan — ne on kirjoitettu niin, että toimittaja tietää mitä pyydetään.
1. Mitatkaa palvelinvaste (TTFB) ja kertokaa, onko nykyinen webhotelli riittävä. Jos ei, suositelkaa vaihtoehto hintoineen.
2. Ottakaa käyttöön palvelinpuolen välimuisti ja selainvälimuistin otsakkeet staattisille tiedostoille.
3. Tarjoilkaa kuvat WebP- tai AVIF-muodossa, oikeassa koossa laitteen mukaan, ja lisätkää laiska lataus muille kuin ensimmäisenä näkyville kuville.
4. Määrittäkää kuville ja upotuksille kiinteät mitat, jotta sisältö ei hyppää latautuessa (CLS).
5. Viivästäkää muut kuin välttämättömät skriptit — chat, kartat, videot, seuranta — sivun latauksen jälkeen.
6. Ladatkaa fontit itse palvelimelta ja käyttäkää font-display: swap -asetusta.
7. Kertokaa, syntyykö sisältö palvelimella vai vasta selaimessa. Jos jälkimmäinen, esittäkää arvio esirenderöinnistä.
8. Raportoikaa LCP, INP ja CLS ennen ja jälkeen, mobiilista mitattuna.
Viimeinen kohta on tärkein. Ilman ennen–jälkeen-lukuja maksat työstä, jonka tulosta kukaan ei voi todentaa.
Mitä nopeus tekee hakukonenäkyvyydelle
Tässä kannattaa olla rehellinen, koska aiheesta liioitellaan molempiin suuntiin.
Nopeus on Googlen sijoitustekijä, mutta pieni. Googlen oman ohjeistuksen mukaan sivukokemus on yksi signaali muiden joukossa, eikä hyvä nopeus nosta heikkoa sisältöä relevantimman sisällön ohi. Hitaan sivuston nopeuttaminen ei siis nosta sinua kärkeen, jos sisältö ei vastaa hakuun.
Sen sijaan nopeus vaikuttaa suoraan siihen, mitä tapahtuu hakutuloksen klikkauksen jälkeen — ja se osa on paljon suurempi. Kävijä, joka odottaa kuusi sekuntia, palaa takaisin hakutuloksiin. Sillä ei ole väliä kuinka hyvä palvelu on, jos sitä kuvaava sivu ei ehdi latautua.
Käytännön järjestys on siis tämä: jos sivusto ei näy hauissa lainkaan, nopeus ei ole ensimmäinen korjattava — käy syyt läpi artikkelissa kotisivut eivät näy Googlessa. Jos sivusto näkyy ja saa klikkauksia mutta yhteydenottoja ei tule, nopeus on yksi ensimmäisistä epäillyistä. Laajempi kuva hakukonetyöstä on sivulla hakukoneoptimointi yritykselle.
Milloin nopeutta ei kannata enää paikata
Joskus vastaus ei ole optimointi. Kolme tilannetta, joissa korjaaminen tulee kalliimmaksi kuin uudelleen rakentaminen:
Hitaus juontaa teemasta tai sivunrakentimesta. Voit pakata kuvat ja karsia lisäosat, mutta pohja tuottaa edelleen viisinkertaisen määrän koodia tarpeeseen nähden. Katto tulee vastaan nopeasti.
Alustaa ei enää ylläpidetä. Jos julkaisujärjestelmä tai teema ei saa päivityksiä, nopeusongelman rinnalla on tietoturvaongelma, ja jälkimmäinen on vakavampi.
Optimointi on jo tehty kerran eikä se kestänyt. Sivusto nopeutettiin vuosi sitten, ja nyt se on taas hidas. Se tarkoittaa, että rakenne ei kestä normaalia käyttöä.
Näissä tapauksissa kannattaa laskea uudistuksen ja jatkuvan paikkaamisen hinta rinnakkain. Merkit ja päätöskehikko käydään läpi artikkelissa milloin kotisivut kannattaa uudistaa.
Miten estät hitauden palaamisen
Hidastuminen on lähes aina vähittäistä ja kertyy huomaamatta, joten sen estäminen kuuluu säännölliseen ylläpitoon. Mitä ylläpitoon kuuluu ja mitä eri mallit maksavat, on eritelty artikkelissa mitä kotisivujen ylläpitoon kuuluu.
Nopeus ei ole projekti vaan ylläpitoa. Sivustot hidastuvat vähitellen, koska jokainen uusi kuva, lisäosa ja seurantakoodi lisää painoa eikä kukaan poista mitään.
Kolme tapaa, jotka pitävät sen kurissa:
Sääntö kuville. Kukaan ei lataa sivustolle kuvaa, jota ei ole ensin pakattu. Yksi rivi ohjeeksi sille, joka päivittää sisältöä.
Mittaus kerran kvartaalissa. Aja PageSpeed Insights neljännesvuosittain samalle kolmelle sivulle ja kirjaa luvut samaan taulukkoon. Hidastuminen näkyy ennen kuin kukaan huomaa sitä käytössä.
Kysymys jokaiselle uudelle työkalulle. Ennen kuin sivustolle lisätään uusi widget tai seurantakoodi, kysy mitä se painaa ja voiko sen ladata vasta sivun jälkeen. Useimmiten voi.
Jos haluat, että joku mittaa sivustosi ja kertoo suoraan mikä sitä hidastaa ja mitä korjaus maksaa, ota yhteyttä.