Lühivastus: testisime 60 juhuslikult valitud Eesti väikeettevõtte kodulehte Google’i mobiilse kiirustestiga (Lighthouse / PageSpeed). Mediaan-mobiiliskoor oli 58 punkti sajast ja mediaan-laadimisaeg (LCP) 8,2 sekundit. Ainult 3 lehte 60-st (5%) said rohelise skoori (90+), samas kui 88% lehtedest laadis mobiilis üle nelja sekundi. Levinuimad põhjused olid samad peaaegu igal lehel: liigsed ümbersuunamised, kasutamata JavaScript ja kasutamata CSS. Asi pole niivõrd platvormis, kuivõrd selles, kui palju lehele laaditakse.
Räägime klientidele iga päev, et lehe kiirus on äriküsimus, mitte tehniline detail. Aga kui aeglased Eesti väikeettevõtete lehed päriselt on? Otsustasin selle ära mõõta, mitte lihtsalt oletada. Võtsin 60 juhuslikku Eesti väikeettevõtte kodulehte – teenindus, kaubandus ja tootmine, üle Eesti, mitte meie enda kliendid – ja lasin kõik ühest ja samast Google’i mobiilsest kiirustestist läbi. Allpool on tulemused ja see, mida nendega peale hakata.
Kuidas me testisime
- Valim: 60 Eesti väikeettevõtte avalehte, 20 igast sektorist – teenindus (juuksurid, hambakliinikud, kohvikud, autoteenindus jne), kaubandus (väikepoed ja e-poed) ja tootmine (mööbli-, toidu-, metalli- ja käsitöötootjad). Geograafiliselt Tallinnast Saaremaani, Tartust Narva kanti. Ükski neist pole meie klient.
- Mõõdik: Google Lighthouse’i mobiilne kiirustest (sama mootor, mis pagespeed.web.dev taga). Simuleeritud keskklassi mobiil aeglase ühendusega – täpselt see, mille põhjal Google su lehte päriselt hindab.
- Skoor: arvutasime iga lehe Lighthouse’i mobiiliskoori (0-100) Google’i avaldatud valemiga viiest põhimõõdikust: FCP, Speed Index, LCP, Total Blocking Time ja CLS.
- Aeg ja ulatus: kõik mõõtmised tehtud 21. juulil 2026, üks mõõtmine lehe kohta. Tulemused on anonümiseeritud – me ei nimeta ega häbista ühtegi lehte, vaid vaatame üldpilti. Üksik mõõtmine kõigub veidi, eriti Total Blocking Time’i osas, nii et võta üksikarve suunanäitajana, mitte täppisteadusena.
Tulemused: mediaan on 58 punkti ja 8 sekundit
Siin on kogu valimi peamised arvud. Roheline Lighthouse’i skoor algab 90-st, kollane on 50-89 ja punane alla 50.
| Näitaja | Tulemus (60 lehe kohta) |
|---|---|
| Mediaan-mobiiliskoor | 58 / 100 (vahemik 30-95) |
| Rohelises (90+) | 3 lehte – 5% |
| Punases (alla 50) | 14 lehte – 23% |
| Alla 90 (ei ületa “hea” piiri) | 95% |
| Mediaan-LCP (suurima sisu laadimine) | 8,2 s |
| LCP üle 4 sekundi | 88% lehtedest |
| LCP üle 10 sekundi | 40% lehtedest (kõige aeglasem 32 s) |
| Mediaan-FCP (esimese sisu ilmumine) | 3,4 s |
| Ebastabiilne paigutus (CLS üle 0,1) | 20% lehtedest |
Ehk lühidalt: tüüpiline Eesti väikeettevõtte koduleht laeb mobiilis kaheksa sekundit ja ei jõua Google’i “hea” tsooni lähedalegi. Google peab LCP-d heaks alla 2,5 sekundi – selle piiri alla mahtus meie valimist täpselt üks leht.
Miks 8 sekundit on probleem
Kiirus mõjub kahele asjale korraga. Esiteks Google’i pingereale: lehe kiirus ja Core Web Vitals on otsene edetabeli tegur, nii et aeglane leht jääb otsingus tahapoole. Teiseks – ja otsesemalt – müügile. Enamik su külastajaid tuleb telefonist, ja iga sekund laadimisajas kaotab osa neist enne, kui nad su lehte üldse näinud on. Kaheksa sekundit tähendab, et suur osa inimestest on juba lahkunud.
Oluline: need on laboritingimuste arvud, simuleeritud keskklassi telefoniga aeglasel ühendusel. Kiirel wifil uue iPhone’iga näeb sama leht paremat aega. Aga just laboritingimustes hindab Google su lehte, ja just seal kohtub sinuga klient, kes on bussis kehva levialaga. Kui leht on seal kiire, on ta kõikjal kiire.
Levinuimad põhjused
Google’i test annab iga lehe kohta ka nimekirja, mida parandada saaks. Kolm asja kordusid peaaegu igal lehel:
- Liigsed ümbersuunamised – 93% lehtedest. Leht saadab brauseri ühelt aadressilt teisele, enne kui midagi laadima hakkab. Iga hüpe lisab aega, eriti mobiilis.
- Kasutamata JavaScript – 92% lehtedest. Lehele laaditakse hunnik koodi, mida see leht tegelikult ei kasuta. Tuleb tavaliselt pluginatest ja teemadest, mis laevad kõik igaks juhuks kaasa.
- Kasutamata CSS – 88% lehtedest. Sama lugu stiilifailidega: leht tõmbab alla terve raamatukogu, aga kasutab sellest murdosa.
46 lehte 60-st (77%) kandsid kõiki kolme korraga. Ükski neist eraldi pole katastroof, aga koos teevad nad lehest selle kaheksasekundilise laadija. Ja pane tähele, mida selles nimekirjas ei ole ühegi konkreetse põhjusena: “liiga ilus disain”. Aeglus ei tule sellest, et leht on liiga hea – see tuleb ballastist, mida keegi pole koristanud.
Kas süüdi on lehekonstruktor?
Ootasin, et süüdlane on selge: lehekonstruktorid, mis on tuntud oma raskuse poolest. 38 lehte 60-st olid WordPressil ja neist umbes pooled kasutasid mõnda konstruktorit. Ja tõsi ta on: valimi kõige aeglasemad lehed olid rasked, palju laadivad konstruktori-lehed, üks neist 32-sekundilise LCP-ga.
Aga andmed ei luba öelda, et konstruktor ise on süüdi. Konstruktoriga ja ilma konstruktorita lehtede mediaanskoor oli täpselt sama – 58. Kõige kiiremad lehed valimis ei kasutanud küll ühtki konstruktorit, aga konstruktorita lehtede seas oli ka omajagu aeglasi (näiteks rasked Wixi ja omakoodilised lehed laadisid sama kaua). Nii et aus järeldus on see:
Küsimus pole niivõrd selles, millega leht on tehtud, kuivõrd selles, kui palju sinna laaditakse. Konstruktor teeb ballasti kuhjamise lihtsaks, aga ka konstruktorita saab teha aeglase lehe – ja korralikult ehitatud konstruktori-leht võib olla täiesti mõistlik.
Meie ise ei kasuta lehekonstruktoreid, ja oleme selle valiku põhjused eraldi lahti kirjutanud. Aga see uuring ei ütle “konstruktor = halb”. Ta ütleb “kontrollimata ballast = aeglane”.
Sektorite lõikes
Kõige aeglasem sektor oli kaubandus (mediaanskoor 52) – loogiline, sest poed ja e-poed kannavad rohkem pilte ja tootegaleriisid ning maksescripte. Teenindus oli kõige kiirem (62) ja tootmine jäi vahepeale (58). Ükski sektor ei olnud lähedal sellele, mida võiks nimetada heaks.
Mida sa oma lehega teha saad – tasuta
Pane oma aadress lehele pagespeed.web.dev ja vaata mobiili skoori. Kui see on alla 50, oled punases tsoonis ja tõenäolised põhjused on selles järjekorras:
- Pildid. Otse kaamerast või telefonist üles laaditud mitme-megabaidised pildid on kiireim viis leht aeglaseks teha. Õige suurus ja kaasaegne formaat (WebP) lahendab enamiku.
- Pluginad ja koodi ballast. Iga plugin toob kaasa oma JavaScripti ja CSS-i, sageli ka lehtedele, kus seda ei kasutata. Loe pluginate arvust ja sellest, kui palju on liiga palju.
- Puuduv vahemälu (cache) ja aeglane majutus. Ilma vahemäluta ehitab server iga külastuse jaoks lehe nullist.
Suure osa neist saab parandada ilma lehte ümber ehitamata. Põhjalikumalt oleme selle lahti kirjutanud loos “Miks mu WordPressi leht on aeglane”.
Korduvad küsimused
Google’i Lighthouse’i skoor 90-100 on roheline (“hea”), 50-89 kollane (“parandamist vajav”) ja alla 50 punane (“nõrk”). Meie 60 Eesti väikeettevõtte lehe uuringus oli mediaan 58 ja ainult 5% jõudis rohelisse. Praktiline eesmärk on üle 90 mobiilis ja LCP alla 2,5 sekundi.
Massruumi 2026. aasta uuringu järgi, mis testis 60 juhuslikku Eesti väikeettevõtte kodulehte, on mediaan-mobiiliskoor 58 punkti sajast ja mediaan-laadimisaeg (LCP) 8,2 sekundit. 88% testitud lehtedest laadis mobiilis üle nelja sekundi ja ainult 5% saavutas Google’i rohelise skoori.
Mitte automaatselt. Meie uuringus oli konstruktoriga ja ilma konstruktorita lehtede mediaanskoor sama. Valimi kõige aeglasemad lehed olid küll rasked konstruktori-lehed, aga aeglaseks võib jääda ka konstruktorita leht. Otsustav pole tööriist, vaid see, kui palju koodi, skripte ja optimeerimata pilte lehele laaditakse.
Mine lehele pagespeed.web.dev, sisesta oma aadress ja vaata “Mobile” skoori. Sama mootorit (Google Lighthouse) kasutasime ka selles uuringus. Kui mobiili skoor on alla 50, alusta piltidest, seejärel pluginate arvust ja vahemälust.
Kui tahad teada, kus su leht seisab
Me ehitame kiireid lehti ilma lehekonstruktorita ja kirjutame ainult selle koodi, mida leht päriselt kasutab – just seepärast on kiirus meie lehtedel sisse ehitatud, mitte hilisem lisand. Kui tahad teada, kus su praegune leht selles pildis seisab ja mida saaks parandada, vaatame su lehe kiiruse tasuta üle. Ja kui plaanid uut lehte, alusta hinnakirjast, uuri, kui palju kodulehe tegemine 2026 maksab, või loe, mida tähendab korralikult ehitatud WordPressi koduleht.
