[js] zorgt voor hoge load clientside

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • Spider.007
  • Registratie: December 2000
  • Niet online

Spider.007

* Tetragrammaton

Topicstarter
Ik merk plotseling een hoge load bij het laden van bijvoorbeeld deze pagina. Op FireBird@AMD2000Xp gaat de CPU hier 6 seconden naar de 100%. Ik neem aan dat dit komt door de JS die wordt gebruikt om alle gegevens weer te geven. Is er de intentie om dit op ooit te gaan vervangen door 'normale' html of is er een bijzondere reden dat alle met JavaScript wordt gedaan?

[ Voor 3% gewijzigd door Spider.007 op 26-11-2003 23:10 ]

---
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


Acties:
  • 0 Henk 'm!

  • Robin
  • Registratie: Juni 2001
  • Niet online
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.

Acties:
  • 0 Henk 'm!

  • Wouter Tinus
  • Registratie: Oktober 1999
  • Niet online

Wouter Tinus

Whee!

Bespaart bandbreedte, er zijn geen plannen om er HTML van te maken, wel om die categorie te splitsen in subcategorieën zodat de pagina minder groot is.

Professioneel Hyves-weigeraar


Acties:
  • 0 Henk 'm!

  • Femme
  • Registratie: Juni 1999
  • Laatst online: 10:55

Femme

Hardwareconnaisseur

Official Jony Ive fan

De traagheid wordt veroorzaakt door de grote tabellen, niet door javascript.

Acties:
  • 0 Henk 'm!

  • Spider.007
  • Registratie: December 2000
  • Niet online

Spider.007

* Tetragrammaton

Topicstarter
Robin 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.
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 wordt :)
ik dacht al dat dat de reden was; is de besparing echt zo groot als er bijvoorbeeld al gebruik wordt gemaakt van gzip compressie?
er zijn geen plannen om er HTML van te maken, wel om die categorie te splitsen in subcategorieën zodat de pagina minder groot is.
Dat is altijd mooi; ik begrijp dat jullie hier al even mee bezig zijn maar begrijp dat het even duurt voor alles gecategoriseerd is :)
Femme schreef op 26 november 2003 @ 23:40:
De traagheid wordt veroorzaakt door de grote tabellen, niet door javascript.
Interessant punt. Je stelt dus dat exact dezelfde pagina maar met html tabellen in plaats van JavaScript even snel wordt geladen?

---
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


  • crisp
  • Registratie: Februari 2000
  • Nu online

crisp

Devver

Pixelated

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...

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


  • Spider.007
  • Registratie: December 2000
  • Niet online

Spider.007

* Tetragrammaton

Topicstarter
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...
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?

---
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


  • crisp
  • Registratie: Februari 2000
  • Nu online

crisp

Devver

Pixelated

eerlijk gezegd lijkt het me ook weinig onderhoudsvriendelijk door zo via JS je layout uit te zetten.
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:

JavaScript:
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:

JavaScript:
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


  • crisp
  • Registratie: Februari 2000
  • Nu online

crisp

Devver

Pixelated

Met wat tweaks krijg ik het hooguit 15% sneller (IE5.5 van 13 naar 11 seconden Firebird 0.7 van 27 naar 24 seconden op een P3 350Mhz). De parsetijd is toch de grootste bottleneck want de winst op de JS executietijd is maar ongeveer een halve seconde, de rest van de winst komt uit het feit dat ik meer in CSS had gestopt en een colgroup had opgegeven met de breedtes van de kolommen zodat ik niet voor elke regel de width in de td hoefde te zetten (kortere strings)...

[ Voor 48% gewijzigd door crisp op 27-11-2003 12:01 ]

Intentionally left blank


  • Femme
  • Registratie: Juni 1999
  • Laatst online: 10:55

Femme

Hardwareconnaisseur

Official Jony Ive fan

Precies wat ik bedoel, javascript levert nauwelijks extra belasting op voor de client.

  • crisp
  • Registratie: Februari 2000
  • Nu online

crisp

Devver

Pixelated

Femme schreef op 27 november 2003 @ 15:53:
Precies wat ik bedoel, javascript levert nauwelijks extra belasting op voor de client.
JS Executietijd van de verwerking van de pricewatch tabel (1178 items) win95 P3 350Mhz:

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


  • Spider.007
  • Registratie: December 2000
  • Niet online

Spider.007

* Tetragrammaton

Topicstarter
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.

---
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


  • crisp
  • Registratie: Februari 2000
  • Nu online

crisp

Devver

Pixelated

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.
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.
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

Pagina: 1