[JS] Javascript performance statistics

[g4wx3]

Javascript is de laatste jaren stukken sneller geworden, dankzij chrome, en frameworks die sterk optimaliseren.

Maar dit gaat altijd om ideale situaties, snelle computers, geen browser-rommel.

Hoe zit het met de real-life performance van javscript?
Dit over alle browser en systemen heen?

Ik kon hier geen info over vinden op internet.
De werkelijke gebruikers ervaring van javascript.

(Google moet toch iets hierover weten?)

[TERW_DAN]

http://jsperf.com
JSperf is op zich wel een manier om te kijken hoe vlot je scripts draaien. Ik vind je vraag ook een beetje vaag om er echt een heel concreet antwoord op te kunnen geven eigenlijk. Welke performance wil je exact weten?

[R4gnax]

g4wx3 schreef op zaterdag 14 februari 2015 @ 12:35:
Hoe zit het met de real-life performance van javscript?
Dit over alle browser en systemen heen?

De bottleneck is al jaren niet meer JS, maar de DOM en het layout algoritme v/d browser. Zoek maar eens naar het vermijden van layout en repaint en je zult flink wat result hits krijgen, denk ik.

[g4wx3]

R4gnax schreef op zondag 15 februari 2015 @ 18:39:
[...]


De bottleneck is al jaren niet meer JS, maar de DOM en het layout algoritme v/d browser. Zoek maar eens naar het vermijden van layout en repaint en je zult flink wat result hits krijgen, denk ik.

Dit is inderdaad een intressante opmerking.

Ik stel namelijk vast dat de snelheid van "het internet", bij gebruikers nogal fors kan varieren.
Dit lossstaand van de eigenlijke internetsnelheid, en de lokale verbindingsmethode.
Enerzijds de computer-performance pc/tablet (hardware-kant), maar anderzijds, vooral browser-keuze en al dan niet rommel in het OS of de browser, (Software kant)

Het blijft belangrijk voor de gebruiker, en voor het mileu, om optimalisaties te doen op afbeeldingen, framework en database-queries.

Om javascript sneller te doen reageren, zou de DOM, dus de HTML moeten worden geoptimaliseerd.

Dit beantwoord wel mijn vraag. Toch eigenaardig dat er weinig aandacht wordt gegeven aan de werkelijke laadtijd bij grote sites. (dus hoe lang een gemiddelde gebruiker wacht op een site)

Zie bijvoorbeeld dit artikel:
http://marketingland.com/...uring-the-last-year-37604

[n8n]

R4gnax schreef op zondag 15 februari 2015 @ 18:39:
[...]


De bottleneck is al jaren niet meer JS, maar de DOM en het layout algoritme v/d browser. Zoek maar eens naar het vermijden van layout en repaint en je zult flink wat result hits krijgen, denk ik.

Daarom altijd eerst je DOM in de js bouwen en dan in 1 keer toevoegen, dus niet elk item apart painten. DOM operaties zijn nog aardig snel, het painten is de ware bottleneck.

Jsperf kan je inderdaad gebruiken om te testen. Zorg ook dat je geen variabelen creëert in een loop statement, of fucties declareert in een loop. Als snelheid je ding is zou ik ook ver weg blijven van jQuery.

[McVirusS]

fastdom is wel interessante library om DOM manipulatie te optimaliseren. Werkt behoorlijk goed (goed zichtbaar bij dingen die vaak updaten bijv. aan de hand van scrollpositie).

Daarnaast is dit wel erg brede vraag van TS. Wat wil je precies meten/weten? Performance van mobiele devices is natuurlijk minder goed als van desktop computers. Maar hoe belangrijk dat is hangt ook weer af van je doelgroep. Goede algemene tip is goed naar je Google Analytics kijken welke apparaten/browsers populair zijn op jouw site en daar op testen.

[R4gnax]

n8n schreef op zondag 15 februari 2015 @ 20:36:
[...]
Daarom altijd eerst je DOM in de js bouwen en dan in 1 keer toevoegen, dus niet elk item apart painten. DOM operaties zijn nog aardig snel, het painten is de ware bottleneck.

Zolang je enkel een repaint nodig hebt is er eigenlijk nog niet veel aan de hand. De killer is een relayout, waardoor dimensies van meerdere elementen veranderen en waardoor meerdere elementen een repaint nodig gaan hebben.

Uiteraard is het beste nog steeds als je alles enkel door de compositor af kunt laten handelen. Dat komt er eigenlijk op neer dat wanneer je zaken snel opeenvolgend gaat veranderen (bijv voor animatie) je altijd zoveel mogelijk via compositor operaties probeert te werken, dwz CSS transform of opacity wijzigingen en niet veel anders.