LCP 10 sekúnd: čo sa na webe deje a koľko zákazníkov môžete strácať

Otvoríte web alebo e-shop.

Niečo sa už zobrazuje.

Vidíte hlavičku, možno logo, možno menu.

Ale hlavný obsah stále nikde.

Veľký banner, produktová fotografia, hlavný nadpis alebo kľúčová časť stránky sa zobrazí až po niekoľkých sekundách.

Ak sa najväčší dôležitý prvok stránky zobrazí až po desiatich sekundách, môžeme hovoriť o extrémne zlom výsledku jednej z najdôležitejších metrík výkonu webu:

Largest Contentful Paint – LCP.

A hoci používateľ pravdepodobne netuší, čo skratka LCP znamená, veľmi dobre cíti jej dôsledok:

„Tento web je pomalý.“

A často urobí jedinú vec.

Odíde.

Čo je LCP?

Largest Contentful Paint patrí medzi Core Web Vitals – základné metriky, ktorými sa hodnotí používateľská skúsenosť webu.

LCP meria čas od začiatku načítania stránky po okamih, keď sa zobrazí najväčší relevantný obsahový prvok viditeľný v aktuálnom okne prehliadača.

Môže to byť napríklad:

• hlavný banner,
• veľká fotografia produktu,
• obrázok v hero sekcii,
• veľký textový blok,
• poster videa,
• iný dominantný obsahový prvok.

Google definuje dobrý LCP ako hodnotu 2,5 sekundy alebo menej.

Hodnota medzi 2,5 a 4 sekundami znamená, že stránka potrebuje zlepšenie.

Nad 4 sekundy je LCP hodnotený ako slabý.

Pri vyhodnocovaní reálnej používateľskej skúsenosti sa sleduje 75. percentil načítaní oddelene pre mobilné a desktopové zariadenia.

Ak teda vidíte LCP 10 sekúnd, nie ste trochu nad odporúčanou hodnotou.

Ste približne štvornásobne nad hranicou dobrého výsledku.

Čo znamená LCP 10 sekúnd v praxi?

Predstavte si zákazníka, ktorý klikol na Google reklamu.

Za klik ste zaplatili.

Otvorí sa stránka.

Po jednej sekunde ešte čaká.

Po dvoch sekundách stále čaká.

Po troch sekundách už môže začínať premýšľať, či je problém v jeho telefóne.

Po piatich sekundách časť používateľov odchádza.

A pri desiatich sekundách môže byť značná časť návštevníkov už dávno preč.

To znamená, že:

• zaplatili ste za návštevníka,
• reklama fungovala,
• Google návštevníka priviedol,
• ale web ho nestihol presvedčiť ani len tým, že zobrazí svoj hlavný obsah.

Pomalý web môže znehodnotiť marketing ešte pred tým, než sa marketing vôbec dostane k slovu.

Ako zlý je LCP 10 sekúnd?

LCP	Hodnotenie	Praktický význam
do 2,5 s	dobré	hlavný obsah sa zobrazí dostatočne rýchlo
2,5–4 s	potrebuje zlepšenie	už existuje citeľná rezerva
nad 4 s	slabé	používateľ už môže vnímať stránku ako pomalú
5–6 s	výrazný problém	čakanie je na mobile často veľmi citeľné
10 s	kritické	hlavný obsah prichádza extrémne neskoro

Samozrejme, jedno laboratórne meranie neznamená, že každý používateľ vždy čaká presne rovnaký čas.

Výsledok ovplyvňuje:

• rýchlosť zariadenia,
• internetové pripojenie,
• lokalita,
• cache,
• aktuálne zaťaženie servera,
• prehliadač,
• stav siete.

Preto treba vždy rozlišovať laboratórne a reálne dáta.

Laboratórne dáta vs. reálni používatelia

Toto je veľmi dôležité.

Lighthouse test vytvára kontrolované podmienky.

Simuluje konkrétne zariadenie a sieť a umožňuje opakovateľne porovnávať výsledky.

To je výborné pri hľadaní technických problémov.

Neznamená to však automaticky:

„Každý návštevník čaká presne 5,71 sekundy.“

Naopak, reálne používateľské dáta – napríklad Chrome UX Report – hovoria o tom, čo skutočne zažívali návštevníci webu.

Oba pohľady sú dôležité.

Laboratórne meranie vám pomáha nájsť problém. Reálne dáta vám pomáhajú zistiť jeho skutočný rozsah.

Reálny príklad: audit consultee.biz

Pri aktuálnom teste webu consultee.biz cez EshopMonitor.sk sme na mobile namerali:

• Performance score: 68/100,
• LCP: 5,71 sekundy.

EshopMonitor tento výsledok označil ako technickú rezervu a upozornil, že dobrá hodnota LCP je najviac približne 2,5 sekundy.

Zároveň výslovne uvádza, že ide o laboratórny Lighthouse test na simulovanom mobilnom zariadení, nie o priame meranie všetkých reálnych používateľov.

To je podľa nás správny spôsob interpretácie.

Výsledok 5,71 sekundy totiž neznamená:

„Web je definitívne zlý.“

Znamená:

„Je tu konkrétna výkonnostná rezerva, ktorú má zmysel technicky preveriť.“

A presne na to audit slúži.

Čo sa počas tých 10 sekúnd vlastne deje?

LCP nie je jeden jednoduchý čas.

Dá sa rozdeliť na štyri základné časti:

1. Time to First Byte – TTFB,
2. oneskorenie začiatku načítania LCP zdroja,
3. samotné načítanie LCP zdroja,
4. oneskorenie jeho vykreslenia.

Tieto štyri časti spolu tvoria výsledný LCP.

1. Time to First Byte – server ešte ani nezačal poriadne odpovedať

TTFB meria čas od požiadavky po prvý bajt HTML odpovede.

Ak server odpovedá dve alebo tri sekundy, máme problém ešte pred načítaním obrázkov, CSS alebo JavaScriptu.

Príčinou môže byť napríklad:

• pomalý hosting,
• preťažený server,
• pomalá databáza,
• zložité serverové operácie,
• chýbajúca cache,
• veľká vzdialenosť servera od návštevníka,
• presmerovania.

Ak má TTFB napríklad 3 sekundy, web prakticky nemá šancu dosiahnuť dobrý LCP 2,5 sekundy.

Nie je možné zobraziť hlavný obsah za 2,5 sekundy, ak samotný HTML dokument začne prichádzať po troch sekundách.

2. Prehliadač nevie, že má LCP zdroj začať načítavať

Toto je jeden z najčastejšie prehliadaných problémov.

Predstavme si, že LCP prvkom je veľký hero obrázok.

Problém nemusí byť v tom, že obrázok má 500 kB.

Problém môže byť, že prehliadač sa o jeho existencii dozvie príliš neskoro.

Napríklad:

• obrázok je definovaný cez CSS background,
• CSS sa musí najskôr načítať,
• potom spracovať,
• až následne prehliadač zistí, že má obrázok stiahnuť.

Podobný problém môže vzniknúť, ak:

• obrázok vkladá JavaScript,
• hero slider sa inicializuje neskoro,
• LCP obrázok má omylom lazy loading,
• zdroj je ukrytý za ďalšou závislosťou.

Google upozorňuje, že pri slabom LCP býva problémom často práve resource load delay – čas, keď browser mohol načítavať dôležitý zdroj, ale ešte o ňom nevedel.

3. LCP obrázok je príliš veľký

Toto je klasický problém.

Na obrazovke vidíte banner s rozmerom približne 1 200 × 500 pixelov.

Server však posiela:

• obrázok 5 000 × 3 000 px,
• PNG,
• s veľkosťou 4 MB.

Na rýchlej optike si to možno nevšimnete.

Na mobilnom pripojení už áno.

Skontrolujte:

• reálne rozmery obrázka,
• kompresiu,
• WebP alebo AVIF,
• responsive images,
• srcset,
• správnu veľkosť pre konkrétne zariadenie.

4. LCP obrázok má lazy loading

Lazy loading je skvelá optimalizácia.

Ale nie na všetko.

Obrázky hlboko pod prvou obrazovkou nemusíte sťahovať okamžite.

Hlavný hero obrázok však chcete načítať čo najskôr.

Ak použijete:

loading="lazy"

na prvok, ktorý sa stane LCP, môžete jeho načítanie zbytočne oddialiť.

Pre LCP obrázok je spravidla vhodné načítanie prioritizovať, nie odkladať.

5. Render-blocking CSS

Browser dostane HTML.

Ale pred tým, než stránku zobrazí, musí spracovať veľký CSS súbor.

Ten môže obsahovať:

• tisíce pravidiel,
• štýly pre stránky, ktoré práve nepoužívate,
• kód pluginov,
• CSS knižnice,
• staré komponenty.

Výsledok?

Hlavný obsah je stiahnutý, ale browser stále čaká, kým ho môže správne vykresliť.

6. Príliš veľa JavaScriptu

Moderné weby často načítavajú obrovské množstvo JavaScriptu.

Napríklad:

• slider,
• chat,
• analytiku,
• remarketing,
• heatmapu,
• cookie systém,
• A/B testing,
• recenzie,
• personalizáciu,
• affiliate skripty.

Každý zvlášť môže vyzerať nevinne.

Spolu však môžu vytvoriť veľmi drahý JavaScriptový balík.

Problém je ešte výraznejší na slabších mobiloch.

Stiahnutie JavaScriptu je totiž iba prvá časť.

Mobil ho musí:

• parsovať,
• kompilovať,
• vykonať.

7. Slider môže byť drahší, než si myslíte

Hero slider je typický kandidát na LCP problém.

Namiesto jedného hlavného obrázka môže web načítať:

• tri bannery,
• JavaScript slidera,
• CSS slidera,
• fonty,
• animácie.

A pritom používateľ často uvidí iba prvý slide.

Niekedy je jednoduchý statický hero blok nielen rýchlejší, ale aj marketingovo účinnejší.

8. Webfonty môžu zdržiavať hlavný nadpis

LCP nemusí byť obrázok.

Môže to byť veľký nadpis.

Ak čaká na načítanie externého fontu, jeho vykreslenie sa môže oneskoriť.

Skontrolujte:

• počet fontov,
• počet rezov,
• preload kritického fontu,
• font-display,
• self-hosting fontov.

9. Cookie banner, chat a tretie strany

Každý marketingový nástroj niečo stojí.

Nie iba peniaze.

Aj výkon.

Typický web môže mať:

• Google Tag Manager,
• GA4,
• Google Ads,
• Meta Pixel,
• Hotjar,
• chat,
• affiliate tracking,
• cookie platformu.

Pri ročnom audite sa oplatí položiť jednoduchú otázku:

Používame ešte všetky skripty, ktoré sa na webe načítavajú?

Často objavíme tracking agentúry, s ktorou firma už dva roky nespolupracuje.

10. Cache nefunguje alebo neexistuje

Ak server pri každej návšteve znovu generuje rovnaký obsah, vykonáva rovnaké databázové dotazy a skladá rovnakú stránku, môže zbytočne spomaľovať TTFB.

Podľa platformy môže pomôcť:

• serverová cache,
• page cache,
• object cache,
• browser cache,
• CDN.

11. CDN môže pomôcť – ale nevyrieši všetko

Content Delivery Network dokáže distribuovať statické súbory bližšie k používateľovi.

To môže pomôcť najmä pri geograficky rozptýlených návštevníkoch.

Ale CDN nevyrieši:

• zlé databázové dotazy,
• 3 MB hero banner,
• zle prioritizovaný LCP obrázok,
• tony nepoužitého JavaScriptu.

12. Presmerovania môžu zobrať stovky milisekúnd ešte pred začiatkom

Predstavte si:

http://example.sk
→ https://example.sk
→ https://www.example.sk
→ https://www.example.sk/sk/

Každé presmerovanie znamená ďalší sieťový krok.

Na rýchlom pripojení zanedbateľný.

Na mobilnej sieti podstatne drahší.

10-sekundové LCP nemusí znamenať jeden veľký problém

Toto je veľmi dôležité.

Často nehľadáme jednu katastrofálnu chybu.

LCP môže vyzerať napríklad takto:

Časť	Čas
TTFB	2,0 s
čakanie na objavenie LCP obrázka	2,5 s
stiahnutie obrázka	2,0 s
čakanie na vykreslenie	3,5 s
Spolu	10 s

Žiadna jednotlivá časť nemá desať sekúnd.

Ale malé problémy sa spočítali do katastrofálneho výsledku.

Práve preto treba LCP analyzovať ako celý reťazec.

Koľko zákazníkov môžete stratiť?

Tu treba byť opatrný.

Neexistuje univerzálne pravidlo:

„LCP 10 sekúnd znamená presne 37 % stratených zákazníkov.“

Taký údaj by bol zavádzajúci.

Závisí od:

• značky,
• sortimentu,
• konkurencie,
• zdroja návštevnosti,
• zariadenia,
• ceny produktu,
• urgencie nákupu.

Historické výskumy Google a SOASTA však ukázali veľmi jasný trend:

čím dlhšie sa mobilná stránka načítava, tým vyššia je pravdepodobnosť odchodu používateľa.

V jednej známej analýze sa pri náraste času načítania z 1 na 10 sekúnd zvýšila modelovaná pravdepodobnosť bounce o 123 %.

Iná analýza ukazovala približne 13 % bounce pri načítaní pod 3 sekundy a takmer 60 % po prekročení 9 sekúnd.

Treba zdôrazniť, že ide o staršie štúdie celkového času načítania, nie o univerzálnu konverznú tabuľku LCP pre každý dnešný e-shop.

Ich význam však zostáva veľmi praktický:

extrémne pomalé stránky strácajú návštevníkov skôr, než dostanú šancu konvertovať.

Ako si dopad spočítať na vlastnom e-shope?

Namiesto slepého preberania priemerných percent si spravte vlastný model.

Predstavme si:

• 100 000 návštev mesačne,
• 2 % konverzný pomer,
• priemerná objednávka 80 €.

To znamená približne:

2 000 objednávok × 80 € = 160 000 € mesačný obrat.

Ak by problémy s výkonom spôsobili iba 5 % stratu potenciálnych objednávok, bavíme sa približne o:

8 000 € mesačne.

Pri 10 % rozdiele:

16 000 € mesačne.

Toto nie je predikcia.

Je to jednoduchý scenár, ktorý ukazuje, prečo má výkon zmysel prepočítavať cez obchodné čísla, nie iba cez zelené a červené kolieska v PageSpeed.

Najdrahší problém môže byť platená návštevnosť

Pri organickej návštevnosti vás pomalý web stojí príležitosť.

Pri PPC vás môže stáť príležitosť aj peniaze za klik.

Predstavme si Google Ads:

• CPC 0,80 €,
• 10 000 návštev,
• náklady 8 000 €.

Ak významná časť používateľov odíde pre zlú používateľskú skúsenosť ešte pred zobrazením hlavného obsahu, časť reklamného rozpočtu ste minuli na návštevnosť, ktorej ste nedali férovú šancu nakúpiť.

Ako LCP otestovať?

LCP sa dá dnes pomerne jednoducho preveriť viacerými spôsobmi.

1. Google PageSpeed Insights

Najjednoduchší verejný nástroj.

Zadáte URL a získate:

• mobilné meranie,
• desktopové meranie,
• Lighthouse diagnostiku,
• Core Web Vitals,
• ak sú dostupné, aj dáta reálnych používateľov Chrome.

PageSpeed Insights nájdete na:

https://pagespeed.web.dev/

2. Chrome DevTools a Lighthouse

Ak potrebujete ísť technicky hlbšie, použite Chrome DevTools.

Výhodou je možnosť pozrieť:

• ktorý prvok bol LCP,
• Network waterfall,
• časovanie requestov,
• blokujúce zdroje,
• JavaScript,
• CSS,
• Performance trace.

Toto je vhodná cesta pre developera alebo technický audit.

3. Bezplatný audit cez EshopMonitor.sk

Ak chcete rýchlo skontrolovať e-shop alebo web spolu s ďalšími technickými a SEO signálmi, LCP vieme zmerať aj v rámci bezplatného auditu na EshopMonitor.sk.

EshopMonitor využíva laboratórne Lighthouse meranie zvlášť pre mobil a desktop a jasne oddeľuje tieto výsledky od dostupných dát reálnych používateľov Chrome.

Výhodou je, že spolu s výkonom kontroluje aj ďalšie oblasti, napríklad:

• HTTPS,
• robots.txt,
• sitemap.xml,
• title a meta údaje,
• technické SEO signály,
• vybrané bezpečnostné prvky,
• ďalšie technické nálezy.

Bezplatný audit si môžete spustiť na:

www.eshopmonitor.sk/audit

Výsledok netreba chápať ako definitívny verdikt nad celým webom.

Je to rýchla automatická kontrola, ktorá vám ukáže, kde môže byť problém a čomu sa oplatí venovať ďalšiu pozornosť.

Netestujte iba homepage

Veľmi častá chyba:

Majiteľ otestuje homepage.

Výsledok je dobrý.

A uzavrie:

„E-shop je rýchly.“

Lenže zákazníci môžu prichádzať priamo na:

• produkty,
• kategórie,
• blogové články,
• landing pages.

Každý typ stránky môže mať úplne inú šablónu a iné výkonnostné problémy.

Testujte preto minimálne:

1. homepage,
2. hlavnú kategóriu,
3. produktovú stránku,
4. obsahovú stránku,
5. najnavštevovanejšiu landing page.

Netestujte iba raz

Jedno meranie môže ovplyvniť:

• momentálne zaťaženie servera,
• externý skript,
• sieť,
• cache.

Ak dostanete LCP 10 sekúnd, test zopakujte.

Ak dostanete:

• 9,8 s,
• 10,3 s,
• 9,4 s,

problém je veľmi pravdepodobne reálny.

Ak ďalšie merania ukážu:

• 2,4 s,
• 2,6 s,
• 10,1 s,

treba analyzovať, čo spôsobilo anomáliu.

Ak máte LCP 10 sekúnd, čo riešiť ako prvé?

Nerobte náhodných dvadsať optimalizácií.

Postupujte systematicky.

Krok 1: Nájdite LCP prvok

Je to:

• obrázok,
• nadpis,
• video,
• banner?

Krok 2: Rozdeľte LCP na štyri časti

Skontrolujte:

• TTFB,
• resource load delay,
• resource load duration,
• render delay.

Google odporúča práve tento spôsob analýzy, pretože celé LCP je súčtom týchto štyroch fáz.

Krok 3: Pozrite Network waterfall

Kedy sa LCP zdroj začne sťahovať?

Ak až po troch sekundách, nezačínajte kompresiou obrázka.

Najskôr riešte, prečo browser tri sekundy čakal.

Krok 4: Skontrolujte server

Ak je TTFB vysoké, optimalizácia obrázka vás nezachráni.

Krok 5: Skontrolujte tretie strany

Odstráňte alebo odložte všetko, čo nepotrebujete na prvé zobrazenie.

Krok 6: Zopakujte meranie

Optimalizácia bez merania pred a po je iba pocit.

Čo neopravovať naslepo

Ak vám nástroj ukáže zlý LCP, neznamená to automaticky:

„Treba zmenšiť obrázky.“

Google vo svojich novších analýzach upozorňuje, že samotný čas sťahovania obrázka často nie je najväčšou časťou slabého LCP.

Problém býva veľmi často v:

• TTFB,
• oneskorenom objavení LCP zdroja,
• dependency chains,
• render delay.

Preto treba merať príčinu, nie optimalizovať podľa dojmu.

Má LCP vplyv aj na SEO?

Core Web Vitals sú súčasťou širších signálov page experience.

Ale bolo by nesprávne tvrdiť:

„Znížime LCP z 5 na 2 sekundy a posunieme sa o päť pozícií.“

Takto SEO nefunguje.

Výkon stránky je iba jeden z mnohých signálov.

Pre e-shop je však často ešte dôležitejšia iná vec:

rýchlejší web používajú skutoční zákazníci.

A oni rozhodujú o:

• bounce rate,
• počte prezretých produktov,
• pridaní do košíka,
• objednávke,
• tržbách.

Výkon webu je obchodná metrika

Technici vidia:

LCP = 5,7 s.

Majiteľ e-shopu by mal vidieť:

Koľko zákazníkov čaká príliš dlho a čo nás to môže stáť?

Práve preto má zmysel prepájať výkon s analytikou.

Porovnajte napríklad:

• mobil vs. desktop,
• rýchle vs. pomalé landing pages,
• bounce rate,
• engagement,
• konverzný pomer,
• tržbu na návštevu.

Ak pomalšie stránky zároveň horšie konvertujú, získavate oveľa silnejší argument na optimalizáciu než obyčajné červené číslo z Lighthouse.

Záver: 10 sekúnd nie je technická kozmetika

Ak má web LCP 2,8 sekundy, hovoríme o optimalizácii.

Ak má 4,5 sekundy, máme jasný problém.

Ak má 6 sekúnd, mali by sme ho riešiť prioritne.

A ak sa hlavný obsah objavuje približne po desiatich sekundách, nejde o kozmetickú technickú chybu.

Je to potenciálny obchodný problém.

Nemusí vás stáť presne 10 %, 20 % alebo 50 % zákazníkov.

To bez reálnych dát nevieme.

Vieme však jedno:

zákazník nemôže kúpiť produkt, ktorý ešte nevidí.

A každá zbytočná sekunda vytvára ďalšiu príležitosť, aby zavrel stránku a odišiel ku konkurencii.

Viete, aké LCP má váš e-shop?

Nemusíte začínať rozsiahlym technickým auditom.

Na EshopMonitor.sk si môžete spustiť bezplatnú automatickú kontrolu e-shopu a preveriť základné technické, SEO a výkonnostné signály vrátane laboratórneho Lighthouse merania na mobile a desktope.

Výsledok vám môže ukázať, či sa oplatí hlbšie preveriť LCP, Core Web Vitals alebo ďalšie technické oblasti.

Spustiť bezplatný audit e-shopu »