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

Meine mobile Webseite ist langsam…

Ich wollte eigentlich „Deine mobile Webseite ist langsam…“ schreiben, aber das wäre gemein und vielleicht sogar falsch – und so stimmt der Betreff immerhin.

Bisher habe ich mich immer auf die „Responsive Alles Könner Rahmenwerke“ verlassen wie zum Beispiel Foundation oder Bootstrap und während man damit eine Seite entwickelt sitzt man im Büro, zu Hause oder sonstwo und hat Kabel-LAN, Kabellos-LAN, LTE oder HSDPA am Smartphone und schaut sich immer über diese Breitbänder die eigene Arbeit an.

Es hallt noch durch die Räume dass man vor dem Start der Umsetzung gesagt hat „Man müsse auf niedrig sowie hoch aufgelöste Displays achten“ aber diese Aussage hat man falsch verstanden, oder falsch gemeint.

Weiterlesen

HTML5 Video als Flashfallback

Tja, das Web wäre soweit, aber die User noch nicht. Daher gibt es doch relativ oft die Anforderung einen bestehenden Flashplayer bei Geräten zu ersetzen die kein Flash installiert haben.

Dabei gibt es zwei Dinge zu beachten: Kann der Browser ohne Flash überhaupt HTML5 Video und liefert man die richtigen Codecs aus – sonst schaut der User ja auch wieder in die Röhre.

Wenn zum Beispiel ein IE8 kein Flash installiert hat und man einfach als Fallback den <video>-Tag eingebunden hat ist dem User nicht geholfen.

Weiterlesen

Find As You Type / Autocomplete im Eigenbau (jQuery & yii)

Wir sind uns wohl alle einig: Ein Textfeld auf der eigenen Homepage das nach jedem Buchstaben, der eingegeben worden ist, eine aktualisierte Ausgabe erzeugt ist schön!
Google nennt sowas „Google Instant“, wir nennen es jetzt mal „Finde beim tippen“-Funktion oder so.

Als Ausgangssituation nehmen wir an, wir haben eine Datenbank mit beliebigen Inhalt (zB Blog Beiträge) und nun soll mit einem Textfeld der Titel der Blogeinträge durchsucht werden. Weiterlesen

„lazy load“ vom facebook cdn

Obwohl Facebook ein CDN bietet, wartet man (der Browser) häufig lange auf Facebook Javascripts oder CSS Dateien… Manchmal bis zu 10 Sekunden oder länger und in dieser Zeit denkt der Seitenbesucher das die Seite „langsam“ ist, also langsam ausgeliefert wird.

Wenn wir Yahoos und Googles Seiten Optmierungen vollendet haben, haben wir zwar alle <script>-tags vor Ende des </body>-tags gesetzt, aber wenn Facebook nur langsam seine Daten ausliefert, dreht sich oben im Browser noch die Spinner Grafik und manchmal verzögern sich dadurch massiv weitere JavaScript Ausführungen.

Weiterlesen

jQuery && IE(6/7) && parsererror && utf8 && utf-8…

Heute hatte ich einen interessanten Fehler zu finden. Das Problem war ganz einfach, es sollte per ajax etwas nachgeladen werden. Genau genommen etwas validiert. Im Erfolgsfall kam die Antwort "1" ansonsten "0" zurück.

Und dann kam der IE6 und IE7 und gaben einen „parsererror“ aus. In Fiddler und Co konnte ich die ajax calls verfolgen und sehen das der richtige Wert zurückgeliefert wird, aber trotzdem wurde immer der „error“ Handler aufgerufen…

Weiterlesen

Die Internet Explorer Familie ist nicht immer so schlecht

Es ist nicht der 1. April und tatsächlich meine ich die Überschrift ernst.

Kürzlich musste ich viele vermeindliche IE-Familien-Fehler beheben und im Endeffekt feststellen, das der Fehler im MarkUp oder Javascript lag. Da hat die Sturheit der verschiedenen IE-Versionen besseres HTML und Javascript zur Folge gehabt. Hier ein paar Beispiele:

Fall 1: In allen IEs (6-8) wurden Bilder nicht angezeigt? Das ausgespielte HTML wurde aus einem Blog RSS Feed gebildet und Chrome/Safari/Firefox zeigten alles richtig an. Nur alle IEs nicht. Ein Blick in den Quelltext zeigte das die Bilder als Höhenangabe „yy“ und Breitenangabe „xx“ hatten. Also hatte die IE Familie einen Fehler des Blog aufgedeckt.

Fall 2: Ein Javascript funktioniert nicht wie gedacht im IE6 und 7. Im Markup hatte ich eine Liste <ul> und jedes seiner <li>s beherbergte einen Link mit der Klasse „epaper„. Im jQuery wurde mittels $('a.epaper').fancybox(…) ein Verhalten festgelegt. Nun funktionierte dies in allen anderen Browsern, nur IE 6 und IE 7 zeigten lediglich beim ersten <li> Element den gewünschten Effekt ?!
Als erstes habe ich natürlich den Quelltext der einzelnen <li>s Zeichen für Zeichen überprüft aber keine Veränderung festgestellt – die Liste wurde aus einem Template generiert. Danach musste eine Internetsuche nach „fancybox ie bug“ weiterhelfen, aber auch dort wurde ich nicht fündig, die aktuellste Fancybox Version wurde schon genutzt.
Als nächstes: Javascript $('a.epaper') Eventhandler auskommentieren, testen und sehen: Das Verhalten ändert sich nicht!? Weitersuchen im Javascript und folgende Eventhandler Definition finden: $('a#inline').fancybox(…)… Auch diese auskommentieren und endlich: In allen Browsern geht nichts mehr.
Nochmal den Quelltext zu rate ziehen und sehen das alle <a> Elemente in den <li> als id „inline“ bekommen. Das ist nicht valides HTML und IE6 und IE7 halten sich daran das eine id unique sein soll und hören beim setzten von Eventhandler per ID auf sobald sie die gesuchte id gefunden haben.

Zum Glück war der Eventhandler von $('a.epaper').fancybox(…);“ falsch gesetzt und hat dieses Quelltextmanko aufgebracht.

Diese Sturheit der IE Familie hat mich doch beeindruckt, da man hier weniger fehlertolerant zur Sache geht und dadurch das Webmeistern wieder in eine professionellere Ecke stellt. Das hat mir gefallen.

Internet Explorer 9

Die ganze Web Community fiebert dem IE9 entgegen und alle sind happy und froh?!

Alle? Naja, eine Kleinigkeit gibts da noch…

Der IE9 läuft nur noch auf WinVista/Win#7 und nutzt hier Hardwarebeschleunigung. Und da beginnt das Problem. Ich selbst nutze Ubuntu mit (aktuell) drei VMs die alle ein XP beherbergen jeweils mit einer IE Instanz. Das klappt bis jetzt ganz gut – im Gegensatz zu einem virtualisierten WinVista oder Win#7. Wenn ich jetzt noch einen Browser habe der in meiner VM auf Hardwarebeschleunigung setzt, wird das Browertesten zu einer echten Herausforderung.

Kann ich aktuell alle 3 VMs parallell offen haben und in annehmbarer Geschindigkeit Webseiten testen, führt die Ausführung eines virtualisierten Vista/7 schon zu Performance Einbußen auf dem ganzen System. Das ist schlecht.

Bleibt also nur zu hoffen das MS diesmal einen großartigen Job machen und ich durch valides HTML / CSS mir sicher sein kann dass der IE9 es sowieso richtig darstellt. So wie das Web ja auch gedacht ist / war / und bleibt.