Magazín ze světa digitálního marketingu
Pozadí vlevo Pozadí vpravo

Optimalizujte rychlost svého webu pomocí jednoho řádku v kódu!

Že je rychlost načítání webu důležitá pro SEO, není žádná novinka. Technik na zrychlení načítání je mnoho, málokdo však zná a využívá preconnect, prefetch a prerender. Pokud dobře znáte svůj web a chování uživatelů, právě tyto techniky mohou načítání výrazně zrychlit.

Chrome UX report

Chrome UX report je databáze od Googlu, která ukládá data z prohlížeče Chrome a používá metriky v ní uložení při řazení výsledků vyhledávání. Jednou ze zásadních metrik je právě rychlost načítání. Při hodnocení rychlosti se zohledňují například tyto faktory (oficiální google dokumentace):

First contentful paint

Čas od navigace (přechodu) na stránku po vykreslení prvního obsahu (text, obrázky).

DOMContentLoaded

Čas, kdy byl poprvé načten DOM (Document Object Model).

Právě tyto metriky se vám podaří díky preconnect, prefetch nebo prerender „ošálit“. Jak?

Komunikace mezi prohlížečem a cílovým serverem

Abyste správně pochopili, jak to celé funguje, musíte vědět, co se děje na pozadí po zadání URL.

V první fázi se přeloží doménové jméno z adresního řádku (např. www.facebook.cz) na IP adresu cílového serveru (157.240.30.35). O to se stará DNS server. Prohlížeč tedy pošle požadavek s doménovým jménem na DNS server. Ten ho buď má uložené a rovnou vrátí odpověď v podobě IP adresy, nebo se dotáže dalšího DNS serveru. Následně informaci uloží k sobě, poté vrátí IP adresu.

V momentě, kdy váš prohlížeč obdrží IP adresu serveru, zahájí s ní komunikaci.Váš prohlížeč se tedy dotáže pomocí GET požadavku na cílovou stránku či zdroj. Server požadavek zpracuje a v případě, že požadovaný soubor nalezne, vrátí ho zpět.

Celý proces je hezky rozkreslen na obrázku č. 1.

Image Co se děje po zadání URL
Obrázek 1 – co se děje po zadání URL (massivetechinterview.blogspot.com)

Před tím, než začne prohlížeč komunikovat se serverem a stahovat jakékoliv zdroje, musí s ním tedy navázat spojení. Jedná se například o tzv. DNS lookup, TCP handshake nebo v případě šifrovaného spojení TLS negotiation. Teprve pak může stahovat zdroje nutné pro načtení stránky.  Připojení lze navázat pouze jednou pro každou doménu. Není tedy nutné ho znovu navazovat po každém stažení zdroje.

Preconnect

Díky preconnectu můžete prohlížečům označit externí domény, pro které chcete vytvořit spojení ještě před stahováním zdroje. Například:

  • Na vašem webu máte videa z domény youtube.com.
  • Do hlavičky zdrojového kódu stránky dáte následující řádek:
<rel="preconnect" href="https://www.youtube.com">
  • Uživatelům, kteří začali číst článek, na kterém je umístěné video, se video a jeho náhledový obrázek zobrazí o něco rychleji. Vyhledávač totiž s doménou youtube.com již navázal spojení a může tak rovnou začít stahovat zdroje.

Na obrázku č. 2 můžete vidět, jak preconnect funguje v praxi pro urychlení stažení Google fontů (v tomto případě ušetřil 47 ms):

preconnect
Obrázek 2 – preconnect (zdroj: https://www.igvita.com/2015/08/17/eliminating-roundtrips-with-preconnect/)

Podpora preconnect

Na obrázku č. 3 se dozvíte, jaké prohlížeče a jaké verze těchto prohlížečů podporují preconnect:

prohlížeče podporující preconnect
Obrázek 3 – prohlížeče podporující preconnect (zdroj: caniuse.com)

Obrázek 3 – prohlížeče podporující preconnect (zdroj: caniuse.com)

Příklad preconnect v kódu:

<link rel="preconnect" href="https://ir.ebaystatic.com">

DNS-Prefetch

DNS-prefetch funguje podobně jako preconnect. Rozdíl je však v tom, že se provede pouze DNS lookup. TCP handshake a TLS negotiation se tímto neřeší. V případě preconnectu tedy dojde ke znatelnějšímu urychlení. Výhodou dns-prefetch je to, že ho podporují některé prohlížeče, které preconnect nepodporují (zejména IE). Použití se neliší. Jediná změna nastává v záměně atributu rel=“preconnect“ za rel=“dns-prefetch“.

Jakou variantu tedy použít?

Doporučujeme využít obě varianty s tím, že preconnect uvedeme na stránce jako první. Díky tomu si zajistíme časovou úsporu alespoň za dns-lookup, v případě že uživatel přijde z prohlížeče, který nepodporuje preconnect, ale podporuje dns-prefetch. V opačném případě se provede preconnect a dns-prefetch se odignoruje.

Podpora dns-prefetch

prohlížeče podporující dns-prefetch
Obrázek 5 – prohlížeče podporující dns-prefetch (zdroj: caniuse.com)

Příklad dns-prefetch v kódu:

<link rel="dns-prefetch" href="https://ir.ebaystatic.com">

Prefetch

Prefetch se používá pro předčasné stažení zdrojů, které předpokládáte, že bude potřeba pro načtení další stránky. Čili pokud uživatel navštíví vaši hlavní stránku a vy na základě dat z Google Analytics víte, že 50 % uživatelů se v dalším kroku proklikne na stránku ceníku, dává smysl z této stránky přednačíst zdroje. Typickým příkladem může být například několikadílný návod. Člověk, který přečte první díl, bude s velkou pravděpodobnostní pokračovat druhým dílem. Pro lepší představu:

  • Nacházíte se na URL A, ze které uživatelé často odcházejí na URL B.
  • V kódu na URL A označíte zdroje z URL B pomocí prefetch.
  • Jakmile uživatel přijde na URL A, v pozadí se mu začnou stahovat označené zdroje do cache (mezipaměť).
  • Při prokliku na URL B budou zdroje přednačtené a k načtení URL B tak dojde rychleji.

Například ebay.com (https://www.ebay.com/deals/trending/all) používá prefetch pro přednačtení gifu, který signalizuje, že se část stránky načítá (klasické točící se kolečko). V momentě, kdy kliknete na načtení dalších produktů se gif ukáže okamžitě. V kódu to vypadá takto:

<link rel="prefetch" href=https://ir.ebaystatic.com/pictures/aw/pics/express/images/imgLoading.gif>

Jakmile navštívíme stránku s produkty, gif se přednačte a uloží se do cache paměti.

požadavek na prefetchovaný zdroj
Obrázek 5 – požadavek na prefetchovaný zdroj

Kdyby se gif nepřednačítal, trvalo by skoro vteřinu (709 ms), než by se zobrazil.

Podpora prefetch

prohlížeče podporující prefetch
Obrázek 6 – prohlížeče podporující prefetch

Prerender

Jak už napovídá název, prerender by měl něco předem renderovat. Je tomu ale opravdu tak? Dnes záleží především na prohlížeči, který používáte.

Prerender v Google Chrome dříve

Prerender v Google Chrome v minulosti opravdu fungoval tak, že v případě, že jste se nacházeli na URL A, na které byl prerender na URL B, zdroje URL B se stáhly a celá stránka se předem vykreslila na skryté záložce. V momentě, kdy jste klikli na odkaz na URL B, záložky se vyměnily a došlo v podstatě k okamžitému zobrazení. Celý tento proces byl však velice náročný na paměť.

Prerender v Google chrome nyní

Od verze 63 přišel Google Chrome se změnou, kdy k rel=“prerender“ začal přistupovat jako tzv. NoState Prefetch. U takto označených URL již nedochází k vykreslování stránky, ale pouze ke stažení zdrojových kódů (html, css, js) do cache paměti.  Oproti klasickému prefetch tak nemusíte označovat zvlášť jednotlivé zdroje. Nevýhodou je stažení pouze samotných zdrojových kódů.

Budoucnost prerenderu v Google chrome

Zajímalo nás, jak to s prerenderem v Google chrome bude v budoucnu, a tak jsme se zeptali přímo v Googlu:

Yes, as far as I’m aware Google Chrome will use NoState Prefetch in place of prerender. I recommend prefetch over prerender. Prefetch has more browser support. Additionally, Chrome is planning on deprecating prerender eventually.“

– Tajný zdroj pracující v Google

Vyplývá z toho, že do budoucna plánuje Google podporu prerenderu v Chromu úplně vypnout. Bylo nám tedy doporučeno používat raději prefetch. My si však myslíme, že přesto bude stát za to, programátorsky ošetřit, aby byl prerender nasazen pro prohlížeče, které jej podporují, a pro zbytek využít prefetch.

Ostatní prohlížeče

Co se týče ostatních prohlížečů, prerender podporuje pouze nejnovější Internet Explorer a Opera. Zde stále dochází k celkovému vykreslení stránek v pozadí a načtení je tak téměř okamžité. Firefox zatím s podporou prerenderu zaostává.

Dá se předpokládat, že kombinace IE + Chrome + Opera již pokrývá většinu uživatelů internetu. Před nasazením prerenderu však přesto doporučujeme ověřit v Google Analytics, jestli i ve vašem případě opravdu většina uživatelů přichází z prohlížečů, které prerender podporují a má cenu prerender nasadit.

Prerender v Google SERPu

Velice zajímavé je, že Google začal prerenderovat výsledky s vysokou pravděpodobností prokliku v SERPu. Již dříve prerenderoval některé AMP výsledky na mobilu. V poslední době se však prerender objevil i na desktopových zařízeních. Většinou se jedná o brandové dotazy, kde je veliká šance, že uživatel klikne právě na daný výsledek, není to však podmínkou.

výsledek na ne-brandový dotaz
Obrázek 7 – Prerenderovaný výsledek na ne-brandový dotaz (červeně je označen prerenderovaný výsledek)

V případě, že je váš výsledek prerenderovaný Googlem, máte pravděpodobně vyhráno. Znamená to, že vaše CTR je natolik vysoké, aby Google předpokládal, že právě na váš výsledek se s největší pravděpodobností uživatel proklikne.  Jestli je nějaký výsledek prerenderovaný, zjistíme z kódu přímo na stránce SERPu. Stačí přes CTRL+U a pak CTRL+F vyhledat „prerender“. Anebo čtěte dále, rozhodli jsme se vám to ulehčit a vytvořili jsme doplněk do prohlížeče Google Chrome. ☺

Naopak zvažte, jestli má smysl vytvářet obsah optimalizovaný na dotaz, na který již Google někoho prerenderuje, protože prerenderovaný výsledek pokrývá drtivou většinu prokliků. Minimálně může tato informace posloužit pro určení priorit při tvorbě vstupních stránek.

Pokud ani na brandový dotaz váš výsledek není Googlem prerenderovaný, může to pro vás být signál pro optimalizaci snippetu.

Test funkčnosti prerenderování v Google Chrome

Pro test jsme si vybrali dotaz „alza“, který samozřejmě Google prerenderuje.

prerender na dotaz "alza"
Obrázek 8 – prerender na dotaz „alza“

V pozadí díky tomu došlo k odeslání požadavku na přednačtení zdrojů.

požadavek na zdroje Alza.cz
Obrázek 9 – Požadavek na zdroje Alza.cz (informace z doplňku Web Sniffer pro Google Chrome)

V nástroji ChromeCacheView jsme si nechali zobrazit obsah cache paměti Chromu (předesílám, že jsem cache předem smazal, takže data nemohou pocházet z historické návštěvy).

obsah cache paměti
Obrázek 10 – obsah cache paměti

Z obrázku je jasně vidět, že stačila pouhá návštěva SERPu s prerenderovaným výsledkem a bez jakékoliv návštěvy webu alza.cz se do cache uložily zdroje.

To, že je stránka prerenderovaná, se dozvíme také ve Správci úloh Chromu.

prerender ve Správci úloh
Obrázek 11 – Prerender ve Správci úloh

Děkujeme Filipu Podstavcovi (Marketing Miner) za čas vynaložený ke konzultacím, který nám v průběhu testování prerenderu věnoval.

Podpora prerender

Podpora prerender
Obrázek 12 – Prohlížeče, které podporují prerender

Dárek od nás na automatickou identifikaci resource hintů na webu

V Taste Medio se snažíme si co nejvíce ulehčit práci a otevírat zdrojový kód pro identifikaci resource hintů při každé návštěvě či hledání, by moc efektivní nebylo. Proto jsme napsali doplněk pro Google Chrome, který přítomnost jakéhokoliv z hintů na stránce identifikuje.

V případě prerenderu navíc vyznačí všechny odkazy vedoucí na prerenderovanou stránku. Rozhodli jsme se o doplněk podělit i s vámi. Jestliže o něj máte zájem, můžete ho stáhnout zde ☺.

 

Jak lze „resource hinty“ zapsat v kódu?

  • Do HTML hlavičky stránky pomocí značky <link>

<link href=URL stránky/zdroje' rel='preconnect/prefetch/prerender'>

 

  • V HTTP hlavičce

Link:URL stránky/zdroje; rel=preconnect/prefetch/prerender;

Připravujeme případovou studii!

Zajímá vás téma zrychlování přechodu mezi stránkami? Připravujeme pro vás případovou studii, ve které nastíníme, jak konkrétně jsme resource hinty implementovali a co nám to reálně přineslo. Můžete se tedy těšit na pokračování článku!

Závěr

Je škoda, že techniky na přednačítání zdrojů u nás nejsou příliš rozšířené. Myslíme si, že by si zasloužili mnohem více pozornosti. Existuje X scénářů, ve kterých má jejich použití obrovský potenciál pro zlepšení uživatelského prožitku. Na závěr přikládáme komentář předního českého SEO Specialisty – Filipa Podstavce:

„Přednačítání zdrojů, na které bude uživatel přecházet, je za mě velmi efektivní strategie, která vede k mnohem spokojenějším uživatelům. Webmasteři by se měli přestat zamýšlet pouze nad rychlostí načtení hlavní stránky od nuly (bez cache), ale začít řešit především dobu přechodů mezi stránkami a optimalizovat tak uživatelskou zkušenost při konzumaci jejich obsahu.“ 

Vaši snahu o lepší uživatelský prožitek pomocí resource hintů zaručeně ocení jak vaši uživatelé, tak i samotný Google, který vás navíc pravděpodobně ocení plusovými body ☺

Sdílejte článek

Související články