Vrijdagavond verveling: Rendering snelheid van browsers

Door AtleX op zaterdag 7 juni 2008 16:04 - Reacties (8)
Categorieën: Algemeen, Development & code, Views: 9.207

Afgelopen week liep ik tegen een probleem aan met een tooltje dat logt naar een HTML file. Op zich niet zo gek verkeerd, je kan zo heel eenvoudig en duidelijk de log lezen in je browser wat toch beter is dan wat plain text meuk lezen. Het nadeel is natuurlijk dat je niet eenvoudig een log parser kunt gebruiken. :)

Verder stond ik daar niet zo bij stil, ik had nog nooit de logfile van het programma bekeken, tot ik woensdag tegen een vervelend probleem ermee aanliep. Ik opende dus de logfile, wat duidelijk niet zo slim was. :X Het duurde een eeuwigheid voor mijn browser, Firefox 2.0.0.14, het bestand had geopend. Een blik in Windows Explorer liet zien dat de file 32MB groot was, en dat duurt dus wel even. :X

Daarom kwam ik op het idee om eens te meten hoe lang het duurt om een browser een grote HTML file te laten renderen. Natuurlijk stuitte ik daarbij op een paar problemen. Het eenvoudigste probleem, ik heb de ballen verstand van rendering engines van browsers, negeer ik gewoon, en het grootste (waar haal ik fatsoenlijke files vandaan) was eenvoudig op te lossen. Een jaar terug postte mijn naamgenoot, Alex), een tooltje om een afbeelding om te zetten naar een HTML file. Zijn programma was erg traag, en dus bouwde ik als antwoord een snellere versie.

Afbeeldingen naar HTML omzetten levert flink grote bestanden op. Deze afbeelding van net geen 18KB groot levert een HTML file op van zo'n 12MB. Prima geschikt voor mijn doel dus. :Y)

Maar ja, de <table> tag is aanwezig in HTML sinds versie 3.0 en dus kan iedere browser die snel renderen. Het moet natuurlijk wel een uitdaging blijven, en dus heb ik mijn tooltje wat uitgebreid:
http://tweakers.net/ext/f/M62szaDiTcZfLrlej5lz1Ecd/thumb.png
Vergeleken met versie 1 zjin er nogal wat dingen bijgekomen. Zo kan ik nu naast het converteren naar een <table>-based file ook omzetten naar een bestand waar elke pixel een absoluut gepositioneerde <div> is. De laatste optie gebruikt JavaScript om voor elke pixel een <div> aan te maken, die absoluut te positioneren en vervolgens door middel van appendChild() aan de <body> te hangen. Zo kan ik op 3 manieren testen, waardoor ook de verschillen tussen de verschillende methodes meetbaar zijn. Ook kan ik 2 stukjes JavaScript toevoegen, die de duur van de rendering meten. Verder zit er nog wat nutteloze informatie bij, zoals de hoeveelheid pixels die verwerkt zijn, en de hoeveelheid pixels per seconde die er verwerkt worden.

Vervolgens moest ik een leuke afbeelding hebben. De standaard plaatjes die gebruikt worden om bijvoorbeeld monitoren of camera's te testen vond ik te saai, complete wallpapers zijn te groot en omdat ik een groot Calvin & Hobbes fan ben heb ik toch deze strip weer gebruikt.

Dan nu, de testmethode. Mijn tijd is kostbaar, ook als ik me verveel. Daarom heb ik ervoor gekozen om slechts in een paar browsers te testen. Firefox 2.0.0.14, Firefox 3.0 RC2 (Portable Apps), Opera 9.50 beta 2 en Internet Explorer 7. Dat alles onder Windows, Windows Vista Business 32b SP1 (ENG) om precies te zijn. Als testmachine heb ik mijn gewone PC gebruikt, een Core 2 Duo E6400, met 4GB PC2-5300.

De afbeelding heb ik omgezet naar alledrie de render methodes, <table>, <div> & JS. Vervolgens heb ik eerst de tabel variant getest in Firefox 2.0.0.14, daarna in 3.0 RC2, toen in Opera 9.50 beta 2 en als laatste in Internet Explorer 7. Daarna heb ik dit herhaald met de <div> file en het JS bestand.

Als eerste, de files:
FileGrootte (bytes)
calvin-on-scientific-law_table.html10.478.376
calvin-on-scientific-law_div.html15.439.043
calvin-on-scientific-law_js.html35.149.519


Dan de resultaten:

calvin-on-scientific-law_table.html
BrowserSnelheid (ms)
FF 2.0.0.14124468
FF 3.0 RC248078
Opera 9.50 beta 211314
IE 78237

Opera maakt alle <td>'s veel te groot, waardoor er van de afbeelding niets meer klopt.

calvin-on-scientific-law_div.html
BrowserSnelheid (ms)
FF 2.0.0.14748630
FF 3.0 RC2-
Opera 9.50 beta 217910
IE 724141

IE7 laat maar de halve afbeelding zien, en is zo snel klaar dat ik me afvraag of hij de hele pagina heeft gerenderd. Opera is erg, erg snel, en laat dit plaatje wel correct zien. FF valt tegen, 2.0.0.14 is ontzettend traag, en 3.0 RC2 is 2x gecrashed. De derde keer heb ik 'm na een uur gestopt. Dit lijkt niet aan de PortableApps versie te liggen, op mijn laptop crashed een normaal geinstalleerde 3.0 RC2 ook.

calvin-on-scientific-law_js.html
BrowserSnelheid (ms)
FF 2.0.0.14-
FF 3.0 RC2-
Opera 9.50 beta 217783
IE 7-

Firefox 2.0.0.14 & 3.0 RC2 crashen, zowel op mijn PC als in mijn virtual machines op mijn laptop. :( Opera is weer erg snel, velen malen sneller dan de andere browsers. IE7 crashed ook, na een hele tijd niets te doen (geen CPU load, maar de menu's e.d. werken wel). Dit valt me een beetje tegen, 1 browser die goed en snel zijn werk doet, en en 3 anderen die gewoon crashen.

Een conclusie kan ik hier niet echt aan verbinden, en daar was het me ook niet om te doen. Het was leuk om eens te kijken hoe snel browsers zijn met grote files, maar verder is deze benchmark knap waardeloos aangezien niemand die enigzins bij zijn verstand is zulke enorme files gaat inladen, of rare truukjes uithaalt om zijn gigantische pagina met JavaScript op te bouwen. Ik heb me iig weer een avondje vermaakt. :P Mensen die het ook eens willen proberen kunnen hier mijn Image2HTML tool downloaden. :) Ga er geen gigantische afbeeldingen mee omzetten, bij 1920*1080 krijg je vrijwel zeker een OutOfMemoryException. :X

Volgende: Robocopy - Een verborgen schat in Windows 06-'08 Robocopy - Een verborgen schat in Windows
Volgende: PHP sucks, of toch niet? 05-'08 PHP sucks, of toch niet?

Reacties


Door Tweakers user dcm360, zaterdag 7 juni 2008 16:29

Grappig testje!

even de html met table-layout gepakt en hier ook getest. Leuk om te zien dat browsers er heel verschillende tijden over doen om de pagina te renderen. Iets anders leuks is het geheugengebruik. Ik heb bij drie browsers een lege tab bijgeopend en het geheugengebruik op dat moment genoteerd. Vervolgens de pagina geopend en weer het geheugengebruik opgeschreven. Hier de verschillen in geheugengebruik:
Opera 9.27 - 145.8MB
Internet Explorer 7.0.5730.13 - 173.4MB
Firefox 2.0.0.14 - 275.1MB

Leuk hè, nutteloze statistieken!

Door Tweakers user Megaflix, zaterdag 7 juni 2008 22:06

Hele grappige test :+ Dit zou eigenlijk wel een benchmark-test verdienen voor nieuwe browsers :D Bij jouw test verbleekt de acid-test-reeks :P

Door Tweakers user AndriesLouw, zaterdag 7 juni 2008 23:24

Niemand die enorme logfiles in gaat laden? Nu, dan ben ik zeker een uitzondering ;)

Het is maar goed dat je in DirectAdmin kunt beperken hoeveel logregels je op je scherm wilt zien. Want zelfs pagina's zonder HTML duren in Firefox lang om "te renderen". (Wellicht voor je volgende test, het vergelijken van de laadtijden van pagina's met 10 MB plaintext in de <body>.)

Door Tweakers user jbvo, zaterdag 7 juni 2008 23:52

Opera ftw! :+

Door Tweakers user crisp, zondag 8 juni 2008 18:44

Interessant. Parsing-performance lijkt de laatste tijd met de opkomst van allerlei core JS benchmarks nogal in het donker te blijven staan terwijl het met name bij dynamische updates toch de grootste bottleneck is. Ik ben zelf al een tijdje bezig met het bedenken van benchmarks om op een onafhankelijke manier de (dynamische) rendersnelheid van browsers te kunnen vergelijken.

Ik denk dat in de gevallen hier nog wel wat truukjes mogelijk zijn om eea sneller te laten renderen door verschillende browsers. Er valt wel eea af te dingen aan de gekozen methodes om een 'grid' te laten renderen, maar dat laat niet onverlet dat het met de hier gekozen methoden niet sneller zou kunnen (zoals o.a. Opera al bewijst).

Door Tweakers user Punkie, dinsdag 10 juni 2008 11:45

Zeker niet nutteloos en jawel, ook hier worden wel eens enorme html pagina's gegenereert als log. Als ontwikkelaar loop je wel eens vaker tegen de limieten aan (hoezo max 4 GB per file) :)

Door Tweakers user crisp, dinsdag 10 juni 2008 23:06

Zelf ook even wat testjes gedaan maar met de beste wil van de wereld krijg je dit in geen enkele browser snel :P Het zijn immers sowieso 800x254 (afmetingen van het C&H gifje) = 203.200 elementen.

Zelfs als je het kleinste element (qua tagname) pakt die geen sluittag nodig heeft, <p> dus, en je ze bijvoorbeeld laat floaten zodat je niet absoluut hoeft te positioneren maar een fixed-width container kan gebruiken en je voor de 6 verschillende kleuren een class gebruikt ipv inline style="background-color:#f00" dan heb je dus al sowieso 203.200 x '<p class=x>'.length = 2.235.200 bytes aan markup + je container + je css.

Met scripting kan je dat toch aardig reduceren; je kan de ruwe imagedata base64-encoded opslaan in een JS var en vervolgens met een JS gif-implementatie uitlezen en je elementen genereren. Al met al kan je dan nog wel onder de 50KB blijven ;)

Ik denk echter dat voor dit soort zaken scripting + <canvas> toch wel de meest beste oplossing is en waarschijnlijk ook nog wel de snelste in browsers die dat native ondersteunen.

Door Tweakers user Kiphaas7, dinsdag 17 juni 2008 19:07

Opera 9.50 (final) laat anders het plaatje prima zien hoor, dus dat is nog een pluspuntje voor opera :D

Voor de duidelijkheid, ik heb deze link gebruikt:
http://atlex.nl/tmp/html.zip

Reageren is niet meer mogelijk