§1Co a jak měřit
Než cokoliv změníte, změřte. PageSpeed Insights, Lighthouse v Chrome DevTools, případně WebPageTest. Vždy mobilní verzi — to je to, co Google používá pro hodnocení.
Tři klíčové metriky: LCP (Largest Contentful Paint, obvykle hero obrázek nebo H1), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint).
§2Hero obrázek
Nejtypičtější příčina pomalého LCP. Tři věci najednou:
- Formát: AVIF, fallback WebP, JPEG nikdy. Rozdíl ve velikosti: 60–80 % bez vizuální ztráty.
- Velikost: přesně taková, jak se zobrazuje. Ne 4K do hero o šířce 1200 px.
- Preload: v
<head>použijte<link rel="preload" as="image" href="hero.avif">. Vyřeší to LCP o 200–500 ms.
§3Webfonty
Druhá nejčastější příčina. Co dělat:
- Selfhostujte. Google Fonts CDN je v ČR pomalejší než váš vlastní server.
- Subset. Stáhněte jen latin (případně latin-ext pro češtinu), ne všechny znakové sady.
- font-display: swap. Bez toho čeká stránka na font.
- Preload klíčový font. Stejný princip jako u hero obrázku.
<link rel="preload" href="/fonts/inter-400.woff2" as="font" type="font/woff2" crossorigin>§4Render-blocking CSS a JS
Co stahuje prohlížeč v <head> blokuje vykreslování. Dva přístupy:
- JS: přidejte
deferu všech<script>mimo nezbytných. U externích skriptů (analytics, chat) zvažteasync. - CSS: kritické CSS inline v
<head>, zbytek načíst po vykreslení (media="print"hack nebo plugin).
U WordPressu pomůže plugin jako WP Rocket nebo FlyingPress — udělají to za vás. Ale pochopit, co se děje, je dobré.
§5Lazy-load — ale jen pod ohybem!
Klasická chyba: lazy-load se zapne na všechny obrázky včetně hero. Hero pak čeká, až ho prohlížeč „uvidí", což je hned, ale s přidaným nákladem na vyhodnocení viewportu.
Hero obrázek nesmí mít loading="lazy". Naopak — ideálně fetchpriority="high". Všechno pod prvním ohybem (fold) loading="lazy".
Výkonnostní audit za 90 minut
Spojím vás s vaším webem a vaším Search Console, podívám se na reálná data a pošlu vám priority. Bez dalších závazků.
§6Hosting a cache
Nejúčinnější změna, kterou většina firem podceňuje. Tři úrovně:
- Page cache (na úrovni WordPressu): WP Rocket, W3 Total Cache, vlastní Object cache.
- Server-side cache (na úrovni Apache/Nginx): vyřeší TTFB.
- CDN (Cloudflare, Bunny): krátí latenci pro návštěvníky mimo CZ.
Po nasazení všech tří jsem na typickém WordPressu schopen dosáhnout TTFB pod 100 ms a LCP pod 1 s. Bez přepisu šablony.
Core Web Vitals nejsou raketová věda. Devadesát procent zlepšení dosáhnete těmito pěti kroky. Až pak se vyplatí řešit drobnosti. A vyplatí se to — Google viditelně preferuje rychlé weby.
