Autor: Gerd

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

Erstellt von Nico Martin

Slides: http://slides.com/nicomartin/webperformance-wpbern/

Wenn wir in diesem Kontext von «Performance» sprechen, geht es um die Ladezeit der Seite vom Absenden der URL bis zur kompletten Ansicht der Webseite. Ein weiterer Aspekt der Performance wäre die Verarbeitung von Animationen im Browser. Dieser war jedoch nicht Teil dieses Treffens.

Grundsätzlich folgt ein Ladeprozess einer dynamischen HTML-Webseite immer demselben Schema:

1. Der Browser (Client) startet eine Anfrage / schickt Daten an einen Server
2. Der Server verarbeitet diese Daten und stellt eine Antwort zusammen
3. Der Server schickt die Antwort als HTML DOM zurück
4. Der Client liest das Dokument und startet je nach Inhalt weitere Anfragen für zusätzliche Dateien (Assets).

Im oben beschriebenen Ablauf gibt es zwei «Nadelöhre», die wir nun genauer anschauen.

Verarbeitung auf dem Server

Je nach Komplexität der Anwendung und Leistung des Servers kann diese Verarbeitung sehr lange dauern. Da werden z. B. Inhalte aus einer Datenbank z. T. sogar von anderen URLs geladen. Der einfachste Schritt wäre dabei, bereits gemachte Prozesse zu speichern (Server-Caching). Hier hilft zum Beispiel WP Super Cache, W3 Total Cache oder Cachify.

Viel wichtiger wäre jedoch ein schneller Server, der z. B. auch php7 unterstützt.

Assets

Assets sind in dem Sinne zusätzliche Dateien, die der Browser lädt, um die Seite darzustellen. Das sind in der Regel Bilder, JavaScript- und CSS-Dateien:

JavaScript / CSS

Die erste Frage, die sich ein Entwickler immer stellen sollte, ist: «Brauche ich das?»

Wenn man die Features, die diese Datei bietet, nicht nutzt, dann muss sie auch nicht eingebunden werden. Das ist i. d. R. schon der erste Punkt, an dem viele WP-Themes scheitern. Sie beinhalten zu viele ungenutzte Features.

Wenn man die Datei doch benötigt, dann empfiehlt sich ein minify (z. B. https://jscompress.com/ oder noch besser automatisch beim Entwickeln). Bei einer grossen Bibliothek wie jQuery 3.1.1 spare ich dadurch über 65% an Daten!

Ein weiterer wichtiger Punkt ist der Ladeprozess. Dateien, die in den <head> der Seite eingebunden werden, blockieren das Rendern der Seite. Deshalb macht es Sinn, JavaScript Dateien immer ganz am Ende der Seite einzubinden.

Autoptimize bringt viele Features mit, sollte jedoch nur eingesetzt werden, wenn man sich der Sache sicher ist.

Bilder

Der wichtigste Punkt im ganzen Performance-Prozess ist jedoch die Bildoptimierung.

• Bildgrösse an die effektive Grösse auf der     Webseite anpassen (responsive Images)
• So weit wie möglich verlustlos komprimieren
• jpeg anstelle von png verwenden
• progressive JPEG anstelle von Standard     (baseline) JPEG verwenden

Hierbei kann ich z. B. den EWWW Image Optimizer empfehlen.

progressive JPEG

Während ein baseline JPEG von oben nach unten geladen wird, lädt progressive JPEG Layer für Layer. Das heisst, als Erstes wird eine sehr schlechte Version des Bildes geladen und erst nach und nach kommen neue Layer hinzu. Das hat den Vorteil, dass der User nach wenigen Millisekunden bereits ein Bild sieht und erst später die Qualität nachgeladen wird. Ich habe das hier kurz demonstriert:

baseline JPEG: https://performancedemo.vir2al.ch/

progressive JPEG: https://performancedemo.vir2al.ch/?type=progressive

PageSpeed Insights

Zuguter Letzt gibt es einen einfachen Weg, die Performance einer Seite zu messen (oder zumindest eine Vorstellung zu bekommen). Da die Performance nicht zuletzt auch SEO-relevant ist, stellt Google ein Tool zur Verfügung:

https://developers.google.com/speed/pagespeed/insights/

Dieses kann eine Hilfe sein, sollte aber nicht als einziger Massstab angesehen werden. Denn wie es Paul Bakaus selber sagt: «Nobody cares about how fast your site is, only how fast it feels». (https://fronteers.nl/congres/2016-spring/sessions/the-illusion-of-speed-by-paul-bakaus)

Und der arbeitet immerhin für Google an deren Chrome Browser.

Interessante Links

https://fronteers.nl/congres/2016-spring/sessions/save-the-day-with-http2-image-loading-by-tobias-baldauf

https://www.youtube.com/watch?v=G3WGjDk4-Ic

Überlegungen:

Beim Webhosting werden durch den Hoster regelmässig Backups durchgeführt. Jedoch hat man darauf wenig Einfluss wann und wie gesichert wird und die Wiedereinspielung ist meist teuer.

Backups sind wichtig, falls es Updates gibt oder neue Plugins ist die Installation beschädigt haben, d.h. Backup. Sicherheitsgefühl ist für jeden anders, Änderungen sollten erhalten bleiben.

Auch im Falle eines Angriffs sind Backups wichtig, um die letzte saubere Installation zurück zusichern.

Strategie:

Die Backup Strategie, d.h. wie oft gesichert wird und wo die Backups gelagert werden, hängt von den Anforderungen ab (Änderungen, Sicherheitsgefühl). Es ist zu überlegen, die Sicherung nicht auf auf den gleichen Server abzulegen. Backups auch löschen, zwei gute Backups genügen.

WordPress besteht aus zwei Teilen, die SQL Datenbank mit allen Inhalten und Dateien.

Plugins:

Es kann direkt auf den Server ein Backup mit Cronjobs organisiert werden, einfacher sind Plugins. Man sollte darauf achten, ob automatische zeitplangesteuerte Backups möglich sind und das Zurücksichern ebenfalls einfach möglich ist.

Gratisversionen:

BackWPup  (sehr verbreitet, viele Funktionen, Zeitpläne möglich, Restore nicht optimal (FTP Upload, PHP Admin)
BackupWordpress (Zeitpläne möglich, Restore nicht optimal (FTP Upload, PHP Admin)
Duplicator (eignet sich nur für manuelle Backups und sehr gut zum Umziehen einer WP Installationen auf eine andere Test-Domain)

Bezahlversionen

Hiermit sind automatisch zeitgesteuerte Backups in der Regel auf verschiedenen Medien und cloudbasierten Speicherorten möglich. Die Firmen bieten meistens auch Speicherplatz an.

Vaultpress $99/Jahr für eine Domain
BackupBuddy $80/Jahr für eine Domain, $100 für 10 Domains
(bietet zusätzliche laufende Sicherung mit Stash)
Duplicator Pro $39/Jahr für 3 Domains

Plugins zur Verwaltung von mehreren Seiten

Die Lösungen haben in der Regel auch Backupmöglichkeiten integriert

CMSCommander
InfiniteWP
MainWP

 

Artikel geschrieben von Stephan Zurfluh, Überarbeitung Gerd Zimmermann