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

Workshop: Making Responsive Websites Fast

Workshop: Making Responsive Websites Fast

Summary of what we learned at the @LDNWebPerf workshop by https://twitter.com/guypod from Akamai, on how to make RWD sites fast!

(Used for an internal presentation)

Matt Bailey

May 20, 2015

More Decks by Matt Bailey

Other Decks in Technology


  1. • Mobile is big (1/3 of all traffic)! • Original

    approach - do nothing • Then, dedicated domains (eg. m.domain.com) • Now, Responsive Web Design The Mobile Web
  2. Responsive Web Design • Google recommends it • Adoption is

    fast on the increase • Challenge: • Different devices, same download • More bytes-per-pixel on smaller screens
  3. RWD Problems • Very few RWD sites optimise for performance

    • RWD sites generally heavier than mdot sites • RWD sites generally heavier to process than mdot sites • Example: • Old CNN site - Adaptive mdot, 571KB, 15s • New CNN site - RWD, 2.9MB, 41.9s • Load time matters!
  4. Problem: Over Downloading • Download and Shrink - the same

    image is used on all devices and just shrunk for smaller screens
  5. Solution: Responsive Images • ‘srcset’ - suggests to the browser

    which images to use • <picture> element - forces the browser to use certain images (art direction) • Browser support is good, but Polyfills are available for older browsers
  6. Problem: Download And Hide • Often images are hidden on

    ‘mobile’ views • The problem is that the browser still has to download them
  7. Solution: Conditional Loading (Client-Side) • Use placeholders (1px.gif), then swap

    the ‘src’ if the image is not set to ‘display: none;’ • Or check for screen size, orientation changes etc. • You can also use the <picture> element to achieve a similar effect
  8. Problem: Over Downloading CSS • Most sites have just one

    CSS file • Fewer requests, but wasteful bytes
  9. Solution: Conditional loading • You could have one file for

    each ‘breakpoint’ • Conditionally load each file using media queries • All files are still downloaded, but deferred so not render blocking • or JavaScript (async) • Design mobile first
  10. Solution: Critical Rendering Path • Inline critical CSS in the

    head • Load non-priority CSS asynchronously • Without the CSSOM first paint is blocked
  11. REsponsive + Server Side (RESS) • Server conditionally assembles design

    response • Doesn’t replace RWD • Tuned for families families of devices (http:// web.wurfl.io/) • Use cookies, get user’s device data, include/ignore blocks • Can’t add a cookie using JavaScript because it won’t be set on first view
  12. RESS With Edge Side Includes (ESI) • Another form of

    conditional loading • Benefit: Can be placed directly in templates (looks like XML) • Works with EDC, eg. detect user’s screen width, then conditionally load block • Other providers offer (limited) ESI support, eg. Varnish
  13. Problem: Image File Sizes • A LOT of image variants

    are required: • Thousands of products • Multiple images per product • Multiple breakpoints • Standard def and High def (Retina) • Versions optimised for browser type • Versions optimised for poor network • = LOTS of images to manage! • Image transcoding takes time (especially on the first-run)
  14. Solution: Better file formats • JPEGXR (IE) • WebP (Chrome,

    Android, Opera) • JPEG2000 (iOS, Safari) • JPEGXR and WebP can save over 30% compared to a standard JPEG
  15. • Akamai Image Manager for delivery-time selection • Use ‘srcset’

    to load the right sized images • Use <picture> to load the right image format • Akamai Image Manager can also adjust image compression based on network performance
  16. Problem: Third-Party Scripts • On the increase • Can pose

    a risk: SPOF (Single Point Of Failure)