Kuidas teha veebisaidist kiirem: praktiline kontrollnimekiri

Veebisaidi kiiremaks tegemiseks mõõda seda esmalt PageSpeed Insightsiga ja paranda seejärel suurim põhjus, mida see näitab — tavaliselt liiga suured pildid, liiga palju JavaScripti, rasked fondid või kolmanda osapoole skriptid. Püüdle Google'i Core Web Vitals'i „hea“ sihtmärkide poole: peamine sisu nähtav 2,5 sekundi jooksul, reageeringud puudutustele 200 millisekundi jooksul ja peaaegu ei mingit paigutuse hüppamist. Enamik saite jõuab sinna mõne muudatusega, mitte ümberehitusega.

Mõõda enne, kui midagi muudad

Arvamine raiskab aega. Kaks tasuta tööriista katavad peaaegu kõiki:

• PageSpeed Insights (pagespeed.web.dev) — kleebi elav URL. See näitab väljaandmeid päris Chrome'i kasutajatelt (kui su saidil on piisavalt liiklust) ja laboriandmeid simuleeritud laadimisest, lisaks konkreetsete probleemide nimekirja.
• Lighthouse Chrome'i DevTools'is — sama labortest, mida saab käivitada igal lehel, mida saad avada, sealhulgas eelvaates. Testi mobiilirežiimis; telefonid aeglasemas võrgus on koht, kus probleemid ilmnevad.

Oluline on Google'i Core Web Vitals. 2026. aasta septembri seisuga annab Google'i dokumentatsioon web.dev-is need „head“ lävendid, mõõdetuna lehelaadimiste 75. protsentiili järgi:

INP asendas 2024. aastal vana First Input Delay näitaja. Kui mõni tööriist näitab veel FID-i, on see vananenud.

Kirjuta algsed numbrid üles. Pärast iga parandust testi uuesti, et teaksid, mis aitas.

Kuhu aeg läheb: võimalused ja kompromissid

Iga levinud põhjusel on parandus ja igal parandusel on hind. Alusta ülevalt — need on kõige odavamad ja kõige levinumad.

Pildid

Pildid on kõige levinum probleem ja kõige lihtsam parandada. 800 piksli laiuses kuvatav 4000-pikseline foto sunnib iga külastajat alla laadima viis korda rohkem, kui ta näeb.

• Serveeri pilte selles suuruses, milles neid kuvatakse, koos reageerivate srcset suurustega telefonidele ja arvutitele.
• Kasuta kaasaegseid vorminguid (WebP või AVIF) ja mõistlikku tihendamist.
• Määra igale pildile width ja height, et brauser saaks ruumi reserveerida. See üksi parandab enamiku paigutuse nihkest.
• Lae nähtava ala all olevad pildid hilinenult loading="lazy" abil.
• Ära lae lehe ülaosa peamist pilti hilinenult. Google'i LCP-juhend on selles otsene: LCP-pildi hilinenud laadimine viivitab seda alati. Anna sellele hoopis fetchpriority="high".

JavaScript

Paljud AI-ehitatud saidid on ühe lehe äpid (SPA): brauser laadib alla JavaScripti paketi ja joonistab seejärel lehe. Mida suurem pakett, seda pikem tühi ekraan. Parandused, järjekorras vaevanõudmise järgi:

1. Eemalda, mida ei kasuta. Palu nimekiri sõltuvustest ja lõika välja raamatukogud, mis lisati kord ja unustati — kuupäevateek ühe kuupäeva jaoks, täielik ikoonipakk viie ikooni jaoks.
2. Jaga marsruudi kaupa. Lae admin-töölaua kood alles siis, kui keegi selle avab, mitte avalehel.
3. Renderda avalikud lehed ette. Turundusleht, mis saabub päris HTML-ina, ilmub enne, kui ükski JavaScript käivitub. See aitab ka otsingumootoreid; vaata SEO AI-ga ehitatud veebisaitidele.

Aeglane INP tähendab tavaliselt ühte pikka ülesannet, mis blokeerib lehe — loendi filtreerimine iga klahvivajutuse peale või kogu tabeli uuesti renderdamine, kui üks lahter muutub. Chrome'i DevTools'i jõudluspaneel näitab, milline.

Fondid

Iga fondiperekond ja kaal on veel üks fail. Kaks perekonda ja kolm kuni neli kaalu on tavaliselt piisavalt. Eellaadi nähtava ala kohal kasutatav font, kasuta font-display: swap, et tekst kuvaks kohe, ja hosti fondid ise, kui välisteenus on sinu külastajatele aeglane.

Kolmanda osapoole skriptid

Vestlusvidinad, analüütika, soojuskaardid, reklaampikslid, manustatud videod ja sotsiaalsed voogud laadivad kõik koodi teistelt serveritelt. Igaüks tundub väike; koos on need sageli lehe aeglaseim osa. Hoia alles need, mida tegelikult vaatad. Lae ülejäänud pärast seda, kui leht on interaktiivne, ja asenda rasked manustused (YouTube'i mängija, kaart) kerge eelvaatega, mis laeb päris asja alles klõpsust.

Serveri vastus

Time to first byte (TTFB) — kui kaua server kulutab vastamise alustamiseks — jääb kõigi teiste näitajate alla. Staatilised lehed, mida serveeritakse CDN-ist (võrgustikust serveritest, mis asuvad külastajatele lähedal; vaata mis on CDN), on peaaegu kõikjal kiired. Lehed, mida server ehitab iga päringu jaoks, sõltuvad sellest serverist ja selle andmebaasist. Vahemälu korduva töö jaoks ja andmebaasi indeksid aeglaste päringute jaoks on tavalised parandused.

Viibad, mis töötavad

Ole konkreetne: nimeta leht, näitaja ja piirang. Kleebi PageSpeed Insightsi leiud, kui neid on.

PageSpeed Insights näitab avalehe LCP-d 4,8 s mobiilil ja LCP-element on kangelaspilt. Muuda kangelaspilt suuruseks ja WebP-ks, serveeri reageerivad suurused, määra width ja height, anna sellele fetchpriority="high" ja veendu, et seda ei laaditä hilinenult. Lae kõik nähtava ala all olevad pildid hilinenult. Ära muuda disaini.

Audiitse selle äpi sõltuvused. Loetle iga pakett, mida see kasutab, ja umbkaudu, kui palju see paketti lisab. Eemalda kasutamata paketid ning jaga marsruudid /admin ja /settings eraldi tükkideks, mis laaduvad alles siis, kui neid külastatakse.

Otsikasti tundub /products lehel aeglane. Viivita filtrit, väldi kogu loendi uuesti renderdamist iga klahvivajutuse peale ja jaota loend lehtedeks või virtualiseeri see, kui kirjeid on üle 200.

Samm-sammult

1. Testi elavat lehte PageSpeed Insightsis mobiilil. Märka LCP, INP ja CLS ning seal loetletud kolm peamist probleemi.
2. Paranda esmalt pildid: suurused, vormingud, mõõtmed, nähtava ala alt hilinenud laadimine, kangelaspildi prioriteet.
3. Eemalda kolmanda osapoole skriptid, mida ei kasuta, ja lükka ülejäänud edasi.
4. Kärbi fondid sellele, mida disain vajab.
5. Vähenda JavaScripti: eemalda kasutamata paketid, jaga marsruudi kaupa.
6. Renderda avalikud lehed ette, kui need on ikka kliendipoolselt renderdatud ja LCP on ikka aeglane.
7. Kontrolli serverit: vahemälu, andmebaasi indeksid, staatiline majutus sisule, mis harva muutub.
8. Avalda uuesti ja testi uuesti. PageSpeed Insightsi väljaandmed uuenevad järgmiste nädalate jooksul, kui päris külastused saabuvad, seega hinda varajasi tulemusi laboriandmete järgi.

Levinud vead

• Testimine ainult kiires sülearvutis. Su külastajad on keskmise klassi telefonidel ja kehvas mobiilses andmesides. Testi mobiilirežiimis.
• Täiuslikule 100-le järele jooksmine. Laboriskoor on juhis. Kui Core Web Vitals on hea vahemikus, on sisu ja kasutatavus olulisemad kui viimased punktid.
• Kõige hilinenult laadimine, sealhulgas kangelaspilt. See halvendab LCP-d.
• Kiiruspluginate või teegi lisamine peale. Kaalu eemaldamine on peaaegu alati parem kui lisakoodi lisamine selle haldamiseks.
• Eelvaate optimeerimine, mitte elava saidi. Arendusliku eelvaate käitab optimeerimata ehitus. Mõõda avaldatud aadressi.
• Kiiruse parandamine ühe korra. Iga uus vidin, pilt ja funktsioon lisab kaalu. Testi uuesti suurte muudatuste järel.

Kiiruse kontrollnimekiri

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 mobiilil
• Pildid suuruseks muudetud, tihendatud, kaasaegses vormingus, koos width ja height-ga
• Kangelaspilt pole hilinenult laaditud; nähtava ala all olevad pildid on hilinenult laaditud
• Pole kasutamata JavaScripti raamatukogusid; rasked marsruudid on eraldatud
• Kaks fondiperekonda või vähem, peamine font eellaaditud
• Ainult kasutatavad kolmanda osapoole skriptid, laaditud hilinenult
• Avalikud lehed renderdatud ette või staatilised, kus võimalik
• Testitud uuesti elaval aadressil pärast avaldamist

Kiirus ja mobiilne paigutus käivad koos; vaata kuidas teha veebisaidist mobiilile reageeriv. Täieliku enne käivitamist tehtava läbivaatuse jaoks käsitleb kuidas viia AI-prototüüp tootmisesse ülejäänud.

Kiirus Mythexis

Mythexis teed need muudatused küsides vestluses või Pro-paketis koodiredaktoris. Kontrolli avaldatud aadressi, mitte eelvaadet, sest eelvaade käitab arendusserverit. Staatilised esilehed juurutatakse avaldamisel staatiliste saitidena (staatilised veebisaidid), mis sobib sisulehtedele. Serveriga äpid skaleeruvad nulli: nad magavad tegevusetuna ja ärkavad järgmisel külastusel, seega on esimene päring pärast vaikset perioodi aeglasem, ja seotud andmebaas läheb magama pärast 5 minutit tegevusetust (hostimise piirangud). Kui avalik leht on aeglane ainult esimesel külastusel, on see tõenäoline põhjus. Turundusleheküljete hoidmine staatilisena aitab. Pärast muudatusi avalda uuesti ja tee kõva värskendus.

Küsimused