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

Javascript und der </body>-Tag

„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

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

Nachtrag: Mobile Web Performance Optimierung

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

mobile Web Performance Optimization mit Chromiums 38 Responsive Design View

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

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