Successfully reported this slideshow.
Your SlideShare is downloading. ×

The Anatomy Of A Performance Audit

Ad

#gatsbyconf
#gatsbyconf
The Anatomy of A
Performance Audit
Sam Bhagwat • Co-founder, Chief Strategy Officer, Gatsby

Ad

#gatsbyconf
● What does fast mean?
● How do you stay fast?
● How do you get fast?

Ad

#gatsbyconf
UX
Why performance matters
Conversion Search
Ranking

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

#gatsbyconf
Plugin
output for
a page
(2) Reduce bundle size || Triage | Isolate | Refactor | Evaluate

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Loading in …3
×

Check these out next

29 of 51 Ad
29 of 51 Ad

More Related Content

The Anatomy Of A Performance Audit

  1. 1. #gatsbyconf #gatsbyconf The Anatomy of A Performance Audit Sam Bhagwat • Co-founder, Chief Strategy Officer, Gatsby
  2. 2. #gatsbyconf ● What does fast mean? ● How do you stay fast? ● How do you get fast?
  3. 3. #gatsbyconf UX Why performance matters Conversion Search Ranking
  4. 4. #gatsbyconf Making a slow website fast is hard Everything impacts perf Hard to know what changes matter for you Get fast, stay fast
  5. 5. #gatsbyconf ● First, the performance improvements you make ● Second, the process you have to quantify, maintain, and extend those improvements Perf: improvements and process
  6. 6. #gatsbyconf [perf improvements without a perf process]
  7. 7. #gatsbyconf Part 0: What is Fast?
  8. 8. #gatsbyconf Core Web Vitals (loading) (interactivity) (layout shift)
  9. 9. #gatsbyconf Part 1: Stay Fast Creating a performance process for your Gatsby site
  10. 10. #gatsbyconf 1. Choose a primary testing tool Lighthouse (Google) WebPageTest
  11. 11. #gatsbyconf Gatsby Cloud Third-party services 2. Per-commit, per-PR perf monitoring
  12. 12. #gatsbyconf 3. Quantify each change & watch the #s Before After
  13. 13. #gatsbyconf Part 2: Get Fast Implementing Performance Improvements
  14. 14. #gatsbyconf All fast websites are alike. All slow websites are slow in different ways. - Leo Tolstoy Kyle Mathews
  15. 15. #gatsbyconf All performance work is telling your user’s browser how to do less work
  16. 16. #gatsbyconf 1. Fetch and parse third party scripts. 2. Fetch and parse your main JavaScript bundle. 3. Fetch, load and paint images and media 4. Load CSS & fonts and paint the screen 5. Make calls over the network to do (1)-(4) Types of work the browser does (post-HTML load)
  17. 17. #gatsbyconf 1. Address third-party script impact 2. Reduce JavaScript bundle size 3. Optimize image and media delivery 4. Optimize styling and font files 5. Resource requests & CDN configuration Types of improvements you can make
  18. 18. #gatsbyconf For each “browser work” type: 1. Triage: triage the overall impact caused by this type of browser work to decide your level of effort 2. Isolate: Identify & isolate key lines of code impacting perf 3. Refactor: when clear-cut, remove or refactor code 4. Evaluate: when not clear-cut, estimate potential perf gain from refactoring, and evaluate whether it’s worth the time TIRE: a perf improvement pattern
  19. 19. #gatsbyconf 1. Address third-party script impact 2. Reduce JavaScript bundle size 3. Optimize image and media delivery 4. Optimize styling and font files 5. Resource requests & CDN configuration (1)Third-party scripts ||
  20. 20. #gatsbyconf (1)Third-party scripts || Triage | Isolate | Refactor | Evaluate
  21. 21. #gatsbyconf ① “Reduce the impact of third-party code” ② “Minimize main-thread work” ③ “Reduce JavaScript execution time” (1)Third-party scripts || Triage | Isolate | Refactor | Evaluate
  22. 22. #gatsbyconf ● Remove each script, test before / after Lighthouse scores (individual impact) ● Remove all scripts, test before / after Lighthouse scores (collective impact) Understand script impact (1)Third-party scripts || Triage | Isolate | Refactor | Evaluate
  23. 23. #gatsbyconf Understand the business “why” (1)Third-party scripts || Triage | Isolate | Refactor | Evaluate ● For each script, understand: ○ Overall business purpose ○ Relative importance ○ Who uses the data
  24. 24. #gatsbyconf 1. Cut when possible a. Remove high-cost, low- value scripts b. Remove unused scripts 2. Optimize everything else a. Lazy load scripts b. Inline scripts Reduce script impact (1)Third-party scripts || Triage | Isolate | Refactor | Evaluate
  25. 25. #gatsbyconf 1. Address third-party script impact 2. Reduce JavaScript bundle size 3. Optimize image and media delivery 4. Optimize styling and font files 5. Resource requests & CDN configuration (2) Reduce bundle size
  26. 26. #gatsbyconf ② “Reduce JavaScript execution time” ① “Minimize main-thread work” (2) Reduce bundle size || Triage | Isolate | Refactor | Evaluate
  27. 27. #gatsbyconf Install gatsby-plugin-webpack-bundle-analyser-v2 and add it to your gatsby-config.js Profile your code (2) Reduce bundle size || Triage | Isolate | Refactor | Evaluate
  28. 28. #gatsbyconf (2) Reduce bundle size || Triage | Isolate | Refactor | Evaluate Experimental: gatsby-plugin-perf-budgets Visit /_report.html
  29. 29. #gatsbyconf Plugin output for a page (2) Reduce bundle size || Triage | Isolate | Refactor | Evaluate
  30. 30. #gatsbyconf Application level chunks (shared with all pages) framework-*.js (React / React-DOM) app-*.js (Gatsby framework) webpack-runtime-*.js (coordinates bundle interaction) commons-*.js (libraries used on every page) styles-*.js (CSS modules) (2) Reduce bundle size || Triage | Isolate | Refactor | Evaluate
  31. 31. #gatsbyconf Template-level chunks (shared with pages with this template ) component-*.js (each component & the components it uses) [hash].js (3rd-party libraries used by this template) (2) Reduce bundle size || Triage | Isolate | Refactor | Evaluate
  32. 32. #gatsbyconf 1. Order of operations a. Audit commons-*.js, app-*.js first b. Audit critical path templates 2. On each chunk…. a. Identify large third-party imports (eg, Moment) b. Identify components & data that shouldn’t be needed in a particular template or commons Identify high-leverage points (2) Reduce bundle size || Triage | Isolate | Refactor | Evaluate
  33. 33. #gatsbyconf 1. Replace heavy third-party libraries with lighter weight alternatives 2. Upgrade to Gatsby 3 for smaller bundles 3. Examine your import structure a. Look for shared components pulling in other, unneeded components Make high-impact changes (2) Reduce bundle size || Triage | Isolate | Refactor | Evaluate
  34. 34. #gatsbyconf 1. Address third-party script impact 2. Reduce JavaScript bundle size 3. Optimize image and media delivery 4. Optimize styling and font files 5. Resource requests & CDN configuration
  35. 35. #gatsbyconf ① “Defer offscreen images” ② “Serve images in next- gen formats” ③ “Efficiently encode images” (3) Images and Media|| Triage | Isolate | Refactor | Evaluate
  36. 36. #gatsbyconf 1. Smaller & faster than gatsby-image 2. Much faster than not using gatsby-image at all! Use gatsby-plugin-image (3) Images and Media|| Triage | Isolate | Refactor | Evaluate
  37. 37. #gatsbyconf 1. Address third-party script impact 2. Reduce JavaScript bundle size 3. Use Gatsby’s tools for images and other media 4. Optimize styling and font files 5. Resource requests & CDN configuration
  38. 38. #gatsbyconf (command-shift-P) (4) Styling and Fonts || Triage | Isolate | Refactor | Evaluate
  39. 39. #gatsbyconf (4) Styling and Fonts || Triage | Isolate | Refactor | Evaluate
  40. 40. #gatsbyconf (4) Styling and Fonts || Triage | Isolate | Refactor | Evaluate
  41. 41. #gatsbyconf (4) Styling and Fonts || Triage | Isolate | Refactor | Evaluate
  42. 42. #gatsbyconf ….consider refactoring to a more modular CSS solution (4) Styling and Fonts || Triage | Isolate | Refactor | Evaluate
  43. 43. #gatsbyconf If you see >30kb font files, slim down ● Prefer woff2, woff to ttf ● Trim down to one alphabet (eg Latin for US/EU) ● Prefer (correct) font self- hosting to Google Fonts to save request times (4) Styling and Fonts || Triage | Isolate | Refactor | Evaluate
  44. 44. #gatsbyconf 1. Address third-party script impact 2. Reduce JavaScript bundle size 3. Use Gatsby’s tools for images and other media 4. Optimize styling and font files 5. Resource requests & CDN configuration
  45. 45. #gatsbyconf ● Load critical assets from your main domain where possible. ● Preconnect to subdomains using gatsby-plugin-preconnect ● Utilize Gatsby Link to optimizing intra-site navigation Resource requests & CDN config (5) Resources & CDN || Triage | Isolate | Refactor | Evaluate
  46. 46. #gatsbyconf ● Perf matters because of UX, conversions, and search rankings ● Like getting healthy, hard part is getting fast and staying fast ● You stay fast by running a testing tool on every PR and commit. ● You get fast by: ○ ....looking at five types of browser work (third-party scripts, JS bundles, images & media, styles, and requests) ○ And following the TIRE process (Triage relative importance, Isolate key code, Refactor if easy, Evaluate impact if not) So, to recap…….
  47. 47. #gatsbyconf ● Sign up for Gatsby Cloud ● Use the new gatsby-plugin-image And...if you only have a couple hours
  48. 48. #gatsbyconf Oh, and one last thing….
  49. 49. #gatsbyconf Want to do this even better? We’re happy to help.
  50. 50. #gatsbyconf Want to do this even better? We’re happy to help. gatsbyjs.com/concierge/
  51. 51. #gatsbyconf #gatsbyconf Thank you!✌ Sam Bhagwat @calcsam

Editor's Notes

  • I’m excited to talk about a key reason why people love Gatsby: fast sites.

    "In fifteen minutes, I'm going to share with you enough information to get started with a performance audit, we've done dozens of these at Gatsby."
  • The tricky thing is that performance isn’t just about making your site fast, it’s about keeping it fast. That means putting the right processes in place at your organization.

    In other words, performance is both a technical challenge and a people challenge.
  • The tricky thing is that performance isn’t just about making your site fast, it’s about keeping it fast. That means putting the right processes in place at your organization.

    In other words, performance is both a technical challenge and a people challenge.
  • What Addy’s saying is that performance work without organizational basis in place will feel like this.

    “[After] improving performance, metrics often rapidly regress once [teams] return to feature development.” -- Addy Osmani, Web Performance Lead, Google


    “When companies put in the work to improve performance, perf metrics will often rapidly regress once they return to feature development.”


  • Okay, so a couple things about this talk.

    Also, this talk is accompanied by a new piece of documentation in the Performance section. If you’re curious to dive deeper into any of the topics I’ll be covering, that doc is a great place to star

    So let’s talk about what a performance process looks like. The good news is that it’s simpler than you might think.
  • Third, watch the numbers. Performance gains -- and regressions -- are sometimes unexpectedly large. You could improve performance 10 points by eliminating one script; or reduce it 10 points by accidentally pulling in extra JavaScript. Quantify so you know what moves the needle.
  • So let’s talk about what a performance process looks like. The good news is that it’s simpler than you might think.
  • First, choose a testing tools. These are both great choices. Lighthouse tends to be seen as more "canonical".

    Webpagetest tends to be seen as more precise.
  • Second, monitor performance on a per-commit, per-PR basis to flag regressions.
    Gatsby Cloud has Lighthouse performance reports built into its CI/CD.
    Alternately, use a third-party service -- there are tons of great options.
  • Third, watch the numbers. Performance gains -- and regressions -- are sometimes unexpectedly large. You could improve performance 10 points by eliminating one script; or reduce it 10 points by accidentally pulling in extra JavaScript. Quantify so you know what moves the needle.
  • Okay, so you’ve got your performance process in place. Now time to get down to improving performance.
  • Gatsby makes your sites fast by default.

    But there are lots of things you can do that will still make it less fast than it could be. We’re going to talk today about how to improve performance by finding and fixing those issues. This is a great quote by Kyle.
  • This is one way to think about performance. All performance work is telling your user’s browser how to do less work
  • Fundamentally there are five things that your browser is doing, after it reads the initial HTML.

    “These are the main that we’ve seen from Gatsby sites” ← use this language to frame things. Gatsby does a ton of things to optimize -- both inherent in the framework as well as a number of plugins --

    Each thing the browser does is something you can optimize.
  • Typically you’re going to get the most impact from tackling the first three.

    But we’re going to
  • Typically you’re going to get the most impact from tackling the first three. But you won’t know for sure until you run a report. But which one of them is most important? That’s where you run your audit report. Let’s dive into a audit quickly.
  • Let’s talk about addressing third-party scripts.
  • Split out into a couple of slides, add screenshots, talk track from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R57
  • Split out into a couple of slides, add screenshots, talk track from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R57
  • 3rd party scripts are a black box for most developers. To improve things, you have to look into the box.
  • The first thing you should do is understand what’s going on.
  • After you have a sense for the impact of each script and all scripts, you have a number of options to explore.

    Maybe there’s a high-cost script that you can cleverly eliminate by using a system you already use to send the data marketing needs.
    Maybe one script was only being left by someone who left last last month, and you can get rid of it.
  • Split out into a couple of slides, add screenshots, talk track from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R57
  • This is the plugin output for one of our builds on gatsbyjs.com.

    Seeing something like this can be a bit intimidating, so I’ll break it down here.
  • Looking at the naming structure, you can identify several “application” level chunks shared between all pages (Note: This is a pretty healthy bundle)
  • You can also see chunks that are specific to the particular “template” used to generate this page (Note: This is a pretty healthy bundle)
  • Once you’ve done
  • Laurie just gave a great talk on Gatsby image, so this is most of it! Go watch her talk and implement Gatsby image if you haven’t already!
  • Split out into a couple of slides, add screenshots, talk track from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R57
  • Split out into a couple of slides, add screenshots, talk track from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R57
  • Slim down from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R139
  • This is the Coverage Drawer -- a tab you can find in Chrome Developer Tools -- for the homepage of an e-commerce site that is using Gatsby. You can see their homepage is roughly 300 kilobytes, around 80% of which isn’t being used. This is because they’re pulling in a lot of CSS that isn’t being used. They’re working on refactoring and modularizing their CSS using CSS modules.

    Slim down from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R139
  • This is the Coverage Drawer -- a tab you can find in Chrome Developer Tools -- for the homepage of an e-commerce site that is using Gatsby. You can see their homepage is roughly 300 kilobytes, around 80% of which isn’t being used. This is because they’re pulling in a lot of CSS that isn’t being used. They’re working on refactoring and modularizing their CSS using CSS modules.

    Slim down from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R139
  • This is the Coverage Drawer -- a tab you can find in Chrome Developer Tools -- for the homepage of an e-commerce site that is using Gatsby. You can see their homepage is roughly 300 kilobytes, around 80% of which isn’t being used. This is because they’re pulling in a lot of CSS that isn’t being used. They’re working on refactoring and modularizing their CSS using CSS modules.

    Slim down from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R139
  • This is the Coverage Drawer -- a tab you can find in Chrome Developer Tools -- for the homepage of an e-commerce site that is using Gatsby. You can see their homepage is roughly 300 kilobytes, around 80% of which isn’t being used. This is because they’re pulling in a lot of CSS that isn’t being used. They’re working on refactoring and modularizing their CSS using CSS modules.

    Slim down from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R139
  • This is the Coverage Drawer -- a tab you can find in Chrome Developer Tools -- for the homepage of an e-commerce site that is using Gatsby. You can see their homepage is roughly 300 kilobytes, around 80% of which isn’t being used. This is because they’re pulling in a lot of CSS that isn’t being used. They’re working on refactoring and modularizing their CSS using CSS modules.

    Slim down from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R139
  • This is the Coverage Drawer -- a tab you can find in Chrome Developer Tools -- for the homepage of an e-commerce site that is using Gatsby. You can see their homepage is roughly 300 kilobytes, around 80% of which isn’t being used. This is because they’re pulling in a lot of CSS that isn’t being used. They’re working on refactoring and modularizing their CSS using CSS modules.

    Slim down from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R139
  • The tricky thing is that performance isn’t just about making your site fast, it’s about keeping it fast. That means putting the right processes in place at your organization.

    In other words, performance is both a technical challenge and a people challenge.
  • The tricky thing is that performance isn’t just about making your site fast, it’s about keeping it fast. That means putting the right processes in place at your organization.

    In other words, performance is both a technical challenge and a people challenge.
  • The tricky thing is that performance isn’t just about making your site fast, it’s about keeping it fast. That means putting the right processes in place at your organization.

    In other words, performance is both a technical challenge and a people challenge.

×