Poznámka k postu Zrychlení načítání JavaScriptu

od aichi E-mail

Odkaz: http://www.sindelka.cz/cz/zrychleni-nacitani-javacriptu/

Pavel ve svém příspěvku uvádí pár zajímavých myšlenek, jak se stavět k problému bobtnajících JavaScriptů a CSS souborů se stále složitějšími designy.

Pokračování:

Shrnutí

Pavel rozebírá problémy spojování souborů do jednoho velkého, jeho možnost komprese pomocí Apache a také uvádí způsob jeho cacheování pomocí mod_rewrite.

Co s rozrůstající se knihovnou JS?

Cílem našeho snažení by mělo být omezení HTTP requestů na server a uložení co nejvíce obsahu do keše prohlížeče uživatele. Omezení HTTP requestů rozebírají na Yahoo blogu, ponaučením, které si můžeme odnést je, že zhruba polovina uživatelů má prázdnou keš. Proto se snažíme sloučit soubory tak, abychom ze serveru žádali co nejméně souborů. Tím pádem je vhodné abyste sloučili všechny vaše JavaScriptové soubory do jednoho, CSS soubory taky do jednoho. Sice se je uživatel bude muset stahnout při prvním přístupu, ale při jejich nakešování jejich velikost nebude vadit.

Spojení souborů lze provést ve Windows pomocí příkazu:

copy /b soubor1.js + soubor2.js + souborN.js output.js

nebo v Linuxu:

cat soubor1.js soubor2.js > output.js

Výsledný soubor můžeme nechat tak jak je, nebo ho zabalit. Pokud chceme zmenšit velikost pomocí balení, je nutné si vybrat takový balící nástroj, který nám nerozbije funkčnost skriptů. Balící skripty se rozlišují na dva druhy. První z nich pouze vyhodí všechny komentáře a přebytečné mezery, druhý typ celý javascript enkóduje pomocí Base64. Pak výsledek začíná většinou:

eval(function(p,a,c,k,e,r)

Druhému způsobu doporučuji se vyhnout, neboť používání evalu je zlo :-), ale hlavně dekódování stojí procesorový čas při každém použití (načtení stránky), kdežto načtení většího souboru se děje pouze jednou.

Pro kompresi CSS souboru je možné využít online CSS kompresor. U kompresování CSS na nejvyšší uroveň může nastat problém se Safari 1 a 2, pokud posledním pravidlem v chlupaté závorce je komentářový rovnítkový hack.

Kešování

Pokud máme dva soubory (jeden JS a druhý CSS), chceme aby si je uživatelé stáhli jednou a zůstali jim nakešovaný. Ale také chceme, abychom mohli jednoduše změnit obsah a prohlížeče uživatelů na změnu reagovaly okamžitě. Toho lze docílit verzováním souborů.

/js/main.js?13

Pavel ve svém článku nejdříve psal, že v RFC 2616 pro HTTP protokol je napsáno, že URL s parametry za otazníkem se nemají kešovat a proto doporučuje verzi vkládat do názvu souboru a použít mod_rewrite pro nasměrování na správné názvy souborů. Nyní po Vránově upozornění se již opravil, takže použití mod_rewrite postrádá smysl. Jeho použití zaprvé zbytečně zatěžuje server a za druhé jeho použití by využilo pouze 3% uživatelů, kteří používají Operu, která URL s otazníkem nikdy nekešuje.

Poslední věc co musíme nastavit je, aby server posílal správně hlavičku s expirací v keši prohlížeče, což Pavel zapoměl zmínit. Pokud máte přístup k nastavení Apache, je možné v httpd.conf souboru nastavit modul mod_expires např. takto:


ExpiresActive On
ExpiresByType text/css A2592000
ExpiresByType text/javascript A2592000

Pak budou JavaScripty a CSS soubory kešovány jeden měsíc. Pokud k tomuto nastavení nemáte přístup, musíte si ho obstarat jinými prostředky, tedy nejlépe ve vašem skriptovacím jazyku, např. PHP.

Nezapomeňte, že to samé nastavení můžete provést i pro obrázky.

Adresy zpětných odkazů pro tento příspěvek:

Trackback URL (right click and copy shortcut/link location)

3 komentářů

Komentář od: Pavel Šindelka [Návštěvník] E-mail · http://www.sindelka.cz
Už tu jde vložit komentář, takže kopíruji ten ze svého blogu, aby byl u článku, ke kterému se vztahuje :) Takže:

Díky Michale za hezké doplnění, konkrétní metody spojování souborů či posílání hlaviček s expirací jsem (záměrně) nerozebíral - a je dobře, že tyhle informace budou k nalezení.

S vším, cos napsal, souhlasím - až na jednu výjimku. Použití mod_rewite skutečně podle mého smysl nepostrádá. Zmiňovaná zvýšená zátěž serveru způsobená tímto jedním rewritem navíc je, troufám si tvrdit, prakticky nezměřitelně malá a zanedbatelná. V zápisu "/js/main.js?13" nevidím nic jednoduššího oproti zápisu "/js/main.v13.js". A naopak stoprocentní funkčnost přes všechny prohlížeče (mimochodem podle mých informací (http://technet.idnes.cz/pro...) má u nás Opera kolem 5% a technické komunitě kolem 15% podílu na trhu) mi přijde jako výrazné plus. V tomto případě se mi zkrátka zdá mnou prezentované řešení o fous lepší.

Nicméně jsem moc rád, že ses něco konečně rozhodl sepsat. Moc rád (a určitě v tom nebudu sám) si přečtu Tvoje postřehy z PHP a hlavně Javascriptu. Tam se mám ještě hodně co učit :)
17. 02. 08 @ 21:01
Komentář od: aichi [Člen] E-mail
Na druhou stranu pokud tvoříš větší systém s více servery, můžes obrázky a CSSka vydávat jiným serverem než zbytek. Na tomto serveru nepotřebujes Apache, ale nějaký jednoduchý server, např. Lighhttpd http://www.lighttpd.net/ , který mod_rewrite neumí. Pak se musís rozhodnout a většinou ti nebude vadit trafik od 3-5% uživatelů co mají browser, který prdí na normy.
18. 02. 08 @ 14:48
Komentář od: Pavel Šindelka [Návštěvník] E-mail · http://www.sindelka.cz
OK, v té specifické situaci, kdy není možné mod_rewrite použít, bych ho nepoužil :)

Ještě trochu offtopic k té Opeře - schválně jsem se díval na návštěvníky svého blogu a s mírným překvapením jsem zjistil, že cca 60% z nich používá FF, 20% IE a 20% (!) Operu. Na www.darkage.cz je Opera na 15%. Takže já si Operu ignorovat nemůžu dovolit :) Jinak v těchto případech je to samozřejmě trochu dáno specifickou cílovou skupinou návštěvníků, nicméně i tak to stojí za zmínku.
18. 02. 08 @ 20:11

Napsat komentář


Vaše e-mailová adresa nebude zveřejněna.

Adresa Vašich WWW stránek bude zveřejněna.
(Konce řádku budou převedeny na <br />)
(Jméno, email a webová stránka)
(Dovolí ostatním uživatelům kontaktovat Vás prostřednictvím formuláře pro zprávy (Vaše e-mailová adresa NEBUDE zveřejněna.))