Core Web Vitals a rychlost e-shopu: proč se web načítá pomalu a co s tím

Rada, kterou k pomalému načítání webu najdete všude, zní „zrychlete web“. Zní dobře, jenže v téhle podobě se s ní nedá nic dělat. Neříká, co přesně je pomalé, kolik vás to stojí, ani kdo to má opravit — vy, nebo dodavatel vašeho e-shopového řešení. Tenhle článek proto odpovídá na tři otázky:

• Co přesně Google měří a jaké hodnoty stačí?
• Kolik mě pomalý web stojí — na pozicích a na penězích?
• Proč se můj e-shop načítá pomalu a co s tím zmůžu sám, když mám web na pronajaté platformě?

Ještě než se pustíme do měření: jak vůbec poznáte, že jde o rychlost, a ne o něco jiného? Tři signály jsou vidět bez jakéhokoli nástroje. Na mobilu mimo wi-fi trvá, než se objeví hlavní fotka. Po kliknutí na filtr nebo variantu se chvíli neděje nic. A fotky s cenami doskakují, až stránka při tom poskočí. Každý z těch tří projevů má jméno, číslo i vlastní opravu — a přesně v tomhle pořadí je probereme.

Je to technický článek z tématu SEO a UX pro e-shop, ale programovat kvůli němu nemusíte. Technika v něm slouží k tomu, abyste věděli, o co požádat vývojáře a jak si ověřit, že to pomohlo. A pokud teprve skládáte celkový obrázek, co všechno rozhoduje o viditelnosti e-shopu, začněte u přehledového článku SEO pro e-shop — rychlost je jedna z jeho vrstev.

Co jsou Core Web Vitals a jak Google rychlost měří

Core Web Vitals jsou tři metriky, tedy tři měřené hodnoty, kterými Google popisuje chování stránky vůči skutečnému návštěvníkovi. Měří, jak dlouho člověk čeká na obsah, jak rychle stránka reaguje na jeho akce a jestli mu obsah neuskakuje pod rukama.

Tři barevná pásma potkáte ve všech nástrojích Googlu: zelená znamená splněno, oranžová „funguje to, ale zdržuje“ a červená problém, který zákazník vnímá. Samotné prahy platí beze změny od března 2024, kdy metrika INP nahradila starší a mírnější FID (web.dev). Právě ta výměna byla pro e-shopy citelná: INP měří odezvu každé interakce — filtrů, výběru variant, košíku — takže weby, které dřív prahy splňovaly, je najednou splňovat přestaly.

Důležitější než samotné prahy je ale způsob, jak se vyhodnocují. Google totiž nebere jeden testovací běh: měří skutečné návštěvy vašeho webu za posledních 28 dní, které sbírá prohlížeč Chrome do veřejné databáze CrUX (Chrome User Experience Report). Z těch návštěv se počítá takzvaný 75. percentil — aby stránka prošla, musí práh splnit tři čtvrtiny z nich (web.dev). Tytéž návštěvy se navíc dělí na mobilní a počítačové a hodnotí se zvlášť, takže věta „na mém notebooku se to načítá hned“ o výsledku neříká vůbec nic. O vašem výsledku rozhoduje průměrný telefon vašeho zákazníka na průměrném připojení.

Z toho plyne první praktický závěr: rychlost e-shopu není jedno číslo, které jednou změříte a máte hotovo. Je to průběžný stav, který se mění s každou novou funkcí, bannerem nebo doplňkem — a měří se na zákaznících, ne na vašem počítači.

Proč se e-shop načítá pomalu: tři viníci po jedné

Pomalé načítání není u e-shopu jedna nemoc, ale tři různé — a každá z těch tří metrik popisuje jednu z nich. Vyplatí se rozumět tomu, co která znamená pro zákazníka a co ji na produktové stránce nejčastěji kazí, protože podle toho se dělí práce: jiný viník, jiná oprava, jiný účet.

LCP: jak dlouho zákazník čeká na to hlavní

První z nich, LCP (Largest Contentful Paint), měří, za jak dlouho se objeví největší prvek stránky — na produktové stránce skoro vždy hlavní fotka produktu. Do 2,5 vteřiny je to v pořádku; do té doby zákazník kouká na poloprázdnou stránku a rozhoduje se, jestli počká. Zároveň je to metrika, na které padá nejvíc webů: na mobilu ji plní jen 62 % z nich, méně než odezvu i stabilitu (Web Almanac 2025). Pokud nevíte, kde začít, začněte tady.

Na vině jsou nejčastěji zbytečně velké obrázky: fotka nahraná v plném rozlišení z fotoaparátu, galerie načítaná celá najednou, banner přes celou šířku. Zadání pro vývojáře nebo pro nastavení platformy můžete zkopírovat rovnou: obrázky zmenšit (u hlavní fotky stačí delší strana kolem 2 000 pixelů a velikost do 200 kB) a ukládat je ve formátu WebP nebo AVIF. Hlavní fotce pak nastavit přednostní načtení (fetchpriority="high") a zbytek galerie načítat líně (lazy loading). Když ani potom LCP neklesne, bývá viníkem odezva serveru: PageSpeed Insights, bezplatný měřicí nástroj Googlu, rozkládá LCP na čtyři fáze. Když největší díl ukrajuje čekání na první odpověď (TTFB), problém není ve fotce, ale v hostingu.

Jak si to ověříte: vložte produktovou stránku do PageSpeed Insights a rozbalte diagnostiku LCP — nástroj pojmenuje konkrétní prvek, který se vykresloval nejdéle. U produktové stránky to má být hlavní fotka; když je to banner, video nebo cizí skript, máte viníka černé na bílém.

INP: jak rychle stránka odpovídá na kliknutí

U INP (Interaction to Next Paint) nejde o čekání na obrázek, ale o to, co se stane po kliknutí. Zvolíte variantu, zaškrtnete filtr, přidáte do košíku — a INP měří, za jak dlouho stránka viditelně zareaguje. Do 200 milisekund působí odezva okamžitě, nad půl vteřiny — což je hranice červeného pásma — už je zdržení zřetelné na první pohled.

Odezvu nekazí obrázky, ale skripty, tedy kód, který na stránce běží. Prohlížeč je totiž zpracovává v jediné frontě: dokud dopočítává měřicí kódy, chat nebo personalizaci, k vašemu kliknutí se nedostane. Do stejné fronty se u e-shopu stavějí filtry v kategorii (výběr barvy, velikosti nebo ceny — odborně fasetové filtry) a přepínání variant, protože každé kliknutí spouští přepočet. Oprava se dá říct jednou větou, a přesto je z těch tří nejtěžší: mít na stránce méně skriptů a ty nepodstatné načítat až nakonec. Kterých skriptů se to týká, projdeme v kapitole o skriptech třetích stran.

Jak si to ověříte: z jednoho testu INP nezjistíte — simulace odezvu na skutečné klikání neměří. Vezměte svůj telefon, projděte produktovou stránku a klikejte na filtry a varianty; co ucítíte jako zaváhání, to zažívají i skuteční zákazníci. Tvrdé číslo pak najdete v reálných datech v Search Console — bezplatném nástroji Googlu s daty o vašem webu — nebo v horní části PageSpeed Insights.

CLS: jak moc obsah uskakuje

Třetí metrika, CLS (Cumulative Layout Shift), měří vizuální stabilitu — jestli obsah při načítání drží na místě, nebo skáče. Klasický projev: chcete kliknout na tlačítko, jenže nad ním právě doskočila cena, lišta nebo banner, obsah poskočí a vy kliknete na něco jiného. A měří se po celou dobu prohlížení, takže se počítá i obsah, který doskakuje při posouvání stránkou.

Může za to obsah, který se načítá později, aniž by pro něj stránka měla předem vyhrazené místo. Typicky obrázky bez udaných rozměrů, reklamní a informační lišty, cookie lišta nebo pozdě načtené ceny a dostupnosti. Oprava patří k těm levnějším a zadání zní: každému obrázku doplnit rozměry (atributy width a height) a každé liště či banneru vyhradit místo předem. Poskakování si pak ověřte po každé úpravě vzhledu — když se šablona, tedy hotový vzhled e-shopu, upravuje narychlo skriptem místo pořádné úpravy stylů, stabilita se rozbije, i když web „vypadá stejně“. Přesně to popisuje Shoptet u e-shopu deNatura.cz, kterému úpravy vzhledu JavaScriptem rozházely stabilitu stránky (blog Shoptetu, duben 2026).

Jak si to ověříte: otevřete produktovou stránku na mobilu a jen se dívejte, jestli mezi prvním zobrazením a plným načtením něco poskočí — hlavně kolem ceny a tlačítka „Do košíku“. PageSpeed Insights navíc v diagnostice vypíše seznam prvků, které posuny způsobily.

Tři metriky, tři různí viníci: obrázky, skripty a chybějící místo pro později načtený obsah. Než ale začnete cokoli z toho opravovat, vyplatí se vědět, co si od zrychlení slibovat — na pozicích ve vyhledávání se totiž odehraje méně, než se traduje.

Co rychlost skutečně udělá s pozicemi

Na pozicích ve vyhledávání rozhoduje rychlost jen málo — a právě tady vzniká většina přehnaných očekávání.

Ta očekávání nevznikla náhodou. Když Google v roce 2021 Core Web Vitals zaváděl, mluvilo se o nich jako o novém hodnoticím systému a půlka internetu se předháněla v optimalizaci. Jenže v dubnu 2023 Google „prostředí stránky“ ze seznamu svých hodnoticích systémů zase vyřadil: rychlost zůstala jedním z mnoha dílčích signálů, ne samostatným algoritmem (Google Search Central, duben 2023).

Stejně to dnes říká i dokumentace Googlu, a nezvykle přímočaře. Dobré výsledky v přehledech Core Web Vitals podle ní nezaručují přední pozice a vyhledávání „se vždy snaží zobrazit nejrelevantnější obsah, i když je prostředí stránky podprůměrné“ (dokumentace Google). Přeloženo: obsah, který odpovídá na dotaz, porazí rychlejší stránku s horší odpovědí. Honit setiny vteřiny kvůli SEO je špatná investice.

To ale neznamená, že je rychlost pro SEO jedno. Funguje jako jazýček na vahách mezi jinak srovnatelnými stránkami. A extrémně pomalý web ztrácí pozice nepřímo: návštěvníci z něj odcházejí, roboti Googlu na něm projdou méně stránek a málokdo na něj odkáže. Splněné prahy vám tedy samy pozice nezvednou; nesplněné vás ale brzdí, a to i tam, kde máte obsah v pořádku.

Pro vás z toho plyne jedno rozhodovací pravidlo: investici do rychlosti neobhajujte pozicemi, protože tam je dopad malý a nejistý. Obhajujte ji penězi, které pomalý web prokazatelně stojí — a právě o těch je další kapitola.

Kolik vás pomalý web stojí — a kterým číslům nevěřit

Peníze jsou ten pravý důvod, proč rychlost řešit. Jenže zrovna kolem rychlosti koluje víc nafouknutých čísel než kde jinde, takže se vyplatí znát ta doložená i ta, která doložená nejsou.

Nejsilnější číslo máme z jednoho z mála případů, kdy někdo rychlost skutečně testoval řízeným pokusem. Vodafone v Itálii postavil proti sobě dvě verze téže prodejní stránky — jednu zrychlenou, druhou původní — a měřil rozdíl. Verze s LCP lepším o 31 % prodala o 8 % víc (web.dev, 2021). Stejná stránka, stejná nabídka; lišila se jen rychlost. Byl to test jedné stránky na jednom trhu, takže číslo neberte jako sazbu. Směr ale ukázal skutečný pokus, ne dohad.

Druhé měření je širší, zato slabší. Studie Deloitte a Googlu sledovala 37 evropských a amerických značek a měřila, co se děje, když se mobilní web přirozeně zrychlí o pouhou desetinu vteřiny. Výsledek: každým krokem nákupu prošlo o 3,2 až 9,1 % víc lidí a hodnota objednávky vzrostla o 9,2 % (Deloitte/Google, 2020). Tady si všimněte povahy čísla: nikdo nic nezrychloval schválně, jen se měřilo, co se s rychlostí souběžně mění. Je to korelace, ne pokus — ukazuje ale stejným směrem.

Ty ztracené nákupy přitom neodcházejí do vzduchu, ale ke konkurenci. Podle měření HTTP Archive dnes všechny tři prahy na mobilu plní 48 % webů a číslo se rok od roku lepší — v roce 2021 to bylo 32 % (Web Almanac 2025). Výmluva „všichni jsou na tom stejně“ tedy pomalu přestává platit: v té lepší polovině jsou často právě konkurenti, se kterými se přetahujete o zákazníka. Co dalšího kromě rychlosti rozhoduje, jestli návštěvník nakonec nakoupí, rozebírá článek o UX a konverzích e-shopu.

Dvěma číslům, která potkáte nejčastěji, naopak nevěřte doslova:

• „53 % lidí odejde, když se stránka načítá déle než 3 vteřiny.“ Pochází z dat Googlu z roku 2016 — z doby před dnešními telefony i sítěmi. Google ho ve svých aktuálních materiálech už sám necituje.
• „Amazon: každých 100 ms zpoždění = −1 % tržeb.“ Tohle číslo nevyšlo v žádné publikaci Amazonu; pochází z blogu bývalého zaměstnance z roku 2006 a od té doby se opisuje jako fakt. Řízené experimenty se záměrným zpomalením u velkých webů existují a směr potvrzují — jen z nich nevyčtete žádnou univerzální sazbu.

Že ta dvě čísla nejsou k citování, neznamená, že je jejich směr špatný — pomalé weby prodávají hůř, to dokládají i doložená měření výš. Znamená to jen, že přesnou sazbu „vteřina = X % tržeb“ vám nikdo seriózně neřekne. Hrubý odhad pro vlastní rozhodování si ale uděláte snadno: vezměte měsíční počet objednávek a průměrnou marži a spočítejte, kolik by vám přineslo jedno procento konverze navíc. To je strop, kolik má smysl do zrychlení ročně investovat — a u většiny e-shopů vyjde překvapivě vysoko. Skutečný argument je totiž jednoduchý: pomalý web vám bere zákazníky, kteří už na stránce jsou a které jste už zaplatili, ať reklamou, nebo obsahem.

Jak si rychlost změřit

Změřit rychlost umíte zdarma a bez odborníka — stačí vědět, kam se dívat a co které číslo znamená.

Začněte v Search Console, kde najdete přehled pojmenovaný Core Web Vitals (název se nepřekládá ani v české verzi). Ukazuje stav celého webu z reálných návštěv za posledních 28 dní a stránky seskupuje podle šablon (nápověda Search Console). Všechny produktové stránky tak spadnou do jedné skupiny: sdílejí vzhled, a tedy i příčinu problému. To je pro vás výhodné, protože neřešíte tisíc adres, ale dvě tři skupiny — když se skupina produktových stránek zobrazí oranžově nebo červeně, příčina sedí v šabloně a stačí jedna oprava. A pokud Search Console nastavenou nemáte, nevadí: začněte rovnou dalším nástrojem, ten funguje bez přihlášení, a ověření Search Console si mezitím vyžádejte od správce webu.

Na jednotlivou stránku použijte PageSpeed Insights. Tady vzniká nejčastější nedorozumění: nástroj ukazuje dva různé druhy údajů a je snadné si je splést.

• Nahoře jsou reálná data uživatelů (CrUX) — plníte, nebo neplníte Core Web Vitals. Tohle je to, co „vidí Google“, a jediné, co se počítá.
• Níže je skóre 0–100 z nástroje Lighthouse — výsledek jednoho simulovaného testu na pomalém telefonu a pomalé síti. Je to užitečná diagnostika, ale není to známka od Googlu. Web se skóre 60 může Core Web Vitals bez problémů plnit — a web se skóre 95 může v reálném provozu propadat, protože simulace neměří odezvu na skutečné klikání (web.dev).

Honit se za skóre 100 je proto zbytečné. Číst se má horní část: reálná data.

U menšího e-shopu navíc často nastane tohle: PageSpeed Insights u konkrétní stránky žádná reálná data neukáže, protože stránka nemá dost návštěv, aby se dostala do databáze CrUX. Nástroj v tu chvíli sáhne po souhrnných datech celého webu (takzvaná data na úrovni originu). Proto se také čísla v PageSpeed Insights a v Search Console můžou lišit — každé se dívá na jinak širokou skupinu návštěv. Když nestačí ani souhrn za web, zbývá simulace Lighthouse jako orientační zkouška.

Chybějící data v CrUX neznamenají nic špatného — jen to, že Google o rychlosti vašeho webu žádná reálná data nemá. Důvod ji řešit tím ale nemizí, jen se přesouvá na stranu zákazníka: ten pomalost cítí bez ohledu na to, jestli ji Google vidí. A pokud chcete přesto vlastní reálná čísla, řešení existuje. Vývojář vám na web nasadí bezplatný měřicí skript web-vitals od Googlu; ten posílá hodnoty LCP, INP a CLS vašich skutečných návštěvníků do Google Analytics.

Čím začít: otevřete Search Console (nebo PageSpeed Insights, pokud ji nemáte) a podívejte se na mobilní data. Výsledky si zapište i s datem — přehledy hodnotí klouzavých 28 dní, takže každá oprava se v číslech projeví až po několika týdnech, a bez poznámek nepoznáte, jestli pomohla.

Co zmůžete sami na české platformě

Sami zmůžete víc, než se u „technického“ tématu čeká — jen jinde, než se obvykle radí. Klíč je vědět, kde končí odpovědnost platformy a začíná ta vaše.

Pronajatá platforma: server a šablonu drží provozovatel

Na pronajaté platformě odpovídá za servery, kód šablon a jejich průběžné zrychlování provozovatel. Shoptet uvádí, že odezva jeho serverů je velmi dobrá „pro drtivou většinu ze 40 tisíc e-shopů“. Shrnuje to trefnou metaforou: „Shoptet vám dává kvalitní motor, ale jak rychle auto pojede, záleží na tom, co do něj naložíte“ (blog Shoptetu, duben 2026). Upgates tvrdí totéž — šablony ve výchozím stavu dosahují výborných výsledků a nový e-shop startuje kolem 93 bodů v PageSpeed na počítači (Upgates). U toho čísla si vzpomeňte na předchozí kapitolu: je to laboratorní skóre, a navíc z počítače — a ten je snazší disciplína než mobil. O reálných Core Web Vitals nerozhoduje; jako hrubá orientace o výchozím stavu šablony ale poslouží.

Jedno je k těm tvrzením potřeba dodat: jsou to slova platforem o sobě samých a nezávislé srovnání českých platforem neexistuje, protože mezinárodní měření je nezahrnují. Obě platformy se ale shodují s praxí v tom hlavním — rychlost nejčastěji kazí to, co si na web přidáte sami: úpravy šablony na míru, marketingové skripty, doplňky třetích stran a nezmenšené obrázky s bannery. Tedy věci plně ve vaší moci.

Praktický důsledek: na pronajaté platformě opravujete svou část, ne platformu. Projděte proto nainstalované doplňky a vypněte ty, které nepoužíváte; obrázky nahrávejte zmenšené podle zadání z kapitoly o LCP. A po každé další instalaci doplňku nebo úpravě šablony rychlost přeměřte, protože právě tam se nejčastěji pokazí.

Kdybyste přesto měli podezření, že je pomalá samotná platforma nebo šablona, ověříte to srovnáním: změřte v PageSpeed Insights jiný e-shop na stejné platformě a šabloně. Když je výrazně rychlejší než ten váš, viník je ve vaší části; když je stejně pomalý, pošlete oba výsledky podpoře platformy a ptejte se tam.

Open-source řešení: rychlost je celá vaše starost

U e-shopu na WooCommerce nebo PrestaShopu žádný provozovatel servery ani šablonu nedrží. Hosting, cache — tedy ukládání hotových stránek do mezipaměti, aby se nemusely při každé návštěvě sestavovat znovu — i počet pluginů jsou vaše rozhodnutí, případně rozhodnutí vašeho vývojáře. Právě cache přitom sama dokumentace WooCommerce vede jako podmínku výkonu, bez které se e-shop s databázově náročným košíkem neobejde (dokumentace WooCommerce).

Mezinárodní data ukazují důsledek té volnosti: zatímco pronajaté platformy plní Core Web Vitals nadprůměrně často, e-shopy na WooCommerce výrazně podprůměrně (Web Almanac 2025). Část rozdílu vysvětluje samotná skladba těch webů: na WooCommerce běží i e-shopy na nejlevnějším sdíleném hostingu bez správce. A právě v tom je pointa: open-source e-shop je přesně tak rychlý, jak dobrý je jeho správce. Vaše tři páky jsou hosting (ne nejlevnější sdílený), zapnutá a otestovaná cache a pravidelný úklid pluginů. To je zadání pro správce webu, a zároveň dobrý test, jestli nějakého skutečně máte.

Skripty třetích stran: každý si musí na sebe vydělat

Třetí oblastí jsou skripty třetích stran — měřicí kódy, chat, cookie lišta, personalizace, widgety recenzí. Právě ty jsou největší položka, kterou si na web přidáváte sami, a zároveň jedna z mála oblastí, kde existují tvrdá čísla:

• Google Tag Manager s osmi měřicími kódy zpomalil testovací stránku zhruba o 3 vteřiny proti stránce bez nich. Měřeno na simulaci pomalejšího mobilního připojení (profil Fast 3G); na rychlé síti bude rozdíl menší, na horší naopak ještě větší (Analytics Mania, 2025). To neznamená GTM vyhodit — stejné kódy vložené do stránky natvrdo byly ještě dvakrát pomalejší. Znamená to nemít v něm kódy, které nikdo nečte.
• Cookie lišta umí zdvojnásobit čas do zobrazení hlavního obsahu, když se sama stane největším prvkem stránky — v doloženém příkladu z 1,4 na 3,6 vteřiny. A tatáž lišta zdržuje i odezvu: kliknutí na „Přijmout“ umí stránku zablokovat na stovky milisekund a mezi nástroji na správu souhlasu je v tom rozdíl přes 130 ms (DebugBear, 2025).
• Chatovací widgety stahují podle poskytovatele od necelých 100 KB po zhruba 700 KB navíc (pagespeed.one, 2025).

U každého z nich si proto položte jednoduchou otázku: vydělá si na sebe? Chat, který obslouží deset zákazníků denně, ano. Heatmapa, kterou nikdo tři měsíce neotevřel, a měřicí kód kampaně, která dávno skončila, ne — a přesto dál zpomalují každou návštěvu. Inventura skriptů jednou za čtvrtletí je nejlevnější zrychlení, které existuje: nic nestojí a nikdo vám při ní nemůže nic rozbít. Sepište si všechny doplňky a měřicí kódy, které na webu běží, a ke každému doplňte, kdo ho používá a k čemu — co odpověď nemá, kandiduje na vypnutí. Teprve po téhle inventuře má cenu bavit se s vývojářem o technice.

Rychlost je vstupní podmínka pro všechno ostatní

Rychlost je vstupní podmínka proto, že bez ní se ostatní práce nevyplatí. Obsah, strukturovaná data (údaje na stránce zapsané ve tvaru, kterému rozumí vyhledávače) i reklama vedou zákazníka na stránku — a pomalá stránka ho na poslední chvíli ztratí. Jak stejnou produktovou stránku doladit obsahově — titulky, popisky a strukturovaná data — rozebírá článek o on-page a technickém SEO produktových stránek.

Zároveň platí, že rychlost a technické opravy nejsou naše služba. V SEO auditu rychlost změříme, pojmenujeme příčiny a seřadíme priority podle dopadu — samotnou opravu ale dělá váš vývojář nebo dodavatel platformy, protože zásahy do cizího webu nepřebíráme. Naše těžiště je jinde: v produktových datech a feedech — souborech s nabídkou, které e-shop posílá do srovnávačů a reklamních systémů — a v jejich souladu se stránkou. Díky tomu vám audit řekne i to, co čistě technický pohled neřekne: jestli máte dřív řešit pomalou šablonu, nebo třeba popisky a strukturovaná data, které brzdí viditelnost víc.

Co udělat teď a co nechat být

Celý článek se dá stlačit do tří kroků, které zvládnete tento týden bez rozpočtu:

1. Změřte se. Search Console nebo PageSpeed Insights, mobilní data, zapsat výsledky i s datem. Postup máte v kapitole o měření.
2. Udělejte inventuru. Doplňky a skripty se jménem uživatele a účelem; co neobstojí, vypněte. Je to nejlevnější zrychlení, které existuje.
3. Zadejte vývojáři to, co sami nezměníte. Typicky přesně tři věci z kapitoly o metrikách: zmenšit a přednostně načítat hlavní obrázky (LCP), doplnit rozměry obrázkům a vyhradit místo lištám (CLS), odložit nepodstatné skripty (INP). Formulace v těch kapitolách jsou psané tak, abyste je mohli zkopírovat do e-mailu. Po každé změně přeměřte a počítejte s tím, že reálná data se přepisují 28 dní.

A co nechat být: honbu za skóre 100, přepisování webu kvůli setinám a víru, že rychlost sama o sobě zvedne pozice. Rychlost je hygiena — jako uklizený sklad nebo pokladna, u které se netvoří fronta. Nikdo vás za ni nepochválí, ale bez ní prodělává všechno ostatní, co děláte dobře. Zákazník z vlaku, který na začátku článku zavřel váš e-shop, se nevrátí ani neozve; příště ale nemusí mít důvod odcházet.