Jak zrychlit web: praktický kontrolní seznam

Web zrychlíte tak, že ho nejdřív změříte nástrojem PageSpeed Insights a pak opravíte největší příčinu, kterou ukáže: obvykle příliš velké obrázky, příliš mnoho JavaScriptu, těžká písma nebo skripty třetích stran. Cílte na „dobré“ hodnoty Core Web Vitals od Googlu: hlavní obsah viditelný do 2,5 sekundy, odezva na dotyk do 200 milisekund a téměř žádné skákání rozvržení. Většina webů se tam dostane pár změnami, ne přepsáním.

Nejdřív měřte, pak měňte

Odhadování plýtvá časem. Dva bezplatné nástroje pokryjí téměř každého:

• PageSpeed Insights (pagespeed.web.dev): vložte živou URL. Ukáže terénní data od skutečných uživatelů Chrome (pokud má web dost návštěvnosti) a laboratorní data ze simulovaného načtení, plus seznam konkrétních problémů.
• Lighthouse v Chrome DevTools: stejný laboratorní test na libovolné stránce, kterou můžete otevřít, včetně náhledu. Testujte v mobilním režimu; problémy se ukážou na telefonech se pomalejší sítí.

Čísla, na kterých záleží, jsou Core Web Vitals od Googlu. Od září 2026 dokumentace Googlu na web.dev uvádí tyto „dobré“ prahy, měřené v 75. percentilu načtení stránek:

INP v roce 2024 nahradil starší metriku First Input Delay. Pokud nástroj stále hlásí FID, je zastaralý.

Zapište si výchozí hodnoty. Po každé opravě měřte znovu, abyste věděli, co pomohlo.

Kam čas mizí: možnosti a kompromisy

Každá běžná příčina má opravu a každá oprava má cenu. Začněte těmi nahoře, protože jsou nejlevnější a nejčastější.

Obrázky

Obrázky jsou nejčastějším problémem a nejsnáze se opravují. Fotka o 4 000 pixelech zobrazená na 800 pixelech nutí každého návštěvníka stáhnout pětkrát víc, než vidí.

• Podávejte obrázky ve velikosti, v jaké se zobrazují, s responzivními velikostmi srcset pro telefony a počítače.
• Používejte moderní formáty (WebP nebo AVIF) a rozumnou kompresi.
• Nastavte width a height u každého obrázku, aby prohlížeč vyhradil místo. Jen to opraví většinu posunu rozvržení.
• Líně načítejte obrázky pod záhybem pomocí loading="lazy".
• Nikdy nenačítejte líně hlavní obrázek nahoře stránky. Pokyny Googlu k LCP jsou v tom neúprosné: líné načítání LCP obrázku ho vždy zpozdí. Dejte mu fetchpriority="high".

JavaScript

Mnoho webů vytvořených AI jsou jednostránkové aplikace (SPA): prohlížeč stáhne JavaScriptový balík a teprve pak vykreslí stránku. Čím větší balík, tím delší prázdná obrazovka. Opravy podle úsilí:

1. Odstraňte, co nepoužíváte. Požádejte o seznam závislostí a odeberte knihovny, které byly jednou přidány a zapomenuty: knihovnu pro datum kvůli jednomu datu, celý balík ikon kvůli pěti ikonám.
2. Dělte podle trasy. Načtěte kód administrátorského dashboardu, až ho někdo otevře, ne na domovské stránce.
3. Předrenderujte veřejné stránky. Marketingová stránka, která se dodává jako skutečné HTML, se objeví dřív, než běží jakýkoli JavaScript. To pomáhá i vyhledávačům; viz SEO pro weby vytvořené AI.

Pomalé INP obvykle znamená jednu dlouhou úlohu blokující stránku: filtrování obrovského seznamu při každém stisku klávesy nebo překreslení celé tabulky, když se změní jedna buňka. Panel Performance v Chrome DevTools ukáže, která.

Písma

Každá rodina písma a váha je další soubor. Dvě rodiny a tři nebo čtyři váhy obvykle stačí. Přednačtěte písmo použité nad záhybem, použijte font-display: swap, aby se text ukázal hned, a pokud je externí služba písem pro vaše návštěvníky pomalá, hostujte písma sami.

Skripty třetích stran

Chatovací widgety, analytika, heatmapy, reklamní pixely, vložená videa a sociální kanály načítají kód z jiných serverů. Každý se zdá malý; dohromady bývají nejpomalejší částí stránky. Ponechte si ty, na které se skutečně díváte. Ostatní načtěte až po interaktivitě stránky a těžké vložené prvky (přehrávač YouTube, mapu) nahraďte lehkým náhledem, který načte skutečný obsah až po kliknutí.

Odezva serveru

Time to First Byte (TTFB), tedy jak dlouho server trvá, než začne odpovídat, leží pod každou další metrikou. Statické stránky podávané z CDN (sítě serverů blízko vašich návštěvníků; viz co je CDN) jsou rychlé téměř všude. Stránky, které server skládá při každém požadavku, závisí na něm a na jeho databázi. Cachování opakované práce a indexy databáze pro pomalé dotazy jsou obvyklé opravy.

Prompty, které fungují

Buďte konkrétní: pojmenujte stránku, metriku a omezení. Pokud máte, vložte nálezy z PageSpeed Insights.

PageSpeed Insights hlásí LCP 4,8 s na mobilu pro domovskou stránku a LCP prvkem je hero obrázek. Zmenši a převeď hero obrázek na WebP, podávej responzivní velikosti, nastav width a height, dej mu fetchpriority="high" a zajisti, aby nebyl líně načítán. Líně načítej každý obrázek pod záhybem. Nemění design.

Zaudituj závislosti této aplikace. Vypiš každý balík, co ho používá a zhruba kolik přidává do balíku. Odeber nepoužívané a rozděl trasy /admin a /settings na samostatné části, které se načtou, až když se na ně někdo podívá.

Vyhledávací pole na /products je pomalé. Debouncuj filtr, nepřekresluj celý seznam při každém stisku klávesy a pokud má seznam víc než 200 položek, stránkuj nebo virtualizuj.

Krok za krokem

1. Otestujte živou stránku v PageSpeed Insights na mobilu. Zapište LCP, INP a CLS a tři nejčastější problémy, které se objeví.
2. Nejdřív opravte obrázky: velikosti, formáty, rozměry, líné načítání pod záhybem, prioritu pro hero.
3. Odstraňte skripty třetích stran, které nepoužíváte, a zbytek odložte.
4. Zredukujte písma na to, co design potřebuje.
5. Zmenšete JavaScript: odstraňte nepoužívané balíky, dělte podle trasy.
6. Předrenderujte veřejné stránky, pokud jsou stále renderované na klientovi a LCP je pořád pomalé.
7. Zkontrolujte server: cachování, indexy databáze, statický hosting pro obsah, který se zřídka mění.
8. Znovu publikujte a znovu otestujte. Terénní data v PageSpeed Insights se aktualizují během následujících týdnů, jak přicházejí skutečné návštěvy, takže dřívější výsledky posuzujte podle laboratorních dat.

Časté chyby

• Testování jen na rychlém notebooku. Vaši návštěvníci jsou na středních telefonech a nestabilních mobilních datech. Testujte v mobilním režimu.
• Honba za dokonalými 100 body. Laboratorní skóre je průvodce. Jakmile jsou Core Web Vitals v dobrém pásmu, obsah a použitelnost jsou důležitější než posledních pár bodů.
• Líné načítání všeho, včetně hero obrázku. To zhorší LCP.
• Přidávání rychlostního pluginu nebo knihovny navrch. Odstranění zátěže téměř vždy porazí přidání kódu na její správu.
• Optimalizace náhledu, ne živého webu. Vývojové náhledy běží na neoptimalizovaných buildech. Měřte publikovanou URL.
• Oprava rychlosti jednou. Každý nový widget, obrázek a funkce přidává váhu. Po velkých změnách znovu testujte.

Kontrolní seznam rychlosti

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 na mobilu
• Obrázky zmenšené, komprimované, moderní formát, s width a height
• Hero obrázek není líně načítán; obrázky pod záhybem líně načítány
• Žádné nepoužívané knihovny JavaScriptu; těžké trasy oddělené
• Dvě rodiny písem nebo méně, hlavní písmo přednačteno
• Jen skripty třetích stran, které skutečně používáte, načtené pozdě
• Veřejné stránky předrenderované nebo statické, kde to jde
• Znovu otestováno na živé URL po publikování

Rychlost a mobilní rozvržení jdou dohromady; viz jak udělat web responzivní pro mobily. Pro úplný průchod před spuštěním pokrývá zbytek jak dostat AI prototyp do produkce.

Rychlost na Mythexu

Na Mythexu tyto změny děláte požadavkem v chatu nebo v editoru kódu na Pro. Kontrolujte publikovanou URL, ne Náhled, protože Náhled běží na vývojovém serveru. Statické frontendy se při publikování nasazují jako statické weby (statické weby), což se hodí na obsahové stránky. Aplikace se serverem se škálují na nulu: když jsou nečinné, uspí se a probudí při další návštěvě, takže první požadavek po klidném období je pomalejší. Připojená databáze usne po 5 minutách nečinnosti (limity hostingu). Pokud je veřejná stránka pomalá jen při první návštěvě, je to pravděpodobná příčina. Udržování marketingových stránek statických pomáhá. Po změnách znovu publikujte a udělejte tvrdé obnovení stránky.

Otázky