Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Escaping the uncanny valley (Velocity 2012)

Escaping the uncanny valley (Velocity 2012)

Techniques for matching native app performance on the web with HTML5

Andrew Betts

October 04, 2012
Tweet

More Decks by Andrew Betts

Other Decks in Technology

Transcript

  1. Escaping the uncanny valley Techniques for matching native app performance

    on the eb ith HTML5 ndre Betts (@triblondon) Director, FT Labs (@ftlabs)
  2. 1880 1900 1920 1940 1960 1980 2000 2020

  3. None
  4. orks offline Portable Long battery life Can be read in

    bright sunlight Cheap Ubiquity Bookmarking Sharing Nesprint Fast start up Clipping/saving Can be read in the dark Updates in real time Electronic delivery Search Personalisation Deep linking
  5. orks offline Portable Long battery life Can be read in

    bright sunlight Cheap Ubiquity Bookmarking Sharing ‘Traditional’ eb Fast start up Clipping/saving Can be read in the dark Updates in real time Electronic delivery Search Personalisation Deep linking
  6. orks offline Portable Long battery life Can be read in

    bright sunlight Cheap Ubiquity Bookmarking Sharing pps Fast start up Clipping/saving Can be read in the dark Updates in real time Electronic delivery Search Personalisation Deep linking
  7. e need to care about supporting existing features as much

    as getting ne ones.
  8. The FT eb app… The FT eb app provides a

    touch optimised user experience ithout native code.
  9. …and the Economist app n HTML5 ebsite rapped in BlackBerry

    eborks for app orld distribution on the PlayBook.
  10. None
  11. “The biggest mistake e made as a company as betting

    too much on HTML5 as opposed to native,” “It just asn’t ready”
  12. None
  13. None
  14. HTML5 sites can be great But building a good HTML5

    site is very hard.
  15. The basics Learn ho the broser optimises stuff: the easy

    ay is not alays the fastest ay.
  16. DOM operations •  re slo. But you kne that. • 

    Simple rules: – Batch your rites – Don't interleave reads and rites – Do as much in CSS as possible
  17. var itr = 0; for (itr = 0; itr <

    1000; itr++) { $('#list').append('<li>Item '+itr+'</li>'); } var str = ''; for (itr = 0; itr < 1000; itr++) { str += '<li>Item '+itr+'</li>'; } $('#list').html(str); 160ms 32ms Batching rites
  18. Selectors document.getElementById('a').getElementsByClassName('b')[0]; document.querySelector('#a').querySelector('.b'); document.querySelector('#a .b'); 12x

  19. setTimeout •  Is unpredictable •  Test: fire a timer every

    50ms
  20. setTimeout var itr = 0, int = 50; var t

    = setTimeout(tmr, int), start = new Date().getTime(); function tmr() { var end = new Date().getTime(); $('#results').append('<li>'+(end-start-int)+'</li>'); itr++; if (itr > 1000) return; start = new Date().getTime(); t = setTimeout(tmr, int); }
  21. setTimeout •  iPhone 4S, overshoot in ms:

  22. Storing data HTML5 can store data on device too, it's

    just… ell, it's complicated.
  23.  happy family of technologies •  ebSQL •  IndexedDB • 

    localStorage (and sessionStorage) •  Cookies •  HTML5 pplication Cache •  FilePI
  24. HTML5 application cache

  25. Current best practice •  Use appcache sparingly – Fonts, sprites, one

    master, and a fallback entry – CSS, HTML, JS in localStorage – Other approaches: see Jake rchibald •  localStorage for speed •  Database for capacity
  26. NTIVE

  27. Storage optimisation hile e are limited by tiny quotas, e

    need to learn to live ith less.
  28. Text encoding ‘compression’ •  JavaScript internally uses UTF-16 for text

    encoding •  Great idea for processing: fast string operations, full support for Unicode BMP •  Terrible idea for storage of English text or base-64 encoded images.
  29. None
  30. None
  31. None
  32. SCII packed into UTF-16 Text   S   i  

    m   p   l   e   Decimal   83   105   109   112   108   101   As  binary   01010011   01101001   01101101   01110000   01101100   01100101   Shi<ed   01010011  01101001   01101101  01110000   01101100  01100101   As  hex   53  69   6D  70   6C  65   UTF-­‐16   卩   浰   汥  
  33. SCII packed into UTF-16 function  compress(s)  {    var  i,

     l,  out='';    if  (s.length  %  2  !==  0)  s  +=  '  ';    for  (i  =  0,  l  =  s.length;  i  <  l;  i+=2)  {      out  +=  String.fromCharCode((s.charCodeAt(i)<<8)  +                s.charCodeAt(i+1));    }    return  out;   }  
  34. Uh oh Debugging this might be hard.

  35. None
  36. Cache layers Every type of cache offers different trade offs.

    So use them all.
  37. DOM Memory Cache server Broser storage pplication caching Database Hide/sho

    elements already in DOM Instant – paint only. High memory footprint JavaScript variables Very quick – DOM rite + paint. ebSQL/IndexedDB or localStorage I/O on localStorage very fast. DB much sloer but async Varnish / Squid etc HTTP delay, fast read from cache, infinite storage Memcache pplication overhead, added flexibility, smaller components, MySQL / PostgreSQL / Couch / Mongo etc Ultimate master repository
  38. DOM caching <div class='on-library' data-current='library'> <div class='library'>...</div> <div class='contents'>...</div> <div

    class='article'>...</div> </body> el.classList.remove('on-'+el.getAttribute('data-current')); el.setAttribute('data-current', state.type); el.classList.add('on-' + state.type);
  39. Memory caching var pagecache = {}; function getPage(path) { if

    (pagecache[path]) return pagecache[path]; database.load(path, function(pagehtml) { pagecache[path] = pagehtml; }); }
  40. Memory caching •  Consider a cache eviction policy – Least recently

    added (easy) – Least recently used (better, but is it orth it?) •  Metadata? Cache objects not strings •  Merge dynamic data into cache on read
  41. Server side •  Varnish caching pages, data, images, audio – token

    auth – vary headers •  Memcache useful for batched PI calls – parallel reads using multiGet
  42. Tradeoffs Example  render  latency  (3G   network)   Effec7ve  

      capacity   DOM   2ms  (paint)   A  few  hundred  nodes   JavaScript  memory   10ms  (layout  +  paint)   5MB   Browser  storage   70ms  (read  +  layout  +  paint)   50MB   Network  cache   300ms  (network  +  layout  +   paint)   Infinite   Memcache/DB   400ms  (backend  +  network  +   layout  +  paint)   Infinite  
  43. Prefetching and batching HTTP requests are painful, so do feer

    of them and make them count.
  44. One HTTP request! •  ggressive batching - collect requests asynchronously:

    •  Callbacks per action and per group api.add('getStory', {'path': '/1'}, callback1); api.add('getStory', {'path': '/1'}, callback2); api.send(callback3); api.add('healthcheck', params, callback4); api.send(callback5);
  45. Hardare acceleration The key to smooth animation of complex layouts

  46. Using accelerated animation •  Repositioning elements causes a relayout • 

    ccelerated animation = paint only •  First: turn on acceleration •  Then: apply a transition .thing { -webkit-transform: translateZ(0); } .thing { -webkit-transition: all 3s ease-out; } .thing.left { -webkit-transform: translate3D(0px,0,0); } .thing.right { -webkit-transform: translate3D(600px,0,0); }
  47. None
  48. lternatives •  TouchScroll •  Scrollability •  iScroll •  Overthro (uses

    scrollTop)
  49. Click delay Native apps react instantly. Use smart touch to

    click conversion to keep up
  50. None
  51. Fastclick •  github.com/ftlabs/fastclick •  Removes 300ms delay on touch • 

    Programmatic clicks aren't quite the same - e handle it here e can (eg apply focus)
  52. hen you can't make it any faster… make it seem

    faster.
  53. None
  54. Spinners and loading bars Not all progress feedback is created

    equal
  55. Progress feedback psychology •  Providing feedback makes things faster • 

    Overestimating the time remaining makes it go quicker •  Progress feedback that starts earlier finishes sooner
  56. Donloading! Oh noes! Trying RELLY hard! Bah. e give up.

  57. Progressive rendering Sho something! Quick!

  58. Still rendering sections... and the image... and the rest of

    the article!
  59. None
  60. “Don’t build native apps, build eb apps” -­‐  Tim  Berners-­‐Lee

     
  61. Thanks andre@labs.ft.com @triblondon, @FTLabs Do you ant to build this

    stuff? Join in. jobs@labs.ft.com Image  credits::     hYp://cdn3.worldcarfans.co/2008/2/medium/9080214.017.Mini1L.jpg,    hYp://www.netbasic.com/blog/2008/10/mini-­‐car-­‐parking-­‐fail,  hYp://runningstopsigns.files.wordpress.com/ 2011/04/smart-­‐car.jpg