Frontend Performance @ 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
- 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%!
- 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/
- 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
- 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
- 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/
- 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