[IE] render performance bug?

[pimlie]

Omdat de client parsetime van onze intranet applicatie aan de lange kant was, heb ik aan de hand van de Yahoo's Best Practices guide (oftewel YSlow) de html code van de applicatie geoptimaliseerd. Het belangrijkste wat ik veranderd heb is dat alle javascript includes in de header staan en alle javascript code onderaan de html staat.

Nadat ik dit had veranderd had bleek de client parsetime van onze applicatie echter opeens 3 keer langer te zijn geworden! Na het stap voor stap terugdraaien van alle veranderingen kwam ik erachter dat juist het gebrek aan script tags voor een enorme vertraging zorgt in Internet Explorer (iig 7).

Wellicht dat een voorbeeld het handigst is om dit uit te leggen:
zonder script tag = langzaam
met script tag = snel

De 2 html bestanden zijn muv van de script tag identiek. Beide bestanden renderen hier ook het zelfde. Het enige verschil zit hem in de Browser Parsetime die in de statusbalk verschijnt (gebruik een E6850, 2GB).
Als ik geen script tag toevoeg doet IE ca 1,9 seconde over het renderen van de pagina.
Als ik wel een script tag toevoeg dan doet IE er <0,1 seconde over om te renderen!

Een gigantisch en bijna ongeloofwaardig verschil natuurlijk. Het is iig geen 'meetfout', ik ervaar dit verschil in render tijd zelf ook als ik beide pagina's herlaad. De plaats van de script tag is overigens ook belangrijk, het werkt alleen als ik hem voor of in de overflowing div zet. Na de overflowing div heeft geen effect.

Ik heb gezocht of dit een bekend probleem is van IE maar ik heb niets kunnen vinden. Mijn vraag is dan ook of jullie ook het verschil in render tijd van bovengenoemde pagina's ervaren?
Zo ja, heeft iemand enig idee waar dit door zou kunnen komen? Gebruik ik verkeerde html en/of css syntax? Of is het toch echt een echte bug?

Terzijde, firefox 2 doet er gemiddeld 0,9 seconde over om deze pagina te parsen. Ook niet heel snel dus..

[Bozozo]

Euhm, ben je allergisch voor tabellen of lijkt dat maar zo? Ik denk dat die pagina tien keer zo snel laadt als je een tabel gebruikt ipv een miljard DIV elementen.

Verder zie ik inderdaad het snelheidsverschil heel duidelijk in IE7, maar ik heb geen idee van de oorzaak.

[MueR]

Hier is ook Firefox 2 traag met die pagina hoor. Verder ben ik met Bozozo wbt de divs. If it looks like a dog, barks like a dog, it probably is a dog. Dit is gewoon een tabel, gebruik dat ding dan ook.

[Civil]

Stond er in die Yahoo's Best Practices guide niets vermeld over het correct gebruik van html ?

Jouw pagina is een tabel met adresgegevens. Iedereen zou deze informatie in een tabel plaatsen omdat dat nu eenmaal de enige juist wijze is om deze informatie te presenteren. Maar bij jouw (jullie) intranet applicatie is gekozen voor het gebruik van div's, waarom ?

[crisp]

Kijk ook eens of het scheelt als je die @import vervangt door een gewone <link>

Verder eens met bovenstaande: dit moet je gewoon in een tabel stoppen

[Verwijderd]

Maar... maar divs zijn hip

Test het inderdaad eens uit met een old school table ?

[ Voor 23% gewijzigd door Verwijderd op 30-05-2008 12:06 ]

[Snake]

Verwijderd schreef op vrijdag 30 mei 2008 @ 12:05:
Maar... maar divs zijn hip

Test het inderdaad eens uit met een old school table ?

Bullshit, dit is tabulaire data, dit moet in een tabel.

[Verwijderd]

Snake schreef op vrijdag 30 mei 2008 @ 12:07:
[...]

Bullshit, dit is tabulaire data, dit moet in een tabel.

Dat was niet serieus ofzo... ik ga helemaal mee met de hond van hierboven. Je ziet gewoon dat devvers vaak naar technieken grijpen die hip, hot & cool zijn terwijl de oude techniek ook prima werkt en soms zelf gebruiksvriendelijker en/of beter is.

Maar misschien heeft de TS wel een goede reden om dit zo aan te pakken ?

[pimlie]

Bedankt voor jullie reacties, maar laten we niet verzanden in een wel of geen tabellen discussie.

De voorbeeld code hierboven is een compleet gestripte versie van wat wij gebruiken in onze applicatie. In het verleden gebruikten we idd een tabel, voor onze oplossing is echter gebleken dat we beter div's kunnen gebruiken (denk aan resizen van kolommen, toevoegen/verwijderen van kolommen, uitklapbare tree's etc etc). Daarnaast zal het qua performance echt niet veel uitmaken. Kijk maar naar de link met script tag die 500 records in <0,1s rendert.

Mag ik jullie er trouwens op wijzen dat datagrid's als ActiveWidgets ook geen tabellen gebruiken?

crisp schreef op vrijdag 30 mei 2008 @ 12:04:
Kijk ook eens of het scheelt als je die @import vervangt door een gewone <link>

Dit zorgt ervoor dat de browser parsetime die gemeten wordt wel laag is, maar je ziet/merkt dat IE in de achtergrond nog bezig is met het verwerken van informatie en dus eigenlijk langer dan 0,1 seconde bezig is. Zie hier.

[MueR]

Resizen van kolommen doen tables native, divs niet. Een tabel opnieuw opbouwen kan een beetje javascripter net zo goed als dat het met een collectie divs te doen is. En "zij doen het ook niet" is wel de belabberdste reden om iets niet te doen.

[pimlie]

Kerel, ga nou niet beginnen met 'een beetje javascripter'. Je/jullie hebben totaal geen idee wat onze eisen zijn aan een datagrid dus ga er nou maar vanuit dat wij de voor ons beste keuze hebben gemaakt.

Daarnaast heb ik nooit gezegd dat ik geen tabellen gebruik omdat AW ze ook niet gebruikt. 'Jullie' mogen dus blijkbaar wel zeggen dat jullie vinden dat ik het in een tabel moet opzetten, maar ik mag niet laten zien dat er ook mensen zijn die met mij gelijkgestemd zijn? Kom op zeg..

[Sen]

MueR schreef op vrijdag 30 mei 2008 @ 12:25:
Resizen van kolommen doen tables native, divs niet. Een tabel opnieuw opbouwen kan een beetje javascripter net zo goed als dat het met een collectie divs te doen is. En "zij doen het ook niet" is wel de belabberdste reden om iets niet te doen.

Wat weet jij wat wij niet weten. Werk je met pimlie of zit je maar wat te gokken hij zegt duidelijk waarom hij dat zo wil doen en dat er andere onderdelen zijn die wel het beste presteren in div's.

knip, persoonlijke aanval er uit gehaald

Btw ik denk dat als je het met tabellen zou doen je langzamer zou zijn in rendering dus dat zou ik al niet proberen.

[ Voor 12% gewijzigd door André op 30-05-2008 16:53 ]

[pimlie]

@Sen

Goed, omdat ik die eeuwige div-tabellen discussies als hierboven niet kan uitstaan en voor eens en altijd de wereld uit wil helpen heb ik het maar weer eens geprobeerd, zie hier.
En wat blijkt? Het rendert 2x langzamer dan de met de script tag geoptimaliseerde div's.

Daarnaast zitten er nog een paar layout technische nadelen, mn mbt de meest linker en meest rechter kolommen die een statische breedte hebben en nu niet overflowen zoals ik het wil.

Maar mijn eigenlijke vraag blijft dus staan, waarom rendert IE een pagina 20x zo snel door het toevoegen van een lege <script> tag? Hopelijk weet iemand op deze specieke vraag nog een antwoord

[Dekaasboer]

Haha,

Er achterkomen waaromen waarom IE dit soort rare dingen doet is volgens mij even futiel als de eeuwige div/ tabellen discussie.

Misschien worden er buffers/ systeembronnen geactiveerd/ vrijgemaakt op het moment dat er scripts in de BODY voorkomen en snelt dat het proces op?

[Bosmonster]

pimlie schreef op vrijdag 30 mei 2008 @ 15:16:
Maar mijn eigenlijke vraag blijft dus staan, waarom rendert IE een pagina 20x zo snel door het toevoegen van een lege <script> tag? Hopelijk weet iemand op deze specieke vraag nog een antwoord

Die vraag kun je beter bij MS neerleggen denk ik. Wij hebben heel weinig kaas gegeten van de sourcecode van IE.

Dat de oplossing werkt voor jou is mooi, gebruik het en wees er blij mee zou ik zeggen.