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í

Tato stránka probírá zmíněná témat jedno po druhém. Chcete-li detailnější vhled do problematiky, podívejte se do článku na co stránka při vykreslování čeká.

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ří:

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:

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:

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é, 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 čas, takže pokud je takto načítaných objektů příliš mnoho, může to způsobit zpomalení. Názory na míru tohoto zpomalení se různí, já osobně nevím.

Externí skripty

Asi největší brzdou současného webu (aktualizováno 2005 a 2015) jsou externí skripty, tedy soubory s javascriptem uložené vně stránky v jiném souboru. Ty se sice také stahují paralelně, ale stránka při vykreslování čeká, než dorazí konec skriptu. Obzvlášť problematické jsou pak externí javascriptové kódy reklam, protože ty jsou často nastaveny tak, aby se na klientovi nekešovaly.

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.

Množství požadavků před textem

Velký problém dělá, když je na začátku stránky (typicky v sekci <head>) umístěno větší množství odkazů na skripty a styly. Pro každý takový styl a skript musí prohlížeč navázat nové http spojení, což zabere dost času. Potom musí prohlížeč počkat, než dorazí kompletní soubor, než začne pokračovat v dalším vykreslování stránky.

Pokud jste se někdy divili, jak je možné, že Google funguje tak rychle, pak část tajemství je právě v tom, že do výsledků vyhledávání nenačítá žádný externí skript ani styl. Žádný, nula.

Já do svých stránek načítám vždy právě jeden css styl. Považuji to za vhodné, protože mám obvykle dobře nastavené kešování, a tak je tento soubor dostupný z keše při příštím načtení stránky ze stejného webu. Víc než jeden styl bych si ale připojit netroufnul. Javascripty umisťuji na konec stránky, aby se načítaly až poté, co se stránka uživateli zobrazí.

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 na Win 98 si ukládá data do c:\windows\Temporary Internet Files, na Win 2000 do osobní složky Documents and Settings, 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č).

Více o keších se dozvíte v mém překladu Kešovacího návodu pro autory webu a webmastery.

Rychlost zobrazování

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

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í.

Psychologie čtenáře: 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:

Velké tabulky

Jednoduše řečeno: tabulka se zobrazí až po té, co se načte celá. (Aktualizace 2004: platí to tak zejm. v Internet Exploreru, ale ten je stále velmi důležitý. Ostatní prohlížeče s touto chybou se už moc nepoužívají.) 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í ale jsou:

Většina ambiciózních serverů dnes svízel s velkými tabulkami ignoruje a nechává své čtenáře čekat. (Aktualizace 2004: už je to trochu lepší, dost webmasterů se naučilo obtékané divy.)

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 

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.

V novějších prohlížečích (aktualizováno 2004 mj. pro IE6) se tento problém už nevyskytuje -- prohlížeč si vymezí nějakou malou oblast a tabulku vykreslí relativně brzo.

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. 

Obsahuje-li horní rám hodně obrázků
přičemž
levý rám
asi také 
obsahuje
hodně 
obrázků,
tak se linka ucpe paralelním přenosem mnoha souborů, mezi nimiž má hlavní text malou prioritu.

Takže se zobrazí pozdě.

Rychlost serveru

Na rychlosti serveru se podílí:

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 

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 domácí Linuxy mých kamarádů takhle fungují bez restartu několik let). 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 (a nesrovnatelnou cenu -- Apache je zdarma), 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:

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 tedy 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, pěti, deseti...

Většina 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í. 

 

Reklama

www.webhosting-c4.cz, webhosting s doménou v ceně. 20GB
o tvorbě, údržbě a zlepšování internetových stránek

Návody HTML CSS JavaScript Články Ostatní

Základy Prvky stránek Tvorba webu

Jak psát web píše Yuhů, Dušan Janovský. Kontakt.