rarouš.weblog

Výkon webových stránek můžeme obecně zvýšit snížením počtu dotazů na server, snížením objemu přenášených dat, optimalizacemi HTML kódu a v neposlední řadě optimalizací výkonného kódu aplikace. První tři pravidla lze uplatnit i na obyčejných prezentacích, proto se na ně podíváme blížeji.

Snížení počtu dotazů na server

Prvním krokem v optimalizaci by mělo být snížení počtu dotazů na server. Čím víc dotazů, tím více se musí přenášet dat, tím více musí server vynaložit prostředků na jejich obsloužení.

Snažte se snížit počet souborů, které vaše stránka tahá s sebou. Pokuste se sloučit externí skripty do jednoho souboru, stejně tak stylopisy. Místo toho, abyste měli zvláštní stylopis pro tisk, využijte pravidla @media print. Dále omezte @import pravidla na minimum. Další spoustu dotazů mají jistě na svědomí obrázky. Využijte chytře techniku spojování obrázků a snižte tak počet dotazů na minimum.

Dalším krokem ke snížení počtu dotazů je správně nastavené kešování. Většinou se setkávám s tím, že kešování není řízeno vůbec nebo je rovnou zakázáno. To považuju za velikou chybu. Místo zakázání kešování, zkuste nastavit cache na minutu, dvě. Nedělejte to však pomocí meta tagů, to nemá žádný význam. Posílejte HTTP hlavičky. Např. Cache-Control: public, must-revalidate, proxy-revalidate, max-age=120 nastavuje veřejné kešování na dvě minuty a za tuto dobu musí jak lokální, tak proxy cache stránku obnovit.

Dalším účinným pomocníkem je Entity Tag – ETag. ETag je hash obsahu. Pokud se obsah změní, změní se i hash. Tento hash je posílán v hlavičce klientovi a ten ho může připojit do opětovného dotazu. Pokud se obsah na serveru nezměnil, server odpoví kódem 304 Not Modified. V takovém případě je odpověď krátká a přenáší se jen několik bajtů a klient ví, že může použít lokální verzi.

Správným nastavením hlaviček Cache-Control a ETag můžete svému serveru hodně odlehčit.

Snížení objemu přenášených dat

Když už máme snížený počet dotazů – tedy zátěž serveru, ve druhém kroku bychom se měli pokusit snížit trafic – množství přenášených dat. Zkoušel jsem několik technik. Rád používám XHTML protože ho pak můžu zpracovávat pomocí obecného XML readeru. A XHTML vyžaduje oproti HTML o dost bajtů navíc. Proto jsem si udělal takový malý benchmark mojí titulní stránky. Rozdíl mezi HTML a XHTML verzí je cca 3 %. Pak jsem zkusil ořezat přebytečné bílé znaky. Tam už to bylo o něco lepší úspora 13 %. Kombinace HTML bez bílých znaků pak je na šestnácti 16%. Je to sice pěkné číslo, ale zase taková úspora to není.

Proto jsem nasadil kompresi. Ta konečně přinesla kýžený výsledek – úspora 64 %. Docela zajímavý nástroj, který vám zjistí, zda kompresi používáte a kolik byste byli schopní uspořit, najdete na stránkách www.aspnetresources.com. Zkoušel jsem pokusně české portály a kompresi používá pouze Seznam.cz. Přitom zcela jistě ji dříve používal i Atlas.cz, nechápu, proč už není zapnutá.

Jak zprovoznit kompresi na vašem serveru? Pokud máte IIS 6 a možnost nastavit si server sám, tak detaily najdete v článku Enabling HTTP Compression (IIS 6.0), v případě IIS 7 zase v článku Changes to compression in IIS7. Pokud k nastavení serveru přístup nemáte, můžete použít HttpModul pro kompresi. Uživatelé Apache jistě znají mod_deflate a mod_gzip.

Správně nastavenou kompresí ušetříte trafik. Ať už platíte vy nebo váš poskytovatel, je nejen ekonomické ale i solidární mít kompresi zapnutou.

Optimalizace kódu stránky

Správně napsaným kódem se dá zrychlit vykreslování stránky.

• Pokud je vaše stránka well-formed a je validní, může být její vykreslení mnohem rychlejší.
• Pokud nastavíte obrázkům rozměry, bude vykreslování stránky plynulejší a nebude se nepříjemně natahovat.
• Pokud u dlouhých tabulek správně použijete thead, tfoot a vícero tbody, taktéž docílíte rychlejšího zpracování stránky.
• Pokud externí skripty a jiné větší objekty, na jejichž zpracování musí prohlížeč čekat, připojíte až na konec stránky, nebude se na ně zbytečně čekat na začátku nebo uprostřed. Je to třeba častý nešvar magazínů, kde se vám načte perex, pod ním se 20 sekund načítá reklama a pak najednou nablikne zbytek stránky.

Spoustu zajímavých tipů na zrychlení najdete ve vývojářské části Yahoo v článku Best Practices for Speeding Up Your Web Site. Užitečný nástroj ze stejné dílny, který vám stránku zkontroluje přímo ve vašem prohlížeči je Add-on do Firebugu s názvem Y-Slow.

Mnoho z vás si jistě řekně, „k čemu bych měl optimalizovat, když moje stránky navštěvuje pár lidí denně?“ Já jsem toho názoru, že plýtvat se nemá. Doma taky určitě nemáte neustále otevřený vodovodní kohoutek…

Velmi často se ve zdrojových kódech HTML stránek potkávám se zajímavým mýtem a to s následujícím ta­gem:

<meta http-equiv="pragma" content="no-cache">

Autor se tím pravděpodobně pokouší docílit toho, aby se jeho stránka necachovala. Přejdu-li to, že vypnutí cachování je nesmysl už z pohledu škálování výkonu webové aplikace, tak stejně užití pragmy nemá hlubšího významu.

Proč je použití Pragma:no-cache nesmysl

1. Hlavička Pragma s hodnotou no-cache je součástí specifikace HTTP 1.1 z historic­kých důvodů a je dnes plně nahrazena hlavičkou Cache-Control.
2. Hlavička Pragma je pouze hlavičkou požadavku a v odpovědi nemá opodstatnění.

Hlavičku Pragma:no-cache posílali klienti HTTP/1.0 když nechtěli dostat cachovanou odpověď z lokální nebo proxy cache, ale přímo od serveru, který volali. Posílat ji tedy v odpovědi (natož v HTML) nemá žádný význam. Někdo by mohl podotknout, že mu to funguje. Mícrosoft na to říká: strkejte si pragmu do HTML, ale my vás stejně budem cachovat. Mozilla raději řídí cachování pomocí HTTP hlaviček a tento tag také ignoruje.

Závěr

Nejprve si rozmyslete, zda je pro vás zakázání cachování opravdu přínosné – v 99% případů nebude. Pokud stejně nebudete chtít cachovat (každý požadavek bude váš server muset vždy zpracovat, bude muset protéct po vaší lince atd.), posílejte HTTP hlavičku Cache-control s hodnotou no-cache. Vkládání do meta stránky nemá opodstatnění, zbytečně tak zvětšíte opověď a prohlížeče to stejně většinou ignorují.

Tagy: HTML, Pragma, Cache

Mikroformáty jsou určeny pro snadnější získávání dat ze stránek, jak pro lidi, tak pro stroje. Jedním z problémů je, jak vkládat data a časy, aby byly pochopitelné pro lidi i snadno vyparsovatelné strojem.

Způsobů zápisu data a času existuje nespočet. Snad každý stát/jazyk definuje jiná pravidla pro jejich zápis. Ruku na srdce, kdo z nás přesně ví, jak správně zapisovat datum a čas v naší mateřštině? Případ od případu se může lišit a i správných způsobů je hned několik. Pro přenos časové informace existují standardní formáty, ale ty jsou pro lidi mnohem méně srozumitelné. Jak skloubit snadnou čitelnost pro lidi i stroje?

Mikroformáty na scénu

Kupodivu mnoho mikroformátů obsahuje i definici pro některý časový údaj. Naštěstí, každý to neřeší jinou cestou, ale používá se návrhový vzor pro zápis data a času. V tomto vzoru se používá tag abbr, který uzavírá „lidskou interpretaci“ data a času, a v atributu title jeho strojovou podobu dle ISO 8601. Navíc se ještě využívá návrhového vzoru třída pro definování, co datum právě vyjadřuje.

Datum publikace článku můžeme zapsat následujícím způsobem:

Publikováno
<abbr class="published"
  title="2008-04-20T10:00:00Z">
  20. dubna 2008 ve 12.00
</abbr>.

V ukázce si můžete všimnout, že čas se v atributu title neshoduje s „lidskou“ podobou. Je to dáno tím, že jde o vyjádření tzv. univerzálního času UTC. Ekvivalentně lze zapsat jako středoevropský letní čas 2008-04-20T12:00:00+02:00.

Výpis v dotnetu

V ASP.NET se dají pro správný výpis použít dvě metody třídy System.DateTime. Tou první je metoda ToUniversalTime(), která čas převede na UTC, a tou druhou je ToString("s"), která vytvoří textovou podobu tzv. seřaditelného času. Nezapomeňte však přidat písmeno Z, vyjadřující UTC.

<abbr class="published"
  title="<%= item.DatePublished.ToUniversalTime().ToString("s") %>Z">
  <%= item.DatePublished.ToString("f")%>
</abbr>

Bohužel, žádný ze standardních formátů přesně neodpovídá tomu, který potřebujeme. Ale je tu možnost použít vlastní formát pro univerzální vyjádření času yyyy'-'MM'-'dd'T'HH':'mm':'ss'Z' nebo yyyy'-'MM'-'dd'T'HH':'mm':'sszz pro System.DateTimeOffset.

Tagy: microformats, asp.net

Minulý týden jsme si prodiskutovali pár mýtů na téma HTML vs. XHTML. Zjistili jsme, že v HTML 4 jsou hodnoty atributů id a class citlivé na velikost písmen (přinejmenším v CSS a JavaScriptu). Shodli jsme se na tom, že DTD je přežitek, a že za spoustou mýtů stojí prasata, která jsou podvědomě spojována s HTML.

Dneska si povíme o jedné věci, která nám možná přidá na hodnotě XHTML a tou jsou mikroformáty.

Mikroformáty

Mikroformáty jsou sémanticky obohacené části XHTML kódu. Ačkoli se pro jejich definovaná využívá atributů (class, rel, rev…), které jsou samozřejmě definovány v HTML, k získávání jejich cenných dat se obecně využívá XML parserů. Proto je lepší mít stránky v dobře sestaveném XHTML, než v plně validním HTML – samozřejmě pokud chcete mikroformáty využívat. Ale proč by ne.

Uživáme v praxi

Když se podíváte do pravého sloupce (možná je až dole), na první pohled tam nenajdete nic zajímavého, vlastně kecám. Hned nahoře jsou moje kontaktní údaje, k jejich definici jsem použil mikroformátu hCard, který slouží k popisu vizitkových dat a je kompatibilní se standardním formátem vCard.

O kousek niž je další box s titulem Kolegové a kamarádi, není to nic jiného než blogroll s odkazy na mé kolegy, kamarády a další dobré lidi :). Při jeho tvorbě jsem použil špetku mikroformátu zvaného XFN. Tento slouží k definici meziblogových vztahů.

Mezi těmito boxy je jiný, tako co žádný mikroformát nepoužívá, ale informuje o tom, že stále hledám nějakého šikovného kolegu, co umí dobře C# a chtěl by se mnou spolupracovat na Atlasu firem a s ním spojených interních systémech. Práce je to opravdu zajímavá, rozšíříš si obzory a navíc možnost pracovat s tak milými a sympatickými lidmi…

S čím na ně?

Jo k praktickému využití mikroformátů ještě schází podpora v prohlížečích. Do odnoží firefoxu se dá doinstalovat nástroj Operator, který je určitě dobrým pomocníkem při vývoji a je propojen na některé služby, které s MF umí pracovat. Nativní podpora pro mikroformáty je slibována ve Firefoxu 3 a Internet Exploreru 8 (znamená to, že bude konečně umět XHTML?). Dále se po internetu válej nějaký skripty, které slouží k transformaci na jiné formáty, CSSka pro zvýrazňování mikroformátů ve stránce a tak.

Tagy: Microformats, XHTML

DGX se rozhodl vydat článek s titulkem Konečně pravda o XHTML a HTML a moudře zakázal komentáře, protože toto je stále téma, které dokáže pěkně blafnout. Díky tomu můžu napsat svůj komentář u sebe.

1. Dovolil bych si nesouhlasit s následujícím tím, úryvkem, z části Prasárny.

   XHTML kód zase třeba používáním řetězců abc, AbC, aBC pro různé třídy.

   Hodnoty atributů class a id jsou stejně case-sensitive jak v HTML, tak v XHTML. Pokud se tak nechoval např. Netscape 6-, byla to chyba jeho interpreteru CSS.

2. Můj názor na DTD v XHTML je již nějakou dobu celkem jasný – přináší jen problémy, stěžuje rozšiřitelnost. Užívejme raději schéma a jmenné prostory. Jediný důvod k použití DTD v XHTML je, bohužel, přepínání prohlížeče do standard modu.
3. Dle mého názoru je velkou výhodou XHTML v čisté podobě to, že je lépe čitelné pro lidského čtenáře, protože se může lépe orientovat (vizuálně), kde daný element končí a kde začíná.

Největším problémem bezesporu je XML samotné. Jeho striktnost a jednoznačnost vyvolává v kreativní části lidstva ranní nevolnost. Jak jinak si vysvětlit, že ani relativně velké firmy nejsou schopné dodávat dobře sestavené dokumenty?

Tagy: XHTML