Vortrag zum Thema Frontend Performance vom 20.01.2012 an der Hochschule der Medien Stuttgart

1. Frontend
Performance
Jakob Schröter
20.01.2012 @ Hochschule der Medien Stuttgart

2. Frontend Engineer
Kajona CMS
Bachelor of Computer
Science in Media Master of Computer
Science and Media
Wanderer
Schlagzeuger

4. PERFORMANCE

6. FRONTEND PERFORMANCE

8. LADEZEIT?
Spalte2
1000 ms
500 ms
100 ms
50 ms

10. Einfluss der Ladezeit
Glückliche User
Mehr User
Mehr Umsatz
Kurze
Ladezeit

11. Einfluss der Ladezeit
Amazon +100 ms 1 % weniger Verkäufe1
Yahoo +400 ms 5-9 % weniger Zugriffe1
Google +500 ms 20 % weniger Zugriffe1
Bing +2000 ms 4,3 % weniger Umsatz/Nutzer2
Shopzilla -5000 ms 25 % mehr Zugriffe
7-12 % mehr Umsatz
50 % weniger Hardware3
Mozilla -2200 ms 15,4 % mehr Downloads4
1 http://www.websiteoptimization.com/speed/tweak/psychology-web-performance/
2 http://www.slideshare.net/dyninc/the-user-and-business-impact-of-server-delays-additional-bytes-and-http-chunking-in-web-search-presentation
3 http://radar.oreilly.com/2009/07/velocity-making-your-site-fast.html
4 http://blog.mozilla.com/metrics/category/website-optimization/

12. User Experience
Empfohlene Ladezeit:
– vor 2006: unter 8 Sekunden Jupiter research
– 2006: unter 4 Sekunden Jupiter research
– 2009: unter 2 Sekunden Forrester Research
„Jede Website, deren Ladezeit eine Sekunde
überschreitet, tut dem Benutzer weh.“ Jakob Nielsen
http://www.stevesouders.com/blog/2010/05/07/wpo-web-performance-optimization/

13. 10 Golden Principles of
Successful Web Apps
Speed
Instant Utility
Software is Media
Less is More
Make it Programmable
Make it Personal
RESTful
Discoverabilty
Clean
Playful
http://thinkvitamin.com/web-apps/fred-wilsons-10-golden-principles-of-successful-web-apps/

14. SEO -> WPO
• Ist Search Engine Optimization ist ein
Thema von gestern?
• Performance beeinflusst Google Ranking
seit April 2010

15. „Das Internet ist nicht
schneller geworden“
http://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2

16. PERFORMANCE OPTIMIEREN
Messen: z.B. JMeter
Bottlenecks finden: Profiling des Backends
Code optimieren / mehr Server-Hardware / bessere Server-Anbindung

17. Was wollen wir messen?
Wahrgenommene Wartezeit!
= Inhalt ist für den Nutzer sichtbar
= Nutzer denkt, er kann interagieren

18. Performance messen #1
• HTML-Seite generiert und • Definiertes DOM-Element
geladen sichtbar
• DOM-Ready-Event • „Above the Fold“ (AFT)
DOM ist aufgebaut, Inhalt evtl. keine Änderungen mehr am
sichtbar sichtbaren Inhalt
• OnLoad-Event
alle Ressourcen wurden geladen,
Inhalt evtl. sichtbar

19. Performance messen #2
• verschiedene Clients
• verschiedene Locations
• verschiedenen Anbindungen
• Performance kontinuierlich messen…

20. 20%
80%

21. Wahrgenommene Ladezeit
einer Webseite
20%
80%

22. Wahrgenommene Ladezeit
einer Webseite
20%
Server
80%
Client

23. Wahrgenommene Ladezeit
einer Webseite
20%
Server
80%
Client

24. WAS PASSIERT IM BROWSER?

25. Your best friends
• „F12“-Tools
• Firebug
• Yahoo YSlow
• Google PageSpeed
• Speed limiter: Webscarab
• WebPageTest.org
• ShowSlow.com

26. HTML (Server) Resources (Client)

27. HTTP Requests are expensive!
ANZAHL DER REQUESTS REDUZIEREN

28. HTTP Requests reduzieren
• Redirects vermeiden
• Dateien sinnvoll kombinieren
– base.js, dragndrop.js, upload.js, …
– base.css, dashboard.css, lightbox.css
• Auch Grafiken – CSS Sprites
– button.png, button_hover.png,
button_active.png, …

29. CSS Sprites
sprites.png
40px
110px
.button {
width: 10px; height: 10px;
background-image: url(sprites.png);
background-position: 100px 40px;
}
.button:hover {
background-position: 110px 40px;
}

30. Intelligentes Browser-Caching
Use HTTPs potential!
• Achtung, ETag!
GET File
Server Client
File
GET File, if modified
Server Client
304 not modified
File

31. Intelligentes Browser-Caching
• Besser: Expires-Header
GET File
Server Client
File
Expires 01.01.2013 00:00
Server Client
File

32. Supercache: Gemeinsames CDN
• Google CDN
– //ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js
• Aber: Single Point Of Failure
– Asynchron laden
– Lokales Fallback

33. Cache busters
• base-12.js
• styles-67.css
• background-890.png
• 890/background.png
• background.png?890

34. HTTP Requests are expensive!
REQUESTS VERKLEINERN

35. Compression & Minifying
• alles was geht: HTML, CSS, JS, JSON, XML,
…aber keine Bilder, PDFs, SWFs, …
• Komprimieren
– mod_deflate
• Minimieren
– YUICompressor, UglifyJS, ...

37. Compression & Minifying
hdm-stuttgart.de
Komprimiert
Original Minified Komprimiert + Minified
HTML 101 KB 97 KB 17 KB 16 KB
CSS 90 KB 68 KB 19 KB 14 KB
JS 243 KB 195 KB 73 KB 63 KB
434 KB 360 KB 109 KB 93 KB
-341 KB ≈ -79%!

38. Compression & Minifying
laut.fm

39. Compression & Minifying
netflix.com
“Adopting a single optimization,
gzip compression, resulted in a 13-25% speedup
and cut their outbound network traffic by 50%.”
http://www.stevesouders.com/blog/2010/05/07/wpo-web-performance-optimization/

40. IMAGE
OPTIMIZATION

41. Image Optimization
JPG PNG GIF
Farbanzahl
• Richtige Abmessungen + „Für Web speichern“
• CSS-Sprites

42. smushit.com
hdm-stuttgart.de
130 x 86 px

43. smushit.com
spiegel.de

44. smushit.com
koeln.de

45. smushit.com
laut.de

46. smushit.com
laut.fm

47. HDM-STUTTGART.DE
-325 KB Compression & Minifying
-97 KB Image Optimization
-422 KB -49%

48. HTTP Requests are expensive!
REIHENFOLGE DER REQUESTS

49. Order of loading resources
<script> blockiert weitere Downloads
<script> blockiert Rendering
-> Reihenfolge beachten
-> defer/async-Attribute bzw. Loading-Tools nutzen

50. Order of loading resources
DOM-ready onLoad
Zwingend Sichtbare Ergänzende
CSS notwendige Scripts Pre-/Lazy-Loading
Grafiken Scripts
base.css modernizr.min.js background.jpg dragndrop.js
button.png lightbox.js
<head> <body> Dynamisch per JS

51. PRELOADING

52. Preloading
• Z.B. Loginseite

53. LAZY-LOADING

54. Post-loading

55. Asynchrone Requests
• Inhalte per AJAX nachladen
• Testen! ;-)

56. Domain sharding / CDN
• Schnellere Antwortzeiten/Übertragungsraten
– Schlanker Webserver
– Cookie-freie Domain
• Parallele Downloads (für ältere Browser)
– nur 2 Requests per Host
s-static.ak.facebook.com

57. Usability
• Kann die Nutzerführung optimiert werden?
• Kann der Nutzer bereits etwas tun, während
er warten muss?

58. Advanced WPO
NOCH NICHT SCHNELL GENUG?

59. Rendering optimieren
• Progressive Rendering / Early Flushing
• Anzahl der DOM-Element reduzieren
• Reflow optimieren

60. JavaScript optimieren
• JavaScript Best Practices
• DOM-Manipulationen
• Memory Leaks fixen
• Verzögertes Parsen / Ausführen
<script>
/*
function weNeedThisLater () {}
var weNeedThisLater2 = 123;
*/
</script>

61. CSS optimieren
• Selektoren sind unterschiedlich schnell
.myStyle { }
ul li .myStyle { }
• CSS braucht Rechenleistung
– border-radius, box-shadow, text-shadow,
background-image, …
http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/

62. Chrome Speed Tracer

63. Strangeloop Site Optimizer
Fokus auf der vom Nutzer wahrgenommenen Ladezeit.
Analysiert Nutzerverhalten und lädt Ressourcen bereits vor.

64. Web Performance Optimization
„IST JA GANZ SCHÖN
AUFWÄNDIG…“

65. Sehr gute Tools verfügbar
• Yahoo YSlow
• Google PageSpeed
• Dynatrace AJAX Edition
• WebPageTest.org

66. Vieles lässt sich automatisieren
Integration in den Deployment/Build-Prozess
– JS/CSS-Dateien kombinieren
– Compression & Minifying
– Caching und Cache busters
– Bildoptimierung
– Verteilung auf CDN

67. Auf dem Server
• On-the-fly
– Mod_deflate
– Mod_pagespeed
– WEBO Site SpeedUp (PHP)

68. Externe (kommerzielle) Services
• On-the-fly in der Cloud
– blaze.io
– strangeloop.com
– Google Page Speed Service
• Monitoring
– Gomez

69. HTML 5 + CSS 3 + JavaScript
• CSS 3
– CSS statt Grafiken
– Canvas
• HTML 5
– Network Timing API
– Web Storage statt Cookies
– Web Workers
– Web Sockets
• JavaScript!!!

70. Multiplexed streams
Request prioritization Server push & hint
HTTP header compression
Was Google hat, was wir (noch) nicht haben…
GOOGLE + CHROME use SPDY
An experimental protocol
for a faster web
~50% reduction in page load time

72. Entlastet auch
Enorme die Server Basics sind einfach
Auswirkungen
Best Practices
Frontend
Performance
beachten &
weiter optimieren matters!
Kosten/Nutzen abwägen
Direkte Verbesserung
für die Nutzer
don‘t fiddle – analyse first
Mobiles Internet
RIA

73. Weiterführend
• Bücher:
– Steve Souders: High Performance Websites
– Steve Souders: Even Faster Websites
• Test-Webseite: http://stevesouders.com/cuzillion
• http://developer.yahoo.com/performance/
• http://code.google.com/intl/de-DE/speed/

74. Beispiele aus der Praxis

75. Dynamische Bildauslieferung
• /image.php?src=image.jpg&width=200
• Standard:
– Kein Client-seitiges Caching
– Evtl. Server-seitiges Caching
– PHP wird ausgeführt
– Evtl. Session + Datenbank-Verbindung

76. Dynamische Bildauslieferung
• /image/w200/11259834/hdm-stuttgart.jpg
• Optimale Lösung:
– Server-seitiges Caching
– Client-seitiges Caching
• Cache Header + Expires Header + HTTP 304 Not Modified
• Cache buster + Redirect für alte URLs
– PHP nur wenn wirklich benötigt
• Mod_rewrite

77. Best practices
• Nicht alles muss neu erfunden werden
– HTML5 Boilerplate verwenden
• data-URLs
• http://caniuse.com/
• Memory Leaks im Client
• Messen was auf dem Client passiert

78. Frontend
Performance
Jakob Schröter
jakob.schroeter@seitenbau.com