Pomalé načítání webových stránek: Zjistěte, kde je problém a vyřešte ho

Stručné shrnutí: Pomalý web neposuzujte podle pocitu. LCP nad 2,5 s už znamená reálný problém. Sledujte TTFB: do 800 ms obvykle ukazuje na aplikaci, vyšší hodnoty spíš na hosting. Místo náhodného vypínání pluginů začněte testem v PageSpeed nebo WebPageTest a rychle zjistíte, jestli řešit obsah stránky, nebo server.

Pomalý web není jen nepříjemnost, ale konkrétní problém, který se dá změřit a vyřešit. Klíčová otázka je jednoduchá: čekají uživatelé na server, nebo na samotnou stránku? V článku si ukážeme, jak to během pár minut poznat a jestli má smysl řešit aplikaci, nebo hosting.

Obsah článku

• Jak poznat pomalý web
• Příklad z praxe: pluginy
• Správná diagnostika
• Problém je v aplikaci
• Problém je v hostingu
• FAQ

Jak poznat, že váš web je skutečně pomalý (a nejde jen o váš prohlížeč)

Pomalý web není pocit, ale měřitelný stav. To je důležité si uvědomit hned na začátku, jinak se snadno pustíte do optimalizací, které problém vůbec neřeší.

Google používá pro hodnocení rychlosti Core Web Vitals, kde je hlavní metrikou LCP:

• LCP do 2,5 s = dobrý stav
• 2,5–4 s = potřeba zlepšení
• nad 4 s = problém

Chcete-li více informací, můžete začít u článku Co je page speed.

Pokud tyto hodnoty překračujete opakovaně, znamená to, že pomalé načítání vidí i vaši návštěvníci, nejen vy na svém zařízení.

Pro rychlou orientaci si vystačíte se dvěma čísly:

• LCP (Largest Contentful Paint) ukazuje, kdy se zobrazí hlavní obsah stránky.
• TTFB (Time to First Byte) říká, za jak dlouho server začne odpovídat.

LCP tedy ukazuje reálný uživatelský zážitek, TTFB vám napoví, kde problém hledat.

V praxi se tyto metriky krásně doplňují. Můžete mít rychlý server (nízký TTFB), ale pomalý web kvůli obrázkům nebo skriptům (vysoké LCP). Stejně tak může být stránka lehká, ale server odpovídá pomalu (pak jsou LCP i TTFB vysoké).

Jednoduché pravidlo: Pomalé načítání webu způsobuje aplikace ve chvíli, kdy server odpoví rychle (nízký TTFB), ale stránka se vykresluje pomalu. Pokud je pomalá už samotná odpověď serveru (vysoký TTFB), problém je v hostingu nebo backendu.

Typický příklad z praxe: Pomalý web kvůli pluginům

S tímto problémem se setkáváme často: uživatelé si na WordPress nainstalují zbytečné pluginy, které pak zatěžují systém.

Na čisté instalaci WordPressu jsme naměřili TTFB 146 ms. Po přidání 18 pluginů vzrostl na 612 ms. Hosting zůstal stejný, ale aplikace začala server výrazně víc zatěžovat.

To je přesně situace, kdy se pomalé načítání webových stránek řeší v aplikaci, ne změnou hostingu.

Nejčastější chybou je řešit hosting dřív než aplikaci. Ve většině případů pomalého webu jsou hlavním problémem obrázky, skripty nebo pluginy, ne server.

Než začnete cokoliv upravovat, udělejte si základní kontrolu:

• otevřete web v anonymním okně
• vypněte VPN, pokud ji používáte
• zkuste jinou síť (např. mobilní data)
• spusťte PageSpeed Insights

Pokud je web pomalý jen u vás, řešíte lokální problém (prohlížeč, DNS, připojení).

Pokud je pomalý všude, má smysl jít do hlubší diagnostiky.

Tenhle krok se často podceňuje, a přitom vám může ušetřit hodiny zbytečné práce.

Pět minut na diagnózu: proč je váš web pomalý?

Ve většině případů není třeba hluboký audit. Stačí pár měření a víte, jestli řešíte aplikaci (WordPress), nebo hosting.

Základní pravidlo, které se nám opakovaně potvrzuje:

• nízký TTFB + vysoký LCP: problém ve front-endu nebo aplikaci
• vysoký TTFB: problém vzniká ještě před vykreslením stránky (server, databáze, PHP)

Tohle jednoduché rozdělení funguje překvapivě spolehlivě a výrazně zrychlí rozhodování.

Přečtěte si, jak poznat pomalou databázi a co s tím.

Rychlý postup

Na základní diagnostiku stačí pár kroků. Cílem není detailní audit, ale rychle zjistit, jestli problém vzniká na serveru, nebo až při načítání stránky.

PageSpeed Insights

Začněte LCP (Largest Contentful Paint). Pokud je nad 2,5 s, web už působí pomalu pro reálné uživatele a má smysl hledat příčinu.

Důležité: PageSpeed ukazuje zvlášť mobilní a desktop verzi. Mobilní bývá skoro vždy pomalejší, protože simuluje slabší zařízení a pomalejší připojení. Pro hodnocení výkonu berte jako hlavní mobilní výsledek – ten je blíž realitě většiny návštěvníků a i Google řeší SEO hlavně pro mobily.

WebPageTest (Praha / Vídeň / Frankfurt)

Pak otestujte web z reálné lokality. Sledujte hlavně:

• TTFB – jak rychle odpoví server
• velikost stránky – kolik dat se načítá
• počet requestů

U běžného firemního webu je rozumný základ kolem 1–2 MB. Pokud vidíte 6–8 MB, problém je většinou v obsahu stránky (obrázky, skripty).

Waterfall (ve WebPageTest)

Po dokončení testu otevřete detail výsledku a klikněte na záložku Waterfall. Uvidíte graf, kde každý řádek představuje jeden načítaný soubor a čas běží zleva doprava.

Sledujte hlavně začátek:

• dlouhé čekání na první HTML → problém server / backend
• rychlá odpověď, ale dlouhé načítání souborů → problém front-end

Stačí pár sekund a víte, kde se „čeká“.

Opakujte test 3×

Jedno měření nestačí. Výsledky se liší podle zátěže. Rozdíl několika sekund na stejné stránce není výjimka.

Už se nám stalo, že jsme viděli rozdíl 2,1 s vs. 4,8 s na stejné stránce – jen kvůli cron úloze na pozadí.

Zkontrolujte administraci

Nakonec otevřete /wp-admin:

• pomalý admin → backend, databáze nebo hosting
• rychlý admin, pomalý web → front-end nebo šablona

Tenhle krok často rozhodne nejrychleji.

Kdy má smysl měnit hosting: Hosting má smysl řešit až ve chvíli, kdy je TTFB opakovaně vysoký z více lokalit a zpomalení se projevuje i v administraci.

Rozhodovací přehled

Výsledek měření	Pravděpodobný viník	Co řešit
TTFB do 500 ms, LCP nad 4 s	Obrázky, JavaScript, CSS	Aplikace
TTFB 500–1 000 ms, LCP nad 3 s	Kombinace	Nejprve aplikace
TTFB nad 1 000 ms opakovaně	Hosting, DB, PHP	Hosting
Rychlé testy, pomalé jen u vás	Prohlížeč / síť	Lokální problém

Poznámka: Ve spoustě reálných případů (hlavně bez cache nebo u dynamičtějších webů) je úplně normální vidět TTFB 800–1 000 ms.

Důležité je sledovat trend, ne jeden výsledek. Konzistentní problém má větší váhu než jeden špatný test.

Mini šablona pro vlastní test

URL:
Datum a čas:
Nástroj:
Lokalita:
TTFB:
LCP:
Velikost:
Počet requestů:
Pomalý i admin? ano/ne
Závěr:

Pokud si tyhle údaje zapíšete, máte během pár minut jasno v tom, kde problém vzniká a hlavně čemu se vyhnout.

Problém je v aplikaci: nejčastější viníci a rychlé opravy

Aplikační problém poznáte poměrně spolehlivě: server odpoví rychle (nízký TTFB), ale stránka se skládá dlouho. Jinými slovy: čekání nezačíná na serveru, ale až v prohlížeči.

Typický výsledek: TTFB 150–500 ms, ale LCP 4–6 sekund.

V praxi to znamená, že HTML dorazí včas, ale pak se načítají velké obrázky, skripty, fonty nebo se čeká na JavaScript. Hosting v tu chvíli problém není.

Obrázky: první kontrola u každé pomalé stránky

Obrázky jsou nejčastější a zároveň nejrychleji řešitelný problém. Pokud má homepage několik megabajtů a LCP prvek je velká fotografie nebo slider, víte, kde začít.

Zde je návod pro optimalizaci obrázků ve WordPressu.

Důležité není jen komprimovat, ale přizpůsobit obrázek skutečnému použití. Fotka ve 4000 px nemá co dělat v bloku širokém 1200 px.

Cache: rozdíl mezi dynamickým a statickým webem

Bez cache WordPress při každé návštěvě znovu skládá stránku (PHP, databázi i šablonu). S cache dostane uživatel hotové HTML.

To je zásadní rozdíl.

V interním testu:

• TTFB bez cache: 612 ms
• TTFB s cache: 188 ms

U běžných obsahových stránek je cache jeden z největších „quick wins“. U e‑shopu je potřeba být opatrnější. Homepage, kategorie a články cachovat můžete, košík a účet ne.

Cache ve WordPressu vyřešíte pomocí pluginu. Z praxe se nám nejvíce osvědčily 2: LiteSpeed Cache (návod na nastavení) a WP Super Cache (návod na nastavení).

Existuje více druhů cache. O všech si můžete přečíst v tomto blogovém článku.

Měřitelné rozdíly: běžný vs. optimalizovaný WordPress hosting

V interním srovnání z roku 2026 jsme testovali stejnou WordPress instalaci na běžném hostingu a na /webhosting/wordpressWebglobe WordPress hostingu s LiteSpeed serverem a serverovou cache.

Na stejném webu a bez úprav kódu se lišil hlavně TTFB a rychlost načítání:

• TTFB: 620–780 ms vs. 180–260 ms
• LCP: 3,8–4,6 s vs. 1,9–2,6 s

Rozdíl nevznikl změnou webu, ale prostředím. Serverová cache omezuje zpracování v PHP a LiteSpeed Cache plugin navíc umožňuje optimalizaci obrázků bez zásahu do webu.

Tenhle typ rozdílu ukazuje, proč má smysl řešit nejen aplikaci, ale i prostředí, na kterém běží.

Pluginy a šablona: skrytý výkonový dluh

Každý plugin přidává kód, dotazy nebo skripty. Problém není v tom, že plugin používáte, problém je, když se jeho kód načítá všude.

Typický scénář: formulářový plugin načítá JavaScript na každé stránce, i když formulář je jen na jedné.

V jednom testu přidalo 12 pluginů:

• 47 HTTP requestů
• 740 kB JavaScriptu

To už není detail, ale viditelný dopad na načítání.

Rychlá kontrola: otevřete si v prohlížeči DevTools (nástroje pro vývojáře), klikněte na záložku Network (Síť) a podívejte se, co se načítá. Pokud vidíte skripty, které na stránce nedávají smysl, máte kandidáta na optimalizaci.

Přečtěte si, jak WordPress a další aplikace ovlivňují rychlost webu.

Databáze: problém, který se projeví jinde

Databáze většinou nepoznáte podle homepage, ale podle administrace. Pomalé vyhledávání, ukládání nebo filtrování objednávek, to je typický signál.

Reálný případ:

• WooCommerce s 1,9 milionu řádků v wp_postmeta
• Frontend „ještě šel“, ale administrace reagovala 6+ sekund

Tohle je důležité: databázový problém se často maskuje jako „celkově pomalý web“, ale ve skutečnosti brzdí hlavně backend.

Začněte základním úklidem (revize, transienty, stará metadata), ale vždy se zálohou. Pokud si nejste jistí, co mažete, raději se zastavte. Špatný zásah umí web rozbít rychleji než pomalý dotaz.

Optimalizaci databáze se více věnujeme ve zvláštním článku.

Shrnutí: Pokud server odpovídá rychle, ale stránka se načítá pomalu, řešíte aplikaci. Nejčastěji jde o kombinaci obrázků, cache a zbytečného kódu.

WordPress může být rychlý i na sdíleném hostingu, pokud je aplikace optimalizovaná. Naopak špatně navržený web bude pomalý i na výkonném VPS.

Problém je v hostingu: jak to poznat a co s tím

Hosting se projeví jinak než aplikace. Nečekáte na obrázky nebo skripty, čekáte na samotnou odpověď serveru.

Typický signál: vysoký nebo kolísající TTFB.

Z praxe se opakuje jeden vzor: ráno TTFB 250 ms → odpoledne 1,6 s → večer výpadky.

Aplikace se během dne nemění. Server ano.

To je klíčový rozdíl.

Hosting je pravděpodobný viník, když:

• TTFB je opakovaně nad 800 ms
• hodnoty výrazně kolísají bez změny webu
• pomalý je frontend i administrace
• waterfall ukazuje čekání hned na začátku

Další silné signály jsou chybové stavy:

• 502 / 503 / 504
• timeouty
• vyčerpání PHP memory
• dosažení CPU nebo I/O limitu

Tohle už není optimalizace, ale limit prostředí.

I hosting se dá optimalizovat. Podrobně se tomu věnujeme v článku Jak zlepšit výkon webhostingu.

Problémem ale mohou být ostatní uživatelé, kteří neúměrně vytěžují server pro všechny. S tím nic neuděláte a pokud s tím nedělá nic ani sám poskytovatel, budete zbytečně trpět.

Začíná-li vás hosting omezovat a potřebujete-li mít garantovaný výkon jen pro sebe, zvažte přechod na vlastní virtuální server (VPS).

Přečtěte si, jak poznat, že je čas přejít na VPS.

Kdy už dává smysl VPS

Situace	Sdílený hosting	VPS
Menší firemní web	Stačí	Zbytečný
Blog	Stačí při stabilní návštěvnosti	Při růstu
WooCommerce	Hraniční	Často lepší
Importy / vlastní aplikace	Limitující	Vhodný

VPS dává smysl ve chvíli, kdy problém není v obsahu, ale v kapacitě.

Nejsnazší je přejít z webhostingu na managed VPS. Na běžném VPS se totiž musíte postarat o instalaci OS, zabezpečení i monitoring. Zjistěte, který VPS je pro vás nejlepší.

Jak komunikovat s hostingem

Pokud řešíte výkon s podporou, nepište „web je pomalý“. To nikam nevede.

Pošlete:

1. konkrétní čas testu
2. TTFB + waterfall
3. lokalitu testu
4. popis problému (admin / frontend / obojí)

S těmito daty vám podpora dokáže rozumně poradit. Bez nich bude hádat.

Shrnutí: Pokud čekáte na server (vysoký TTFB), řešíte hosting. Pokud čekáte na načtení stránky, řešíte aplikaci.

Přečtěte si také, jak PHP, databáze a web server ovlivňují rychlost webu.

Časté dotazy

Jak rychlý by měl web být?

Ideální je LCP do 2,5 s.

Pro běžný český web dává smysl:

• TTFB do 500 ms
• velikost stránky do 2 MB

Všechno nad to už začíná být viditelné pro uživatele.

Je pomalý web vždy chyba hostingu?

Ne. Ve většině případů je problém v aplikaci (obrázky, skripty, pluginy).

Hosting řešte ve chvíli, kdy je vysoký TTFB a pomalý je i admin.

Pomůže CDN?

Ano, ale jen částečně. CDN zrychlí statické soubory a pomůže při globální návštěvnosti. Nevyřeší pomalé PHP, databázi ani špatný plugin.

Kdy přejít na VPS?

Ve chvíli, kdy narážíte na limity:

• CPU
• RAM
• I/O
• PHP procesy

Přechod z hostingu na VPS je dobrý nápad typicky u větších e‑shopů nebo projektů s vysokou zátěží.

Pokud máte malý web s velkými obrázky, VPS problém nevyřeší, jen ho prodraží.