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

Web Performance 101 [Chrome Dev Summit 2020]

Web Performance 101 [Chrome Dev Summit 2020]

What do we mean when we talk about "web performance"? Why should you care about it? How can measure it? How do you get other people in your organization to care? In this workshop at the 2020 Chrome Dev Summit, I covered these questions – including an overview of the history of performance metrics, up to Core Web Vitals.

Tammy Everts

December 07, 2020
Tweet

More Decks by Tammy Everts

Other Decks in Technology

Transcript

  1. Web Performance 101:
    What is web performance
    and why should I care?
    @tameverts
    #ChromeDevSummit
    ¯\_(ツ)_/¯

    View full-size slide

  2. speedcurve.com/benchmarks/

    View full-size slide

  3. What is “web performance”?
    Why should I care about it?
    How do I measure it?
    How can I get other people in my
    company to care about it?

    View full-size slide

  4. Slow websites suck.

    View full-size slide

  5. the average web user believes they waste
    two days a year waiting for pages to load

    View full-size slide

  6. “web stress”
    When apps or sites are slow,
    we have to concentrate
    up to 50% harder to stay on task.
    @tameverts

    View full-size slide

  7. 11
    When do users start to interact with a page?

    View full-size slide

  8. 12
    Source: Jakob Nielsen

    View full-size slide

  9. 13
    Source: Jakob Nielsen

    View full-size slide

  10. 15
    “We want you to be able to flick
    from one page to another as quickly
    as you can flick a page on a book.
    So, we’re really aiming very, very
    high here… at something like
    100 milliseconds.”
    Urs Hölzle
    SVP Engineering, Google

    View full-size slide

  11. fast slow
    @tameverts

    View full-size slide

  12. Slow pages affect people’s perception
    of three things completely unrelated to time:
    1. Content “boring”
    2. Visual design “tacky”
    “confusing”
    3. Ease of navigation “frustrating”
    “hard-to-navigate”

    View full-size slide

  13. User experience and
    web performance
    are predictable indicators
    of business outcomes.

    View full-size slide

  14. Rebuilding Pinterest pages for performance
    resulted in 40% decrease in wait time, 15%
    increase in SEO traffic, and 15% increase in
    signup conversion rate.
    Ancestry.com saw a 7% increase in conversions
    after improving render time by 68%,
    page weight by 46% and load time by 64%.
    Staples reduced median page load time by
    1 second and 98th percentile load time by
    6 seconds, resulting in a 10% conversion rate
    increase.
    @tameverts

    View full-size slide

  15. optimal load times for peak conversions
    @tameverts

    View full-size slide

  16. even 100ms delays matter
    @tameverts

    View full-size slide

  17. real user data +
    machine learning

    View full-size slide

  18. collected 1M+ beacons of real user data
    across 93 attributes, including…
    • top-level – domain, timestamp, SSL
    • session – start time, length (in pages), total load time
    • user agent – browser, OS, mobile ISP
    • geo – country, city, organization, ISP, network speed
    • bandwidth
    • timers – base, custom, user-defined
    • custom metrics
    • HTTP headers

    View full-size slide

  19. 1sessions that convert
    have fewer images

    View full-size slide

  20. 2pages with more
    scripts are less likely
    to convert

    View full-size slide

  21. 160+ scripts… uh-oh
    @tameverts

    View full-size slide

  22. speakerdeck.com/csswizardry/its-my-third-party-and-ill-cry-if-i-want-to

    View full-size slide

  23. How fast is fast enough?

    View full-size slide

  24. “The real thing we are after
    is to create a user experience
    that people love and they feel is fast…
    and so we might be front-end engineers,
    we might be dev, we might be ops,
    but what we really are
    is perception brokers.”
    Steve Souders

    View full-size slide

  25. But measuring perception is hard.
    It’s even harder to scale.

    View full-size slide

  26. What tools do we use?
    Synthetic (lab)
    Consistent baseline
    Mimics network & browser conditions
    No installation
    Compare any sites
    Detailed analysis
    Waterfall charts
    Filmstrips and videos
    Limited URLs
    Real user monitoring (field)
    Requires JavaScript installation
    Large sample size (up to 100%)
    Real network & browser conditions
    Geographic spread
    Correlation with other metrics (bounce rate)
    No detailed analysis
    Only measure your own site

    View full-size slide

  27. Free tools to explore
    Synthetic
    webpagetest.org
    developers.google.com/speed/
    pagespeed/insights/
    Real user monitoring
    github.com/bluesmoon/boomerang
    developers.google.com/web/tools/
    chrome-user-experience-report

    View full-size slide

  28. webpagetest.org

    View full-size slide

  29. developers.google.com/speed/pagespeed/insights/

    View full-size slide

  30. A brief history
    of performance metrics

    View full-size slide

  31. TTFB DNS TCP
    TTI FCP FMP
    FID OMG WTF

    View full-size slide

  32. ❑ Correlates to what users actually see in the browser
    ❑ Is easy to use and accessible right out of the box
    ❑ Recognizes that not all pixels and page elements
    are equal
    ❑ Allows us to customize what we measure on
    specific pages
    The best UX metric…

    View full-size slide

  33. Is it happening?
    Is it useful?
    Is it usable?
    Is it delightful?
    developers.google.com/web/fundamentals/
    performance/user-centric-performance-metrics

    View full-size slide

  34. Load Time
    The time from the start of the initial
    navigation until the beginning of the
    window load event

    View full-size slide

  35. Start Render
    The time from the start of the initial
    navigation until the first non-white
    content is painted

    View full-size slide

  36. start render repeat visits

    View full-size slide

  37. First Paint
    First Contentful Paint
    First Meaningful Paint

    View full-size slide

  38. First Paint (FP)
    Pixels first start to render

    View full-size slide

  39. First Contentful Paint (FCP)
    Text and graphics start to render…
    BUT often catches non-meaningful
    paints (e.g. headers, nav bars)

    View full-size slide

  40. First Meaningful Paint (FMP)
    The paint after which the biggest
    ATF layout change has happened
    and web fonts have loaded

    View full-size slide

  41. speedcurve.com/blog/an-analysis-of-chromiums-paint-timing-metrics/

    View full-size slide

  42. Analysis of 40 top Alexa-ranked sites
    95% of FP events occur before Start Render
    85% of FCP events occur before Start Render
    50% of FMP events occur before Start Render
    speedcurve.com/blog/an-analysis-of-chromiums-paint-timing-metrics/

    View full-size slide

  43. Speed Index
    Average time at which visible parts of
    the page are in the viewport

    View full-size slide

  44. ❑ Correlates to what users actually see in the browser
    ❑ Is easy to use and accessible right out of the box
    ❑ Recognizes that not all pixels and page elements
    are equal
    ❑ Allows us to customize what we measure on
    specific pages
    The best UX metric…

    View full-size slide

  45. Custom metrics
    Measure performance with high-precision timestamps
    Available in both synthetic and RUM (yay!)
    https://www.w3.org/TR/user-timing/
    https://speedcurve.com/blog/user-timing-and-custom-metrics/

    View full-size slide

  46. how long does it
    take to display the
    main product image
    on my site?

    View full-size slide

  47. Time to First Tweet
    The time from clicking the link to viewing
    the first tweet on each page’s timeline
    Pinner Wait Time (PWT)
    The time from initiating an action (e.g.,
    tapping a pin) until the action is complete
    (pin close-up view is loaded)
    Time to Interact (TTI)
    @tameverts

    View full-size slide

  48. Lighthouse
    Scores based on audits run on synthetic tests.
    Checks your page against “rules” for Performance, PWA,
    Best Practices, and SEO.
    For each category, you get a score out of 100 and
    recommendations for what to fix.
    developers.google.com/web/tools/lighthouse

    View full-size slide

  49. matuzo.at/blog/building-the-most-inaccessible-site-possible-
    with-a-perfect-lighthouse-score/

    View full-size slide

  50. Core Web Vitals

    View full-size slide

  51. developers.google.com/search/blog/2020/11/timing-for-page-experience

    View full-size slide

  52. “Core Web Vitals are the subset of Web Vitals that
    apply to all web pages, should be measured by all site owners,
    and will be surfaced across all Google tools.
    “Each of the Core Web Vitals represents a distinct facet of
    the user experience, is measurable in the field, and
    reflects the real-world experience of a critical user-centric outcome.
    “The metrics that make up Core Web Vitals will evolve over time.
    “The current set for 2020 focuses on three aspects of the user
    experience — loading, interactivity, and visual stability — and includes
    the following metrics…
    web.dev/vitals/

    View full-size slide

  53. Largest Contentful Paint
    First Input Delay
    Cumulative Layout Shift
    loading
    interactivity
    visual stability

    View full-size slide

  54. 75th percentile of page loads
    across mobile and desktop

    View full-size slide

  55. Amount of time it takes for the largest visual element to render.
    Available in Chrome and Chromium-based browsers.
    Measurable via synthetic and RUM.

    View full-size slide

  56. Amount of time it takes for page to respond to user input
    (e.g. click, tap, key).
    Only measurable via RUM.

    View full-size slide

  57. FID can seem fast because user interactions
    take place later in the page’s rendering cycle...
    after CPU-hogging long tasks have completed.
    speedcurve.com/blog/first-input-delay-google-core-web-vitals/

    View full-size slide

  58. No correlation when looking at all sessions
    speedcurve.com/blog/first-input-delay-google-core-web-vitals/

    View full-size slide

  59. Stronger correlation at 75th percentile
    speedcurve.com/blog/first-input-delay-google-core-web-vitals/

    View full-size slide

  60. Long Tasks have a high correlation
    across the board
    speedcurve.com/blog/first-input-delay-google-core-web-vitals/

    View full-size slide

  61. Long Tasks
    Measures JavaScript functions that take 50ms or longer.
    Long or excessive JS tasks can delay rendering,
    as well as cause page “jank”.
    Measurable via synthetic and RUM.

    View full-size slide

  62. Score that reflects how much page elements shift during rendering.
    Available in Chrome and Chromium-based browsers.
    Measurable via synthetic and RUM.

    View full-size slide

  63. Size of the shifting element matters
    speedcurve.com/blog/visualising-cls-layout-shifts/

    View full-size slide

  64. Image carousels can generate false positives
    speedcurve.com/blog/visualising-cls-layout-shifts/

    View full-size slide

  65. Web fonts & opacity changes can cause issues
    speedcurve.com/blog/visualising-cls-layout-shifts/

    View full-size slide

  66. Bounce rate gets worse as CLS degrades
    Bounce rate improves as CLS degrades
    Bounce rate stays the same as CLS degrades
    @tameverts

    View full-size slide

  67. Look at your
    own data.

    View full-size slide

  68. How do these metrics correlate
    with my business goals?
    How fast should they be?
    How do we stay on track?

    View full-size slide

  69. cnet.com/news/appliance-science-the-well-done-physics-chemistry-of-the-toaster/

    View full-size slide

  70. How to create
    a culture of performance

    View full-size slide

  71. “The largest hurdle to creating
    and maintaining stellar site
    performance is the culture
    of your organization.
    Lara Hogan
    designingforperformance.com

    View full-size slide

  72. “No matter the size or type of team,
    it can be a challenge to educate,
    incentivize, and empower those around you.
    “Performance more often comes down to
    a cultural challenge, rather than simply
    a technical one.”
    Lara Hogan
    designingforperformance.com

    View full-size slide

  73. Educate
    Incentivize
    Empower

    View full-size slide

  74. 2009 Improved average load time from 6s à 1.2s
    7-12% increase in conversion rate + 25% increase in PVs
    Average load time degraded to 5s
    User feedback: “I will not come back to this site again.”
    Re-focused on performance
    0.4% increase in conversion rate
    2010
    2011
    @tameverts

    View full-size slide

  75. 1. No front-end measurement
    2. Constant feature development
    3. Badly implemented third-parties
    4. Waiting too long to tackle performance
    problems
    5. Relying on performance sprints

    View full-size slide

  76. 1. You need a plan

    View full-size slide

  77. Making it up as you go
    is not always a good idea.
    (Actual photo taken yesterday
    of my family’s gingerbread village.)

    View full-size slide

  78. Tools

    Enough

    View full-size slide

  79. 2. Have a champion
    higher up

    View full-size slide

  80. 3. Then build a
    cross-disciplinary team

    View full-size slide

  81. Everyone who touches
    a page should care
    about the performance
    of that page.

    View full-size slide

  82. Embrace performance from the ground up.
    Embed engineers into other teams.
    Enlist performance ambassadors.
    Teach people how to use (or at least understand)
    the monitoring tools you use.

    View full-size slide

  83. 4. Set shared goals

    View full-size slide

  84. It’s perilously easy
    to accidentally become
    a gatekeeper.

    View full-size slide

  85. We first went to the
    engineering leaders,
    and then we went to
    our product leader.
    Our pitch was
    totally different...
    Reefath Rajali // PayPal
    chasingwaterfalls.io/episodes/episode-two-with-reefath-rajali/

    View full-size slide

  86. “When we went to our product leaders,
    we spoke more about the business numbers
    and the business benefits.
    “When we spoke to our engineering leaders,
    it was more about our consumer delight.”
    Reefath Rajali // PayPal
    chasingwaterfalls.io/episodes/episode-two-with-reefath-rajali/

    View full-size slide

  87. Find out what people
    care about

    View full-size slide

  88. ❑ bounce rate
    ❑ cart size
    ❑ conversions
    ❑ revenue
    ❑ time on site
    ❑ page views
    ❑ SEO
    ❑ user happiness
    ❑ user retention
    ❑ competitors

    View full-size slide

  89. If they care about
    business metrics…

    View full-size slide

  90. If they care about
    user engagement…

    View full-size slide

  91. If they care about
    SEO…

    View full-size slide

  92. If they care about
    third parties…

    View full-size slide

  93. Who they are What they care about What to show them
    Executives
    Competition
    Business impact
    Benchmarks (filmstrips and videos)
    Correlation charts (perf + KPIs)
    Marketing
    Third parties
    Traffic + engagement
    SEO
    Content
    Third-party performance
    Correlation charts (perf + bounce rate)
    Lighthouse SEO audits
    Image size
    Devs / engineers Well, lots of stuff, probably Consult with perf team

    View full-size slide

  94. 5. Make everyone
    accountable

    View full-size slide

  95. Performance budgets FTW!

    View full-size slide

  96. Thresholds YOU create for metrics
    that are meaningful for YOUR site
    addyosmani.com/blog/performance-budgets/
    Milestone timings (e.g. start render)
    Quantity-based (e.g. image weight)
    Rules-based (e.g. Lighthouse scores)

    View full-size slide

  97. A good performance budget
    should show you…
    What your budget is
    When you go out of bounds
    How long you’re out of bounds
    When you’re back within budget

    View full-size slide

  98. zillow.com/tech/bigger-faster-more-engaging-budget/

    View full-size slide

  99. zillow.com/tech/bigger-faster-more-engaging-budget/

    View full-size slide

  100. Super important!
    Look at your own data
    Monitor your competitors
    No sandbagging allowed
    Take a step-by-step approach if necessary
    Use synthetic and RUM (numbers may will vary)

    View full-size slide

  101. Pro tips
    Create budgets for your popular
    and regularly changing pages
    Review violations early and always
    Compare before and after releases
    Update budgets accordingly
    zillow.com/engineering/bigger-faster-more-engaging-budget/

    View full-size slide

  102. Who What Metric
    Ops Back-end issues TTFB
    Marketing
    Most important content
    Third parties
    SEO
    Largest Contentful Paint
    JS Long Tasks
    Lighthouse SEO score & audits
    Devs / engineers
    How well pages are built
    Performance issues
    Start Render, Web Vitals
    Lighthouse Performance audits

    View full-size slide

  103. Give people ownership

    View full-size slide

  104. “One of the original directives
    of the performance team
    was we weren’t going
    to set ourselves up
    to be performance cops.”
    Dan Chilton, Vox Media
    responsivewebdesign.com/podcast/vox-media-performance/

    View full-size slide

  105. “We weren’t going to go around slapping people
    on the wrist, saying, ‘You built an article that
    broke the page size budget! You have to take that
    down or change that immediately!’
    “Our goal setting out was to set up best practices,
    make recommendations, and be a resource within
    the company that people can turn to when they
    have to make performance-related decisions.”
    Dan Chilton, Vox Media
    responsivewebdesign.com/podcast/vox-media-performance/

    View full-size slide

  106. 6. Communicate

    View full-size slide

  107. “We, as engineers,
    should learn how
    to show the impact
    on anything we do.”
    Malek Hakim // Priceline
    chasingwaterfalls.io/episodes/episode-one-with-malek-hakim/

    View full-size slide

  108. How often is often enough?
    Wall monitors and dashboards 24/7
    Alerts (to people who can make fixes) in realtime
    Reports no more than 1X week
    Meetups, hackathons, etc. monthly (if possible)

    View full-size slide

  109. 7. Don’t forget to celebrate!

    View full-size slide

  110. medium.com/the-telegraph-engineering

    View full-size slide

  111. Score some easy wins

    View full-size slide

  112. “The dull boring stuff”
    ~Andy Davies
    Scripts (especially third parties)
    Images
    Extraneous code
    Defer assets where possible

    View full-size slide

  113. Shaved 15KB off logo
    Ran A/B test
    Increased bookings
    chasingwaterfalls.io/episodes/episode-one-with-malek-hakim/

    View full-size slide

  114. In summary…

    View full-size slide

  115. There’s no magic.
    Show up with a plan.
    Do the work.
    (Be patient.)

    View full-size slide

  116. Thanks!
    @tameverts
    speedcurve.com/blog

    View full-size slide