Proč je váš web pomalý: 5 příčin a jak je opravit

⏱️ Doba čtení: ~10 minut | 📅 Publikováno: 23.prosince 2025

Pomalý web je díra v rozpočtu

Není to technický problém. Není to "něco, co jednou opravíme". Je to díra, kterou unikají peníze — každý den, zatímco čtete tento text.

Zákazník klikne na vaši reklamu. Za ten klik jste zaplatili. Web se načítá sekundu, dvě, tři... Na čtvrté zavře záložku. Peníze pryč, zákazník pryč, a vy jste se o tom ani nedozvěděli.

A to není ojedinělý případ — je to systém. Každá sekunda načítání navíc odřízne část publika. Google vás srazí ve vyhledávání. Konverze klesají. A vy si myslíte, že problém je v reklamě, v produktu, v ceně — v čemkoli kromě té bílé obrazovky, kterou vidí vaši zákazníci.

Dobrá zpráva: dá se to vyléčit. Ale nejdřív potřebujete diagnózu.

Diagnostika: kde začít

Než začnete něco optimalizovat, musíte měřit. "Připadá mi, že web je pomalý" není diagnóza. Potřebujete konkrétní čísla.

Nástroje pro testování

Google PageSpeed Insights — zdarma a nejdůležitější. Zobrazuje skóre od 0 do 100 pro mobilní a desktopovou verzi zvlášť. Pokud vidíte červenou zónu (0-49) — máte vážné problémy. Oranžová (50-89) — prostor pro zlepšení. Zelená (90-100) — vše v pořádku.

GTmetrix — podrobnější report. Zobrazuje "vodopád" načítání: co se načítá, v jakém pořadí, jak dlouho každý prvek trvá. Užitečné pro hledání konkrétních úzkých míst.

WebPageTest — pro hloubkovou analýzu. Umožňuje testovat z různých lokací a zařízení. Pokud je vaše publikum v Evropě, ale server v USA — tady to uvidíte.

Mobile vs Desktop: proč je to důležité

Google používá Mobile-First Indexing. To znamená, že pro řazení se dívá na mobilní verzi vašeho webu, i když uživatel hledá z počítače.

Například: PageSpeed ukazuje 85 bodů pro desktop a 35 pro mobil. Majitel webu kontroloval jen desktop a myslel si, že je vše v pořádku. Mezitím Google celou dobu viděl pomalý mobilní web.

Vždy kontrolujte obě verze. Pokud musíte volit prioritu — mobilní je důležitější.

A ještě jedna věc: netestujte web na svém počítači s rychlým internetem. Chrome DevTools umožňuje simulovat pomalé 3G — takto váš web vidí mnoho mobilních uživatelů.

Core Web Vitals: tři metriky, které Google chce

V roce 2021 Google zavedl Core Web Vitals jako oficiální faktor řazení. Jsou to tři konkrétní metriky, které měří skutečný uživatelský zážitek. Ne abstraktní "rychlost", ale konkrétní věci.

LCP (Largest Contentful Paint)

Co to je: čas, za který se načte největší viditelný prvek na obrazovce. Obvykle je to hlavní obrázek, video nebo velký blok textu.

Cílová hodnota: do 2,5 sekundy — dobré. 2,5-4 sekundy — vyžaduje zlepšení. Více než 4 sekundy — špatné.

Typická příčina problémů: těžký hero obrázek bez optimalizace, pomalý server, render-blocking zdroje.

INP (Interaction to Next Paint)

Co to je: čas od kliknutí/tapnutí uživatele do vizuální odezvy webu. Nahradil starou metriku FID v březnu 2024.

Cílová hodnota: do 200 ms — dobré. 200-500 ms — vyžaduje zlepšení. Více než 500 ms — špatné.

Typická příčina problémů: těžký JavaScript, zejména skripty třetích stran (analytika, chatboti, reklamní pixely). Uživatel klikne na tlačítko — a půl sekundy se nic neděje.

CLS (Cumulative Layout Shift)

Co to je: jak moc obsah "skáče" během načítání. Znáte ten pocit, když chcete kliknout na tlačítko, a ono najednou sjede dolů, protože se načetla reklama?

Cílová hodnota: do 0,1 — dobré. 0,1-0,25 — vyžaduje zlepšení. Více než 0,25 — špatné.

Typická příčina problémů: obrázky bez uvedených rozměrů, fonty načítající se se zpožděním, dynamický obsah (reklamy, bannery).

Příčina #1: Těžké obrázky

Nejčastější příčina pomalých webů. A nejsnáze se opravuje.

Typický scénář: designér nahrál hero obrázek 4000×3000 pixelů, 5 MB. Na webu se zobrazuje v 1200×800. Těch 5 MB se stejně stáhne celých. Vynásobte 10-15 obrázky na stránku — a máte 50+ MB, které uživatel musí stáhnout.

Jak to opravit

Komprimujte obrázky. Nástroje jako TinyPNG nebo Squoosh zmenší velikost o 60-80% bez viditelné ztráty kvality. Je to zdarma a trvá to minutu.

Používejte moderní formáty. WebP je o 25-35% menší než JPEG při stejné kvalitě. AVIF je ještě menší, ale nepodporují ho všechny prohlížeče. WordPress, Shopify a většina moderních CMS umí automaticky konvertovat do WebP.

Uveďte rozměry. Vždy přidávejte atributy width a height k tagu <img>. To zabrání "skákání" obsahu (CLS) během načítání.

<!-- ❌ Špatně -->
<img src="photo.jpg">
<!-- ✅ Dobře -->
<img src="photo.webp" width="800" height="600" alt="Popis obrázku">

Zapněte lazy loading. Obrázky pod ohybem stránky nemusí se načítat hned. Atribut loading="lazy" odloží jejich načítání, dokud k nim uživatel nedoscrolluje.

<img src="photo.webp" loading="lazy" width="800" height="600" alt="Popis">

Responzivní obrázky. Různé velikosti obrazovky potřebují různé velikosti obrázků. Proč by mobilní telefon stahoval obrázek široký 2000 pixelů?

Nejrychlejší způsob, jak získat výsledky — prostě zkomprimujte obrázky na hlavní stránce přes TinyPNG. 10 minut práce může zrychlit web o 30-50%.

Příčina #2: Nabobtnalý kód (CSS/JavaScript)

Moderní weby jsou přetížené kódem. Typické WordPress téma s sebou táhne 20+ CSS souborů a stejně tolik JavaScriptu. Většina tohoto kódu se na konkrétní stránce nepoužívá.

Render-blocking zdroje

To je nejzákeřnější problém. Prohlížeč nezačne zobrazovat stránku, dokud nestáhne a nezpracuje CSS a JS umístěné v <head>. Uživatel vidí bílou obrazovku a čeká.

PageSpeed často zobrazuje varování "Eliminate render-blocking resources". Co s tím dělat:

Pro JavaScript: přidejte atribut defer nebo async. To umožní prohlížeči stahovat skript paralelně bez blokování renderování.

<!-- ❌ Blokuje renderování -->
<script src="analytics.js"></script>
<!-- ✅ Neblokuje -->
<script src="analytics.js" defer></script>

Pro CSS: vytáhněte kritické CSS (styly pro první obrazovku) inline do <head>, a zbytek načítejte asynchronně.

Minifikace

Minifikace odstraňuje mezery, komentáře a zkracuje názvy proměnných v kódu. Soubor se stane nečitelným pro člověka, ale prohlížeči je to jedno. Velikost se sníží o 10-30%.

Většina CMS má pluginy pro automatickou minifikaci. Pro WordPress — Autoptimize, WP Rocket, LiteSpeed Cache.

Nepoužívané CSS/JS

Chrome DevTools (záložka Coverage) ukazuje, kolik kódu na stránce se skutečně používá. Často je to 20-30% z načteného. Zbytek je mrtvá váha.

Řešení závisí na situaci:

• Odstraňte pluginy/moduly, které nepoužíváte
• Načítejte skripty jen na stránkách, kde jsou potřeba
• Pro složité případy — nástroje jako PurgeCSS

Ale pozor: agresivní minifikace a odstraňování "zbytečného" kódu může web rozbít. Vždy testujte na staging prostředí před produkčním nasazením.

Příčina #3: Příliš mnoho HTTP požadavků

Každý soubor na stránce je samostatný HTTP požadavek na server. CSS, JavaScript, obrázky, fonty, ikony... Na typickém webu jich může být 100+. Každý požadavek má latenci a ty se sčítají.

Skripty třetích stran: tichí zabijáci rychlosti

Typická sestava na marketingovém webu:

• Google Analytics
• Google Tag Manager
• Facebook Pixel
• Hotjar nebo Clarity
• Intercom nebo jiný chatbot
• Reklamní skripty

Každý z těchto skriptů s sebou táhne další skripty. GTM může načíst desítky dalších tagů. A všechny se spouštějí v prohlížeči uživatele, spotřebovávají prostředky.

Výsledek: metrika INP letí do červené zóny. Uživatel klikne — a web "přemýšlí" půl sekundy, protože JavaScript je zaneprázdněn analytikou.

Co dělat:

• Proveďte audit: kolik skriptů skutečně používáte? Ten Hotjar, který jste nainstalovali před rokem — dívá se někdo na ty záznamy?
• Načítejte nekritické skripty se zpožděním (po načtení stránky)
• Používejte GTM rozumně — ne všechno je třeba trackovat

Fonty

Google Fonts jsou pohodlné, ale každý font je požadavek na externí server. A pokud jste připojili 3 fonty po 4 řezech — to je 12 požadavků.

Řešení:

• Omezte se na 1-2 fonty
• Načítejte jen řezy, které potřebujete (400, 700, ne všechno od 100 do 900)
• Hostujte fonty lokálně místo Google Fonts
• Použijte font-display: swap, aby byl text viditelný před načtením fontu

Slučování souborů

10 malých CSS souborů je lepší sloučit do jednoho. To sníží počet požadavků. Ale s HTTP/2 to už není tak kritické — protokol umožňuje načítat mnoho souborů paralelně.

Příčina #4: Absence cachování

Bez cachování prohlížeč stahuje všechny soubory znovu při každé návštěvě. Logo webu, CSS, JavaScript — vše se načítá znovu a znovu, i když se to nezměnilo.

Cachování v prohlížeči

Server může prohlížeči říct: "Tento soubor se rok nezmění, ulož si ho lokálně." Při další návštěvě se soubor načte z cache okamžitě.

Nastavuje se přes HTTP hlavičky Cache-Control a Expires. Pro statické soubory (CSS, JS, obrázky) se doporučuje cachovat na rok.

# Příklad pro Nginx
location ~* \.(css|js|jpg|jpeg|png|gif|ico|webp|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Serverové cachování

Dynamické stránky (PHP, Python, Node.js) se generují na každý požadavek. Server vykonává kód, dotazuje se databáze, sestavuje HTML. To zabere čas.

Serverová cache ukládá hotové HTML. Další uživatel dostane uloženou kopii bez vykonávání kódu.

Nástroje:

• OPcache — cachuje zkompilovaný PHP kód. Měl by být zapnutý na jakémkoli PHP serveru.
• Redis / Memcached — cachují výsledky databázových dotazů a objekty.
• Varnish — HTTP cache před webovým serverem. Může web dramaticky zrychlit.
• Pluginy — WP Super Cache, W3 Total Cache, LiteSpeed Cache pro WordPress.

Page Cache

Pro většinu obsahových webů (blogy, katalogy, landing pages) je plné cachování stránek nejefektivnější metodou. Stránka se vygeneruje jednou, pak se servíruje jako statické HTML.

Ale pamatujte: cachování nefunguje pro stránky s personalizovaným obsahem (košík, uživatelský účet). Tam je potřeba jiný přístup — fragmentové cachování nebo AJAX načítání dynamických částí.

Příčina #5: Pomalý server

Můžete perfektně optimalizovat frontend, ale pokud server odpovídá 2 sekundy — web bude stejně pomalý.

TTFB (Time To First Byte)

Čas od požadavku do prvního bajtu odpovědi. Ukazuje, jak rychle server reaguje. Ideálně — do 200 ms. Pokud více než 600 ms — je problém.

Vysoké TTFB může znamenat:

• Přetížený nebo slabý server
• Pomalá databáze
• Neoptimalizovaný backend kód
• Server geograficky daleko od uživatelů

Gzip / Brotli komprese

Textové soubory (HTML, CSS, JS, JSON) lze komprimovat před odesláním. Gzip zmenšuje velikost o 70-80%. Brotli je ještě efektivnější pro text.

Zkontrolujte, zda je komprese zapnutá. V Chrome DevTools (Network → vybrat soubor → Headers) hledejte Content-Encoding: gzip nebo br.

# Zapnutí Gzip v Nginx
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml;
gzip_min_length 1000;

Verze PHP

Rozdíl ve výkonu mezi verzemi PHP je dramatický. PHP 8.3 může být dvakrát rychlejší než PHP 7.4 na stejném kódu.

Databáze

Pomalé databázové dotazy jsou častou příčinou vysokého TTFB. Zejména na webech s velkým množstvím obsahu nebo složitými filtry.

Základní kroky:

• Zapněte slow query log pro nalezení problémových dotazů
• Přidejte indexy na pole, podle kterých se vyhledává
• Optimalizujte tabulky (OPTIMIZE TABLE pro MySQL)
• Nakonfigurujte MySQL buffery (innodb_buffer_pool_size)

Hosting

Levný sdílený hosting nebo VPS znamená stovky webů na jednom serveru. Pokud sousední web/klient "sežere" prostředky — trpí všichni.

Dedikovaný server poskytuje garantované prostředky. Rozdíl v rychlosti může být 2-3×.

CDN: kdy ho skutečně potřebujete

CDN (Content Delivery Network) je síť serverů po celém světě, které uchovávají kopie vašeho obsahu. Uživatel dostává soubory z nejbližšího serveru, ne z vašeho hlavního.

Kdy CDN pomůže

• Geograficky rozptýlené publikum. Server v Nizozemsku, ale polovina uživatelů v Asii? Latence bude znatelná.
• Hodně statického obsahu. Obrázky, CSS, JS — to vše CDN servíruje efektivněji.
• Špičky provozu. CDN může převzít 60-80% zátěže a chránit hlavní server.
• DDoS ochrana. Většina CDN (zejména Cloudflare) filtruje škodlivý provoz.

Kdy CDN není potřeba

• Lokální byznys. Pokud jsou všichni uživatelé v jedné zemi a server také — CDN nedá znatelné zrychlení.
• Dynamický obsah. CDN cachuje statiku. Pro personalizované stránky je méně efektivní.
• Nízký provoz. Náklady na nastavení se nemusí vyplatit.

Z našich zkušeností: pokud je vaše publikum v jedné zemi a server poblíž — CDN přinese 10-15% zlepšení díky cachování statiky. Skutečný efekt (50%+) pocítí projekty s globálním publikem. Ale i pro lokální weby je CDN užitečný jako DDoS ochrana a další vrstva cachování.

Checklist: 15 bodů ke kontrole

Rychlá sebeanalýza. Projděte seznam a označte, co je hotovo:

🖼️ Obrázky

• ☐ Obrázky jsou zkomprimované (TinyPNG, Squoosh)
• ☐ Používá se WebP místo JPEG/PNG
• ☐ Uvedeny width a height pro všechny <img>
• ☐ Lazy loading pro obrázky pod ohybem

💻 Kód

• ☐ CSS/JS minifikováno
• ☐ Kritické CSS inline v <head>
• ☐ JavaScript s atributem defer nebo async
• ☐ Odstraněny nepoužívané pluginy/skripty

🌐 Server

• ☐ Gzip nebo Brotli komprese zapnutá
• ☐ PHP verze 8.2+ (doporučeno 8.3/8.4)
• ☐ OPcache zapnutý
• ☐ Cachování v prohlížeči nastaveno (Cache-Control)

📊 Monitoring

• ☐ TTFB pod 600 ms
• ☐ Core Web Vitals v zelené zóně
• ☐ Pravidelná kontrola přes PageSpeed (měsíčně)

Pokud více než 5 bodů není splněno — je významný prostor pro zlepšení.

FAQ: Často kladené otázky

Jaká rychlost načítání je považována za normální?

Google doporučuje LCP do 2,5 sekundy. V praxi: pokud se stránka plně načte za 3 sekundy — je to dobré. Za 1-2 sekundy — výborné. Více než 5 sekund — problém, který uživatelé pocítí.

Stačí nainstalovat plugin pro cachování?

Je to dobrý první krok, ale ne všelék. Plugin pro cachování pomůže se zátěží serveru, ale neopraví těžké obrázky, render-blocking skripty nebo pomalou databázi. Je potřeba komplexní přístup.

Web je rychlý na počítači, ale pomalý na mobilu. Proč?

Mobilní zařízení mají slabší procesory a často pomalejší internet. JavaScript, který se rychle spustí na desktopu, může mobilní prohlížeč "pověsit". Vždy testujte mobilní verzi zvlášť.

Ovlivňuje rychlost SEO?

Ano, přímo. Core Web Vitals jsou od roku 2021 oficiálním faktorem řazení Google. Pomalé weby dostávají nižší pozice. Navíc pomalý web má vyšší bounce rate, což také negativně ovlivňuje SEO.

Jak často kontrolovat rychlost?

Doporučujeme měsíčně přes PageSpeed Insights. Povinně — po aktualizacích CMS, instalaci nových pluginů nebo změnách na webu. Rychlost může postupně degradovat a pravidelný monitoring pomáhá to včas zachytit.

Sdílený hosting vs VPS: jak velký je rozdíl v rychlosti?

Záleží na konkrétních poskytovatelích, ale v průměru je VPS 2-3× rychlejší. Hlavní výhodou jsou garantované prostředky. Na sdíleném hostingu váš web soutěží se stovkami dalších o CPU a RAM.