1. První krok: rozpoznání adresy a DNS překlad
Jakmile zadáte adresu webu, prohlížeč nejdřív zjistí, kam má požadavek poslat. Pokud napíšete www.example.cz, počítač nepracuje s názvem domény, ale s IP adresou serveru. O tu se postará DNS (Domain Name System), což je v praxi internetový „telefonní seznam“.
DNS dotaz obvykle neprobíhá jen jednou. Prohlížeč nejprve zkontroluje vlastní cache, pak systémovou cache, DNS resolver poskytovatele nebo veřejnou službu jako Google DNS (8.8.8.8), Cloudflare (1.1.1.1) nebo DNS server hostingu. Pokud záznam není uložený, resolver se ptá dál – autoritativních DNS serverů domény. Tohle celé může trvat od jednotek milisekund po desítky milisekund, u špatně nastaveného DNS i déle.
Pro SEO a výkon je DNS důležitější, než se zdá. Pomalý DNS lookup zpomalí první načtení a zbytečně prodlužuje TTFB i start renderingu. Prakticky to poznáte třeba u webů, které používají mnoho externích domén – analytika, chat widgety, tag manager, CDN, fonty. Každá další doména znamená potenciální další DNS dotaz.
- Jak měřit: Chrome DevTools > Network, WebPageTest, GTmetrix, Pingdom.
- Co zlepšit: omezit externí domény, použít dns-prefetch a preconnect, správně nastavit TTL.
- Praktický tip: pokud váš web využívá CDN, přidejte preconnect už do hlavičky HTML pro nejdůležitější externí hosty.
2. Navázání spojení: TCP, TLS a proč HTTPS není jen „zámek“
Jakmile prohlížeč zná IP adresu, musí se k serveru připojit. U moderního webu to znamená kombinaci síťového spojení a šifrování. Tradičně se používá TCP, u novějších protokolů jako HTTP/3 běží komunikace nad QUIC, který staví na UDP a lépe zvládá ztrátovost i mobilní sítě.
Před samotným přenosem dat proběhne u HTTPS TLS handshake. Prohlížeč ověřuje certifikát, dohodne šifry a klíče a teprve pak se začne posílat obsah. U HTTP/2 a HTTP/3 je toto zásadní: web může být rychlý i bezpečný zároveň. Pokud je certifikát špatně nastavený, expiruje nebo řetězec důvěry není kompletní, návštěvník vidí varování a důvěra i konverze klesají.
V praxi se vyplatí sledovat nejen „jestli web běží na HTTPS“, ale i kvalitu konfigurace. Například web s dlouhým TLS handshake bude pomalejší na první návštěvě. Pomůže CDN, moderní certifikáty, zapnuté HTTP/2 nebo HTTP/3, správné cache hlavičky a minimalizace redirectů.
- Nástroje: SSL Labs pro test certifikátu, WebPageTest pro waterfall, Chrome DevTools pro timing.
- Co hlídat: expiraci certifikátu, řetězec intermediate certifikátů, přesměrování http → https → www/non-www.
- SEO dopad: pomalé nebo rozbité HTTPS zhoršuje UX, crawl efficiency i důvěryhodnost webu.
3. Požadavek na server: co se děje mezi prohlížečem a backendem
Když je spojení připravené, prohlížeč odešle HTTP request. V něm je metoda, hlavičky, cookies, jazyk, typ zařízení, cache instrukce a další metadata. Server podle toho rozhodne, zda vrátí stránku z cache, nebo ji dynamicky vygeneruje. U WordPressu to často znamená běh PHP, dotazy do databáze a renderování šablony. U Next.js nebo headless řešení může server vracet předrenderovaný HTML výstup nebo data pro hydratační vrstvu.
Pro výkon je klíčová metrika TTFB (Time to First Byte). Pokud je vysoká, problém bývá na serveru, v databázi, v pluginu, v API integraci nebo v hostingu. U dobře optimalizovaného webu se TTFB často drží pod 200 ms na kvalitní síti, u pomalejších webů ale snadno přeskočí 600 ms až 1 s.
Na serverové straně se vyplatí sledovat:
- cache: page cache, object cache, CDN cache;
- databázi: pomalé dotazy, indexy, počet pluginů;
- middleware: redirecty, security pluginy, WAF;
- aplikaci: render čas šablony, API volání, externí služby.
U e-shopů je typický problém v tom, že stránka produktů načítá desítky skriptů, recenze, doporučení, měření a personalizaci. Výsledek? HTML sice dorazí rychle, ale stránka se „skutečně“ zobrazí až později. Pro Core Web Vitals je důležité nejen poslat první bajt, ale i rychle vykreslit hlavní obsah a minimalizovat blokující JS.
4. HTML, CSS, JavaScript: jak se stránka skládá v prohlížeči
Po doručení HTML prohlížeč začíná stavět DOM a současně stahovat další zdroje. CSS je obvykle render-blocking, takže bez něj se stránka nemá správně vykreslit. JavaScript může být ještě problematičtější: pokud je umístěný nevhodně, zastaví parsing HTML a prodlouží dobu, než uživatel uvidí obsah. Tady se láme chleba mezi „server odpověděl“ a „uživatel něco vidí“.
Moderní webové technologie to řeší různě. Next.js využívá server-side rendering, statické generování nebo hybridní režimy. WordPress zase často spoléhá na pluginy, které přidávají skripty bez kontroly jejich dopadu. U obou platí stejná zásada: méně blokujících zdrojů, lepší priority a co nejrychlejší načtení hlavního obsahu.
Konkrétní postupy, které dávají smysl:
- odebrat nepoužívané CSS a JS;
- odložit skripty pomocí defer nebo async tam, kde to nepoškodí funkčnost;
- inline kritické CSS pro nadpisy, menu a hero sekci;
- komprimovat přes Brotli nebo Gzip;
- nasadit moderní formáty obrázků jako WebP nebo AVIF;
- preloadovat fonty a klíčové assety.
U Core Web Vitals je důležité sledovat LCP (Largest Contentful Paint), CLS a INP. Pokud se LCP zlepšuje, ale INP je špatné, stránka sice rychle vypadá hotově, ale na interakce reaguje pomalu. To bývá typické u webů přetížených marketingovými skripty, chaty, heatmapami a A/B testy.
5. Co si z toho odnést pro SEO, výkon a měření
Celá cesta od zadání adresy po plně načtenou stránku ukazuje, že výkon webu není jeden problém, ale řetězec desítek drobných rozhodnutí. Pro SEO je klíčové, aby vyhledávač i uživatel dostali rychle dostupný, dobře čitelný a stabilní obsah. Pokud se web zbytečně zdržuje na DNS, TLS, serveru nebo v JavaScriptu, zhoršuje se crawl budget, indexace i uživatelská zkušenost.
V praxi doporučuji tento diagnostický postup:
- 1. Změřte waterfall: WebPageTest nebo Chrome DevTools ukáže, kde se čeká nejdéle.
- 2. Zkontrolujte TTFB: pokud je vysoké, řešte hosting, cache a backend.
- 3. Ověřte DNS a TLS: SSL Labs, DNS checker, měření z více lokalit.
- 4. Sledujte Core Web Vitals: PageSpeed Insights, Search Console, CrUX.
- 5. Auditujte skripty: kolik jich běží, kdo je přidal a zda skutečně přinášejí hodnotu.
Pro marketéry je důležité vědět, že i „neviditelná“ infrastruktura má přímý dopad na výkon kampaní. Pomalý web zvyšuje bounce rate, snižuje konverzi a prodražuje PPC. Pro vývojáře je zase zásadní oddělit problém frontendu od backendu a měřit každou vrstvu zvlášť. A pro majitele webu je nejdůležitější jednoduché pravidlo: rychlost, stabilita a bezpečnost nejsou technický luxus, ale přímý obchodní faktor.
Když tedy příště zadáte webovou adresu, proběhne v pozadí přesně řízený řetězec kroků – od DNS přes šifrované spojení až po vykreslení stránky. A právě v těchto milisekundách se rozhoduje o tom, zda web působí profesionálně, nebo zbytečně ztrácí návštěvníky ještě před prvním kliknutím.