Lühike vastus
Saidi kiirus mõjutab Google'i positsioone, kuid kaudselt ja nõrgemalt, kui tavaliselt arvatakse. Google kinnitab, et Core Web Vitals kuulub rankimissignaalide hulka — aga väikese kaaluga tegurina, mis avaldub peamiselt siis, kui muu on võrdne. Kiire, aga keskpärase sisuga sait ei edesta aeglast saiti, mis annab päringule ammendava vastuse.
Praktiline järeldus on lihtne: kiirus ei vii tippu, kuid selgelt aeglane sait segab kõike ülejäänut — inimesed pöörduvad otsingusse tagasi, konversioon langeb ja suurtel saitidel väheneb ka indekseerimise sagedus. Seepärast tasub kiirus viia tasemele "korras" ja sinna peatuda.
Mida Google täpselt mõõdab
Alates 2021. aastast kannab mõõdikute komplekt nime Core Web Vitals ja 2024. aastast kuulub sinna aegunud FID-i asemel INP.
| Mõõdik | Mida näitab | Hea lävend |
|---|---|---|
| LCP (Largest Contentful Paint) | Millal joonistus välja ekraani põhielement — tavaliselt bänner või pealkiri | kuni 2,5 s |
| INP (Interaction to Next Paint) | Kui kiiresti leht reageerib klikkidele ja puudutustele | kuni 200 ms |
| CLS (Cumulative Layout Shift) | Kui palju paigutus laadimise ajal hüppab | kuni 0,1 |
Kaks asja, millest kõige sagedamini valesti aru saadakse.
Esiteks: arvestatakse 75. protsentiili, mitte keskmist. Mõõdik on läbitud, kui lävendisse mahub kolm neljandikku reaalsetest külastustest 28-päevases aknas. Üks aeglane külastus pilti ei riku, kuid püsivalt aeglane veerand publikust rikub.
Teiseks: rankimisel kasutatakse väliandmeid, mitte laboriandmeid. Väliandmed on CrUX ehk päris Chrome'i kasutajate koondmõõtmised. Laboriandmed on Lighthouse ehk simulatsioon emuleeritud seadmel. PageSpeed Insightsi skoor, mida kõik taga ajavad, on laboriandmete oma.
Seepärast on ainus raport, millest alustada, Search Console'i "Peamised veebinäitajad": seal on samad väliandmed, grupeeritud lehetüüpide kaupa.
Miks kiirus otsingus siiski märgata annab
Otsene mõju rankimisele on väike. Kuid kiirusel on kolm kaudset kanalit ja need on tugevamad.
- Kasutajakäitumine. Kui leht ei joonistu mobiilis paari sekundiga välja, läheb osa inimesi otsingutulemustesse tagasi ja avab konkurendi. Google ei pea seda käitumissignaaliks lugema, et tulemus oleks sama: külastuse sai konkurent, mitte sina.
- Konversioon. Aeglane vorm või tootekaart tapab päringud sõltumata positsioonidest. See on eraldi ülesanne — käsitlen seda konversiooni optimeerimise kontekstis, kuid alguse saab see sageli just tehnilisest poolest. Kiirus on vaid üks plokk kogu nimekirjas, mis on veebilehe tehniline optimeerimine, ja kaugeltki mitte esimene tähtsuse järjekorras.
- Indekseerimine. Google on öelnud, et aeglaste serverivastuste korral vähendab Googlebot külastussagedust. 150 lehega teenusesaidil pole see oluline. 40 000 URL-iga e-poel tähendab aeglane server, et osa lehti lihtsalt käiakse harvemini üle — ja mõnikord ongi see vastus küsimusele, miks Google ei indekseeri lehti.
Kui sulle lubatakse positsioonide kasvu "kiiruse optimeerimise arvelt", on see hoiatusmärk. Kiirust parandatakse sellepärast, et see segab kasutajaid ja raha, mitte sellepärast, et see tõstaks saiti viis kohta.
Mida ma oma projektidel näen
Põhiline sissetulek tuleb mul enda saitidelt konkurentsitihedates finantsnišides ja seal olen seda enda peal kontrollinud: LCP viimine punasest tsoonist rohelisse ei ole mulle kordagi iseenesest positsioonihüpet andnud. Mida see stabiilselt andis, oli väiksem lahkumiste osakaal mobiilis ja prognoositavam analüütika.
Vastupidine kehtib samuti ja on palju valusam. Kui sait läheb punasesse tsooni — tavaliselt pärast uue plugina, tugivestluse või järjekordse piksli paigaldamist —, on langus kiiresti näha nii liikluses kui ka päringutes. Kiirust on kordades lihtsam ära lõhkuda kui parandada.
Ausad piirid: mul ei ole andmeid tõeliselt suurte, sadade tuhandete URL-idega projektide kohta, kus crawl-eelarve muutub peamiseks argumendiks. Kõik ülalkirjutatu käib teenusesaitide, väiksemate e-poodide ja sisuprojektide kohta ehk tüüpilise Eesti väikeettevõtte kohta.
Veel üks kohalikule turule omane tähelepanek: mitmekeelsetel Eesti saitidel kohtan sagedamini mitte kiiruse-, vaid struktuuriprobleemi — valed hreflangid, duplikaadid keeleversioonide vahel, hägune otsinguintent. Selle taustal ei ole vaidlus sekundikümnendike üle kõige olulisem. Keelevalikust olen kirjutanud eraldi: mis keeles veebilehte Eestis turundada.
Mida esimesena parandada
Järjekord on just selline — odavamast kallimani.
- Pildid. Kaasaegne formaat (WebP või AVIF), tegelikud mõõtmed hiiglaslike originaalide asemel,
widthjaheightmärgendis paigutuse hüppamise vastu, laisk laadimine kõigele, mis jääb esimesest ekraanist allapoole. Saitidel, kus sellega pole tegeletud, on see kõige sagedamini ka LCP peamine probleem. - Kolmandate osapoolte skriptid. Vestlusaknad, arvustusevidinad, kolm analüütikasüsteemi, soojuskaardid, reklaamikontode pikslid. Ava Network-vaheleht ja vaata, mis peale sinu saidi laadib. Tavaliselt saab poole kadudeta eemaldada ja ülejäänu edasi lükata.
- Serveri vastuseaeg. Aeglast TTFB-d ei ravi frontend'i optimeerimine. Siin aitavad vahemälu, korralik majutuspakett ja CDN. Kolimist ennast ei tasu karta: majutuse vahetus ei halvenda SEO-d, kui migratsioon on korrektselt tehtud.
- Fondid.
font-display: swapja põhikirjatüübi eellaadimine eemaldavad pika tühja lehe ja osa paigutuse hüpetest. - Alles siis kood. Bundle'i tükeldamine, kasutamata CSS-i eemaldamine, hüdratsiooni optimeerimine. See on kõige kallim osa ja tüüpilisel saidil annab see kulutatud aja kohta kõige vähem. Kui asi on siia jõudnud, käib jutt tavaliselt juba saidi ümbertegemisest, mitte punktparandustest.
Kuidas aru saada, kas probleem üldse on
Sammhaaval, viieteistkümne minutiga:
- Ava Search Console'is raport "Peamised veebinäitajad", eraldi mobiilivaade — see on peaaegu alati halvem kui lauaarvuti oma.
- Vaata, kas on URL-i gruppe punases või kollases tsoonis ja millised lehetüübid sinna sattusid. Sageli on see üks konkreetne lehekategooria, mitte kogu sait.
- Võta probleemsest grupist üks tüüpiline URL ja lase see PageSpeed Insightsist läbi. Vaata mitte skoori, vaid ülemist väliandmete plokki ja diagnostikate loetelu.
- Kui väliandmeid pole, on liiklust CrUX-i valimi jaoks vähe. Siis ei ole kiirus sinu praegune probleem — tegele sisuga.
- Korda mõõtmist mitte varem kui 28 päeva pärast parandusi: väliandmed uuenevad libiseva aknaga ega reageeri kohe.
Näite sellest, mis praktikas tulemust annab, leiad Eesti mööblipoe SEO juhtumist: seal andis kasvu töö struktuuri ja kategooriatega, tehniline pool oli eeldus, mitte põhjus.
