Web se často začne zrychlovat opačně: někdo nainstaluje optimalizační plugin, zapne všechny přepínače a potom hledá, proč nefunguje formulář. Správné pořadí je měření, hypotéza, jedna změna, kontrola funkce a nové měření.
Ve starší verzi tohoto článku jsem popisoval i postupy, které dnes nedoporučuji, například lokální proxy cizích skriptů nebo obecné nasazení AMP a PWA. Přinesly dílčí laboratorní zlepšení, ale přidávaly riziko zastaralého kódu, rozbitých aktualizací a složitější správy. Moderní web má být rychlý ve své hlavní verzi.
Co dnes měřit
Google pro Core Web Vitals používá tři stabilní metriky:
- LCP: načtení hlavního obsahu, dobrá hodnota je do 2,5 sekundy.
- INP: odezva na interakce, dobrá hodnota je pod 200 milisekund.
- CLS: nečekané posuny rozvržení, dobrá hodnota je nejvýše 0,1.
Hranice platí pro 75. percentil načtení a jsou shrnuté v oficiálním přehledu Core Web Vitals pro Google Search. Výsledky skutečných návštěvníků v Search Console nebo CrUX mají přednost před jedním laboratorním testem na mém notebooku.
Laboratorní nástroje jsou přesto důležité: ukážou waterfall, hlavní vlákno, nevyužitý kód a konkrétní kandidáty na opravu. Field data říkají, že problém existuje; laboratoř pomáhá zjistit proč.
Nejdřív určete rozsah problému
- Porovnejte mobil a desktop.
- Rozdělte šablony: titulní stránka, článek, služba, výpis, formulář a e-shop.
- Zkontrolujte rychlé a pomalé země, zařízení a zdroje návštěv.
- Najděte URL skupiny se špatnými field daty.
- U reprezentativní stránky pořiďte opakovatelný laboratorní záznam.
Jedna rychlá titulní stránka neznamená rychlý web. A jedna pomalá návštěva na starém telefonu neznamená, že musíte přepsat celý systém.
Pořadí zásahů s nejčastějším dopadem
1. Server a HTML
Změřte dobu do prvního bajtu a rozdělte ji na DNS, spojení, čekání na server a přesměrování. Dlouhé čekání může způsobit hosting, databáze, necachovaná stránka, pomalé API nebo řetězec redirectů. Zapněte vhodnou page cache pro veřejný obsah a object cache tam, kde dává smysl. Přihlášené uživatele, košík a personalizaci z cache správně vyjměte.
2. Hlavní obrázek
LCP často tvoří hero obrázek. Dodávejte rozměr odpovídající zobrazení, používejte srcset, kompresi a moderní formát WebP nebo AVIF s rozumnou zálohou. Hlavní obrázek nenačítejte líně; naopak obrázky pod prvním viewportem lazy-loadujte. U obrázků nastavte šířku a výšku, aby prohlížeč rezervoval místo a nesnižoval CLS.
3. CSS a fonty
Odstraňte nepoužívané styly s rozvahou a kritické CSS držte malé. Fonty omezte na potřebné řezy a znakové sady, lokální soubory dlouhodobě cachujte a preload používejte jen pro skutečně časný font. Přednačíst deset fontů znamená jen vytvořit novou frontu.
4. JavaScript a interakce
Rozdělte velké balíky, odložte nekritický kód a třetí strany načítejte až ve chvíli, kdy jsou potřeba a dovoluje to souhlas. Atributy async a defer nejsou kouzla; pořadí skriptů a závislosti musíte otestovat. Dlouhé úlohy na hlavním vlákně rozdělujte a reakci na kliknutí nenechte čekat na analytiku.
5. Třetí strany
Chaty, heatmapy, reklamní pixely, videa a A/B nástroje mohou přidat síťové požadavky i práci procesoru. Každý skript musí mít vlastníka a obchodní důvod. Nenačítejte ho synchronně do hlavičky jen proto, že instalační návod je nejkratší. Analytiku lze spravovat přes Google Tag Manager, ale kontejner sám výkon nezachrání.
WordPress: méně překryvů, více kontroly
WordPress dokumentace doporučuje řešit výkon přes hosting, počet a kvalitu pluginů, obrázky, cache a distribuční síť. Projděte její přehled optimalizace i samostatné vysvětlení cache.
- Aktualizujte WordPress, PHP, šablonu a pluginy nejprve na stagingu.
- Odstraňte nepoužívané pluginy a překryvy více cache či minifikačních nástrojů.
- Profilujte databázové dotazy a pomalé externí volání.
- Naplánujte údržbu databáze, ale nemažte revize nebo metadata naslepo.
- Po každé optimalizaci projděte formuláře, vyhledávání, přihlášení a nákupní tok.
Rozumný výběr doplňků rozebírám v článku nejlepší pluginy pro WordPress.
Co nedělat
- Nestahujte cizí analytické či reklamní skripty na svůj server jen kvůli skóre. Můžete přijít o bezpečnostní a funkční aktualizace.
- Nenastavujte roční cache pro měnící se soubor bez verzování názvu.
- Neodstraňujte CSS nebo JavaScript podle automatického reportu bez testu všech šablon.
- Nehodnoťte úspěch pouze podle Lighthouse skóre. Google výslovně uvádí, že dobré Core Web Vitals samy o sobě nezaručí vysoké pozice ani skvělý uživatelský zážitek.
- Nezrychlujte web tím, že skryjete obsah nebo funkci, kterou zákazník potřebuje.
Čtyřtýdenní plán
- Týden 1: baseline field dat, laboratorní měření a seznam šablon.
- Týden 2: server, cache, přesměrování a největší LCP zdroje.
- Týden 3: obrázky, fonty, CSS, JavaScript a třetí strany.
- Týden 4: regresní test, nové měření, monitoring a dokumentace.
U každé změny zaznamenejte datum, URL, metriku před a po, dopad na funkci a možnost návratu. Sledujte také konverzní poměr, dokončení formulářů a chyby; rychlejší stránka, která méně prodává, není hotová optimalizace.
Začněte kontrolou technických základů webu a analytiky v technickém auditu a GA4. Pokud potřebujete určit pořadí oprav podle dopadu a ceny, napište mi přes kontakt.