Website UX Performance Toolkit / Plain Tweaks

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

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

simple Javascript HTML5 jQuery Form Validation

Formular Validierung hat noch nie Spaß gemacht und meistens beschränke ich die Validierung auf die Server-Seite. Doch bevor man ein Formular per AJAX abschicken will, ist es immer besser auch auf der Client-Seite die Eingaben zu validieren und dem Benutzer ggf. noch darauf hinzuweisen dass nicht alle notwendigen Informationen eingegeben sind, das erspart Frustration.

HTML5 ist dabei eine große Hilfe. Mit dem erweiterten Formularfeld Attribut type, sowie dem pattern und required Attribut übernimmt der Browser die Validierung. Per Javascript reicht dann die Suche nach Formular Elementen die required sind aber einen invalid Status haben:

var $form = $("#emailForm");
if ($form.find(":required:invalid").length === 0) {
  // alle Pflichtfelder validieren
 
} else {
  // Nicht alle Pflichtfelder validieren
}

Über CSS kann man die Formularfelder auch noch stylen je nachdem ob sie valid oder invalid sind. Wer noch „Nicht-HTML5-Browser“ unterstützten muss, könnte per Modernizr((Modernizr  – the feature detection library for HTML5/CSS3)) eine Weiche schalten und ein Javascript Plugin zur Valdierung nutzen, oder per Progressive Enhancement((Progressive Enhancement – Wikipedia Artikel)) das Formular einfach über die serverseitige Parameter Validierung überprüfen und ausgeben lassen – um die serverseitige Validierung kommt man auch mit der jQuery Zeile von oben nicht drumherum. Frontend Formular Validierung ist und bleibt ein UX-Enrichment((UX Enrichment – Die Bereicherung des Benutzer Erlebnis)).

Einstieg in Sass und Compass bei eigenen Projekten

Im vierten Quartal 2011 bin ich auf Sass bzw. Scss aufmerksam geworden, doch den ersten Einsatz dieser Technik habe ich dann bis Ende 2012 verschleppt.

Die Möglichkeiten die Sass bietet hatten mich damals schon direkt überzeugt, aber die Sorge, dass man in einem echten Kundenprojekt sich mit den neuen Möglichkeiten verzettelt waren auch berechtigt. Beim ersten Projekt hatten nicht alle Entwickler die gleiche Wissensbasis zu Sass und dadurch kam es häufig dazu dass die Kompilierung nicht überall gleich gut funktionierte, oder dass Änderungen direkt in die css-Datei geschrieben wurden und dann wieder verloren gingen, bzw. dank SVN mühsam in die Sass Datei übertragen werden konnten.

Beim zweiten Projekt fühlte man sich soweit, dass ein CSS Framework als Ruby Gem genutzt wurde und auch hier war die Gefahr des Vergaloppieren groß.

Mittlerweile schreibe ich nur noch Sass und habe Wege gefunden und beschreibe im folgenden Wege wie man die Technologie einem ganzen Team mit gemischten Hintergrund (Designer, Markup Artist, Entwickler) zugänglich machen kann.

 

Schritt 1: Einrichtung von Sass und Compass auf allen Arbeitsplätzen

Auf der Sass Installationsseite und der Compass Seite wird die Installation für alle gängigen Betriebssysteme (Win, Mac, Linux) erklärt. Vom Einsatz eines GUI-Tool rate ich jedem ab, mit einer geschickten Konfiguration kann man seinen gewohnten Arbeitsablauf (IDE/Editor usw.) beibehalten und ein kleines Terminal Fenster erledigt alle Sass-Aufgaben.

Am Ende von Schritt 1 muss auf jedem Arbeitsplatz der Befehl compass watch ausführbar sein, auch auf dem Entwicklungssystem und dem Produktivsystem.

 

Schritt 2: Konfiguration des Projektes

Das Code Repository muss so angelegt sein, dass jedes Teammitglied, nach einem Checkout im Wurzelverzeichnis des Projektes den Befehl compass watch aufrufen kann und ab diesem Zeitpunkt sich wieder der Sass Entwicklung widmen kann.

Dazu gesellt sich die config.rb an die Seite des Entwicklers, eine simple Textdatei im Wurzelverzeichnis in der ein paar Variablen festgelegt werden:

http_path = "/"
css_dir = "css" # Verzeichnis in dem nachher das CSS laden soll: zum Beispiel "webroot/css"
sass_dir = "sass" # Verzeichnis in dem die scss Dateien liegen
images_dir = "img"
javascripts_dir = "js"

output_style = (environment == :production) ? :compressed : :expanded # Steuerung über das Format des erzeugten CSS

Die letzte Zeile hat es in sich, mit folgenden compass watch Befehlen, kann hier direkt minifiziertes CSS für das Produktivsystem oder lesbares CSS für die Entwicklung erzeugt werden:

compass watch -e production --force // erzeugt miniziertes CSS
compass watch // bringt menschenlesbares und debugbares CSS zu Tage

Schritt 3: Arbeiten mit Sass

Nachdem diese Hürde genommen ist kann die Arbeit mit Sass durch starten. Die grundlegende Technik (Schachteln von CSS Regeln) muss jedem Teammitglied erklärt werden sowie die Funktion der &– und @extend Funktion. Eine Sass Schulung wie sie zum Beispiel bei Code School angeboten wird kann hier hilfreich sein. Wie bei jeder neuen Technik unterscheiden sich die Lernkurven innerhalb eines Teams und daher sollte man schauen dass die Technik langsam Einzug hält und nicht zu abgefahrene Nutzung von @mixins und @functions Mitglieder ausschließt.

Ein nettes Gimmick während der Entwicklung bietet auch die // und /* ... */ Kommentarfunktionen in Sass. Der // Kommentar, weist den Compiler an, diese Zeile zu ignorieren, während der /* ... */ Kommentar in der kompilierten Datei erscheint.

Tipp: Comeback der @import Regel

Jeder Web Performance Optimierer hasst die @import Regel die immer noch in CSS Dateien vorkommt. Doch bei Sass feiert diese Regel zurecht ein Comeback. Der Compiler von Sass erkennt die @import Aufrufe und kopiert daraufhin die genannte Datei in die zu kompilierende Scss Datei, bevor er sie dann komplett kompiliert.

Dadurch kann ein Projekt beliebig viele verschiedene Sass Dateien benutzen, die in der Ausspielung alle in einer CSS Datei zusammengefasst sind. Wenn das ganze noch minifiziert ist, ist ein großer Schritt in der WPO einfach so erledigt.

// Beispiel app.scss
@import "video";
@import "bootstrap";

// ab hier folgen eigene Style Definitionen
.. {
 &:...{

 }
 .. {

 }
}

Mit diesen Angaben sucht der Compiler nach folgenden Dateien: video.scss, _video.scss, bootstrap.scss, _bootstrap.scss und bindet diese im Erfolgsfall ein. Der Unterstrich im Dateinamen weist den Compiler außerdem noch dazu an, die Datei nur einzubetten und nicht selbst zu kompilieren. Ohne Unterstrich enstehen im /css/ Verzeichnis auch die Dateien video.css und bootstrap.css.

Tipp: Einbindung von Frameworks per Sass

Die Technik habe ich im Abschnitt hier drüber erklärt, aber in der Einleitung habe ich erwähnt dass man viele Dinge auch als Ruby Gem in ein Projekt einbinden kann.

Das haben wir bei einem Projekt getan und Foundation 4 eingebunden. Ungeschickt dabei stellte sich heraus, dass alle Teammitglieder auch das Foundation Gem installiert haben mussten und Gem Versionen die nicht der initial Version (mit der das Projekt gestartet wurde) entsprachen, erzeugten fehlerhaftes CSS.

Dank dieser Erfahrung nutze ich mittlerweile immer die Anpassungsfunktion auf der Website eines Framework Anbieters und binde diese Dateien dann fest in das Projekt ein. Ein Update oder eine Erweiterung des Frameworks kann dann immer über diesen Weg erfolgen, was auf den ersten Blick etwas umständlich erscheint, aber dadurch ist es allen Teammitglieder immer möglich auf ihren Geräten das Projekt selbst zu erzeugen und das ist eine Menge wert.

Firefox2 & Firefox3, „em“ size does matter!

Beim letzen Posting dachte ich noch dass dem Problem des unterschiedlichen Rechnens von relativen Größenangaben nur mit CSS Hacks beizukommen ist. Da habe ich gestern eine neue Erfahrung gemacht: Nachkommastellen!

Bei pixelgenauen Umsetzungen von Webseiten steht man vor dem Problem das der FF2 und IE6 bei festen Pixelangaben sich weigern den Seiteninhalt richtig zu vergrößern. Es wird einfach nur der Text vergrößert, Design und Layout wachsen nicht mit. Daher gibt man alle Größen relativ zur eingestellten Schriftgröße vom Browser an und schwupps, zoomen ff2 und ie6 wieder alles mit.

Nun hatte ich per CSS dem body eine Schriftgröße von 0.66em gegeben und darauf alle weiteren Größenangaben basiert. Im ieX und FF3 sah auch alles gleich aus, der FF2 und die Webkits verrechneten sich aber leider. So war die 780 Pixel breite Inhaltsbox im FF2 und den Webkits immer etwas zu schmal! Also hatte ich erst mit CSS Hacks für diese Browser die Größe angepasst, aber beim probieren dann auch einfach mal 0.661em als Schriftgröße genommen und auf einmal rechnen alle Browser wieder richtig.

Wer hätte das gedacht?