Rendersnelheid van Firefox

[SuperRembo]

Waarom is Firefox toch zo gruwelijk traag in het renderen van grote tabellen en grote aantallen form velden?

Internet Explorer rendert met gemak een pagina met 1000 invoervelden in 0.02 seconden, Opera heeft er 0.15 s voor nodig, maar bij Firefox duurt het wel 0.45 s! Bij grote tabellen is Firefox vaak een factor 10-50 trager dan IE. Bij de combinatie, een grote tabel met in elke cell een invoerveld is het nog beroerder. Het verbaast me dat een tekst-invoerveld veel meer tijd kost dan bijvoorbeeld een checkbox.

Natuurlijk kan je beter voorkomen dat je zo veel velden of zulke grote tabellen gebruikt, maar soms ontkom je er niet aan, of is het niet mogelijk om snel een betere oplossing te realiseren.

Een tabel kan wat sneller worden door de kolombreedtes te specificeren samen met table-layout: fixed. Het lijkt erop dat autocomplete="off" een tekstveld iets sneller maakt. Zijn er nog andere dingen die ik in de html kan toepassen? Zijn er in Firefox nog instellingen te wijzigen die het renderen sneller maakt?

[BtM909]

Ja er zijn nog meer instellingen. Zoek even in CSA naar firefox tweaks of via google.

Wat is voor de rest je discussiepunt. Wil je de performance van rendering bespreken, maak dan eens een mooie testcase, zet die online (met eventuele timestamps). Dat discussieert wat makkelijker

[XWB]

Internet Explorer heeft sowieso al weinig te renderen Opera is inderdaad erg vlot, maar die doet dat op een andere manier geloof ik. Firefox 3.0 is overigens een stuk sneller dan 2.0

Verder boeit het me weinig, alles onder 1 seconde merk je toch zo goed als niet.

[SuperRembo]

Ja een online testcase is wel handig. Ik had net een langer verhaal getypt maar Firefox ging onderuit bij 1000 selectboxes

[curry684]

Ik mis het punt ergens. Wat je zegt is dat de ene auto goed rijdt op stront, en de andere niet. Ik zou er dan persoonlijk voor kiezen om er geen stront in te gooien in plaats van over de fabrikant te klagen.

[crisp]

Elke browser heeft wel bugs, ook op het gebied van form-elementen. Kijk maar eens wat er met Opera gebeurd als je dit laat renderen en probeert een radio-button te selecteren:

PHP:

<?php

for ($i = 1; $i < 1000; $i++)
    echo '<input type="radio" name="foo" value="' . $i . '">Optie ' . $i . '<br>';

?>

[SuperRembo]

curry684 schreef op woensdag 19 december 2007 @ 23:33:
Ik mis het punt ergens. Wat je zegt is dat de ene auto goed rijdt op stront, en de andere niet. Ik zou er dan persoonlijk voor kiezen om er geen stront in te gooien in plaats van over de fabrikant te klagen.

Ik klaag niet, verbaas me vooral over het grote verschil _{nou ok, ik klaag misschien ook een beetje}

In 99.99% van de gevallen werkt het perfect, alleen sommige klanten eten erg veel waardoor hoeveelheid stront die ze te verwerken krijgen erg groot kan worden. Ik ben op zoek naar (eenvoudige) oplossingen waarmee ik het leed kan verlichten terwijl er ondertussen aan een structurele oplossing wordt gewerkt.

Een paar testcases staan hier

[ Voor 32% gewijzigd door SuperRembo op 19-12-2007 23:49 ]

[Verwijderd]

Heb hier op m'n Mac ook je testcases geprobeerd.

• Safari (althans de laatste nightly Webkit) doet over alle voorbeelden minder dan een halve seconde. Geen merkbare wachttijd in elk geval (want schijnbaar hebben ze bij Apple een trucje ingebouwd om bij dit soort tests te frauderen; geen idee of dat hier een rol speelt.).
• Opera is iets langzamer, maar nog steeds erg snel. Inderdaad duurt het erg lang om één van de radiobuttons te selecteren (paar seconden), zoals Crisp al zei.
• Firefox is even snel als Opera, behalve in het voorbeeld van de tabel met text-inputs: meer dan 30 seconden. Raar dat alleen de combinatie zo traag is. Aan de rest merk ik niets geks.
• Camino is ietsje trager dan Firefox, maar nog veel trager in het voorbeeld van de tabel met text-inputs: bijna een minuut! Ik zou gegokt hebben dat Camino sneller zou zijn, omdat het van de aqua-interface van de Mac gebruik maakt, wat een voordeel zou kunnen zijn.

Gokje: beperkte maxlength instellen? (Voor hetzelfde geld wordt -ie nog trager.)

Overigens vind ik dat je alle recht hebt om te klagen. Dit moet FF gewoon snel kunnen, zoals andere browsers.

[_Thanatos_]

1000 invoervelden in 0,45 seconden. Nou w00t. Hoeveel heb je er dan dat het zoveel boeit dat je er een topic over moet openen? En als een tabel (met tabulaire data dus) te groot wordt, introduceer je hoe dan ook paging voor de leesbaarheid.

Met andere woorden, ga niet zitten zeveren op *enorme* pagina's want die hoor je gewoon niet te hebben. Dus ik zeg: het boeit niet.

[SuperRembo]

Het gaat om een form waar in uitzonderlijke gevallen 200 regels staan. Elke regel bevat een stuk of 30 form elementen, dus zo'n 6000 form velden (invoervelden, selectboxen, en knoppen) in totaal. In IE staat zo'n pagina er in een seconde of 5-6, maar in Firefox pas na 30-50 seconden. Dat is het verschil tussen nog net werkbaar en niet werkbaar.

Het inbouwen van paging is niet triviaal. Er worden totalen berekend, waarden verdeeld over meerdere regels, controles uitgevoerd, etc. Dit moet er uiteindelijk wel komen, maar dat duurt nog even.

[Plague]

Functies groeperen dan maar? Kan je iets meer over de context vertellen? Want imho is een form met 6000 form-velden op zich al onwerkbaar. Daarnaast zeg je totalen, maar kan je dan niet beter ipv tekstvelden gewoon tekst tonen? M.a.w: textfields waar je dingen moet invoeren, en gewone tekst waar je de totalen laat zien. Lijkt me ook duidelijker voor de gebruiker. En dan hoop ik voor je dat je op ongeveer 500 invoervelden blijft steken, want meer dan 500 velden invullen is gewoon echt zeer matig. Of dynamisch opbouwen d.m.v. JavaScript (steeds 1 of x regels toevoegen wanneer nodig).

[moozzuzz]

_Thanatos_ schreef op donderdag 20 december 2007 @ 04:04:
Dus ik zeg: het boeit niet.

Het boeit voor jou niet. Het blijft technisch gezien erg merkwaardig dat browsers zo van streek geraken bij veel form-elementen of veel table-structuur, terwijl zeker dat laatste relatief eenvoudig is. Probeer voor de gein es een tabel van (10.000 rijen x 2 col) es te selecteren in FF en dan in IE. (real live voorbeeld: ooit es een klein PHP'tje geschreven om alle *mediafiles* van mijn externe HD uit te schrijven. FF crashte toen ik de boel in een spreadsheet wou gooien; IE had het even moeilijk maar bleef overeind.)

[curry684]

Punt blijft staan dat je de browser gebruikt voor iets waar ie niet voor bedoeld is. Je PHP file had ook gewoon een csv kunnen genereren met content-disposition attachment.

Dat crashen niet mag staat buiten kijf, maar dat ze het moeilijk hebben met mishandeling: tja.

[Voutloos]

moozzuzz schreef op donderdag 20 december 2007 @ 09:14:
(real live voorbeeld: ooit es een klein PHP'tje geschreven om alle *mediafiles* van mijn externe HD uit te schrijven. FF crashte toen ik de boel in een spreadsheet wou gooien; IE had het even moeilijk maar bleef overeind.)

Of je output het gewoon als csv ipv een table. Eenvoudig(er) en doeltreffend.

edit:
ik blijf maar spuit 11 reacties plaatsen laatste tijd...

[ Voor 7% gewijzigd door Voutloos op 20-12-2007 09:21 ]

[RM-rf]

moozzuzz schreef op donderdag 20 december 2007 @ 09:14:
[...]

Het boeit voor jou niet. Het blijft technisch gezien erg merkwaardig dat browsers zo van streek geraken bij veel form-elementen of veel table-structuur, terwijl zeker dat laatste relatief eenvoudig is.

I beg to differ ...

zeker tabellen en ook form-elementen zijn niet de simpelste elementen om te renderen omdat ze zo hun eigen eigenschappen hebben en dus specifieke eisen stellen aan hun weergave (form-elementen die veel extra events moeten kunnen afvangen en tabellen waarbij dus eigenlijk de cellen onderling gerelateerd zijn en hun verschijningsvorm ook danken aan de grootte van omliggende cellen, kolommen en rijen)...

wat veel browsers meestal doen is ofwel het 'brak' toepassen van juist de standaards om aan rendertijd te winnen, of andere trucjes die je als ontwikkelaar meestal niet werkt, totdat je op een gegeven moment tegen vreemde en oneigenlijk gedrag van de browser aanloopt, en dan is het een des te grotere klus daar weer omheen te werken...

Om heel eerlijk te zijn zou ik eerder opteren voor iets langzamere browsers die wel correct renderen en zich juist aan de standaards houden... echter voor het brede publiek is dat nu juist iets waarvan ze het voordeel niet duidelijk genoeg merken en daarom is het veel 'populistischer' om 'quic-and-dirty' te renderen en denken veel gebruiker juist een goede browser te hebben omdat die 'lekker snel' is.

[SuperRembo]

Plague schreef op donderdag 20 december 2007 @ 09:09:
Daarnaast zeg je totalen, maar kan je dan niet beter ipv tekstvelden gewoon tekst tonen? M.a.w: textfields waar je dingen moet invoeren, en gewone tekst waar je de totalen laat zien. Lijkt me ook duidelijker voor de gebruiker.

Er worden totalen berekend (op de client) over de ingevoerde regels. Er staan op de regels invoervelden die door gewone tekst kunnen worden vervangen.

curry684 schreef op donderdag 20 december 2007 @ 09:17:
Punt blijft staan dat je de browser gebruikt voor iets waar ie niet voor bedoeld is. Je PHP file had ook gewoon een csv kunnen genereren met content-disposition attachment.

De testcase is uiteraard een vereenvoudigde voorstelling van de werkelijke pagina

[Voutloos]

offtopic:
SuperRembo, dat csv verhaal slaat specifiek op moozzuzz' post

[curry684]

RM-rf schreef op donderdag 20 december 2007 @ 09:57:
[...]

I beg to differ ...

En groot gelijk. Ik heb door de jaren heen wel een paar layoutengines geschreven, en niets zo ruk als tabel-achtige structuren. Want je moet er rekening mee houden dat als op row 9867 ineens een cell niet past en dus expand-to-content moet doen, de vorige 9866 rows weer overnieuw gedaan moeten worden. Waarna ineens andere cellen niet meer passen op basis van de regels van de tabel als geheel, en je dus wederom recursief de hele tabel moet narekenen op basis van nieuwe kennis. Op die manier is het heel snel een heel erg exponentieel probleem waar je mee zit, omdat alles aan elkaar geknoopt is, in tegenstelling tot standaard layouts waarbij de flow zichzelf wel berekent.

Ik durf uit ervaring best te zeggen dat hoe sneller een table-based rendering is, hoe meer niet noodzakelijk valide shortcuts hij maakt om dat effect te bereiken. En als archetype van de table-based renderers kan ik me dus al helemaal wel voorstellen dat de IE-engine jarenlang is geoptimaliseerd op tables renderen ja. Dank aan Frontpage en HTML 3.x, niet aan de developers.

SuperRembo schreef op donderdag 20 december 2007 @ 10:10:
[...]

De testcase is uiteraard een vereenvoudigde voorstelling van de werkelijke pagina

Zoals Voutloos deze keer op tijd zegt hadden we het over het specifieke geval, maar ik weet 100% zeker dat de kern ook voor jouw situatie opgaat: dat je iets aan het doen bent wat je niet in een webpage moet doen. Duizenden invoervelden heb je spreadsheets voor, geen webpagina's, net zoals het leuk is dat je in een webpagina beperkte rich-text editors kunt zetten maar je een afstudeerscriptie ook beter in Word of LaTex kunt opstellen.

[ Voor 11% gewijzigd door curry684 op 20-12-2007 11:52 ]

[SuperRembo]

Ik weet dat de huidige pagina niet is zoals het hoort. Je kunt er natuurlijk over blijven doorzeuren, maar zoals gezegd staat er een paging oplossing in de planning.

Ik begrijp dat het renderen van een tabel lastig is, ik verbaas me vooral over de traagheid van de invoervelden. Ook bij kleine aantallen is Firefox daarmee een factor 10 trager dan IE.

Ik ben dus op zoek naar relatief eenvoudige aanpassingen die ik kan maken om het geheel sneller te maken.

Voutloos schreef op donderdag 20 december 2007 @ 10:15:

offtopic:
SuperRembo, dat csv verhaal slaat specifiek op moozzuzz' post

offtopic:
Sorry, dan heb ik niet goed gelezen

[curry684]

SuperRembo schreef op donderdag 20 december 2007 @ 14:49:
Ik weet dat de huidige pagina niet is zoals het hoort. Je kunt er natuurlijk over blijven doorzeuren, maar zoals gezegd staat er een paging oplossing in de planning.

De neiging hier op GoT is nu eenmaal dat we liever waardevol advies geven waar je echt wat aan hebt dan assisteren bij belabberde workaroounds

[Juup]

Hier is nog een alternatief:

Render alle values gewoon als plaintext, en pas als je op een rij klikt maak je er inputs van.

[curry684]

Als je dan toch Ajax doet, bouw dan een nette JSON data-fetcher en pager die 50 rows met inputs per pagina toont en automagisch previous/next en progressive searching erbij genereert.