nav line

Výkonnostní optimalizace front-endu web integračního projektu

Nedostane-li uživatel obsah vašeho webu v určitém rozumném čase, často odejde a již se třeba nevrátí. Proto nesmí uživatele pomalé načítání webu nějak obtěžovat a v nejlepším případě by si neměl ani uvědomovat, že musí na něco čekat.

Při tvorbě webu nebo webových aplikací má na rychlost zobrazení vliv celá řada věcí – od vlastního zdrojového kódu přes infrastrukturu až po schopnosti webového prohlížeče. Nyní se budu soustředit na problémy obklopující front-endový výkon webu, což jsou vlastně všechny vazby mezi prohlížečem a naším webovým projektem poté, co byl dynamicky vytvořen a jako HTML odeslán do prohlížeče. Zaměřím se na hlavní problémy front-endové optimalizace a postupy, jak je minimalizovat a docílit tak na web integračním projektu lepší „user experience“ – subjektivní vnímání rychlosti koncovým uživatelem.

V řadě případů lze podstatně zrychlit rychlost načítání webu, zaměříme-li se na několik oblastí, které je nutné optimalizovat. V konečném důsledku musíme snížit počet HTTP požadavků a velikost stahovaných dat na nezbytné minimum a psát programový kód optimalizovaný, protože i když je v současnosti výpočetní výkon na zařízeních vysoký, tak mnohdy se i velmi výkonný stroj zadýchá a uživatel to pocítí v rychlosti, jakou web může prohlížet.

Mezi hlavní a nejrozšířenější oblasti optimalizace patří:

  • HTML, CSS, JavaScript,
  • obrázky.
  • URL adresy.
  • cachování (načítání do mezipaměti).

HTML, CSS, JavaScript a jiné textové formáty

Jedná se zejména o vlastní HTML kód, kaskádové styly a javascript, pro které se uplatňují následující pravidla:

  • Odstranit z HTML vše, co tam není třeba - z mého pohledu se jedná hlavně o komentáře. Ty by měly zůstat v šablonách, ze kterých je HTML generováno, ale neměly by se dostat do výstupu. Občas se doporučuje i všech rušení bílých znaků a “nepotřebných” uzavíracích tagů (), ale toho bych se spíše vyvaroval, protože to vyřeší zapnutá komprese.
  • Zapnout na všechny textové formáty kompresi (gzip+deflate) - jedná se zejména o HTML, XML, TXT, JS a CSS soubory.
  • Předpřipravit si obsah pomocí “Link prefetching” - v zásadě se jedná o mechaniku, kdy lze donutit prohlížeč “předstahovat” určitý obsah v době, kdy zahálí a šetřit tak uživateli čas.
  • CSS soubory umístit na začátek HTML do hlavičky a JS naopak umístit až na konec.
  • Slučovat CSS a JS soubory. O slučování by se měla ideálně starat aspoň v případě JS portálová platforma. V případě CSS lze řešit například preprocesorem (LESS, SASS, …) případně pomocí různých komplexnějších nástrojů s různě pokročilým GUI jako Koala, Prepros App, WinLESS atd. nebo robustnějších nástrojů založených na příkazové řádce - Grunt, PHỞ DEVSTACK. Lze také používat řadu online nástrojů - YUI Compressor, Google Closure Compiler.
  • Minifikovat CSS a JS soubory. O minifikaci se již většinou stará sám vývojář například s využitím nástrojů popsaných výše.
  • JS knihovny třetích stran, které nejsou důležité pro fungování a zobrazení stránky načítat asynchronně (Google Analytics, …) nebo je linkovat přímo ze zdroje, či z nějakého společného úložiště (Google Hosted Libraries).
  • Provádět obecné optimalizace kódu, např. nepoužívat v CSS obecné selektory (*), nepoužívat klauzuli @import pro načítání dalších CSS protože to zvyšuje HTTP požadavky, nevyužívat „CSS Expressions“, neplýtvat zdroji v JS, vytvořit validní kód apod.

Obrázky

Obrázky tvoří nedílnou součást webu a velmi často je na nich celý web postaven a mohou tvořit podstatnou část objemu webu. Proto je důležité věnovat úsilí do jejich optimalizace.

  • Vždy zvolit pro daný obrázek správný formát (GIF, JPG, PNG) dle obsahu obrázku popř. jeho umístění tedy volit jestli se zvolí ztrátová či bezztrátová komprese a tedy i formát obrázku. Při tom je potřeba dbát i na velikost výsledného souboru, která musí být co nejmenší při zachování původní kvality.
  • Pro obrázky tvořící vlastní design webu používat tzv. “CSS Sprites”, kdy jsou jednotlivé obrázky skládány do jednoho souboru a do layoutu webu pak umísťovány pomocí CSS (background-position). Tato technika šetří HTTP požadavky. Spojovat obrázky můžeme ručně přímo v grafickém editoru nebo pomocí nějakého nástroje - sprite me, stitches
  • Obrázkům vždy nastavovat rozměry ať už přímo v HTML nebo CSS, čímž zamezíme různým mezi stavům a “přeskakování” prvků na stránce. Přičemž tyto rozměry musí odpovídat reálným rozměrům daného obrázku. Tzn. například nepoužívat pro náhledy 20x20px obrázek s reálnými rozměry 250x250px. Šetříme tak přenášená data.
  • Vhodné je využití tzv. lazy loadingu, kdy se obsah stránky načte, až když jej uživatel potřebuje. Může se používat na různé části obsahu (pro “infinity-scroll”), ale vhodný je využít jej na postupné načítání obrázků, čímž lze šetřit objem přenesených dat a HTTP požadavky. Hojně se využívá v responzivním designu.
  • Data URIs - pokud máme objemově malé obrázky, tak pro snížení počtu HTTP požadavků lze využít vkládání obrázků do webu pomocí tzv. “data URIs”, kdy je obsah obrázku vložen přímo do HTML popř. CSS. Takový obrázek je pak dostupný okamžitě po stažení dané HTML stránky (CSS souboru). Obsah takového data URI obrázku je zakódován pomocí Base64 a je vložen následovně do stránky: data[][;charset=][;base64],. Jen z podstaty Base64 kódovacího algoritmu je pak takový obrázek datově o třetinu větší. Hojně se využívá v responzivním designu popř. v mailových šablonách. Více zde - http://en.wikipedia.org/wiki/Data_URI_scheme

URL adresy

  • Vyhnout se požadavkům na neexistující soubory (chyba 404) - např. špatně zadaná cesta k obrázku v dokumentu nebo cesta k obrázku v CSS souboru.
  • Používat více hostnames (domén) pro možnost využít více souběžných HTTP procesů - viz. část o cachování (reverzní proxy cache server).

Cachování

  • Servírování statických souborů přes reverzní proxy - využití reverzního proxy cache serveru pro servírování statických zdrojových souborů (JS, CSS a obrázky). Je vhodné přistoupit k řešení, kdy různé typy souborů jsou servírovány z různých hostů, aby se obešel problém s prohlížečem limitovaným počtem HTTP požadavků per host.
  • Využít cache návštěvníkova prohlížeče pomocí nastavení expiračních hlaviček pro statické soubory (JS, CSS a obrázky) a tedy nestahovat již jednou stažené soubory, ale používat jejich lokální verze. Odpověď webového serveru se statickým zdrojovým souborem musí obsahovat všechny expirační hlavičky, které jsou potřeba pro úspěšné zacachování jak na reverzních proxy, tak v prohlížečích.
  • Vydávat statické zdrojové soubory přes persistentní HTTP spojení (http://en.wikipedia.org/wiki/HTTP_persistent_connection), tzn. na web serveru nastavit hlavičku Keep-Alive optimálně na hodnotu 15 sekund.
  • Zvážit využití CDN (Content Delivery Network) pro vydávání velkých statických souborů (zejména se jedná o video obsah).
  • Pokud je to možné využívat tzv. “full page caching” a cachovat celé sestavené stránky, kdy se výsledná stránka negeneruje na straně serveru pokaždé znova, ale po prvním vygenerování je její podoba na serveru uložena jako HTML a následně už je vydávána návštěvníkům tato verze. Lze aplikovat na jednotlivé stránky, sekce nebo celý web s fixní nebo proměnlivou délkou exspirace v návaznosti na výkonostní optimalizaci zátěže (performance tuning) web serveru.

Nástroje na analýzu

Pokud chcete zjistit, jak jsou na tom vaše stránky, nebo se pustit do vlastní optimalizace, existuje řada nástrojů, kterými lze web analyzovat a které často i zobrazují seznam možných řešení. Jedním z nejznámějších nástrojů jsou Google PageSpeed Tools, které existují jako samostatný online nástroj nebo jako rozšíření do prohlížeče.

Tento nástroj analyzuje vaší stránku a vrátí seznam návrhů pro její optimalizaci, přičemž vychází z PageSpeed Rules. Výsledky analýzy je ovšem nutné brát trochu s nadhledem a nehnat se bezmyšlenkovitě za co nejvyšším PageSpeed rankem. Všechna měření nemusí být zcela přesná.

Dalším zajímavým nástrojem je například WebPageTest, který funguje na obdobném principu jako Google PageSpeed, ale uživatel toužící po více podrobnostech si zde užije více.

Pro základní přehled o tom, jak na tom váš web je stačí také většina současných prohlížečů, kde v příslušných nástrojích pro vývojáře jsou dostupné základní informace jako HTTP požadavky, cache, komprese a velikosti přenesených dat.

PageSpeed Module

Pokud máte možnost spravovat váš WWW server Apache nebo používáte vlastní, je doporučeno používat kromě výše uvedených optimalizací také PageSpeed Module. Jedná se o open-source modul pro Apache, který automaticky aplikuje na web PageSpeed Rules.

Závěr

Body popsané tvoří základ toho, jak lze odhalit místa, které nejvíce zpomalují načítání vašeho webu a jak lze tyto nedostatky ostranit. Některé techniky jsou jednoduché, ale je třeba s nimi počítat již od začátku našeho projektu, jiné jsou poměrně složité na implementaci a také vyžadují patřičné vývojářské kapacity a/nebo součinnost správce provozní webové infrastruktury (web serveru). Nutné je také počítat s tím, že optimalizace je třeba provádět opakovaně v návaznosti na vývojový cyklus (s každým novým releasem). Každopádně výsledek vynaloženého úsilí na front-end optimalizace pak stojí za to a přináší vedle výrazného zrychlení načítání webu spokojenějšího uživatele, o kterého nám jde v první řadě.

Ohodnoťte článek

Výkonnostní optimalizace front-endu web integračního projektu

Související články

Vyhledávání na blogu

Webová integrace

Webová integrace jako nová oblast pro business „velkých" webových agentur.

o webové integraci

Profily blogujících