Proč je váš web pomalý (a jak to dnes opravit)

Rychlost webu není metrika pro okázalost, je přímým hnacím motorem příjmů. Výzkum Googlu ukazuje, že jednosekundové zpoždění načítání mobilní stránky snižuje konverze až o 20 %. Amazon proslul výpočtem, že každých 100 milisekund latence stálo 1 % tržeb. Pro firmu generující ročně prostřednictvím svého webu 500 000 € může půlsekundové zlepšení rychlosti znamenat hodnotu 50 000 € nebo více ročně. Rychlost jsou peníze a každá pomalá stránka představuje únik v potrubí vašich příjmů.

Kromě konverzí rychlost stránky přímo ovlivňuje vaše pozice ve vyhledávačích. Google používá rychlost stránky jako faktor hodnocení od roku 2010 a Core Web Vitals, soubor metrik uživatelské zkušenosti zahrnující Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) a Interaction to Next Paint (INP), se staly oficiálním signálem hodnocení v roce 2021. Weby, které tyto benchmarky nesplňují, jsou ve výsledcích vyhledávání aktivně penalizovány a ztrácejí viditelnost ve prospěch rychlejších konkurentů bez ohledu na kvalitu obsahu.

V GRADAX provádíme audit výkonu webu jako součást každého klientského projektu. Zjištění jsou pozoruhodně konzistentní: většina webů je výrazně pomalejší, než by měla být, a příčiny jsou téměř vždy odstranitelné. Neoptimalizované obrázky, nadbytečné JavaScript balíčky, špatný hosting a chybějící cachování tvoří přes 80 % problémů s výkonem, které diagnostikujeme. Následuje systematický průvodce identifikací a odstraněním každého z těchto úzkých hrdel.

Než začnete cokoli optimalizovat, stanovte spolehlivý výchozí stav. Google PageSpeed Insights je nejdostupnější startovní bod: zadejte svou URL a získáte podrobnou zprávu pokrývající Core Web Vitals, skóre výkonu a konkrétní doporučení pro optimalizaci. Spusťte ji na své domovské stránce i na nejnavštěvovanějších vstupních stránkách, protože výkon se výrazně liší mezi různými typy stránek. Lehká domovská stránka může mít skóre 95, zatímco stránka s výpisem produktů s desítkami obrázků má skóre 45.

Pro hlubší analýzu použijte Google Lighthouse v Chrome DevTools se zapnutým omezením sítě. Nastavte připojení na „Slow 4G“ a CPU na „4x slowdown“, abyste simulovali podmínky, které zažívá významná část vašich návštěvníků na mobilních zařízeních. Metriky výkonu za těchto omezených podmínek odhalí úzká místa, která jsou na vašem vysokorychlostním vývojovém stroji neviditelná. Věnujte zvláštní pozornost Time to First Byte (TTFB), který měří dobu odezvy serveru a je často limitujícím faktorem pro weby na sdíleném hostingu.

WebPageTest.org poskytuje nejkomplexnější analýzu včetně vodopádových grafů, které ukazují, kdy se každý zdroj načítá a jak se zdroje vzájemně blokují. Spusťte testy z více lokalit a na různých rychlostech připojení, abyste pochopili, jak si váš web vede u návštěvníků po celém světě. Zobrazení filmového pásu je obzvláště cenné; ukazuje postupné vykreslování stránky snímek po snímku, takže je okamžitě zřejmé, kdy velké zdroje způsobují viditelná zpoždění při načítání.

Obrázky jsou největším přispěvatelem k velikosti stránky na průměrném webu a tvoří přibližně 50 % celkového objemu přenesených dat. Neoptimalizovaný hlavní obrázek může snadno vážit 3–5 MB, což samo o sobě překračuje celkový doporučený rozpočet stránky Googlu ve výši 1,5 MB. Řešení je přímočaré: převést obrázky do moderních formátů, vhodně je zkomprimovat, nastavit správnou velikost a načítat je líně.

WebP a AVIF jsou moderní obrazové formáty, které byste měli používat. WebP poskytuje o 25–35 % menší velikosti souborů než JPEG při ekvivalentní vizuální kvalitě a podporuje ho každý hlavní prohlížeč. AVIF posouvá kompresi ještě dál, o 50–60 % menší než JPEG, ale kódování je pomalejší a podpora prohlížečů, i když roste, zatím není univerzální. Poskytujeme AVIF tam, kde je podporován, a v případě nepodpory přecházíme na WebP, přičemž pro automatický výběr formátu používáme HTML prvek picture nebo serverové vyjednávání obsahu.

Responzivní obrázky jsou stejně důležité. Posílání úvodního obrázku širokého 2400 pixelů na mobilní zařízení s viewportem 375 pixelů plýtvá šířkou pásma a časem zpracování. Použijte atribut srcset k poskytnutí více velikostí obrázků a nechte prohlížeč vybrat tu vhodnou. Pro většinu webů pokrývá poskytnutí obrázků v šířkách 640 px, 1024 px, 1440 px a 1920 px celý rozsah velikostí viewportu. V kombinaci s líným načítáním (nativní atribut loading="lazy") se obrázky pod ohybem nestahují, dokud se uživatel nepřiblíží k jejich zobrazení, což výrazně zlepšuje počáteční dobu načítání.

Vaše hostingové prostředí stanovuje výkonnostní minimum, které žádná front-endová optimalizace nepřekoná. Pokud serveru trvá 800 milisekund vygenerovat HTML odpověď, vaše stránka se nemůže načíst pod jednu sekundu bez ohledu na to, jak dobře optimalizujete obrázky a skripty. Time to First Byte (TTFB) by měl být u většiny stránek pod 200 milisekund. Pokud váš TTFB trvale překračuje 400 milisekund, vaším úzkým místem je hosting.

Sdílený hosting je nejčastějším viníkem. Na sdíleném serveru váš web soutěží s desítkami nebo stovkami dalších webů o CPU, paměť a I/O šířku pásma. Když sousední web zažije špičku návštěvnosti nebo spustí náročný skript, váš výkon se zhorší. Upgrade na VPS nebo vyhrazený cloudový server tuto konkurenci eliminuje tím, že garantuje vaši alokaci zdrojů. Konkrétně pro WordPress weby může spravovaný WordPress hosting, který zahrnuje cachování na úrovni serveru, PHP opcode cachování a optimalizaci databázových dotazů, snížit TTFB o 60–80 % ve srovnání s běžným sdíleným hostingem.

Umístění serveru také hraje větší roli, než si většina lidí uvědomuje. Fyzika ukládá minimální latenci na základě rychlosti světla ve vláknovém kabelu, přibližně 1 milisekunda na 100 kilometrů. Server ve Spojených státech odpovídající uživateli v Německu přidává minimálně 60–80 milisekund latence na obousměrnou komunikaci, než začne jakékoli zpracování. Pokud je většina vašeho publika v konkrétním regionu, hostujte server v tomto regionu. Pro globální publikum přibližuje CDN váš obsah uživatelům bez ohledu na umístění serveru.

Moderní weby přenášejí obrovské množství JavaScriptu a CSS, z nichž velkou část prohlížeč uživatele nikdy nepotřebuje. Mediánový web v roce 2025 přenáší přes 500 KB JavaScriptu a stránky postavené na těžkých frameworcích nebo zatížené skripty třetích stran často překračují 2 MB. Každý kilobajt JavaScriptu musí být stažen, parsován, zkompilován a spuštěn, než se stránka stane plně interaktivní. To je hlavní důvod, proč stránka může vypadat vizuálně kompletní, ale několik sekund nereaguje na kliknutí a posouvání.

Proveďte audit JavaScript balíčků pomocí karty Coverage v Chrome DevTools, která ukazuje procento staženého kódu, který se skutečně spustí při načítání stránky. Je běžné zjistit, že 50–70 % JavaScriptu je na dané stránce nevyužito. Tree-shaking, code splitting a dynamické importy mohou dramaticky snížit počáteční velikosti balíčků. Pokud používáte framework jako Next.js nebo React, ujistěte se, že využíváte vestavěný code splitting, který načítá pouze JavaScript potřebný pro aktuální stránku, místo aby odesílal celou aplikaci předem.

Skripty třetích stran jsou často největším problémem. Analytické nástroje, chatovací widgety, vložený obsah ze sociálních sítí, nástroje pro A/B testování, reklamní pixely, každý z nich přidává vlastní JavaScript, síťové požadavky a režii na zpracování. Viděli jsme klientské weby, které načítají dvanáct nebo více skriptů třetích stran o celkové velikosti přes 1,5 MB. Prověřte každý skript třetí strany z hlediska nezbytnosti a dopadu. Nekritické skripty načítejte asynchronně pomocí atributu defer a zvažte odstranění těch, které nepřinášejí měřitelnou obchodní hodnotu. Audit technického SEO přesně odhalí, které skripty stahují vaše Core Web Vitals pod hranici splnění.

Cachování je nejúčinnější optimalizace výkonu, kterou můžete zavést, protože zcela eliminuje práci. Místo opětovného generování stránky nebo stahování zdroje při každém požadavku cache poskytne uloženou kopii v zlomku času. Efektivní cachování funguje na několika vrstvách: cachování v prohlížeči, serverové cachování, aplikační cachování a cachování na CDN. Každá vrstva snižuje zátěž té následující a společně mohou snížit spotřebu serverových prostředků o 90 % nebo více.

Cachování v prohlížeči se řídí pomocí HTTP hlaviček. Nastavte hlavičky Cache-Control s odpovídajícími hodnotami max-age pro každý typ zdroje: statické soubory jako obrázky, fonty a verzované CSS/JS soubory by se měly cachovat jeden rok (max-age=31536000) s direktivami immutable a public. HTML stránky by se měly cachovat kratší dobu, nebo vůbec, podle toho, jak často se obsah mění. Service workery přidávají další vrstvu tím, že cachují zdroje na úrovni aplikace, což umožňuje okamžité načtení stránky pro vracející se návštěvníky a dokonce i offline funkčnost.

Serverové cachování ukládá plně vykreslený HTML výstup stránky, takže následné požadavky přeskočí celý proces vykreslování. Pro WordPress generují pluginy jako WP Super Cache nebo W3 Total Cache statické HTML soubory, které Apache nebo Nginx poskytuje přímo, aniž by vůbec spouštěl PHP. Pro vlastní aplikace mohou Redis nebo Memcached cachovat databázové dotazy, odpovědi API a vypočítané výsledky. Klíčovou zásadou je cachovat na co nejvyšší úrovni, cachovaná HTML stránka je rychlejší než cachovaný databázový dotaz, který je rychlejší než necachovaný databázový dotaz.

Content Delivery Network distribuuje statické soubory vašeho webu po globální síti okrajových serverů, takže uživatelé stahují zdroje ze serveru geograficky blízkého jim, a ne z vašeho origin serveru, který může být tisíce kilometrů daleko. Nasazení CDN je jedno z nejúčinnějších a nejméně pracných zlepšení výkonu, která máte k dispozici, a služby jako Cloudflare nabízejí štědré bezplatné tarify, které pokryjí většinu malých a středně velkých webů.

Přínosy CDN pro výkon jsou nejvýraznější u uživatelů daleko od vašeho origin serveru. Web hostovaný ve Frankfurtu, který posílá obrázek uživateli v Tokiu, zaznamená pokles latence obousměrného přenosu z přibližně 250 milisekund na méně než 30 milisekund, když je tento obrázek cachován na okrajovém uzlu v Tokiu. Vynásobte toto zlepšení každým obrázkem, stylem, fontem a skriptem na stránce a kumulativní efekt je transformační. Naměřili jsme, že nasazení CDN zkrátilo celkovou dobu načtení stránky o 40–60 % pro mezinárodní návštěvníky.

Moderní CDN jdou nad rámec prostého cachování statických souborů. Cloudflare, Fastly a AWS CloudFront nabízejí možnosti edge computingu, které dokážou cachovat celé HTML stránky, provádět A/B testování na okraji sítě, optimalizovat obrázky za běhu a dokonce spouštět serverless funkce v okrajových lokalitách. Pro weby na WordPress cachuje Cloudflare APO (Automatic Platform Optimization) celé stránky na okraji sítě a dosahuje TTFB pod 50 milisekund globálně, výkon, kterého by nebylo možné dosáhnout s hostováním pouze na origin serveru, bez ohledu na to, jak výkonný váš server je.

Pokud chcete okamžité výsledky bez hlubokého technického ponoru, zde je pět změn, které můžete zavést za méně než hodinu. Nejprve nainstalujte a nakonfigurujte plugin pro cachování, pokud používáte WordPress. WP Super Cache je zdarma a nastavení zabere pět minut. Za druhé prožeňte své obrázky hromadným optimalizátorem, jako je ShortPixel nebo Imagify, který dokáže zmenšit velikost obrázků o 60–80 % bez viditelné ztráty kvality. Za třetí zapněte na serveru kompresi GZIP nebo Brotli, která během přenosu zmenší velikost textových zdrojů o 70–90 %.

Za čtvrté odložte nekritický JavaScript přidáním atributu defer ke značkám script nebo jeho přesunem na konec těla HTML. Zabráníte tím blokování počátečního vykreslení stránky JavaScriptem a můžete zlepšit skóre LCP o několik set milisekund. Za páté zapněte CDN. Bezplatný tarif Cloudflare zabere deset minut nastavení a okamžitě zlepší dobu načtení pro každého návštěvníka, který se nenachází blízko vašeho serveru. Jen těchto pět změn může posunout web ze skóre PageSpeed 40 na 75 nebo více.

Pro zlepšení nad rámec těchto rychlých výher je komplexní audit výkonu nejefektivnější investicí, kterou můžete udělat. Ve společnosti GRADAX analyzujeme každou vrstvu stacku, hostingovou infrastrukturu, konfiguraci serveru, architekturu aplikace, front-endové soubory a závislosti třetích stran, a dodáme prioritizovaný plán optimalizací seřazený podle dopadu a náročnosti implementace. Většina klientů zaznamená zkrácení doby načtení stránky na polovinu během prvního týdne po zavedení našich doporučení. Kontaktujte nás a domluvte si audit výkonu pro svůj web.