---
Prozium - The great nepenthe. Opiate of our masses. Glue of our great society. Salve and salvation, it has delivered us from pathos, from sorrow, the deepest chasms of melancholy and hate
Professioneel Hyves-weigeraar
Het feit dat een andere categorie sneller laad zegt niet automatisch dat het niet aan het javascript ligt. Het is uiteraard logisch dat een pagina met minder entries sneller is geladen; of daar nu JavaScript of HTML voor gebruikt wordtRobin Vreuls schreef op 26 november 2003 @ 23:34:
Dat komt niet door de javascript maar eerder door het aantal prijzen dat weergegeven moet worden en gerenderd wordt door de browser. Als je naar een andere categorie surft met minder entries, dan is de pagina sneller geladen.
ik dacht al dat dat de reden was; is de besparing echt zo groot als er bijvoorbeeld al gebruik wordt gemaakt van gzip compressie?Wouter Tinus schreef op 26 november 2003 @ 23:35:
Bespaart bandbreedte,
Dat is altijd mooi; ik begrijp dat jullie hier al even mee bezig zijn maar begrijp dat het even duurt voor alles gecategoriseerd iser zijn geen plannen om er HTML van te maken, wel om die categorie te splitsen in subcategorieën zodat de pagina minder groot is.
Interessant punt. Je stelt dus dat exact dezelfde pagina maar met html tabellen in plaats van JavaScript even snel wordt geladen?Femme schreef op 26 november 2003 @ 23:40:
De traagheid wordt veroorzaakt door de grote tabellen, niet door javascript.
---
Prozium - The great nepenthe. Opiate of our masses. Glue of our great society. Salve and salvation, it has delivered us from pathos, from sorrow, the deepest chasms of melancholy and hate
Bij net gebruik van CSS en een list voor de items ipv een table (de enige HTML-overhead is dan nog een li-tag) denk ik dat je zelfs kleinere pagina's zonder JS kan genereren...
Gaat misschien niet helemaal op voor de pricewatch data wat toch wel tabulair is in essentie en meerdere kolommen bevat, ik ga eens naar die pw1 functie kijken wat die doet...
[ Voor 21% gewijzigd door crisp op 27-11-2003 00:27 ]
Intentionally left blank
Dat punt probeerde ik inderdaad ook al te maken; ik denk dat bij het gebruik van gzip compressie de repeterende tabel tags netjes gecomprimeerd zouden worden (aanname). Uiteraard zijn hier verdere tests voor nodig; maar ik zie toch het liefst plain HTML binnenstromen in plaats van ellenlange JavaScript statements (die mijn browser vervolgens moet gaan uitvoeren). Is er vanuit Tweakers.net de intentie om deze clientside scripting te gaan vervangen door serverside scripts?crisp schreef op 27 november 2003 @ 00:14:
door het gebruik van javascript is de load op de client toch wel degelijk hoger dan wanneer die client alleen HTML voorgeschoteld zou krijgen en dus alleen maar zou hoeven te parsen in plaats van de HTML eerst nog middels javascript te creëeren.
Bij net gebruik van CSS en een list voor de items ipv een table (de enige HTML-overhead is dan nog een li-tag) denk ik dat je zelfs kleinere pagina's zonder JS kan genereren...
---
Prozium - The great nepenthe. Opiate of our masses. Glue of our great society. Salve and salvation, it has delivered us from pathos, from sorrow, the deepest chasms of melancholy and hate
Verder zie ik dat er per item in de pricewatch een functiecall wordt gedaan; dat moet imho efficienter kunnen. Ook die afvragingen kan je anders (sneller) doen met een predefined array en een index.
even een voorbeeldje wat efficienter kan; per call wordt bijvoorbeeld de achtergrond bepaald:
1
2
3
4
5
6
7
8
9
10
11
| var pw_bg=0; var pw_bghtml_array=[]; var pw_bghtml_array[0]="background='" + ImgURL + "g/table/bg1.gif'"; var pw_bghtml_array[1]="background='" + ImgURL + "g/table/bg2.gif'"; function pw_bg_cycle() { pw_bg = 1 - pw_bg; return pw_bghtml_array[pw_bg]; } |
nu kan je dus in je functie gewoon dit doen:
1
| document.write('<table '+pw_bg_cycle()+'>'); |
nog mooier is natuurlijk om dit gewoon met CSS te doen en een alternate class
ook zou je binnen de functie het aantal document.write's kunnen beperken tot 1, en in plaats van elk stukje string als apart argument meegeven er eerst 1 string van bakken.
In het geval dat het een erg lange string zou worden verdient het aanbeveling dat met array elementen op te lossen die je op het laatst met een join('') samenvoegd (IE wordt erg traag bij het werken met lange strings).
Ik zal vandaag eens kijken of ik wat dingen kan benchmarken. Het viel mij ook al op dat mijn browser (IE6 / win2k / AMD XP2000) veel moeite had met de genoemde pagina.
[ Voor 83% gewijzigd door crisp op 27-11-2003 08:51 ]
Intentionally left blank
[ Voor 48% gewijzigd door crisp op 27-11-2003 12:01 ]
Intentionally left blank
JS Executietijd van de verwerking van de pricewatch tabel (1178 items) win95 P3 350Mhz:Femme schreef op 27 november 2003 @ 15:53:
Precies wat ik bedoel, javascript levert nauwelijks extra belasting op voor de client.
IE5.5: 1200 ms
Mozilla 1.3 / Firebird 0.7: 2640 ms
toch nog behoorlijk naar mijn mening
na wat JS aanpassingen:
IE5.5: 600 ms
Mozilla 1.3 / Firebird 0.7: 1370 ms
da's nog maar de helft, dus loont toch wel - zeker voor de wat minder krachtige PC's.
Verdere optimalisaties moet je dus gaan zoeken in het minimaliseren van de gegenereerde HTML (zoveel mogelijk met CSS oplossen)
Intentionally left blank
---
Prozium - The great nepenthe. Opiate of our masses. Glue of our great society. Salve and salvation, it has delivered us from pathos, from sorrow, the deepest chasms of melancholy and hate
Net getest; gegenereerde content was zo'n 1.5 MB en het parsen duurde respectievelijk 12 seconden in IE5.5 en 48(!?) seconden in Mozilla hoewel Moz wel al na een seconde of 4 al een deel van de tabel liet zien terwijl IE 'm pas na 12 seconden volledig op het scherm zette.Spider.007 schreef op 27 november 2003 @ 17:22:
Heb je hierbij ook getest hoelang de verwerking van een pagina zonder javascript duurt? Volgens mij bied oa. FireBird een 'Generated Source' view op de pagina; je zou kunnen kijken hoelang het duurt om deze clientside op te bouwen.
Die parsetijden zit je dus gewoon aan vast, ook als je het niet door JS laat genereren en de enige mogelijkheid om dat sneller te krijgen is door de HTML structuur kleiner en eenvoudiger te maken.
Nu is dit ook wel een extreem trage PC met weinig geheugen moet ik zeggen
Intentionally left blank