Kako ubrzati web stranicu: praktičan kontrolni spisak

Da ubrzate web stranicu, prvo je izmjerite pomoću PageSpeed Insights, pa popravite najveći uzrok koji on pokaže — obično prevelike slike, previše JavaScripta, teške fontove ili skripte trećih strana. Ciljajte na Googleove "dobre" vrijednosti Core Web Vitals: glavni sadržaj vidljiv za 2,5 sekundi, odgovor na dodir za 200 milisekundi i gotovo nikakvo skakanje rasporeda. Većina stranica do toga dođe s nekoliko promjena, a ne prepravljanjem.

Izmjerite prije bilo kakve promjene

Nagađanje troši vrijeme. Dva besplatna alata pokrivaju skoro sve:

• PageSpeed Insights (pagespeed.web.dev) — zalijepite živu URL adresu. Pokazuje podatke s terena od stvarnih Chrome korisnika (ako vaša stranica ima dovoljno saobraćaja) i laboratorijske podatke iz simuliranog učitavanja, plus listu konkretnih problema.
• Lighthouse u Chrome DevTools-u — isti laboratorijski test, pokrenut na bilo kojoj stranici koju možete otvoriti, uključujući pregled. Testirajte u mobilnom režimu; problemi se pokazuju na telefonima sporijim mrežama.

Brojevi koji su bitni su Googleovi Core Web Vitals. Od septembra 2026, Googleova dokumentacija na web.dev daje ove "dobre" pragove, mjerene na 75. percentilu učitavanja stranica:

INP je 2024. zamijenio stariju metriku First Input Delay. Ako neki alat i dalje prijavljuje FID, zastario je.

Zapišite početne brojeve. Nakon svake popravke ponovo testirajte da znate šta je pomoglo.

Gdje odlazi vrijeme: opcije i kompromisi

Svaki čest uzrok ima popravku, a svaka popravka ima cijenu. Počnite s onima na vrhu — najjeftinije su i najčešće.

Slike

Slike su najčešći problem i najlakše ih je popraviti. Fotografija od 4.000 piksela prikazana na 800 piksela širine tjera svakog posjetioca da preuzme pet puta više nego što vidi.

• Služite slike u veličini u kojoj se prikazuju, s responzivnim srcset veličinama za telefone i desktope.
• Koristite moderne formate (WebP ili AVIF) i razumnu kompresiju.
• Postavite width i height na svaku sliku da pretraživač rezerviše prostor. Samo to rješava većinu pomjeranja rasporeda.
• Lazy-load slike ispod preklopa s loading="lazy".
• Nikad ne lazy-load-ujte glavnu sliku na vrhu stranice. Googleove smjernice za LCP su jasne: lazy-loading LCP slike uvijek je odlaže. Umjesto toga dajte joj fetchpriority="high".

JavaScript

Mnoge stranice izgrađene uz AI su single-page aplikacije (SPA): pretraživač preuzme JavaScript paket, pa tek onda iscrta stranicu. Što je paket veći, to je duži prazan ekran. Popravke, po redoslijedu truda:

1. Uklonite ono što ne koristite. Tražite spisak zavisnosti i izbacite biblioteke koje su jednom dodane pa zaboravljene — biblioteku za datume zbog jednog datuma, cijeli paket ikona zbog pet ikona.
2. Podijelite po ruti. Učitajte kod admin dashboarda tek kad ga neko otvori, a ne na početnoj stranici.
3. Prerenderujte javne stranice. Marketing stranica koja se isporučuje kao pravi HTML pojavljuje se prije nego što se pokrene bilo koji JavaScript. Ovo pomaže i tražilicama; pogledajte SEO za web stranice napravljene uz AI.

Spor INP obično znači jedan dugi zadatak koji blokira stranicu — filtriranje velike liste na svaki unos ili ponovno renderovanje cijele tabele kad se promijeni jedna ćelija. Panel Performance u Chrome DevTools-u pokazuje koji.

Fontovi

Svaka porodica fonta i svaka debljina je još jedan fajl. Dvije porodice i tri do četiri debljine obično su dovoljne. Preload-ujte font koji se koristi iznad preklopa, koristite font-display: swap da se tekst odmah prikaže i hostujte fontove sami ako je vanjski servis za fontove spor za vaše posjetioce.

Skripte trećih strana

Chat widgeti, analitika, heatmape, reklamni pikseli, ugrađeni videi i društveni feedovi učitavaju kod s drugih servera. Svaki izgleda malen; zajedno su često najsporiji dio stranice. Zadržite samo one koje stvarno koristite. Ostale učitajte nakon što stranica postane interaktivna, a teške ugradnje (YouTube plejer, mapa) zamijenite lakim pregledom koji učitava pravu stvar tek na klik.

Odgovor servera

Vrijeme do prvog bajta (TTFB) — koliko server treba da počne odgovarati — leži ispod svih ostalih metrika. Statičke stranice poslužene s CDN-a (mreže servera blizu vaših posjetilaca; pogledajte šta je CDN) brze su gotovo svuda. Stranice koje server gradi pri svakom zahtjevu zavise od tog servera i njegove baze podataka. Keširanje ponovljenog posla i dodavanje indeksa u bazu za spore upite su uobičajene popravke.

Promptovi koji rade

Budite konkretni: navedite stranicu, metriku i ograničenje. Zalijepite PageSpeed Insights nalaze ako ih imate.

PageSpeed Insights prijavljuje LCP od 4,8 s na mobilnom za početnu stranicu, a LCP element je slika na vrhu. Promijeni veličinu i pretvori sliku na vrhu u WebP, služi responzivne veličine, postavi width i height, dodaj fetchpriority="high" i pobrini se da nije lazy-load. Lazy-load svaku sliku ispod preklopa. Ne mijenjaj dizajn.

Provjeri zavisnosti ove aplikacije. Navedi svaki paket, šta ga koristi i približno koliko dodaje paketu. Ukloni neiskorištene i podijeli rute /admin i /settings na zasebne dijelove koji se učitavaju samo kad se posjete.

Polje za pretragu na /products je sporo. Debounce-uj filter, izbjegni ponovno renderovanje cijele liste na svaki unos i paginiraj ili virtualizuj listu ako ima više od 200 stavki.

Korak po korak

1. Testirajte živu stranicu u PageSpeed Insights na mobilnom. Zabilježite LCP, INP i CLS i tri najveća problema s liste.
2. Prvo popravite slike: veličine, formate, dimenzije, lazy loading ispod preklopa, prioritet za sliku na vrhu.
3. Smanjite skripte trećih strana koje ne koristite i odložite ostale.
4. Smanjite fontove na ono što dizajn treba.
5. Smanjite JavaScript: uklonite neiskorištene pakete, podijelite po ruti.
6. Prerenderujte javne stranice ako su još renderovane na klijentu i LCP je i dalje spor.
7. Provjerite server: keširanje, indeksi baze, statički hosting za sadržaj koji se rijetko mijenja.
8. Ponovo objavite i ponovo testirajte. Podaci s terena u PageSpeed Insights se ažuriraju tokom narednih sedmica kako stižu stvarne posjete, pa rane rezultate procjenjujte prema laboratorijskim podacima.

Česte greške

• Testiranje samo na brzom laptopu. Vaši posjetioci su na telefonima srednje klase i nestabilnom mobilnom internetu. Testirajte u mobilnom režimu.
• Jurnjava za savršenih 100. Laboratorijski rezultat je vodič. Kad su Core Web Vitals u dobrom opsegu, sadržaj i upotrebljivost važniji su od posljednjih nekoliko bodova.
• Lazy-load svega, uključujući sliku na vrhu. To pogoršava LCP.
• Dodavanje plugina ili biblioteke za brzinu preko svega. Uklanjanje težine gotovo uvijek nadjačava dodavanje koda za njeno upravljanje.
• Optimizovanje pregleda, a ne žive stranice. Razvojni pregledi rade s neoptimizovanim buildovima. Mjerite objavljenu URL adresu.
• Ubrzavanje samo jednom. Svaki novi widget, slika i funkcija dodaju težinu. Ponovo testirajte nakon velikih promjena.

Lista za brzinu

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 na mobilnom
• Slike promijenjene po veličini, kompresovane, moderan format, sa width i height
• Slika na vrhu nije lazy-load; slike ispod preklopa jesu
• Nema neiskorištenih JavaScript biblioteka; teške rute izdvojene
• Dvije porodice fontova ili manje, glavni font preload-ovan
• Samo skripte trećih strana koje stvarno koristite, učitane kasno
• Javne stranice prerenderovane ili statične gdje je moguće
• Ponovo testirano na živoj URL adresi nakon objave

Brzina i mobilni raspored idu zajedno; pogledajte kako napraviti web stranicu responzivnom za mobilne. Za cijeli prolaz prije lansiranja, kako prenijeti AI prototip u produkciju pokriva ostalo.

Brzina na Mythexu

Na Mythexu ove promjene radite tako što tražite u chatu ili u uređivaču koda na Pro planu. Provjerite objavljenu URL adresu, a ne Preview, jer Preview pokreće razvojni server. Statički frontend-i se pri objavi deployuju kao statički sajtovi (statičke web stranice), što odgovara stranicama sa sadržajem. Aplikacije sa serverom skaliraju na nulu: u mirovanju spavaju i bude se pri sljedećoj posjeti, pa je prvi zahtjev nakon tihog perioda sporiji, a priložena baza podataka spava nakon 5 minuta neaktivnosti (ograničenja hostinga). Ako je javna stranica spora samo pri prvoj posjeti, to je vjerovatan uzrok. Držanje marketing stranica statičkim pomaže. Nakon promjena, ponovo objavite i uradite tvrdo osvježavanje.

Pitanja