Nová generace webových aplikací bohatě využívá javascriptu i kaskádových stylů k tomu, aby zvyšovala uživatelský komfort pro návštěvníky. Asynchronní dotazy na pozadí (AJAX), dynamické přepínání vzhledu, okamžitá odpověď aplikace bez nutnosti stránku odesílat zpět na server - to všechno se dnes stalo standardem.
Zrychlení načítání javascriptů
Velice rozšířeným názorem je, že soubory s kaskádovými styly nebo s javascriptem bychom měli pokud možno spojovat do menšího množství větších monolitických souborů. Že je lepší mít jeden 50kB soubor, než deset souborů o velikosti 5kB. Omezíme tím počet požadavků na server a stránka se tak rychleji zobrazí. Důležité je si také uvědomit fakt, že jak Internet Explorer, tak i Firefox, dokáží najednou paralelně stahovat z jedné domény maximálně dva zdroje. V praxi to znamená, že zatímco prohlížeč pracně stahuje několik javascriptových souborů, na obrázky se nedostane a stránka se poměrně dlouhu dobu zobrazuje bez nich.
Tento přístup má samozřejmě i nevýhody. Zřejmě tou největší je ten fakt, že při každé, byť drobné změně javacriptu (resp. CSS), je potřeba dostat k uživateli kompletní (třeba 100kB) soubor dat.
Za rozumný kompromis považuji ten případ, kdy je potřebný kód sice rozdělen, ale pouze do několika málo souborů. V každém z těchto souborů by se měly nacházet objekty (funkce, styly, ...), které spolu určitým způsobem souvisejí. V ideálním případě pak dosáhneme toho, že nebude třeba vždy nahrávat všechny tyto soubory, ale v závislosti na tom, kde se na stránkách nacházíme, budou nahrány vždy jen ty potřebné. Pokud těchto "knihoven" nebude příliš, nebudou vyžadovat ani příliš požadavků na webový server. Zároveň tímto způsobem výrazně omezíme negativní vliv monolitického přístupu, o kterém jsem psal v předchozím odstavci.
Další oblíbená metoda, kterou se dá snížit čas potřebný ke stažení souborů s kaskádovými styly a javascriptem, je komprese. Zřejmě nečastější je nasazení mod_gzip. Tento modul serveru Apache při přijetí požadavku zkomprimuje obsah dokumentu (browser si ho po přijetí samozřejmě opět rozbalí), a tím zmenší jeho velikost. Pochopitelně se tak děje na úkor strojového času procesoru na serveru (komprese) i u klienta (dekomprese). Mod_gzip navíc při práci vytváří na disku dočasné soubory s komprimovanými daty, které nabídne ke stažení a následně smaže. A zde je další potenciální Achillova pata tohoto modulu - práce s diskem je mnohonásobně pomalejší než práce s pamětí a u velmi vytížených webových serverů se počet I/O operací může lehce dostat za hranici, kdy mod_gzip přestane přínášet zrychlení, ale naopak se stane brzdou.
Zdroj: Sindelka.cz