Falešně rychlé weby: jak se hackuje Lighthouse skóre

Komunita kolem rychlosti webu žije ve falešném cyklu. Lidé si totiž pletou Lighthouse skóre s rychlostí webu. Toho zneužívají autoři pluginů, kteří cílí na zlepšení této metriky, aniž by zlepšili rychlost webu.

Na trhu existuje řada pluginů nabízejících zrychlení webu na jedno tlačítko. Budeme jmenovat například WP-Optimize, WP Rocket nebo Website Speedy. Jejich dopadem ovšem často jen zlepšení Lighthouse skóre.

Dělají to většinou tak, že odloží načtení veškerého JavaScriptu. Tím mohou zlepšit jednu metriku, ale znehodnotit jiné metriky rychlosti a poškodit vám analytiku.

Website Speedy jsme pro potřeby článku zkoumali více a experimentem u klienta jsme zjistili, že vypnutí pluginu sice vrátí Lighthouse skóre do normálních hodnot, ale s rychlostí webu nic neudělá.

Navíc vidíme velmi podezřelou detekci testování, takže web testovaný Lighthousem se může chovat jinak než u skutečných uživatelů.

Lighthouse skóre. Špatná metrika, která ale všechny zajímá#

Při onboardingu klientů do PageSpeed.ONE několikrát měsíčně bavím s někým, kdo chce „zlepšit skóre v PageSpeed Insights“. Takové to kolečko dole. No však víte, Lighthouse skóre.

Rozumíme tomu. Je to jedno číslo, hezky barevné, snadno se posílá kolegům přes Slack… Jenže Lighthouse skóre je výsledek syntetického testu jedné stránky, v jednom prostředí, s jedním nastavením. Složení i váhy se mezi verzemi Lighthouse mohou měnit. Stejně tak vám Lighthouse na vašem počítači ukáže jiné číslo než Lighthouse v PageSpeed Insights.

Pojďme to znovu zopakovat:

Lighthouse skóre není metrika rychlosti webu. Je to technický diagnostický ukazatel.

Také se v PageSpeed Insights díváte na špatné místo?

Rychlost webu totiž nevzniká v Lighthouse. Vzniká v telefonech vašich návštěvníků, v hospodské wifi, na starém čínském smartphonu na tři čárky signálu, s deseti otevřenými taby a při klikání na cookie lištu.

Lighthouse tohle nevidí. Není to totiž uživatel. Lighthouse nescrolluje, nekliká, nepřihlásí se, neotevře filtr produktů ani nedojde do checkoutu.

Skutečnou rychlost měří metriky Core Web Vitals z databáze Chrome UX Report. (Rozdíly mezi labem a daty od uživatelů shrnuje synth vs. CrUX vs. RUM.)

Ekonom by řekl: „Jasně, Goodhartův zákon“#

Ekonom Charles Goodhart kdysi napsal jednu větu, která se dnes učí na univerzitách:

„Jakmile se z metriky stane cíl, přestává být dobrou metrikou.“

Tady to sedí perfektně. Z Lighthouse skóre se totiž přesně tohle stalo.

Lidi chtějí jednoduché číslo. Google ho (dle mého názoru chybně) v PageSpeed Insights ukazuje velké a barevné.

Klienti se na Lighthouse skóre ptají agentur. Některé agentury jej pak slibují vylepšit. A pak přijdou pluginy, které slibují to samé, jenom rychleji a bez práce.

Jakmile se z diagnostického čísla stane obchodní argument, vznikne trh s jeho vylepšováním. A jakmile je výpočet předvídatelný, někdo začne hackovat metriku, namísto optimalizace webu.

Odkládání JavaScriptu není optimalizace, ale přesouvání problému#

Velké množství dnešních „zrychlovacích“ pluginů má jedno zatržítko, které umí zvednout Lighthouse skóre o desítky bodů za pět vteřin práce. Odloží spuštění veškerého JavaScriptu až na první interakci uživatele. Scroll, kliknutí, dotek obrazovky.

Proč to na hacknutí Lighthouse skóre funguje tak spolehlivě? Lighthouse stránku načte a změří. Nescrolluje, nekliká, obrazovky se nedotkne. Odložený JavaScript tedy v testu nikdy neproběhne. Z měření tím například zmizí Total Blocking Time (TBT), tedy metrika, která má v Lighthouse skóre největší váhu. Zlepší se také rychlost načtení (LCP).

Lighthouse skóre vyskočí nahoru, přitom se na webu nezrychlilo nic. Pro skutečného uživatele se totiž nic nezměnilo. Jen se to přesunulo na později. A často do nejhoršího možného momentu.

Ilustrace odložení JavaScriptu. Skripty se načtou až po uživatelské interakci. Je to zlo.

V PageSpeed.ONE jsme optimalizovali stovky webů, ale nikdy jsme tuto techniku klientům nedoporučili. Jaká jsou rizika odložení všech JavaScriptů?

1. Negativní vliv na interakce (INP). Uživatel dorazí na stránku, přečte si nadpis a klikne. V tu chvíli se spustí všechen odložený JavaScript, který se do té doby hromadil. Hlavní vlákno prohlížeče se zablokuje a první kliknutí uživatele čeká. Přesně tohle může zhoršit metriku INP, kterou Google počítá do Core Web Vitals.
2. Negativní vliv na posuny layoutu (CLS). Skripty, které dorenderovávají obsah, tedy karusely, personalizace a další, se při odložení JavaScriptu spustí pozdě. V Lighthouse testu se přitom žádný posun nezměří, protože se ten kód nikdy nespustil. Skutečnou hodnotu CLS tak nevidíte ani vy.
3. Funkčnost měření. Analytika, souhlas s cookies, chat, A/B testy a měření konverzí se odkládají spolu se vším ostatním. Data vám pak nemusí sedět a nikdo neví proč.
4. Znehodnocení Lighthouse skóre. Jak jsme psali, Lighthouse skóre sice není metrika rychlosti webu, ale pro diagnostiku změn nebo optimalizace je užitečné. Tím, že v Lighthouse skóre není žádný JavaScript, měříte úplně něco jiného než váš web.

Odložení všech JavaScriptů je špatná technika. Rozhodnout, co se má načíst kdy a v jakém pořadí, je inženýrská práce, která vyžaduje znalost konkrétního webu. Jedno zatržítko, které odloží veškerý JavaScript, tuto práci nezastane.

A to nejproblematičtější nakonec. Dodavatelé těchto funkcí u nich zpravidla nikde neuvádějí, co to udělá s Lighthouse skóre a jak to může ohrozit rychlost u reálných uživatelů. Kdyby to totiž uváděli, zákazník by pochopil, že si často nekupuje rychlejší web, ale jen lepší číslo v testu.

WP-Optimize: načapaný optimalizátor Lighthouse skóre#

V roce 2022 vývojář Gijo Varghese zveřejnil screenshot pluginu WP-Optimize, kde je vidět, že JavaScript se na stránce načte jenom tehdy, když prohlížeč není Lighthouse, GTmetrix, headless Chrome nebo Pingdom.

V ukázce z WP-Optimize je vidět kód, který se snaží detekovat Lighthouse, Pingdom nebo GTmetrix.

Výrobce tohoto pluginu pro optimalizaci WordPressu obvinění veřejně odmítl. Prý jde o specifické nastavení „Defer using JavaScript“.

Dobře, ale proč tam toto nastavení vlastně je? Jsme zpátky u toho, že takový setup žádný optimalizátor rychlosti neudělá. Obecné tipy k rychlosti na WordPressu máme v optimalizaci WordPressu.

WP Rocket: hranice, kde končí optimalizace#

Podobný problém má i známý optimalizační plugin WP Rocket. I ten obsahuje funkci s nevinným názvem Delay JavaScript Execution. Zapnete zatržítko a všechny skripty počkají, až uživatel posune stránku, klikne nebo se dotkne obrazovky.

Podrobnosti psal už v roce 2021 Alexander Goller v článku, kde tento problém oprávněně přirovnává k emisnímu skandálu Dieselgate, kdy automobily Volkswagen měnily nastavení motoru při emisních testech tak, aby splnily požadované hodnoty.

Jaký je stav dnes? Toto nastavení ve WP Rocket stále existuje. WP Rocket na stránce k nastavení odložení JavaScriptu píše jen to, že jde o jednu z nejvýkonnějších optimalizací.

Nevinné jedno nastavení pluginu? Nemyslím si. Nikde na stránce funkce totiž WP Rocket nepíše, co tohle udělá s Lighthouse skóre. A to je problém.

WP Rocket píše jen o výhodách nastavení „Delay JS execution“, ale už nezmiňuje rizika.

Takže WP-Optimize i WP Rocket stále tuto vlastnost prodávají, aniž by upozornili na to, že může uměle navýšit Lighthouse skóre a na další rizika, o kterých jsem psal výše.

Website Speedy: vylepšení rychlosti nebo Lighthouse skóre?#

Website Speedy je nástroj pro několik různých platforem, který o sobě prohlašuje, že je „Automatic Website Speed Optimizer“. Jeden náš klient tomu uvěřil a tento doplněk dlouhé měsíce používal v domnění, že tím pomáhá rychlosti webu.

Kolega Michal Matuška však přišel na to, že i tento doplněk může jen uměle navýšit Lighthouse skóre. Posuďte sami.

Website Speedy na homepage slibuje vliv na bounce rate a SEO rankingy.

Naše pátrání kolem Website Speedy#

Začíná to už samotným webem, kde se na jednu hromadu dává „vliv na byznysové metriky“ a „Lighthouse skóre“. Rychlost má určitě na byznys vliv, ale toto nelze propojit se syntetickou metrikou.

Už samotný marketing těchto rozšíření totiž spoléhá na uživatele, který věří, že Lighthouse skóre je rychlost webu. A že jich je hodně.

Sami autoři Website Speedy to v komunikaci s námi přiznávají:

„Our dashboards and documentation currently lead with lab scores, and we do not spell out that lab results can differ from what real users experience.“

Ve zdrojovém kódu Website Speedy jsme našli detekci testovacích nástrojů#

Kolegovi Michalovi chování Website Speedy nedalo a chtěl se pustit do zkoumání zdrojového kódu. Ten je velmi silně obfuskovaný, tedy záměrně znečitelněný.

V kódu jsme po rozkódování přes několik AI agentů našli podmínku, která rozhoduje, jestli se JavaScript na webu vůbec spustí. A co myslíte? Ano, nespustí se, pokud detekuje testování rychlosti.

Před publikací jsme se Website Speedy zeptali na jejich postoj. Zakladatel Ishan Makkar odpověděl velmi rychle:

„Our script does not detect or branch on Lighthouse, PageSpeed Insights, GTmetrix, headless browsers, or any synthetic testing environment.“

Dodal, že osobně prošel kód na několika živých zákaznických webech a naše zjištění nedokázal reprodukovat. A nabídl nám čisté demo se svou aktuální produkční verzí, ať si to ověříme sami.

Demo přišlo 18. srpna. Kolega Michal Matuška v jeho skriptu našel tohle:

Kousek kódu z dema od Website Speedy. Hack před námi schovali.

Funkce se jmenuje isAuditBot, tedy „je to auditní robot“. Hned první řádek vrací false, takže se v demu, které nám poskytli, celá detekce nikdy neprovede. Ve skriptu z webu našeho klienta vypnutá nebyla.

Mimochodem, v tom mrtvém zbytku kódu se testují řetězce, které nápadně připomínají názvy nejčastějších syntetických měřících nástrojů, tedy GTmetrix, Lighthouse, PageSpeed, WebPageTest a Headless Chrome.

Jako důkaz neviny jsme dostali instalaci, ve které byla detekce testovacích nástrojů odstrojena tou nejrychlejší možnou cestou.

Co se stalo, když jsme vypnuli Website Speedy na webu klienta?#

S klientem jsme se dohodli na dočasném vypnutí Website Speedy. Vidíme tedy docela přesně, co se s rychlostí stalo, když plugin přestal fungovat. Skoro nic.

Lighthouse skóre se sice razantně zhoršilo…

Změna Lighthouse skóre homepage po vypnutí Website Speedy.

Po vypnutí Website Speedy se Lighthouse skóre na homepage změnilo z 95 bodů na zhruba 60. Zhoršilo se? Ne, normalizovalo.

Vliv na Core Web Vitals ale vypnutí pluginu nemělo žádný:

Vývoj Core Web Vitals po vypnutí pluginu Website Speedy.

Nevidíme žádnou změnu kromě jiných vlivů, které na webu probíhají:

• Mírné zhoršení rychlosti webu (LCP) koreluje s výkyvem TTFB (odezva backendu).
• CLS se zlepšuje úpravou jiné vlastnosti webu a časově nesouvisí.
• Je dobré připomenout, že CrUX data od Googlu ukazují 28denní kumulativní stav, takže změny se projevují delší dobu.

Po vypnutí Website Speedy došlo na webu našeho klienta k normalizaci Lighthouse skóre. Ale rychlost webu zůstala beze změny.

Naše metodika a co netvrdíme#

Abychom byli fér, měli bychom si v případě našeho pátrání kolem Website Speedy ujasnit metodiku:

• Website Speedy si nepřeje zveřejnění zdrojového kódu pluginu, proto zveřejňujeme jen zdrojový kód dema, které nám poskytli a které se od zdrojáku pluginu liší.
• Experimentovali jsme na webu jednoho z našich klientů.
• Nemáme zde kvantitativní data z více projektů.
• Vypnutí pluginu a naše zkoumání kódu proběhlo v červenci 2026.
• Mimo vypnutí pluginu jsme na webu nic dalšího neoptimalizovali.

Plugin Website Speedy u našeho klienta držel Lighthouse skóre vysoko, aniž by to reálným uživatelům přineslo měřitelně rychlejší web.

Jeden problém je tedy v autorech pluginů. Ale ten větší je v samotných uživatelích, kteří za tyto pluginy platí.

Lighthouse nezahazujte. Jenom z něj nedělejte cíl#

Používejte nástroj Lighthouse jako diagnostiku. Najde vám pomalý obrázek, zbytečně velký balík JavaScriptu nebo blokující CSS. Pro tyhle účely je Lighthouse skvělý.

Rychlost webu? Dívejte se na Core Web Vitals. Tečka.

Jako hlavní byznysové metriky pro rychlost webu sledujte data od skutečných uživatelů. Core Web Vitals z Chrome UX Reportu nebo data z vlastního měření (RUM). Sledujte celou doménu a nejdůležitější šablony v monitoringu, ne jednu URL jednou za čas.

Víme, že poptávka po jednom skóre na všechno je velká, v PageSpeed.ONE proto používáme také naše vlastní Skóre PageSpeed.ONE, postavené nad uživatelskými daty metrik Core Web Vitals.

V našem jednorázovém testu rychlosti webu také Lighthouse skóre upozaďujeme, co to jde. Naopak ukazujeme trend Core Web Vitals a slovní zhodnocení stavu rychlosti.

Pokud chcete podobný případ ověřit sami, pomůže následující postup.

Jak prověřit podezřelý skok v Lighthouse skóre#

Checklist, jak odhalit podezřelé hackování Lighthouse skóre:

• Začněte otázkou, jestli skóre nevyskočilo podezřele rychle po instalaci pluginu nebo po jedné změně konfigurace.
• Porovnejte síťové požadavky a spuštěný JavaScript v Lighthouse s běžným načtením v prohlížeči.
• Ověřte první scroll, kliknutí, cookie lištu, otevření filtru, formulář i checkout. Lighthouse nescrolluje ani nekliká, ale uživatel ano.
• Zkontrolujte data od uživatelů (CrUX nebo RUM) před změnou a po ní. Zelenější laboratorní skóre bez zlepšení uživatelských dat není výhra.
• A hlavně: přestaňte kupovat pluginy, které slibují zázračné zrychlení na jedno kliknutí.

Až vám příště někdo nabídne plugin, který zázračně zvedne skóre za pět minut, zeptejte se ho na jednu věc:

Jaký vliv bude mít na reálnou rychlost u uživatelů, například Core Web Vitals? Pokud vám na tuhle otázku neumí odpovědět, znáte odpověď sami.

Mějte rychlé weby. A měřte rychlost správně.

Tagy:Rychlost webuLighthouse