Demos: http://jsperf.com/jquery-performance-2015
Die folgenden Tipps erklären wie man die Performance von jQuery verbessern kann, einfach indem man das Framework korrekt einsetzt und bei kritischem Code auf JavaScript zurückgreift.
– verwende “gute” Selektoren
– verwende Variablen als Cache
– verwende “chaining” -> .function1().function2()…
– vermeide Dom Interaktionen
jQuery-Selektor Performance
Sehr Schnell: $(“#id”) || $(#id).find(“.class”)
Schnell: $(“tag.class”)
Normal: $(“.class”) || $(“.class”).children()
Langsam: $(“tag”)
Langsamer: $(“tag1 tag2”) || $(“.class tag:type”)
Extrem Langsam: $(“.class > *”) || $(“.class :type”)
Daraus ergibt sich z.B. das eine Kombination aus “.class #id” langsamer ist, als ein einfacher “#id”-Selektor. Deshalb ist es bei jQuery auch schneller einen bestimmten Bereich im Dom via “#id”-Selektor zu laden und anschließend in der entsprechenden Variable nach weitern HTML-Fragmenten zu suchen. -> .find()
Zudem sollte man bei Selektoren bedenken, dass rechts immer der spezifischste Ausdruck stehen sollte. Gegebenenfalls benötigt man jedoch gar keine lange Selektoren, wenn man Zugriff auf das entsprechende HTML hat, um dieses zu ändern.
// Unoptimiert:
$(“tag1.class1 .class2”)
// Optimiert:
$(“.class1 td2.class2”)
Demo (#id vs .class):
http://jsperf.com/cached-jquery-selector-2015-v2/2
Demo (jQuery – find):
http://jsperf.com/cached-jquery-selector-2015-v3
Demo (jQuery – find vs jQuery Plugin):
http://jsperf.com/cached-jquery-selector-vs-jquery-plugin
Demo (jQuery – simple vs jQuery Plugin):
http://jsperf.com/jquery-simple-vs-jquery-plugin
Demo (Zepto.js vs jQuery):
http://jsperf.com/cached-jquery-selector-vs-zepto-selector-v2/5
Demo (Zepto.js vs jQuery vs Sprint.js vs JavaScript):
http://jsperf.com/zepto-vs-jquery-2013/103
Demo (Sprint.js vs jQuery):
http://jsperf.com/cached-jquery-selector-vs-sprintjs-selector
Demo (JavaScript vs jQuery):
http://jsperf.com/cached-jquery-selector-vs-javascript
IMMER Variablen als Cache verwenden
Um auf bestimmte HTML-Fragmente im Dom zuzugreifen ist es aus Performance-Sicht hilfreich, wenn man sich einen Teil vom Dom in einer Variable speichert und anschließend nur noch innerhalb von JavaScript arbeitet. z.B.:
// Sehr langsam (& Sinnfrei):
$('.myElement span').each(function(i) {
$('.myElement span').eq(i).css('color', 'green');
});
// Langsam:
$('.myElement span').each(function() {
$(this).css('color', 'green');
});
// Langsam:
$('.myElement span').css('color', 'green');
// Schneller:
$('#myElement').find('span').css('color', 'green');
// Noch schneller: (jQuery + JavaScript)
myElement = $('#myElement').find('span');
for (var i = 0, len = myElement.length; i < len; i++) {
myElement[i].style.color = 'green';
}
// Sehr schnell: (kein jQuery)
myElement = document.querySelector('.myElement');
myElement = myElement.querySelectorAll('span');
for (var i = 0, len = myElement.length; i < len; i++) {
myElement[i].style.color = 'green';
}
// Sehr sehr schnell: (kein jQuery)
myElement = document.getElementById('myElement');
myElement = myElement.getElementsByTagName('span');
for (var i = 0, len = myElement.length; i < len; i++) {
myElement[i].style.color = 'green';
}
Demo (mit / ohne Cache-Variable):
http://jsperf.com/cached-jquery-selector-2015-v2
Zusammenfassung:
jQuery ist im Vergleich mit JavaScript oder anderen Frameworks langsamer, aber wenn man z.B. noch den IE8 unterstützen muss, sollte man auf ein umfassendes Framework wie jQuery nicht verzichten, da ansonsten die entgütige Entwicklungszeit (z.B. Bugfixes für IE) die bessere Performance nicht rechtfertigt. Ein weitere Pluspunkt für jQuery sind die viele bereits fertigen jQuery-Plugins. Außerdem kann man die Performance von jQuery verbessern, wenn man beim programmieren von jQuery-Plugins darauf achtet so wenig Dom-Selektoren “$()” bzw. Dom-Interaktionen wie möglich zu nutzen.
Um dies zu bewerkstelligen kann man z.B. auf das jQuery Boilerplate zurückgreifen, so dass man bereits eine erste Programmier-Struktur vorgegeben hat. Dies hat zusätzlich den Vorteil, dass die eigenen Plugins, die jQuery typische Verkettung von Befehlen unterstützen. Außerdem gewöhnt man sich somit daran in Modulen / Plugins zu denken, welche man zudem durch dessen Konfiguration auch wiederverwenden kann.
Zepto.js war bei meinen Tests keine Alternative zu jQuery, da z.B. ein each() kein zepto-object zurückgibt, so dass man innerhalb der Schleife wieder einen Selektor benötigt. Das Framework nutz die Syntax und Namen wie jQuery, verhält sich jedoch leider etwas anders.
Sprint.js war in den Tests bei weitem schneller als jQuery, jedoch unterstützt dieses Framework nur IE 10+, außerdem ist dieses Framework nicht mal ein Jahr alt, die Dokumentation ist noch nicht vorhanden (bzw. verweist auf die jQuery Dokumentation) und es wurde noch nicht von so vielen Entwicklern getestet wie z.B. jQuery.
Links:
– Erklärung zu jQuery- bzw. CSS-Selektoren: http://suckup.de/howto/jquery/crashkurs-jquery-selektoren/
– Effektive CSS-Selektoren: https://css-tricks.com/efficiently-rendering-css/
– jQuery Performance (Tizen): https://developer.tizen.org/dev-guide/2.3.0/org.tizen.guides/html/web/w3c/perf_opt/jquery_performance_improvement_w.htm
– jQuery Performance (jQuery): http://learn.jquery.com/performance/optimize-selectors/
– jQuery Performance (Blog-Post): http://blog.dareboost.com/en/2014/04/jquery-performance-optimization/
