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
Tweet

More Decks by Matt Bailey

Other Decks in Technology

Transcript

  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)