Toužíte po stránkách, které jsou rychlé jako blesk? Načítají se mrknutím oka a zdá se, že vyžadují neskutečně výkonné servery? Takové můžete mít, stačí využívat osvědčených postupů pro optimalizaci.

Co v tomto článku najdete?

Cílem tohoto článku je shrnout všechny podstatné kroky v optimalizaci stránek do jednoho přehledného článku. Pokud tedy půjdete krok za krokem – na konci by vás měli čekat bleskové stránky.

I když pochopitelně stránky může brzdit více faktorů, má zkušenost je taková, že většinou za pomalostí stojí jen nevyužívání těchto věcí.

Minifikace CSS a JS

Jako první je důležité minifikovat vaše CSS a JS soubory.

Minifikace je v podstatě smazání všech zbytečných znaků, které prohlížeč pro vykreslení nepotřebuje a musí je při čtení kódu přeskakovat. Jedná se o nové řádky, mezery či poznámky.

Díky minifikaci zmenšíte své soubory a tak ušetříte datový provoz mezi serverem a prohlížečem. Díky tomu budou stránky o chlup rychlejší, protože návštěvník nebude nucen stahovat zbytečná data.

Svá CSS můžete kupříkladu minifikovat pomocí tohoto nástroje.

Pro ukázku jsem si vzal CSS soubor z jedné stránky o velikosti 19,3 kB a prohnal ho nástrojem. Výsledkem je soubor o velikosti 15,1 kB, což je o 4 kB méně. Minifikací tak bylo ušetřeno 21 % z původní velikosti.

A to samozřejmě bez změny funkčnosti.

Gzip komprese

Gzip komprese je jeden z dalších způsobů, jak posílat do prohlížeče ještě méně dat. Touto metodou se dá ušetřit klidně i 70-80 % z celkové velikosti jakéhokoliv textového souboru.

Takže takto můžete zmenšit všechny vaše HTML, CSS, JS, XML, ale i třeba SVG soubory. SVG jsou sice obrázky, ale psané v XML, jde tedy vlastně o text. Proto u nich také můžete aktivovat Gzip.

Většina stránek běží na webovém serveru Apache. V tom případě se stačí přesvědčit, zda máte nainstalovaný modul mod_deflate. Pokud ano, pravděpodobně již vaše stránky komprimované jsou.

To se dá snadno zjistit nástrojem Check GZIP compression.

Do políčka postupně zadejte vaše CSS, JS a HTML odkazy a ujistěte se, že všechny vhodné soubory Gzip používají.

Kešování na straně klienta

Kešování je druhou nejdůležitější metodou pro rychlé stránky. Kešování v pravém slova smyslu je totiž věc, která se používá doslova všude.

Stejně jako si váš počítač pamatuje nedávno zavřené aplikace, aby je za moment dokázal rychleji otevřít, stejně tak si prohlížeč pamatuje již stažené soubory, aby si tutéž věc nemusel stahovat stále dokola.

Pokud například navštívíte Interval.cz, prohlížeč si stáhne a zapamatuje všechny soubory, které mají nastavené kešování a při kliknutí na další odkaz se již nestahují, ale načítají z vašeho disku. Proto vždy načítání poprvé navštíveného webu trvá déle, než jeho pozdější proklikávání.

Na svém blogu kupříkladu kešuji i kompletně vygenerované stránky, takže otevření stejného článku podruhé je díky tomu doslova bleskové.

Odpověď na první načtení jednoho vybraného článku trvala 305 milisekund. Druhé načtení téhož článku už zabralo jen 4 milisekundy. A to právě díky kešování.

Jestliže tedy chcete tuto metodu prostudovat hlouběji, přečtěte si tento článek o kešování.

Obrázky a jejich optimalizace

Celou dobu tu byla řeč o optimalizaci textových souborů, ale na stránkách je postupem let více a více obrázků. A ne malých.

Jak je tedy optimalizovat?

Nástrojů je naštěstí více než dost. V podstatě stačí jen obrázek uložit do správného formátu a poté ho prohnat nějakým nástrojem, který smaže zbytečná data bez vizuální změny kvality (bezeztrátová komprese).

Pro obrázky bohaté na barvy jako jsou fotografie používejte formát JPG. Pro všechny webové obrázky jako jsou různá ohraničení, ozdoby a podobně naopak zvolte PNG a vždy (!) soubor uložte v co možná nejmenší barevné paletě.

Je plýtváním ukládat PNG obrázek, který má jen 30 barev do barevné palety o 256 barvách. I když nejsou barvy použity, barevná paleta se uložit musí a tím vzrůstá velikost souboru. Uložením do barevné palety o 32 barvách tak ušetříte.

Až tak učiníte, zkuste své obrázky prohnat nějakým online nástrojem. Uvidíte, jak moc své obrázky ještě můžete zmáčknout. Někdy se výsledný obrázek zmenší jen o 8 %, jindy o 30 – záleží na obrázku a nedá se to moc dobře odhadnout dopředu.

Já osobně moc rád využívám nástroj od Kraken.io. Jen si při nahrávání obrázků nezapomeňte změnit kvalitu na Lossless, tedy bez vizuální změny kvality.

Jinak řečeno – vaše obrázky budou stejně kvalitní a detailní jako předtím. Jen budou mít menší velikost.

Věc jménem data URI

Zůstaňme ještě u obrázků. Psal jsem, že pro webové obrázky a různé ozdoby se hodí formát PNG. Jenže co když těch obrázků, které potřebujete pro načtení webu je hodně a jsou malé?

Pak vám zahltí prohlížeč, který umí načítat jen omezené množství souborů současně a tak vám klidně 2 kB velké obrázky zbytečně brzdí načítání.

V takovém případě se můžete uchýlit k využívání data URI – tedy uniform resource identifier.

Jde ve své podstatě o to, že maličké obrázky převedete na dlouhou řádku znaků, kterou následně vložíte namísto adresy k obrázku do vašeho HTML či CSS.

Naprosto eliminujete HTTP požadavek na obrázek a zrychlíte díky tomu své stránky. Obecně se tvrdí, že by se takto měli převádět obrázky jen do velikosti 32 kB, ale já bych tak činil raději do 10 kB.

Tato metoda by se zkrátka neměla používat na velké obrázky.

Jestliže máte na svých stránkách kupříkladu 10 obrázků, které mají třeba jen 20 na 20 pixelů, klidně je na data URI převeďte a ušetříte si zmiňovaných 10 požadavků, což se už rozhodně počítá.

Učinit tak můžete pomocí tohoto nástroje, který vám po nahrání obrázku zobrazí něco jako: data:image/gif;base64,R0lGODlhAQABAJEAAAAAAP///93d3f///yH5BAEAAAMALAAAAAABAAEAAAICVAEAOw== – což je kód, který vložíte namísto adresy na právě nahraný obrázek.

Prohlížeč si tuto řádku již sám zpracuje a návštěvníkům zobrazí jako klasický obrázek.

Doba odezvy serveru

Doba odezvy serveru je čas, který serveru trvá zpracovat váš požadavek na načtení konkrétní stránky než vám ji zašle. I když to mnozí přehlíží, je to důležitá věc, která rozhoduje o komfortu při surfování na webu.

Čím menší odezva, tím rychleji může být stránka doručena k uživateli.

Statické stránky mají běžně odezvu kolem 50 ms, protože server nemusí nic složitě zpracovávat. Ty přes PHP s využíváním databáze mají kolem 200 ms, což je pořád skvělé.

Horší je, když máte cokoliv nad 400 milisekund. Pak už si troufám tvrdit, že vaše stránky reagují pomalu. Ať už kvůli špatnému hostingu, napsanému kódu či hromadou balastu, který server musí zpracovávat.

Proto platí obecné pravidlo – smažte ze stránek cokoliv zbytečného. Ať server má dostatek prostředků pro načítání obsahu. Optimalizujte svou databázi přes phpMyAdmin a zeptejte se na technické podpoře, zda váš hosting podporuje opcode cache.

Starší verze PHP mají k sobě občas přibalené APC či XCache, ale naprosto nejlepší odpovědí může být, že vaše stránky běží na nejnovější verzi PHP. Tedy například PHP 5.5 či 5.6. Ta totiž už od základu opcode cache obsahuje a tak se o nic starat nemusíte. Navíc je rychlejší.

A pravděpodobně budou vaše stránky reagovat do 200 ms. To si ostatně můžete vyzkoušet díky Check GZIP compression nástroji.

Do políčka vložte požadovanou URL adresu a podívejte se na řádek Execution time of HTTP request. Jestliže je vaše průměrná hodnota kolem či pod 200 milisekund, gratuluji. Pokud ne, zkuste pátrat proč a zapracujte na tom.

Slovo závěrem

Závěrem bych vám už jen poděkoval za přečtení a doufám, že vás článek nabudil k zlepšení svého webu. Protože není žádný důvod ani omluva pro pomalé stránky.

Není to nezvládnutelný úkol a vaši návštěvníci rychlejší web jistě ocení.

3 Příspěvků v diskuzi

  1. škoda že jste v takovém článku nezmínili ZEND OPCache, nástroj který dokáže mnohanásobně zrychlit běh php skriptů díky jejich kompilaci. Opravdu velmi doporučuji, rozdíl jsem nejznatelněji registroval na webu který jsem hostoval z RASPBERRY PI, který jednoduchý php skript vracel asi 800ms, a po nasazení OPCache jen za 50ms, řádový nárůst rychlosti …

    • Ten je právě zamýšlen při zmiňování se o PHP 5.5 a 5.6, protože je standardně dodáván k PHP 5.5 a novější.

      Takže tam je, i když není přímo jmenován :).

Odpovědět