Das Thema Website-Performance beschäftigt uns seit Anbeginn des Webs. Die Websites sind grösser, bildlastiger und komplexer geworden, auf der anderen Seite sind die Bandbreiten gestiegen und die Geräte leistungsfähiger geworden, mobile Endgeräte mit ganz eigenen Anforderungen kamen hinzu. Wir werfen einen Blick auf die Situation heute. Welche der alten Tricks bringen noch was, worauf kann man mittlerweile getrost verzichten? Alles unter besonderer Berücksichtigung der infrastrukturellen Rahmenbedingungen und Eingedenk der Tatsache, dass Websites heute nicht mehr von Hand gebaut werden, sondern zumeist aus einem CMS kommen.

1. Webinale 2018
Performance-Optimierung für CMS getriebene Websites,
Berlin, 06 Juni 2018
Sporty Speedometer @ welcomia/ depositphotos

2. 20 goldene Regeln
von Steve Souders

3. Wie messen?

4. webpagetest.org
Wie messen?

5. https://developers.google.com/speed/pagespeed/insights/
Wie messen?

6. Uptrends
Wie messen?

7. New Relic
Wie messen?

8. 1. Bilder

9. 1. Bildformate

10. 1. Bildformate

11. GIF: gut für Grafiken mit wenigen Farben
PNG: Das „bessere“ GIF, komprimiert verlustfrei, kann
Transparenz.Achtung: Kann dadurch sehr gross werden
JPEG: Optimal für Biilder, lässt sich gut komprimieren. Sollte
progressive sein.
TIFF: Hat imWeb nichts verloren. Sicher, daß es im CMS
nicht doch benutzt wird?
BMP: Dito
SVG:Vectorgrafikformat, daß im Browser darstellbar ist,
sehr gut für Logos etc.
1. Bildformate

12. Was ist mit WebP?
1. Bildformate

13. 1. Bildformate
Bilder zusätzlich für Chrome inWebP ausgeben.
Ergibt ca. 30% kleinere Bilder
ACHTIUNG: Speicherplatz
ACHTUNG: CDN
(Umsetzung per picture element, mit polyfill)

14. 2. Bildgrössen

15. 2. Bildgrössen
2. Bilder sollen
natürlich vom CMS
automatisch skalliert
und komprimiert
werden.
Falls das CMS das nicht (gutgenug) kann:
www.imgemagick.org

16. 2. Bildgrössen

17. Gewünschter Workflow:
Der Redakteur lädt das Bild im Originalformat in der
Originalauflösung hoch, den Rest erledigt das System
automatisch.
Achtung: Ritch-Text-Editor!
2. Bildgrössen

18. Berücksichtigung von
HiDPI Monitoren:
Source Sets:
@1und @2 und @3
2. Bildgrössen

19. Für Bilder mit fester Breite
Qualität vs. Geschwindigkeit vs. Speicherbedarf
ACHTIUNG: Speicherplatz
ACHTUNG: CDN
2. Bildgrössen

20. Für responsive
Websites oder mobile
Versionen
Source Sets:
Wieviele und welche
Bildbreiten sind
sinnvoll?
2. Bildgrössen

21. Grafic: Wikipedia.com
2. Bildgrössen

22. 2. Bildgrössen
Qualität vs. Geschwindigkeit vs. Speicherbedarf
ACHTIUNG: Speicherplatz
ACHTUNG: CDN

23. 3. Metadaten

24. 3. Metadaten
Metadaten können
Bilder stark
aufblähen.

25. 3. Metadaten
35 kb
Mit Metadaten Ohne Metadaten
14 kb
http://exif.regex.info
Bei allen Bildern oder evtl. nurThumbnails alles ausser
IPTC rausnehmen.
Achtung: Evtl. rechtliche Implikationen

26. Farbprofile blähen
Bilder ebenfalls auf und
sind zumeist unnötig.
Evtl. alle Farbprofile auf SRGB umrechnen
3. Metadaten

27. Evtl. alle Farbprofile auf SRGB umrechnen
3. Metadaten

28. II. Caching

29. 1. Locales Caching

30. Expire Dates im Server setzen, damit
die Dateien im Browser gecached
werden:
Bilder: lange
HTML, Javascript und CSS: kürzer
Ausnahmen für Analytics etc.
Achtung:Wird vom CDN überschrieben
1. Locales Caching

31. 2. Content Delivery
Network

32. 2. CDN
Optimal bei weltweiten Zielgruppen und high trafficWebsites
Kostspielig
VORSICHT bei dynamischen Inhalten

33. 2. CDN
Bei AMP Pages kriegt man das Google CDN „gratis“ dazu.

34. III. Ladereihenfolge

35. Optimalerweise den sichtbaren
Bereich zuerst, den Rest lazy loading
Text vor Bildern
Skripte am Ende der Seite laden
(Geht nicht mit allen, manche müssen/sollen
im Head stehen.
Browserdetection, JQuery, Analytics)
Hier muss man immer Kompromisse machen
ACHTUNG:Themenbühne
III. Ladereihenfolge

36. IV. Anzahl der HTTP
Requests

37. IE 11:
Max Connections = 33
Connections per Hostname = 13
Chrome 60:
Max Connections = 24
Connections per Hostname = 6
Firefox 54:
Max Connections = 29
Connections per Hostname = 6
IV. Anzahl HTTP
Requests

38. IV. Anzahl HTTP
Requests

39. CSS und Javascript zusammenlegen
wo immer möglich und sinnvoll
Bilder auf (mehrere) Subdomain
auslagern. Request Limit gillt pro
(Sub)Domain.
Fremden Code evtl. von extern laden
(Bootstrap, Fonts, JQuery etc.)
Auslagern von CSS und JS eher nicht sinnvoll, da gecached
Achtung: CMS
Achtung: CDN
Achtung: HTTP/2
IV. Anzahl HTTP
Requests

40. V. Javascript und CSS
minifizieren

41. V. Javascript und CSS
minifizieren

42. Performancegewinn hängt von der
Größe der JS und CSS ab
Nur sinnvoll, wenn automatisiert
möglich (Less, Sass)
Lesbarkeit geht verloren und
Deployment Prozess wird komplexer
Genau prüfen, ob im konkreten Fall wirklich sinnvoll
V. Javascript und CSS
minifizieren

43. VI. DNS Lookups
reduzieren
Weiterleitung von http auf https plus Site Root in einem
Schritt machen.
DNS Lookup aus anderen Ländern hängt von der CDN
Performance ab.

44. Gzip auf dem Server benutzen
AJAX cachbar machen
VII. Der Rest

45. Find these slides and
much more stuff at
www.bokowsky.net/de/knowledge-base/

46. Vielen Dank
Markus Bokowsky
markus@bokowsky.de
@MarkusBokowsky
sowie auf Facebook, Google+, Foursquare,
LinkedIn, Lanyrd, Pinterest, etc.
Bokowsky + Laymann GmbH
www.bokowsky.de
@BokowskyLaymann
sowie auf Facebook, Slideshare, YouTube,
Flickr
P.S: Bokowsky + Laymann sucht Entwickler
Objective-C, Java (Android), PHP, ColdFusion, Swift
jobs@bokowsky.de oder im Social Network IhresVertrauens