Audituj weby jako profesionál - Kompletní průvodce nástrojem Lighthouse pro markeťáky

Lighthouse je nástroj v prohlížeči Google Chrome, který umožňuje automatizované testování webu a webových aplikací. Kromě výkonu a použitelnosti webu umí testovat třeba i základní SEO faktory a checklist pro PWA.

Představení Lighthouse

O Lighthouse již dříve byla na blogu Marketing Mineru zmínka v rámci článku Staň se Chrome DevTools SEO ninjou! Jedná se o velice zajímavý nástroj, který si zaslouží vlastní článek s podrobnými informace o jednolivých auditech.

Nástroj provádí několik desítek testů v pěti oblastech. Jedná se o audity výkonu, Progressive Web App, přístupnosti, obecných best practice a od února 2018 i SEO. V tomto článku naleznete přehled většiny auditů, základní pokyny k použití nástroje, informace jak interpretovat výsledky a také mnoho zdrojů a checklistů pro další studium problematiky.

Lighthouse je dostupný několika způsoby. V první řadě je součástí Chrome Developer Tools v prohlížeči Google Chrome. Do Chrome DevTools se dostanete stiskem klávesy F12. Klávesovou zkratkou CTRL+SHIFT+I. Nebo kliknutím na pravé tlačítko myši a volbou Inspect. DevTools jsou nejlepší volbou a článek je primárně postavený na této metodě.

Další cesta k Lighthouse je přes stejnojmenný plugin do Chrome. Popravdě moc nevidím důvod, proč instalovat plugin pro nástroj, který už je součástí prohlížeče. Plugin má méně možností nastavení, je méně spolehlivý a může se zasekávat bez zjevných příčin. Výhodou pluginu teoreticky může být to, že dostává některé updaty rychleji. Například SEO audity byly v pluginu dostupné již v únoru. Do DevTools se ale dostaly až někdy v průběhu dubna.

Lightouse je dostupný i jako open-source a veškeré zdrojové soubory si můžete stáhnout i na GitHubu. Pokročilým uživatelům a vývojářům to umožní lepší automatizaci testování pro větší množství URL. Manuál k instalaci je k nalezení také na GitHubu. Tamtéž naleznete i Report Viewer. To je nástroj, který slouží pro prohlížení json výstupu, který nástroj generuje.

Všechny potřebné odkazy jsou uvedené níže. Pokud nejste velmi zkušení uživatelé nebo vývojáři, doporučuji začít ideálně s průzkumem Chrome DevTools. Pokud se v DevTools neorientujete nebo je nechcete používat, tak případně s instalací pluginu do Chrome.

• Lighthouse plugin na Chrome Web Store.
• Lighthouse na webu Tools for Developers.
• Lighthouse na GitHubu.
• Lighthouse Report Viewer.

Rozdíly mezi pluginem a DevTools

Mezi pluginem a DevTools jsou drobné odlišnosti. V době vytvoření článku je v DevTools Lighthouse ve verzi 2.9 a v pluginu Lighthouse ve verzi 3. Aktuální verze 3 má lepší UI a především lépe nastavené váhy některých výkonnostních parametrů a měla by tudíž poskytovat reprezantativnější výsledky. Důkladnější přehled získáte ve Scoring Guide pro Lighthouse v3. Plugin pak oproti DevTools zase nenabízí některá nastavení, která mohou s výslednými metrikami výrazně pohnout, například využití cache.

Aktualizováno: 2018-06-20. Za upozornění na nepřesnosti a doplnění informací děkuji Petrovi Havlíkovi.

Obecně platí stav, že Lighthouse plugin ani DevTools prakticky nikdy nejsou stejné a vyskytují se mezi nimi menší či větší rozdíly, které jsou zpravidla dorovnány s příchodem nové verze prohlížeče či pluginu.

Spuštění a nastavení prvního reportu

Vyberte si metodu, která vám vyhovuje více. DevTools nebo plugin. Obě možnosti mají své výhody a nevýhody. Pro přípravu textu jsem zvolit DevTools, které aktuálně poskytují širší nastavení za cenu horšího skóringu. Samotné skóre a váhu jednotlivých testů však nepovažuji za úplně klíčové metriky. V této fázi, kdy s Lighthouse začínáte jsou zásadní konkrétní nedostatky a pochopení metrik nikoliv finální bodový zisk. Ten bude důležitý až vychytáte základy a začnete testy automatizovat.

Přes Chrome DevTools si můžete report nastavit a nemusíte instalovat žádný doplněk do prohlížeče. Nastavení se vyskytuje v prohlížeči Chrome od verze 67. Můžete si vybrat jestli bude web vykreslován jako na mobilním zařízení či na desktopu. Nastavit pomalejší 3G síť. A také si zvolit zda nástroj využije nacachovaných zdrojů. Kliknutím na levé tlačítko + pak můžete zvolit oblasti auditu.

Jaké nastavení zvolíte by mělo vycházet z dat o vašem webu. Jaké vstupní zařízení používají uživatelé vašeho webu? Jak rychlé připojení k internetu? Testujte web tak, jak ho vidí většina vašich uživatelů. Potřebné informace a data zjistíte v Google Analytics. Co se týče dalšího nastavení, tak doporučuji používat Clear storage a nechat pro začátek zapnuté všechny audity, abyste viděli všechny informace.

Informace, které získáte jsou zaměřené silně technicky. Hlavním účelem auditu je debugging a optimalizace webu v oblastech výkonu, přístupnosti a PWA. Poznatky poslouží dobře především zkušeným konzultantům a vývojářům.

U každého auditu naleznete základní informace a v detailu auditu i odkaz na podrobnější vysvětlení postupy opravy nalezeného problému. Silně problematické oblasti a faktory jsou označeny červeně. Středně problematické oranžově. A zeleně ty, které auditem bez větších obtíží prošly.

Pojďme se vrhnout na testování!

Výkon

Testy a reporty v této sekci se zaměřují na výkon a rychlost webu. Výsledky vám umožní zjistit zásadní nedostatky. A Lighthouse poskytuje dostatek informací pro následující debugging. Je docela dobré se připravit na to, že výsledný report vypadá jinak a je výrazně odbornější než například z PageSpeed Insights, které jsou postavené spíše pro méně zkušené uživatele.

Naleznete zde tři podsekce. Jsou to metriky, příležitosti a diagnostika. Metriky vyjadřují výkon webu číselně - rychlost načtení, rychlostní index a podobně. Příležitosti uvádí řadu tipů a konkrétních příkladů, jak dosáhnout zrychlení webu. Například očištěním kódu od nepoužívaných CSS nebo JavaScriptů. Diagnostika jde nejvíce do hloubky a umí odhalit chybně nastavená pravidla cachování, časování JavaScriptů či špatně optimalizovanou trasu vykreslování.

Základní přehled testů výkonu

• První vykreslení, kdy je již viditelný primární obsah stránky.
• První interakce, kdy je možné stránku používat.
• Konzistentní interakce, kdy je možné stránku používat bez omezení.
• Percepční index rychlosti udává, jak rychle se stránka zaplní viditelným obsahem. Více o tomto indexu se můžete dočíst na stránce Speed Index.
• Odhadovaná latence vstupu s 90% pravděpodobností udává, jak dlouho trvá reakce na uživatelský vstup.
• Rychlé načtení prvního bajtu (Time to First Byte). Server by ideálně měl odpovídat do 200 ms.
• Styly, které nejsou používány nebo blokují vykreslení.
• Scripty, které blokují vykreslení.
• Minifikace scriptů a stylů.
• Zdroje, které využívají neefektivní cachovací politiku.
• Kritické řetězce požadavků na zdroje s vysokou prioritou.
• Nedostatky v instrumentaci JavaScriptu a tipy pro využití User Timing API.
• Vhodné škálování obrázků, komprese obrázků, využití nových obrázkových formátů (například JPEG 2000 či WebP) a využití lazy loadingu.
• Komprese textů.
• Minimalizace redirektů.
• Omezení používaných zdrojů a zatěžování sítě. Na stránce What Does My Site Cost? si můžete spočítat, kolik peněz stojí načtení vaší stránky uživatele na mobilním připojení v zahraničí.
• Udržování rozumné velikosti DOM a rychlosti vykreslování.
• Rychlost parsování, kompilace a provedení JavaScriptu.

Jak pracovat s reportem a další doporučení

Čemu věnovat pozornost, pokud jste SEO konzultanti? Zaměřte se určitě na metriky. Jsou relativně jednoduše interpretovatelné a dostačující pro účely SEO auditu. Konzultanti zběhlí v testování a optimalizaci rychlosti webu určitě využijí i navrhované příležitosti. Ale pravděpodobně se zde nedozvíte nic, co byste už nevěděli z jiných nástrojů jako PageSpeed Insights, Pingdom či GTmetrix. Informace uvedené v diagnostice jsou pak určené primárně pro vývojáře. Pokud daným informacím a výstupům auditů plně nerozumíte, tak doporučuji zdrženlivost v jejich interpretaci. Raději celý výstup předejte do rukou vývojářům.

Progressive Web App (PWA)

Jedná se o poměrně novou Google technologii (nebo možná spíše přístup), která má velkou podporu. Progressive Web App jsou weby, které mohou vypadat a mohou se chovat jako nativní aplikace. Hlavními výhodami PWA je spolehlivost, rychlost a vysoké zapojení uživatelů. Tato technologie přináší řadu výhod. Nejedná se však o nic snadného a jednoduše implementovatelného. Určitě to není vhodné pro všechny weby. O PWA začněte přemýšlet ve chvíli, kdy jste dostatečně velcí a silní hráči a zvažujete tvorbu mobilní aplikace. Důkladně konzultujte a prozkoumejte výhody a nevýhody různých řešení.

Termín progressive web apps se objevil v roce 2015 a popisoval aplikace, které využívaly výhod moderních webových prohlížečů. Hlavní technologie spojené s PWA jsou service workers (JavaScript, který běží na pozadí HTML nezávisle na jiných scriptech) a web app manifests (soubory s metadaty). Klíčové výhody jsou pak progresivita (pro všechny funguje stejně nehledě na prohlížeči či operačním systému), responsivita (přizpůsobí se všem zařízením) a nezávislost (jsou plně dostupné všude a kdykoliv, i na špatném připojení či v offline režimu).

Základní přehled testů PWA

• Použití technologie Service Worker, která umožňuje využití funkcí Progressive Web App.
• Offline aplikace vrací status kód 200. Offline funkčnost zajišťuje technologie Service Worker.
• Zobrazování výzvy k instalaci webové aplikace a její přidání na domovskou obrazovku.
• Konfigurace vlastní customizované úvodní obrazovky.
• Adresní řádek není nakonfigurován pomocí tagu <meta name="theme-color"> a neodpovídá barvám brandu.
• Aplikace není plně závislá na JavaScriptu a zobrazuje alespoň část obsahu i bez něj.
• Je používáno HTTPS a HTTP stránky jsou správně přesměrovány na HTTPS.
• Stránky se načítají rychle i na 3G připojení.
• Existuje tag <meta name="viewport"> s definovanou šířkou (width) nebo počáteční škálou (initial-scale).
• Obsah je správně škálován pro viewport. Šířka obsahu musí odpovídat šířce viewportu.

Jak pracovat s reportem a další doporučení

V první řadě se tomuto reportu věnujte až ve chvíli, kdy skutečně používáte PWA nebo se cestou PWA chcete vydat.

PWA je rozsáhlá oblast a Lightouse ji ani zdaleka nepokrývá celou, protože některé prvky není možné testovat automatizovaně. Je nutné manuální kontrola. K tomu vám pomůže oficiální PWA Checklist. Pár příkladů, abyste si udělali představu. Web musí například fungovat napříč všemi hlavními prohlížeči, přechody mezi stránkami musí být plynulé a každá existující stránka musí mít vlastní unikátní URL.

Pokud vás PWA zajímá více tak můžete začít se studiem Progressive Web Apps stránce Google Developers či MDN. Prozkoumat existující aplikace na webu PWA Rocks. Nebo sledovat novinky a inspiraci na PWA Stats. Již také existují různé nástroje, frameworky, kurzy a mnoho dalších zdrojů, které můžete využít.

PWA jsou obzvláště mocné ve spojení s AMP. Občas se používá zkratka PWAMP. Pokud některou z těchto technologií zvažujete, doporučuji k přečtení článek na oficiálním AMP webu, jak zkombinovat Accelerated Mobile Pages a Progressive Web Apps. Pro více informací určitě také navštivte web How PWAMP Works, který vybudovala Aleyda Solis.

Přístupnost

Přístupnost patří mezi jedno z nejvíce opomíjených témat. Všechny pravidla jsou kontrolovány podle aXe pravidel. Ty existují v několika verzích. Lighthouse provádí audit na základě verze 2.2.

Níže již bez odkazů uvádím jen přehled prvků, které kontroluje Lighthouse. Všechny doplňující informace a zdroje pak naleznete v uvedených aXe pravidlech.

Až si celý seznam a checklist projdete, tak pochopíte, že se nejedná o nijak zásadně komplikované téma. V drtivé většině případů je to vlastně otázkou strukturování HTML kódu a vhodném použití správných prvků. Celá tato část tedy leží primárně na kodérech a vy, jako klienti nebo specialisté, byste měli trvat na tom, aby kód webu či šablony webu, byl vytvořený kvalitně a web byl dobře použitelný pro všechny skupiny uživatelů.

Základní přehled testů přístupnosti

• Prvek <html> obsahuje atribut [lang] s validní hodnotou dle BCP 47 specifikace.
• Hodnota atributu [accesskey] musí být vždy unikátní.
• Prvky <input type="image"> musí mít vyplněný atribut [alt].
• Stránka obsahuje nadpisy, odkazy nebo orientační body, které poskytují mechanismy umožňující efektivní přeskakování obsahu a různých prvků důležitých pro vizuální rozhraní.
• Stránka obsahuje prvek <title>.
• Prvky <frame> a <iframe> mají title.
• Buňky (<td>) prvku <table> používající atribut [headers] vždy odkazují pouze na buňky ve stejné tabulce.
• Prvky <th> a prvky s atributy [role="columnheader"/"rowheader"] neobsahují buňky, ke kterým se vztahuje daný popis.
• Pole formulářů mají štítky.
• Na webech designovaných pomocí tabulek designové prvky <table> neobsahují tagy <th>, <caption> či atribut [summary].
• Prvky <object> mají definovaný atribut [alt].
• Prvky <video> obsahují tag <track> s atributy [kind="captions"] a [kind="description"].
• HTML tagy jako <dl>, <dt> a <dd> jsou správně strukturované a obsahují pouze vybrané prvky.
• [id] atributy na stránce jsou unikátní.
• Správné použití meta tagů jako je například <meta http-equiv="refresh">.
• Atribut [user-scalable="no"] není používán v elementu <meta name="viewport"> a hodnota atributu [maximum-scale] není menší než 5.
• Pozadí a prvky v popředí (například text) mají adekvátní barevný kontrast.
• Seznamy neobsahují pouze prvky <li> a prvky podporující (<script> a <template>).
• Položky seznamů (<li>) nejsou součástí prvků <ul> nebo <ol>. Jednotlivé položky jsou značkovány pomocí <li>.

Podobně jako PWA či SEO, ani přístupnost není možné obsáhnout pouze jedním automatizovaným testem. Je proto nutné provést důkladný audit, který by měl provádět odborník na přístupnost. Jak na to, se dozvíte ve článku How To Do an Accessibility Review. Níže je uvedený krátký přehledový checklist. Všechny body jsou důkladněji více popsány v uvedeném článku o auditu přístupnost.

Checklist pro manuální kontrolu

• Stránka je dobře strukturovaná, obsah logicky seřazený a stránku je možné procházet pomocí tabulátoru.
• Nikde na stránce nejsou oblasti, kde by se tabulátor zasekával a odváděl pozornost uživatele.
• Vizuální pořadí prvků na stránce odpovídá pořadí v DOM.
• Interaktivní prvky na webu je možné ovládat pomocí klávesniace.
• Interaktivní prvky jsou označeny pomocí štítkových atributů aria-label či aria-labelledby a mají přiřazeny atributy rolí jako role či aria-checked. Více viz články Introduction to ARIA a ARIA Labels and Relationships.
• Pokud se na webu v důsledku interakce zobrazí nový prvek, například text, pozornost uživatele je směrována k tomuto obsahu.
• Obsah pozicovaný mimo viditelnou část stránky je skrytý pomocí display: none či aria-hidden=true.
• Značkování nadpisů (H1-H6) dodržuje pořadí a žádné úrovně nejsou vynechávány.
• Orientační body jako <main> či <nav> v HTML5 jsou využívány pro zlepšení navigace.

Jak pracovat s reportem a další doporučení

Málokdo si zvládá představit, proč se vlastně něco jako použitelnost řeší. Často se hovoří, že třeba pořadí a struktura nadpisů H1 - H6 nemá vliv na SEO. Štítky do polí formulářů se přidávají pouze kvůli použitelnosti. Validita kódu nemá vlastně vůbec na nic vliv. A tak podobně. Z části je to pravda, ale je vhodné se na věci dívat s větším odstupem a nadhledem.

Existuje velká škála různých skupin uživatelů. Od běžných uživatelů až po ty, kteří mají různé hendikepy. Pro většinu z vás to bude asi těžko představitelné, ale i slepí lidé jsou uživateli webu. A mohou být uživateli právě vašeho webu či e-shopu. Nevidomý uživatel používá k procházení webu různé asistivní technologie, které mu navigaci v menu a obsah webu předčítají. Web musí být pro asistivní technologie vhodně strukturovaný. Za prvé, aby ho zvládly projít. A za druhé, aby ho zvládly správně tlumočit uživateli.

To je však jen jeden pohled na použitelnost. Jsou uživatelé se zrakovými vadami, pro které musí být web čitelný. Případně text musí jít zvětšit, aby ho uživatel dokázal přečíst. Text musí být dostatečně kontrastní k pozadí webu a tak dále. Jsou uživatelé s omezenou pohyblivostí, kteří se na webu potřebují přesunovat pomocí tabulátoru. Obrázek jste si snad udělali a už lépe chápete proč je vhodné použitelnost řešit. Vaše služby a produkty chtějí používat i lidé s hendikepy. Usnadněte jim to. A pište vaidní kód, protože asistivní technologie často nezvládnou rozprasovat web s takovou lehkostí, jako to udělá třeba googlebot.

Podrobnější informace můžete v češtině získat na webu Blind Friendly o který se stará TyfloCentrum. V češtině také můžete využít Pravidla pro tvorbu přístupného webu od Davida Špinara. A rozhodně sledujte i Radka Pavlíčka, který se tématu přístupnosti a asistivních technologií dlouhodobě věnuje.

Toto je především apel na kodéry a webaře. Dělejte weby použitelné a pokud možno validní alespoň do té míry, aby ve W3C testu validity nevracely žádné fatální chyby.

Best Practices

V této sekci naleznete souhrn obecnějších doporučení pro modernizaci webu. A také další tipy pro optimalizaci možných problémů s výkonem, které nebyly v Performace auditu. Jedná se o mix různých technologií a metod od základních až po pokročilé. Většinou nezařaditelné do žádného jiného auditu.

Základní přehled Best Practices testů

• Není používána zastaralá Application Cache.
• Není používán zastaralý typ databázového API Web SQL. Místo toho je doporučováno například IndexedDB.
• Web je na HTTPS. Je to doporučováno i z důvodu, že HTTPS je ranking signál.
• Web pro své vlastní zdroje využívá HTTP/2.
• Web využívá technologii Passive Listeners pro zlepšení výkonu scrollování. Technologie zajišťuje plynulejší scrollování s výrazně rychlejší odezvou.
• Ve vlastních scriptech nejsou využívány Mutation Eventy. Mimo jiné se jedná o zastaralý mechanismus monitoringu změn v DOM, která byla narazena metodou MutationObserver.
• Pro dynamický zápis externích scriptů není využíváno metody document.write(), která může výrazně zpomalit zobrazení stránky.
• U odkazů, které se otevírají v nových oknech a tabech je využíván atribut rel="noopener", který přináší velkou výhodu pro zlepšení výkonu webu.
• Hodnota property short_name u Web App Manifestu bude zobrazená celá na domovské obrazovce používaného zařízení.
• V průběhu načítání stránky nejsou vyžadovány povolení pro získání geolokačních údajů a zobrazování notifikací.
• Na frontendu nejsou používány javascriptové knihovny, které obsahují bezpečnostní nedostatky.
• Nejsou používány zastaralé API a technologie. Přehled zastaralých technologií naleznete na webu Chrome Platform Status.
• Povoluje uživatelům vkládat text do polí s hesly.
• V konzoli prohlížeče nebyly zalogovány žádné chyby. Více informací pro případný debugging naleznete ve článcích Diagnose and Log to Console a Exception and Error Handling.
• Zobrazuje obrázky ve vhodné velikosti.

Jak pracovat s reportem a další doporučení

Primárně se zaměřte na technologie, které používáte a ve kterých máte nedostatky. Využijte to také jako příležitost prozkoumat nové technologie a posunout se na vyšší úroveň. Best Practices jsou mix různých testů, které souvisí s výkonem, zabezpečením, PWA, SEO a obecně nevhodnými zastaralými technologiemi. Vše musíte zpracovat dle vlastního uvážení. Pokud něčemu nerozumíte nebo si nejste jistí, tak raději další kroky konzultujte s někým zkušenějším.

SEO

Nástroj kontroluje několik základních faktorů, které pomáhají webu v SEO. Konkrétně se má jednat o ranking faktory, ale mezi audity se nachází i položky jako meta description či title, o kterých Google dříve prohlásil, že nejsou ranking signály. Test částečně vychází z Webmaster Guidelines.

Základní přehled SEO testů

• Existence meta description a elementu <title>. Ty mimo jiné pomáhají v navigaci uživatelů na webu.
• Existence tagu <meta name="viewport"> s definovanou šířkou (width) nebo počáteční škálou (initial-scale).
• Stránka je funkční a nevrací neplatný stavový kód.
• Odkazy mají anchor texty. Ty jsou důležité pro budování kvalitní odkazové architektury webu.
• Stránka má povolenou indexaci v meta robots a X-Robots-Tag.
• Vícejazyčné weby obsahují validní hreflang atributy.
• Stránka má validní atribut rel=canonical.
• Většina obsahu je psaná fonty v čitelné velikosti, tedy 16px a více. Pokud nevíte proč právě 16px, můžete se zkusit seznámit se základy optimalizace čitelnosti textu.
• Stránka nepoužívá pluginy, což mohou být třeba různé flashové soubory či Silverlight aplikace, které jsou často nepoužitelné na mobilních zařízeních.

Jak pracovat s reportem a další doporučení

Lighthouse zběžně kontroluje i použitelnost webu na mobilních zařízeních a validuje použití strukturovaných dat. Ale doporučuje provést manuálně další testy v těchto dvou oblastech. Pro použitelnost je to Mobile-Friendly Test. Pro strukturovaná data pak Structured Data Testing Tool a Structured Data Linter.

Pokud se SEO věnujete, tak nepochybně chápete, že Lighthouse testuje jen pár prvků. A povětšinou velmi základních. Nebo téměř nesouvisejících se SEO. V žádném případě tudíž nedoporučuji, se výsledky testu nějak více řídit. Audit webu v olbasti SEO by měl probíhat úplně jinak. Pro důkladný audit je například nutné použití crawleru nebo pohled do dat v Google Analytics a Google Search Console. Lightouse v této oblasti nijak nenahrazuje práci specialisty. A ani práci specialistům pravděpodobně nijak neulehčí.

Závěrem

Plugin Lighthouse nabízí možnost rychlého a jednoduchého testování velké škály základních faktorů na webu. V žádném případě se však nejedná o komplexní technický audit, který by pokryl web v celé škále. Zvláště pak v oblasti SEO silně pokulhává. Naopak v oblastech rychlosti a použitelnosti webu je extrémně užitečný.

Jednu věc jsem nezmínil. Lighthouse popsanou metodou testuje pouze jednu URL, jednu stránku, vašeho webu. Takový výstup není 100 % relevantní. Měli byste otestovat větší vzorek stránek. Například na e-shopu homepage, stránku kategorie, podkategorie, stránku s filtrací a stránku produktu. A ideálně alespoň tři stránky od každého typu. Na každém typu stránky se mohou nacházet jiné problémy. A předtím, než se pustíte do nějakých úprav a oprav, byste měli přesně vědět co všechno je špatně. Umožní vám to lépe prioritizovat. Často se stává, že dojde k testu pouze homepage, která je pak krásně vyladěná, ale zbytek webu nefunguje, protože nikoho nenapadlo otestovat žádnou další stránku.

Co se týče SEO, tak jako hlavního SEO pomocníka doporučuji zvolit jiný nástroj. Ideální je některý z moderních crawlerů nebo Marketing Miner. Tyto nástroje vám umožní mnohem lépe, spolehlivěji a automaticky validovat větší množství URL v oblastech jako je hreflang, canonical, strukturovaná data či indexovatelnost. Lighthouse spíše takový SEOmat.

Obdobně se to týká auditu Best Practices, který je poněkud chaotický a nekonzistentní.

Nástroj je v každém případě zajímavý jako celek, protože máte možnost zjistit, které faktory jsou pro Google důležité. A především zjistit, na jaké škále se pohybují různé metriky, kdy je ještě něco přijatelné.

Pokud by pro vás byly vysoká technická úroveň a nové odborné pojmy překážkou, doporučuji se vrhnout na studium Google Developers stránky Mobile Sites, především pak sekce Mobile SEO Overview, a časem absolvovat Mobile Sites Certifikaci. S nástupem Mobile-First Indexu a většího počtu uživatelů webů z mobilních zařízení pro vás budou tyto informace v dohledné budoucnosti nedocenitelné.

Disclaimer: Článek v této chvíli neobsahuje všechny testy a audity. Text bude doplňován a aktualizován. Poslední update proběhl dne 18. 6. 2018.