Pomalé LCP

Stránka se třikrát načte ve skutečném prohlížeči (pokaždé v novém, prázdném kontextu, tedy se studenou keší) a změří se LCP (Largest Contentful Paint): čas, za který se vykreslí největší viditelný prvek, typicky hlavní obrázek nebo nadpis. Z těch tří hodnot se bere medián. Nález vznikne, když je medián vyšší než 2 500 ms. Práh je v config/seo.json pod web_vitals.lcp_ms_threshold a report u nálezu uvede naměřenou hodnotu.

Práh není náš odhad: 2,5 s je oficiální hranice mezi „dobré“ a „vyžaduje zlepšení“ v metodice Core Web Vitals.

Zásadní omezení, které musíte znát, než podle toho čísla něco uděláte:

• Je to laboratorní měření, ne data od vašich návštěvníků. Tři načtení z jednoho místa, z našeho serveru, po naší lince, v jednom okamžiku. Google k hodnocení používá data od skutečných uživatelů za 28 dní. Naše číslo a to jeho se můžou lišit výrazně.
• Měří se jen vzorek: nejvýš 10 stránek (web_vitals.max_sample_pages), ne celý web.
• Medián ze tří měření, ne 75. percentil. Google počítá 75. percentil z tisíců načtení od skutečných uživatelů; my máme tři pokusy z jednoho stroje. Tři vzorky spolehlivě odstraní jeden odlehlý výkyv (proto ta změna 2026-09-19: jedno měření nám na torumata.com/en ukázalo 2 604 ms tam, kde medián z pěti měření byl 112 ms), ale rozptyl vašich návštěvníků nenahradí. Počet vzorků je v config/seo.json pod web_vitals.samples_per_page.
• Neměříme INP (odezvu na interakci), třetí metriku Core Web Vitals; vyžadovala by skutečnou interakci uživatele.

A co kontrola neposuzuje vůbec: příčinu. Změří, že se největší prvek vykreslil pozdě, ale neřekne, jestli za to může váš server, velký obrázek, nebo cizí skript. To musíte najít vy.

Berte proto naši hodnotu jako indicii, kde se podívat, ne jako verdikt. Nález je na úrovni stránky, závažnost varování.

Tady je potřeba rozdělit dvě věci, protože jedna z nich je doložená pevně a druhá vůbec.

Pro klasické vyhledávání jsou Core Web Vitals potvrzený řadicí signál; Google to píše ve vlastní dokumentaci: Core Web Vitals používají jeho řadicí systémy. Je to ale jen jedna součást širšího hodnocení „page experience“ a funguje spíš jako rozhodčí při shodě než jako hlavní kritérium; relevance a kvalita obsahu váží víc.

Na viditelnost v odpovědích AI asistentů doložený vliv nemáme a netvrdíme ho. Žádný z primárních zdrojů se tím nezabývá, stejná disciplína jako u strukturovaných dat a llms.txt. Proto třída „efekt nedoložený“, přestože pro klasické vyhledávání je to jeden z mála signálů, který má Google potvrzený černé na bílém.

A jedna otevřená nejistota, kterou radši přiznáme, než bychom ji zamlčeli: v roce 2026 kolovaly zprávy o možném zpřísnění prahu LCP na 2,0 s. Jeden zdroj to tvrdil, druhý popíral, a žádný z nich nebyl Google. Primární zdroj (web.dev) uvádí 2,5 s bez zmínky o změně, takže se držíme jeho. Kdyby vám někdo tvrdil 2,0 s, ptejte se, odkud to má.

Nejdřív se podívejte na skutečná data, ne na naše. Pokud máte web v Search Console, report Core Web Vitals tam ukazuje měření od vašich návštěvníků za 28 dní, a to je číslo, podle kterého vás Google hodnotí.

LCP se skoro vždycky láme na jednom ze čtyř míst, v tomhle pořadí četnosti:

1. Hlavní obrázek se stahuje pozdě. Má loading="lazy" (u obrázku nad ohybem je to kontraproduktivní; viz SEO-38 naruby), nebo se načítá až po skriptu. Řešení: fetchpriority="high" a žádné líné načítání pro první obrázek.
2. Obrázek je zbytečně velký. Fotografie 4000 px široká zobrazená na 800 px. Řešení: moderní formát (SEO-37) a responzivní varianty přes srcset.
3. Blokující zdroje v hlavičce. Písma a styly, které musí dorazit, než se vůbec začne kreslit. Řešení: preload u kritických, odložení zbytku.
4. Pomalá odpověď serveru. Když samotné HTML dorazí za vteřinu, LCP pod 2,5 s už nedáte. Řešení: keš, CDN, rychlejší generování stránky.

A věc, která se u výkonu často přehlíží: měřte po každé změně, ne až na konci. Optimalizace, která na papíře dává smysl, umí LCP zhoršit: typicky preload deseti souborů naráz, který si navzájem ukradnou linku.