Bilder Output – Responsive Images

Heute Abend habe ich rund um das Thema Bilder-Ausgabe in WordPress referiert. Es war eine kleine Runde – aber mit interessanten Fragen und Diskussionen.

Wir begannen mit den (Meta)infos, welche wir einem Bild hinzufügen können. Dabei habe ich ausführlich auf die Wichtigkeit des Alternativtextes hingewiesen. Im Anschluss folgte ein Thema, welches bei mir lange viele Fragezeichen auslösten, dem Theme Feature Content Width. Wir diskutierten über drei kleine Zeilen Code und die Auswirkungen mit dem width Attribut.

Danach folgte das Hauptthema: Responsive Images. Mit Hinweisen auf die letzte Präsentation von Mark, habe ich erklärt, was es mit dem Begriff Responsive auf sich hat. Da die Ausführungen zu den Attributen srcset und sizes genug Zeit beanspruchen, blieben das SVG-Format und das, mir bisher zu wenig bekannte, picture Element aussen vor.

Zu guter Letzt habe ich anhand von Penguin die möglichen Optimierungen eines Themes gezeigt. Hier ein ausführlicher Artikel auf WPZOO: Responsive Images in WP 4.4: Ein paar Handgriffe fehlen noch …

 

Responsive Design – Worauf kommt es an?

Erstellt mit Notizen von Tom

Slides: Mark Howells-Mead

Die Inhalte des Vortrags sind gut über die Slides nachzuvollziehen. Hier einige ergänzende Anmerkungen:

Gute Tool um zu prüfen, was in welchen Browser funktioniert: caniuse.com

Ein Breakpoint markiert die Bildschirmbreit, wenn eine andere Darstellung verwendet werden soll (responsive Sprung).

In der Regel müssen 5 verschiedene Bildschirmgrössen beachtet werden: Smartphone hoch/quer,Tablet hoch/quer, Desktop. Es gibt aber unendliche Varianten (siehe Foto auf Folie 2). Und dann noch «Retina».

Mark empfiehlt im Code den Breakpoint nicht pixel, sondern in rem zu definieren. Dabei ist 1 rem = 16px (standard). Dies spielt z.b. eine Rolle, wenn jemand Schriftgrösse im Browser auf 130% einstellt. Dann wird die Schrift nicht unnatürlich vergrößert.
960, 1024 usw, ist immer durch 16 teilbar.
960/16=reine Zahl

Unter dem Gesichtspunkt Performance gilt: Mobile first!
Die Darstellung im Handy sollte darum so light wie möglich, nur was nötig ist, damit es möglichst wenig zu laden hat. Je größer der Bildschirm, desto mehr Möglichkeiten hat man mehr Informationen in die Darstellung zu packen.

Je mehr «retina», desto feiner kann auch die Schrift sein, auch Grautöne. (= je älter, desto gröber).
Es gibt verschiedene Emulatoren (z.B. Browserstack (kostenpflichtig) Quirktools, responsivetest.net oder auch Erweiterungen für Chrom und FireFox) für die responsive Darstellung, aber manchmal kann diese vom Original abweichen. Deshalb auch immer Tests mit einem Original-Gerät. Hoch- und Querformat testen!

Ist ein Theme responsive, lädt es auf Desktop, iPad oder Smartphones unterschiedliche Inhalte. Je kleiner der Bildschirm, desto weniger wird dargestellt (Folien 6-9).
Bilder werden dabei ganz normal in WordPress eingebunden. Dabei wird jedes Bild standardmäßig in drei verschiedenen Größen gespeichert und je nach Bildschirmgröße dargestellt. Je nach Theme wird ein Bild auch in mehr Größen von WordPress gespeichert.

(Zukunft: Javascript «Service Worker». Mehr als Cache, etwas das quasi eine App in einem Browser nachbaut. Mit RestAPI, superlight, superfast, z.B. bei offline browsing, eine ganze Site durchklicken, alles bleibt danach im Browser. Verbessert die Performance!)

Die Auflösung muss keine direkte Relation haben, ob es mobile ist oder nicht!
iPad Pro hat mehr Pixel als viele Desktops. Xperia 3800px, bei 806 ppi, «Super-Retina». Oder dann hats vielleicht einen Kongressaal-Monitor.

Wenn Möglich SCG-Images verwenden. Geht nicht für Fotos.
Beispiel: sbbrcs.ch
Das Trapez links passt sich der Auflösung des Bildschirms an.

Check, ob ein Theme gut responsive ist:
* Gibt es aktuelle Updates?
* Hat die Demosite eine gute Performance (Google Page Speed Insights, GTMetrix, pingdom etc.)
[x] disable cache = es kommt immer ohne caching, pure speed getestet
* Ist es SVG-ready? (nice to have)
* Unterstützt es Responsive Images?
* Anzeige mit verschiedenen Bildschirmen und Auflösungen testen. Das Browserfenster kleiner schieben reicht dabei nicht aus! In Chrome z.B. mit Entwicklertools testen oder Emulatoren nutzen (siehe oben).

google map auf mobile, fenster muss klein genug sein besonders auf Mobile, damit finger-browserscrollen ≠ mapdragging