Kako narediti spletno stran hitrejšo: praktičen kontrolni seznam

Spletno stran pospešite tako, da jo najprej izmerite s PageSpeed Insights, nato odpravite največji vzrok, ki ga pokaže — običajno prevelike slike, preveč JavaScripta, težke pisave ali skripte tretjih oseb. Ciljajte na Googlove oznake »dobro« za Core Web Vitals: glavna vsebina vidna v 2,5 sekunde, odziv na dotik v 200 milisekundah in skoraj brez premikanja postavitve. Večina strani tja pride z nekaj spremembami, ne s prepisovanjem.

Najprej izmerite, šele nato spreminjajte

Ugibanje zapravlja čas. Dve brezplačni orodji pokrijeta skoraj vse:

• PageSpeed Insights (pagespeed.web.dev) — prilepite živ URL. Prikaže podatke s terena od resničnih uporabnikov Chroma (če ima stran dovolj obiska) in laboratorijske podatke iz simuliranega nalaganja, ter seznam določenih težav.
• Lighthouse v Chromovih orodjih za razvijalce — isti laboratorijski test na katerem koli odprtem pregledu, vključno s predogledom. Testirajte v mobilnem načinu; težave se pokažejo na telefonih z počasnejšimi omrežji.

Številke, ki so pomembne, so Core Web Vitals Googla. Od septembra 2026 Googlova dokumentacija na web.dev navaja te »dobre« pragove, merjene pri 75. percentilu nalaganj strani:

INP je leta 2024 nadomestil starejšo metriko First Input Delay. Če orodje še vedno poroča FID, je zastarelo.

Zapišite začetne številke. Po vsakem popravku znova testirajte, da veste, kaj je pomagalo.

Kje gre čas: možnosti in kompromisi

Vsak pogost vzrok ima popravek, vsak popravek pa ima ceno. Začnite z zgornjimi, ki so najcenejši in najpogostejši.

Slike

Slike so najpogostejša težava in najlažje za popraviti. 4000-pikselska fotografija, prikazana pri 800 pikslih širine, prisili vsakega obiskovalca, da prenese petkrat več, kot vidi.

• Postrezite slike v velikosti, v kateri so prikazane, z odzivnimi velikostmi srcset za telefone in računalnike.
• Uporabite sodobne formate (WebP ali AVIF) in smiselno kompresijo.
• Nastavite width in height na vsaki sliki, da brskalnik rezervira prostor. Samo to odpravi večino premikanja postavitve.
• Leno nalagajte slike pod pregibom z loading="lazy".
• Nikoli ne leno nalagajte glavne slike na vrhu strani. Googlova smernica za LCP je odločna: leno nalaganje LCP slike jo vedno zakasni. Namesto tega ji dajte fetchpriority="high".

JavaScript

Mnoge strani, zgrajene z AI, so enostranske aplikacije (SPA): brskalnik prenese paket JavaScripta in nato nariše stran. Večji paket, daljši prazen zaslon. Popravki, razvrščeni po naporu:

1. Odstranite, kar ne uporabljate. Zahtevajte seznam odvisnosti in izrežite knjižnice, ki so bile dodane enkrat in pozabljene — knjižnico za datume zaradi enega datuma, celoten paket ikon zaradi petih ikon.
2. Razdelite po poti. Naložite kodo nadzorne plošče za skrbnike, šele ko jo nekdo odpre, ne na domači strani.
3. Predrenderirajte javne strani. Tržna stran, ki se pošlje kot pravi HTML, se prikaže, preden se izvede kateri koli JavaScript. To pomaga tudi iskalnikom; glejte SEO za spletne strani, zgrajene z AI.

Počasen INP ponavadi pomeni eno dolgo opravilo, ki blokira stran — filtriranje ogromnega seznama ob vsakem pritisku tipke ali ponovno upodabljanje celotne tabele, ko se spremeni ena celica. Zavihek Performance v Chromovih orodjih za razvijalce pokaže, katero.

Pisave

Vsaka družina pisav in debelina je še ena datoteka. Dve družini in tri ali štiri debeline so običajno dovolj. Prednaložite pisavo, ki se uporablja nad pregibom, uporabite font-display: swap, da se besedilo prikaže takoj, in pisave gostite sami, če je zunanja storitev za pisave za vaše obiskovalce počasna.

Skripte tretjih oseb

Klepetalni gradniki, analitika, toplotne karte, slikovne pike oglasov, vdelani videoposnetki in družbeni viri nalagajo kodo z drugih strežnikov. Vsak se zdi majhen; skupaj so pogosto najpočasnejši del strani. Obdržite tiste, ki jih dejansko pregledujete. Ostale naložite, potem ko je stran interaktivna, in težke vdelave (predvajalnik YouTube, zemljevid) nadomestite z lahkim predogledom, ki pravo vsebino naloži šele ob kliku.

Odziv strežnika

Time to First Byte (TTFB) — kako dolgo strežnik začne odgovarjati — je podlaga za vse druge metrike. Statične strani, postrežene iz CDN-ja (omrežja strežnikov blizu vaših obiskovalcev; glejte kaj je CDN), so hitre skoraj povsod. Strani, ki jih strežnik sestavi ob vsaki zahtevi, so odvisne od tega strežnika in njegove podatkovne baze. Običajna popravka sta predpomnjenje ponavljajočega se dela in indeksi v podatkovni bazi za počasne poizvedbe.

Pozivi, ki delujejo

Bodite natančni: poimenujte stran, metriko in omejitev. Če imate, prilepite ugotovitve PageSpeed Insights.

PageSpeed Insights poroča LCP 4,8 s na mobilniku za domačo stran, LCP element pa je glavna slika. Spremenite velikost glavne slike in jo pretvorite v WebP, postrezite odzivne velikosti, nastavite width in height, dajte ji fetchpriority="high" in poskrbite, da ni leno naložena. Leno naložite vsako sliko pod pregibom. Ne spreminjajte zasnove.

Pregledajte odvisnosti te aplikacije. Navedite vsak paket, kaj ga uporablja in približno koliko doda paketu. Odstranite neuporabljene in razdelite poti /admin in /settings na ločene dele, ki se naložijo šele ob obisku.

Iskalno polje na /products se zdi počasno. Omejite pogostost filtriranja (debounce), preprečite ponovno upodabljanje celotnega seznama pri vsakem pritisku tipke in seznam razdelite na strani ali virtualizirajte, če ima več kot 200 elementov.

Korak za korakom

1. Testirajte živo stran v PageSpeed Insights na mobilniku. Zapišite LCP, INP in CLS ter tri največje težave na seznamu.
2. Najprej popravite slike: velikosti, formate, dimenzije, leno nalaganje pod pregibom, prioriteto za glavno sliko.
3. Odrežite skripte tretjih oseb, ki jih ne uporabljate, ostale odložite.
4. Skrajšajte pisave na to, kar zasnova potrebuje.
5. Zmanjšajte JavaScript: odstranite neuporabljene pakete, razdelite po poti.
6. Predrenderirajte javne strani, če so še vedno upodobljene na odjemalcu in je LCP še vedno počasen.
7. Preverite strežnik: predpomnjenje, indekse podatkovne baze, statično gostovanje za vsebino, ki se redko spremeni.
8. Ponovno objavite in ponovno testirajte. Podatki s terena v PageSpeed Insights se posodabljajo v naslednjih tednih, ko prihajajo pravi obiski, zato zgodnje rezultate presodite po laboratorijskih podatkih.

Pogoste napake

• Testiranje samo na hitrem prenosniku. Vaši obiskovalci uporabljajo srednje zmogljive telefone in nestabilne mobilne podatke. Testirajte v mobilnem načinu.
• Lov za popolnimi 100 točkami. Laboratorijski rezultat je vodilo. Ko so Core Web Vitals v dobrem razponu, sta vsebina in uporabnost pomembnejši od zadnjih točk.
• Leno nalaganje vsega, tudi glavne slike. To poslabša LCP.
• Dodajanje hitrostnega vtičnika ali knjižnice nad vse. Odstranjevanje teže skoraj vedno premaga dodajanje kode za njeno upravljanje.
• Optimiziranje predogleda, ne žive strani. Razvojni predogledi uporabljajo neoptimizirane gradnje. Merite objavljen URL.
• Pospeševanje enkrat. Vsak nov gradnik, slika in funkcija dodaja težo. Po večjih spremembah znova testirajte.

Kontrolni seznam hitrosti

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 na mobilniku
• Slike zmanjšane, stisnjene, v sodobnem formatu, z width in height
• Glavna slika ni leno naložena; slike pod pregibom so leno naložene
• Brez neuporabljenih knjižnic JavaScripta; težke poti razdeljene
• Največ dve družini pisav, glavna pisava prednaložena
• Samo skripte tretjih oseb, ki jih dejansko uporabljate, naložene pozno
• Javne strani predrenderirane ali statične, kjer je mogoče
• Ponovno testirano na živem URL-ju po objavi

Hitrost in mobilna postavitev gresta skupaj; glejte kako narediti spletno stran odzivno za mobilne naprave. Za celoten pregled pred zagonom pokriva ostalo kako prenesti AI prototip v produkcijo.

Hitrost na Mythexu

Na Mythexu te spremembe naredite s povpraševanjem v klepetu ali v urejevalniku kode na paketu Pro. Preverite objavljen URL, ne predogleda, saj predogled teče na razvojnem strežniku. Statični front-endi se ob objavi razmestijo kot statične strani (statične spletne strani), kar ustreza vsebinskim stranem. Aplikacije s strežnikom se skrčijo na nič (scale to zero): ko so nedejavne, zaspijo in se zbudijo ob naslednjem obisku, zato je prva zahteva po tihem obdobju počasnejša, priložena podatkovna baza pa zaspi po 5 minutah nedejavnosti (omejitve gostovanja). Če je javna stran počasna samo ob prvem obisku, je to verjetni vzrok. Tržne strani, ki so statične, pomagajo. Po spremembah znova objavite in osvežite stran s trdim osveževanjem (hard refresh).

Vprašanja