Ako zrýchliť web: praktický kontrolný zoznam

Aby bol web rýchlejší, najprv ho zmerajte nástrojom PageSpeed Insights, potom opravte najväčšiu príčinu, ktorú ukáže — zvyčajne príliš veľké obrázky, príliš veľa JavaScriptu, ťažké písma alebo skripty tretích strán. Cieľte na „dobré“ hodnoty Core Web Vitals od Google: hlavný obsah viditeľný do 2,5 sekundy, reakcia na ťuknutie do 200 milisekúnd a takmer žiadne skákanie rozloženia. Väčšina stránok sa tam dostane pomocou pár zmien, nie prepisovaním.

Najprv merajte, až potom meňte

Hádanie plytvá časom. Dva bezplatné nástroje pokryjú takmer každého:

• PageSpeed Insights (pagespeed.web.dev) — vložte živú URL. Ukáže terénne dáta od skutočných používateľov Chrome (ak má web dosť návštevnosti) a laboratórne dáta zo simulovaného načítania, plus zoznam konkrétnych problémov.
• Lighthouse v nástrojoch pre vývojárov v Chrome — rovnaký laboratórny test na ľubovoľnej stránke, ktorú môžete otvoriť, vrátane náhľadu. Testujte v mobilnom režime; na telefónoch s pomalšou sieťou sa problémy ukážu najlepšie.

Čísla, na ktorých záleží, sú Core Web Vitals od Google. Od septembra 2026 dokumentácia Google na web.dev uvádza tieto „dobré“ prahy, merané na 75. percentile načítaní stránky:

INP v roku 2024 nahradil staršiu metriku First Input Delay. Ak nástroj stále uvádza FID, je zastaraný.

Zapíšte si začiatočné čísla. Po každej oprave test zopakujte, aby ste vedeli, čo pomohlo.

Kam mizne čas: možnosti a kompromisy

Každá bežná príčina má opravu a každá oprava má náklad. Začnite s hornými — sú najlacnejšie a najbežnejšie.

Obrázky

Obrázky sú najbežnejší problém a najľahšie sa opravujú. Fotka s 4 000 pixelmi zobrazená na 800 pixeloch núti každého návštevníka stiahnuť päťkrát viac, než vidí.

• Podávajte obrázky vo veľkosti, v akej sa zobrazujú, s responzívnymi veľkosťami srcset pre telefóny a počítače.
• Používajte moderné formáty (WebP alebo AVIF) a rozumnú kompresiu.
• Nastavte width a height pri každom obrázku, aby prehliadač vyhradil miesto. Len to opraví väčšinu posunu rozloženia.
• Oneskorene načítavajte obrázky pod záhybom pomocou loading="lazy".
• Nikdy neoneskorujte hlavný obrázok na začiatku stránky. Pokyny Google pre LCP sú v tomto jasné: oneskorené načítanie LCP obrázka ho vždy spomalí. Namiesto toho mu nastavte fetchpriority="high".

JavaScript

Mnohé weby vytvorené AI sú jednostránkové aplikácie (SPA): prehliadač stiahne balík JavaScriptu a až potom vykreslí stránku. Čím väčší balík, tým dlhšia prázdna obrazovka. Opravy, zoradené podľa náročnosti:

1. Odstráňte, čo nepoužívate. Požiadajte o zoznam závislostí a odstráňte knižnice, ktoré sa pridali raz a potom zabudli — knižnicu na dátumy kvôli jednému dátumu, celý balík ikon kvôli piatim ikonám.
2. Rozdeľte podľa trasy. Načítajte kód administračného dashboardu až vtedy, keď ho niekto otvorí, nie na domovskej stránke.
3. Predrenderujte verejné stránky. Marketingová stránka, ktorá sa doručí ako skutočné HTML, sa zobrazí skôr, než sa spustí akýkoľvek JavaScript. Pomáha to aj vyhľadávačom; pozrite SEO pre weby vytvorené AI.

Pomalé INP zvyčajne znamená jednu dlhú úlohu, ktorá blokuje stránku — filtrovanie obrovského zoznamu pri každom stlačení klávesu alebo prekresľovanie celej tabuľky, keď sa zmení jedna bunka. Panel Performance v nástrojoch pre vývojárov v Chrome ukáže, ktorá.

Písma

Každá rodina písma a váha je ďalší súbor. Dve rodiny a tri alebo štyri váhy zvyčajne stačia. Prednačítajte písmo použité nad záhybom, použite font-display: swap, aby sa text hneď zobrazil, a písma hostujte sami, ak je externá služba pre písma pomalá pre vašich návštevníkov.

Skripty tretích strán

Chatovacie widgety, analytika, heatmapy, reklamné pixely, vložené videá a sociálne kanály načítavajú kód z iných serverov. Každý vyzerá malý; spolu sú často najpomalšou časťou stránky. Nechajte si tie, ktoré naozaj sledujete. Ostatné načítajte, keď je stránka interaktívna, a ťažké vložené prvky (prehrávač YouTube, mapu) nahraďte ľahkým náhľadom, ktorý načíta skutočný obsah až po kliknutí.

Odozva servera

Time to first byte (TTFB) — ako dlho server trvá, kým začne odpovedať — leží pod každou inou metrikou. Statické stránky servírované z CDN (siete serverov blízko vašich návštevníkov; pozrite čo je CDN) sú rýchle takmer všade. Stránky, ktoré server zostavuje pri každej požiadavke, závisia od neho a jeho databázy. Bežné riešenia sú cachovanie opakovanej práce a indexy v databáze pre pomalé dotazy.

Prompty, ktoré fungujú

Buďte konkrétni: pomenujte stránku, metriku a obmedzenie. Ak máte nálezy z PageSpeed Insights, vložte ich.

PageSpeed Insights hlási LCP 4,8 s na mobile pre domovskú stránku a prvkom LCP je hlavný obrázok. Zmenšite a prevediete hlavný obrázok do WebP, podávajte responzívne veľkosti, nastavte width a height, dajte mu fetchpriority="high" a zabezpečte, aby nebol oneskorene načítavaný. Oneskorene načítajte každý obrázok pod záhybom. Nemeňte dizajn.

Auditujte závislosti tejto aplikácie. Vypíšte každý balík, to, čo ho používa, a zhruba koľko pridáva do balíka. Odstráňte nepoužité a rozdeľte trasy /admin a /settings do samostatných častí, ktoré sa načítajú až pri návšteve.

Vyhľadávacie pole na /products pôsobí pomaly. Pridajte debounce k filtru, nevykresľujte celý zoznam pri každom stlačení klávesu a ak má zoznam viac ako 200 položiek, stránkujte ho alebo virtualizujte.

Krok za krokom

1. Otestujte živú stránku v PageSpeed Insights na mobile. Poznačte si LCP, INP a CLS a tri hlavné problémy, ktoré sú uvedené.
2. Najprv opravte obrázky: veľkosti, formáty, rozmery, oneskorené načítanie pod záhybom, prioritu pre hlavný obrázok.
3. Odstráňte skripty tretích strán, ktoré nepoužívate, a zvyšok odložte.
4. Zredukujte písma na to, čo dizajn potrebuje.
5. Zmenšite JavaScript: odstráňte nepoužité balíky, rozdeľte podľa trás.
6. Predrenderujte verejné stránky, ak sú stále renderované na klientovi a LCP je stále pomalé.
7. Skontrolujte server: cachovanie, indexy databázy, statický hosting pre obsah, ktorý sa málokedy mení.
8. Znova publikujte a otestujte. Terénne dáta v PageSpeed Insights sa aktualizujú počas nasledujúcich týždňov, ako prichádzajú skutočné návštevy, preto skoré výsledky posudzujte podľa laboratórnych dát.

Časté chyby

• Testovanie len na rýchlom notebooku. Vaši návštevníci používajú stredne výkonné telefóny a nestabilné mobilné dáta. Testujte v mobilnom režime.
• Honba za dokonalými 100 bodmi. Laboratórne skóre je len orientačné. Keď sú Core Web Vitals v dobrom pásme, obsah a použiteľnosť sú dôležitejšie než posledné body.
• Oneskorené načítanie všetkého, vrátane hlavného obrázka. To zhorší LCP.
• Pridávanie ďalšieho rýchlostného pluginu alebo knižnice. Odstránenie záťaže takmer vždy porazí pridanie kódu na jej správu.
• Optimalizovanie náhľadu, nie živého webu. Vývojové náhľady bežia na neoptimalizovaných zostaveniach. Merajte zverejnenú URL.
• Oprava rýchlosti len raz. Každý nový widget, obrázok a funkcia pridáva záťaž. Po väčších zmenách test zopakujte.

Kontrolný zoznam rýchlosti

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 na mobile
• Obrázky zmenšené, skomprimované, moderný formát, s width a height
• Hlavný obrázok nie je oneskorený; obrázky pod záhybom oneskorené
• Žiadne nepoužité knižnice JavaScriptu; ťažké trasy oddelené
• Dve rodiny písma alebo menej, hlavné písmo prednačítané
• Len skripty tretích strán, ktoré skutočne používate, načítané neskoro
• Verejné stránky predrenderované alebo statické, kde to ide
• Znova otestované na živej URL po publikovaní

Rýchlosť a mobilné rozloženie idú spolu; pozrite ako urobiť web responzívny pre mobily. Na úplný prehľad pred spustením pokrýva zvyšok článok ako dostať AI prototyp do produkcie.

Rýchlosť na Mythex

Na Mythex tieto zmeny robíte tak, že ich požiadate v chate, alebo v editore kódu na tarife Pro. Kontrolujte zverejnenú URL, nie Náhľad, pretože Náhľad beží na vývojovom serveri. Statické frontendy sa pri zverejnení nasadia ako statické weby (statické weby), čo sa hodí pre obsahové stránky. Aplikácie so serverom sa škálujú na nulu: pri nečinnosti zaspia a pri ďalšej návšteve sa zobudia, takže prvá požiadavka po tichom období trvá dlhšie, a pripojená databáza zaspí po 5 minútach nečinnosti (limity hostingu). Ak je verejná stránka pomalá len pri prvej návšteve, pravdepodobná príčina je práve toto. Udržiavanie marketingových stránok statických pomáha. Po zmenách publikujte znova a obnovte stránku s vynútením načítania.

Otázky