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)

    View Slide

  2. 1880 1900 1920 1940 1960 1980 2000 2020

    View Slide

  3. View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  7. e need to care about
    supporting existing
    features
    as much as getting ne ones.

    View Slide

  8. The FT eb app…
    The FT eb app provides a touch optimised user
    experience ithout native code.

    View Slide

  9. …and the Economist app
    n HTML5 ebsite rapped in BlackBerry eborks for
    app orld distribution on the PlayBook.

    View Slide

  10. View Slide

  11. “The biggest mistake e made as a
    company as betting too much on
    HTML5 as opposed to native,”
    “It just asn’t ready”

    View Slide

  12. View Slide

  13. View Slide

  14. HTML5 sites can be great
    But building a good HTML5
    site is very hard.

    View Slide

  15. The basics
    Learn ho the broser optimises stuff: the
    easy ay is not alays the fastest ay.

    View Slide

  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

    View Slide

  17. var itr = 0;
    for (itr = 0; itr < 1000; itr++) {
    $('#list').append('Item '+itr+'');
    }
    var str = '';
    for (itr = 0; itr < 1000; itr++) {
    str += 'Item '+itr+'';
    }
    $('#list').html(str);
    160ms
    32ms
    Batching rites

    View Slide

  18. Selectors
    document.getElementById('a').getElementsByClassName('b')[0];
    document.querySelector('#a').querySelector('.b');
    document.querySelector('#a .b');
    12x

    View Slide

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

    View Slide

  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(''+(end-start-int)+'');
    itr++;
    if (itr > 1000) return;
    start = new Date().getTime();
    t = setTimeout(tmr, int);
    }

    View Slide

  21. setTimeout
    •  iPhone 4S, overshoot in ms:

    View Slide

  22. Storing data
    HTML5 can store data on device too, it's
    just… ell, it's complicated.

    View Slide

  23.  happy family of technologies
    •  ebSQL
    •  IndexedDB
    •  localStorage (and sessionStorage)
    •  Cookies
    •  HTML5 pplication Cache
    •  FilePI

    View Slide

  24. HTML5 application cache

    View Slide

  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

    View Slide

  26. NTIVE

    View Slide

  27. Storage optimisation
    hile e are limited by tiny quotas, e
    need to learn to live ith less.

    View Slide

  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.

    View Slide

  29. View Slide

  30. View Slide

  31. View Slide

  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  
    ShiAs  hex   53  69   6D  70   6C  65  
    UTF-­‐16   卩   浰   汥  

    View Slide

  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;  
    }  

    View Slide

  34. Uh oh
    Debugging this might be hard.

    View Slide

  35. View Slide

  36. Cache layers
    Every type of cache offers different trade
    offs. So use them all.

    View Slide

  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

    View Slide

  38. DOM caching

    ...
    ...
    ...

    View Slide

  39. Memory caching
    var pagecache = {};
    function getPage(path) {
    if (pagecache[path]) return pagecache[path];
    database.load(path, function(pagehtml) {
    pagecache[path] = pagehtml;
    });
    }

    View Slide

  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

    View Slide

  41. Server side
    •  Varnish caching pages, data, images, audio
    – token auth
    – vary headers
    •  Memcache useful for batched PI calls
    – parallel reads using multiGet

    View Slide

  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  

    View Slide

  43. Prefetching and batching
    HTTP requests are painful, so do feer of
    them and make them count.

    View Slide

  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);

    View Slide

  45. Hardare acceleration
    The key to smooth animation of
    complex layouts

    View Slide

  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); }

    View Slide

  47. View Slide

  48. lternatives
    •  TouchScroll
    •  Scrollability
    •  iScroll
    •  Overthro (uses scrollTop)

    View Slide

  49. Click delay
    Native apps react instantly. Use smart
    touch to click conversion to keep up

    View Slide

  50. View Slide

  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)

    View Slide

  52. hen you can't make it any faster…
    make it seem faster.

    View Slide

  53. View Slide

  54. Spinners and loading bars
    Not all progress feedback is created equal

    View Slide

  55. Progress feedback psychology
    •  Providing feedback makes things faster
    •  Overestimating the time remaining makes it
    go quicker
    •  Progress feedback that starts earlier finishes
    sooner

    View Slide

  56. Donloading!
    Oh noes! Trying
    RELLY hard!
    Bah.
    e give up.

    View Slide

  57. Progressive rendering
    Sho something! Quick!

    View Slide

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

    View Slide

  59. View Slide

  60. “Don’t build native apps,
    build eb apps”
    -­‐  Tim  Berners-­‐Lee  

    View Slide

  61. Thanks
    andre@labs.ft.com
    @triblondon, @FTLabs
    Do you ant to build this stuff? Join in.
    [email protected]
    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  
     

    View Slide