JSMeter: Cesta do hlubin webové stránky

Jak vypadá Javascript na těch nejznámějších webových stránkách a proč ho dnes nelze spolehlivě měřit populárními benchmarky SunSpider, V8 nebo Dromaeo.

V posledním měsíci jste se u nás mohli podívat hned na několik javascriptových benchmarků. Nejprve jsem srovnal Operu s Chromem, v dalším článku pak nový Internet Explorer 9 s konkurencí a nakonec i „Devítku“ s testovací verzí Firefox 3.7. Používal jsem populární testy SunSpider od autorů jádra WebKit, V8 testování od Googlu a Dromaeo od tvůrců jádra Gecko, které používá třeba Firefox.

Ve všech z těchto článků jsem zdůrazňoval, že podobná testování lze velmi snadno marketingově zneužít, a pokud je v jednom z dílčích testů Dromaea Opera 10.50 čtyřicetkrát rychlejší než Internet Explorer 8, neznamená to, že se vám snad stránky Živě.cz namísto jedné sekundy vykreslí v Exploreru až za necelou minutu.

V dnešním článku tento výrazný rozdíl mezi teorií javascriptových benchmarků a praxí každodenního surfování vysvětlím a na pomoc si vezmu studii Microsoft Research JSMeter. Možná se teď zaleknete a řeknete si, že to bude beztak nějaká podplacená studie, tak tomu ale není. JSMeter není další z mnoha benchmarků, který má podivným číslem vyjádřit, o kolik je prohlížeč rychlejší než konkurence. Naopak se jedná o studii, která hodnotí kvalitu Javascriptu na konkrétních webových stránkách a jeho analýzou se nás snaží přesvědčit, že je třeba podobné benchmarky jako SunSpider, V8 nebo Dromaeo brát s docela velkou rezervou. Jejich původní účel byl totiž docela jiný.

Měření javascriptového výkonu je důležitou částí vývoje každého prohlížeče. Programátoři musí mít po ruce nástroj, na kterém mohou ladit jeho výkon a měřit rychlost zpracovávání elementárních úloh. V průběhu posledních let se ale z „inženýrského“ měřiče stalo hodnotící kritérium celého prohlížeče. Internet je tedy plný grafů, které vyjadřují, o kolik je Opera nebo Chrome zase rychlejší než v předchozím sestavení. Výsledky samozřejmě mají určitou vypovídací hodnotu a pořadí prohlížečů skutečně koreluje s kvalitou javascriptového motoru v jejich nitru, poměry, absolutní čísla a další hodnoty je ale třeba brát s rezervou – velkou rezervou.

Tuto myšlenku se snaží už nějaký pátek prosadit i autoři studie JSMeter. Ačkoliv název evokuje nějaký skutečný program nebo webový test, který můžeme sami spustit, ve skutečnosti se alespoň v současné době jedná pouze o několik studií v PDF, pár desítek snímků z PowerPointu a tucet grafů. Oč tedy jde?

Oč tedy jde? Co je to JSMeter?

Webové stránky jsou stále složitější a obsahují kvanta javascriptového kódu. Už to skutečně není jen pár řádků textu, který na stránce vykresli aktuální čas nebo jednoduchou animaci, ale velmi komplikovaný kód, který je ve své podstatě stejně složitý jako zcela běžný desktopový „tlustý“ program. A takové složité stránky jednoduše nelze jen tak změřit primitivním javascriptovým benchmarkem.

Javascriptový motor – překladač – v Internet Exploreru se skládá z jediného souboru jscript.dll. Díky tomuto jasnému oddělení od zbytku prohlížeče si pro měření kvality a komplexnosti Javascriptu na webových stránkách autoři studie vybrali právě staré dobré „IEčko“, k němuž ostatně měli i zdrojové kódy – stačilo zavolat kolegům z vývojového týmu. Knihovnu následně upravili a udělali z ní vlastně jakýsi měřící systém. A pak ji zakomponovali zpět do Internet Exploreru a hurá do běžného surfování.

Upravený Internet Explorer – v podstatě tedy onen JSMeter – zpracovává běžné webové stránky, díky upravenému JS motoru ale umí přesně analyzovat, co se děje při zobrazování a zpracovávání stránky a jejího kódu. Díky tomu se autorům aplikace podařilo sesbírat obrovské množství dat.

Nesurfovali přitom jen tak ledabyle na internetu, ale na konkrétních webech z žebříčku nejnavštěvovanějších stránek Alexa.com. Do výběru se dostal jak Google, tak Bing, Facebook, Gmail, Bing Mapy i Google Mapy, elektronické obchody eBay a Amazon a také zpravodajské CNN a Economist.

Na každém z těchto webů testovací prohlížeč s upraveným javascriptovým motorem provedl několik typických operací. Neprovedl tedy jen prosté načtení stránky, ale odeslal e-mail, vyhledal zboží, našel místo na mapě nebo vyhledal nějaký výraz ve vyhledávačích. Díky tomu měli nakonec analytici po ruce několik stovek megabajtů dat. Prakticky vše, co lze jen zjistit o zpracování a zobrazení webové stránky.

Co je to webová stránka

Nadpis kapitoly vám může připadat trochu zavádějící, každý přeci ví, co je to webová stránka a že se skládá z HTML jazyka. Výsledky analýzy JSMeter ale mluví o pravém opaku. Zapomeňte nyní na klasický HTML kód, paragrafy, tabulky, obrázky a kaskádové styly. Toto vše ze stránky smažte, až zůstane samotný javascriptový kód. Věřte, že u zkoumaných stránek zdaleka nezbude několik málo řádků textu – zbudou jich stovky, tisíce a nezřídka i desetitisíce. U těch nejsložitějších aplikací je dnes HTML kód paradoxně chudým příbuzným. Pánem je zde AJAX a Javascript.

Klepněte pro větší obrázek
Velikost javascriptového kódu na oblíbených stránkách dosahuje astronomických rozměrů

Tabulka je plná čísel, všimněte si ale zvláště druhého sloupce, ve kterém najdete velikost Javascriptu na každé z těchto stránek. Pokud na ně koukáte s otevřenou pusou, vůbec se vám nedivím. Zatímco kvanta kódu u Google Map jsou vzhledem ke složitosti aplikace ještě pochopitelná (2 MB JS kódu), při pohledu na ryze zpravodajský web Economist je to už trochu s podivem (900 kB). Jen zopakuji, že se jedná o velikost JS kódu, pokud tedy připojíte ještě HTML, styly a grafiku, velikost stránky se bez problému nafoukne na dva-tři megabajty.

Vývojáře pak jistě zaujme i 1., 5. a 6. sloupec, kde se autorům podařilo z kódu vytáhnout počty pracovních funkcí. Opět ale připomínám, že se nejedná o prosté načtení stránky, ale o součet všech operací, které je třeba provést k nějakému úkonu – třeba k vyhledání zboží na eBay. Na takových Google Mapách se tedy při vyhledávání geografických míst podle JSMeteru do procesu zapojí skoro tři tisíce unikátních funkcí. Od těch elementárních až po ty složité. A pokud spočtete všechny dohromady včetně těch, které se díky AJAXu neustále opakují, číslo vystoupá na závratný milion.

Javascriptové benchmarky nehodnotí realitu

Proč to vše píšu? Protože je důležité srovnání. Tabulka výše popisuje strukturu kódu několika populárních webů, jak ale vypadá nitro benchmarků SunSpider nebo V8? Je velmi jednoduché. SunSpider a V8 (ale ve své podstatě i Dromaeo) měří rychlost zpracovávání Javascriptu nad velmi jednoduchými operacemi, které nemají s reálným surfováním prakticky nic společného. Zatímco při práci s Facebookem se v nitru prohlížeče neustále zpracovávají stovky a tisíce javascriptových funkcí, benchmarky reálně pracují s desítkami až stovkami funkcí. Zatímco při načtení titulní stránky na reálných webech se do práce z 80 % zapojuje okolo stovky funkcí a ty ostatní jen výjimečně u specifických úloh (vkládání obrázků a videa, přidávání přátel aj.), 80 % práce v benchmarcích odpracuje asi desítka funkcí. Jednoduše řečeno, benchmark nám může napovědět, jak rychle bude prohlížeč pracovat s matematickými transformacemi. Kolik webů, které takové operace provádějí, ale během dne navštívíte?

A pak je tu ještě jedna slabina testování a ještě jedna pěkná tabulka plná čísel – události. Takovou událostí může být ve světě Javascriptu třeba stisknutí nějakého tlačítka, klepnutí na odkaz, ale také změna stavu v AJAXu, kdy se na pozadí běhu prohlížeče permanentně stahují data, aniž byste museli na něco klepat. Může se to zdát jako banalita, ale události se obrovskou měrou podepisují na rychlosti zpracování stránky.

Klepněte pro větší obrázek
Javascriptových událostí (třeba klepnutí na odkaz nebo práce AJAXu na pozadí)
najdete na populárních webech neméně obrovské množství

Při surfování na Facebooku JSMeter zaznamenal více než pět tisíc podobných událostí – v drtivé většině případů se jednalo o AJAX, operace na pozadí. Aby to bylo co nejsrozumitelnější, takovou AJAX operací může být třeba připojení nového komentáře. Když na Facebooku napíšete zprávu a klepnete na modré tlačítko, neobnoví se stránka (to by bylo v podstatě jen několik málo událostí), ale na pozadí běhu prohlížeče se spustí složitý mechanizmus, který uloží komentář do databáze na webovém serveru a bude čekat na odpověď, že se to podařilo. Jakmile dostane zprávu o úspěchu, zobrazí komentář na stránce. Za tímto uživatelským luxusem stojí okolo 150 unikátních událostí.

V nitru Javascriptu

Klepněte pro větší obrázek
Google a Bing trochu jinak

Tohoto grafu se vůbec nelekejte, jedná se ve své podstatě o jednoduchou časovou osu, která vyjadřuje, množství paměti, kterou zaberou různé operace v průběhu načítání stránky. Google vlevo pokaždé zabere velký kus paměti, krátce na to ji ale uvolní (ostré zuby). Naopak Bing postupně nabírá více a více paměti. V čem je rozdíl? Při načítání výsledků z Googlu se v nitru dotazuje na různé webové zdroje. Jakmile je zpracuje, uvloní je a nakonec sestaví hotovou stránku s textovými výsledky, miniaturami obrázků, kontextovou reklamou aj.

Bing naopak při načítání pracuje s menším množstvím externích zdrojů, vše si tedy zpracovává sám. V závěru tedy sice spotřebovává více zdrojů, v průběhu ale zase tak divoce nepřeskupuje bajty informací z jednoho místa na druhé – nemá ostré zuby. Oba skripty ve své podstatě dělají to samé, generují výsledky z vyhledávače, každý z nich na to jde ale naprosto odlišně a JS benchmarkem prakticky nelze vyjádřit, který vyhledávač bude ve kterém prohlížeči rychlejší.

Toto je už docela složitý příběh, se kterým si běžný JS benchmark neporadí, prakticky totiž rychlost zpracovávání událostí netestuje. Pokud má Amazon 6 000 událostí a Gmail jich při práci s poštou vytvoří 1 500, pak javascriptové benchmarky podobných událostí podle JSMeteru zpracují okolo jedné desítky.

Dramatická evoluce

Webová stránka už dávno není tím, čím byla na sklonku devadesátých let. Z Javascriptu jako doplňku stránky, ve které se staral o jednoduché úkony a představoval několik stovek, až tisíců řádků kódu, se stal skutečný moloch, který se u těch nejsložitějších „Web 2.0“ aplikací rozrostli do velikosti desítek tisíc řádků.

Jeho zpracovávání je stále složitější a z původně jednoduchého programu – webového prohlížeče – se pomalu stává univerzální program na vše, ve kterém mnoho z nás čte poštu, pracuje s dokumenty, kouká na video a hraje flashové hry. Když si tedy uvědomíte, kolik obecných věcí vlastně musí prohlížeč zvládnout, je vůbec s podivem, že je tak rychlý – vzpomeňte na hromadu problémů u specializovaných aplikací, které mají za úkol jen jednu funkci.

Po tom všem je tedy zřejmé, že Javascriptové benchmarky je skutečně třeba brát s velmi velkou rezervou. Ostatně stejně jako populární Acid3 test. Nedávají nám totiž odpověď na to, který z prohlížečů je skutečně lepší v běžných „nelaboratorních“ podmínkách.

 

Za posledních deset let se zhruba 160× zvýšila rychlost průměrného připojení k internetu.Stejně tak ale ruku v ruce s výkonem počítačů vzrostla i náročnost webového kódu a dat. Svým způsobem tedy nesurfujeme o moc rychleji než kdysi – surfujeme ale jinak.

 

Témata článku: Microsoft, Technologie, Web, Prohlížeče, Internet Explorer, Benchmark, Nitro, Motor, Ajax

10 komentářů

Nejnovější komentáře

  • Přemysl Vaculík 30. 3. 2010 19:38:21
    a co reknes na dalsi verzi? musim si vzdy nechat rezervu pro hodnoceni...
  • RandoMMeR 30. 3. 2010 19:30:57
    gmail pouzivam uz dost dlho, a myslim ze slovo "dobra prace" je strasne,...
  • Nothrem Sinsky 30. 3. 2010 13:30:20
    Ale přesně to se v článku píše: "...Knihovnu ... Javascript překladače...
Určitě si přečtěte

Operační systém běžným počítačům nedal Bill Gates, ale Gary Kildall

Operační systém běžným počítačům nedal Bill Gates, ale Gary Kildall

** Gary Kildall pochopil, že levné výpočetní čipy mohou posloužit jako univerzální počítače pro všechny ** Připravil pro ně proto první operační systém ** Později mu systém vyfoukl Microsoft a nazval ho MS DOS

23.  4.  2017 | Pavel Tronner | 57

Umělá inteligence je sice v plenkách, už teď ale přestáváme rozumět, jak vlastně funguje. To je problém

Umělá inteligence je sice v plenkách, už teď ale přestáváme rozumět, jak vlastně funguje. To je problém

** Už je to tady, lidé přestávají chápat počítače ** Systémy neuronových sítí začínají pracovat tak, že ani jejich tvůrci přesně neví, co se uvnitř děje ** Do budoucna to může být závažný problém

24.  4.  2017 | Jakub Čížek | 112

Acer chrlí novinky: levný a tenký Predator, nové Switche a další notebooky

Acer chrlí novinky: levný a tenký Predator, nové Switche a další notebooky

** Acer na konferenci v New Yorku představil velkou spoustu novinek z oblasti počítačů, notebooků i monitorů ** Notebookové novinky se dotkly řad Predator, Swift, Switch i Aspire ** Herní notebooky dostaly nový typ chlazení

27.  4.  2017 | Karel Javůrek | 9

Jak by měly vypadat příští Windows? Designéři si pohráli s futuristickým prostředím Neon

Jak by měly vypadat příští Windows? Designéři si pohráli s futuristickým prostředím Neon

** Zkraje roku unikly na internet snímky nového prostředí Neon ** Součástí Windows by mohlo být už na podzim ** Komunita grafiků na webu nespala a začala si hrát

26.  4.  2017 | Jakub Čížek | 60

Jak funguje Apple Liam: Robot, který umí recyklovat staré iPhony

Jak funguje Apple Liam: Robot, který umí recyklovat staré iPhony

** Apple zveřejnil detaily, jak funguje robotický systém Liam pro recyklaci iPhonů ** Jeden Liam zvládne rozdělat i na ty nejmenší díly 1,2 milionů iPhonů ročně ** Liam je důležitým prvkem k tomu, aby Apple mohl vyrábět pouze ze stoprocentně recyklovaných materiálů

24.  4.  2017 | Karel Javůrek | 21


Aktuální číslo časopisu Computer

Supertéma: moderní cestování

Kdy opravdu přijdou nové baterie?

Velké testy: 6 herních notebooků a 8 volantů

Recenze: AMD Ryzen řady 5