Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scaling Front-End Performance - Velocity 2016

1,611 views

Published on

Presentation from Velocity 2016 on creating a performance-resilient web application

Published in: Technology
  • Great presentation. Regarding the Client-Side Decisions, the most important parameter is the RTT between the client and the server handling the connection (origin server or CDN edge server). You indicate in slide #19 that the delta (performance.timing.responseStart - performance.timing.navigationStart) should give the TTFB, a good proxy for RTT. From the Navigation Timing spec, it looks like the delta (performance.timing.responseStart - performance.timing.requestStart) would also give a measure of TTFB. These 2 measures of TTFB are probably pretty close however I wanted to ask you why you picked navigationStart over requestStart.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Scaling Front-End Performance - Velocity 2016

  1. 1. Scaling Front-End Performance Patrick Meenan @PatMeenan
  2. 2. http://www.internetworldstats.com/top20.htm
  3. 3. http://www.internetworldstats.com/top20.htm
  4. 4. Increasing Usage  Get More Users - Mostly coming from emerging markets - Mostly mobile-only - Mostly with highly variable connectivity - REALLY long tails  Increase usage of existing users - Faster = more usage
  5. 5. FCC 2016 Broadband Progress Report https://www.fcc.gov/reports-research/reports/broadband-progress-reports/2016-broadband-progress-report
  6. 6. FCC 2016 Broadband Progress Report https://www.fcc.gov/reports-research/reports/broadband-progress-reports/2016-broadband-progress-report
  7. 7. “non-fixed” broadband  Mostly Satellite or Cellular  All with low data caps  Most with HUGE latencies - 1s RTT satellite not uncommon - 100+ms cellular is “good”, can be MUCH higher
  8. 8. Traditional development – mocks and feature lists https://www.smashingmagazine.com/2015/04/using-sketch-for-responsive-web-design-case-study/
  9. 9. Loading is an experience – treat it like one  What should they see while loading?  On slow connections, what are acceptable blank page times?  Can the content move/relayout? - Hint, the answer should always be NO!  How should text load/display, how long is blank text acceptable for?  What order should the images load?  Can content be displayed incrementally?
  10. 10. Search Lite http://searchengineland.com/google-launches-streamlined-lite-version-of-mobile-search-interface-for-slower-connections-218269
  11. 11. Search “Interventions”  Weblight – transcoded pages on slow mobile connections in select countries - 4x Faster page loads - 80% Less Data - 50% Increase in page views http://indianexpress.com/article/technology/tech-news-technology/google-brings-in-search-lite-to-load-pages-4x-faster-on-slower-networks/
  12. 12. How Fast is your site?
  13. 13. Willing to put money on that?
  14. 14. Runtime content decisions  Reduce number of ads  Fall back to text ad placements  Eliminate tag manager or A/B testing calls  Lazy image loading  Single domain HTTP/2 Serving
  15. 15. Client-side Decisions – Javascript timings  Start of the head  performance.now()  performance.timing.responseStart - performance.timing.navigationStart  End of the head  Before each optional external resource/script (ads, widgets, whatever)  Defeats preload scanner 
  16. 16. Client-side Decisions  Slow connection?  navigator.connection.downlinkMax < 2.0  Low Battery?  navigator.getBattery()
  17. 17. Client-side Decisions – Service Worker  Observe request/response times  Dynamically adjust  Block 3rd-party requests  Alter image requests to low quality  Fetch “lite” version of modules  Track/store over time
  18. 18. Server-side Decisions – Save-Data header  HTTP Request header  save-data: on  Chrome 49+, Opera 35+, Yandex 16.2+  Disable transformations:  Cache-Control: no-transform
  19. 19. Server-side Decisions – Connection RTT  Reasonable proxy for connection speed/experience  getsockopt(fd, IPPROTO_TCP, TCP_INFO, &ti, &tisize);  ti.tcpi_rtt  Nginx: $tcpinfo_rtt (as of 1.1.18)  Apache Traffic Server: TCPInfo plugin
  20. 20. Server-side Decisions – Tracking CIDR blocks  Based on historical performance  Slow reaction time  Accounts for full experience
  21. 21. Watch out for usage shifts  YouTube Feather  Aggregate performance stats showed slower  Due to new users who could not previously use it at all  Chrome Resource Priorities Change  Aggregate performance stats showed no change  Slight increase in population  Adjusted stats showed expected 5-10% improvement in tail
  22. 22. Browser “Interventions”  Data saver mode  Mini/Proxy Browsers  Ad Blocking  Browsers becoming more agressive
  23. 23. Browser “Interventions”  https://groups.google.com/a/chromium.org/forum/#!forum/intervention-dev  Removing active scroll listeners  Blocking document.write  Throttling timers in background frames  Immediately fall back to system fonts (shipped in 49)  Lazy load images  Cleaning up navigation history  Anything that can make the web better for users, regardless of specs
  24. 24. Thank You Patrick Meenan @PatMeenan

×