Tag Archives: Performance

Quick-Hints #10

Yay Jubiläum

#perfmatters

#perfmatters ist ein beliebtes Thema derzeit auf meinem Blog. Hier hinzufügen möchte ich noch ein paar Slides von Addy Osmani mit Case-Studies und weiterem Hintergrundwissen zur Erhöhung der Rendering-Performance im Browser. Es kommt aber nicht nur auf die Geschwindigkeit beim Rendering an, auch der Weg vom Server zum Browser muss bedacht werden. Google Mitarbeiter Ilya Grigorik hat einiges tief gehendes Wissen zu “High Performance Browser Networking” in einer Präsentation verpackt und kann dir so auch in diesem Gebiet zu besserer Performance deiner WebApp verhelfen. Vor allen bei mobilen Webseiten ist die Latency ein großes Problem. Ein CDN kann hier zumindest ein wenig Milderung verschaffen.

Wenn du zukünftig die Veränderungen deiner Performanceoptimierung tracken willst, kannst du dies mit Google Analytics machen. Am besten fügst du hierfür vor:

Continue reading

Quick-Hints #9

JavaScript Tutorials

Promise Cartoon by Wilf Eddings

Promise Cartoon by Wilf Eddings / @iamwilf

Wie so häufig in den Quick-Hints; ein paar JavaScript Tutorials. Im letzten Quick-Hints hatte ich schon ein CheatSheet zum Thema Promises verlinkt, jetzt hab ich noch etwas gefunden, was ich unbedingt noch hinzufügen möchte: Ein Cartoon, der sehr anschaulich Promises erklärt.

Ich gehöre nicht zu den riesen Fans von AngularJS, aber in Verbindung mit der detaillierten Erklärung, wie man ChromeApps entwickelt, ist ein dabei ein gutes “ChromeApp mit AngularJS entwickeln” Tutorial herausgekommen.

StartUp-Doku

Jetzt noch zwei Dokumentationen zum Thema StartUp / Firmengründung. Bei startingupinamerica.com ist eine Doku zu finden, in der USA-Einwanderer von Ihrer Business-Story berichten und die Vorteile für ihr neues Land verdeutlichen. Umgekehrt werden hier auch die Vorteile eines StartUps in Amerika gegenüber anderen Ländern aufgezeigt.

Das folgende YouTube-Video ist die Hintergrundgeschichte zu Minecraft. Es erzählt ein wenig über die Entstehung von Mojang, der Firma hinter Minecraft und rund um den Entwickler notch.

#perfmatters

Wenn du als PHP- oder Java-Entwickler aus der (standardmäßig) blockierend Input/Output Welt kommst, solltest du dich bei JavaScript (nodeJS) relativ schnell mit dem Thema non-blocking IO beschäftigen und dazu hier der passende (englische) Einstieg: Zen of non-blocking IO. Als Bonus gibt es dort auch eine schöne Übersicht, was einen WebServer ausmacht.

Um die Performance seiner Webanwendungen verbessern zu können, ist es essentiell, dass du verstehst, wie ein Browser arbeitet und funktioniert. Genauer, wie stellt der Browser deinen HTML und CSS Code dar. Auf Youtube habe ich hierzu ein nettes Einstiegsvideo “How Browser Works” gefunden, vier Minuten und die Basics sind klar. Wenn du über diese Basics hinaus bist, musst du UNBEDINGT dieses Experten-Video sehen. 51 Minuten geballtes Wissen über Rendering-Performance und wie diese in deiner WebApp gesteigert werden kann. Den Speaker anschließend noch folgen: Google Mitarbeiter Paul Lewis auf Twitter.

Quick-Hints #7

Als Webentwickler muss man sein Produkt ständig in mehreren Browsern und am besten noch in mehreren Umgebungen testen. Hier eine schöne Möglichkeit: http://blog.mattbailey.co/post/50337824984/grunt-synchronised-testing-between-browsers-devices

Mit SVG-Grafiken in Webseiten kann man viele schöne Dinge anstellen. Zum Beispiel ein Logo / eine Schrift animieren: http://jakearchibald.com/2013/animated-line-drawing-svg/

Ein paar nette CSS3 Effekte für Menüs / Links sind unter folgendem Link zu finden: http://tympanus.net/Development/CreativeLinkEffects/. Um diese auch in vielen Browsern nutzen zu können, empfiehlt sich der Einsatz eines Autoprefixers, zum Beispiel: http://css-tricks.com/autoprefixer/

Für Fälle, in denen man das letzte Element eines Arrays möchte, gibt es viele Möglichkeiten. Wenn man wert auf die Performance legt sollte man ganz klar “array[array.length – 1]; benutzen. Siehe: http://jsperf.com/get-last-item-from-array/10

Quick-Hints #5

  1. Für umfangreiches debuggen von JavaScript Client- und Server-Code: https://trace.gl/
  2. Mehr Performance im Siteflow dank Prefetch dank HTML5: Link
  3. Ein Blogsystem, kein CM-System; Ghost will die Alternative zu WordPress für Blogger werden und hat dafür ausreichend Kapital per Kickstarter eingesammelt.
  4. Schon heute in ES6 entwickeln und als ES5 ausliefern, Addy Osmani hat beschrieben wie es geht. Dank Grunt.js kann dies völlig automatisiert geschehen.
  5. two.js ist eine API für 2D-Grafiken im Browser unabhängig vom Context.
  6. Noch mehr Performance für WebApps gibt es dank den Tipps von Mozilla für Apps auf Firefox OS in JavaScript.

 

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