Optimalizace rychlosti webu – základní postupy pro zrychlení

Rychlost webu je základ

Když se někdo proklikne na váš web a několik sekund to vypadá, že se nic nenačítá a neobjevuje, tento člověk pravděpodobně prostě odejde a bude si myslet, že vám web prostě nefunguje. Dnes je potřeba, aby se vše načetlo, nebo alespoň bylo znát, že se něco načítá, v řádu desetin sekund, naprosté maximum jsou pak velmi nízké jednotky sekund.

Weby prostě musí dnes být svižné a rychlé, jinak to nejde. Existuje řada studií nebo pokusů, kdy se zvýšila doba načítání webu třeba jen o desetinu sekundy, ale prodeje klesly i o procenta nebo i desítky procent. Samozřejmě když se pak web načítá dlouhé sekundy, tak na to nikdo nemá moc nervy a jednoduše odejde.

Rychlost webu není klíčová jen pro čtenáře, ale jde o jeden z velmi rozhodujících faktorů, když jde o hodnocení našeho webu vyhledávači. Tento technický SEO faktor je vážně zásadní vyřešit. Podíváme se na problematiku trochu více zeširoka. Pro optimalizaci rychlosti webu je totiž potřeba vědět, jak prohlížeče stránky vytvářejí a jak se stahují jednotlivé zdroje, což nám pak pomůže lépe zhodnotit, jak bychom měli postupovat, aby byl náš web co nejrychlejší, a čtenáři i vyhledávače byli spokojeni.

Jak měřit rychlost webu

Ideální je se na web prostě podívat 😀 Je ale pravda, že pokud jsme na vysokorychlostním internetu, tak řadu věcí nepoznáme, protože se i velké obrázky nebo celkově objemný kód načtou hodně rychle.

Můžeme si v prohlížeči nastavit, že chceme simulovat pomalejší připojení, což nám pak ukáže, jak se náš web zobrazuje třeba lidem na 3G připojení, což nám řekne více o tom, co trvá a s čím je možná potřeba něco dělat, ať už z hlediska lepšího kódování nebo umístění někam jinam do kódu.

Takto uměle zpomalit internetové připojení můžeme v Google Chrome zmáčknutím Ctrl + Shift + I, a poté:

Za mě je nejsnazší a mnohdy nejpřesnější využít nástroje, které se na web podívají a zkontrolují, co by šlo vylepšit, a rovnou nabídnou seznam příležitostí, kde je ohledně optimalizace rychlosti prostor ke zlepšení.

Za mě jsou nejlepší nástroje GTMetrix, Pingdom Tools a PageSpeedInsight. Všechny tyto nástroje jsou zadarmo, bez registrace, a prostě jen vložíte URL stránky, kterou chcete zkontrolovat. Složitější je pak samotnou optimalizaci provést opravdu správně, ale snadno se tak dozvíte, jestli někde na webu nemáte opravdu velký fail, který je možné opravit dost snadno.

Jak prohlížeče zobrazují obsah

Nebudu tady zabíhat do vyložených detailů, protože to není zase tak extra podstatné. Základem prakticky každé webové stránky je kombinace HTML, CSS a JavaScriptu (JS), které jsou napsány tak, aby prohlížeč chápal strukturu, umístění a vzhled prvků (o což se stará HTML a CSS) a možnost vytváření dynamických změn (typicky práce JavaScriptu).

V rámci HTML kódu můžeme v zásadě libovolně umisťovat CSS i JS, ale také odkazy na obrázky nebo další zdroje, které se postupně stahují a jsou využívány k vytvoření webové stránky, jak jí nakonec vidíme v prohlížeči.

Prohlížeč nejdříve stáhne samotný HTML kód, který postupně prochází a vykresluje webovou stránku. Některé zdroje, typicky obrázky, se začnou stahovat ve chvíli, kdy na ně prohlížeč v HTML kódu narazí, takže v praxi to pak vypadá tak, že se tyto obrázky donačtou v již hotovém stránce.

Naštěstí existuje řada metod, jak zařídit, že zdroje načtou s předstihem, tedy se nikdy nezobrazí prázdné místo, do kterého se doplní obrázek, nebo naopak že zdroje načtou až později pouze v případě potřeby, a neblokují tak klíčové zdroje, které jsou potřeba k vykreslení stránky. Na základy těchto metod se podíváme, abychom věděli, jak vlastně k optimalizaci přistupovat, a které metody naopak už jsou dnes zastaralé a vlastně mohou způsobit, že se web načítá moc dlouho.

Zastaralé metody optimalizace za časů HTTP/1

Než se pustíme do toho, co pro optimalizaci dělat, je dobré vědět, co také nedělat. Pro přenos HTML se používá protokol HTTP. Ten má ale několik verzí a neustále se vylepšuje. Dnes již zastaralá verze HTTP/1 fungovala tak, že pro stažení každého zdroje (obrázek nebo jiný soubor typu CSS nebo JS, případně cokoliv jiného), muselo být navázáno spojení se serverem, odkud se zdroj stahoval. Toto navazování spojení vždy chvíli trvá, než se ověří třeba zabezpečení, ale také než server vůbec odpoví. Tohle se dělo u každého jednoho zdroje, přestože jich třeba více pocházelo z jednoho serveru.

Optimalizace tak dříve probíhala tak, že snaha bylo o co možná nejmenší množství žádostí na server o jednotlivé zdroje. Všechny styly nebo skripty, ale mnohdy také obrázky, se kombinovaly do co nejmenšího počtu souborů, čímž se snižoval počet žádostí na server, kdy každá žádost znamenala kvůli potřebě navazování nových spojení nějakou prodlevu.

Problém tak nastával v tom, že prohlížeč musel natahat všechny zdroje, třebaže nejsou nijak důležité, a mohlo by se s nimi počkat. Například CSS se v rámci optimalizace zkombinovaly do jednoho souboru, přestože řada stylů může počkat, protože ovlivňují třeba až patičku stránky, u které se mohlo na stažení zdrojů v pohodě počkat. Každé rozdělení pak znamenalo delší čas stahování, tedy vždycky něco za něco.

Dnes naštěstí funguje další verze HTTP/2 (případně ještě novějšího a ještě efektivnějšího HTTP/3, ale princip je v tomto případě stejný), která tenhle problém odbourává. S HTTP/2 nenavazujeme neustále nová a nová spojení se stejným serverem, abychom stahovali nové zdroje. S jedním navázaným připojením stáhneme řadu zdrojů, takže tu není prodleva kvůli novým spojením.

Tohle je dost podstatný rozdíl, protože najednou ničemu nevadí, že stahujeme menší soubory, kterých je více. Mění se tak princip celé optimalizace, protože nejde o kombinování souborů, ale naopak chytré a efektivní rozdělování souborů, a načtení ve správném pořadí a ve chvíli, kdy je potřebujeme.

Jak poznat, přes jaký protokol se stahují zdroje z vašeho serveru

Ne všechny webhostingy mají automaticky zapnutý přenos přes HTTP/2 nebo HTTP/3. Vědět, který protokol je využíváme, je ovšem pro strategii naší optimalizace rychlosti webu naprosto klíčové.

Protokol naštěstí snadno zjistíme díky prohlížeči. Využijeme nejpoužívanějšího Google Chrome:

1. Spustíme Google Chrome a přejdeme na web, u kterého nás zajímá použitý protokol
2. Zmáčkneme kdekoliv na tomto webu pravé tlačítko myši a vybereme možnost Prozkoumat. Využít můžeme i klávesové zkratky Ctrl + Shift + I (měkké i)
3. Otevře se vývojářský panel. Ten je mimochodem super pro kontrolu a úpravu HTML kódu, úpravy CSS a mnoho a mnoho dalších věcí.
4. Překlikneme si na záložku Network
   
5. Refreshneme stránku (využijeme třeba zkratku Ctrl + F5)
6. V záložce Network začnou naskakovat všechny zdroje, které se načetly pro zobrazení stránky. Vidíme tu samotný HTML dokument, obrázky, styly a cokoliv dalšího, co bylo pro vykreslení stránky potřeba.

Zajímá nás teď hlavně sloupec Protocol, kde vidíme verzi HTTP protokolu. Pokud vidíme, že se soubory z našeho serveru stahují protokolem h2 nebo h2, je vše v pořádku. Pokud vidíme http/1.1, tak se vše stahuje pod zastaralým protokolem HTTP/1.

Takhle by to mělo vypadat	Takhle by to nemělo vypadat

Pokud vidíme HTT//1, je potřeba kontaktovat náš webhosting a požádat o změnu protokolu na HTTP/2 nebo HTTP/3.

Řekl bych, že právě přechod z HTTP/1 na HTTP/2 nebo 3 je opravdu zásadní při optimalizaci rychlosti webu, a co je super, v zásadě tady není co zkazit a jen musíte kontaktovat váš webhosting a o změnu požádat. Dramaticky se zrychlí načítání zdrojů vašeho webu a pro čtenáře i vyhledávače se významně zlepší dojem z celého webu.

Pokud to z nějakého důvodu nepůjde a webhosting toto odmítne nebo cokoliv, přejděte na jiný webhosting, protože tohle je vážně základ. I nejlevnější varianty českých webhostingů fungují standardně na HTTP/2, případně změnu zcela bez problému umožní.

Rychlost serveru a verze PHP

Můžete mít seberychlejší a sebeoptimalizovanější web, jakmile jste ale na pomalém serveru/webhostingu, tak se bude vše načítat pomalu. Výběr správného hostingu je prostě základ a bez tohohle se prostě nehnete. To, jaký hosting je pro vás nejvhodnější, je pak trochu složitější otázka, a záleží, co vlastně potřebujete a na jakých technologiích váš web pojede a o jak náročnou aplikaci půjde. Pokud potřebujete například přenášet videa nebo velké obrázky, bude se pravděpodobně hodit něco jiného, než když půjde o web založený hlavně na textu a článcích.

Pokud pojede váš web na WordPressu, řada hostingů nabízí na míru připravená řešení, kdy v zásadě nemusíte nic moc řešit, samotný WordPress nainstalujete přímo z administrace na pár kliknutí. To je celkem super, když nic moc nechcete řešit a chcete vše mít rychle na konfiguraci, která je ozkoušená.

Pozor ale, i Wordpress hostingy nemusejí být perfektní, a někdy jde prostě jen o lákadlo na klienty, ale ve skutečnosti hosting nijak zvlášť optimalizovaný není. Vždycky je fajn si daný hosting ozkoušet a vidět vše v praxi. V komunitě jsou chválené wordpressové hostingy WP-Hosting.cz nebo OneBit, ale ani jeden jsem upřímně nezkoušel.

Co je PHP a proč na verzi záleží

Dalším faktorem je verze PHP. PHP je programovací jazyk, který pod kapotou pohání většinu webů. Je na něm postaven třeba WordPress. PHP je ovšem v řadě verzí, kdy další a další verze jsou hlavně rychlejší a bezpečnější, ovšem také vyžadují programátorské postupy. Standard je dnes, aby webhosting podporoval PHP verzi alespoň 7.4, ideálně pak abychom si mohli verzi v případě potřeby měnit.

Tady je potřeba trocha testování, protože různé doplňky mohly být vytvořeny pro starší verze PHP, tedy je potřeba vše ozkoušet, a případně nefunkční funkce vyměnit za ty, které jsou pravidelně aktualizovány a jedou tedy na novějších verzích PHP.

Přestože starší verze PHP mohou být z hlediska rychlosti řešeny třeba stránkovou cache, o které píšu dále, rozhodně VELMI doporučuji přejít na novější verze, alespoň 7+, které jsou nejenom rychlejší, ale hlavně také bezpečnější. A pokud něco nefunguje, měla by se spíš vyřešit aktualizace nebo výměna dané funkce, než zůstat ne nižší verzi PHP. A pokud něco nefunguje, měla by se spíš vyřešit aktualizace nebo výměna dané funkce, než zůstat ne nižší verzi PHP

Minifikace HTML, CSS a JavaScriptu

Když se podíváme na zdrojový kód nějakého webu, asi chceme, aby byl přehledný a my se v něm vyznali. Tedy byl odřádkovaný, zdokumentovaný a pokud možno snadno pochopitelný. Počítač ovšem nic takového nepotřebuje. Každý zbytečný komentář v kódu, mezera nebo nový řádek je něco, co v kódu pro správné zobrazení webu nemusí být, ale jde o nějaký kód navíc, který se musí po síti přenést. Celý kód klidně může být napsán na jeden opravdu dlouhý řádek, a počítačům je to z hlediska čitelnosti úplně jedno.

To samé se týká proměnných v programování. My si je chceme lidsky pojmenovat tak, abychom jim rozuměli. Pro počítač je to ale úplně fuk, a pro něj jsou to jen nějaké textové řetězce. Co se týče webu, je ideální používat co nejméně znaků to jen jde, což se pak promítne v rychlejším webu, protože prostě není potřeba po internetu přenášet tolik dat.

Onomu ořezání a zmenšení kódu o zbytečné znaky se říká minifikace. Znovu platí, že na tohle je nejlepší využívat různé doplňky, které web minifikují automaticky. Zpravidla tohle třeba u WordPressu dělají prakticky jakékoliv optimalizační pluginy, které řeší také stránkovou cache.

Komprimace souborů

Všechny zdroje webové stránky se přenášejí přes počítačovou síť. Hodně bychom tedy měli řešit i velikost souborů. Při přenosu se používají komprimační metody, kdy je soubor zabalen do komprimovaného souboru, přenesen menší, a prohlížeč ho zase rozbalí. Častokrát je toto daleko rychlejší, než soubory přenášet v plné velikosti.

Podobně komprimujeme třeba soubory na počítači do formátů jako .zip nebo .rar. U přenosu webových stránek se používají nejčastěji komprimační metody Gzip nebo Brotli (často efektivnější metoda komprimace vyvinutá Googlem).

Zatímco Gzip komprimace je dnes (snad) naprostý standard, který je podporován na jakémkoliv webhostingu, u Brotli ještě webhosting podporovat nutně nemusí, přestože je dnes podporována všemi velkými prohlížeči.

U komprimace používané pro webové stránky je podstatné si také říci, že byla vyvinuta hlavně pro textové soubory. Tedy samotný HTML kód, CSS, JS nebo cokoliv, co je posíláno formou textu. Naopak se nehodí pro obrázky ve formátech jpg, png, dokumenty ve formátu pdf a podobné soubory, které již komprimovány byly.

Na webhostingu se tedy doporučuji zeptat, jestli je podporována Brotli komprimace, a případně jaké je potřeba podniknout kroky. U Gzip komprimace je aktivace vcelku snadná, a jen do souboru .htaccess přidejte tento kód, který instruuje server, jaké typy souborů mají být zkomprimovány:

AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml

Optimalizace obrázků

Obrázky bývají často z pohledu přenesených dat největší soubory. I jeden obrázek může mít klidně několik megabajtů, což ani při vysokých rychlostech internetového připojení není zrovna neznatelné, zvlášť když je těchto obrázků na stránce hodně.

Měli bychom řešit hned několik věcí, když jde o optimalizaci.

Formát obrázků

Obrázky na webu by typicky měly mít formát .jpg (ideální pro fotky), .png (ideální pro ilustrace), nebo dnes moderní webový formát .webp (znovu vyvinutý Googlem a podporovaný v zásadě všemi moderními prohlížeči) či ještě modernější, ale ještě ne všemi prohlížeči podporovaný .avif.

Můžeme používat i další formáty jako .svg, které se využívají jako snadno škálovatelné ikony, nebo gify, které se dají využívat hlavně pro možnost animovaných obrázků, případně využít formát base64, kdy obrázek vepisujeme v textové podobě přímo do HTML kódu, ale tím asi tak s běžnými formáty použitých na webu končíme.

Použití správného formátu obrázku má velký vliv na to, jak moc místa obrázek zabere a tedy i na celkovou rychlost webu.

Protože s podporou obrázků to někdy hapruje, existuje skvělý element picture, do kterého umístit obrázky ve více formátech, a prohlížeč si pak prochází postupně formáty obrázků, a pokud nějaký formát nezná, tak prostě využije jiný, který již zná. Takto se pak dají velmi rychle využívat i vyloženě moderní formáty, kdy prohlížeče, které je podporují, je využijí, a které prohlížeče je neznají, tak zobrazí nějaký standardnější formát typu jpg nebo png. Více o elementu picture i s příklady najdete tady.

Rozměry obrázků

Pokud používáme obrázky, měli bychom používat správné rozměry. Obrázek v HTML kódu můžeme načíst třeba v plné velikosti 1000x700px, ale uměle ho zmenšit na velikost třeba 300x200px. Prohlížeč obrázek sice opravdu zobrazí menší, ale musí nejdříve stáhnout obrovský soubor, který je násobně větší než malý obrázek, který je reálně potřeba.

Redakční systémy typicky tohle řeší za nás tak, že po nahrání obrázku do systému se z obrázku automaticky vytvoří verze v různých rozměrech, které se následně využívají na webu v různých prvcích, a že se tedy nenačítají obrovské soubory.

Když řešíme rozměry obrázků, v HTML kódu bychom měli vždy definovat, jak velký obrázek zobrazujeme. Tedy zahrnout atributy width a height. Třeba:

<img src="obrazek.jpg width="500" height="300">

Všimněte si, že se do atributů nepíše rozměr (tedy třeba 500px), ale pouze číslo. Samotný rozměr, který píšeme do atributů, je vždy v pixelech, ale ono px tam nepíšeme.

Prohlížeč pak podle těchto atributů rovnou ví, kolik místa má pro obrázek na stránce vyhradit, a nedochází k podivným posunům obsahu, kdy by obrázek po načtení odsunul obsah, ale na stránce se vyhradí místo o rozměrech atributů width/height, do kterého obrázek doskočí, až se stáhne. Na webu pak můžeme poklidně scrollovat, a nestane se, že třeba uživatel někam chce kliknout, ale obrázek mu ono místo na kliknutí odsune jinam, nebo se čtenář překlikne úplně jinam, než původně chtěl.

K obrázkům bychom tak vždy měli tyto atributy přidávat a poté načítat obrázek ve správné velikosti. Neměli bychom tedy do rozměrů 200x100px načítat obrázek 2000x1000px. Systém by měl z tohoto velkého obrázku vytvořit obrázek s korektními rozměry, a do tohoto menšího prostoru pak načítat ten, než aby načetl obrázek obrovský, a jen ho pak uměle zmenšil samotný prohlížeč.

Komprimace obrázků

Komprimace obrázků v zásadě o něco sníží kvalitu samotného obrázku, ale může i velmi razantně snížit velikost souboru. Můžete také komprimovat bezztrátově, tedy že kvalita obrázku bude do posledního pixelu zachována, ale soubor se typicky zase tolik nezmenší.

Pokud zrovna nemáte web založený na perfektních fotkách, nějaká míra ztrátové komprimace je typicky zcela ok a rozhodně byste měli mít na svém webu nějaký mechanismus, který obrázky optimalizuje při nahrání. Tohle je zrovna taková věc, u které je nejlepší jednou jí nastavit, a pak na vše zapomenout.

Lazy Loading

Hodně užitečná věcička. Lazy Loading (nejen obrázků) načítá zdroj až ve chvíli, kdy je opravdu potřeba. Pokud se nějaký obrázek nachází na spodní části stránky, není potřeba ho vlastně stahovat, dokud uživatel do spodku stránky nesjede. Tomuto opožděnému načítání obrázků se říká právě Lazy Loading.

Správné nasazení se řešilo různě, ale dnes naštěstí Lazy Loading podporují nativně přímo všechny větší prohlížeče, nebo minimálně brzy podporovat budou. Z našeho pohledu je potřeba u obrázků nasadit atribut loading=“lazy“, který prohlížeči říká, že daný obrázek se má načítat až ve chvíli, kdy je třeba. Vypadá to třeba takto:

<img src="pejsek.jpg loading="lazy" width="500" height="600">

V zásadě je to celé, a nemusíme nic dál řešit nebo instalovat nějaké lazyloadovací javascriptové knihovny nebo něco podobného. Pokud zrovna někdo přijde na náš web a používá velmi starý prohlížeč, obrázek se stále načte, jen ne za pomocí Lazy Loadingu.

Cache

Cache si můžeme představit jako data, která jsou zkopírována a uchována pro pozdější použití. Cache existuje hodně druhů, ale my se podíváme jen na cache, která je podstatná při prohlížení webu, a se kterou můžeme reálně něco udělat, když nám jde o zrychlení našeho webu.

Cache v prohlížeči

Některé soubory, které si prohlížeč stáhne, jsou uloženy v počítači, a prohlížeč je dále využívá bez jejich dalšího stahování. To ušetří spoustu přenosů souborů, které jsou na každé stránce onoho webu stejné. Typicky jde třeba o logo webu, fonty, ale i řadu obrázků. Proto při návštěvě webu poprvé trvá načítání o něco déle – vše se musí stáhnout, zatímco při proklikávání už je vše svižnější – prohlížeč využívá již stažené zdroje. Tomuto se říká Browser cache, tedy cache v prohlížeči.

Tohle vše se z pohledu uživatele víceméně děje v režii prohlížeče. Z pohledu majitele webu je ovšem potřeba prohlížeči říci, jak dlouho by měl dané zdroje uchovávat, než je má stahovat znovu. Uživatel, který si někdy smaže cache, může normálně dále na web přijít, ale prohlížeč znovu vše stáhne.

Nastavení je zase celkem snadné a do .htaccess můžete přidat následující kus kódu, který je vzatý přímo z GTMetrix, tedy testovače rychlosti webu. Fonty, obrázky nebo videa si mže prohlížeč držet v cache rok, styly a skripty měsíc. Můžete si dle libosti tyto doby měnit, pokud chcete.

ExpiresActive On
# Images
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresByType image/avif "access plus 1 year"
# Video
ExpiresByType video/webm "access plus 1 year"
ExpiresByType video/mp4 "access plus 1 year"
ExpiresByType video/mpeg "access plus 1 year"
# Fonts
ExpiresByType font/ttf "access plus 1 year"
ExpiresByType font/otf "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType application/font-woff "access plus 1 year"
# CSS, JavaScript
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
# Others
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType image/vnd.microsoft.icon "access plus 1 year"

Stránková cache

Zde je situace malinko složitější, tak to vezmu více zeširoka. Webová stránka je vždy zaslána jako HTML dokument. Ten v sobě obsahuje odkazy na další zdroje, jako jsou obrázky, skripty nebo styly, a někdy může stránka být vykreslena z naprosté většiny pomocí JavaScriptu. Základem je ale HTML.

Tento HTML dokument se ovšem prakticky jistě vytváří dynamicky za pomocí nějaké technologie na serveru, a nejde tedy o statický dokument, který si vytvoříme klidně v poznámkovém bloku. Nejčastěji jde o technologie typu PHP + databáze, ale může jí i o různé kombinace všeho možného. Pointa je, že tyto technologie ve výsledku musí vytvořit HTML dokument, který se pak zobrazuje v prohlížeči. A to, jak dokument poskládají, je dáno URL. Některé části webu jsou tak vždy stejné (logo, menu, patička stránky), jiné se mění (obsahová část stránky).

Pokud tedy navštívíme nějakou webovou stránku, server, kde se tato webová stránka nachází, vlastně podle našeho požadavku poskládá dynamicky pomocí různých technologií HTML dokument, a zašle ho prohlížeči, který ho pak přeloží a zobrazí v čitelné podobě ve formě webové stránky.

Je to praktické z toho pohledu, že pokud bychom náš web skladovali ve formě stovek nebo tisíců HTML dokumentů, jakákoliv menší změna na webu, kterou bychom na webu dělali, by se musela měnit u každého jednoho souboru. Takto můžeme měnit vše v zásadě na jednom místě, jen je to prostě kódování a programování. Zase holt něco za něco. Problém je také v tom, že ono poskládání HTML kódu serveru prostě chvilku trvá, a také server zatěžuje. Při návštěvě dané URL se musí zpracovat veškerý kód, který HTML vytváří. To jednak trvá, jednak to zatěžuje samotný server.

Řešení spočívá ve vytváření takzvané stránkové cache. Pokud někdo přijde na náš web, server pomocí nějakých svých mechanismů poskládá HTML kód. Ten to již hotový kód si pak ale uloží, a pokud někdo jiný chce vidět tuto stejnou webovou stránku, neskládá server tento HTML kód znovu, ale zašle již hotovou verzi.

Tohle má smysl, pokud je obsah webu statický ve smyslu, kdy každý uživatel uvidí na dané URL stejný obsah, respektive je mu servírován stejný HTML kód. Stránky se tedy nevytváří pro každého uživatele jiné, jako to dělá třeba Facebook nebo jiné sociální sítě podle zájmů, přidaných přátel, sledovaných stránek atp.. Standardní blog nebo magazín je statický, takže cachování má smysl.

Problém je ve vytváření této stránkové cache, kdy je prostě potřeba nějaký nástroj. Je totiž třeba řešit docela dost technických věcí, automatické mazání cache při změně obsahu atp.

U WordPressu je vše celkem hodně jednoduché, a vyřeší to pluginy zdarma jako W3 Total Cache, WP Super Cache, nebo premiový placený plugin WP Rocket.

WP Rocket mimochodem velmi pěkně řeší řadu technických aspektů, které řeším v tomhle článku, takže můžete vyřešit skoro všechny mouchy jednou ranou, přestože třeba nechcete o všem vědět perfektně a do detailu. Jen je to prostě placený plugin, který asi hned na začátku kupovat nebudete chtít, ale pokud již váš blog běží a něco vydělává, tak WP-Rocket ušetří dost času.

Optimalizace JavaScriptu

Nebudu tu úplně řešit samotnou optimalizaci z hlediska samotného napsání kódu. CSS i JS by měly být napsány efektivně, což je asi jasné. Důležité je ale také to, kdy a co se přesně načítá.

Umístění JavaScriptu

JavaScript přidává zajímavé funkce, ale umí také pěkně web zasekat. Špatně napsaný, objemný nebo umístěný JavaScript umí razantně snížit rychlost webu pro uživatele. Podíváme se na poměrně snadné metody, jak s JavaScriptem zacházet tak, aby pokud možno web nezpomaloval.

Jak bylo řečeno na začátku článku, prohlížeč si stáhne HTML kód a postupně ho začne zpracovávat. V případě obrázků si tyto zdroje stahuje souběžně s dalšími zdroji, ale u JavaScriptu to funguje jinak. Když prohlížeč narazí na nějaký soubor s JavaScriptovými kódy, tak tento soubor stáhne, všechny skripty se zpracují, a až pak se pokračuje s dalším zpracováním HTML kódu. Když tedy na začátek HTML kódu umístíme obří soubor nebo knihovnu, která se musí nejdříve zpracovat, zabijeme si kompletně rychlost webu, protože prohlížeč bude dlouho zpracovávat. Co tedy s tím?

JavaScript se někdy používá k vytvoření samotného HTML kódu, ale častěji u klasických blogů jen dodává různé funkcionalitky, které nejsou nijak důležité v první sekundě načítání webu. Proto je naprosto běžná praxe, že se JavaScript vkládá až na úplný konec HTML kódu, typicky přes zavírací </body> tag.

Acync a defer JavaScriptu

Umístění JavaScriptu na konec dokumentu je jedna možnost, kterou doporučuji, ale naštěstí existují instukce pro prohlížeč, kdy tohle není úplně nutné. Tyto instrukce jsou acync nebo defer. V kódu by pak vypadaly takto:

<script async src="skripty.js"></script>

nebo

<script defer src="skripty.js"></script>

Při klasickém načítání JS bez atributů async nebo defer, prohlížeč zastaví vykreslování HTML dokumentu, stáhne JS, spustí skripty, a až se vše dodělá, začne zase vykreslovat HTML. Atributy async a defer instruují prohlížeč, že má s JavaScriptem zacházet trochu jinak.

• Async – Pokud prohlížeč narazí na JS s tímto atributem, začne soubor stahovat, ale během stahování stále vykresluje HTML dokument. Teprve ve chvíli, kdy je JS stažen, zastaví se vykreslování HTML, zpracují se skripty v souboru, a až poté se pokračuje ve vykreslování HTML.
• Defer – JavaScript se stahuje během vykreslování HTML kódu. Samotné skripty se zpracují až ve chvíli, kdy je vykreslování HTML dokončeno.

Pěkně je to vidět na obrázku:

V praxi se až na výjimky dá říci, že je v pořádku všechen JavaScript deferovat, tedy se spustí až když je HTML dokument celý vykreslen. Super výhoda je i ta, že prohlížeč si pamatuje, v jakém pořadí na deferovaný JS narazil, a po vykreslení HTML dokumentu je spustí ve správném pořadí tak, jak byly soubory umístěny v HTML kódu. To je super třeby ve chvíli, kdy některé soubory jsou závislé na jiných (typicky si třeba nahrajeme nějakou knihovnu s funkcemi typu jQuery, a pak až náš JavaScript, který tuto knihovnu využívá – pokud je JS umístěn ve správném pořadí v našem kódu, defer se postará o to, že je knihovna korektně zpracována před dalšími skripty, které tuto knihovnu ke svému fungování potřebují).

Defer je tedy asi nejlepší způsob, jak načítat JavaScript, který není potřeba k vykreslení klíčových částí HTML dokumentu, ale který jen přidává neživotně důležité funkcionality nebo části stránky, na které se může nějakou chvíli počkat.

Oproti tomu async má tu nevýhodu, že nikdy pořádně nevíme, kdy se soubor se skripty stáhne a začne zpracovávat. To se hodí ve chvíli, kdy skripty s atributem async nejsou závislé na žádné knihovně nebo jiném JS, ale zároveň nechceme čekat na úplné vykreslení HTML, než se skripty zpracují. Běžně se tedy async využívá při zobrazování reklamních bloků. JS se stahuje a neblokuje vykreslení HTML, ale jakmile je soubor stažen, zpracuje se a reklamy se tedy zobrací co možná nejdříve, což je žádané.

Úplně v praxi tedy chceme JS umístit co nejníže v HTML dokumentu, aby stahování neblokovalo stahování jiných zdrojů + tento JS i tak opatříme atributem defer. Pokud potřebujeme, aby se JS zpracoval co nejdříve, umístíme ho podle potřeby v dokumentu a opatříme atributem async, který neblokuje vykreslování HTML během stahování, ale zpracuje se co nejdříve.

Optimalizace CSS

Protože jsme na HTTP/2, není žádané všechny styly zkombinovat do jednoho souboru, ale naopak souborů vytvořit více, a umisťovat je postupně v dokumentu podle potřeby. Není potřeba okamžitě načítat styly, které řeší vzhled úplného spodku stránky, kde ještě uživatel určitě pár sekund nebude. Naopak by to byla chyba, protože bychom stahováním a zpracováváním těchto stylů blokovali jiné zdroje, které jsou potřeba hned.

Critical path CSS

Velmi důležité jsou takzvané kritické CSS. To jsou ty styly, které jsou nutně potřeba ke správnému zobrazení stránky, kterou uživatel vidí, aniž by scrolloval myší nebo posouval obrazovkou na mobilu. Této horní části stránky se anglicky říká above-the-fold.

Tyto kritické styly je potřeba umístit co možná nevýše v HTML kódu, zpravidla někam mezi tagy <head>, protože jsou klíčové k nejlepšímu uživatelskému dojmu. Díky tomu, že jde o menší soubor nebo styly vložené přímo do HTML kódu, tak neblokují další vykreslování stránky, jako by se stalo při jednom velkém souboru se styly, který by se musel nejdříve celý stáhnout a pak až zpracovat.

Při delším stahování se blokuje vykreslení obsahu a může docházet i k různým změnám ve vzhledu, což vypadá prostě blbě. Díky kritickým stylům je první dojem ze stránky o mnoho lepší, protože je načteno jen to, co je opravdu potřeba, takže se i stránka v ideálním případě načte prakticky okamžitě.

Pozor, při generování kritických stylů je potřeba trocha testování. Existují nástroje, které jsou schopny kritické styly extrahovat, a vy si je pak můžete umístit do stránky. Ideální je ale stav, kdy tyto styly dodává přímo tvůrce webu nebo šablony, protože jsou pak tyto styly vždy snadněji udržovatelné a aktualizovatelné. Nehledě na to, že bývají přesnější a jsou schopny zacílit na všechny typy stránek, které na webu máte. Kritické styly se typicky liší třeba na homepage a na stránce se článkem.

Zbavte se přebytečných stylů a skriptů

Tohle je nešvar WordPressu a hlavně webů, které mají nainstalovaných spoustu rozšíření. Web je nakonec zasekán řadou přebytečných stylů a skriptů, což ho prostě zpomaluje. Řada těchto souborů navíc vůbec není potřeba na každé stránce.

Celkem klasický příklad je formulář pro sběr kontaktních údajů nebo obecně kontaktování redakce. Skripty a styly pro tento formulář potřebujete jen na stránkách, kde se tento formulář reálně nachází (což může být klidně jen jediná stránka webu), ale autoři daného formuláře mohou natvrdo načítat všechny skripty a styly na všech stránkách webu, ať už se na nich formulář nachází, nebo ne, což je prostě zbytečné a jen se web nafukuje a je pomalejší.

Je pravda, že je prostě jednodušší načítat vše na každé stránce, a pak nemusíte nic řešit, což ještě není taková katastrofa, když nemáte web zasekaný funkcionalitami, ale i tak je prostě čistší a pro uživatele příjemnější, že nemusí stahovat soubory, které nepotřebují, kvůli funkcím, které na stránce ani nejsou.

Jako obvykle poradím WordPressové řešení v podobě pluginu Asset CleanUp, které řeší přesně tento problém. I ve free verzi si web vyčistíte od přebytečných stylů a skriptů. Ty můžete například všude zakázat, ale vytvořit výjimku pro ty stránky, kde je potřeba, nebo naopak zakazovat stránku od stránky. Placená verze pak nabízí více funkcionalit jako detekci zařízení a následné (ne)načítání v závislosti na tom, jestli je uživatel na mobilu, tabletu nebo počítači, ale abych řekl pravdu, free verze mi přijde dostatečně dobrá a hlavně velmi přístupná i pro netechnicky zdatné majitele webu, kdy je jasně a zřetelně vidět, co zakazujeme a jaký skript nebo styl patří jakému pluginu nebo šabloně.

Přednačítání zdrojů

Pokud víme, že některé zdroje jako jsou typicky obrázky nebo fonty budeme potřebovat, můžeme prohlížeč instruovat, aby je stáhl předem, a využil je pak okamžitě. Přednačítání ze dvojsečná zbraň, u které je potřeba vybírat, u jakých zdrojů se to opravdu vyplatí, a které naopak přednačítat nechceme.

Obecně bychom měli řešit přednačtení obsahu v úplně horní části stránky, tedy above-the-fold. Typicky půjde o logo webu, úvodní obrázek a font/y použitý/é na webu. Stejně tak nemá smysl přednačítat zdroje, které na stránce nejsou použity. Tím naopak zdržujeme načítání, protože se stahuje něco, co není potřeba, a i prohlížeče budou v konzoli trochu nadávat, že nějaké zdroje nebyly použity během prvních pár sekund, a že je tedy nemáme přednačítat.

Všechny kódy umisťujeme mezi tagy <head>, kde dávají smysl. Nemá pak smysl přednačítat zdroje, na které prohlížeč stejně ihned narazí a stáhne je klasickým způsobem. Jde tedy o přednačtení zdroje, který je v kódu až někdy později, ale my bychom tento zdroj chtěli mít připravený co možná nejdříve.

Kódy pro přednačtení zdrojů mohou vypadat takto:

Přednačtení fontu:

<link rel="preload" href="arial.woff2" as="font" type="font/woff2" crossorigin>

Doporučuji uvádět i atribut type. Prohlížeč tak hned ví, o jaký formát souboru jde, a pokud tento formát nepodporuje, tak ani zdroj nestahuje. Fonty doporučuji přednačítat pouze ve formátu woff2, který je dnes podporován všemi velkými prohlížeči. Je dobré mít k dispozici i záložní formát woff pro uživatele Internet Exploreru, ovšem tento font již nepřednačítat.

Přednačtení obrázku:

<link rel='preload' as='image' href='logo.png'>

S přednačítáním to rozhodně nepřehánějte a využijte ho pouze pro zdroje, které víte, že budou velmi rychle potřeba při zobrazení stránky. Pokud budete přednačítat zdroje, které nedávají smysl, stránky si můžete dokonce zpomalit, protože bude prohlížeč řešit přednostně věci ve chvíli, kdy nejsou potřeba.

Připravení připojení k jiné doméně

Často stahujeme zdroje z jiné domény. Může jít o javascriptové knihovny/frameworky, Google Fonty nebo třeba reklamní bloky. Když stahujeme nějaký tento zdroj z cizí domény, potřebuje prohlížeč vždy navázat spojení a zdroj stáhnout. Ono navazování spojení ale chvíli trvá.

Naštěstí můžeme prohlížeči předem říci, že z nějaké domény budeme později něco stahovat, takže je možné navázat spojení předem, aby se poté pouze stáhl daný zdroj bez potřeby navazovat nové spojení.

Obecně se používají meta značky dns-prefetch a preconnect, kdy preconnect naváže kompletní spojení, ale (jako obvykle) není podporován Internet Explorerem. dns-prefetch naváže pouze část spojení, ale je podporován všemi prohlížeči.

V praxi je možné využít obě tyto značky najednou, kdy prohlížeče, které nepodporují preconnect, mohou využít alespoň dns-prefetch. Tuto praxi doporučuje i Mozilla.

Také je potřeba říci, že preconnect a dns-prefetch se používají ve chvíli, kdy víme, že z nějakého zdroje budeme stahovat, ale ještě neznáme přesnou URL, odkud zdroj stáhneme. To je právě případ třeba reklam AdSense nebo dalších reklamních programů a sítí, nebo Google Fontů.

<link rel="preconnect" href="/assets/vendor/googleapis/" crossorigin>
<link rel="dns-prefetch" href="/assets/vendor/googleapis/">

Atribut crossorigin v zásadě říká, že je zdroj možné sdílet mezi více doménami. Jako URL přednačtení zdroje si pak všimněte, že se nepíše protokol http nebo https, ale pouze to co je za ním, což pokryje jakýkoliv protokol.

Je toto všechno?

Není a nebude. Web je každý trochu jiný a vyžaduje jinou péči. Tyto rady jsou velmi obecné, ale pokud se jimi budete řídit, váš web prostě bude rychlejší, což je lepší pro vás i vaše čtenáře/zákazníky.

Výše popsané optimalizační techniky jsou velmi obecné, ale myslím, že v zásadě libovolný web je může pohodlně nasadit, a že se rychlost webu zvýší. Samozřejmě je potřeba přistupovat ke všemu situačně, což se týká hlavně umisťování CSS a JS, případně defer/async JS. Naopak neřeším věci typu, že by web měl být efektivně naprogramovaný, což beru tak nějak jako ložené, a tady by byla potřeba velmi pečlivá práce a znalost zdrojových kódů, kde je pak řešení opravdu složitější a nelze ho nijak zobecnit.

Pokud budete výše napsané optimalizační techniky nasazovat, velmi doporučuji zaprvé vše pečlivě zazálohovat, a zadruhé vše dělat postupně. Občas na něco použijete plugin, který může web trochu rozbít, kdy může přeházet styly nebo skripty, a něco pak vypadá jinak nebo nefunguje. Je dobré vždy vědět, co jste právě dělali a jestli vše funguje, než se pustíte do něčeho dalšího. Snadno pak zjistíte, co problém způsobilo, než když nasadíte 10 změn, a pak bádáte, která mohla nebo nemohla za problém, který nastal.