Ein Nachteil von jQuery? Performance!

jQuery ist eine beliebte Library zur DOM-Manipulation (und mehr) in JavaScript. Diese Library hat wahrscheinlich mehr Anwender zu JavaScript gebracht als irgendetwas anderes. Sie beschleunigt den Entwicklungsprozess erheblich, vor allem für Anfänger und bei Cross-Browser-Problemen. Vor noch nicht allzu langer Zeit war Letzteres ein echtes Problem. Heute bietet JavaScript, abgesehen von der Implementierung des InternetExplorers, viele / ausreichend Funktionen zur DOM-Manipulation.

Beim Review eines JavaScript-Codes eines Kollegen, welcher jQuery nutzt, unterhielten wir uns zunächst nur über die performance Unterschiede zwischen Caching und nicht Caching von Elementen zur Manipulation der Width-Eigenschaft. Es wurde eine $(selector).each() verwendet und es ging darum, ob innerhalb der Each-Function das aktuelle DOM-Element gecached wird, oder nicht.

// !--- Caching
$(selector).each(function( index ) {
  var $el = $(this);
  // 2-3 DOM-Manipulationen an dem Element
  // mit Benutzung von $el, z.B. $el.width()
});

// !--- kein Caching
$(selector).each(function( index ) {
  // 2-3 DOM-Manipulationen an dem Element
  // mit Benutzung von $(this), z.B. $(this).width()
});

Da es wirklich nur zwei – drei Anweisungen waren, ging es zunächst nur darum, ob die extra Zeile mit der Anweisung des Cachings nötig ist oder ob es in diesem Fall wirklich Vorteile in der Performance bringt. Der Performance-Frage bin ich dann mit jsPerf hinterher gegangen. Dank einer kleinen Diskussion kamen zwei Dinge zum Vorschein:

  1. jQuery.width() ist extrem langsam und sollte durch jQuery.css() ersetzt werden.
  2. Plain JavaScript schlägt die jQuery Performance um viele 100 wenn nicht sogar 1000%.

Zum ersten Punkt:

“One thing that hasn’t changed is the return value of the .width() method. As it’s always been documented, it gets and/or sets the “content” width of an element, and that is regardless of the CSS box-sizing being used by the element. However, jQuery 1.8 now needs to check the box-sizing property whenever you use .width() so that it can decide whether it needs to subtract out the padding and border width. That can be expensive—up to 100 times more expensive on Chrome!”
http://blog.jquery.com/2012/08/16/jquery-1-8-box-sizing-width-csswidth-and-outerwidth/

Auf obiges Zitat bin ich Dank eines Users in der Google+ JavaScript Community gekommen. Ich hatte dort meine jsPerf-Ergebnisse vorgestellt. Einige hatten meiner ursprünglichen Version auch noch einiges hinzugefügt, sodass wir mittlerweile bei der achten Revision sind. Die Revision 3 war die von mir vorgestellte Revision und hat die meisten Testergebnisse, weshalb sie auf jeden Fall auch beachtet werden sollte. Ansonsten empfehle ich Revision 8, weil dort alle Anmerkungen und Erweiterungen der Community enthalten sind*:

http://jsperf.com/jquery-cache-no-cache/8

Die Ergebnisse, die dort zu sehen sind, sind es, welche mich zu der Aussage des zweiten Punktes kommen lassen. Selbst wenn man jQuery.css() benutzt, hat man noch weit weniger Performance – verglichen mit vanilla JS. Vor allem für den mobilen Bereich ist das sicher sehr interessant, ist dort doch die Performance dringend benötigt und man muss sehr selten auf den IE Rücksicht nehmen.

*** Update am 12.07.2014
Habe nun noch eine Version erstellt, in der einige Fehler der Vorgänger behoben wurden und ein paar neue Vergleiche hinzugekommen sind. Außerdem habe ich auf die aktuelle jQuery Version (2.x) umgestellt. Trotz allem ist jQuery weiterhin in diesem Vergleich um ein vielfaches langsamer:

http://jsperf.com/jquery-cache-no-cache/13

One thought on “Ein Nachteil von jQuery? Performance!

  1. Pingback: (HTML5 Canvas-)Bilder hochauflösend (Retina) darstellen | bennybennet

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>