Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (13)
Similaire à Building Lightning Fast Websites (for Twin Cities .NET User Group)
Similaire à Building Lightning Fast Websites (for Twin Cities .NET User Group) (20)
Dernier
Dernier (20)
Building Lightning Fast Websites (for Twin Cities .NET User Group)
- 2. Introductions • Former Principal Consultant @ ILM • Apr 2014, founded fasterweb.io • Automatically bundle, minify, gzip • Then…automatically cache static parts of dynamic pages • Then…backburner (for now) • Web Perf Consulting
- 3. 1 second & 100 milliseconds • Round numbers • Nielsen usability study (1993) • 0.1 second is reacting instantaneously • 1 second is uninterrupted flow • Achievable in 2015! • …kinda…
- 4. 1 second before…what exactly? • DOMContentLoaded event • onload event • Page rendered on client • Before end-of-<body> scripts • Page interactive on client • After <body> & DOMContentLoaded scripts
- 5. Building Lightning-Fast Websites 1. How exactly is a website loaded by a browser? • What makes it slow? • Single download • Page full of resources 2. How can we optimize the process?
- 6. Optimizing Website Load Time – Why? • Speeding up a fundraising site by 60% increased donations by 14%. Kyle Rush, Obama Campaign (2012) • Speeding up advertising load times by roughly 1.5 seconds increased click-through rates by 12%. DoubleClick (2011) • Cutting 2.2 seconds off loading time increased conversions by 15%. Blake Cutler, Mozilla (2010) • A 400ms increase in load time caused a 5-9% increase in site abandonment. Nicole Sullivan, Yahoo (2008)
- 7. Faster sites are more successful.
- 8. 2 Speed Factors: Latency & Bandwidth • Latency: inherent delay for any request • Limited by geography & speed of light • “RTT” (Round-Trip Time) • “TTFB” (Time to First Byte) = latency + Server Time • Bandwidth: download speed • Limited by infrastructure • And concurrent downloads • And TCP slow-start (“pseudo-latency”) • Download time = Latency + (size / Bandwidth) Read this: https://www.igvita.com/2012/07/19/latency-the-new-web-performance-bottleneck/
- 9. Typical Bandwidth, Latency • Cable/DSL Internet • 20 Mbps, 40ms • 4G LTE • 10 Mbps, 80ms • 3G • 1 Mbps, 300ms • Bandwidth delay = Latency delay for 100kB Note Mbps = megabits, not megabytes
- 10. HTTP Request Lifecycle 1. Radio wakeup (for mobile) 2. DNS Lookup 3. TCP Connection 4. TLS Negotiation (for HTTPS) 5. Request Upload 6. Server Processing 7. Response Download 8. Client Processing
- 11. 1-4. Stuck with these… 1. Radio wakeup (for mobile) • 4G LTE: 250ms from idle (10s), 50ms from inactive (> 100ms) 2. DNS Lookup • Ideally cached…otherwise 1 RTT + ~100ms 3. TCP Connection • 1 RTT, Keep-Alive lasts for 60s 4. TLS Negotiation (for HTTPS) • 2 RTTs + CPU time + OCSP, TLS Resume eliminates 1 RTT Breaking the 1000ms Time to Glass Mobile Barrier (Ilya Grigorik) – https://www.youtube.com/watch?v=Il4swGfTOSM
- 12. 5-8. Upload, Server Time, Download, Client Time • 1 RTT • Reserve 100ms for parsing/rendering • Everything else: under our control
- 13. HTTP Request Lifecycle 1. Radio wakeup (for mobile) 2. DNS Lookup 3. TCP Connection 4. TLS Negotiation (for HTTPS) • Upload, Server, Download, Client This is for one HTML document only! Desktop Mobile Desktop #2 Mobile #2 0 250 0 50 140 180 0 0 40 80 0 0 80 160 0 0 140 180 140 180 400ms 850ms 140ms 230ms ≈600ms ≈180ms
- 14. But our websites aren’t just one HTML doc…
- 15. Page Loading Process (server-rendered) HTML Received CSS/JS Requested <head> JS/CSS Received <body> JS Received HTML Requested DOMContentLoaded Waiting for HTML… Waiting for <head> JS/CSS files… Layout Complete Page Rendered No JavaScript Waiting for <body> JS files… <head> JavaScript (no DOM) <body> JavaScript DOMContentLoaded JavaScript Page is Ready! • DOM is parsed as bytes are received • Parsing waits for JS Execution • JS execution waits for CSS • Rendering waits for CSS • Rendering might wait for post-body JS
- 16. Waterfall Diagram • Visualization of page HTTP requests • Generated by Fiddler (Windows) • HTTP only • HAR format (HTTP Archive) • Includes DNS, TCP, SSL • Browser debug tools, plugins • webpagetest.org • tools.pingdom.com Load Sequence for jsfiddle.net
- 17. perfViewer.js • In-page waterfall diagram • Add <script> to your page • Show for any page w/ bookmarklet • Shows latency & download for all resources • Uses HTML5 Resource Timing API • (no latency info for cross-domain requests) • www.joestrommen.com/perf-viewer-js
- 18. Building Lightning-Fast Websites 1. How exactly is a website loaded by a browser? • What makes it slow? • Single download • Page full of resources 2. How can we optimize the process?
- 19. 1. Make your Server Fast • Target 100ms • Move expensive operations to AJAX calls • Flush <head> immediately • Put scripts in <head> with “defer” attribute • Make HTML server-cacheable
- 20. 2. Eliminate first-render dependencies • Inline critical CSS/JS • Load the rest asynchronously • Use Progressive Enhancement • Make <script> tags `async defer` • Corollary: don’t use document.write • Example: theguardian.com/us • Critical CSS/JS/images inlined • 1 request, 68kB, 200ms
- 21. 3. GZip Compression for Static Content • Reduces text file size by ≈70% • Not useful for images • Use it! • Please, please use it • Be careful with GZip + secure dynamic content • “Breach” attack - breachattack.com • Attacker matches content to secret, GZip size shrinks
- 22. 4. Caching Strategy • 3 Headers • Cache-Control (e.g. “public, max-age=3600”, “private”, “no-cache, no-store”) • Etag (file hash), Last-Modified (date/time) • Recommended: Versioned static files • Reference with hash, e.g. <link href="site.css?v=za3ffbjGOWq0NBu49W9UkZzJsAlCYJzmfwKDuOAv7eM1"… • Cache-Control: public, max-age=31536000 • ETag & Last-Modified Headers • Downside: conditional requests, 304 Not Modified
- 23. Versioned URLs in .NET • BundleConfig ALL THE THINGS • I’m working on a simpler way… • github.com/strommen/WebPerfLib.NET
- 24. Caching != Fast Webpages • Caching helps: • Returning visitors • Intra-site navigation • Caching does not help for: • New visitors • Frequent updates • Yahoo cache miss rate: • Users: 40-60% • Page Views: 20% http://yuiblog.com/blog/2007/01/04/performance-research-part-2/
- 25. 5. Optimize File Delivery • nginx – faster file server than Apache, IIS • Also, caching reverse proxy • Content Delivery Network (CDN) • Geo-distributed file servers • Really, really good at serving files • Most support same-domain • Downsides: low DNS TTL, purging
- 26. 6. Use HTTP/2 (or SPDY) • “Multiplexing” – multiple downloads, one connection • Caveats: • Limited server support for HTTP/2 • Only supporting CDN is Akamai • Not supported on IE <= 10 (or IE11 for Win7) • Requires HTTPS • Perf benefit…in theory • Rumors of 10-30% improvement • Concrete studies…?
- 27. 7. Bundle Resources • One file, multiple scripts • JavaScript or CSS • Reduce request quantity • Consider cacheability • Useless (harmful!) for HTTP/2
- 28. 8. Optimize Images • Choose appropriate format • JPEG – lots of colors, fuzzy edges • PNG – line art, few colors • GIF – animated • BMP – NEVER • Choose appropriate size • Optimize them! • Save up to 75% • Imageoptim (command-line) • Kraken.io (web-based)
- 29. 9. Avoid Multiple Domains (sharding) Pros • More parallel downloads • Avoid cookie uploads Cons • 6 per host is already a lot… • TCP congestion – see Cloudshark • Extra DNS lookups • Extra TLS negotiations • Extra complexity • Obsolete with HTTP/2, SPDY https://insouciant.org/tech/network-congestion-and-web-browsing/
- 30. 10. Minimize Web Fonts • Incompatible with #2 “Eliminate first-render dependencies” • While loading… • Use websafe font? (Firefox) • Show no text? (Chrome) • Streamline font weights • Bold font vs. CSS font-weight: bold; • Common subset: 50% smaller • http://www.fontsquirrel.com/tools/webfont-generator
- 31. 11. JavaScript tricks • PJAX (github.com/defunkt/jquery-pjax) • Link target is fetched with AJAX, pushed into DOM & history API • No DOMContentLoaded • Example: www.mprnews.org • InstantClick (instantclick.io) • PJAX, but fetch on mouseover/touchstart • Example: www.joestrommen.com
- 32. 12. Minify JavaScript • Reduce JS size by 20-60% • Renames local vars to short names • Removes whitespace & comments • Including license comment! Be careful… • Source Maps (.js.map file) • Example: Grunt + Uglify jquery-1.11.2 GZipped Text Minified 32kB (-88%) 94kB (-66%) Readable 80kB (-71%) 278kB
- 33. SPA Horror Stories… • 1 MB of JavaScript, takes 2s • Empty space @ 2.5-4s: JavaScript execution (Core i5) • 3 separate API calls 8 separate HTML templates • Loading GIF @ 4.5s!!!
- 34. Recap 1. How exactly is a website loaded by a browser? • What makes it slow? 2. How can we optimize the process?
- 35. Further Reading • VelocityConf slides – velocityconf.com/devops-web-performance-2015/public/schedule/grid/public • Steve Souders – www.stevesouders.com • PerfPlanet Calendar – calendar.perfplanet.com • Twitter: #perfmatters • My Github: github.com/strommen • I’m always happy to discuss this stuff! joe@joestrommen.com
- 36. Thanks!
Notes de l'éditeur
- Audience poll: Developer, Leader/Manager, Entrepreneur Front-end, back-end – what technologies?
- Nielsen study is at http://www.nngroup.com/articles/response-times-3-important-limits/
- (before showing stats) As computer experts, we are bold, confident, and determined. That’s unusual Most internet users are scared, impatient, confused. Not just grandma! Adding friction is going to make them less likely to succeed Nice thing about web perf is that we can measure it (stats) Wide range of sites have reported stuff like this
- Key point
- Typical wired-network latency is speed of light to the server + 10ms. It’s not going to improve much Bandwidth can be improved – it’s just building bigger pipes.
- Unless your file is >100kB, it causes more overhead due to latency than bandwidth Caveats: bandwidth #s are theoretical, latency #s are practical. is lost due to overhead…but Still though, 100kB is massive – jQuery is only 33kB Keep this in mind, and we’ll come back to it later
- The first 4 of these are out of our control for the most part.
- The first 4 of these are out of our control for the most part.
- Key point
- Let’s assume the page has some CSS & script references in the head, and a few more script references at the end of the body The faster we download JavaScript, the faster the page is ready What impacts the download speed?
- X-Axis = time Y-Axis = HTTP requests Black bar is TTFB Requests with nothing after the black bar are tiny – download is instantaneous
- Node tool to help with critical CSS: https://github.com/addyosmani/critical
- SPDY is basically a beta version of HTTP/2 I haven’t seen a single thing published along the lines of “We enabled SPDY and saw improvements of X%”
- The polar bear images are 50kB and 18kB respectively. I don’t even remember which is which.
- Web fonts are reasonably heavy – 20-100kB Another thing to consider is that fonts can cause reflows when they load if they’re wider than the browser is going to guess. Personal website – I hide the entire content while the font downloads
- Bonus points – failed API call. And all of this happens on mobile as well. Using AngularJS doesn’t have to cause you 4s of overhead…but if you’re not careful, it will. Be cognizant of page load