More Related Content
Similar to 5 Steps to Faster Web Sites and HTML5 Games
5 Steps to Faster Web Sites and HTML5 Games
- 1. Michael Ewins @ewinsmi Mobile Monday Edinburgh - 22 September 2014
- 3. 40% ofpeople abandon a website that takes more than 3 seconds to load. “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. Ref: https://www.youtube.com/watch?v=6UeRMMI_IzI (“WebPageTestPower Users” –Velocity 2014)
- 5.
- 6.
- 7. DNS lookup TCPhandshake HTTP request HTTP response
- 8. “No request isfaster than a request not made” Ilya Grigorik (“High Performance Browser Networking”, Sept 2013)
- 9.
- 10. Requests Bytes JSON45 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/
- 11.
- 12. 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/
- 13. Javascript: e.g.grunt-contrib-concat CSS: e.g. grunt-contrib-cssmin Ref: http://yeoman.io/blog/performance-optimization.html
- 14. 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
- 15. 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/
- 16. Requests Bytes Images31 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/
- 17. We saved… Requests8 Elapsed time 358 ms TTFB 1205 ms Download 877 ms Bytes 147.1K
- 18. “We’ve remade theInternet in our image… obese” Jason Grigsby (April 2011)
- 19.
- 20.
- 21. Requests Bytes Images31 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/
- 22. 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
- 23. File Size DownloadTime 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+
- 24. Requests Bytes Javascript21 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/
- 25. 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
- 26. Apply totext 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
- 27. JQUERY OPTIMIZATION: http://youmightnotneedjquery.com/ Ref: https://mathiasbynens.be/demo/jquery-size
- 28. Before After Frequency44 KHz 22 KHz BitRate 56 kbps 32 kbps File Size 1600 K 401 K Content download time 3753 ms 769 ms
- 29.
- 30. "On a mobilenetwork the average RTT is more than 300ms... roughly comparable to a 1990s-era dial-up”, Tammy Everts (April 2014)
- 31. Cache Lookup DNSlookup TCP handshake HTTP request HTTP response Ref: https://www.igvita.com/posa/high-performance-networking-in-google-chrome/
- 32. 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
- 33. Review thehostnames 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
- 34. Scotland toAWS 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
- 35. Headers areuncompressed. Cookies Eliminate cookies for static resources Ref: http://www.yuiblog.com/blog/2007/03/01/performance-research-part-3/
- 36. Request #8is 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/
- 37.
- 38. Initial pageload: 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/
- 39. <script src="main.js" async>< /script > IE>=10, Chrome>=8, Firefox>=3.6, Safari>=5.1 Ref: https://www.youtube.com/watch?v=aHDNmTpqi7w
- 40.
- 41. Top 100 AlexaTop 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
- 42. Multiple streamson a single connection Prioritised streams HTTP Header compression Server initiated streams (push) Ref: https://www.mnot.net/talks/pdf/http2-op-perf.pdf
- 43. “It gives youthe power to make a large webpage with many resources load faster than a small webpage with few resources”, Patrick Sexton
- 44. HTML DOM CSSCSSOM Ref: https://www.youtube.com/watch?v=VKTWdaupft0 Render Tree Layout Paint
- 45.
- 46.
- 47. Pre-render thecontent 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
- 48.
- 49.
- 50. Before After TTFB0.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/
- 51. Before After TTFB0.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/
- 52. Before After TTFB0.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/
- 53. “Being a PerformanceCop is not a sustainable thing” Lara Hogan (Google I/O, June 2014)
- 54. WebPageTest (+API) Google PageSpeed Pingdom Yotta WebSiteTest Dareboost RUM Yslow Zoompf etc Timings Comparisons Trends
- 56. Educate theteam Developers Everyone else Why should they care? Email / Blog / etc Dashboards
- 57. Automate improvementsinto build process Establish a budget Automate performance testing grunt-perfbudget Surface feedback convenient for daily work Ref: https://github.com/tkadlec/grunt-perfbudget
- 59. 1. Make fewerrequests 2. Make resources smaller 3. Faster round trips 4. Optimize Critical Rendering 5. Web Performance Culture
- 62.
Editor's Notes
- #3 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
- #4 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)
- #5 1. Performance Golden Rule defined by 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
- #6 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:
- #7 1. HTML page download – the initial requst 2. Critical path JS / CSS 3. Other resources http://www.webperformancetoday.com/2014/03/18/waterfalls-101-how-to-use-a-waterfall-chart-to-diagnose-performance-pains/
- #8 1. Dark green = DNS lookup. One lookup per domain. 2. Orange = TCP Connection. Round trip. Browsers can have approx 6 connections to the same server. 3. Bright green = Time to first byte. This is the time from the request being made until the first byte is served back. 4. Blue = content download. This indicates how long it takes for a server to fully serve the requested resource.
- #9 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
- #10 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
- #11 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.
- #12 1. Each line includes a request and the download. 2. There is a lot of green data – TTFB / requests
- #13 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
- #14 1. Similar technique for JS & CSS 2. Multiple files – better for development 3. Single file – often better for delivery CAUTION!!
- #15 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/
- #16 1. We have saved significantly on the request time 2. We also saved on response time & download time by ensuring consistent encoding (22 KHz & 32 Kbps)
- #17 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)
- #18 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
- #19 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
- #20 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.
- #21 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).
- #22 1. Images account for approx 70% of the web page resources
- #23 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.
- #24 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)
- #25 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)
- #26 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
- #27 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.
- #28 1. This is for jquery: https://mathiasbynens.be/demo/jquery-size 2. Use minification and gzip 3. Similar techniques for HTML / JSON / CSS 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
- #29 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.
- #30 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.
- #31 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
- #32 Timings from http://www.webpagetest.org/result/140831_E3_E1J/2/details/ 1. Look for the resource in the browser cache – if it has expired or not seen it before then we must request it. See chrome://view-http-cache/ 2. DNS lookup to obtain the IP address – if we are lucky the host name may already be cached. See 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. See http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/ 4. 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 will be a repeat DNS – TCP – request to the back-end server. Until first byte served. 6. The blue chart is the time from first to the last byte. This 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.
- #33 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
- #34 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
- #35 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/
- #36 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/
- #37 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.
- #38 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.
- #39 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
- #40 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 5. Defer attribute works in IE 5.5+ 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
- #41 TCP has a slow start algorithm for connections This determines how many TCP segments are delivered before a round trip acknowledgement is needed. After the ack it increases. Each TCP segment is 1460 bytes Initcwnd should be around 10 (above diagram is old – it starts at 3) 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
- #42 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?
- #43 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/
- #44 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/
- #45 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 files 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 parser. 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.
- #46 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.
- #48 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
- #49 1. Inline all JS and all CSS 2. Initial download is longer 3. Still doing the same JS processing.
- #50 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
- #53 These optimizations have bigger effects where network latency is slower.
- #54 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
- #56 1. Pingdom RUM
- #57 1. Educate: write up / explain the best practices 2. Developers – speak their language (automate / make it easy to adopt) 3. Others – speak their language (tie it back to biz metrics) 4. Send an email explaining the issue and why it matters (make it regular) 5. Surface the data in a dashboard. http://blog.codinghorror.com/performance-is-a-feature/
- #58 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.
- #62 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