Velký test sedmi webových prohlížečů

Slovo úvodem

Před několika lety se v dílně Mozilla.org nesměle objevil webový prohlížeč s hrdým názvem Phoenix. Krom svého hrdého názvu však nijak zvlášť z řady nevyčníval a ani se příliš nedostal do obecného povědomí uživatelů. Čas postoupil a z ne příliš známého Phoenixe se vyklubal Firebird, který si již pomalu našel cestičku i mezi obyčejné uživatele. Ani tento název však nebyl konečný a tentokrát se na scéně ukázal jako již dnes důvěrně známý Firefox.

Firefox měl hned zpočátku smělé plány. Mělo se jednat o rychlý webový prohlížeč oproštěný od většiny funkcí původní Mozilly a spolu se svými sourozenci měl časem Mozillu nahradit. Podle statistik a nedávných tahanic o další osud Mozilla Suite to vypadá, že se tato náhrada skutečně povedla. Jak to však vypadá s tou slibovanou rychlostí? Na to se můžete podívat v následujícím testu.

Na startovní čáru byla vedle Firefoxu postavena Mozilla Suite, Epiphany, Galeon a nedávno recenzovaný Kazehakase, kteří rovněž používají jádro z Mozilla Suite, Konqueror a Opera ve dvou verzích. Pro zajímavost byl do testu zařazen i DeerPark, tedy Alfaverze připravovaného Firofoxu 1.1. Prohlížeč Konqueror byl testován v prostředích KDE i Gnome, abychom zjistili, jak moc je spojen se svým domovským KDE.

Všechny nasazené prohlížeče

Jako testovací počítač byl zvolen starší notebook s procesorem Pentium II 366 MHz, 192 MB RAM s distribucí Gentoo a prostředím Gnome. Tento na dnešní poměry již poněkud starší počítač byl zvolen záměrně, jelikož zde byl reálný předpoklad, že naměřené hodnoty budou v širším časovém intervalu a méně se tak projeví chyby vzniklé měřením.

Každá zde zveřejněná hodnota je aritmetickým průměrem deseti měření. Žádná z naměřených hodnot se výrazně neliší od vypočteného průměru, jinými slovy průměr není ovlivněn jednou výrazně vychýlenou hodnotou. Takto získané hodnoty jsou pak dále přepočteny na procenta, přičemž jako 100 % byl použit údaj získaný u Firefoxu, aktuálně asi nejpoužívanějšího alternativního prohlížeče. Každý prohlížeč měl vytvořen nový profil, a byl tedy používán ve výchozím nastavení.

Rychlost startu

Na dobu spouštění prohlížeče má vliv řada faktorů. Nejvýrazněji se zde projevuje rozdíl mezi studeným a teplým startem prohlížeče. Studeným startem se rozumí první spuštění prohlížeče po nabootování počítače. Teplým pak každé další spuštění, kdy se různou měrou začínají projevovat diskové cache na všech úrovních a podobně. Rychlosti startů pak ještě dále komplikuje způsob spouštění prohlížeče. Rozdíl mezi dobou spuštěním prohlížeče s požadavkem na načtení určité stránky a spuštěním s prázdnou či žádnou stránkou byl u některých prohlížečů výrazný. Proto byla veškerá měření pro teplý i studený start prováděna ještě pro spuštění s požadavkem na načtení velmi jednoduché stránky z lokálního umístění a spuštění s prázdnou čí žádnou stránkou, dle možností prohlížeče.

Studený start

V tomto testu byly měřeny doby prvního startu jednotlivých prohlížečů. Aby měly jednotlivé prohlížeče rovné podmínky, měření probíhalo ihned po nabootování PC a bylo vždy provedeno pouze jedno měření jednoho prohlížeče.

Teplý start

Zde byly měřeny doby opakovaného startu daného prohlížeče. Před tímto testem byl každý prohlížeč cca 5× spuštěn a vlastní časy startu byly měřeny až po ustálení kolem určité hodnoty, kdy se prohlížeč mohl naplno „opřít“ o cache a podobně.

Výkon renderovacího jádra

Pro účely tohoto měření byla vygenerována stránka obsahující 3 000× tabulku o dvou sloupcích a sedmi řádcích. V tabulce byl obsažen jeden obrázek a vzhled tabulky byl zadán pomocí kaskádových stylů. Jelikož doby prvních několika vykreslení byly nepatrně delší, vlastní odečet hodnot začal opět až po pátém vykreslení, kdy již došlo k ustálení hodnot.

Použitá paměť

Paměť byla měřena ihned po spuštění prohlížeče s vykreslenou jednoduchou stránkou. Stránka byla vykreslena záměrně, jelikož z hodnot využité paměti bylo zřejmé, že například Kazehakase ihned po spuštění neinicializuje renderovací jádro Gecko. Poněvadž hodnoty po inicializaci bez jádra nemají žádný praktický význam, bylo potřeba ihned načíst alespoň minimální stránku.

Hodnoty byly odečteny programem top a bylo zachováno i jeho značení.

• Číslo označované VSZ ( VIRT) udává jinak řečeno velikost virtuální paměti procesu. To znamená jednak data, jednak i soubory procesem namapované do paměti (minimálně kód programu samotného a přilinkovaných knihoven).
• Druhé populární číslo se často označuje zkratkou RSS ( RES) a říká nám, kolik fyzické operační paměti program v danou chvíli skutečně zabírá. Zde nejsou ovšem započteny ani stránky paměti, které jsou zrovna náhodou odswapované.
• Hodnota SHR udává „sdílenou“ paměť. Např. libc má namapovaný prakticky každý program, a tak hezky nabobtná jeho velikost, ovšem přitom je v paměti ve skutečnosti samozřejmě pouze jediná kopie. Problémy vyvstávají kolem (obvykle vláknovitých) programů, které si spustí hromádku procesů společně sdílejících velkou část paměti – tu pak najdete započítanou u každého z procesů. top takovou paměť vypisuje ve sloupečku SHR  – to ovšem neznamená, že všechna ta paměť musí být nutně opravdu sdílená! Např. pokud je program dynamicky slinkován s nějakou obskurní knihovnou, pravděpodobně bude zahrnuta v SHR, i když jde o jediný proces, který v dané chvíli knihovnu využívá.

Jak je patrné, problematika využívání paměti není zdaleka tak jednoduchá, jak by se na první pohled zdálo, a proto je zapotřebí se na zde uváděné hodnoty dívat s jistým nadhledem a automaticky neodsuzovat ten či onen prohlížeč kvůli několika MB v určitém sloupci.

Za informace o unixové paměti děkuji Petru Baudišovi.

Co z hodnot vyplývá?

Konqueror

Zajímavých výsledků dosáhl Konqueror. Již před vlastními testy bylo zřejmé, že se jedná o nástroj úzce spjatý s KDE. Jako jediný si tak zasloužil privilegium a jeho starty byly měřeny jak v Gnome, tak v KDE. Při studeném startu se mu v Gnome opravdu příliš nevedlo a skončil beznadějně poslední. Naproti tomu v KDE se cítil takříkajíc jako ryba ve vodě a s přehledem zvítězil. Je to dáno tím, že při běhu KDE jsou již všechny potřebné knihovny v paměti. Při teplém startu již v obou prostředích předvedl velmi slušný výsledek. Pokud tedy používáte KDE, z rychlostního hlediska Konqueror rozhodně nezklame.

Kazehakase

Rozporuplně může působit nedávno recenzovaný Kazehakase. Jestliže má ihned po spuštění vykreslit i stránku, dosahuje „pouze“ mírně nadprůměrných hodnot, jelikož zároveň inicializuje i renderovací jádro. Pokud však tento požadavek vypustíme, je připraven k provozu doslova rychlostí samuraje. Vzhledem k tomu, že následné načtení vybrané stránky, zejména při pomalejším připojení, také nějakou dobru trvá, má Kazehakase čas během této doby inicializovat jádro, a nijak tím nezdržuje. V renderování pokusné stránky nijak neoslnil.

Je ale potřeba si uvědomit, a to platí pro všechny zde testované prohlížeče, že testovací stránka byla značně umělá. Při běžném používání se s webovou stránkou, kde vlastní HTML kód má téměř 1 MB a navíc obsahuje 3 000 tabulek, asi nesetkáte. K této situaci se můžete přiblížit snad jen používáním webového prohlížeče v roli FTP klienta. Prohlížečem prezentovaný HTML kód odpovídající obsahu adresáře na FTP serveru pak bez problému může dosáhnout i několika MB. To je však již prohlížeč používán k jinému účelu, než k jakému je primárně určen. Naopak typická stránka, jejíž velikost se obvykle nepřehoupne přes 100 KB a krom běžného formátování a několika sloupců na ní nic není, by byla pro testy nepoužitelná. Jestliže vám jde opravdu hlavně o rychlost nebo máte starší sestavu, Kazehakase vás nezklame.

Epiphany

Epiphany dosahoval velmi podobných výsledků jako Kazehakase. Vzhledem k v podstatě stejné koncepci, tedy Gecko v GTK 2 kabátku, se není ani moc čemu divit. Jediný výraznější rozdíl byl v okamžité inicializaci jádra, a tedy už tak neohromí startem. To ovšem neznamená, že by byl v praxi pomalý.

Galeon

Naopak docela zklamáním byl Galeon. Jelikož pro něj platí totéž co pro Epiphany a Kazehakase (GTK 2 GUI + Gecko), očekával jsem i podobné výsledky. Ve startech ale docela zaostával. Pokud vás Galeon nepřesvědčil jinými než zde testovanými kriterii, o změně tímto směrem nemá asi cenu příliš uvažovat.

Opera

Opera je prohlížeč, který před nedávnem povýšil verzi nad rámec běžných bezpečnostních aktualizací, a tak byl pro zajímavost otestován ve dvou verzích. Výkony obou verzí jsou velmi podobné, až na starty s požadavkem na načtení stránky. Zde dokáže nová Opera nějakou tu sekundu ušetřit. Pokud k tomu přičteme bezpečnostní opravy, nad přechodem na „osmičku“ nemá cenu příliš polemizovat. Pokud Operu ještě nepoužíváte, příliš nelpíte na licenci a navštěvujete stránky, které se svým rozsahem vymykají běžným standardům, nebo naopak nemá váš počítač paměti nazbyt, Opera by pro vás mohla být tím pravým.

Firefox a Mozilla Suite

Na závěr jsem si nechal dva, respektive tři, rivaly ze stejné stáje. Firefox ve dvou verzích a Mozilla Suite. Pokud bych měl dle získaných dat ohodnotit smělé plány Firefoxe zmiňované v úvodu, tak do jisté míry se mu splnit podařily. Do jisté míry proto, že ve všech kategoriích našel přemožitele, a to někdy i dost výrazné. Je tedy co zlepšovat a DeerPark zatím předvádí spíše mírně opačný trend. Vzhledem k tomu, že se jedná teprve o Alfa verzi, je na hodnocení zatím velmi brzy. Přihlédneme-li navíc i k novým funkcím, dovolím si tvrdit, že situace s výkonem mohla být i výrazně horší.

A co se Mozilla Suite týče, její další verze již pod hlavičkou Mozilla Foundation nevyjde. Situace však není beznadějná a o její další vývoj se postará samotná komunita. Nezbývá než doufat, že všem tato změna prospěje. Mozilla Suite by se krom nového názvu mohla dočkat i svěžího větru do plachet a v Mozilla Foundation se nebudou zbytečně štěpit síly mezi dva podobné projekty.