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

The State of the Web

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.

Karolina Szczur

August 31, 2017

More Decks by Karolina Szczur

Other Decks in Programming


  1. State of the Web Presented by @fox

  2. The Internet is growing exponentially, but we fail to reflect

    on the greater picture.
  3. We haven’t been building with empathy, situation variability awareness, let

    alone performance in mind.
  4. 51% of 7 billion people have access to the Internet

    Read: Q2 2017 Global Digital Statshot
  5. 7 mb/s is the average network speed worldwide Read: Akamai's

    State of the Internet Report for Q1 2017
  6. 93% of Internet users go online via mobile devices Read:

    Q2 2017 Global Digital Statshot
  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
  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”.
  9. Daily application updates can easily yield 700 MB downloads.

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

  11. If we’re building the web platform from the position of

    privilege and lack of empathy, it results in exclusionary, subpar experiences.
  12. Optimising all assets

  13. One of the ways to significantly improve performance starts with

    understanding how the browser analyses and serves assets.
  14. HTML 100 ms 200 ms 300 ms 400 ms 500

    ms 600 ms 700 ms CSS JAVASCRIPT FONT
  15. A critical request contains assets that are necessary to render

    the content within the users’ viewport.
  16. Lead image Logo Web font Which assets are critical?

  17. <link rel="preload" href="critical.css" as="style"> Fetch immediately Type of an asset

  18. The Critical Request by Ben Schwarz

  19. Enabling request priority in Chrome

  20. 1. Cache aggressively 2. Enable server-side compression 3. Prioritise critical

    assets 4. Use content delivery networks Performance checklist
  21. Optimising images

  22. Images can account for most of transferred payload, which is

    why imagery optimisation can yield the biggest performance wins.
  23. How do I pick the right format?

  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.
  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 (<video autoplay muted loop>) Read: Choosing an Image Format
  26. Coach designers on picking and exporting the most suitable format.

  27. WebP is 25-34% smaller than other formats. It can be

    safely used with fallbacks. Read: A new image format for the Web
  28. brew install webp cwebp -q source.png -o output.webp

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

    to optimise.
  30. ImageOptim SVGO

  31. Guetzli can produce up to 35% smaller JPEGs (but be

    wary of its speed). See: Guetzli on Github
  32. We need to serve the right resolutions and file types

    to the right devices.
  33. The srcset attribute <img srcset="cat-320w.jpg 320w,
 cat-480w.jpg 480w,
 cat-800w.jpg 800w"

    sizes="(max-width: 320px) 100vw,
 (max-width: 480px) 80vw,
 src="cat-800w.jpg" alt="Cat"> 
 Condition (media query) Width relative to viewport Width of the image source
  34. The picture element <picture>
 <source media="(min-width: 40em)” srcset="big.jpg 1x, big-hd.jpg

 srcset="small.jpg 1x, small-hd.jpg 2x">
 <img src="fallback.jpg" alt="">
 Condition (media query) Image source to use Read: Responsive Images 101
  35. CDNs can take out a lot of complexity from serving

    responsive, optimised assets on image-heavy sites.
  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
  37. Optimising web fonts

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

  39. None
  40. There are four web font formats. It’s safe to use

    WOFF2 with a WOFF fallback.
  41. WOFF2 font files are 30% smaller.

  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
  43. Limit the number of typefaces, font weights and styles. Read:

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

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

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

  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
  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
  49. npm install webfontloader npm install fontfaceobserver

  50. Font loading strategy in action

  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
  52. Optimising JavaScript

  53. There’s a much more sinister performance bottleneck hidden behind our

    beloved JavaScript than its size.
  54. Unpacked JavaScript can become 2-3x bigger than what we’ve sent

    down the wire. Read: JavaScript start-up performance
  55. Parse and compile times are so high it takes 8

    seconds to reach an interactive state.
  56. Package managers can easily obscure the size of our dependencies.

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

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

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

    splitting and dynamic imports.
  60. When starting a project, consider lightweight framework alternatives.

  61. 1. Monitor how much JavaScript is delivered 2. Get rid

    of unnecessary dependencies 3. Implement code splitting 4. Consider framework alternatives Performance checklist
  62. Tracking performance

  63. 1. Leverage user-centric metrics 2. Set performance budgets 3. Monitor

    continuously 4. Build performance awareness and empathy Performance checklist
  64. Great performance metrics aim to be as close to portraying

    users’ experience as possible.
  65. Delivery-oriented metrics User-centric metrics Speed Index First Paint onLoad First

    Meaningful Paint onDomLoaded Visually Complete onContentLoaded Time to Interactive
  66. First Paint First Contentful Paint First Meaningful Paint Visually complete

  67. Metrics can quickly become confusing. Without actionable targets, it’s easy

    to lose track of what we’re trying to achieve.
  68. Set attainable performance budgets. performancebudget.io browserdiet.com/calories/

  69. Monitoring performance shouldn’t be manual.

  70. Use Google Lighthouse npm install -g lighthouse

  71. Try out Calibre calibreapp.com

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

  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.
  74. As technologists, it’s our responsibility to not hijack attention and

    time. timewellspent.io We need to be conscious of human focus.
  75. Let’s build a better, more mindful future for all of

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