Optimalizace CLS má proti zbytku technického SEO jednu výhodu: viníka jde chytit při činu. CLS (Cumulative Layout Shift) je číslo, kterým Google známkuje nečekané poskakování obsahu — a každý takový poskok se dá v prohlížeči zvýraznit, změřit a dohledat až k prvku, který ho způsobil. Co skákání dělá s návštěvníky a proč ho Google vůbec hodnotí, jsem vysvětlila v článku CLS: proč se vám web skáče pod rukama. Tady navazuje samotná oprava: čím posuny najít, kterých pět příčin za nimi stojí skoro vždycky a co přesně kvůli nim zadat vývojáři. Cílová hodnota je podle Googlu CLS do 0,1.
Nejdřív posuny najděte
Opravovat naslepo je drahé. Než vývojář sáhne do šablony, chcete vědět dvě věci: jestli je CLS opravdu problém (na to jsou čísla) a co konkrétně se hýbe (na to je prohlížeč).
PageSpeed Insights (pagespeed.web.dev) odpoví na první otázku. Nahoře jsou polní data: skutečné návštěvy vašeho webu v Chromu za posledních 28 dní, tedy číslo, které vidí i Google. Pod nimi laboratorní test — jedno simulované načtení, které se hodí na rychlé ověření opravy, ale CLS soustavně podceňuje. Robot totiž stránku jen načte; nescrolluje, nekliká a nepočká si na banner, který doskočí po deseti vteřinách. CLS se přitom měří za celou návštěvu: posuny jdoucí rychle za sebou se sčítají do dávek a výsledné skóre je nejhorší dávka, jakou stránka návštěvníkovi předvedla. Proto existují weby s nulou v laboratoři a červenými polními daty. Máte-li Search Console, sekce Core Web Vitals vám navíc problém rozdělí po skupinách stránek: hned víte, jestli skáče celý web, nebo jen produktové detaily.
Chrome DevTools odpoví na druhou otázku. Dvě funkce stojí za to znát, i když kód psát nebudete:
- Layout Shift Regions (v nabídce Rendering). Po zapnutí prohlížeč každý posun barevně zvýrazní přímo při prohlížení. Otevřete web, proklikejte pár stránek a dívejte se, co problikává. Rychlejší diagnóza neexistuje.
- Záznam v panelu Performance. Spustíte nahrávání, obnovíte stránku, chvíli scrollujete a záznam zastavíte. Posuny rozvržení mají na časové ose vlastní stopu; po kliknutí na konkrétní posun uvidíte, které prvky se pohnuly a v jakém okamžiku. Tohle už je práce pro vývojáře — ale právě tenhle záznam je zadání, se kterým nemusí nic hledat.
Pět viníků, za kterými se skákání skrývá skoro vždycky
Příčin může být bezpočet, u klientských webů se ale vrací pořád stejná pětice.
Obrázky bez rozměrů
Prohlížeč skládá stránku dřív, než se stáhnou obrázky. Dokud u obrázku nevidí rozměry, nerezervuje mu žádné místo — a když obrázek dorazí, odstrčí všechno pod sebou. Oprava je nejjednodušší z celého seznamu: každý obrázek a video má mít v HTML uvedenou šířku a výšku.
<img src="produkt.webp" alt="Popis produktu" width="800" height="600">
Nebojte se, že tím obrázek „zamknete“ na 800 pixelů. CSS ho dál zmenšuje podle displeje; prohlížeč si z atributů vezme jen poměr stran a podle něj drží místo. Totéž umí v CSS vlastnost aspect-ratio. Moderní redakční systémy rozměry doplňují samy, jenže šablony a pluginy je umí zase ztratit — kontrola se vyplatí i na WordPressu.
Reklamy, embedy a mapy
Bannery, vložená videa, mapy a příspěvky ze sociálních sítí přijíždějí ze serverů třetích stran, tedy skoro vždycky později než zbytek stránky. Bez rezervovaného místa roztlačí obsah kolem sebe, a protože reklamní pozice bývají velké, jde typicky o největší posuny na stránce.
Oprava: kontejner, do kterého se reklama nebo embed načítá, dostane předem minimální výšku (min-height), vložené video poměr stran 16 : 9. Má to daň, se kterou je fér počítat — když se reklama nenačte, zůstane na stránce prázdné místo. Prázdné místo ale návštěvníka nerozčílí. Skok ano.
Webová písma
Než se stáhne vlastní font, prohlížeč vykreslí text písmem náhradním. To má jinou šířku i výšku, takže se text po výměně přeskládá. Úplně to odstranit nejde, srazit skoro na nulu ano — a je to úprava na pár řádků CSS: vlastností font-display se řídí, kdy a jestli se font vymění, a náhradní písmo se dá velikostně doladit tak, aby výměna nebyla skoro vidět. Vývojáři stačí zadání jednou větou: „ať text při načtení fontu neposkakuje.“
Cookie lišta a další vkládané lišty
Klasika posledních let: stránka se vykreslí, o vteřinu později se nahoře vysune cookie lišta a celý obsah sjede o kus níž. Jeden takový posun umí zkazit CLS víc než všechny obrázky dohromady, protože se pohne prakticky celá plocha obrazovky.
Řešení je laciné: lišta, která obsah překryje (typicky připnutá dole), žádný posun nezpůsobí. Druhá možnost je rezervovat pro ni místo předem. U hotových cookie nástrojů na to většinou nepotřebujete ani vývojáře — v nastavení bývá volba pozice a lišta dole překryvem je z pohledu CLS nejbezpečnější. Totéž platí pro lišty se slevou nebo výzvou k odběru: cokoliv, co se vysune nad rozečtený obsah, se počítá.
Pozdě načítané styly
Nenápadný, ale zákeřný viník: část CSS dorazí se zpožděním, třeba proto, že ji na stránku vkládá skript, a stránka se po jejím uplatnění přeskládá. Vídám to u nástrojů na A/B testování, chatovacích widgetů a šablon, které si styly přinášejí po kouskách. Zadání pro vývojáře: styly, které ovlivňují rozložení stránky, patří do hlavičky od začátku, ne do skriptů spouštěných kdovíkdy.
Většina webů, které mi projdou rukama, ztrácí návštěvnost kvůli třem až pěti chybám. Které brzdí ten váš? Pošlete mi adresu a do 48 hodin to víte. Ručně, zdarma a bez závazku.
Kdy CLS řešit — a kdy nechat být
Prahy z dokumentace Googlu: do 0,1 dobré, 0,1 až 0,25 „potřebuje zlepšení“, nad 0,25 špatné. Vždy měřeno na 75. percentilu návštěv — web musí držet u tří čtvrtin lidí, ne u vás v kanceláři na rychlé síti.
Zároveň: CLS 0,15 vás v pozicích nepotopí. Core Web Vitals jsou v hodnocení Googlu slabý signál mezi mnoha silnějšími a samotnou opravou skákání konkurenci nepředběhnete. Opravujte kvůli lidem: kvůli kliknutím, která dopadla vedle, ztracenému místu v textu a košíkům opuštěným ze vzteku. A pořadí si nechte určit polními daty — když svítí CLS, řešte CLS; když je CLS zelené a kulhá načtení nebo odezva, má přednost LCP, případně INP.
Časté otázky
Laboratorní test ukazuje skoro nulu, polní data jsou špatná. Čemu věřit?
Polním datům — ta se počítají. Laboratorní robot stránku jen načte: nescrolluje, nečeká na reklamy ani na lištu, která vyskočí po pár vteřinách, takže většinu posunů z reálného prohlížení vůbec nezažije. V laboratoři se pravdě přiblížíte záznamem v panelu Performance, při kterém stránkou scrollujete jako návštěvník.
Obrázky načítám odloženě (lazy loading). Řeší to CLS?
Neřeší, spíš naopak: odložený obrázek dorazí ještě později, takže bez uvedených rozměrů udělá posun hluboko na stránce, kde už člověk čte. Rozměry potřebují odloženě načítané obrázky ze všech nejvíc. Kombinace rozměrů a lazy loadingu je v pořádku a rychlosti pomáhá.
Musím kvůli CLS omezit reklamy?
Nemusíte. Banner v předem rezervovaném prostoru s pevnou velikostí skóre nekazí — CLS měří posuny, ne přítomnost reklamy. Pozor jen na formáty, které se samy roztahují nebo vsouvají doprostřed textu — u těch se vyplatí spočítat, jestli výnos stojí za návštěvníky, které skákání odežene.
Většina oprav je otázka šablony, ne přestavby webu
Dobrá zpráva na konec: nic z téhle kuchařky není přestavba. Rozměry obrázků, rezervované sloty, lišta překryvem — to jsou zásahy do šablony, které šikovný vývojář zvládne v řádu hodin. Nejtěžší na celém CLS je něco jiného: vědět, jestli ho váš web vůbec má, na kterých stránkách a jestli je na řadě dřív než jiné opravy. A to je otázka pro SEO audit: Core Web Vitals v něm stojí vedle obsahu, indexace a odkazů, takže hodiny vývojáře investujete tam, kde webu pomůžou nejvíc, a ne do metriky, která je zrovna v módě.
Zdroje k faktům v článku:
- CLS: prahy 0,1 a 0,25, 75. percentil, dávky posunů (okno max. 5 s, rozestupy do 1 s) (ověřeno 19. 7. 2026): web.dev/articles/cls
- Nejčastější příčiny CLS a opravy: rozměry obrázků a embedů, rezervace místa pro dynamický obsah, chování webfontů (ověřeno 19. 7. 2026): web.dev/articles/optimize-cls
- Polní data z CrUX za 28 dní vs. laboratorní test Lighthouse v PageSpeed Insights (ověřeno 19. 7. 2026): developers.google.com/speed/docs/insights/v5/about
- Layout Shift Regions v nabídce Rendering a stopa posunů v panelu Performance v Chrome DevTools (ověřeno 19. 7. 2026): developer.chrome.com/docs/devtools/rendering/performance
