Why performance matters: Measuring your websites performance

Why performance matters: Measuring your websites performance

A brief introduction to client-side performance. How to measure your websites performance bottlenecks. Followed by a few tips and best practices to overcome common client-side performance issues and some examples of how we are tackling these issues at the Guardian.

276c149f793de9af4e98991ed52ff874?s=128

Patrick Hamann

April 24, 2013
Tweet

Transcript

  1. Measuring your websites performance Patrick Hamann Front-end London - April

    2013 Why performance matters
  2. Who am I? • @patrickhamann • Client-side developer • Performance

    geek
  3. Who I work for

  4. What am I going to cover?

  5. What am I going to cover? • Why performance matters

  6. What am I going to cover? • Why performance matters

    • How to measure your websites performance bottlenecks
  7. What am I going to cover? • Why performance matters

    • How to measure your websites performance bottlenecks • Myths, tips and best practices
  8. Ideal load time?

  9. < 3 secs

  10. Reality:

  11. 7.25 secs

  12. Page weight is increasing YoY Source: HTTPArchive

  13. 1.4 Mb

  14. User load time expectations Source: Web Performance Today

  15. 71% of users want your mobile site to load as

    fast as the desktop equivalent. Source: Gomez
  16. "We made the new platform 60% faster and this resulted

    in a 14% increase in donation conversions." Kyle Rush - Obama Campaign
  17. Measuring performance Tools

  18. The critical path Network Parse Paint

  19. Waterfall analysis

  20. None
  21. None
  22. Size

  23. Size Latency

  24. Size Latency Download

  25. Size Latency Download DOMContentReady

  26. Size Latency Download DOMContentReady Load

  27. WebPageTest.org

  28. WebPageTest.org

  29. WebPageTest.org

  30. WebPageTest.org

  31. WebPageTest.org

  32. WebPageTest.org

  33. WebPageTest : Comparison

  34. WebPageTest : Video

  35. PROBLEMS

  36. Common performance bottlenecks • Latency • Payload • Caching •

    Paint
  37. Latency • Time to first byte (TTFB) • Incurred on

    every request • Much worse on mobile • CDN’s • The closer to the user, the lower the latency • Edge side compression • HTML ?!
  38. Reduce payload: 101 • Compression • GZip (mod_deflate mod_pagespeed) •

    Concatenate CSS/JS • Defer to load event (lazy-load) • Conditional loading • Cache
  39. Reduce payload: CSS • Only resource that should block the

    parser! • Load only bare minimum for page chrome • Conditionally load the rest • Browsers download CSS they don't need : e.g. print, tv, device-ratio... • Serve of same host - no DNS lookup • Inline ?*&%!
  40. None
  41. WTF!

  42. Reduce payload: Images • Compression: • Photoshop 60% > ImageOptim

    25/70% • Progressive JPEGs • WebP • Base64 icons or icon fonts • Clean SVGs • No images at all?
  43. Progressive JPEGs Source: Performance calendar

  44. WebP - Content negotiation WebP lossless images are 26% smaller

    in size compared to PNGs. WebP lossy images are 25-34% smaller in size compared to JPEG Source: NetDNA blog
  45. Caching • Far-future cache headers • Invalidation • AppCache is

    broken :( • Mobile is harder • Smaller shared cache • Stuff critical assets in localStorage
  46. None
  47. WTF!

  48. Render • Don't use setTimeout • Use request animation frame

    instead. • CSS Animations get over these issues. • Avoid recalculation • Bisecting slow CSS styles & elements
  49. Render: Timeline Source: Addy Osmani

  50. Continuous paint mode Source: HTML5 Rocks

  51. R.U.M

  52. Navigation timing API Source: W3C

  53. Navigation timing API Source: W3C

  54. None
  55. None
  56. Google Analytics: Site Speed

  57. HAR

  58. None
  59. Automation: PhantomJS & YSlow Source: Ilya Grigorik

  60. Automation: HAR Storage Source: https://code.google.com/p/harstorage/

  61. Automation: CI Integration Build Test Deploy Users Monitor

  62. Automation: CI Integration Build Test Deploy Users Monitor YSlow

  63. The Future

  64. The Future • SPDY/HTTP 2.0

  65. The Future • SPDY/HTTP 2.0 • Responsive images

  66. The Future • SPDY/HTTP 2.0 • Responsive images • <image

    defer/>
  67. The Future • SPDY/HTTP 2.0 • Responsive images • <image

    defer/> • Application controller
  68. The Future • SPDY/HTTP 2.0 • Responsive images • <image

    defer/> • Application controller • WebP
  69. The Future • SPDY/HTTP 2.0 • Responsive images • <image

    defer/> • Application controller • WebP • Client-hints
  70. The Future • SPDY/HTTP 2.0 • Responsive images • <image

    defer/> • Application controller • WebP • Client-hints • RESS?
  71. It sounds easy... • It’s not • Requires a lot

    of dev time • Maintenance and upkeep • How do you track regression?
  72. Performance budget • Optimize an existing feature or asset •

    Remove an existing feature or asset • Don’t add the new feature or asset
  73. PERFORMANCE FIRST

  74. Thank you! @patrickhamann Front-end London - April 2013 We’re hiring!