Fronted-Performance optimieren in Chrome – Like a Boss

Nicht nur Frontend Entwickler kennen es: Man freut sich, dass die hollywoodreifen Animationen auf der Webseite oder im User Interface endlich funktionieren. Ein raffinierter Parallax-Effekt verleiht dem Ganzen dann noch den letzten Schliff. Das Problem: Es ruckelt und hakt an allen Enden, die Lüfter seines nagelneuen Rechners fangen an zu drehen. Was tun?
Zum Glück bieten die Chrome-Developer Tools einige hilfreiche Werkzeuge an, um die Performancefresser zu identifizieren. Diese geben nicht nur einen guten Überblick über Performance-Engpässe sondern dokumentieren außerdem die Bildwiederholrate, CPU-Auslastung und das Asset-Handling.

Wo finde ich diese Tools nun?

Wer die Chrome Developer-Tools kennt, ist möglicherweise schon mal über das Timeline Tab gestolpert. Öffnet man die Ansicht das erste Mal, ist es nicht ganz unwahrscheinlich, dass man von der hohen Informationsdichte erschlagen ist. Daher soll dieser Artikel als eine Art Entry-Point für den Einstieg sein. Denn es lohnt sich.
Ist das Timeline-Tab bereits geöffnet und die Seite wird neu geladen, werden die Performance-Daten des initialen Seitenaufrufes bis zum fertigen Rendern der Seite automatisch aufgezeichnet.
Danach kann man einzelne Aufzeichnungen starten, um z.B. die Performance einzelner Interaktionen auf der Seite untersuchen zu können. Dabei sollte beachtet werden: Je kürzer die Aufnahme und je weniger Aktionen aufgezeichnet werden, desto einfacher ist die Analyse.

Überblick

Der Einstieg: Ein kurzer Überblick über die Oberfläche.
Bildschirmfoto 2016-03-30 um 13.07.21

A) Bedienelemente

Die beiden linken Symbole dienen zum Starten und Stoppen der Aufzeichnung. Alternativ kann hierfür das Tastenkürzel cmd + E / Strg + E verwendet werden. Mit den Checkboxen können zusätzliche Informationen an/abgewählt werden, die dann entsprechend mit aufgezeichnet werden.

B) Überblick

Diese Ansicht bietet eine Übersicht über den Verlauf der Seiten-Performance. Sie dient außerdem als Navigation, um den aktuellen Bereich auszuwählen.

C) Flame-Chart

Hier werden die einzelnen Ereignisse und deren Dauer als horizontale Balken visualisiert. Parallele Ereignisse werden nach unten gestapelt. Der findige Beobachter erkennt hier drei unterschiedliche gefärbte vertikale gestrichelte Linien: die blaue Line stellt den DOMContentLoaded-Event dar. Die grüne Linie markiert den ersten Paint-Event und die rote den load Event.

D) Details

Ist kein Ereignis angewählt werden hier die Statistiken für  Zeitraum aufgeführt, der in der Übersichtsansicht ausgewählt ist. Um die Anzeige auf ein Ereignis zu begrenzen, kann im Flame-Chart ein Ereignis ausgewählt werden.
In der Überblicksansicht kann man die Auswahl der Ereignisse eingrenzen in dem man die Regler verschiebt. Die Visualisierungen im Flame-Chart und dem Detailbereich passen sich entsprechend an und beziehen sich nur auf den ausgewählten Bereich.
2016-03-30 16_25_29

Exkurs: Die typische Rendering-Pipeline

In der Regel gibt es fünf verschiedene Schritte bei der Frame-Berechnung, die bei der Entwicklung zu beachten sind. Über diese Bereiche hat  der Entwickler die größte Kontrolle.

Javascript

Typischerweise werden Scriptaufrufe verwendet um Werte zu ändern, die dann in Änderungen der Darstellung resultieren. Das kann z.B. die animate Funktion in jQuery sein oder das Hinzufügen von DOM-Elementen. Diese Darstellungsänderungen werden nicht ausschließlich durch Javascript ausgelöst. Es können auch CSS-Animationen, Transistions, o.ä. dafür verantwortlich sein.

Style Calculations

In diesem Prozess findet der Browser heraus, welche CSS-Regeln anhand der Style-Angaben für welche Elemente angewandt werden müssen.

Layout

Darauf folgt in der üblicherweise die Berechnung der Positionen der jeweiligen Elemente und wie viel Platz diese benötigen. Das Layout-Modell des Webs ist so konzipiert, dass gewisse Abhängigkeiten der Elemente untereinander herrschen. Verändert ein Element, welches mit float positioniert ist seine Breite, beeinflusst es die Position und Größe der umliegenden Elemente.

Paint

Im Painting-Prozess werden die Pixel der einzelnen Elemente berechnet. Es berücksichtigt Eigenschaften wie Text, Farben, Bilder, Rahmen. Die Berechnung findet auf verschiedenen Ebenen (Layers) statt.

Composite

Nachdem Painting-Prozess sind die einzelnen Komponenten (Layers) der Seite bereits berechnet. Beim Compositing werden diese Komponenten dann übereinander gelegt. Besonders entscheidend ist dies bei überlappenden Elementen.

1. JS/CSS >Style > Layout > Paint > Composite

Pasted Graphic
Wenn eine Eigenschaft eines Elements verändert wird, welche dessen Abmessungen oder Position verändert (z.B. height, width, top, left, o.ä, muss der Browser alle oder zumindest alle umliegenden Elemente neu berechnen und zusammengesetzt werden (Layout > Paint > Composite)

2. JS/CSS > Style > Paint > Composite

Pasted Graphic 1

Werden nur Paint-only Eigenschaften geändert (background-image, color, box-shadow), kann der Browser den Layout-Prozess überspringen.

3. JS/CSS > Style > Composite

Pasted Graphic 2

Wenn eine Eigenschaft verändert wird, bei denen der Layout und Painting-Prozess übersprungen werden kann, überspringt der Browser diese Schritte und springt direkt in den Compositiing-Prozess. Darunter fallen z.B. transform oder opacity.
Vor allem für performance-kritische Fälle, z.B. für Animationen oder bei Scroll-Events, bei denen die entsprechenden Funktionen in der Regel besonders oft aufgerufen werden, ist diese Variante besonders erstrebenswert.

Repaintbereiche auf der Seite visualisieren

Im DevTools Hauptmenü gibt es einen Eintrag mit der Bezeichnung More Tools nennt. Wählt man hier die Rendering Settings aus, erhält man weitere Funktionen. Ist die zusätzliche Leiste am unteren Bildschirmrand nicht sichtbar, kann man diese mit der Esc-Taste wieder erscheinen lassen.
Im Teilfenster am unteren Bildschirmrand befindet sich dann eine Check-Box mit dem Titel Enable paint flashing.

rendering-settings

Über das DevTools Hauptmenü können weitere Tools eingeblendet werden.


Aktiviert man diese werden auf der Seite Bereiche markiert, bei denen Painting-Events auftreten. So erhält man in Echtzeit einen guten Überblick, welche Bereiche für mögliche Performance-Engpässe sorgen.
2016-03-30 22_26_11
————
Es gibt einen Talk von Paul Irish, der mehrere Anwendungsbeispiele veranschaulicht.

Florian Strohmaier
Florian Strohmaier
UX Designer

Mit seinen Spezialgebieten UI-Konzeption, Prototyping und Frontendentwicklung unterstützt Florian das Dev-Team bei NETWAYS. Trotz seines Design-Backgrounds fühlt er sich auch in der Technik zuhause. Gerade die Kombination aus beidem hat für ihn einen besonderen Reiz.

Weekly Snap: OpenLDAP with ACL, NodeJS & Dev Tools Galore

23 – 27 January was filled with developer tools, in particular NodeJS as well as OpenLDAP, with a sys admin email tip to boot.
Martin offered a quick troubleshoot for the Mac error “Index Out Of Range Exception” that popped up as he installed SP2 on the company Exchange 2010.
Then in a development tag team, Angsar briefly reviewed the top tools for software developers with a good dose of scepticism, while Eric went into more depth on one of the better ones – NodeJS. With a quick guide to installation creating a simple .png, he gave the server side Java Script framework the thumbs up.
Finishing off the week, Philipp continued on his OpenLDAP roll, this time in working with ACL on 2.4.x versions.

Beliebte Software-Entwickler-Werkzeuge bei Startup-Unternehmen

Developer Tools Statistik (Quelle: bestvendor.com)Ursprünglich fand ich diese Umfrage vom Thema her interessant und einen kurzen Blick wert. Mehr wollte ich gar nicht schreiben. Eigentlich.
Wir liegen „voll im Trend“
Allerdings war ich bislang der Ansicht, hier bei netways einem Alternativ-Open-Source-Underground-Software-Usage-Unternehmen zu dienen (mit 1337 – |-|4><><0r-Ansätzen was Pizzabestellungen betrifft). Nun muss ich mein Weltbild nolens volens korrigieren – die Ergebnisse entlarven schonungslos unseren Hang zum Mainstream: Mysql, Selenium IDE, Netbeans, Redmine, Vim, Git … puh.
Ich empfehle mich
Unsinn mal beiseite geschoben, ist es doch spannend, was andere Leute in der Branche einsetzen und schaden kann es nicht, das ein oder andere Tool für sich zu entdecken. Den Gedanken greifen die Statistiker dann auch brav auf und schlagen sechs „Hidden gems and trending apps“ vor, die man unbedingt probieren muss. Warum auch immer.

  • Nun spricht nichts per se dagegen, New Relic vorzuschlagen. Ich habe es bislang nicht ausprobiert, es sieht viel schmucker aus als etwa pinba oder xymon und bietet, wenn ich es korrekt erfasst habe, umfangreichere Funktionen. Vielleicht hätte man das erwähnen können. Und dass es etwas (und was) es kostet (ausgenommen es stellt einem etwa ein Hoster zur Verfügung).
  • Ähnlich verhält es sich mit dem Texteditor Sublime Text, den man bei regelmäßiger Nutzung (so zu lesen auf der Homepage) bezahlen sollte, aber immerhin kann man „mächtiger als Textmate und einfacher zu bedienen als vim oder Emacs“ als wertende Aussage zählen lassen.
  • Ist GitX (L) tatsächlich ein Geheimtipp für Mac-User? Kann ich nicht beurteilen. „Great“ und „GUI“ lässt zumindest vollkommen offen, warum man gerade die L-Variante wählen sollte.
  • WorkFlowy Listen Tool ScreenshotA lightweight way to make useful lists“ beschreibt WorkFlowy schon beinahe ausreichend. Zusätzlich kann man die Listen freigeben. Aber entweder ist man dort bestrebt, das Gros der Funktionen vor mir geheim zu halten. Oder „Project -“, „Task-Managing“ und vor allem „Bug tracking“ sind schon verdammt „lightweight“. „Create shopping lists for your smart-phone online“ wenn man böswillig ist.
  • Zu guter Letzt (ja, nix zu node.js, bin zu faul und unwissend) – ein Sony-Kopfhörer? „Bad boys“, die den labernden Chef ausblenden? Anarchisch. Und innovativ. Absoluter Geheimtipp für Entwickler. Warum gerade dieses Modell? Etwa aufgrund der geschlossenen Bauart mit guter Außendämpfung, den zig ordentlichen Bewertungen durch diverse Fachmagazine, oder persönlichem Geschmack des Schreiberlings? Man weiß es nicht. Eventuell hat die Dispo gerade Sony an Land gezogen. Falls ja: sehr galant eingeflochten, die Werbung. Respekt.

Hübsch sinnfrei
Käme man nun auf die Idee, noch die „Schlussfolgerungen“ aus den Zahlen zu studieren, würde man obendrein durch bessere Kalendersprüche belästigt. Ich spare mir an dieser Stelle, diese Ergüsse aufzudröseln.
Ich konstatiere: Thematisch und optisch ansprechende Statistik wie aus dem Bilderbuch, bestens geeignet für unterschwelliges Product-Placement. Egal. Ich für meinen Teil empfinde jedenfalls 55,8% der Farben als angenehm (Flächenbedeckung, anteilig) – zumindest für ein Diagramm. Gesetzt den Fall, man sähe die graue Schraffur als unifarben an, was 33,3% der hier momentan Anwesenden in durchschnittlich 173,8% größerer oder gleicher Entfernung vor dem Monitor sitzend, als der durchschnittliche Golf-GTI-Fahrer mit Kappe nach hinten (66,9% der männlichen Umfrage-Aspiranten) am Duftbaum (89,3% der befragten Rückspiegel, Vanille-Cocos) vorbei schielt (also die 34,7% mit Hornhautdeformation, Brillenkorrekturfähig) am besten gelingt.