Jak zrychlit načítání webu

Kde začít: nejrychlejší výhry

Než spouštíte komplexní optimalizaci, zaměřte se na tyto tři věci — mají největší dopad v nejkratším čase:

1. Obrázky (nejčastější příčina pomalých webů)

Neoptimalizované obrázky jsou zodpovědné za 60–80 % objemu stažených dat na průměrném webu. Co dělat:

• Převést na WebP — WebP je o 25–35 % menší než PNG nebo JPEG při stejné kvalitě. V PHP: imagecreatefromjpeg() + imagewebp(), nebo knihovna Intervention Image.
• Lazy loading — přidat loading="lazy" na všechny obrázky mimo viewport. Výjimka: hero obrázek (ten naopak musí mít fetchpriority="high").
• srcset a sizes — pro responsivní obrázky, aby mobilní prohlížeč nestahoval obraz pro desktop.
• Komprese — před nahráním komprimujte přes Squoosh, TinyPNG nebo automaticky při uploadu.

2. Caching

Bez cachingu server generuje každou stránku od nuly při každém návštěvníkovi. Dvě vrstvy:

• HTTP cache hlavičky — statické soubory (CSS, JS, obrázky, fonty) by měly mít Cache-Control: max-age=31536000, immutable. Nastavte v .htaccess nebo nginx.conf.
• PHP OPcache — PHP kompiluje skripty při každém requestu, pokud není OPcache zapnutý. Zkontrolujte v phpinfo(), zda je aktivní.

3. Minifikace CSS a JavaScript

Nekomprimované soubory mohou být 2–5× větší než potřeba. Veškeré komentáře, mezery a odsazení přidávají bytes bez hodnoty pro prohlížeč. Nástroje: Vite/esbuild pro JS, PurgeCSS pro odstranění nepoužitého Tailwind CSS.

Střední úroveň: server a CDN

Gzip / Brotli komprese

Textové soubory (HTML, CSS, JS) se komprimují na 20–30 % původní velikosti. Brotli je novější a lepší než Gzip. Ověřte přes curl -I -H "Accept-Encoding: br" https://vaseweb.cz — v response byste měli vidět Content-Encoding: br.

CDN (Content Delivery Network)

CDN servíruje statické soubory z geograficky blízkého serveru. Pro CZ/SK weby stačí Cloudflare (free tier) — přesměruje DNS, automaticky komprimuje, cachuje statiku a chrání před DDoS. Konfigurace trvá 15 minut.

TTFB — Time to First Byte

TTFB nad 600 ms signalizuje buď pomalý hosting, nebo pomalou PHP aplikaci. Příčiny: zbytečné databázové dotazy při každém requestu, absence server-side cache, přetížený sdílený hosting. Řešení podle příčiny: optimalizace dotazů, Redis/Memcached cache, nebo přestup na lepší hosting.

Pokročilá úroveň: databáze a backend

N+1 problém

Klasická past v ORM frameworcích (Doctrine, Eloquent, ActiveRecord). Místo jednoho SQL dotazu, který načte 100 záznamů s relacemi, se provede 101 dotazů (1 + 100 pro každý záznam zvlášť). Řešení: JOIN nebo eager loading (with() v Eloquent, JOIN FETCH v Doctrine).

Chybějící databázové indexy

Dotaz bez indexu prohledává celou tabulku. Na tabulce s 10 000 záznamy to trvá milisekundy, na tabulce s milionem záznamů sekundy. Identifikujte problematické dotazy přes MySQL EXPLAIN nebo slow query log (slow_query_log = 1 v my.cnf).

SELECT * místo konkrétních sloupců

Každý sloupec navíc zvyšuje objem dat přenesených z databáze. Pokud potřebujete jen ID a jméno uživatele, pište SELECT id, name FROM users, ne SELECT *.

Jak ověřit výsledky

Po každé změně měřte, ne odhadujte:

• PageSpeed Insights — pagespeed.web.dev — celkové skóre + CWV
• WebPageTest.org — detailní waterfall diagram načítání
• Chrome DevTools — záložka Network (co se stahuje) + Lighthouse (audit)
• GTmetrix — přehledný report s doporučeními

Měřte vždy z mobilního pohledu — Google primárně hodnotí mobile-first a mobilní skóre bývá výrazně horší než desktop.