Embracing the Network — DIBI Conf, March 2016

Embracing the Network — DIBI Conf, March 2016

This version of the talk was originally presented at DIBI Conf in Edinburgh, Scotland on the 18th March 2016.

The network is intrinsically unreliable. More so, the network is out of your control as a developer. Therefore, we must design systems which embrace the unpredictability of the network and defend against it all costs. How can you prioritise the delivery of your core content? What best-practices can you use to optimise your assets? How can we design interfaces which adapt and respond to changing network conditions? And finally, how are new APIs such as ServiceWorker changing the way we think about the network?

During this talk Patrick will share his experiences delivering high-performance websites to millions of users over the past 3 years at The Guardian and Financial Times. Which – most importantly – are resilient to the network.

276c149f793de9af4e98991ed52ff874?s=128

Patrick Hamann

March 26, 2016
Tweet

Transcript

  1. Embracing the network Patrick Hamann — DIBI, March 2016
 @patrickhamann

    Modern techniques for building resilient front ends !
  2. None
  3. None
  4. Why?

  5. <a href=“http://next.ft.com”>FT.com</a>

  6. None
  7. None
  8. None
  9. https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing 1. The network is reliable. 2. Latency is zero.

    3. Bandwidth is infinite. 4. The network is secure. 5. Topology doesn't change. 6. There is one administrator. 7. Transport cost is zero. 8. The network is homogeneous. 
 The fallacies of distributed computing 
 PETER DEUTSCH — SUN MICROSYSTEMS, 1994
  10. Multiple points of failure Dmytrii Shchadei — http://www.slideshare.net/metrofun/reduce-mobile-latency " #

    # # $ Internal latency Firewalls, Load Balancers, Servers % Internet routing latency CDNs, ISPs, Caches, Proxies Control plane latency ~600ms on average UK 3G connection ~200ms
  11. Title Text

  12. Title Text Request Map: http://requestmap.webperf.tools/

  13. Baking in the assumption that everything can and will fail

    leads you to think differently about how you solve problems. 
 SAM NEWMAN — BUILDING MICROSERVICES, O’REILLY 2015 http://shop.oreilly.com/product/0636920033158.do
  14. 1. Testing and monitoring failure 2. Designing for failure 3.

    Embracing failure 4. The future
  15. Testing for failure

  16. A single point of failure (SPOF) is a part of

    a system that, if it fails, will stop the entire system from working. SPOFs are undesirable in any system with a goal of high availability or reliability, be it a business practice, software application, or other industrial system. https://en.wikipedia.org/wiki/Single_point_of_failure
  17. http://uk.businessinsider.com/doubleclick-for-publishers-down-2014-11

  18. http://uk.businessinsider.com/doubleclick-for-publishers-down-2014-11

  19. http://uk.businessinsider.com/doubleclick-for-publishers-down-2014-11 http://www.stevesouders.com/blog/2010/06/01/frontend-spof/

  20. None
  21. https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

  22. Facebook 2G Tuesdays - www.businessinsider.com.au/facebook-2g-tuesdays-to-slow-employee-internet-speeds-down-2015-10?op=1

  23. User Timing API http://www.w3.org/TR/resource-timing/ window.performance.mark(“fonts-loaded“); <script> window.performance.mark("css-start"); </script>
 <link rel="stylesheet"

    href="/main.css" /> <link rel="stylesheet" href="/fonts.css" /> <script> performance.mark("css-end"); performance.measure("css-loading", "css-start", "css-end"); </script>
  24. None
  25. None
  26. • Test 1st and 3rd party dependencies for SPOFs •

    Use network shaping to simulate mobile conditions • Monitor metrics contextual to your business • Mark and measure your custom events • Alert if metrics pass their thresholds/budgets
  27. 1. Testing and monitoring failure 2. Designing for failure 3.

    Embracing failure 4. The future
  28. Designing for failure

  29. None
  30. None
  31. None
  32. None
  33. None
  34. Delay User perception 0 - 100ms Instant 100 - 300ms

    Small perceptible delay 300 - 1000ms Machine is working 1000+ ms Likely mental context switch 10,000+ ms Task is abandoned
  35. None
  36. None
  37. None
  38. • Respond within a 1000ms • Avoid loading spinners •

    Consider using skeleton screens • Re-use familiar UI patterns within error messaging • Use human friendly copy, especially in error states • Visualise the state of the network
  39. 1. Testing and monitoring failure 2. Designing for failure 3.

    Embracing failure 4. The future
  40. Embracing failure

  41. None
  42. Loading fonts https://tabatkins.github.io/specs/css-font-rendering/ Chrome Opera Safari Firefox IE Timeout 3s

    3s no timeout 3s 0 Fallback Yes Yes n/a Yes Yes Swap Yes Yes n/a Yes Yes
  43. CSS Font Rendering Controls Module https://tabatkins.github.io/specs/css-font-rendering/ @font-face { font-family: 'MyShinyFont';

    src: url('http://fonts.ft.com/async.woff2'); font-display: swap; } @font-face { font-family: 'MyBlockingFont'; src: url: url('http://fonts.ft.com/blocking.woff2'); font-display: block; }
  44. & ServiceWorker ' ( %

  45. & ServiceWorker ' ( % 

  46. & ServiceWorker ' ( %

  47. Cache only self.addEventListener('install', function(event) { event.waitUntil( caches.open(cacheName).then(function(cache) { return cache.addAll([

    ‘http://fonts.ft.com/fonts.css', 'http://fonts.ft.com/serif', 'http://fonts.ft.com/sans-serif' ]); }) ); }); https://jakearchibald.com/2014/offline-cookbook
  48. Cache only https://jakearchibald.com/2014/offline-cookbook self.addEventListener('fetch', function(event) { // If this is

    a request for font file if (/fonts\.ft\.com/.test(event.request)) { // If a match isn't found in the cache, the response // will look like a connection error event.respondWith(caches.match(event.request)); } });
  49. X Cache only & ' ( %  ( X

    ( ( '
  50. Title Text https://jakearchibald.com/2014/offline-cookbook

  51. Stale-while-revalidate self.addEventListener('fetch', function(event) { // Get stale from cache event.respondWith(

    caches.open(cacheName).then(function(cache) { return cache.match(event.request).then(function(response) { // If in cache relvalidate var network = fetch(event.request).then(function(response){ if(response.status < 400) { cache.put(event.request, response.clone()); } }); // Return stale or network if none return response || network; }); }) ); }); https://jakearchibald.com/2014/offline-cookbook
  52. Stale-while-revalidate & ' ( %  (

  53. Stale-if-error self.addEventListener('fetch', function(event) { // Always fetch response from the

    network event.respondWith( fetch(event.request).then(function(response) { // If we received an error response if(!response.ok) { // If we received an error response return caches.match(event.request) } else { // Response was healthy so update cached version cache.put(event.request, response.clone()); return response; } }) ); });
  54. Timeouts & ' ( % X * X

  55. Timeout race function timeout(delay) { return new Promise(function(resolve, reject) {

    setTimeout(function() { resolve(new Response('', { status: 408, statusText: 'Request timed out.' })); }, delay); }); } self.addEventListener('fetch', function(event) { // Attempt to fetch with timeout event.respondWith(Promise.race([timeout(2000), fetch(event.request)])); });
  56. Dead letter queue & ' ( % X + offline

    online
  57. • Pre-fetch and cache critical resources • Serve stale and

    revalidate • Serve stale if error • Always use timeouts • Queue and batch requests • Treat the network as an enhancement!
  58. The future

  59. Offline Network unavaliable

  60. Push notifications

  61. Background sync navigator.serviceWorker.ready.then(function(registration) { regitration.periodicSync.register({ tag: 'get-latet-news', // default: ''

    minPeriod: 12 * 60 * 60 * 1000, // default: 0 powertState: 'avoid-draining', // default: 'auto' networkState: 'avoid-cellular' // default: 'online' }).then(function(periodicsyncReg) { // success }, function() { // failure }); });
  62. 1. Testing and monitoring failure 2. Designing for failure 3.

    Embracing failure 4. The future
  63. Thanks @patrickhamann
 speakerdeck.com/patrickhamann github.com/Financial-Times ! , - Do you want

    to help build this stuff? Join in.