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)).

Der aktuelle Stand

Die neuen Optimierungen werden auf einem Notebook mit Ubuntu Gnome 14.10 x64, 4GB Ram, Samsung SSD, Core i5-2467M CPU, PHP5.5.12 und mySQL 5.5.41 ausgeführt. Die letzten Ergebnisse wurden auf einem AMD A8-3850, 12GB Ram, Seagate HDD (1TB, 32MB Cache) und Ubuntu 14.10 x64 ermittelt. Webserver, Datenbank und PHP kommt alles aus den Standard Ubuntu Repositories.

Da nun andere Hardware als Ausgangspunkt dient, wurde der optimierte Stand vom letzten Mal nochmal auf dieser Plattform nachgemessen:

×LadezeitloadDOMreadyScreen
Beispielseite mit ersten Optimierungen (JS Zusammenfassung, Hintergrundbild optimieren)
Wifi784ms706ms427msp2-wifi1
3G/UMTS5.10s4.94s1.05sp2-3g1
EDGE15.12s14.57s2.86sp2-edge1
GPRS1.2m1.2m12.54sp2-grs1

Diese Zeiten unterscheiden sich hauptsächlich beim DOMready Event, das liegt am async Attribut im Javascript Script Tag, welches ich seinerzeit vergessen hatte.

Optimieren der SVG Dateien Schritt 1

Viele Grafiken auf der Seite sind als einzelne SVG Dateien hinterlegt. Das freut alle HiDPI Besucher und ärgert Besucher mit älteren Browsern, da bisher kein Fallback existiert.

Die 5 SVG Dateien erzeugen 5 GET Requests und insgesamt 31.760 KB.

Bisher wurden die SVG Dateien direkt vom Grafiker übernommen und nicht weiter optimiert. Immerhin werden die SVGs mittels GZIP komprimiert übertragen.

SVGs Minifizieren | grunt-svgmin((grunt-svgmin – wie svgo nur in der Grunt Werkzeugkette))

Verschiedene Tools können diese Arbeit ausführen. Für die Kommandozeile kann man svgo((svgo – nodejs basiertes Kommandozeilen Werkzeug um SVG Dateien zu optimieren)) benutzen, oder man erweitert seinen Grunt Workflow mit grunt-svgmin:

    ...
    svgmin: {
        options: {
            plugins: [
                {
                    removeViewBox: false
                }, {
                    removeUselessStrokeAndFill: false
                }
            ]
        },
        dist: {
            files: [{
                expand: true,
                cwd: "src/svg",
                src: ["**/*.svg"],
                dest: "./assets/",
                ext: ".min.svg"
            }]
        }
    },
    ...
    grunt.loadNpmTasks('grunt-svgmin');
    ...

Nachdem grunt durchgelaufen ist, sind die SVG Dateien nur noch 20.281 KB groß, also eine Brutto Ersparnis von  37%, ohne Berücksichtigung der gzip Auslieferung des Web Servers.

SVG Sprite | grunt-svgstore((grunt-svgstore – Zusammenfassen von vielen SVG Dateien zu einer Sprite Datei))

Es ist möglich SVG Dateien in einem Sprite zusammenzufassen. Dadurch spart man wieder wertvolle GET Requests, aber die Technik hat einige Tücken und muss bei jedem Anwendungsfall neu bewertet werden. Überraschenderweise war für alle IEs (9-11) ein JS Workaround nötig: svg4everybody((svg4everybody – Polyfill für IE9-IE11 zur Nutzung von SVG Sprites)).

Nach sehr langem Ausprobieren, habe ich den Sprite Ansatz verworfen. In diesem Anwendungsfall werden verschieden große SVG Dateien immer an die Bildschirmgröße angepasst. Diese Anpassung habe ich für Firefox und Chromium hinbekommen, aber für die IE Familie war es dann irgendwann nicht mehr witzig. ;-)

Der Vollständigkeit sei gesagt dass ich die Anleitung auf css-tricks.com((css-tricks.com: Icon System with SVG Sprites)) gefunden habe. In anderen Projekten kann die SVG Sprite Nutzung aber durchaus nochmal probiert werden.

Webfonts

Die Webfonts sind von dritten Quellen eingebunden. Dazu muss man sagen, dass die WebFont Anbieter die Auslieferung ihrer Fonts schon maximal optimieren. Hier ist es gerade bei einem OnePager schwer mehr herauszuholen. Aber bei einem Webauftritt mit mehreren Seiten (also die meisten) könnte sich der Trick den ich beim letzten Mal schon erwähnte, mehr nutzen: Loading webfonts with high performance on responsive websites((Loading webfonts with high performance on responsive websites)).

Fonts.com bietet an die Dateien selbst zu hosten, nur muss pro Font Datei auf eine Fonts.com CSS verlinken, damit sie weiterzählen können wie oft der Font angezeigt wurde. Dieses nachvollziehbare Verhalten der Anbieter bringt dann aber keinerlei Einsparung weiterer GET Requests.

Pobeweise habe ich trotzdem die oben genannte Anleitung ausprobiert und den WOFF-Font als base64 direkt in die CSS eingebunden. Hier wurde allerdings deutlich das DOMContentLoaded Event verzögert, da die CSS Datei riesig war und dann noch das parsen von base64 etc dazukam. Die Ausspielung über fonts.com war deutlich zügiger und da man pro Font eine externe CSS Datei einbetten muss, ist hier kein Vorteil zu erzielen.

Einzig der fontawesome ist überflüssig, davon wurde nur ein einziges Icon genutzt, dieses wurde hier als svg heruntergeladen((fontawesome chevron up icon)) und eingebettet.

Fazit

Im Endeffekt wurden die SVG Dateien minifiziert und der fontawesome wurde ersetzt. Weitere Ansätze wie SVG Sprites wurden ausprobiert aber aufgrund des Browsersupports und responsive Anpassungsproblemen verworfen, genauso wie die selbst Auslieferung des Webfont.

Im ersten Schritt wurde eine Hintergrundgrafik für die Ausspielung angepasst und Javascripte wurden per Grunt zusammengefasst, die ganze Seite hat nun 341 KB.

×LadezeitloadDOMreadyScreen
Beispielseite mit weiteren Optimierungen (SVG Minifizierung, FontAwesome Ersatz)
Wifi876ms
(784ms)
752ms
(706ms)
501ms
(427ms)
p2-wifi2
3G/UMTS4.21s
(5.10s)
3.98s
4.94s)
932ms
(1.05ms)
p2-3g2
EDGE12.24s
(15.12s)
11.60s
(14.57s)
2.53s
(2.86s)
p2-egde2
GPRS57.72s
(1.2m)
55.87s
(1.2m)
11.37s
(12.54s)
p2-gprs2

Interessant, ist das bei der WiFi Verbindung tatsächlich die Werte gestiegen sind, allerdings in einem vertretbaren Bereich. Hier ist eigentlich nur ein lokaler GET Request hinzugekommen für das fontawesome SVG.
In allen anderen Netzwerken konnte nochmal etwas herausgeholt werden, da nicht mehr die komplette FontAwesome mitgeladen wird.

Bei einer anderen Website würde ich dem Thema Webfont noch mal mehr Beachtung schenken. Je nach Projekt kann ein externer Webfont aber auch eine Datenschutz Lücke darstellen, da bei jedem Abruf der Besucher per Referrer seinen Weg auf der Seite irgendwohin (fonts.com, google, etc) sendet.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.