Kategorie: Frontend

Website UX Performance Toolkit / Plain Tweaks

Raoul Kramer Schreibe einen Kommentar

UX Performance betrifft ein gesamtes Projekt – vom HTML, CSS und Javascript über den Browser bis zum Besucher der Webseite. Neben der schnellen Auslieferung einer Website (HTTP2, Komprimierung, Minifizierung, Above The Fold / Critical CSS, Caching Header und und und) steht und fällt die Benutzer Erfahrung (das UX – User Experience), sozusagen das Gefühl wenn man die Seite nutzt, mit der Art und Weise wie flüssig ein Browser eine Seite dauerhaft darstellen kann.

Optimierungen an der gefühlten Performance sind im Nachhinein immer schwieriger, als wenn man direkt bei der Implementierung alle Stellschrauben im Blick hat. Die folgende Liste gibt ein paar Anhaltspunkte auf die man achten kann, während der Umsetzung eines Webprojektes.

Die Liste geht bis auf wenige Ausnahmen nicht auf Bibliotheken oder Frameworks ein, sondern auf Frontend Plain-Tweaks, also ein Teil der Werkzeugkiste die man im Hinterkopf haben sollte, ohne npm, bower und co.

TL;DR

  1. Animationen und Übergänge auf einer Webseite mit CSS3 animate oder transition realisieren
  2. absolute und fixed Elemente per transform: translate() animieren, nicht per top, left, right, bottom
  3. Bei Änderungen der Anzeige Art von Elementen (von absolute zu fixed etc) den frei werdenden Platz vorher schon mit padding reservieren
  4. Im Javascript alle DOM-Queries cachen
  5. Javascript Handler delegieren
  6. DOM Elemente selten löschen / hinzufügen
  7. Idealerweise fastdom für DOM Manipulationen benutzen
  8. In teuren Listener wie scroll, mousemove oder resize wenig direkt auf den DOM zugreifen
  9. Teure Listener verlagern
  10. Resize Listener mit absoluter Vorsicht benutzen
  11. will-change oder contains einsetzen
  12. tbc.

Weiterlesen

critical css gulp workflow für eine bessere Benutzer Erfahrung

Raoul Kramer Schreibe einen Kommentar

Wenn es um den Kritischen Rendering Pfad geht, ist das Ziel, dass insbesondere mobile Browser sehr schnell mit dem Rendering der Website anfangen können. Dem Besucher kommt die Reaktion der Website dann schneller vor, als wenn der Browser erst das gesamte CSS lädt und danach die Website rendert. Gerade bei Verbindungen jenseits von LTE, ist ein Render blockender Abruf von CSS, Webfonts, JS ein wahrer Dämpfer des Seitenaufbaus.

Irgendwann im Laufe der Zeit stellte das Web zum Beispiel fest, dass Javascript gar nicht im <head> geladen werden muss, sondern es völlig ausreicht das meiste Javascript vor dem </body> einzubinden. Bis dahin darf der Browser den DOM und das CSSOM erstellen.

Dank Google Pagespeed oder dem schickeren TestMySite rückt jetzt das CSSOM in den Fokus des Rendering.

Weiterlesen

Fullscreen Flyout Menüs / Lightbox und die Scrollbar Breite

Raoul Kramer Schreibe einen Kommentar

Bei Flyouts oder Lightboxen die das Page Scrollen unterbinden

body.overlay {overflow: hidden;}

tritt im Desktop häufig das Problem auf, dass durch die verschwindene Scrollbar alle Inhalte der Seite etwas nach rechts rutschen.

TL;DR

Mit body { width: 100vw; overflow-x: hidden;} nimmt die Seite auch den Platz hinter der Scrollbar ein, während sie bei body { width: 100%; } nur vom linken Rand bis zur Scrollbar dimensioniert ist.

Das liegt daran, dass die Scrollbar z.B. 15px der Seite einnimmt und diese 15px dann freigibt.

Auffällig wird dieses zum Beispiel bei Seiten die ihren Inhalt ab einer gewissen Browserbreite horizontal zentrieren und der Menü Button unter der Maus verrutscht.

Nun hatte ich ein Javascript gefunden, welches mir die Breite der Scrollbar ausgibt, im Linux Chromium die oben genannten 15px, auf Windows Chrome 17px – ungerade Zahlen, im Edge 12px…

Das Javascript im Beitragsbild ist zum großen Teil die Lösung von David Walsh.

Weiterlesen

Javascript und der </body>-Tag

Raoul Kramer Schreibe einen Kommentar

„Kaum macht man es richtig, schon funktioniert es.“

Ein simples Sprichwort – doch kann man das Ganze bei Javascript umdrehen:

„Es funktioniert, also ist es richtig?“

Womit ich beim Thema wäre :-)

Paul Lewis und Jake Archibald haben mich mit ihrem Videoblog HTTP 203 zum Grübeln gebracht. Als erfahrene JS Entwickler hängen wir unseren Code erst vor dem </body>-Tag ein und führen ihn frühestens im document.ready Event aus…

Und um ihr Beispiel (von mir frei übersetzt) zu zitieren:

„Das ist so, als würde man sicher stellen dass die Straßen bis 8:45h frei sind und dann fahren alle auf einmal los“ (HTTP 203: Performance Matters ~30s)

Weiterlesen

svg 2 png grunt workflow

Raoul Kramer Schreibe einen Kommentar

Vektorgrafiken sind toll. Man kann sie unendlich skalieren und der Detailgrad bleibt immer gleich gut. Auf HiDPI((HiDPI – High DPI Bildschirme, sind Bildschirme deren Device Pixel Ratio > 1 ist, also ein berechnetes Pixel von mehreren dargestellt wird und daher ein feineres Bild entsteht)) Displays sind sie die beste Lösung wenn es darum geht einfache Grafiken darzustellen. Photorealismus ist mit Vektorgrafiken allerdings nicht effizient zu erreichen. Hier ist weiterhin progressive JPEG oder ähnliches die beste Wahl.

Auch die Renderperformance sollte beachtet werden. In einem Projekt im Sommer 2013 habe ich am Ende alle SVGs wieder rausgenommen, da in diesem Artikel((Data URI Performance: Don’t Blame it on Base64 | Mobify)) die Rendergeschwindigkeit von SVGs auf mobilen Geräten unter dem Punkt „Secondary Result: SVGs are Surprisingly Slow!“ generell in Frage gestellt wurde. Und damals ging es um die Renderperformance… Weiterlesen

jQuery vs Vanilla JS featuring JSLint = good practice

Raoul Kramer 1 Kommentar

Javascript Frameworks wie jQuery((jQuery – „write less, do more“)) erleichtern jedem Entwickler die Arbeit, aber können dem Browser mehr Arbeit bescheren.

JSLint((JSLint – The JavaScript Code Quality Tool)) ist in der JavaScript Entwicklung ein idealer Partner, doch leider ist jQuery für JSLint nicht ganz durchschaubar und so können sich schnell wieder „bad practices“ einschleichen.

Zu diesem Beitrag habe ich mir ein Testdokument erstellt, welches aus einem simplen html Gerüst besteht und als Inhalt einen <ul> mit 10.000 <li> Elementen besteht, welche jeweils ein Click Event bekommen um eine Klasse zu wechseln. Das erste Beispiel nutzt jQuery 1.7.2, alle weiteren jQuery 1.11.2. UPDATE: Nun habe ich auch eine Vanilla JS delegated Methode durchgemessen. UPDATE 2: Die kompletten Testdateien habe ich nun bei bitbucket hochgeladen: djpogo/vanilla-jquery-listener.

Bei jQuery ist es durchaus gängig einen Listener Funktion als anonyme Funktion zu implementieren. Das sieht dann so aus:

// jQuery < = 1.7.x 
$(".viewportChanger").click(function () { $(this).toggleClass("show"); });

// jQuery 1.11.2 ohne Delegation
$(".viewportChanger").on("click", function () { $(this).toggleClass("show"); });

// jQuery 1.11.2 mit Delegation
$(".viewport").on("click", ".viewportChanger", function () { $(this).toggleClass("show"); });

Weiterlesen

Nachtrag: Mobile Web Performance Optimierung

Raoul Kramer Schreibe einen Kommentar

Vor kurzem hatte ich das Chromium Device Mode Tool((Chromium Device Mode – Ähnlich wie die Firefox Responsive Design View bietet Chromium (oder Google Chrome) seit Version 38 ein leistungsfähigeres Werkzeug an. Neben mehr Geräteprofilen und der Auswertung des mobile viewport gibt es ein Killer Feature, nämlich das die Simulation von Netzwerkverbindungen wie WiFi, 3G,EDGE,GPRS einfach möglich ist.)) wieder entdeckt und ausführlich getestet((mobile web performance optimization mit chromium responsive design view)).

Die Einsparung war mit kleinen Handgriffen direkt enorm, aber ein paar Ideen hatte ich noch, denen ich in diesem Artikel nachgehen werde.

Als Ausblick sei genannt Grunt((Grunt – Der Javascript Task Runner)), SVG((SVG – Scalable Vector Graphic; Ein verlustfrei skalierbares Grafikformat)), Minifizierung((Minifizierung – Entfernen aller nicht notwendigen Zeichen in einer Javascript- oder CSS Datei)), Uglifizierung((Uglifizierung – Ersetzung von Variablen- und Funktionsnamen um einerseits die Datei noch kleiner zu bekommen, anderseits die Lesbarkeit zu erschweren)) und SVG-Sprites((Sprites – im allgemeinen fasst man mit Sprites mehrere Grafiken in einer Datei zusammen, damit diese nur ein mal geladen werden muss und somit den Seitenaufbau beschleunigt)). Weiterlesen

Adobe Extract – cloud powered PSD2HTML

Raoul Kramer Schreibe einen Kommentar

Ein etablierter Workflow in der Web Industrie ist, dass ein Grafiker eine Website mit Photoshop konzipiert und der Frontend Entwickler diese dann zur Umsetzung bekommt.

In Zeiten des Responsive Web hat die pixelgenaue Umsetzung mittlerweile ihren Charme verloren. Viele Probleme die beim statischen Konzipieren in Photoshop entstehen, können bei frühzeitigem Schwenk auf den Browser schneller erkannt und eliminiert werden. Aber trotzdem kann es passieren, dass einen Frontend Entwickler ein PSD als Designvorlage erreicht. Unter Linux hatte man bis vor kurzem dann nur unzureichende Möglichkeiten mit diesem PSD sinnvoll zu arbeiten.

Weiterlesen

mobile Web Performance Optimization mit Chromiums 38 Responsive Design View

Raoul Kramer 2 Kommentare

Der Titel ist ein ziemlicher Buzzword Dump, hält aber was er verspricht.

TL;DR

Mit Hilfe der Responsive Design View im Chromium((Responsive Design Mode – Ein Werkzeug welches verschiedene Geräteprofile und Netzverbindungen simulieren kann)) 38, konnte ich schnell Flaschenhälse auf einer Seite erkennen und mit kleinen Handgriffen beheben.

Neben einer kleinen Theorie-Runde gibt es weiter unten die Messwerte vor und nach der Optimierung, Verbesserungen um 66% sind drin!

und los…

Bis gestern habe ich immer das Firefox Responsive Design View genutzt. Das äquivalente Tool im Chromium war mir bekannt, aber ich fand es nicht so intuitiv wie beim Firefox.

Der Ansatz im Firefox war einfach direkter, allerdings muss man als Anwender das Device Pixel Ratio((Device Pixel Ratio – Hierbei weicht die native Auflösung eines Displays, zum Beispiel Full HD (1920×1080), von der im Gerätebrowser verfügbaren um einen bestimmten Faktor ab)) Konzept verstanden haben und die meta name="viewport" Angabe nicht vergessen.
Weiterlesen