Rychlost stránek

Protože na dnešním Internetu je spousta konkurence, je těžké čtenáře upoutat. Rychlost načítání a zobrazování stránek je přitom klíčová veličina.

Co ovlivňuje délku čekání

• Datová velikost stránek včetně obrázků
• Ukládání stránek na klientovi (cache)
• Struktura stránek (tabulky a pod.)
• Rychlost serveru
• Propustnost linky

Datová velikost

Průměrnému uživateli se jeden kilobajt načítá asi půl sekundy až sekundu. (Existují samozřejmě rozdíly, to je jen pro ilustraci.) Průměrná velikost stránky (bez obrázků) na webu je asi 5 až 10 kB, z toho vychází dvě až deset sekund na načtení stránky. Naneštěstí je navíc nutno započítat dobu na stahování všech objektů stránky, v to patří:

• obrázky
• rámy
• externí stylopisy (css soubory)
• klientské skripty (externí JavaScript)
• applety, různé objekty
• no a samozřejmě samotný text stránky

Je žádoucí, aby celkový součet datových objemů byl co nejmenší.

Obrázky

Zásadní roli přitom hrají obrázky, protože jsou nejčastější a většinou datově největší objekty na stránce. Ty lze zmenšit:

• zmenšením skutečných rozměrů (menší obrázky jsou datově menší)
• použitím kompresních formátů jpeg a gif
• jpg se komprimuje nastavením míry komprese
• gif se komprimuje lépe, je-li jednoduchý, proužkový a má nižší barevnou hloubku

Podrobnější tipy na kompresi včetně tabulky velikostí jsem popsal u přípravy obrázků.

Datová velikost textu 

Závisí jednak na délce textu (s tím nic nenaděláme) a na formátování. Formátováním myslím různé deklarace písma, barev a tak. Je běžné, že se tyto deklarace zadávají mnohokrát častěji, než je třeba. To způsobují převážně editory.

Odhaduji, že v dnešním Internetu jsou stránky průměrně dvakrát datově větší, než by musely být. (Existují i texty zprasené natolik, že jsou až desetkrát větší, než je nutné, ale to je extrém.)

Jak textům datově odlehčit:

• podívat se, co produkuje můj editor a donutit ho nějak, aby byl úspornější
• používat CSS styly, zejména externí stylopis (css soubor). Styly totiž umožňují nadeklarovat vlastnosti písma celé stránce najednou (externí stylopisy dokonce všem podobným stránkám najednou) vcelku úsporně
• nutno připustit, že rámy ulehčí textovým souborům o text menu s odkazy (jinak rámy rád nemám)

Skripty, definice rámů, applety, stylopisy, hudba

Všechny odkazované vložené objekty se do výsledné velikosti stránky také přičítají, ale zpravidla nehrají vážnější roli, protože bývají malé (s výjimkou appletů), nebo nejdou moc zmenšit (applety).

Jedinou záludností je zde počet http spojení. Na otevření protokolu pro každý soubor jsou potřebná také nějaká data (http hlavičky) a pokud je takto načítaných objektů příliš mnoho, tak to může způsobit zpomalení. Názory na míru tohoto zpomalení se různí, já osobně nevím.

Paralelní načítání

Když prohlížeč při analýze dokumentu narazí na obrázek (obecně jakýkoli odkazovaný objekt), tak se ho pokusí stáhnout ze serveru okamžitě. Naváže http spojení se serverem a obrázek stahuje současně se zbytkem stránky. Tímto způsobem se ze serveru může zároveň načítat velmi mnoho objektů.

Takové paralelní stahování je ve většině případů žádoucí. Někdy ale stahované obrázky ucpou linku, takže se načítání vlastního textu stránky velmi zpomalí. Autor stránek s tím nemůže nic moc dělat, nicméně čtenáři si kvůli tomu rádi vypínají obrázky.  

Cache paměti

Různé vyrovnávací paměti, "Temporary Internet Files" a cacheovací proxiny využívají jednoduché myšlenky: proč stahovat znovu něco, co už mám stažené? 

Prohlížeč se při analýze stránky u každého objektu (třeba obrázku) napřed podívá do své cache paměti, jestli tam ten objekt už nemá. Pokud ho najde, tak ho nestahuje. (Podle svého nastavení se maximálně podívá, zda se objekt na serveru nezměnil (stáhne si pouze datový údaj)). To samozřejmě velmi zrychluje celkové načítání stránky. 

Filosofická odbočka: znáte ekologickou poučku, že "nejlevnější energie je ta, kterou není třeba vyrobit"? Parafráze: nejrychleji přenesená data jsou ta, která není nutno přenášet. 

Požadovaná data se v cache paměti (čti [keš]) vyskytují překvapivě často, protože příbuzné stránky ze stejného serveru mají ve zvyku načítat stejné obrázky. Klasickým příkladem je pozadí nebo logo firmy. Při stahování první stránky serveru se obrázky stáhnou, při dalším procházením stránek se čtou z cache paměti. Dá se formulovat obecné pravidlo: 

Na všech příbuzných stránkách používejte tytéž obrázky. To se týká všech načítaných objektů: externích stylopisů nebo knihoven skriptů.

Hrubou chybou je umisťování stejných obrázků do webu jako soubor vícekrát na různá místa, protože pak prohlížeč nemá šanci zjistit, že je to to samé. Postrachem webmasterů jsou v tomto ohledu marketingoví manažeři, kteří by chtěli mít logo na stránkách třikrát různě velké a dvanáctkrát jinak otočené.

Načítání dopředu 

Někteří autoři razí myšlenku tzv. vstupní chodby (termín jsem nalezl u Satrapy), což je úvodní stránka serveru, na které skoro nic není, jenom maximálně jméno firmy/serveru, pár vět a odkaz na hlavní stránku. Většinou to sice pokazí nějaký zbytečný velký obrázek, ale i tak je vstupní chodba dokonalým místem pro načítání obrázků dopředu. 

Dejme tomu, že budu chtít předem načíst logo firmy. Obrázek s logem umístím na závěr stránky vstupní chodby a zneviditelním ho (rozměry 1, 1 a display: none). Prohlížeč si ho načte a až uživatel přejde na hlavní stránku, bude logo už načtené. 

Obrázků může být samozřejmě více. Dají se dokonce dopředu načítat celé stránky pomocí neviditelného elementu <iframe>. Problematika před-načítání objektů je široká; její techniky se používají hlavně při skriptování. 

Nutno poznamenat, že neviditelné načítání dat může pozorného uživatele pěkně zmást -- pokud tedy bude čekat na dokončení načítání. 

Fyzické umístění cache paměti

Když už píšu o cache pamětích prohlížečů, tak Internet Explorer si ukládá data do c:\windows\Temporary Internet Files, ostatní prohlížeče do podsložek vedle své instalace. Pokud někomu cache paměť vadí při testování stránek, může si tyto soubory smazat. Ale Internet Explorer (a možná i jiné prohlížeče) si udržuje posledních pět stránek i v RAM paměti (takže se musí i zavřít a otevřít prohlížeč).

Rychlost zobrazování

Chtěl bych zdůraznit rozdíl mezi načítáním a zobrazováním.

• Načtená data jsou ta, která dorazila do prohlížeče
• Zobrazení -- to, co vidí čtenář -- tomu ale ještě nemusí odpovídat.

Mnoho stránek je špatně strukturovaných. Prohlížeč pak sice načítá data slušným tempem, ale dlouho je vidět pouze bílá plocha. Nebo text různě poskakuje během načítání.

Trocha psychologie: mám-li už co číst (začátek stránky), příliš mi nevadí, že stránka není načtená celá. Na druhou stranu pokud musím koukat na prázdnou stránku (maximálně s nějakým logem), tak mě to pěkně otráví.

Problémy se zobrazováním jsou způsobeny:

• příliš velkou tabulkou (mnohdy přes celou stránku)
• nerozměrovanými obrázky
• kombinací velkých tabulek a nerozměrovaných obrázků (to je pak katastrofa)
• při použití rámů jejich složitou strukturou

Velké tabulky

Jednoduše řečeno: tabulka se zobrazí až po té, co se načte celá. Pokud je v jedné tabulce celá stránka, tak prohlížeč prostě čeká na poslední písmenko a teprve potom to vykreslí. Autor, který ladí stránku na lokálním disku, si tento problém neuvědomí, protože k němu poslední písmenko dorazí rychle.

Je to skličující skutečnost; tabulka přes celou stránku byl donedávna jediný způsob, jak dát stránce trochu slušný design (pokud nechci používat rámy). Tvůrci prohlížečů a jazyka HTML tak utekli skřetům, aby se nechali chytit vlky. Řešení jsou pracná:

• Rozdělit tabulku do několika menších tabulek
• Nepoužívat tabulky a design udělat pozicováním

Většina ambiciózních serverů dnes svízel s velkými tabulkami ignoruje a nechává své čtenáře čekat.

Rozměrování obrázků

Když u obrázku (tag <img>) uvedu rozměry (atributy width a height), tak si prohlížeč pro ten obrázek vymezí místo. Když je neuvedu, tak prohlížeč po natažení začátku obrázku musí přepočítat zobrazení, což jednak poskočí a jednak to na pomalejších počítačích docela zdržuje.

Tabulky + nerozměrované obrázky

Tabulka se zobrazí, až když se načte celá, ale 

• pokud obsahuje rozměrované obrázky, tak na ně nečeká. 
• Když se ale obrázky uvnitř velké tabulky nerozměrují, tak celá ta velká tabulka čeká, než dorazí všechny obrázky a teprve potom se zobrazí (bojí se totiž, že neznámé obrázky budou moc široké).

Tento případ klasicky nastává u počitadel. Málokdo má ve zvyku počitadlo rozměrovat (protože prostě bývá různě velké), navíc se počitadlo stahuje dlouho, protože se počítá. Je-li uvnitř tabulky, celá tabulka na něj čeká. To může způsobit naprostou nefunkčnost stránky. Kromě počitadel je to běžné i u reklam.

Komplikovaná rámová struktura

Rámy se načítají paralelně, ale mají prioritu vždy ve stejném pořadí: napřed se načítají horní a levé. Rám s vlastním textem bývá v pravém dolním rámu, který se natahuje naposled. 

Rychlost serveru

Na rychlosti serveru se podílí:

• Náročnost zvoleného řešení (serverové skripty)
• Rychlost a kvalita hardwaru
• Zatíženost serveru
• Softwarový server a jeho konfigurace

Ty tam jsou doby, kdy autor stránek musel být zároveň správcem serveru. Dnes je obecnou praxí hostovat někde na páteřní síti u profesionálních poskytovatelů. Ve většině případů už nemůže autor stránek serverovou složku rychlosti nijak ovlivnit (až na použití serverových skriptů). No ale kdyby to někoho zajímalo:

Náročnost serverového řešení

V poslední době stoupá obliba serverových skriptů, zejména PHP. Serverové skripty umožňují hodně věcí, přičemž ale není problém napsat aplikaci, která bude velmi pomalá a zároveň bude zatěžovat server. Pokud s psaním serverových skriptů začínáte, tak to nepodceňujte. 

Rozdíl mezi rychlostí odeslání obyčejné HTML stránky oproti serverovému skriptu 

• nemusí být podstatný, 
• ale může být podstatný (zejména u větších stránek na pomalejších serverech).

Nechápu autory (a je jich hodně), kteří se snaží i banální stránky psát v PHP, když by stačilo HTML. Přitom často zbytečně používají databáze, které celý proces generování také někdy zpomalují. 

Velké servery (zpravodajské služby, katalogy) databáze používat musejí, proto kvůli urychlení používají "předgenerování" stránek. Stránka se na serveru jednou sestaví dynamicky, ale uloží se do statického souboru. Některé technologie používají předgenerování implicitně (JSP servlety, XML translety). 

Hardware 

Říkat, že na provoz web serveru je novější počítač lepší než starší, je zbytečné. Otázka ale zní o kolik je horší -- je to otázka míry. Má smysl investovat do lepšího stroje? Obecně nelze odpovědět. Ale máte-li stránky na stroji, který má málo volné paměti a pomalý disk, přemýšlejte o nějaké změně. 

Zatíženost serveru

Do stejné kategorie s hardwarem patří i otázka zatíženosti. Obecně se o tom zase nedá říci skoro nic. Jestliže jeden počítač funguje zároveň jako LAN-server, pracovní stanice a web server, je to asi špatně (třebaže Radimův domácí Linux takhle fungoval bez restartu přes půl roku). Ale i stroj, který funguje pouze jako web server, může být přetížený, pokud na něj přichází příliš mnoho požadavků nebo na něm běží příliš mnoho služeb. 

Softwarový server a jeho konfigurace

Mezi nejčastější zástupce serverů patří IIS od Microsoftu a volně šiřitelný Apache. Oba mají srovnatelný výkon, v poslední době věřím spíše Apachi. Oba servery se dají snadno konfigurovat a u obou je snadné konfiguraci nějak zkazit, takže je pak server pomalejší. Jde tam o různé moduly a podobné věci. Moc tomu nerozumím, proto raději svěřuji správu serveru povolanějším odborníkům. 

Rychlost linky

Když ženete ovečky přes propast, tak je jejich rychlost dána nejužším místem mostu. Podobně je to s přenosem dat: rychlost je určena nejméně propustnou linkou. Úzké místo může být:

• linka u klienta (čtenáře) -- často modem
• linka od serveru na páteř

Páteř je výraz pro páteřní síť, což je pár docela dost rychlých kabelů, které propojují hlavní internetové uzly. Je to tak rychlá síť, že by se na ní úzké místo (ve smyslu přenosu stránek) hledalo dost špatně.  

Rychlost linky u klienta rozhodně neovlivníte. Rychlost linky od serveru na páteř je to jediné, co vás musí zajímat. Jde o to, aby nebyla pomalejší než běžné připojení uživatelů (modem 56). Přitom je ale třeba počítat s reálnou (nikoli s nominální) propustností. Velký objem přenášených dat reálnou propustnost linky zpomaluje. Pokud třeba na serveru běží Napster stahující hafo MP3ojek nebo pokud je přes linku napojena podniková síť, tak vydělte nominální propustnost dvěma, třemi, čtyřmi. 

Hodně poskytovatelů dnes nabízí web hosting přímo na páteři (včetně freewebů a poskytovatelů připojení zdarma). V tom případě starosti s rychlostí linky odpadají. 

Vizte též: Základy nastavení serveru, Design pomocí tabulek, Příprava obrázků pro web, CSS - Kaskádové styly, Programování stránek

O tvorbě, údržbě a zlepšování internetových stránek. Základy HTML CSS FrontPage Hledání