Který prohlížeč je na světě nejrychlejší?

V APC Magazine se pokusili odpovědět na otázku, který prohlížeč je na světě nejrychlejší. Použili testovací stránku, která změří, za jak dlouho prohlížeč načte a zpracuje data. Na prvním místě se umístil Konqueror, nejhůře dopadl Firefox.

8.9.2006 19:46 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[Dušan Hokův]

hmmm, fakt ze jo... zajimavy

[razor]

Hmmm, tak jsem to zkusil a mému oblibenému firefoxovi 1.5.0.6 to renderování trvá přibližně 2x déle než Opeře 9.01 a Konquerorovi 3.5.2 (Konqueror byl nejrychlejší) . Sice je to dost netypická stránka, ale ten rozdíl mi připadá dost markantní.

[razor]

A srovnat firefoxe na úroveň opery a konquerora ( v případě že je zkompilován s --enable-pango, což mám v gentoo defaultně ) lze následovně: export MOZ_DISABLE_PANGO=1. Je sice stále pomalejší, ale už je firefox na stejné hladině

[Čouž]

No moje skusenosti su take že mi FF zamrzol :(( ver. 1.5.0.6

[Ctirad Feřtr]

Ono stačí jenom nějakou stránkou zaskrolovat. V konqueororu to jede jak po másle a firefox se slušně cuká.

[NbS]

souhlas

1) Konqueror : 3.4.2 time : 4.4289
2) Opera : 9.0.1 build 400 i686 time : 4.9397
3) FF : 1.5.0.4 i686 time : 6.9702
4) IE : 6 time : 9.4856

je taky zvlastni ze FF dosud nezobrazi acid xichtik :( kdezto opera v pohode

[Max]

je taky zvlastni ze FF dosud nezobrazi acid xichtik :( kdezto opera v pohode

Jo, to mě taky štve :-/
Jak to tak doposud vypadá, tak asi odstoupím od ff beta 1 a jdu k opeře 9. Ta pomalost apod. to je strašný. FF je pro linux tak zkur**nej :(
Zdar Max

[Kyosuke]

Kvůli xichtíku? Tsss…

[Michal Kubeček]

je taky zvlastni ze FF dosud nezobrazi acid xichtik

Kdyby vás aspoň trochu zajímalo, proč tomu tak je, asi byste to už dávno věděl. Acid test se objevil (pro Mozillu) prakticky v nejnevhodnější možnou dobu: ve chvíli, kdy byl dokončen jeden vývojový cyklus Gecka, začala se na něm stavět nová generace prohlížečů a současně začal nový vývojový cyklus. Změny, které by bylo potřeba udělat pro plnou funkčnost Acid testu, byly natolik zásadní, že se vývojáři rozhodli je provést až v té nové verzi Gecka. Ta se ale do prohlížečů promítne až v další řadě. Prostě zvítězila stabilita nad výsledkem v jednom mediálně zviditelněném umělém testu. Musím říct, že ačkoli se mi některé kroky vývojářů Mozilly (a často i jejich přístup) příliš nelíbí, s tímto rozodnutím jednoznačně souhlasím.

[kavol]

souhlasím s tím ohledně stability, ale ...

Změny, které by bylo potřeba udělat pro plnou funkčnost Acid testu, byly natolik zásadní, že se vývojáři rozhodli je provést až v té nové verzi Gecka. ... Prostě zvítězila stabilita nad výsledkem v jednom mediálně zviditelněném umělém testu.

ehm, není to spíše tak, že by v Gecku měly být provedeny změny pro plnou podporu CSS2? - pak by totiž mohlo být vedlejším efektem to, že by FireFox a další prošly nejen tím jedním mediálně zviditelněným testem ...

váš příspěvek mi vyznívá, jako byste problém viděl spíše v tom testu a bylo by třeba dělat kdovíjaké špinavé hacky, jen aby to prošlo ... takže stále zastáváte názor, že Gecko je (téměř) dokonalé? - ještě stále jste mi nevysvětlil, proč se Gecko chová k jednomu inline replaced elementu jinak než k druhému ...

[Michal Kubeček]

Ne, to jste mne špatně pochopil. Gecko by samozřejmě mělo být opraveno tak, aby plně podporovalo CSS Level 2 (nebo aspoň 2.1). Problém je v tom, že pro plné fungování Acid testu (ne jen naoko) nestačily jen drobné úpravy, ale byly potřeba zásadnější změny celého renderovacího jádra (prostě některé části bude potřeba přepsat od základu místo nějakého quick-and-dirty-fix, který by zajistil Acid compliance, ale skutečný problém nevyřešil). Ty samozřejmě prováděny byly/jsou, ale až v tom novém vývojovém cyklu. Ale jeho výsledek se do prohlížečů promítne až v dalších verzích. Sice to tak bude vypadat, že Mozille trvalo nejdéle, než splní Acid test, ale to je pořád přijatelnější, než druhá alternativa: že by se ty změny narychlo provedly v produkční verzi Gecka - samozřejmě s katastrofálními důsledky pro stabilitu prohlížeče.

Takže mi, prosím, nepodsouvejte věci, které jsem nikdy neřekl. Problém není v Acid testu, problém je v tom, že Acid test je sice hojně medializovaný, ale není natolik důležitý, aby byla kvůli němu ohrožena stabilita prohlížeče. Proto bude jeho splnění dosaženo později, než by si někteří lidé představovali. Za sebe mohu říci, že jsem rád, že se vývojáři rozhodli takto. Zrovna tak si nemyslím, že je Gecko (téměř) dokonalé, myslím si pouze, že z hlediska podpory CSS Level 2 je na tom přibližně nejlépe ze všech dnes existujících prohlížečů, srovnatelně s Operou, o něco lépe než KHTML (ale ta se v poslední době hodně zlepšila) a daleko před Internet Explorerem.

Co se týká vašeho příkladu, možná by bylo lepší, kdybyste odkázal na diskusi, kterou jsme na toto téma vedli dříve, abych ho nemusel analyzovat znovu od nuly.

[kavol]

nechci vám podsouvat něco, co jste neřekl, pouze píšu, jak jsem vás pochopil já ...

btw, KHTML se naopak (pro mě subjektivně) značně zhoršilo; mimochodem Konqueror 3.5.4 jaksi Acid2 nezvládá ...

[Michal Kubeček]

Možná myslíte jiný časový interval. Já měl na mysli asi tak poslední dva roky. Předtím mi běžně chyby KHTML způsobovaly rozsypání i u zcela běžných stránek, dnes se mi to u Konqueroru téměř nestává.

[kavol]

no, mě spíše přijde, že teď se o hodně lépe vyrovnává s IE-only prasárnami, kteréžto se dříve více sypaly ... a jelikož taková "běžná stránka(tm)" je psána pro IE ...

nedokážu to časově přesně říct - asi myslím KDE 3.4 => 3.5

[Michal Kubeček]

Já myslel dobu od rozhodnutí Apple použít Safari jako defaultní prohlížeč pro MacOS. Ale nechce se mi dohledávat, jakému datu nebo berzi Konqueroru to odpovídá.

[kavol]

aha ... no to bude někdy kolem vydání verze 3, řekl bych ...

máte pravdu, od té doby (resp. od < 3) se hodně zlepšil

[martink]

mimochodem Konqueror 3.5.4 jaksi Acid2 nezvládá ...

Můj konqueror 3.5.4 ho teda zvládá...

[kavol]

http://fotky.hajnet.cz/acid2-konqueror-3.5.4.png

[David Watzke]

http://amd.xhosting.cz/tmp/konqueror_acid2.png

[Luboš Doležel (Doli)]

+1, u mě dopadne Acid2 taky dobře (3.5.4, x86).

[kavol]

hm ... jak vidíš, u mě ta stránka ani nedokončí načítání, přitom wget ji v pohodě stáhne ...

tož, co ty máš co já nemám? (Gentoo ani Athlon64 to není )

[David Watzke]

emerge --info

[kavol]

nemyslím, že by zrovna verze linux headers nebo to, zda kompiluju s -fomit-frame-pointer, dali odpověď na tuto otázku ...

[David Watzke]

Dobře, mám 2 DVD vypalovačky , 2.0 bedny, sluchátka, Audigy 4, dále 3 harddisky, z toho 2 IDE (80, 160 GB) a jeden SATA II (320 GB) strčenej do SATA I (všechny od Seagate). Grafiku GeForce 5750 od MSI, tiskárnu Canon S400, LCD 19" od Neovo. Základovku Biostar s chipsetem nForce4. 500W zdroj.

V čem to podle tebe teda je? Možná nastavení Konqueroru/KDE.

[kavol]

kdybych to věděl, tak bych se tak blbě neptal

[Mikos]

Problém bude zjevně na tvé straně, můj Konqueror 3.5.4 zvládá ACID2 naprosto bez problémů A musím říct že se Konqueror (respektive KHTML) naopak silně zlepšuje, ve verzi 3.5.4 už je absolutně stabilní a neměl sem s ním na žádných stránkách zatím problémy.

Jinak tady máš důkaz: link

[Michal Vyskočil]

Že bych taky zamachroval se svými fotkami? Je to sice z betaverze 3.5, ale už tam mi Acid fungoval bez problémů

[Jakub]

Mohu se zeptat co je to za motiv na tom obrazku?

[Mikos]

Viz můj blogpost

[Michal Kubeček]

Tak jsem si tu diskusi našel (mohl jste se aspoň zmínit, že nebyla tady, ale na Rootu). Odpověď jsem vám tam poskytl, tuto odpověď považuji za správnou i dnes. Pokud vy i dnes trváte na tom, že je chybná, je to vaše věc, nezměnil jsem na tom nic tehdy, nezměním to ani teď. Takže není pravda, že jsem vám to nevysvětlil, pouze jste vy mé vysvětlení odmítl akceptovat.

Stručné shrnutí: ano, v renderingu Gecka jsou chyby, ale tento příklad chybou není, nepočítáme-li skutečnost, že v tomto příkladu Gecko použije defaultní hodnotu 150px místo nuly, kterou by předepisoval standard. Rozhodně ale není chybou, že se Gecko nechová tak, jak očekáváte vy.

[kavol]

hm, nějak jsem si po těch letech nepamatoval, že to bylo na Rootu

bohužel "vysvětlení", které si bere za základ takové argumenty, jako že při renderingu obsahu iframe může potenciálně dojít k chybě, nemohu akceptovat ani nyní

jestliže tvrdíte, že v daném testcase by měla dle standardu být výška vždy 0 a že je výhodou Gecka, že tam dá těch 150 pixelů, aby se alespoň něco zobrazilo, můžete se prosím pokusit ještě jednou stručně vysvětlit, proč zatímco ty iframy mají všechny tuto výšku, obrázky jsou (v Seamonkey 1.0.3) různě vysoké (navzájem a zároveň ≠ 150 pixelů)?

pokud bude vaše vysvětlení zahrnovat sdělení, že img je něco jiného než iframe, vysvětlete prosím i kde vidíte z hlediska definic v příslušných normách rozdíl, který by opravňoval renderer chovat se ke každému jinak

- KHTML, i když se dle mého názoru též nechová korektně, je alespoň konsistentní a všechno zobrazí stejně

[kavol]

víte co, nechte to být - vemte kolo/psa/ženu/děti/cojávím a ... venku je dneska pěkně, aspoň tady u nás

[Michal Kubeček]

Už jsem to vysvětlil tenkrát: element img má pro oba rozměry definované přirozené (intrinsic) rozměry, element iframe je definované nemá a naopak jeho obsah je renderován do viewportu s rozměry definovanými vnějším dokumentem. To, že je ve vašem specifickém případě vnitřní dokument náhodou definované má, je spíše výjimečná situace a nelze z ní odvozovat rendering model elementu iframe. Ale opravdu se o tom nechci znovu hádat, vy jste bohužel přesvědčen, že teprve na základě obsahu vnitřního dokumentu (a třeba i toho, zda při jeho načítání dojde k chybě) se rozhodne, zda se element iframe bude pozicovat jako element s intrinsic rozměry nebo element bez nich. Evidentně nemá smysl vás přesvědčovat, že tomu tak není, stejně jako přesvědčovat mne, že tomu tak je.

[kavol]

mno, já i v tomto komentáři pozoruju jistý posun od minula, ale asi to opravdu nechme spát ... ostatně vizte výše

[Michal Kubeček]

Tak jsem našel zdroj: stručné shrnutí; odkaz na původní thread bohužel zrovna nefunguje.

[walley walleyovic]

:) jeste to ale neni uplne dokonale

[Radomír Fojtík]

To já když kliknu na ten test, musím následně konqueror 3.5.4 odstřelit, protože přestane reagovat.

[David Watzke]

Mně to v 64-bit 3.5.4 jde v pohodě... jednou 3,7s a pak 2,8s.

[Mikos]

Mě to jde naprosto v pohodě (na 32-bitech v Arch Linuxu) a to mám taktéž KDE 3.5.4. Takže zjevně nějaký problém na straně tvojí straně (či straně tvé distribuce).

[David Watzke]

Takže zjevně nějaký problém na straně tvojí straně (či straně tvé distribuce).

Gentoo v tom prsty nemá - na jiným Gentoo s 32-bit Konquerorem 3.5.4 není problém... Možná nějaký šílený CXXFLAGS.

[Radomír Fojtík]

To já když kliknu na ten test, musím následně konqueror 3.5.4 odstřelit, protože přestane reagovat.

[trancelius]

(wild guess) není to třeba tím, že tu stránku ještě stahuje ? Zkus ji nejdřív wgetem stáhnout na lokální jednotku a pak teprv zobrazit

[Radomír Fojtík]

On přestane reagovat v okamžiku, kdy odklepnu to popup okno. Stejné je to i při otevření lokální kopie.

Ale přišel jsem na to, že dám-li OK (hodnota byla 4.03), zamrznutí trvá asi minutu a půl, pak mohu zase pokračovat v používání programu.

[Mikos]

Už jsem na t reagoval výše - ale tak pro jistotu ještě tady Mě to ve stejné verzi KDE (v Arch Linuxu) jde naprosto bez problémů a bleskově rychle. Problém je tedy na tvojí straně...

[kouby]

Zkuste někdo změřit rychlost načítání u FF 2.0, myslím, že tam je to o něco lepší.

[NbS]

jsem asi pozadu ona uz je 2.x ? bo je to night build ...

[kouby]

Je to zatím pouze Beta.

[David Watzke]

5,28s.

[Scarabeus IV]

12,3; 11,6; 11,9 -- nepotesilo mne to

[Luboš Doležel (Doli)]

Vše je 32bit.

www-client/opera-9.01: 3.245999813079834
kde-base/konqueror-3.5.4: 2.322999954223633
www-client/mozilla-firefox-2.0_beta2: 34.73099994659424 (toto není překlep!)
Binární verze mozilla-firefox-2.0_beta2: 7.73799991607666

Už delší dobu pozoruju, že software od Mozilly je mnohem rychlejší v jejich binární verzi než při kompilaci ze zdrojáků.

[Michal Kubeček]

Už delší dobu pozoruju, že software od Mozilly je mnohem rychlejší v jejich binární verzi než při kompilaci ze zdrojáků.

V tom případě bych asi hledal problém v parametrech kompilátoru nebo něčem podobném. Kde by se asi jinak ty superrychlé binární balíčky braly?

[Luboš Doležel (Doli)]

Mně je jasné, že něco budě špatně v CFLAGS, ale ty moje na ostatní soft fungují perfektně - jen Mozilla dělá potíže :-/

[Vojta Drbohlav]

32bit - www-client/mozilla-firefox-2.0_beta2: 6.97900001552734

kompilace ze zdrojáků

[xxx]

Rekl bych, ze jedna z verzi bude zkompilovana s pang-em, a druha bez. Zkuste otestovat tuto stranku: http://www.etf.cuni.cz/~tomasek/test/test-ester.php Verze bez panga zobrazi stranku prasacky (i verze s pangem ma problemy s fontem "SBL Hebrew"). Pokud nepotrebujete zobrazovat komplexni pisma, bude vam to zrejme jedno....

[Vojta Drbohlav]

Mě jede ta stránka(ve Firefoxu) v pohodě až na ty menší problémy s fontem SBL Hebrew => asi mám verzi s pangem

[Michal Kubeček]

O jaké problémy jde? Mně se zdá (u mne) v pořádku všechno, ale z hebrejské abecedy znám jen aleph (možná bych si vzpomněl ještě na gimmel), takže těžko říct…

[xxx]

Samohlasky jsou spatne umistene (posunute do leva)...

[Vojta Drbohlav]

Sem tam to nezobrazí nějakej znak... je tam čtvereček. Používám UTF8

[Michal Kubeček]

Není to spíš problém nainstalovaných fontů? Čtverečky se mi obvykle zobrazují místo znaků, které nejsou k dispozici.

[Vojta Drbohlav]

To je docela možný, ale hebrejsky neumim, tak to ani nebudu instalovat

[Honza Jaroš]

Hmm, koukám, že Pango má víc problémů s národními znaky než jen tohle...

[razor]

Vypadáto, že "zakopaný pes" je skutečně pango. Firefox 1.5.0.6 zkompilovaný bez podpory panga u mě v průměru 3.7s . S podporou panga v průměru 7.2s :-| Chtělo by to asi holt nějaky turbo pro pango

[Semo]

opera a konqueror u mna dosahuju v podstate take iste casy ako u teba. FF 1.5.0.0 zo zdrojakov ma 22.5s a links ma 0.85s

[Pavel Cvrček (JasnaPaka)]

Odkdy může jeden test odpovědět na podobnou otázku? Tenhle test ztěží odpoví na otázku, který prohlížeč má nejrychlejší renderování tabulek.

[Michal Kubeček]

To je obecný problém většiny benchmarků. Lidé nemají rádi složité rozbory. Oni chtějí něco, co jim vyplivne jedno číslo, na jehož základě mouhou zodpovědně prohlásit, že A je nejrychlejší a D nejpomalejší. Že je celý problém podstatně složitější a že na otázku neexistuje jednoduchá odpověď? Vy odborníci si pořád vymýšlíte nějaké výmluvy. To máte jako s oblíbeným porovnáváním operačních systémů podle toho, jak dlouho bootují…

[Fëannatar]

Tak jsem si to taky testnul. HW: Athlon 900MHz, 256MB RAM. SW: Fedora Core 5 (aktuální), Gnome 2.14.3, kernel 2.6.17-1.2174_FC5, wine 0.9.20 Konqueror 3.5.4 (fedora build): 10.4s
Opera 9.0.344: 11.3s
IE6: 12.8s
Firefox 2b2 (latest nightly): 15.9s
Flock 0.7.4: 16.8s
Epiphany 2.14.2.1 (fedora build): 17.9s
Seamonkey 1.5a1 (latest nightly): 18.2s
Galeon 2.0.1 (fedora build): 18.4s
Firefox 3a1 (latest nightly): 19.4s
Firefox 1.5.0.6 (fedora build): 31.6s
Seamonkey 1.0.4 (fedora build): 31.7s
Nejrychlejší je tedy konqueror, ale padá mi tak často, že je nepoužitelnej (alepoň při načítání tý testovací stránky). Opera sice rychlá a zobrazí xichtík, ale tak nějak se mi nelíbí. IE6 rychlej (a to je to testovaný přes Wine), ale blbej, takže zůstávám u ff2b2 nightly ;)

[Mikos]

Co používáš za distribuci? Mě tady pod Arch Linuxem Konqueror totiž vůbec nepadá (a to ho používám dennodenně, Firefox už jsem nespouštěl ani nepamatuju). Předchozí verze se ještě občas sekaly (třeba na některých dlouhých diskuzích na ABCLinuxu), ale 3.5.4 je tu u mě absolutně stabilní bez sebemenších problémů. Řekl bych že problém bude tedy v buildu KDE v tvé distribuci...

[R]

Mne tiez 3.5.4 takmer nepada, zato KMail - to je ina kava :)

[Ondroid]

Já mám Gentoo, KDE 3.5.4 a na web intenzivně používám Konqueror a nepamatuju kdy mi spadnul naposledy. Dle mého názoru je Konqueror king mezi prohlížeči pokud teda používáte KDE. Kdyby v něm tak ještě chtěla fungovat eBanka..

[Pietro]

Ja mam 3.5.4 na SUSE 10.1, mam ho pusteny nepretrzite a ani mne nepada.

[Fëannatar]

Jak jsem napsal v úvodu, používám fedoru 5. Problém může být v buildu KDE, ale na fedoraforum jsou i lidi, kteří používají KDE, a tyto problémy nemají. Takže spíš bych to připsal tomu, že mu vadila ta konkrétní testovací stránka, anebo má prostě jenom problémy, když běží pod Gnome... Stejně, já používám Gnome (KDE se mi prostě nelíbí, je to taková srdeční záležitost), takže Konqueror není zrovna nejvhodnější (a snažím se nahradit všechny KDE aplikace těmi pro GTK/GNOME, přece jenom KDE je pěknej moloch, když je nainstalovanej...)

[VM]

U me na P4 3GHz, Gentoo: firefox-bin cca 2.9s, Konqueror 1.65s, obcas vice. Nez jsem tu stranku ulozil na disk, bylo to pres 10s.

[xxxxxxxx]

seamonkey rulezzz

[trekker.dk]

9.1s oproti 3.6s od Opery, takže Seamonkey bohužel moc nerulezzzuje.

[#Tom]

FekalFox je pomalej, u mě mu to trvá 37 vteřin (FF 1.5), Konqueror (3.4.2) chce jen 15 vteřin.

[Lukáš Zapletal]

A) Na takový "stránky" nechodím.

B) Rychlost ve vyrenderování stránky z historie (tlačítko Back) je v Konqueroru oproti Opeře žalostně pomalé.

Jinak Konq je super.

[kavol]

B) Rychlost ve vyrenderování stránky z historie (tlačítko Back) je v Konqueroru oproti Opeře žalostně pomalé.

tuším, že to má co dělat např. s těmito bugy: 124510, 78575 a samozřejmě 130160

[newman]

Jen pro uplnost: Dillo-0.8.6 renduje stranku za < 0.5 s (jenom odhad, dillo nema javascript) [pentium-m 1.5 GHz @Gentoo]. ff-1.5.0.5 to zabere necelych 10 sekund.

[DoubleR]

No ja takove rozdily zas nemel. Konqueror neco kolem 7.5, FF 9.237. Oboji mi pripada pomale. Fakt je, ze Konqueror drzi jak helvitska vira, FF 1.5.0.6 tu a tam spadne, o betaverzi FF 2 nemluve. Nejlip dopada links - 3.968

[premech]

U me (A64 3000+, 32bit Gentoo) dopadlo takhle:
Konqueror-3.5.4: 0.79s
Firefox-1.5.0.5: 2.02s
Opera-9.0: 1.86