Buchempfehlung: Scott Jehl – Responsible Responsive Design

Scott Jehl - Responsible Responsive Design

Vor Kurzem habe ich Scott Jehls Buch „Responsible Responsive Design“ gelesen. Weil ich so begeistert davon war und viele neue Dinge lernen und mitnehmen konnte, habe ich hier die für mich wichtigsten Infos zusammengefasst.

Eine Rezension spare ich mir an dieser Stelle, aber es sei gesagt, dass dieses Buch für alle jene eine Pflichtlektüre ist, die viel mit Responsive Webdesign und Performance zu tun haben oder sich in dieses Thema einlesen möchten.

Wann setzt man am besten einen Breakpoint?

Start with the small screen first, then expand until it looks like shit. TIME FOR A BREAKPOINT!

– Stephan Hay (https://twitter.com/brad_frost/status/191977076000161793)

Tablesaw: Lösungen für die Darstellung von Tabellen in Responsive Designs

Eine Reihe von jQuery Plugins mit verschiedenen Lösungen für die Darstellung von Tabellen in Responsive Designs.

Wie groß sollten Buttons für Touch sein?

Laut dem Smashing Magazine-Artikel „Finger-Friendly Design: Ideal Mobile Touchscreen Target Sizes” empfiehlt es sich, Buttons 45 – 57 Pixel breit zu machen und Buttons, die tendenziell mit Daumen bedient werden, 72 Pixel breit.

Tap-Click Verzögerung: Zwischen einem Tap und dem Auslösen des Click-Events können 300ms vergehen

Auf vielen Touch-Geräten gibt es eine Verzögerung von mindestens 300ms zwischen einem Tap und dem tatsächlichen Auslösen des Click-Events. Das liegt daran, dass Touch-Geräte nach einem Click kurz warten, um sicher zu gehen, dass es sich nicht um ein Double Tap handelt.

Für diese deutlich wahrnehmbare Verzögerung gibt es zwei Lösungen: tappy.js und FastClick

em in Media Queries

Der Autor bevorzugt es, die Einheit em in Media Queries zu verwenden, weil sie relativ zum Content bzw. der Schriftgröße ist und nicht fix wie Pixel.

In dem Artikel „The EMs have it: Proportional Media Queries FTW!“ erklärt Lyza Gardner die Vorteile und gibt auch ein Beispiel dazu.

Der Unterschied zwischen @media all und @media only all

Der Unterschied zwischen den beiden Anweisungen ist, dass @media all oder @media screen bei allen Browsern greift, die CSS 1.0 unterstützen und @media only all bzw. @media only screen nur bei jenen, die CSS3 Media Queries unterstützen.

CSS Device Adaptation

Der viewport-Meta Tag wurde von Apple eingeführt und ist – ganz unabhängig von seiner Verbreitung - kein W3C Standard. Die standardisierte Technik, um die Breite des Viewports zu verändern, ist die sogenannte „CSS Device Adaptation“.

@-webkit-viewport{width:device-width}
@-moz-viewport{width:device-width}
@-ms-viewport{width:device-width}
@-o-viewport{width:device-width}
@viewport{width:device-width}

Die Breite des Viewports wird also in CSS, und nicht mehr in HTML, angegeben. Opera Mini, Opera Mobile und Internet Explorer sind aktuell noch die einzigen Browser, die „CSS Device Adaptation“ unterstützen. Es macht aber Sinn, die Technik zusätzlich zum viewport-Meta Tag zu verwenden. Warum beschreibt Tim Kadlec in seinen Artikeln „IE10 Snap Mode and Responsive Design“ und „Windows Phone 8 and Device-Width”.

Momentum Scrolling

In iOS kann man „schwungvolles Scrolling“ für Elemente mit Scrollbars aktivieren.

overflow-y: scroll; /* Muss scroll sein, nicht auto */
-ms-overflow-style: auto;
-webkit-overflow-scrolling: touch;

Den Unterschied kann man in diesem Codepen auf Tablet oder Smartphone testen.

Wann sollte man ein Polyfill einsetzen?

In 9 von 10 Fällen ist es besser, dem User eine weniger fortgeschrittene Variante einer Funktionalität zu bieten, als ein Polyfill zu verwenden. Bei der Entscheidung sollte man sich drei Fragen stellen:

  • Wie sehr wird durch das Polyfill die Experience verbessert?
  • Wie stark wird die Performance dadurch verschlechtert?
  • Wie wahrscheinlich ist es, dass das Polyfill irgendwann überflüssig und damit entfernbar ist?

Wie testet man am besten auf verschiedenen Geräten?

Natürlich ist es immer am besten auf den tatsächlichen Geräten zu testen. OpenDeviceLab.com bietet eine Map in der aktuell 143 Open Device Labs weltweit markiert sind, damit man herausfinden kann, ob es eines in der Nähe gibt. Zusätzlich kann man auch sein altes Gerät einem bestimmten Lab spenden.

OpenDeviceLab.com

Was Emulatoren betrifft, empfiehlt Jehl Browserstack.

Es ist wichtig, dass man nicht nur mit den Dev Tools eines bestimmten Browsers gut umgehen kann. Auf devtoolsecrets.com findet man Tipps und Tricks für den Umgang mit den Dev Tools in Chrome, Firebug, Firefox, Internet Explorer, Opera and Safari.

Fragen, die man sich stellen sollte beim Testen auf verschiedenen Geräten.

  • Lädt die Website in einer akzeptablen Zeitspanne?
  • Sind die Hauptinhalte und -funktionen bedienbar?
  • Fühlt sich der Funktionsumfang auf dem jeweiligen Gerät passend an? (progressive enhancement)
  • Kann der Text einfach gescannt werden? Fördert die Zeilenhöhe die Lesbarkeit?
  • Ist die Website benutzbar mit den üblichsten Eingabetechniken für das jeweilige Gerät (bspw. Tastatur, Touch, Maus,..).
  • Sind die tapbaren Bereiche einfach zu tapen ohne dass benachbarte Bereiche getroffen werden?
  • Wird das Layout immer noch gut dargestellt, wenn sich Orientation, Viewport- oder Schriftgröße ändern?
  • Wenn technische Hilfsmittel (bspw. Screenreader) installiert sind, wird der Inhalt auf sinnvolle Art und Weise vorgelesen?
  • Funktioniert das Scrolling flüßig? Werden Animationen flüßig abgespielt?

Wann hat eine Seite schnell genug geladen?

Man kann sagen, dass eine Seite dann schnell genug geladen, wenn die Ladezeite, die benötigt wird bis die Website bedienbar ist, unter einer Sekunde liegt.

Die Performance kann man mit Google PageSpeed Insights testen und Vorschläge für die Optimierung einholen.

Eine weitere Möglichkeit zu testen ist WebPageTest. Ein wichtiger Indikator bei den Tests ist der Speed Index. Laut Paul Irish sollte es das Ziel sein einen Speed Index unter 1000 zu erreichen.

My answer to how fast is fast enough? A Speed Index of under 1000. [...] And lastly I think most people's expectations for what's OK is currently way too lax. :)

Paul Irish

Mehr dazu gibt es in seinem Talk auf der Fluent 2014.

Was kann man als Grundlage für ein Performance Budget nehmen?

Wenn man nicht weiß, welches Performance Budget man festlegen soll, kann man einfach die Ladezeiten oder Speed Indices von Konkurrenz Websites hernehmen, vergleichen und einen niedrigeren Wert budgetieren.

Caching optimieren

Tipps zur Optimierung des Caching einer Website:

Offline Websites

Es kann manchmal auch sinnvoll sein, Inhalte offline verfügbar zu machen.

Lazy Loading

Zwei empfohlene Artikel von Jeremy Keith zum Thema Lazy Loading:

Ein Script um Inhalte lazy zu laden ist Ajax Include. Damit kann man Inhalte unter bestimmten Voraussetzungen laden, bspw. erst wenn das DOM geladen ist oder wenn ein bestimmtes Media Query greift.

Inhalte bei Breakpoints umordnen

AppendAround – Ein Script mit dem man Elemente je nach Breakpoint im DOM umordnen kann.

Performance bei Media Queries in separaten CSS-Dateien

<link href="a.css" rel="stylesheet">
<link href="a.css" rel="stylesheet" media="(min-width: 45em)">
<link href="a.css" rel="stylesheet" media="(min-resolution: 100dpi)">
<link href="a.css" rel="stylesheet" media="nonsense query weeee!">

In allen gängigen Browsern werden alle Stylesheets ganz unabhängig vom media-Attribut geladen, auch wenn die Media Queries nicht greifen.

Unfortunately, not only do browsers always request StyleSheets regardless of their applicability, but many browsers delay rendering (displaying the page content to the user) until those requests have returned.

Scott Jehl

In manchen Browsern werden die Stylesheets zumindest an Hand der media-Attribute priorisiert.

That said, some modern browsers (particularly those based on Webkit and now Blink) will actually evaluate media queries (when present) to determine the priority at which a StyleSheet should be loaded before requesting that StyleSheet. In these browsers, StyleSheets paired with media queries that are found to be inapplicable at load time will be loaded asynchronously (and possibly deferred until higher-priority requests have been made), meaning the page content will be displayed to the user immediately and regardless of whether those de-prioritized StyleSheets have finished loading or not.

Scott Jehl

Beispiel, Untersuchung und Ergebnisse von Scott Jehl auf Github.

Wann sollte man CSS nicht in eine eigene Datei auslagern?

Wenn man eine Single-Page Website macht, jede Seite anders aussieht oder wenn man nur wenig CSS verwendet (~unter 8kb).

Critical path (above the fold) CSS und HTML

Die Datenmenge, die bei der ersten Anfrage an den Server zurückgegeben werden kann, beträgt 14kb. Man sollte versuchen, dass diese 14kb das CSS, HTML und JS umfassen, das notwendig ist für die Darstellung des sichtbaren Teils der Website (Viewport) und den Rest sollte man asynchron laden, bspw. mit loadCSS.

npm Plugin und Grunt Task für das Extrahieren des Critical CSS.

Media Query & Asset Downloading Results

Tim Kadlec hat in seinem Artikel „Media Query & Asset Downloading Results“ untersucht unter welchen Voraussetzungen Bilder speziell beim Einsatz von Media Queries in den gängigsten Browsern geladen werden oder nicht.

Sonstige Skripte, Lösungen und Tools

Data URIs

Data URIs per Drag & Drop konvertieren

Data URIs können Performanceprobleme auf manchen mobilen Geräte verursachen. Passende Artikel dazu:

Barrierefreie und mehrfarbige Icon Fonts

Mehrfarbige Icon Fonts

Grunticon - A mystical CSS icon solution

Grunticon – Browserübergreifend Arbeiten mit SVG Icons inklusive .png-Fallback

Fonts via Javascript laden

CSS Font Loading API

Es gibt auch Alternativen zu jQuery

Shoestring - Eine Alternative zu jQuery mit niedriger Dateigröße.

Javascript dynamisch laden

loadJS – Javascript asynchron laden, je nach Voraussetzung.

CSS und JS dynamisch laden

enhance.js – loadCSS, loadJS und mehr in einem Script zusammengefasst.

A JavaScript workflow designed to progressively enhance sites in a qualified manner.

Manuel Matuzovic

Frontend Developer aus Wien.

Schreibe einen Kommentar

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