Skip to content

Instantly share code, notes, and snippets.

@roc

roc/p-hamann-notes.md

Created March 19, 2014 17:45
Show Gist options
  • Save roc/9647254 to your computer and use it in GitHub Desktop.
Save roc/9647254 to your computer and use it in GitHub Desktop.
Download ZIP
Performance Notes from Patrick Hamann of the Guardian (19/03/2014)
Raw
p-hamann-notes.md

Performance Notes with Patrick Hamann

https://github.com/guardian/frontend

Everything comes from content api at guardian. ('service oriented architecture')

Rendering engine flow (used diagram a bit like http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/image008.jpg)

Javascript blocks because of e.g. document.write - can rewrite the DOM at any point -- want to get javascript out of the rendering flow as much as possible using things like async and defer, putting at the bottom of the page etc

'Swimlaning'

  • Each section of the website is its own application and server
  • Deploy individually
  • If one application fails, the rest continue unharmed
  • Enforce one blocking request for 'core content'

CSS

  • concept of 'critical css'
  • this is inlined into the main html content
  • Browsers will block until they have loaded a CSS element
  • load in global css with ajax, then, if possible add it into localStorage ~500ms gains --> proven with filmstrip ~600ms gains in DOMContentReady
  • First 14k enough to start painting! Keep inline css below 4k or below html+css <14k threshold

Cons of this: having separate

Web Fonts

  • 'Egyptian' typeface very important
  • Detect feature support
  • Base64 encode the binary font files
    • Batch all fonts as strings in one request
  • Fetch JSON assets async
  • Cache in localStorage for next request
    • Mobile HTTP cache in unreliable
  • Small performance hit from unencoding base64
  • Browsers de-prioritise unencoding base64 https://github.com/ahume/webfontjson
  • Width threshold for loading in fonts (lower than 980 loses some fonts)

Responsive Images

Monitoring

  • Navigation timing API window.navigation.timing and boomerang.js - https://github.com/yahoo/boomerang
  • Asset monitoring
    • static monitoring << can set threshold alerting for big/small images
    • gives week on week changes

Speedcurve usage

  • good for getting product owners thinking more about performance

WebPageTest Script (from etsy) https://github.com/etsy/wpt-script

Testing

  • HARD!
  • Every new feature must be justified
    • Optimise an existing feature
    • Remove an existing feature
    • Don't add the new feature
  • Expiring features dashboard - when unused, can be removed
  • Performance first

Future

  • Resource Priorities API

    • w3c draft spec
    • allows devs to give user agent hints on the dl priority of a resource
    • unblock non-critical assets

    <link rel='stylesheet' type='text/css' lazyload />

  • Client hints

    https://github.com/igrigorik/http-client-hints

    • IEFT draft
    • New 'CH' client hint HTTP header

  • SPDY/HTTP 2.0

  • Final draft end of 2014

  • One connection per origin

  • Each single connection can carry any number of bidirectional streams, thus allowing multiplexing

  • Request prioritisation

  • Eliminates unnecessary latency

  • Chrome extension to tell you whether site uses SPDY

Questions

What kind of users did you survey? //

How did you test the speed gains of inlining CSS in the header? What kind of guidelines do you have for inline css vs 'global'? Ophan — how did you find the time to write it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment