Optimalizace rychlosti webu: Odmítáme neslušné HTTP požadavky

14.8.2010 18:34 | Komentáře (19) | Kategorie: Tvorba webu | Štítky: CSS, Firebug, HTML, Javascript, Optimalizace

Každý soubor, který se použije při vykreslení webové stránky (obrázek, CSSko, javascriptová knihovna atd.) představuje jeden HTTP požadavek na server. Dle doporučení HTTP protokolu 1.1 by prohlížeče neměly vyřizovat více jak 2 tyto požadavky zároveň na jednom hostiteli. Současné browsery na to víceméně kašlou a vyřizují jich více. Pro účely tohoto seriálu budeme předpokládat 6 paralelních požadavků (tak je to u většiny současných prohlížečů). Pokud máte na stránce například 5 souborů s CSSkem, 3 javascriptové knihovny, 3 obrázky v HTML kódu a 4 obrázky nahráváte v CSSku, je třeba vyřídit celkem 16 požadavků (tím prvním je samotný HTML dokument). Ty se však nestáhnou zároveň, ale vyřídí se postupně. Nejdříve se začne stahovat prvních šest HTTP požadavků a teprve až první z nich doběhne, může se začít stahovat další. A zde se naskýtá prostor pro optimalizaci. Dneska si povíme konkrétní kroky, jak zvýšit rychlost načítání stránky prostřednictvím snížení počtu HTTP požadavků.

Ukázkový příklad před optimalizací

Začneme příkladem, kde si můžete ověřit, že jsem vám v prvním odstavci příliš nelhal. Zapněte si ve Firebugu záložku Síť a navštivte tuto ukázku. Pokud dáte na stránce reload (Ctrl+F5), měli byste dostat nějaký obdobný přehled HTTP požadavků na časové ose:

Jak vyřizuje prohlížeč HTTP Požadavky - příklad před optimalizací

Po načtení HTML dokumentu se vezme prvních 6 požadavků a začnou se stahovat. Na obrázku je vidět, jak soubory jquery-ui-min.js a script.js musí čekat, až se uvolní místo ve frontě na stažení dalších požadavků a začnou se vyřizovat teprve až doběhnou první dva z balíku předchozích šesti. Dále je vidět, že obrázky se začnou načítat až po načtení jquery.min.js. Toho si zatím nebudeme všímat, dostaneme se k tomu později. Po stažení následuje další balík 6ti požadavků na obrázky a tak poslední obrázek musí chvíli počkat. Tento příklad si pro porovnání ukážeme ještě jednou na konci dnešního dílu, ale už s provedenými optimalizacemi.

Optimalizace CSS

Nemusíme zrovna chodit do Mensy na obědy, aby nám došlo, kde s optimalizací začneme. Nejdříve všechny CSS soubory spojíme do jednoho (zvlášť pokud je stejně máme přilinkovány ke každé stránce webu). Jestliže používáte různé styly pro různá zařízení a odlišujete je přes atribut media, můžete specifikovat typ zařízení až ve spojeném souboru přes pravidlo @media. Vše si ukážeme na příkladu. Nejdříve původní podoba hlavičky před optimalizací:

<link href="/stylesheets/general.css" type="text/css" media="all" rel="stylesheet" />
<link href="/stylesheets/print.css" type="text/css" media="print" rel="stylesheet" />
<link href="/stylesheets/handheld.css" type="text/css" media="handheld" rel="stylesheet" />

<style media="screen" type="text/css">
	@import '/stylesheets/screen.css';
	@import '/stylesheets/lightbox.css';
</style>

Nyní spojíme všechny soubory do jednoho a nazveme jej třeba styles.css. Zároveň se vyhneme zápisu pomocí @import. V některých verzích IE tento zápis způsobí to samé, jako kdybychom připojili CSSko až na konec dokumentu. Stránka by se začala vykreslovat až po načtení tohoto posledního stylu a do té doby by na nás zela bílá obrazovka. Všechny CSS soubory tedy umístíme do hlavičky <head> dokumentu a spojíme je do jednoho následovně:

<link href="/stylesheets/styles.css" type="text/css" rel="stylesheet" />

Soubor styles.css pak bude vypadat takto:

@media all {
	/* obsah souboru general.css */
}

@media screen {
	/* obsah souboru screen.css a lightbox.css*/
}

@media print {
	/* obsah souboru print.css*/
}

@media handheld {
	/* obsah souboru handheld.css*/
}

Tímto jsme z pěti HTTP požadavků udělali jeden a máme první krok v daleké cestě za svištícím webem.

Nyní se podíváme do CSS souboru a provedeme audit toho, co obsahuje. Pokud používáte v CSSku obrázky na pozadí, vytváříte další HTTP požadavky na jejich stáhnutí. Dalším krokem optimalizace bude snaha o pospojování obrázků z CSS do jednoho.

CSS Sprite - ukázka

Tato technika se nazývá CSS sprites a vychází z Pixyho vynálezu Rychlé rollovery bez načítání. Dále se o ní můžete dočíst např. v článku CSS Sprites: Image Slicing’s Kiss of Death magazínu A List Apart. Vlevo se můžete podívat, jak takový sprajt vypadá třeba na Googlu. Všechny objekty, které vidíte na obrázku, mají tento sprajt nastaven jako svůj background-image. Liší se svými rozměry a nastavením pozice obrázku na pozadí přes background-position. Pravda, tato technika není zrovna jednoduchá na spravování a kodérovi může přinést trochu práce navíc. Zvláště pokud se web často mění. Riziko vzniká především tehdy, pokud budete muset změnit rozměry obrázku, který se nachází uvnitř sprajtu. Budete pak muset upravit nastavení background-position všem objektům, kterým se pozadí díky změně tohoto obrázku posunulo uvnitř sprajtu. Proto, než vytvoříme CSS sprajt, je dobré si vše pořádně rozmyslet a vytipovat vhodné kandidáty. Příliš se nespálíte, pokud vyberete obrázky, které splňují následující:

Mají fixní rozměry a obrázek je přes celý objekt – typicky logo, pozadí obrázkového hlavního menu, opakující se obrázkové nadpisy,u e-shopu tlačítka Koupit, fixní ikonky apod.
Často se opakují napříč webem (nemá smysl, aby si návštěvník nahrával dopředu obrázky, které se mu pak vůbec nezobrazí)
Je pravděpodobné, že se nebudou příliš měnit (jinak z toho buď zešílíte nebo začnete používat nějaký lepší nástroj než kalkulačku)

Použití sprajtů není omezeno jen na objekty s fixními rozměry. Vyzkoušejte si na svém webu šikovnou utilitku SpriteMe, která sama vytipuje vhodné obrázky z vašeho CSSka ke sprajtování a vygeneruje je včetně CSS.

Optimalizace Javascriptu

Zde platí stejně jako pro CSSka, spojte JS soubory do jednoho. Na rozdíl od CSS však pokud možno umístěte odkazy na javascripty až na konec HTML dokumentu před značku </body>. Pokud bychom nechali javascripty v hlavičce, blokovali bychom stažení všeho co po skriptech následuje v těle stránky. Prohlížeč totiž neví, co je obsahem javascriptu a netroufne si stahovat další soubory, když to může být třeba zbytečné. Představte si, že by javascript obsahoval kód, který přesměruje stránku nebo přes document.write úplně změní DOM stránky. Toto vysvětluje čekání na javascript v prvním příkladu. Umístění skriptů až na konec HTML dokumentu občas nemusí být úplně jednoduché, ale pokud vytváříme web na zelené louce a není třeba přepisovat již funkční rozsáhlý web prošpikovaný javasciptovou nirvánou (nebo peklem), určitě bych tento přístup doporučil. Pokud musíte vkládat javascript v hlavičce dokumentu, dodržujte alespoň pořadí nejdříve CSS a až pak soubory s javasciptem. Co jsem testoval, tak Opera (10.60) narozdíl třeba od Firefoxu blokuje i stahování CSSka, dokud se nenahraje javascipt. Na Operu ani nezabírá umístění JS až na konec dokumentu. Pro pokročilé kodéry doporučuji prostudovat také zajímavou studii na téma nahrávání javascriptu javascriptem v článku Loading Scripts Without Blocking, případně LABjs – jednu z mnoha knihoven, která se na to specializuje.

Pokud si myslíte, že je pravděpodobnější, že spadne Váš web než Google, mám pro vás další tip. Jestliže používáte nějakou známou JS knihovnu, jako je jQuery, YUI, Prototype a podobně, můžete využít Google Libraries API. Zjednodušeně jde o to, že tyto knihovny netaháte ze svého serveru, ale ze serveru od Googlu. Knihovny jsou tam umístěny v různých verzích, stačí si vybrat tu kterou potřebujete a připojit ji do vaší stránky např. takto:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>

Toto má své výhody i nevýhody. Mezi výhody patří, že HTTP požadavek je na jiný server než váš, a tak se vyhnete omezení počtu HTTP požadavků ze stejného zdroje a stahování dalších souborů poběží paralelně. Další nespornou výhodou je cachování. Pokud Váš návštěvník již v minulosti navštívil některou stránku, která stahuje knihovnu ze stejné adresy, bude mít již při první návštěvě vašich stránek tuto knihovnu ve své cache a nebude si tedy muset knihovnu znovu načítat. Navíc knihovny jsou GZIPované a mají správně nastavené hlavičky – o tomto v dalších dílech seriálu. V poslední řadě také ušetříte nějaký ten kilobajt z provozu serveru. Nevýhoda je nasnadě: důvěřujete nějaké třetí straně, že vám do stránek naservíruje to, co slibuje, a ještě k tomu v nějakém rozumném čase. Dále vznikne určitá časová režie na vyhledání DNS záznamu.

Ukázkový příklad po optimalizaci

Nastal čas podívat se na to, jak dopadl náš ukázkový příklad po optimalizaci. Pokud se podíváte do zdrojového kódu, uvidíte následující změny: 5 CSS souborů bylo spojeno do jednoho stejně tak jako 3 soubory s javascripty. Vzniklý soubor s javascripty byl přilinkován až na konci HTML dokumentu. A nakonec 4 obrázky z CSSka byly spojeny do jednoho sprajtu a CSSko následně upraveno. Podívejme se jak to dopadlo:

Jak vyřizuje prohlížeč HTTP požadavky - příklad po optimalizaci

Jak je vidět, počet požadavků jsme srazili z 16 na 7. Ač časy nejde úplně srovnávat (načtení obou stránek s příklady proběhlo v jiný čas a za jiné konstelace hvězd), je optimalizace patrná na první pohled. V druhém příkladě se nečeká na načtení javascriptu, aby se mohly stáhnout obrázky z dokumentu. Zároveň díky CSS sprajtu a pospojování souborů, jsme ušetřili čekání na vyřízení balíku po šesti požadavcích.

Pokud jste dočetli až sem, zasloužíte si odměnu v podobě kontrolní otázky. Proč se v druhém příkladě soubor img_css_sprite.png nenahraje společně s ostatními v rámci jednoho balíku po šesti? Odpovědi zasílejte na adresu Studio kamarád, nebo je napište do komentářů.

Cachování a konfigurace hlaviček

Doposud jsme se zabývali optimalizací rychlosti pro všechny návštěvníky webu. Nyní vytvoříme pár optimalizací pro návštěvníky, kteří navštěvují váš web opakovaně.

Představte si, že poprvé navštívíte úvodní stránku nějakého webu. V ten moment váš prohlížeč vytvoří spoustu HTTP požadavků na všechny komponenty webu: obrázky, CSSka, javascripty a tak dále. Tyto komponenty si prohlížeč uloží k sobě na disk. Z homepage si následně odskočíte na nějakou podstránku, kde budou některé jiné obrázky a soubory, ale spousta jich bude stejných: logo, CSSko, obrázek na pozadí hlavičky apod. Byla by škoda znovu čekat, než se vyřídí opakující se požadavky. Proto existuje mechanismus cachování v prohlížeči, který umí rozhodnout, co nahrávat znovu, a co si vzít z lokální kopie na vašem disku. Abyste prohlížeči pomohli v rozhodování, je třeba správně nakonfigurovat Váš server, aby do hlaviček přidával některé další informace. To lze buď pomocí ETagů nebo nastavením časové platnosti. My se budeme zabývat druhým jmenovaným způsobem.

Nyní si ukážeme, jak bude zhruba probíhat komunikace se serverem při vyžádání si loga:

Prohlížeč se zeptá: Nazdar mašino, mám tu požadavek na stáhnutí loga. Žádné u sebe na disku nemám, jsem u tebe asi poprvé. Hoď mi zpátky to své úžasné logo. Server odpovídá: Jasně draku, tady ho máš s kódem 200. Naposled se změnilo Last-Modified: Fri, 06 Aug 2010 17:02:37 GMT. Ale tohle logo tady bude stejný ještě tak měsíc. Naštěstí si webmaster přečet jeden návod na netu, tak ti to posílám i s hlavičkou Expires: Tue, 07 Sep 2010 13:21:05 GMT, ať už se příště tak blbě neptáš. Za datum u Expires si dosaďte dnes + 1 měsíc.

Logo jsme tedy na úvodní stránce obdrželi a navštívíme podstránku. Prohlížeč si mumlá sám pro sebe: Hmm, mám stáhnout logo. Kouknu se k sobě na disk, zda ho tam mám. Á tady je, mrška. A platnost koukám má podle Expires ještě skoro jeden měsíc. Tak to už server nebudu otravovat, minule byl nějakej nabubřelej.

Jenže co se nestane, škodolibý uživatel stiskne F5 (pozor, ne Ctrl + F5) a vynutí si znovunahrání stránky. Prohlížeč se ptá: Nazdar mašino, tak jsem tu zpět pro logo. Mám ho sice u sebe, platnost má mít ještě skoro měsíc, ale co nadělám, šéf zmáčknul F5ku. Si snad myslí, že se ta rychlost udělá sama nebo co. Posílám ti to i s hlavičkou If-Modified-Since: Fri, 06 Aug 2010 17:02:37 GMT. Server odpovídá: Nazdar draku, a cos mu na to řek? No nic, kouknu do Last-Modified a porovnám to s If-Modified-Since. Hele, tak to vypadá, že se nic nezměnilo, posílám kód 304 Not Modified.

Takže takto zhruba probíhá komunikace mezi serverem a prohlížečem. Je třeba říct, že vedle cache v prohlížečích existují další možnosti cachování. Může se vám stát, že prohlížeč takto nebude komunikovat přímo se serverem, ale předtím ještě třeba s proxy cache ve vaší firemní síti. Pokud Vás toto téma zajímá detailněji, doporučuji např. článek Kešovací návod pro autory webu a webmastery. My se podíváme jak nakonfigurovat správně server.

Jak je vidět z našeho zachyceného dialogu, ideální stav pro snížení počtu HTTP požadavků je monolog prohlížeče, kdy se serveru vůbec na nic neptá a vezme soubor přímo ze své cache. Toho docílíme správným nastavením hlavičky Expires. Předtím je třeba si ujasnit, co a jak budeme cachovat. Určitě obrázky, flashe, zipy a další soubory. Ty se na webu obvykle často nemění a můžeme jim nastavit expiraci např. za 1 měsíc nebo ještě později. Podle specifikace HTTP 1.1 by expirace neměla být nastavena na více jak jeden rok (i když je toto doporučení často ignorováno). Javascripty a CSSka už se mění častěji a tak dáme expiraci třeba 1 týden (pro účely ukázky). Naopak HTML dokument cachovat nebudeme.

Různé webservery mají různé způsoby konfigurace, my si ukážeme jeden ze způsobů, jak si nastavit Expires hlavičku pomocí .htaccess souboru na serveru Apache s nainstalovaným modulem mod_expires:

<IfModule mod_expires.c>
ExpiresActive On

ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month" 

ExpiresByType text/css "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"
</IfModule>

Pokud upravíte CSS nebo soubor s javascriptem a chcete, aby se všem návštěvníkům nahrál znovu, pomůže soubor přejmenovat. Můžete do názvu souboru inkrementálně zvyšovat jeho verzi např. styles_v001.css. Jiným řešením může být přidání parametru s verzí CSSka za název souboru např. styles.css?v=001. Avšak zde hrozí, že takovou URL s parametrem na konci můžou některé proxy cache ignorovat. Na druhou stranu je verze s parametrem daleko snadněji spravovatelná.

Co se jinam nevešlo

Ohlídejte si, aby se na stránce nevyskytovaly požadavky na neexistující soubory. Ať už jde o obrázky v dokumentu, špatně zadanou cestu k obrázku v CSSku atd. Dokonce i když můžete mít vše v pořádku, prohlížeč občas požaduje neexistující soubor. Typickým příkladem je Opera, která hledá soubor favicon.ico i v případě, když jej v dokumentu vůbec nelinkujete. Je proto dobré faviconu vytvořit či alespoň nahrát na server prázdný soubor favicon.ico.

Dříve už jsem naznačil, že počet paralelně stahovaných souborů lze zvýšit, pokud soubory taháme z jiného hostitele. Teoreticky bychom mohli např. 6 obrázků umístit na i1.example.com, dalších 6 na i2.example.com a mohli bychom všech dvanáct vyřídit zároveň.

Použité zdroje a další počtení

Mekkou všech návodů jak zrychlit web je jednak Page Speed od Googlu a Best Practices for Speeding Up Your Web Site od Yahoo!, kde také naleznete YUIBlog s články na toto téma.

Obě společnosti spojuje jméno Steva Souderse (pozor, to není ten z Beverly Hills 90210), autora knih High Performance Web Sites a Even Faster Web Sites, který byl do Googlu „draftován“ právě z Yahoo!. Na jeho blogu najdete spoustu zajímavých výzkumů a mimo jiné i nástroj Cuzillion, ve kterém lze provádět různé hrátky s HTTP požadavky a testovat je v různých prohlížečích. Pravda je, že nástroj se občas choval podivně a nevracel mi úplně stejné výsledky jako v ukázkách z tohoto článku. Například zde jsem se pokusil nasimulovat podobné podmínky, jako v úvodním neoptimalizovaném příkladu, ale vůbec tam není vidět čekání na nahrání javascriptů – ještě to budu muset prozkoumat. Pokud si hrát nechcete, ale chtěli byste mít pohromadě hotové výsledky měření, jak se různé prohlížeče vypořádají s pořadím požadavků, kolik jich zvládají najednou a podobně, doporučuji web Browserscope, převážně záložku Network.

Závěrem

Tak jsme dospěli na konec dnešního dílu. Pokud máte nějaké dotazy nebo jste v článku nalezli nějaké chybky či nepřesnosti, pište do komentářů. V příštím dílu se zaměříme na optimalizaci prostřednictvím zmenšení objemu přenášených dat.

Další díly seriálu

Optimalizace rychlosti webu: Úvod
Optimalizace rychlosti webu: Odmítáme neslušné HTTP požadavky (This post)

Líbilo se? Pošli mě dál…

Komentáře

Jirka Š. 9.9.2010 13:28

Super, doufám že bude další pokračování!
#3
Emka 9.9.2010 16:06

Jirka: Díky, třetí díl už mám rozepsán. Veškeré pozitivní ohlasy jsou ohromnou motivací k pokoření Cohenova syndromu dvojpříspěvkového blogu .
#4
Trpaslik 9.9.2010 18:44

Tipnu si odpoved na kontrolni otazku do Studia Kamarad: soubor img_css_sprite.png se nahraje pozdeji, protoze je definovany jako css tag az v souboru styles.css – musi se tedy pockat, az se tento soubor nahraje a rozparsuje.
#5
Emka 9.9.2010 20:06

Trpaslik: Bingo!
#6
anydot 9.9.2010 21:55

Na řešení problému s cachováním apod. doporučuju webový analyzátor redbot.org, celkem fajnová vecička.
#7
srigi 10.9.2010 06:48

Mam pre vas ohladne oprimizacie poctu HTTP rqs jeden tip => http://paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/

Skuste si aj v tej stranke vyhladat link „blocking issue“ a precitat aj tamten clanok.

Potom by ste prip. mohli pridat nejake tipy do tohoto clanku (taka v2.0)
#9
blizzboz 10.9.2010 07:39

mno ja v mojom CMS spájam všetky Javascriptové súbory do jedného pomocou PHP, to isté platí aj pre CSS.
#10
Emka 10.9.2010 10:11

srigi: Díky za zajímavý odkaz. Shrnu jeho obsah pro ostatní. Pokud používáte podmíněné komentáře pro nahrání separátního CSSka pro IE6, bude se načítat i v IE8 (interpretovat již ne) a vznikne mezera mezi vyřizováním požadavků. Řešení naleznete v odkazovaném článku od srigiho.

blizzboz: Ano, takto se to obvykle řeší v případě dynamických stránek. Ruby on Rails například v development režimu soubory nespojuje pro snazší debugging a automaticky je pospojuje až v production režimu na ostrém serveru.
#11
glabasnat 10.9.2010 11:49

Zdravím, s teorii souhlasím, ale výsledky měření jsou velice zavádějící.
Jde vidět veliké nesrovnalosti ve zpracovávaných časech. Například general.css se načítá mnohem déle než v druhém příkladě styles.css. Ostatně i u ostatních statických souborů jsou časy mnohem delší a různě skáčou. Toto přisuzuji nekvalitnímu a zahraničnímu hostingu.
Jinak měření se mohlo provádět několikrát pro větší přesnost celkového času.
Já jsem soubory nahrál na jiný hosting (jen dočasně cca do 20.9.2010)
http://www.nej-ceny.cz/t/test_01.html
http://www.nej-ceny.cz/t/test_02.html
http://www.nej-ceny.cz/t/test_03.html
Zde se mě časy pohybovali u prvního testu: stažení: 1.1s i s vykreslením 1.1s
Test2: stažení: 0.7s i s vykreslením 1.2s
Test2: stažení: 0.8s i s vykreslením 1.2s

Jinak aby se nečekalo na zpracování scriptu dá se použít atribut defer (Test3) u tagu script. Což většinou není vhodné (podobně jako dávaní scritu na konec stránky).
#12
Emka 10.9.2010 12:20

glabasnat: Ahoj, také zdravím. Ano, časy nelze srovnávat a také to v článku uvádím. Spíše než o celkový čas mi šlo o vysvětlení principu zrychlení díky paralelnímu vyřizování požadavků a snížení jejich počtu. S tvrzením, že atribut defer není vhodný souhlasím, nikoliv však s tím, že není vhodné dávat tag script (vzhledem ke zvýšení rychlosti) na konec stránky. Proč si tak myslíš?
#13
glabasnat 10.9.2010 12:38

Dávat tag na konec, případně použíti defer má své výhody i nevýhody.
Já jen, že když dám tag na konec stránky nemůžu pak přistupovat k funkcím v tom scriptu.
Například namapuje se nějaká událost (mouseout) na nějaký prvek, web je skoro celý načten a zobrazen ale načítají se scripty. Takže dát tag na konec není vždy vhodné. Velkou výhodu má převážně při využívaní externích služeb, statistiky, načítaní informací o počasí atd..

Jinak těším se na další články (ikdyž přestěhování na jiný hosting zlomilo čas 1.5s )

Zkoušel někdo rozšíření Speed Tracer pro Google Chrome? já byl z toho paf (nebo pif?), respektive trochu víc zmaten.
#14
Emka 10.9.2010 12:56

glabasnat: Defer oproti přidání tagu na konec má nevýhodu v tom, že se chová v různých prohlížečích dost nevyzpytatelně. To že mít script na konci dokumentu není bezbolestné je jasné avšak ne nereálné. Nebo lze použít v článku odkazovanou knihovna LABjs či podobné řešení. Tu poznámku o zlomení času jsem moc nepochopil? To bude asi tím, že je pátek.
#15
glabasnat 10.9.2010 13:02

Emka: to byla narážka na první díl
„Stránky ohodnocené jako rychlé se načítají pod 1,5 sekundy. Tam někde se budeme pohybovat po skončení seriálu.“
#16
Emka 10.9.2010 13:32

glabasnat: jo táák, to jsem nemyslel tak, že pod 1,5 s se dostane ten příklad, ale v nadsázce stránky čtenářů, až provedou optimalizaci . Ten příklad je opravdu jenom ukázka principu.
#17
Martin Talavášek 10.9.2010 23:49

Výborný, podrobný a názorný článek! Díky!

Mezi pokročilé metody zrychlování webu pak patří DATA URIs (http://blog.rival.cz/rychlost-webu-dil-iii/) a kešování „následující“ stránky s HTML 5 (http://blog.rival.cz/rychlost-webu-dil-iv/)
#18
Aleš Roubíček 11.9.2010 09:52

Gratuju k pěknému spotu. Mám však menší výhrady k bezhlavému spojování CSS i JS souborů. Sice se zbavíme jednoho problému (velkého množství HTTP požadavků), ale další problém přibude: velké CSS a JS soubory.

Položme si pár otázek:

1. Opravdu potřebuje handheld (typicky mobilní zařízení možná s mobilním datovým tarifem) stahovat jistě rozsáhlejší styly pro screen a print, když takové výstupy s velikou pravděpodobností nepodporuje? A nejde jen o stahování, ale i parsování takového stylu.

2. Jak často měníte tiskový styl oproti screen stylu? Nestačí pouze využít chytřejšího cachování a infrastruktury webu?

Samozřejmě nejde vyvozovat obecné závěry, protože každý web je svými požadavky specifický a pro každého funguje něco jiného.
#19
Emka 11.9.2010 12:10

Aleš: Dobrá připomínka. Také mám výhrady k bezhlavému spojování CSS a vždy bude záviset na konkrétním webu. Jinak bude vypadat blogýsek, jinak rozsáhlý web životně závislý třeba na návštěvnících z mobilních telefonů. Na druhou stranu, kdybych u každé věty v článku odbočil, nikdy bych článek nedopsal či v lepším případě jako kmet těsně před smrtí dokončil příručku pro webdevelopery o rozsahu Ottova slovníku naučného. Zmínka o handheldech by naboptnala o pokročilé CSS3 media queries, zjišťování user agenta návštěvníka atd.

Jsem rád, že tu jsou komentáře, kde jde na takové věci upozornit a ostatním to dává prostor se zamyslet. A mně také motivaci a témata k dalším článkům.
#20
gawan 20.9.2010 22:19

k téme ešte pripájam opačný názor:
http://www.smashingmagazine.com/2010/03/26/css-sprites-useful-technique-or-potential-nuisance
#21
Emka 20.9.2010 22:52

gawan: Nemyslím, že ten článek vyjadřuje opačný názor, spíše naopak. Jen více akcentuje fakt, že práce se sprajty je voser. A to nepopírám .
#22