Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 5 steps to faster web sites & HTML5 games - updated for DDDscot
Semelhante a 5 steps to faster web sites & HTML5 games - updated for DDDscot (20)
Último
Último (20)
5 steps to faster web sites & HTML5 games - updated for DDDscot
- 1. Michael Ewins @ewinsmi DDDscot - 29 November 2014
- 3. 40% of people abandon a website that takes more than 3 seconds to load – Kissmetrics “We surveyed 3000 users… they rated speed 2nd most important” – The Guardian “1 second.. about the limit for flow of thought to stay uninterrupted” – Jakob Nielsen Ref: https://blog.kissmetrics.com/loading-time/ Ref: https://speakerdeck.com/patrickhamann/breaking-news-at-1000ms-front-trends-2014 Ref: http://www.nngroup.com/articles/response-times-3-important-limits/
- 4. Create an account & keep your test history Test from multiple locations And different network speeds Ref: https://www.youtube.com/watch?v=6UeRMMI_IzI (“WebPageTest Power Users” –Velocity 2014)
- 5. Test for script failures Take TCP Dumps View Chrome tracing logs Ref: https://www.youtube.com/watch?v=6UeRMMI_IzI (“WebPageTest Power Users” –Velocity 2014)
- 11. “No request is faster than a request not made” Ilya Grigorik (“High Performance Browser Networking”, Sept 2013)
- 13. Requests Bytes JSON 45 147.7 K Images 33 1858 K HTML 23 90.6 K Javascript 21 3026.1 K CSS 3 16.1 K Font 1 14K Flash file 1 12.8 K Audio 1 2392.5 K TOTAL 128 7610.7 K Ref: http://www.webpagetest.org/result/140815_WA_DAE/1/details/
- 15. Before After # File Requests 25 1 Total Request Time 2054 ms 33 ms Total Response Time 28 ms 37 ms Bytes Downloaded 45.6 K 31.2 K Ref: http://www.webpagetest.org/result/140821_8H_W8A/9/details/
- 16. Javascript: e.g. grunt-contrib-concat CSS: e.g. grunt-contrib-cssmin Ref: http://yeoman.io/blog/performance-optimization.html
- 17. Ref: http://www.webpagetest.org/result/140828_E8_G1R/1/details/ {"frames":[{ "filename":"audio-off", "frame":{ "x":1583, "y":280, "w":54, "h":55}, "rotated":false, "trimmed":true, "spriteSourceSize":{ "x":0, "y":2, "w":54, "h":55}, "sourceSize":{ "w":54, "h":57} }, etc
- 18. Before After # mp3 file requests 36 2 Total Request Time 1294 ms 69 ms Total Response Time 902 ms 769 ms Bytes Downloaded 713.6 K 401 K Before: http://www.webpagetest.org/result/140827_5C_FSK/9/details/ After: http://www.webpagetest.org/result/140828_E8_G1R/
- 19. Requests Bytes Images 31 714.8 K Javascript 14 273.1 K HTML 10 57.2 K CSS 1 108.5 K Font 1 23.1 K TOTAL 57 1176.7 K Ref: http://www.webpagetest.org/result/140113_ME_NF2/1/details/
- 20. We saved… Requests 8 Elapsed time 358 ms TTFB 1205 ms Download 877 ms Bytes 147.1K
- 21. “We’ve remade the Internet in our image… obese” Jason Grigsby (April 2011)
- 24. Requests Bytes Images 31 714.8 K Javascript 14 273.1K CSS 1 108.5 K HTML 10 57.2 K Font 1 23.1 K TOTAL 57 1176.7 K Ref: http://www.webpagetest.org/result/140113_ME_NF2/1/details/
- 25. Eliminate images Use CSS3 effects (where possible) Use web fonts instead of text in images Vector images or raster images Optimizing vector images Optimizing raster images Lossless v lossy image compression Choosing GIF v PNG v JPEG v WebP Tuning images Delivering scaled image assets Ref: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/image-optimization
- 26. File Size Download Time Saving Browser 1 PNG-24 32079 bytes 395 ms - All 2 JPEG 11674 bytes 80 ms 64% All 3 JPEG 8457 bytes 63 ms 74% All 4 WEBP 6866 bytes - 79% Chrome 27+ Opera 23+ Android 4.3+
- 27. Requests Bytes Javascript 21 3026.1 K Audio 1 2392.5 K Images 33 1858 K JSON 45 147.7 K HTML 23 90.6 K CSS 3 16.1 K Font 1 14K Flash file 1 12.8 K TOTAL 128 7610.7 K Ref: http://www.webpagetest.org/result/140815_WA_DAE/1/details/
- 28. Before After Request (TTFB) 35 ms 41 ms Content Download 4594 ms 615 ms Bytes 2,485.8 KB 202.0 KB Before: http://s.games.iwin.com/m/iwin/bubbletown/v_18/js/main.js After: http://s.games.iwin.com/m/iwin/bubbletown/v_19/js/main.js
- 29. Apply to text assets: JSON, JS, CSS, HTML Typically 60-80% reduction in file size Don’t apply to already compressed binary files. Extra CPU on server to compress. Extra CPU on client to decompress. Ref: http://bigqueri.es/t/sites-that-deliver-images-using-gzip-deflate-encoding/220
- 30. JQUERY OPTIMIZATION: http://youmightnotneedjquery.com/ Ref: https://mathiasbynens.be/demo/jquery-size
- 31. Before After Frequency 44 KHz 22 KHz BitRate 56 kbps 32 kbps File Size 1600 K 401 K Content download time 3753 ms 769 ms
- 33. "On a mobile network the average RTT is more than 300ms... roughly comparable to a 1990s-era dial-up”, Tammy Everts (April 2014)
- 34. Cache Lookup Ref: https://www.igvita.com/posa/high-performance-networking-in-google-chrome/
- 35. Cache Lookup DNS lookup Ref: https://www.igvita.com/posa/high-performance-networking-in-google-chrome/
- 36. Cache Lookup DNS lookup TCP handshake Ref: https://www.igvita.com/posa/high-performance-networking-in-google-chrome/
- 37. Cache Lookup DNS lookup TCP handshake HTTP request Ref: https://www.igvita.com/posa/high-performance-networking-in-google-chrome/
- 38. Cache Lookup DNS lookup TCP handshake HTTP request HTTP response Ref: https://www.igvita.com/posa/high-performance-networking-in-google-chrome/
- 39. Examples… Cache-Control: no-store Do not cache and fetch on every request Cache-Control: private, max-age=86400 Cached by browser but not intermediate caches for 1 day. Cache-Control: public, max-age=31536000 Cached by browser and intermediate caches for 365 days. Etag: "1404984963" Avoid repeat download if the resource hasn’t changed. Ref: https://developers.google.com/speed/docs/insights/LeverageBrowserCaching
- 40. Review the hostnames used by your site. How long is DNS cached for? Pre-fetch DNS Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Controlling_DNS_prefetching
- 41. Review the hostnames used by your site. How long is DNS cached for? Pre-fetch DNS Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Controlling_DNS_prefetching
- 42. Scotland to AWS East: ~110ms Scotland to AWS West: ~190ms Where are your customers? Deploy more servers? Consider using a CDN? Ref: http://www.cdn-locator.com/cdn/edgecast
- 43. Headers are uncompressed. Cookies Eliminate cookies for static resources Ref: http://www.yuiblog.com/blog/2007/03/01/performance-research-part-3/
- 44. Request #8 is a 307 response It redirects to a secure file on Akamai Extra DNS (45ms) Extra connection setup (39ms) Extra TLS setup (264ms) Ref: http://www.webpagetest.org/result/140830_4J_3SR5/3/details/
- 46. Initial page load: DNS: 0 ms (cached) TCP handshake: 0 ms (re-using connection) Request: 127 ms Download: 2 ms Repeat page load: DNS: 0 ms (cached) TCP handshake: 47 ms Request: 121 ms Download: 2 ms Ref: http://www.webpagetest.org/result/140830_PF_1GA7/
- 47. <script src="main.js" >< /script > Ref: https://www.youtube.com/watch?v=aHDNmTpqi7w
- 48. <script src="main.js" async defer>< /script > IE>=10, Chrome>=8, Firefox>=3.6, Safari>=5.1 Ref: https://www.youtube.com/watch?v=aHDNmTpqi7w
- 50. Multiple streams on a single connection Prioritised streams HTTP Header compression Server initiated streams (push) Ref: https://www.mnot.net/talks/pdf/http2-op-perf.pdf
- 51. • Speed Index: 7129 (HTTP) v 5773 (SPDY) • Fully Loaded: 7.6s (HTTP) v 6.3s (SPDY) • Speed Index: 2026 (HTTP) v 1906 (SPDY) • Fully Loaded: 12.7s (HTTP) v 13.4s (SPDY)
- 52. “It gives you the power to make a large webpage with many resources load faster than a small webpage with few resources”, Patrick Sexton
- 53. HTML DOM CSS CSSOM Ref: https://www.youtube.com/watch?v=VKTWdaupft0 Render Tree Layout Paint
- 56. Pre-render the content needed for initial view Make all JavaScript asynchronous Identify the critical CSS & inline Load other CSS asynchronously Ref: https://developers.google.com/speed/pagespeed/insights
- 59. Before After TTFB 0.128 s 0.153 s Start Render 0.793 s 0.394 s Speed Index 1010 722 Before: http://www.webpagetest.org/result/140909_KN_AS0/ After: http://www.webpagetest.org/result/140915_FF_N34/
- 60. Before After TTFB 0.487 s 0.480 s Start Render 2.387 s 0.893 s Speed Index 1269 1083 Before: http://www.webpagetest.org/result/140916_TM_NK1/ After: http://www.webpagetest.org/result/140916_Z1_NCA/
- 61. Before After TTFB 0.924 s 0.936 s Start Render 2.592 s 1.491 s Speed Index 3417 1778 Before: http://www.webpagetest.org/result/140916_9D_QMF/ After: http://www.webpagetest.org/result/140916_QX_PA8/
- 63. “Being a Performance Cop is not a sustainable thing” Lara Hogan (Google I/O, June 2014)
- 64. Site Perf Grade Requests Load time Page size m.iwin.com 87 / 100 67 0.66 s 0.7 MB agame.com 86 / 100 127 1.53 s 1.1 MB games.com 82 / 100 135 3.43 s 1.8 MB gamesplaza.com 78 / 100 93 2.17 s 0.8 MB Arkadium 78 / 100 54 3.84 s 1.3 MB
- 65. Site #req size start render fully loaded speed index S’more Words 66 2.9 MB 0.3 s 7.6 s 7431 Jewel Quest 56 3.6 MB 0.3 s 9.5 s 8986 Bubble Town 96 3.5 MB 1.1 s 12.7 s 8801 Guess It 92 7.9 MB 1.2 s 19.8 s 14660
- 66. Focus on technical aspects: Mobile web: less than 50 requests, less than 600K, no redirects, etc. HTML5 game: less than 500K of audio, one audio sprite, less than 50 resource requests, etc. Focus on user experience: Mobile web: page speed of less than 2000 on 3G HTML5 game: fully loaded in less than 10 seconds on cable
- 67. Top 100 Alexa Top 1000 Alexa Requests 79% < 50 requests 59% < 50 requests Total Size 517 K 828 K Cache lifetime 24%> 365d 7% > 365d Redirects 32% have 0 redirects 22% have 0 redirects Errors 1% have errors 6% have errors Ref: http://mobile.httparchive.org/interesting.php
- 68. Build process Compression, minification, etc. Automate performance testing grunt-perfbudget Surface feedback convenient for daily work Ref: https://github.com/tkadlec/grunt-perfbudget
- 72. 1. Make fewer requests 2. Make resources smaller 3. Faster round trips 4. Optimize Critical Rendering 5. Web Performance Culture
Notas do Editor
- Welcome
- 1. HTML5 Games Portal for mobile / tablet / PC developed by iWin 2. Jewel Quest (match 3) and Bubble Town (bubble popper). 3. Speed is important: tablet (55%); mobile (28%); desktop (17%) + engage with the games / view adverts that pay for the games
- 1. Abandonment. Kissmetrics (web analytics platform) survey from 2011. Many similar studies. 2. Loss in revenues. Aberdeen Group – technology focused research group have found that: 1% delay >> 7% loss of conversions >> $100K per day >> 7% translates to $2.5M per year 3. Users. See Guardian survey. Rated speed 2nd most important only after easy to find content. 4. Growth. Fred Wilson from USV (twitter, soundcloud) “speed is most important” 5. How fast should we be? 1 second (flow) + 10 seconds (abandon)
- 1. Performance Golden Rule - Steve Souders (created Yslow and HTTPArchive) in 2012- “80-90% of the end-user response time is spent on the frontend.” 1b. Backend time = TTFB for HTML. Frontend time = everything else. 2. WebPageTest - Create account on free online tool to test in the browser: Chrome, Firefox, IE, mobile, etc 2a Open source project – download your own from github. 2b. Multiple connection types, multiple locations, 9 runs / median result, video (speed index & visual compare), history, 3. Advanced: SPOF, JS scripts to logon, TCP Dumps, Chrome tracing. http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/ http://www.slideshare.net/patrickmeenan/webpagetest-power-users-velocity-2014
- 1. Performance Golden Rule - Steve Souders (created Yslow and HTTPArchive) in 2012- “80-90% of the end-user response time is spent on the frontend.” 1b. Backend time = TTFB for HTML. Frontend time = everything else. 2. WebPageTest - Create account on free online tool to test in the browser: Chrome, Firefox, IE, mobile, etc 2a Open source project – download your own from github. 2b. Multiple connection types, multiple locations, 9 runs / median result, video (speed index & visual compare), history, 3. Advanced: SPOF, JS scripts to logon, TCP Dumps, Chrome tracing. http://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/ http://www.slideshare.net/patrickmeenan/webpagetest-power-users-velocity-2014
- 1. Dashboard result showing some key indicators 2. First View (cache empty) versus Repeat View (cache populated) 3. First Byte (first part of the response is received from server) >> Start Render (user starts to see something on screen) >> onLoad event >> page Fully Loaded 4. DOM Elements and Number of requests (all files) and Bytes (all files) https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/quick-start-quide#TOC-High-level-Metrics:
- 1. Dashboard result showing some key indicators 2. First View (cache empty) versus Repeat View (cache populated) 3. First Byte (first part of the response is received from server) >> Start Render (user starts to see something on screen) >> onLoad event >> page Fully Loaded 4. DOM Elements and Number of requests (all files) and Bytes (all files) https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/quick-start-quide#TOC-High-level-Metrics:
- 1. Dashboard result showing some key indicators 2. First View (cache empty) versus Repeat View (cache populated) 3. First Byte (first part of the response is received from server) >> Start Render (user starts to see something on screen) >> onLoad event >> page Fully Loaded 4. DOM Elements and Number of requests (all files) and Bytes (all files) https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/quick-start-quide#TOC-High-level-Metrics:
- 1. HTML page download – the initial request / backend time 2. Critical JS / CSS Green line – start render Blue line – Document load 3. Other resources http://www.webperformancetoday.com/2014/03/18/waterfalls-101-how-to-use-a-waterfall-chart-to-diagnose-performance-pains/
- 1. HTML page download – the initial request / backend time 2. Critical JS / CSS Green line – start render Blue line – Document load 3. Other resources http://www.webperformancetoday.com/2014/03/18/waterfalls-101-how-to-use-a-waterfall-chart-to-diagnose-performance-pains/
- 1. Ilya Grigorik is a Web Performance engineer / advocate at Google. 2. He wrote the book “High Performance Browser Networking” which is a great source for detailed understanding of issues affecting web performance. 3. Making fewer requests is an evergreen performance best practice and is a foundation for numerous good things to do. 4. It applies to mobile web just as much as normal web. http://www.amazon.co.uk/High-Performance-Browser-Networking-performance/dp/1449344763
- 1. Approach: Run WPT; Take an inventory; purpose for each resource; is it needed? 2. Bubble town: 128 file requests; 18 seconds. 3. Game is 71 requests / 6.8MB, console is 28 requests / 550K and Advert is 29 requests / 200K https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/eliminate-downloads
- 1. 45 JSON file requests – level data and meta-data for animations / texture atlas 1a. 25 of these are level data JSON files 2. JSON = 147.7K (so it is not the biggest) 3. This inventory includes everything the user would see: game, iWin game console, and a pre-game advert.
- 1. Each line includes a request and the download. 2. There is a lot of requests / green data
- 1. Refactored to a single level JSON file 2. Bytes downloaded and download time are similar to before. 3. But the request time (TTFB) is down from 2 second to 33 ms. 4. Making lots of requests is bad for performance because it increases the effect of latency. 5. TTFB = time for a request to leave browser, travel to server and return
- 1. Similar technique for JS & CSS 2. Multiple files – better for development 3. Single file – often better for delivery 4. CAUTION!! – iterations in dev / repeat download for users
- 1. Jewel Quest: transparent PNG + JSON file (Texture Atlas cf CSS Sprites) 2. Fewer requests – save time 3. We’re still downloading the same image data but we’re just doing it with ONE request See also: http://www.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/
- 1. This is for Jewel Quest 2. We have saved significantly on the request time 3. We also saved on response time & download time by ensuring consistent encoding (22 KHz & 32 Kbps)
- 1. 57 requests – 13 DNS lookups – 25 separate connections 2. Page fully loaded in 3.6 seconds 3. 31 image requests: 24 of them are for games (658K)
- 1. Original design had 16 images in all games section. 2. Most not visible on initial load / more games or auto-scroll 3. Save elapsed time – major saving is the TTFB - latency
- 1. Jason Grigsby is mobile strategist based in Oregon and regular speaker on mobile and responsive design. 2. Making files smaller is an EVERGREEN web performance tactic 3. But in spite of this the trend shows that we’re not getting it. Let’s look at some trend information. Jason Grigsby: https://speakerdeck.com/grigs http://www.slideshare.net/grigs/native-is-easy-web-is-essential/51
- 1. Average web page size is 1.6 MB (actually 1.7MB since I wrote this slide) 2. That is 22 times bigger since 1995 3. Or 4 times bigger than 11 years ago in 2003.
- 1. If we focus on the top 1000 Alexa web sites with data tracked by HTTP Archive. 2. The size of web pages DOUBLED between 2010 and 2013 3. Growth is primarily from images, scripts, and other (video / audio).
- 1. Images account for approx 70% of the web page resources
- 1. Optimizing image file sizes has been a best practice for 15 years+. 2. This list is from Google. Innovation is still happening in this space.
- 1. We can save significant file size for a single image – approx 65 to 75% saving 2. First JPEG create with ImageMagik then progressive JPEG created with Photoshop by artist 3. WebP is new image compression format developed by Google. Limited Browser support. 4. If we apply similar compression to all images on home page then we reduce to 840 ms elapsed time (from 1438 ms)
- 1. Again if we look at the inventory for Bubbletown 2. the largest file size is actually Javascript code not audio or images. 3. There are 21 separate JS file requests but one of the files main.js is 2.5MB (of 3 MB total)
- 1. By minifying a single Javascript file we are able to save almost 4 seconds download time. 2. Minification here is removing whitespace / reducing variable / method names. 3. Used the Grunt plugin grunt-contrib-uglify with mangle & compress options https://github.com/gruntjs/grunt-contrib-uglify
- 1. A key technique for all text assets is to use GZIP. 2. This compresses the file on the server as it is requested (cache this response) 3. Compression is quick and the uncompress is also quick on the client. 4. Don’t do this for binary formats that are already compressed. 5. Some CDNs require you to expose both gzip and non gzip.
- 1. Example focused on jquery: 2. Use BOTH minification and gzip 3. Similar techniques for HTML / JSON / CSS 4. You may not need all of jquery. Aside: https://code.google.com/p/zopfli/ - Zopfli Compression Algorithm is a new zlib (gzip, deflate) compatible compressor. This compressor takes more time (~100x slower), but compresses around 5% better than zlib and better than any other zlib-compatible compressor we have found
- 1. Earlier in the talk we reduced the number of file requests for Audio file delivery in JQ 2. Initially the files went bigger because we had higher sample rate and bit rate 3. Saved 3 seconds in download – Phaser.io sequential loader.
- 1. Visualisation presented at Velocity on 16 September 2014 (for Techcrunch site) 2. The trailing lines are the times for different runs. A lot of variation. 3. Shows clearly that the time to download is not directly proportional to file size 4. Latency has a bigger effect than bandwidth.
- 1. Round trip is the time to make a request and get a response. We want to remove impediments that may slow this down. 2. But each request either needs a new or reuse and existing connection and also DNS lookup. Tammy Everts – Web Performance Evangelist at Radware http://blog.radware.com/applicationdelivery/applicationaccelerationoptimization/2014/04/7-mobile-performance-myths/ Latency again. http://www.webperformancetoday.com/2012/04/02/latency-101-what-is-latency-and-why-is-it-such-a-big-deal/ http://msdn.microsoft.com/en-us/magazine/dd188562.aspx https://engineering.linkedin.com/performance/how-linkedin-used-pops-and-rum-make-dynamic-content-download-25-faster
- 1. Browser cache – if it has expired or not seen it before then we must request it. chrome://view-http-cache/ 2. DNS lookup to obtain the IP address: host name may already be cached. chrome://net-internals/#dns 3. A new TCP connection incurs the Three-Way Handshake which adds a full roundtrip of latency. This is dependent on the distance between client and server and the routing. We’re ignoring SSL / HTTPS – it will incur 1-2 additional round trips 5. Dispatch the HTTP request to the server. If you are hitting a CDN server then there may be a repeat DNS – TCP – request to the back-end server. Until first byte served. 6. HTTP Response is a minimum of 1 round trip but it depends on the response size v TCP congestion window (4-15KB – also slow start) 7. This process is then repeated for every resource in the html response. For timings from http://www.webpagetest.org/result/140831_E3_E1J/2/details/ See http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/
- 1. Browser cache – if it has expired or not seen it before then we must request it. chrome://view-http-cache/ 2. DNS lookup to obtain the IP address: host name may already be cached. chrome://net-internals/#dns 3. A new TCP connection incurs the Three-Way Handshake which adds a full roundtrip of latency. This is dependent on the distance between client and server and the routing. We’re ignoring SSL / HTTPS – it will incur 1-2 additional round trips 5. Dispatch the HTTP request to the server. If you are hitting a CDN server then there may be a repeat DNS – TCP – request to the back-end server. Until first byte served. 6. HTTP Response is a minimum of 1 round trip but it depends on the response size v TCP congestion window (4-15KB – also slow start) 7. This process is then repeated for every resource in the html response. For timings from http://www.webpagetest.org/result/140831_E3_E1J/2/details/ See http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/
- 1. Browser cache – if it has expired or not seen it before then we must request it. chrome://view-http-cache/ 2. DNS lookup to obtain the IP address: host name may already be cached. chrome://net-internals/#dns 3. A new TCP connection incurs the Three-Way Handshake which adds a full roundtrip of latency. This is dependent on the distance between client and server and the routing. We’re ignoring SSL / HTTPS – it will incur 1-2 additional round trips 5. Dispatch the HTTP request to the server. If you are hitting a CDN server then there may be a repeat DNS – TCP – request to the back-end server. Until first byte served. 6. HTTP Response is a minimum of 1 round trip but it depends on the response size v TCP congestion window (4-15KB – also slow start) 7. This process is then repeated for every resource in the html response. For timings from http://www.webpagetest.org/result/140831_E3_E1J/2/details/ See http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/
- 1. Browser cache – if it has expired or not seen it before then we must request it. chrome://view-http-cache/ 2. DNS lookup to obtain the IP address: host name may already be cached. chrome://net-internals/#dns 3. A new TCP connection incurs the Three-Way Handshake which adds a full roundtrip of latency. This is dependent on the distance between client and server and the routing. We’re ignoring SSL / HTTPS – it will incur 1-2 additional round trips 5. Dispatch the HTTP request to the server. If you are hitting a CDN server then there may be a repeat DNS – TCP – request to the back-end server. Until first byte served. 6. HTTP Response is a minimum of 1 round trip but it depends on the response size v TCP congestion window (4-15KB – also slow start) 7. This process is then repeated for every resource in the html response. For timings from http://www.webpagetest.org/result/140831_E3_E1J/2/details/ See http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/
- 1. Browser cache – if it has expired or not seen it before then we must request it. chrome://view-http-cache/ 2. DNS lookup to obtain the IP address: host name may already be cached. chrome://net-internals/#dns 3. A new TCP connection incurs the Three-Way Handshake which adds a full roundtrip of latency. This is dependent on the distance between client and server and the routing. We’re ignoring SSL / HTTPS – it will incur 1-2 additional round trips 5. Dispatch the HTTP request to the server. If you are hitting a CDN server then there may be a repeat DNS – TCP – request to the back-end server. Until first byte served. 6. HTTP Response is a minimum of 1 round trip but it depends on the response size v TCP congestion window (4-15KB – also slow start) 7. This process is then repeated for every resource in the html response. For timings from http://www.webpagetest.org/result/140831_E3_E1J/2/details/ See http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/
- 1. Use browser cache to avoid making repeat requests 2. Four examples on the slide: no cache; browser/1day; browser+CDN/365d; Etags 3. Checklist: what can be cached (query params, case sensitive); how long / what changes frequently?; how to invalidate?. 4. Advanced concepts like gzip; what happens when caches invalidate Flowchart: https://developers.google.com/speed/docs/insights/LeverageBrowserCaching New headers: http://www.fastly.com/blog/stale-while-revalidate/#.VBoRCS5dUZw Vary: Accept-Encoding -Caches should only be used if the incoming request matches the Vary information in the cache. With gzip. http://blog.maxcdn.com/accept-encoding-its-vary-important/ Checklist: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#caching-checklist
- 1. Options limited to things we can control 2. Number of domains referenced – can we reduce? (e.g. events.iwin.com >> m.iwin.com/events) 3. TTL – maybe good reason for 1 minute or 5 minutes or 7 days. Reason? Costs linked to TTL. 4. DNS prefetch (see example). Separate browser thread for DNS lookups - in parallel to downloads and rendering. 4.1 Resource Hint spec: preconnect, prefetch, prerender http://daker.me/2013/05/5-html5-features-you-need-to-know.html $ dig +nocmd +noall +answer +ttlid a m.iwin.com m.iwin.com. 604800 IN CNAME m.iplay.mobi. m.iplay.mobi. 60 IN A 54.209.107.239 $ dig +nocmd +noall +answer +ttlid a games.iwin.com games.iwin.com. 604800 IN CNAME wpc.81CD.edgecastcdn.net. wpc.81CD.edgecastcdn.net. 3600 IN CNAME gs1.wpc.v1cdn.net. gs1.wpc.v1cdn.net. 600 IN A 72.21.81.131 $ dig +nocmd +noall +answer +ttlid a ma.iwin.com ma.iwin.com. 604800 IN CNAME cds.n5v6x5m3.hwcdn.net. cds.n5v6x5m3.hwcdn.net. 300 IN A 205.185.216.10
- 1. Options limited to things we can control 2. Number of domains referenced – can we reduce? (e.g. events.iwin.com >> m.iwin.com/events) 3. TTL – maybe good reason for 1 minute or 5 minutes or 7 days. Reason? Costs linked to TTL. 4. DNS prefetch (see example). Separate browser thread for DNS lookups - in parallel to downloads and rendering. 4.1 Resource Hint spec: preconnect, prefetch, prerender http://daker.me/2013/05/5-html5-features-you-need-to-know.html $ dig +nocmd +noall +answer +ttlid a m.iwin.com m.iwin.com. 604800 IN CNAME m.iplay.mobi. m.iplay.mobi. 60 IN A 54.209.107.239 $ dig +nocmd +noall +answer +ttlid a games.iwin.com games.iwin.com. 604800 IN CNAME wpc.81CD.edgecastcdn.net. wpc.81CD.edgecastcdn.net. 3600 IN CNAME gs1.wpc.v1cdn.net. gs1.wpc.v1cdn.net. 600 IN A 72.21.81.131 $ dig +nocmd +noall +answer +ttlid a ma.iwin.com ma.iwin.com. 604800 IN CNAME cds.n5v6x5m3.hwcdn.net. cds.n5v6x5m3.hwcdn.net. 300 IN A 205.185.216.10
- 1. Connections require a round trip to the server 2. Traceroute (RTT) from my home to AWS East and AWS West. Distance matters. 3. More servers if content is dynamic or not cacheable at CDN. Use GeoDNS. 4. Use a CDN for static content. Edgecast have 19 PoPs. 5. Some CDNs may not support what you are trying to do. E.g. caching by device type. At least OOTB. Google CDN for jQuery: https://stackoverflow.com/questions/5206666/jquery-ui-how-to-use-google-cdn This approach is interesting because your user may already have this file from another web site. May 2013 - Approx 20% of sites use Jquery from google cdn http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ GeoDNS: http://serverfault.com/questions/325076/what-is-the-difference-between-anycast-and-geodns-geoip-wrt-ha http://www.cdnplanet.com/tools/cdnfinder/#site:http://m.iwin.com http://visualwebsiteoptimizer.com/split-testing-blog/geo-distributed-architecture/ http://www.cedexis.com/blog/fun-with-headers/ http://www.semicomplete.com/blog/geekery/ssl-latency.html http://blog.radware.com/applicationdelivery/applicationaccelerationoptimization/2014/04/7-mobile-performance-myths/ https://www.igvita.com/2014/03/26/why-is-my-cdn-slow-for-mobile-clients/
- 1. Review all cookies. 80ms per 4K: http://www.yuiblog.com/blog/2007/03/01/performance-research-part-3/ http://www.jonathanklein.net/2014/02/revisiting-cookieless-domain.html https://twitter.com/csswizardry/status/280639163789893632 http://www.geedew.com/2014/02/26/the-case-for-critical-assets/
- So we make a request and the first thing that the server does is issue a redirect response. In this example (for an advert) We are redirected to a new domain: DNS lookup We then need a new connection And this is a secure domain so we also have TLS setup. And then we can download the content.
- 1. Time spent by the backend server to respond to deliver the HTML 2. In our case this is 41ms. We’re serving from an in-memory cache called Varnish. 3. Unique user behaviours we have pushed to the client (e.g. user id generation). 4. We cache different versions based on device behaviour. 5. Entire talk on this alone.
- 1. If you have a missing file then you’ll get a 404 (favicon) 2. Typically these are not cached. 3. Therefore the request will be repeated every time. 4. Adding to your latency http://zoompf.com/blog/2012/04/instagram-and-optimizing-favicons IE9 can be PNG (not GIF) IE8 must be ICO (uncompressed bitmap) – compress with gzip!!! 16x16 – do not serve larger files & waste bytes Use 4-bit / 16-colors Don’t use data URI – cache it so it is there for every page and not inlining extra data
- 1. Ghostery – what scripts are on your page? 2. What happens if the request to that script fails? That is SPOF 3. When the script fails it blocks your page render / load. 4. Test with SPOF-O-Matic browser plugin or use WebPageTest 4. Use HTML5 async attribute. Async does not block DOMContentLoaded 5. Defer attribute works in IE 5.5+. Defer blocks DOMContentLoaded 6. Use both. Steve Souders - http://www.hakkalabs.co/articles/your-script-just-killed-my-site-transcript https://www.youtube.com/watch?v=aHDNmTpqi7w Tammy Everts: http://www.oreilly.com/pub/e/3089 Alternative to async tag – but our games are html5. http://www.feedthebot.com/pagespeed/defer-loading-javascript.html http://www.slideshare.net/bbinto/third-party-footprint-evaluating-the-performance-of-external-scripts
- 1. Ghostery – what scripts are on your page? 2. What happens if the request to that script fails? That is SPOF 3. When the script fails it blocks your page render / load. 4. Test with SPOF-O-Matic browser plugin or use WebPageTest 4. Use HTML5 async attribute. Async does not block DOMContentLoaded 5. Defer attribute works in IE 5.5+. Defer blocks DOMContentLoaded 6. Use both. Steve Souders - http://www.hakkalabs.co/articles/your-script-just-killed-my-site-transcript https://www.youtube.com/watch?v=aHDNmTpqi7w Tammy Everts: http://www.oreilly.com/pub/e/3089 Alternative to async tag – but our games are html5. http://www.feedthebot.com/pagespeed/defer-loading-javascript.html http://www.slideshare.net/bbinto/third-party-footprint-evaluating-the-performance-of-external-scripts
- 1. TCP has a slow start algorithm for connections 2. This determines how many TCP segments are delivered before a round trip acknowledgement is needed. After the ack it increases. 3. Each TCP segment is 1460 bytes 4. Initcwnd should be around 10 (linux kernel default). Above diagram is old – it starts at 3. Varies by CDN. http://www.stevesouders.com/blog/2010/07/13/velocity-tcp-and-the-lower-bound-of-web-performance/ http://mike.bailey.net.au/2010/07/speed-matters/ *** https://docs.google.com/viewer?url=http:%2F%2Fassets.en.oreilly.com%2F1%2Fevent%2F44%2FTCP%2520and%2520the%2520Lower%2520Bound%2520of%2520Web%2520Performance%2520Presentation.pdf
- 1. Goal is 30-50% faster page load time 2. Chrome & Firefox will enforce HTTPS / SSL (spec doesn’t) 3. Reuse connection – latency is the bottleneck not bandwidth 4. Prioritised streams means we ensure important assets are delivered first 5. Compressed headers (less HTTP overhead) 6. Rather than wait for client to parse the html the server can spot dependencies and start pushing them (cf TCP slow start) 7. Partial rollout - Chrome / Firefox / Opera Android – partial support on IE11 & not on Safari HTTPS Everywhere: https://www.youtube.com/watch?v=cBhZ6S0PFCY http://blog.chromium.org/2013/11/making-web-faster-with-spdy-and-http2.html https://thethemefoundry.com/blog/why-we-dont-use-a-cdn-spdy-ssl/
- Smore Words - not written with Phaser (SPDY faster) SPDY: http://www.webpagetest.org/result/140930_Q0_XX9/ HTTP: http://www.webpagetest.org/result/140930_DX_XTB/ BubbleTown – Phaser (HTTP faster) – Phaser has sequential loader HTTP: http://www.webpagetest.org/result/140930_9B_YQY/ SPDY: http://www.webpagetest.org/result/140930_36_YGH/
- 1. Patrick Sexton is developer of FeedTheBot.com 2. This site analyses your site against Google guidelines – seo, performance, and more. http://www.feedthebot.com/pagespeed/critical-render-path.html http://www.stevesouders.com/blog/2013/05/13/moving-beyond-window-onload/
- 1. Critical rendering path is the sequence of resources that are needed to render a page. 2. Firstly we load and parse the HTML. This may identify other resources it needs to complete the render. 3. Download / parse / execute JS files needed to further construct the DOM. Could be multiple JS files. Request round-trips are expensive. JS blocks the DOM construction. 4. Download / parse / process CSS that blocks construction of the Render tree. 5. The render cannot complete until DOM and CSS ready, render tree ready, layout is ready.
- 1. Google Pagespeed Insights can tell you what resources are on the critical rendering path: 3 x JavaScript files and 2 x CSS files 2. If we put them in the HTML then the browser will block because it thinks it needs them to construct the DOM and the render tree. 3. Each of these resources require us to request / download / parse time.
- 1. Render initial html on the server – don’t do JS / document.write 2. Think about the order of the div elements as this affects resource loading 3. Make all JS asyncrhonous 4. Identify the critical CSS (and keep this small – under 15K) 5. Defer non-critical CSS: CSS does not have equivalent to async (lazyload attribute is coming) - E.g. Load CSS via async JS https://blog.twitter.com/2012/improving-performance-on-twittercom http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-to-product/ https://stackoverflow.com/questions/8372099/should-i-render-this-template-using-javascript-or-the-server
- 1. All JS is async and inlined all CSS 2. Initial download is longer 3. Still doing the same JS processing.
- 1. Speed Index is a measurement that tells us how long it feels like the page takes to load 2. Based on %age completeness of the render (10 frames per second) 3. Useful for before and after comparisons 4. The above chart is from HTTP Archive data
- These optimizations have bigger effects where network latency is slower.
- https://developers.google.com/speed/docs/insights/mobile?hl=en 200 ms for DNS – you cannot really change this but you can make it worse 200 ms for TCP Connection – you cannot really change this but you can make it worse 200 ms for request 200 ms for response 200 ms for render
- Google I/O 2014 – Lara Hogan (Etsy) & Paul Lewis – Performance Culture https://www.youtube.com/watch?v=0bRLtJHo0pI Summary of this talk: https://medium.com/@jakob_anderson/web-performance-culture-68cefc6c7b55 http://www.slideshare.net/mikebrittain/web-performance-culture-and-tools-at-etsy-11159635
- 1. What data should we gather – see earlier in the slides 2. Compare before and after changes 3. Compare competitors 4. Show uplift in other stats
- 1. http://s.games.iwin.com/m/console/v_80/#/m/iwin/smorewords/v_38/#!dnspga Results: http://www.webpagetest.org/result/140911_Y7_YMC/ 2. http://s.games.iwin.com/m/console/v_80/#/m/iwin/puzzle_match3_jewelquest/v_101/#!dnspga Results: http://www.webpagetest.org/result/140911_7W_YSC/ 3. http://s.games.iwin.com/m/console/v_80/#/m/iwin/bubbletown/v_29/#!dnspga Results: http://www.webpagetest.org/result/140911_HX_YGN/ 4. http://s.games.iwin.com/m/console/v_80/#/m/iwin/guessit/v_11/#!dnspga Results: http://www.webpagetest.org/result/140911_Q2_YWC/
- 1. Need the whole team to get it – not just the dev team 2. Define this upfront otherwise you will be told that it is too costly to change the game after it is done. 3. Automate the validation of this budget http://blog.codinghorror.com/performance-is-a-feature/ https://speakerdeck.com/yeseniaperezcruz/design-decisions-through-the-lens-of-a-performance-budget
- 1. HTTP Archive reviews 100K sites twice a month wrt factors affecting web performance (SQL db) 2. Compare top 100 and top 1000 Alexa sites 3. Requests / Total size / caching / redirects / errors 4. Dynect have reported that CDN usage higher in top sites also: http://dyn.com/blog/dyn-research-cdn-adoption-by-the-numbers/ 5. Coincidence or cause?
- 1. Image compression, minification, etc. 2. Budget: #requests, size, speed index, time, #redirects, #errors, cache rules 3. grunt-perfbudget integrates with public or private WPT, different scenarios, and define budgets 4. Etsy surface extra stats in the browser if the user works at Etsy http://sethwalker.me/talks/a-public-commitment-to-performance/ Graphs are awesome: start render, doc complete, etc.
- 1. Automated using Pingdom RUM 2. Daily / weekly email?