Kodulehe kiirus määrab sinu müügi

Lehe kiirus on üks väheseid asju, mis mõjutab korraga nii müüki kui otsingupositsiooni. Levinud hinnangul vähendab iga lisasekund laadimisaega konversioone tuntavalt — ja mobiilis on mõju veel suurem, sest ühendus on kehvem ja kannatus lühem.

Google on kiiruse ka ametlikult hindamiskriteeriumiks teinud. See ei tähenda, et kiire leht automaatselt esikohale tõuseks, aga aeglane leht kaotab konkurendile, kelle sisu on samaväärne.

Hea uudis: WordPressi aegluse põhjused on peaaegu alati samad kolm asja ja need on parandatavad.

Mis on Core Web Vitals?

Google mõõdab kolme näitajat, mis kirjeldavad, kuidas leht kasutajale tundub. Siin need lihtsas keeles.

LCP — Largest Contentful Paint

Millal ilmub lehe kõige suurem sisuelement? Tavaliselt on see hero-pilt või suur pealkiri.

See on "kas leht on juba laadinud" tunne. Eesmärk: alla 2,5 sekundi.

Peamine süüdlane on peaaegu alati optimeerimata suur pilt lehe ülaosas.

INP — Interaction to Next Paint

Kui kiiresti leht reageerib, kui kasutaja midagi teeb? Vajutab nuppu, avab menüü, klõpsab ostukorvi.

See asendas varasema FID-i ja on rangem näitaja. Eesmärk: alla 200 millisekundi.

Peamine süüdlane on liiga palju JavaScripti, mis blokeerib brauseri.

CLS — Cumulative Layout Shift

Kui palju sisu lehel hüppab laadimise ajal? Klassikaline olukord: hakkad nupule vajutama, aga kohale laeb reklaam ja nupp nihkub — sa vajutad valele asjale.

Eesmärk: alla 0,1.

Peamine süüdlane on pildid ja manused ilma määratud mõõtudeta.

Oma lehe seisu näed tasuta PageSpeed Insightsist. Vaata välitulemusi (päris kasutajate andmed), mitte ainult laboritulemust — need erinevad sageli oluliselt.

Peamised põhjustajad WordPressis

1. Optimeerimata ja liiga suured pildid

See on ülekaalukalt kõige levinum põhjus. Otse telefonist üles laaditud pilt võib olla 4 MB ja 4000 pikslit lai, kuigi lehel kuvatakse seda 800 piksli laiuselt.

Mida teha:

• Kasuta WebP-formaati — tavaliselt 25–35% väiksem kui JPEG sama kvaliteedi juures
• Lae üles õiges mõõdus, mitte originaalsuuruses
• Määra igale pildile laius ja kõrgus — see parandab CLS-i
• Kasuta laisklaadimist (lazy loading) allpool ekraaniserva olevatele piltidele
• Ära pane laisklaadimist hero-pildile — see lükkab LCP-d edasi

2. Liiga palju pluginaid

Iga plugin lisab koodi, päringuid ja sageli oma CSS- ja JS-faile — igale lehele, ka seal, kus seda ei kasutata.

Kontrolli: kas on pluginaid, mida enam ei kasutata? Kas kaks pluginat teevad sama asja? Kas lehitsemis-slider on üldse vajalik?

Kõige suurem üksik võit on tavaliselt raske lehekoostaja (page builder) asendamine kergema lahendusega — aga see on juba ümberehitus, mitte seadistus.

3. Aeglane või odav majutus

Kahe-euroline ühisserver jagab ressurssi sadade lehtedega. TTFB (Time to First Byte) ehk serveri esimene vastus võib venida sekundi või kaks — ja see aeg lisandub kõigele muule, ükskõik kui hästi leht optimeeritud on.

Kui TTFB on üle 600 ms, ei ole probleem sinu lehes, vaid serveris.

Kiired sammud kiiruse tõstmiseks

Järjekorras, mis annab kõige rohkem kõige väiksema vaevaga:

1. Optimeeri pildid. Teisenda WebP-sse, vähenda mõõtusid, määra laius ja kõrgus. See üksi lahendab sageli poole probleemist.
2. Seadista vahemälu (caching). Korralik cache-plugin või serveripoolne vahemälu vähendab koormust drastiliselt.
3. Vähenda pluginate arvu. Eemalda kõik, mida ei kasutata.
4. Minimeeri CSS ja JavaScript ning lükka mittekriitiline JS edasi.
5. Kasuta CDN-i, kui kliente on väljaspool Eestit.
6. Kontrolli fonte. Iga kaalu ja stiili laadimine maksab; lae ainult neid, mida päriselt kasutad.
7. Vaheta majutust, kui TTFB jääb kõrgeks ka pärast eelnevat.

Kuidas kiirust õigesti mõõta

Enamik kiirusevaidlusi tekib sellest, et mõõdetakse valesti.

Labori- ja välitulemused on kaks eri asja. Laboritulemus on üks simuleeritud laadimine standardtingimustes — hea võrdlemiseks enne ja pärast muudatust. Välitulemus tuleb päris kasutajatelt viimase 28 päeva jooksul ja just seda Google arvestab.

Kui välitulemusi ei kuvata, tähendab see tavaliselt, et lehel ei ole piisavalt liiklust. Siis pead toetuma laboritulemusele ja tervele mõistusele.

Mõõda alati mobiilivaates. Arvutivaate number on peaaegu alati ilusam ja peaaegu alati ebaoluline.

Mõõda mitu korda. Üksik mõõtmine kõigub. Kolm mõõtmist annavad usaldusväärsema pildi.

Mõõda õiget lehte. Avaleht on tavaliselt kõige paremini optimeeritud. Kontrolli ka tootelehte, blogiartiklit ja checkout'i — probleemid peituvad seal.

Search Console'is on eraldi Core Web Vitals raport, mis näitab, millised lehegrupid on punases. See on parim koht alustamiseks, sest ta põhineb päris kasutajate andmetel.

Mida oodata pärast optimeerimist

Realistlikud ootused hoiavad ära pettumuse.

Pildid ja vahemälu annavad kohese ja selgelt mõõdetava võidu — sageli poole laadimisajast, kui neid varem tehtud ei olnud.

Välitulemused liiguvad aeglaselt. Kuna need põhinevad 28 päeva andmetel, näed täit mõju alles kuu aja pärast. Ära arva, et miski ei töötanud, kui number järgmisel päeval sama on.

Otsingupositsioonid ei hüppa üleöö. Kiirus on üks tegur paljudest. Mõju tuleb pigem kaudselt: inimesed jäävad lehele, vaatavad rohkem lehti ja lahkuvad harvem.

Konversioon reageerib kõige kiiremini. See on ka kõige olulisem number — kui ostukorvi katkestamised vähenevad, on töö end ära tasunud sõltumata sellest, mida PageSpeed näitab.

Kiirus on ka hoolduse küsimus

Optimeeritud leht ei jää iseenesest kiireks. Tüüpiline muster: leht valmib kiirena, aasta pärast on ta aeglane — ja midagi "ei ole ju muudetud".

Tegelikult on. Sisu on lisandunud, iga uus pilt on üles laaditud optimeerimata, vahepeal on paigaldatud kaks uut pluginat ja galerii.

Kolm harjumust hoiavad kiiruse paigas:

• Iga uus pilt optimeeritakse enne üleslaadimist. See on üks kord õpitav harjumus, mis hoiab ära suurima probleemi.
• Uus plugin paigaldatakse teadlikult. Küsi enne: kas see funktsioon on väärt seda, mida ta laadimisele lisab?
• Kiirust mõõdetakse paar korda aastas, mitte ainult siis, kui keegi kurdab.

Kust tuleb kõige suurem võit

Kui aega on vähe ja tahad teha ainult ühe asja, tee see: vaata üle lehe ülaosa suurim pilt.

Peaaegu igal aeglasel Eesti kodulehel on hero-pilt, mis on mitu megabaiti suur, JPEG-formaadis ja laaditud originaalmõõtudes. Selle ühe pildi teisendamine WebP-sse ja õigesse mõõtu parandab LCP-d sageli sekundi või rohkem — ja LCP on kolmest näitajast kõige sagedamini punases.

Teine kõige suurem võit on kasutamata pluginate eemaldamine. Kolm kasutut pluginat võivad lisada igale lehele kümneid failipäringuid.

Mida mitte teha

Ära paigalda korraga viit optimeerimispluginat. Nad hakkavad omavahel konflikti minema ja tulemus on aeglasem ja katkine leht.

Ära aja taga sada punkti PageSpeedis. Vahe 85 ja 95 punkti vahel on kasutaja jaoks tavaliselt märkamatu, aga selle saavutamine võib midagi katki teha. Oluline on, et välitulemused oleksid rohelised.

Ära optimeeri pimesi. Mõõda enne ja pärast — muidu ei tea sa, mis aitas.