Miks mu koduleht on aeglane? Põhjused ja lahendused

„Miks mu koduleht on aeglane?” on küsimus, mida ettevõtja esitab tavaliselt siis, kui keegi on juba kurtnud. Klient ütleb, et leht ei avane telefonis, või PageSpeed Insights näitab punast numbrit. Selles juhendis vaatame, mis teeb ettevõtte kodulehe tavaliselt aeglaseks, kuidas seda õigesti mõõta, mida saab ise parandada ja millal on mõistlikum teha uus leht.

Kui Core Web Vitalsi mõisted on teile uued, lugege enne lühikest sissejuhatust meie artiklist kodulehe tegemisest. Siin läheme sügavamale.

Kõigepealt mõõtke õigesti

Enne parandamist tuleb teada, mis täpselt aeglane on. Kõige lihtsam tööriist on Google'i PageSpeed Insights. Sisestage aadress ja saate kaks väga erinevat tulemust. Neid aetakse sageli segamini.

Välisandmed ja laboriandmed

Välisandmed (field data) tulevad päris külastajatelt. Google kogub neid Chrome'i kasutajatelt, kes on sellega nõus, ja avaldab Chrome UX Reporti (CrUX) kaudu. PageSpeed Insights näitab neid viimase 28 päeva kohta. Need näitavad, kuidas teie leht päriselt töötab teie külastajate telefonides ja võrkudes.

Laboriandmed (lab data) tulevad Lighthouse'ist. See laadib lehe ühe korra simuleeritud aeglasema telefoni ja võrguga. Sellest tuleb ka tuntud skoor nullist sajani.

Mõlemal on oma koht:

	Välisandmed (CrUX)	Laboriandmed (Lighthouse)
Kust	päris külastajad, 28 päeva	üks simuleeritud laadimine
Mida näitab	kas probleem on päriselt olemas	miks probleem tekib
Millal kasutada	otsustamiseks, kas parandada	parandamiseks ja kontrollimiseks
Puudus	väikese liiklusega lehel võib puududa	ei pruugi vastata päris kasutajatele

Väikese ettevõtte lehel on sageli nii, et välisandmeid pole, sest külastajaid on liiga vähe. Siis jääb alles ainult labor. See on normaalne, lihtsalt tuleb meeles pidada, et labori skoor on hinnang, mitte päris kasutajate kogemus.

Kui teie leht on Google Search Consoles, näete seal ka Core Web Vitalsi aruannet, mis rühmitab sarnased lehed kokku ja näitab, millised neist on probleemsed.

Millised numbrid on head

Google'i juhendi järgi peaks 75% külastustest jääma nendesse piiridesse:

Näitaja	Hea	Vajab parandamist	Halb
LCP	kuni 2,5 s	2,5–4 s	üle 4 s
INP	kuni 200 ms	200–500 ms	üle 500 ms
CLS	kuni 0,1	0,1–0,25	üle 0,25

75. protsentiil tähendab, et arvesse läheb ka aeglasema telefoniga külastaja. Kui leht on teie arvutis kiire, ei ütle see veel midagi.

Iga näitaja viitab ka erinevale põhjusele. Aeglane LCP tähendab tavaliselt, et peamine pilt või pealkiri jõuab ekraanile hilja. Halb INP tähendab, et liiga palju JavaScripti hoiab brauserit kinni. Kõrge CLS tähendab, et sisu hüppab, sest piltidel, reklaamidel või fontidel pole ruumi ette jäetud.

Seitse levinumat põhjust ja kuidas neid parandada

1. Optimeerimata pildid

See on kõige sagedasem põhjus ja õnneks ka kõige lihtsamini parandatav. Tüüpiline olukord: fotograafi täissuuruses foto laaditakse otse lehele ja brauser teeb selle telefonis 400 piksli laiuseks. Külastaja laadib alla kümneid kordi rohkem, kui vaja.

Mida teha:

• salvestage pildid kaasaegses formaadis (WebP või AVIF);
• pakkuge igale ekraanile sobivat suurust (srcset ja sizes);
• andke igale pildile laius ja kõrgus, et brauser jätaks ruumi ette ja sisu ei hüppaks;
• laadige ekraanist allpool olevad pildid laisalt (loading="lazy");
• ärge laadige laisalt lehe peamist pilti. See peab tulema esimesena, vajadusel fetchpriority="high" abil.

2. Lehe-ehitajad ja pluginad

WordPressi lehe-ehitajad ja paljud pluginad laadivad oma CSS-i ja JavaScripti igale lehele, ka sinna, kus neid ei kasutata. Iga plugin tundub eraldi süütu, koos lisavad nad sadu kilobaite.

Mida teha:

• käige pluginad läbi ja eemaldage need, mida enam ei kasutata;
• kontrollige, kas kaks pluginat teevad sama asja (näiteks kaks vahemälu- või SEO-pluginat);
• vaadake Lighthouse'i soovitust „Reduce unused JavaScript” ja „Reduce unused CSS”. Need näitavad, kust liigne kood tuleb.

Kui leht on ehitatud täielikult lehe-ehitajaga, on siin võimalused piiratud. Sellest allpool.

3. Kolmanda osapoole skriptid

Vestlusaken, analüütika, reklaamipikslid, küpsiste bänner, sotsiaalmeedia vidinad, kaardid, YouTube'i video. Igaüks neist laadib koodi teise ettevõtte serverist ja see kood jookseb teie lehel. Need on sageli halva INP põhjus.

Mida teha:

• tehke nimekiri kõigist lehel olevatest skriptidest ja küsige iga kohta: kas keegi kasutab neid andmeid?
• eemaldage vanad pikslid kampaaniatest, mis on ammu lõppenud;
• laadige vestlusaken alles siis, kui külastaja sellele klikib. Seni näidake lihtsalt nuppu, mis näeb välja nagu vestlusaken;
• sama kehtib YouTube'i videote ja kaartide kohta: näidake pilti ja laadige päris sisu alles klikil;
• laadige analüütika async või defer abil, et see ei blokeeriks lehe kuvamist.

4. Veebifondid

Kolm fondiperet, igaühes neli paksust, pluss ikoonifont on tavaline. Iga fail on eraldi päring ja kuni font pole kohal, võib tekst olla nähtamatu või hüpata.

Mida teha:

• kasutage vähem fonte ja paksusi. Kaks on tavaliselt piisav;
• kasutage WOFF2-formaati ja muutuvfonte, kui võimalik;
• hoidke fondifailid oma serveris, mitte kolmanda osapoole juures;
• lisage font-display: swap, et tekst oleks kohe loetav;
• laadige peamine font ette (preload).

5. Odav majutus ja CDN-i puudumine

Kui server vastab aeglaselt, ei aita miski muu. Google'i juhend TTFB kohta peab heaks tulemuseks kuni 0,8 sekundit, enne kui brauser saab üldse midagi teha.

Mida teha:

• lülitage sisse lehe vahemälu (cache), et server ei peaks iga lehte iga kord uuesti koostama;
• kasutage CDN-i, mis hoiab failid külastajale lähemal;
• kui leht on jagatud majutusel, kus sama server teenindab sadu teisi lehti, võib parem majutus olla kõige odavam parandus.

6. Renderdamist blokeeriv JavaScript ja CSS

Kui lehe päises on suured skriptid ilma defer või async atribuudita, ootab brauser nende allalaadimise ja käivitamise ära, enne kui midagi näitab. Sama kehtib suurte CSS-failide kohta.

Mida teha:

• lisage skriptidele defer, kui need ei pea kohe jooksma;
• jagage suur JavaScript väiksemateks osadeks ja laadige need alles siis, kui neid vaja on;
• pikad JavaScripti ülesanded (üle 50 ms) jagage väiksemaks, et brauser jõuaks vahepeal klikile vastata. See parandab INP-d.

7. Video avavaates

Suur taustavideo esimesel ekraanil näeb hea välja, aga võib olla mitu megabaiti ja sageli on see just LCP element.

Mida teha:

• näidake kõigepealt kerget pilti (poster) ja laadige video pärast;
• pakkige video korralikult kokku ja tehke telefonile väiksem versioon;
• kaaluge, kas video on telefonis üldse vajalik;
• austage külastaja seadet: kes on liikumise vähendanud, näeb video asemel pilti.

Kiire kontrollnimekiri

Enne kui kellelegi helistate, saate selle ise läbi käia:

• Käivitasin PageSpeed Insightsi telefoni vaates ja vaatasin eraldi välis- ja laboriandmeid.
• Tean, milline element on minu lehel LCP (PageSpeed Insights näitab seda).
• Peamine pilt on WebP või AVIF ega ole laisalt laetud.
• Kõikidel piltidel on laius ja kõrgus.
• Eemaldasin pluginad ja skriptid, mida keegi ei kasuta.
• Vestlusaken ja videod laaditakse alles klikil.
• Kasutan kuni kahte fondiperet.
• Lehel on vahemälu ja failid tulevad CDN-ist.

Parandada või teha uus leht?

Parandamine on peaaegu alati esimene samm. Piltide, pluginate ja skriptide korrastamine annab sageli suurema osa võidust ja maksab vähem kui uus leht.

Uus leht on mõistlik siis, kui:

• kiirus on piiratud platvormi enda poolt. Näiteks lehe-ehitaja, mille koodi ei saa muuta, või suletud platvorm, kus te ei kontrolli skripte;
• iga parandus teeb midagi muud katki. Pluginad sõltuvad üksteisest ja keegi ei julge enam uuendada;
• leht vajab niikuinii uut sisu või kujundust. Siis pole mõtet vana koodi optimeerimisse palju panustada;
• kiirus on otseselt seotud müügiga, näiteks e-pood, kuhu suur osa külastajaid tuleb telefonist.

Uus leht ei ole automaatselt kiire. Ka eritellimusel leht võib olla aeglane, kui sinna pannakse liiga palju. Meie kontseptsioonilehel Lõke, mis on väljamõeldud restorani demo, mitte päris klient, on palju animatsiooni ja WebGL-i. Lighthouse annab sellele siiski 98 kuni 100 punkti, sest raske osa laaditakse alles siis, kui seda on vaja. Kiirus tuleb sellest, mida lehele panemata jätate, mitte tööriistast.

Kui kaalute malli ja eritellimuse vahel, oleme selle valiku lahti kirjutanud eraldi artiklis kodulehe tegemisest.

Kokkuvõte

Aeglane koduleht on harva ühe suure vea tagajärg. Enamasti on see paljude väikeste asjade summa: liiga suured pildid, unustatud pluginad, kolmanda osapoole skriptid ja fondid. Mõõtke kõigepealt õigesti, eristage päris kasutajate andmeid laboritulemusest ja parandage kõige suurema mõjuga asjad esimesena. Uus leht on mõttekas siis, kui platvorm ise on takistuseks.

Meie töid saate ise telefonis ja PageSpeed Insightsis kontrollida meie tööde all. Kui teie koduleht on aeglane ja te ei tea, kust alustada, kirjutage meile. Vaatame lehe üle ja ütleme ausalt, kas piisab parandamisest või on aeg uue lehe jaoks.