The State of the Web

Web performance is a crucial pillar of user experience, yet it’s still the underdog. Oftentimes there’s no budget for tooling or development and metrics are only being checked after features have hit production. As the builders of the Web it’s our job to create not only the best, but also the fastest and most accessible Web for everyone. Let’s acknowledge our privilege and learn to build a fast an accessible Web for everyone. This talk will set the necessary context for understanding why performance is important. We will go through most and least important metrics, how they’re being calculated, setting meaningful performance budgets and tooling. You’ll leave with comprehensive and actionable performance knowledge.

Transcript

1. State of the Web
   Presented by @fox
   

   View Slide

2. The Internet is growing exponentially,
   but we fail to reflect on the greater picture.
   

   View Slide

3. We haven’t been building with empathy,
   situation variability awareness, let alone
   performance in mind.
   

   View Slide

4. 51%
   of 7 billion people have access to the Internet
   Read: Q2 2017 Global Digital Statshot
   

   View Slide

5. 7 mb/s
   is the average network speed worldwide
   Read: Akamai's State of the Internet Report for Q1 2017
   

   View Slide

6. 93%
   of Internet users go online via mobile devices
   Read: Q2 2017 Global Digital Statshot
   

   View Slide

7. Read: Beyond the Bubble: The Real World Performance
   0
   3
   7
   10
   13
   Brazil Indonesia India Germany
   Number of hours worked for 500 MB of data
   

   View Slide

8. 3 mb
   is the average site size
   Please note that averages aren’t statistically accurate.
   Read Ilya Grigorik’s “The average page is a myth”.
   

   View Slide

9. Daily application updates can easily yield 700 MB downloads.
   

   View Slide

10. As technologists often we find ourselves
    in the position of privilege.
    

    View Slide

11. If we’re building the web platform from the
    position of privilege and lack of empathy, it
    results in exclusionary, subpar experiences.
    

    View Slide

12. Optimising all assets
    

    View Slide

13. One of the ways to significantly improve
    performance starts with understanding how
    the browser analyses and serves assets.
    

    View Slide

14. HTML
    100 ms 200 ms 300 ms 400 ms 500 ms 600 ms 700 ms
    CSS
    JAVASCRIPT
    FONT
    

    View Slide

15. A critical request contains assets
    that are necessary to render the content
    within the users’ viewport.
    

    View Slide

16. Lead image
    Logo
    Web font
    Which assets are critical?
    

    View Slide

17. 
    Fetch immediately
    Type of an asset
    

    View Slide

18. The Critical Request by Ben Schwarz
    

    View Slide

19. Enabling request priority in Chrome
    

    View Slide

20. 1. Cache aggressively
    2. Enable server-side compression
    3. Prioritise critical assets
    4. Use content delivery networks
    Performance checklist
    

    View Slide

21. Optimising images
    

    View Slide

22. Images can account for most of transferred
    payload, which is why imagery optimisation
    can yield the biggest performance wins.
    

    View Slide

23. How do I pick the right format?
    

    View Slide

24. Vector
    Resolution independent, usually significantly smaller in
    size. Perfect for logos, iconography and simple assets
    comprising of basic shapes (lines, polygons, circles and
    points).
    Raster
    Offers much more detailed results.
    Ideal for photographs.
    

    View Slide

25. JPEG imagery with many colours (photos)
    PNG-8 imagery with a few colours
    PNG-24 imagery with partial transparency
    GIF animated imagery
    Video for more lightweight GIFs ()
    Read: Choosing an Image Format
    

    View Slide

26. Coach designers on picking and exporting
    the most suitable format.
    

    View Slide

27. WebP is 25-34% smaller than other formats.
    It can be safely used with fallbacks.
    Read: A new image format for the Web
    

    View Slide

28. brew install webp
    cwebp -q source.png -o output.webp
    

    View Slide

29. Using efficient image formats doesn’t warrant
    skipping post-processing.
    We need to optimise.
    

    View Slide

30. ImageOptim SVGO
    

    View Slide

31. Guetzli can produce up to 35% smaller JPEGs
    (but be wary of its speed).
    See: Guetzli on Github
    

    View Slide

32. We need to serve the right resolutions
    and file types to the right devices.
    

    View Slide

33. The srcset attribute
    sizes="(max-width: 320px) 100vw,

    (max-width: 480px) 80vw,

    800px"

    src="cat-800w.jpg" alt="Cat"> 

    Condition (media query)
    Width relative to viewport
    Width of the image source
    

    View Slide

34. The picture element
    

    

    srcset="small.jpg 1x, small-hd.jpg 2x">

    

    

    Condition (media query)
    Image source to use
    Read: Responsive Images 101
    

    View Slide

35. CDNs can take out a lot of complexity
    from serving responsive, optimised assets
    on image-heavy sites.
    

    View Slide

36. 1. Choose the right format
    2. Use vector wherever possible
    3. Reduce the quality if change is unnoticeable
    4. Experiment with new formats
    5. Optimise with tools and algorithms
    6. Learn about srcset and picture
    7. Use an image CDN
    Performance checklist
    

    View Slide

37. Optimising web fonts
    

    View Slide

38. 68%
    of websites use web fonts
    Read: HTTP Archive Interesting Statistics
    

    View Slide

39. View Slide

40. There are four web font formats.
    It’s safe to use WOFF2 with a WOFF fallback.
    

    View Slide

41. WOFF2 font files are 30% smaller.
    

    View Slide

42. @font-face {

    font-family: Post Grotesk;

    src: url('/fonts/Post-Grotesk.woff2') format('woff2'),

    url('/fonts/Post-Grotesk.woff') format('woff'); 

    } 

    Always specify the format
    

    View Slide

43. Limit the number of typefaces,
    font weights and styles.
    Read: Weighing Aesthetics and Performance
    

    View Slide

44. Consider unicode-range subsetting to split
    large fonts (proceed with caution).
    

    View Slide

45. npm install -g glyphhanger
    fontsquirrel.com/tools/webfont-generator
    

    View Slide

46. Fonts are render-blocking,
    often causing Flash of Invisible Text (FOIT).
    

    View Slide

47. We need a font loading strategy to prevent
    users from not being able to access content.
    Read: A Comprehensive Guide to Font Loading Strategies
    

    View Slide

48. @font-face {

    font-family: Post Grotesk;

    src: url('/fonts/Post-Grotesk.woff2') format('woff2'),

    url('/fonts/Post-Grotesk.woff') format(‘woff');
    font-display: swap;

    } 

    Show fallback until
    web font is ready
    

    View Slide

49. npm install webfontloader
    npm install fontfaceobserver
    

    View Slide

50. Font loading strategy in action
    

    View Slide

51. 1. Choose the right format
    2. Audit the font selection
    3. Use Unicode-range subsetting (carefully!)
    4. Establish a font loading strategy
    Performance checklist
    

    View Slide

52. Optimising JavaScript
    

    View Slide

53. There’s a much more sinister performance
    bottleneck hidden behind our beloved
    JavaScript than its size.
    

    View Slide

54. Unpacked JavaScript can become 2-3x bigger
    than what we’ve sent down the wire.
    Read: JavaScript start-up performance
    

    View Slide

55. Parse and compile times are so high it takes
    8 seconds to reach an interactive state.
    

    View Slide

56. Package managers can easily obscure
    the size of our dependencies.
    

    View Slide

57. npm install --save-dev webpack-bundle-analyzer
    

    View Slide

58. Serve only necessary JavaScript
    based on context and routing.
    

    View Slide

59. Read: Webpack: Guide to code-splitting
    If using Webpack: enable code splitting and
    dynamic imports.
    

    View Slide

60. When starting a project, consider lightweight
    framework alternatives.
    

    View Slide

61. 1. Monitor how much JavaScript is delivered
    2. Get rid of unnecessary dependencies
    3. Implement code splitting
    4. Consider framework alternatives
    Performance checklist
    

    View Slide

62. Tracking performance
    

    View Slide

63. 1. Leverage user-centric metrics
    2. Set performance budgets
    3. Monitor continuously
    4. Build performance awareness and empathy
    Performance checklist
    

    View Slide

64. Great performance metrics aim to be as close
    to portraying users’ experience as possible.
    

    View Slide

65. Delivery-oriented metrics User-centric metrics
    Speed Index First Paint
    onLoad First Meaningful Paint
    onDomLoaded Visually Complete
    onContentLoaded Time to Interactive
    

    View Slide

66. First Paint
    First Contentful Paint
    First Meaningful Paint Visually complete
    

    View Slide

67. Metrics can quickly become confusing.
    Without actionable targets, it’s easy to lose
    track of what we’re trying to achieve.
    

    View Slide

68. Set attainable performance budgets.
    performancebudget.io
    browserdiet.com/calories/
    

    View Slide

69. Monitoring performance shouldn’t be manual.
    

    View Slide

70. Use Google Lighthouse
    npm install -g lighthouse
    

    View Slide

71. Try out Calibre
    calibreapp.com
    

    View Slide

72. Tracking performance is a shared
    responsibility: make the data accessible.
    

    View Slide

73. Caring about performance shouldn’t be
    a business goal.
    …but if you need to sell it through possible revenue and engagement gains:
    It’s about fundamental empathy.
    

    View Slide

74. As technologists, it’s our responsibility to not
    hijack attention and time.
    timewellspent.io
    We need to be conscious of human focus.
    

    View Slide

75. Let’s build a better, more
    mindful future for all of us.
    

    View Slide

76. Thank you
    Slides: speakerdeck.com/fox/state-of-the-web
    Questions and Feedback: @fox on Twitter
    

    View Slide