Conquering the uncanny valley

Techniques for matching native app performance on the web with HTML5

by Andrew Betts, FT Labs (trib.tv / @triblondon)

The uncanny valley

We've been doing this for a while

Newsprint

• Works offline
• Portable
• Long battery life
• Can be read in bright sunlight
• Cheap
• Ubiquitous
• Bookmarkable
• Sharable
• Fast start up
• Supports clipping/saving
• Can be read in the dark
• Updates in real time
• Electronic delivery
• Search
• Personalisation
• Deep linking

Lose the constraints

• Tablet
• Phone
• Desktop
• Laptop
• TV
• Games console
• In car screen
• In flight screen
• Billboard
• Kiosk
• e-ink reader
• Hot air balloon

Smooth transitions

No pauses

Matching expectations

Network

The basics

• Async everything: defer and async on script tags
• Even async scripts can block the load event:Start loading your scripts after onload
• Reduce HTTP requests with spriting and script concatenation

Power yum yum

Source: Qualcomm

Latency by radio state

Try it on the JSFiddle.

Batching

• Aggressive batching - collect requests asynchronously:

  api.add('getStory', {'path': '/1'}, callback1);
  api.add('getStory', {'path': '/1'}, callback2);
  api.send(callback3);
  api.add('healthcheck', params, callback4);
  api.send(callback5);

• Callbacks per action and per group
• Process queues in the background

HTTP 2.0 / SPDY

• Makes this unnecessary – in theory, but:
  • Can't optimise cross-origin (third party scripts)
• Still use cases for delayed requests:
  • Offline persistence of queued requests

Images

• Typically 70-95% of web page data is images
• Use an accessible responsive images technique
• Consider high resolution, high compression for high DPI screens

Prefetch and friends

Prefetch and friends

Pre-resolve DNS hostnames for assets later in the page:

<link rel='dns-prefetch' href='hostname-to-resolve.com'>

Fetch subresources early so they're already there when needed:

<link rel='subresource' href='/path/to/some/script.js'>

Pre-fetch resources for likely future navgiations:

<link rel='prefetch' href='/most/likely/next/page.html'>

Pre-render an entire page in the background (Chrome only)

<link rel='prerender' href='/overwhelmingly/likely/next/page.html'>

Rendering

Use the tools

• Timeline
• Chrome tracing
• FPS meter

Old flexbox

IE <11, Firefox (current), Safari <7, iOS <7, Android (current), Blackberry <10

New flexbox

IE 11+, Chrome, iOS 7+, Blackberry 10+

Frame rates

Layout boundary

The area the browser has to re-layout when you change something

For more info see Wilson Page's post or Boundarizr by Paul Lewis.

Layout boundary (fixed)

Layout 'thrashing'

• DOM operations are synchronous but 'lazy' by default
• Browser will batch writes for you
• But you force it to write if you try to read something

Interleaved reads/writes

var h1 = element1.clientHeight;              <== Read (measures the element)
element1.style.height = (h1 * 2) + 'px';     <== Write (invalidates current layout)
var h2 = element2.clientHeight;              <== Read (measure again, so must trigger layout)
element2.style.height = (h1 * 2) + 'px';     <== Write (invalidates current layout)
var h3 = element3.clientHeight;              <== Read (measure again, so must trigger layout)
element3.style.height = (h3 * 2) + 'px';     <== Write (invalidates current layout)
etc.

Batching reads/writes manually

var h1 = element1.clientHeight;              <== Read
var h2 = element2.clientHeight;              <== Read
var h3 = element3.clientHeight;              <== Read
element1.style.height = (h1 * 2) + 'px';     <== Write (invalidates current layout)
element2.style.height = (h1 * 2) + 'px';     <== Write (layout already invalidated)
element3.style.height = (h3 * 2) + 'px';     <== Write (layout already invalidated)
h3 = element3.clientHeight                   <== Read (triggers layout)
etc.

Images.

Image decoding

Image decoding is probably the most expensive thing you ask the browser to do when your page loads.

• Don't load on demand (battery killer on mobile)
• Load but don't decode? No native API (yet. Ahem)
• Polyfill by downloading data: URIs
  • Base64-encode on server
  • Download with XHR
  • Insert string into <img src=''> to trigger decoding
• Con: Fools the browser, may mean you lose browser level optimisations

Hardware accelerated transforms

You need the GPU if you're going to animate a

move, scalefilter, rotate

Using accelerated animations

• Repositioning elements causes a relayout
• Accelerated animation = paint only
• First: move element to GPU layer

  .thing { -webkit-transform: translateZ(0); }

• Then: apply a transition or animation

  .thing { -webkit-transition: all 3s ease-out; }
  .thing.left { -webkit-transform: translate3D(0px,0,0); }
  .thing.right { -webkit-transform: translate3D(600px,0,0); }

This will-change

.thing { will-change: transform, opacity }

Storing data

A happy family of technologies

• Cookies
• localStorage (and sessionStorage)
• WebSQL
• IndexedDB
• HTML5 Application Cache
• Files API
• Cache API

localStorage vs IndexedDB

HTML5 Application cache

If you really want to know more, go read this and watch this

AppCache is dead, long live

ServiceWorker

It's like a server in the browser

Storage optimisation

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.

Squeeze your bits

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

Decompressing

function decompress_v1(data) {
    var i, l, n, m, out = '';
    for (i = 0, l = data.length; i < l; i++) {
        n = data.charCodeAt(i);
        m = Math.floor(n / 256);
        out += String.fromCharCode(m) + String.fromCharCode(n % 256);
    }
    return out;
}

Click delay

Perception

That's it!

Contact me:

• Email: andrew@labs.ft.com
• Twitter: @triblondon, @ftlabs

For jobs in Beijing, visit www.ftchinese.com/jobs

For jobs in London, visit labs.ft.com/jobs