Sprung zum Inhalt

Webdesign nach Maß von webdesign weisshart

Mein Blog

RSS Feed AbonnementRSS 2.0 Feed

zum Archiv und den Kategorien

Schnell, schneller, am schnellsten

Dienstag, 4. August 2015

Responsive Webdesign bedeutet nicht automatisch mobile-friendly.
Quelle: Internet

Na, ist doch meine Rede! Mobile-friendly heißt erstens schlank, zweitens schlank, und drittens schlank.

Wasser predigen … aber auch Wasser trinken!

Nach zahlreichen Ratschlägen, Artikeln und Blogposts über die Notwendigkeit, Webseiten schlank zu halten — zumindest für mobile Geräte — musste ich mich doch auch über meine eigene Site hermachen. Alle Empfehlungen zum Verschlanken angewandt, aber Google PageSpeed Insight war nicht wirklich zufrieden. Die mobile Version von webdesign.weisshart.de konnte Google nur ein müdes "70/100" für die Geschwindigkeit entlocken.

Gut, nach einigen Stunden Recherche und Tests sieht das jetzt schon besser aus:

Screenshot PageSpeed Insights
webdesign.weisshart.de nach der Optimierung: 98 von 100 für Geschwindigkeit, 100 von 100 für Nutzererfahrung

PageSpeed Insights von webdesign weisshart

tl;dr: nur Speed-Freaks lesen hier weiter:

Vorab muss man wissen, dass PageSpeed Insight sich nicht für die absolute Größe der einzelnen Elemente (Grafiken, Text, Scripts usw.) interessiert. Sondern nur beurteilt, ob die eingesetzten Elemente auch mit weniger Datenvolumen, und schneller angezeigt werden können. Eine Minigrafik mit wenigen kB, die nicht optimal komprimiert ist, wenige kB angezeigter Text, der aber im HTML-Markup mit (unsichtbaren) Kommentaren aufgebläht ist, veranlasst PageSpeed Insight bereits zur Abwertung.

Ans Eingemachte geht es aber, wenn diese Meldung gezeigt wird:

JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten "above the fold" (ohne Scrollen sichtbar) beseitigen

Unter Fehlerbehebung findet sich dann gerne folgender Hinweis:

Entfernen Sie JavaScript, das das Rendering blockiert:
http://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js

Ja, es stimmt: jQuery (und ähnliche Element) müssen erst einmal komplett heruntergeladen und vom Browser verarbeitet werden, ehe die Seite angezeigt werden kann.

Möglicherweise ist jQuery aber gar nicht erforderlich zur erstmaligen Anzeige der Seite (above the fold), sondern erst später, wenn es zur Interaktion kommt. Wenn man doch nur den Browser davon überzeugen könnte.

Zum Glück geht das: "defer" heißt das Zauberwort.

Leider reicht diese einfache Technik in vielen Fällen nicht aus. Der Grund: Eine sog. race condition; Mit defer (und auch mit dem async-Attribut) hat man keine Kontrolle über Abhängigkeiten von verschiedenen Scripts. Eine JavaScript-Funktion kann dann einmal funktionieren, beim nächsten Seitenaufruf wieder nicht.
Um sicher zu stellen, dass jede Ressource bereits geladen ist, ehe eine anderer Ressource darauf zugreifen will, bedarf es etwas mehr Aufwand.

Bei stackoverflow.com wurde ich fündig. Ich kann in einem multidimensionalen Array exakt die Reihenfolge der deferred Aufrufe festlegen.

Eine weitere Fehlermeldung von PageSpeed Insight:

Optimieren Sie die CSS-Darstellung für die folgenden URLs:
http://xxx/screen_mob.css

hat mir erst mal etwas Kopfzerbrechen bereitet.

Die angebotene Seite mit Lösungsempfehlungen musste ich wiederholt lesen, bis ich auf die einfache Lösung kam:
Das zur Anzeige "above the fold" erforderliche CSS inline einbinden. Der Rest kann dann in eine externe CSS-Datei, die dann erst unmittelbar vor dem schließenden </body>-Tag aufgerufen wird.

Die weiteren Meldungen sind einfacher, wenn auch möglicherweise mit etwas Arbeit verbunden.

Dass die Technik funktioniert, zeigt nicht nur PageSpeed Insight, sondern auch WebPageTest:

Screenshot WebPagetest
Nur 24 kB für die Anzeige von webdesign.weisshart.de auf dem Smartphone

webdesign.weisshart.de auf dem Nexus 5, getestet von WebPageTest

WebPageTest zeigt weitere Details, die bei der Optimierung helfen können. Dazu den Test am besten mit einem Desktop-Browser, und nicht mit einem mobilen Browser aufrufen.

Besser als alle Testwerkzeuge ist aber die Praxis: Die Seite mit einem Smartphone im Mobilfunknetz (Edge, nicht UMTS oder gar LTE) aufrufen. Vorab sicher stellen, dass die Seite noch nicht im Cache des Smartphones gespeichert ist.

Nachtrag 08.08.2015

98 von 100? Das hat mir keine Ruhe gelassen. Die letzten 2% mussten auch noch her. Obwohl das sicher keinerlei praktische Bedeutung hat.
Der Verursacher war klar: Google Analyics google-analytics.com/ga.js wird nur 2 Stunden gecached, Google PageSpeed Insights hätte aber gerne mindestens 5 Tage. (Da weiß wohl auch eine Hand nicht, was die andere tut.)
Nochmal nein! Google Analytics wird bei mir deferred. Auf die Geschwindigkeit der Anzeige hat das Caching also keinerlei Einfluß.
Dennoch: Ich wollte die 100%, und sei es nur als Fingerübung.
Die Lösung:

  1. google-analytics.com/ga.js selbst hosten. Dann habe ich die Dauer des Caching selbst in der Hand.
  2. Um sicher zu gehen, dass ich allfällige Änderungen des Scripts nicht verpasse: Das Script per Cronjob täglich neu downloaden.
Screenshot PageSpeed Insights
webdesign.weisshart.de nach der Optimierung: 100 von 100 für Geschwindigkeit

Danke diywpblog.com für eine detaillierte Anleitung.



1 Kommentar

  1. Jaja, es google und den Besuchern immer recht zu machen ist mühsam ;)

    Kommentar von Ulrich Söllner — Mittwoch, 12. August 2015 - 18:43 Uhr

Einen Kommentar abgeben

Damit Code-Beispiele richtig angezeigt werden, müssen Sonderzeichen maskiert werden (z.B. < zu &lt;).


(notwendig)

(notwendig)

Spamschutz:
Je nach Inhalt wird Ihr Kommentar eventuell nicht sofort angezeigt, sondern muss manuell freigeschaltet werden.

Archiv:

Kategorien:

Creative Commons Lizenzvertrag
Alle Texte (nicht Bilder!) Creative Commons CC BY-NC-SA 3.0 DE