Prečo to ľudia riešia

Predstavte si nasledujúcu situáciu, ktorá sa opakuje takmer v každom audite.

Klient má web, ktorý si dal urobiť pred rokom. Vývojár odviedol slušnú prácu, konkrétne čistá šablóna, optimalizované obrázky a PageSpeed Insights ukazoval 92/100. Potom prišiel marketing. Pribudol Google Tag Manager. V ňom Google Analytics 4, Google Ads, Meta Pixel, Hotjar a TikTok Pixel. Právnik povedal, že treba consent management, takže pribudla cookie lišta. Obchod povedal, že treba live chat, takže pribudol Smartsupp. A niekto pridal widget s Google recenziami, lebo to vyzerá dôveryhodne.

Nikto nič nepokazil. Každé jedno rozhodnutie bolo obhájiteľné. A napriek tomu má ten istý web dnes 38/100, LCP 4,8 sekundy a INP 610 ms.

Toto je najzradnejší typ spomalenia, pretože nemá jediného vinníka. Vývojár ukáže, že jeho kód je v poriadku. Marketér ukáže, že jeho merania sú nutné. A web je medzitým pomalý.

Prečo to nie je len kozmetický problém

Skripty tretích strán nepoškodzujú rýchlosť rovnomerne. Trafia presne tie metriky, ktoré Google hodnotí:

INP (Interaction to Next Paint) je zasiahnutý najviac. Táto metrika meria, ako rýchlo web odpovie na kliknutie, a odpoveď je pomalá vtedy, keď je hlavné vlákno prehliadača zamestnané niečím iným. JavaScript je jednovláknový, kým sa vykonáva kód cookie lišty, prehliadač nemôže reagovať na nič. Používateľ klikne na tlačidlo Pridať do košíka, nič sa nestane, klikne znova a potom odíde.

CLS (Cumulative Layout Shift) trpí cookie lištou a widgetmi, ktoré sa doložia až po sekunde a posunú celý obsah. Ten moment, keď chcete kliknúť na odkaz a pod prstom sa vám objaví niečo iné, presne to je CLS.

LCP trpí nepriamo, keďže každý skript v hlavičke, ktorý blokuje parsovanie, oddiali vykreslenie hlavného obrázka.

A pripomeniem, čo to stojí. Podľa štúdie Deloitte pre Google zlepšenie rýchlosti mobilného webu o 0,1 sekundy dvihlo konverzie e-shopov o 8,4 %. Cookie lišta a chat dokopy bežne pridajú 0,5 až 1,5 sekundy.

Čo konkrétne robia jednotlivé typy skriptov

Cookie lišty / CMP

Najhorší profil zo všetkých, pretože cookie lišta musí bežať skoro (inak by sa merania spustili bez súhlasu) a musí niečo vykresliť cez obsah.

Typické problémy:

• načítava sa synchrónne z cudzej domény, pričom každé DNS a TLS spojenie navyše trvá desiatky až stovky milisekúnd
• pri vykreslení posunie obsah stránky nadol, čo vedie k zhoršeniu CLS
• veľké CMP riešenia majú JavaScript bundle v stovkách kilobajtov
• často obsahujú vlastný blokovač skriptov, ktorý prepisuje všetky ostatné <script> tagy a to samo o sebe stojí čas na hlavnom vlákne

Live chaty

Chat widget je v podstate malá aplikácia. Načíta vlastný JavaScript, vlastné CSS, ikony, často aj WebSocket spojenie a niekedy aj vlastné písmo. Všetko preto, aby v pravom dolnom rohu byla bublina, na ktorú klikne 1 z 200 návštevníkov.

Najčastejšia chyba: chat sa načítava okamžite pri načítaní stránky, hoci ho používateľ potrebuje až po tom, čo si niečo prečíta.

Tag Manager a pixely

GTM sám o sebe je malý. Problém je to, čo je v ňom. Každý ďalší tag je ďalší skript, ďalšie spojenie a ďalšia práca na hlavnom vlákne. A GTM kontajnery majú vlastnosť, že do nich roky niekto niečo pridáva a nikdy nič nevyhodí, takže v nich nachádzam pixely kampaní, ktoré skončili pred dvoma rokmi.

Recenzie, mapy, videá a sociálne widgety

Vložené YouTube video pridá na stránku niekoľko stoviek kilobajtov ešte predtým, než niekto stlačí play. Vložená Google mapa podobne. Widget s recenziami načítava dáta z cudzieho API.

Ako to vyriešiť

Krok 1: Zmerajte, koľko to naozaj stojí

Nehádajte. Otvorte Chrome DevTools, záložku Performance, spustite nahrávanie a načítajte stránku. V sekcii Main uvidíte, ktoré úlohy blokujú hlavné vlákno a ako dlho. Dlhé úlohy (nad 50 ms) sú zvýraznené a väčšinou patria presne tomu, čo hľadáte.

Ešte rýchlejší test: v DevTools zablokujte domény tretích strán (Network → pravý klik na request → Block request domain) a načítajte znova. Rozdiel je presne to, čo vás tie skripty stoja. Toto číslo ukážte klientovi alebo marketingu, keďže funguje lepšie ako akýkoľvek iný argument.

Tretí zdroj: Chrome User Experience Report cez Search Console vám povie, či to reálnych používateľov trápi, alebo je to len problém v laboratórnom teste.

Krok 2: Vyhoďte, čo sa dá

Najrýchlejšia optimalizácia je odstránenie. Prejdite zoznam a pri každom skripte sa spýtajte:

• Pozeral sa na tieto dáta niekto za posledné tri mesiace?
• Existuje prekryv? (Napríklad Hotjar aj Clarity naraz, prípadne GA4 aj druhý analytický nástroj?)
• Beží pixel kampane, ktorá už neexistuje?
• Potrebuje chat bežať na všetkých stránkach, alebo stačí na produktových a kontaktných?

V praxi sa takto dá vyhodiť 20–40 % skriptov bez toho, aby to ktokoľvek zaznamenal.

Krok 3: Odložte, čo sa vyhodiť nedá

Toto je technicky najúčinnejšia časť. Princíp spočíva v tom, že skript sa nenačíta pri načítaní stránky, ale až vtedy, keď používateľ prvýkrát pohne myšou, skroluje, ťukne alebo stlačí klávesu.

Dopad je dramatický, pretože metriky LCP aj INP sa merajú hlavne v prvých sekundách. Keď sa chat načíta až po prvom skrolovaní, z pohľadu Core Web Vitals prakticky neexistuje a z pohľadu používateľa funguje úplne rovnako.

Ako to nasadiť:

• WP Rocket má funkciu odloženia vykonávania JavaScriptu so zoznamom skriptov na odloženie
• Perfmatters ponúka to isté, plus možnosť vypnúť skripty na konkrétnych stránkach
• GTM vie spúšťať tagy na trigger typu Scroll Depth alebo Element Visibility namiesto načítania stránky
• Facade pattern pre videá a mapy, kde zobrazíte statický náhľadový obrázok a skutočný prehrávač načítate až po kliknutí (overené riešenie je napríklad lite-youtube-embed)

Čo neodkladať: samotnú cookie lištu z dôvodu legálnej povinnosti a skripty, ktoré sa podieľajú na vykreslení obsahu. Odložiť A/B testovací nástroj znamená, že používateľ na chvíľu uvidí pôvodnú verziu, čo je horšie ako pomalý web.

Krok 4: Rezervujte miesto a zabráňte poskakovaniu

Pre všetko, čo sa doloží neskôr, rezervujte miesto vopred cez min-height alebo aspect-ratio. Cookie lišta by mala byť umiestnená ako prekrytie na pevnej pozícii (fixed), nie ako blok, ktorý posunie obsah. Chat bublina rovnako. Týmto jedným zásahom sa často dostanete s CLS pod 0,1.

Krok 5: Zrýchlite spojenia, ktoré zostali

Pre domény, ktoré naozaj musia zostať, použite preconnect v hlavičke. Ušetríte DNS lookup a TLS handshake, čo je typicky 100–300 ms na doménu. Pozor na to, aby ste preconnect používali maximálne na 3–4 domény, inak si navzájom konkurujú.

Kde to nájdete: nástroje

• Chrome DevTools → Performance na odhalenie dlhých úloh a toho, kto blokuje hlavné vlákno
• Chrome DevTools → Network → Block request domain na zistenie, koľko presne stojí konkrétna doména
• PageSpeed Insights a sekcia týkajúca sa minimalizácie vplyvu kódu tretích strán, ktorá vypíše domény aj s ich nákladom
• WebPageTest.org pre prehľadný waterfall, kde vidíte presné poradie a načasovanie každej požiadavky
• Request Map Generator na vytvorenie vizuálnej mapy, ktorá ukáže, ako jeden skript ťahá ďalších päť (výborné na prezentáciu klientovi)
• Google Tag Manager → Preview pre kontrolu toho, čo všetko sa reálne spúšťa a kedy

Toto robím

Volám sa Milan Fraňo a vo WooAcademy robím SEO a technickú optimalizáciu webov. Toto je typ práce, ktorý mám najradšej, pretože má najlepší pomer výsledku k nákladom. Často ide o pol dňa práce, pri ktorej sa nemení ani riadok obsahu a web sa zrýchli o sekundu a pol.

Zároveň je to práca, ktorá vyžaduje porozumenie obom stranám, technickej aj marketingovej. Vyhodiť pixel, ktorý marketing potrebuje, je rovnako zlé riešenie ako nechať web pomalý.

Čo konkrétne robím:

• Audit skriptov tretích strán: zmeriam, koľko presne vás stojí každá doména a odovzdám zoznam odporúčaní na vyhodenie, odloženie alebo ponechanie s odhadom dopadu na LCP, INP a CLS
• Čistenie GTM kontajnera bez toho, aby sa rozbilo meranie, ktoré naozaj používate
• Nasadenie odloženého načítavania vrátane cookie lišty, chatu, videí a máp
• Opravu CLS spôsobeného lištami a widgetmi
• Prepojenie s marketingom, aby sa nestalo, že o pol roka pribudne päť nových tagov a problém je naspäť

Ak máte pocit, že váš web je pomalý a nikto nevie prečo, napíšte mi adresu webu. Zmeriam, koľko vás stoja skripty tretích strán a pošlem vám konkrétne číslo v sekundách. Prvotnú diagnostiku vám pripravím zadarmo.

👉 Nezáväzná konzultácia zrýchlenia webu

Často kladené otázky

Naozaj cookie lišta spomalí web?

Áno, a často výrazne. Väčšina CMP riešení sa načítava z cudzej domény, má JavaScript v stovkách kilobajtov a musí sa spustiť skoro. Navyše mnohé z nich obsahujú blokovač skriptov, ktorý prepisuje ostatné <script> tagy, čo samo o sebe zaťažuje hlavné vlákno. Typický dopad býva 0,3 až 1 sekunda.

Môžem cookie lištu odložiť, aby nespomaľovala?

Nie úplne. Cookie lišta musí bežať pred meracími skriptmi, inak by sa merania spustili bez súhlasu. Dá sa však vybrať ľahšie riešenie, hostovať ho lokálne a hlavne zabrániť tomu, aby posúvala obsah stránky a kazila CLS.

Ako odložiť live chat, aby fungoval, ale nespomaľoval?

Načítajte ho až po prvej interakcii používateľa, napríklad po skrolovaní, pohnutí myšou alebo ťuknutí. Vo WordPresse to vyrieši WP Rocket (funkcia pre odloženie vykonávania JavaScriptu) alebo Perfmatters. Používateľ rozdiel nespozná, pretože kým doskroluje, chat je už načítaný.

Ako zistím, ktorý skript mi kazí INP?

V Chrome DevTools otvorením záložky Performance nahrajte interakciu s webom a pozrite sekciu Main. Dlhé úlohy nad 50 ms sú vyznačené a po rozkliknutí uvidíte konkrétny súbor a funkciu. Doplnkovo použite rozšírenie Web Vitals, ktoré vám ukáže INP v reálnom čase.

Pomôže, keď skripty presuniem do Google Tag Managera?

Samo o sebe nie. GTM je len kontajner a skripty sa aj tak načítajú. Pomôže až to, že v GTM viete nastaviť, aby sa spúšťali na neskorší spúšťač (skrolovanie, viditeľnosť prvku) namiesto načítania stránky.

Ako veľmi vadí vložené YouTube video?

Bežne pridá niekoľko stoviek kilobajtov a viacero spojení ešte predtým, než niekto stlačí play. Riešením je náhľadový obrázok (facade), pričom skutočný prehrávač načítate až po kliknutí. Overené riešenie je lite-youtube-embed.