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
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 privilege.
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,
 800px"
 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 2x">
 <source
 srcset="small.jpg 1x, small-hd.jpg 2x">
 <img src="fallback.jpg" alt="">
 </picture> 
 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 Statistics
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 us.
76. Thank you Slides: speakerdeck.com/fox/state-of-the-web Questions and Feedback: @fox on Twitter