Download to read offline
![#gatsbyconf
[perf improvements without a perf
process]](https://image.slidesharecdn.com/theanatomyofaperformanceauditsambhagwatgatsbyconf2021-210421193501/75/The-Anatomy-Of-A-Performance-Audit-6-2048.jpg)
![#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](https://image.slidesharecdn.com/theanatomyofaperformanceauditsambhagwatgatsbyconf2021-210421193501/75/The-Anatomy-Of-A-Performance-Audit-31-2048.jpg)
Uploaded bySam Bhagwat
The Anatomy Of A Performance Audit
The document discusses how to audit and improve the performance of a Gatsby site. It recommends first choosing a performance testing tool and monitoring performance on every code change. To improve performance, it suggests focusing on five types of "browser work": third-party scripts, JavaScript bundles, images/media, styles/fonts, and resource requests. For each type of work, the document provides a "TIRE" process to Triage impact, Isolate key code, Refactor if possible or Evaluate potential gains from refactoring. Specific recommendations include lazy loading scripts, reducing bundle size by upgrading dependencies, using Gatsby plugins for images and preconnecting to subdomains. The overall message is that performance impacts UX and search
The Anatomy Of A Performance Audit
- 1. #gatsbyconf #gatsbyconf The Anatomy ofA Performance Audit Sam Bhagwat • Co-founder, Chief Strategy Officer, Gatsby
- 2. #gatsbyconf ● What doesfast mean? ● How do you stay fast? ● How do you get fast?
- 3. #gatsbyconf UX Why performance matters ConversionSearch Ranking
- 4. #gatsbyconf Making a slowwebsite fast is hard Everything impacts perf Hard to know what changes matter for you Get fast, stay fast
- 5. #gatsbyconf ● First, theperformance improvements you make ● Second, the process you have to quantify, maintain, and extend those improvements Perf: improvements and process
- 6. #gatsbyconf [perf improvements withouta perf process]
- 7. #gatsbyconf Part 0: Whatis Fast?
- 8. #gatsbyconf Core Web Vitals (loading)(interactivity) (layout shift)
- 9. #gatsbyconf Part 1: StayFast Creating a performance process for your Gatsby site
- 10. #gatsbyconf 1. Choose aprimary testing tool Lighthouse (Google) WebPageTest
- 11. #gatsbyconf Gatsby Cloud Third-partyservices 2. Per-commit, per-PR perf monitoring
- 12. #gatsbyconf 3. Quantify eachchange & watch the #s Before After
- 13. #gatsbyconf Part 2: GetFast Implementing Performance Improvements
- 14. #gatsbyconf All fast websitesare alike. All slow websites are slow in different ways. - Leo Tolstoy Kyle Mathews
- 15. #gatsbyconf All performance workis telling your user’s browser how to do less work
- 16. #gatsbyconf 1. Fetch andparse 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. #gatsbyconf 1. Address third-partyscript 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. #gatsbyconf For each “browserwork” 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. #gatsbyconf 1. Address third-partyscript 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. #gatsbyconf (1)Third-party scripts ||Triage | Isolate | Refactor | Evaluate
- 21. #gatsbyconf ① “Reduce the impactof third-party code” ② “Minimize main-thread work” ③ “Reduce JavaScript execution time” (1)Third-party scripts || Triage | Isolate | Refactor | Evaluate
- 22. #gatsbyconf ● Remove eachscript, 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. #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. #gatsbyconf 1. Cut whenpossible 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. #gatsbyconf 1. Address third-partyscript 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. #gatsbyconf ② “Reduce JavaScript execution time” ①“Minimize main-thread work” (2) Reduce bundle size || Triage | Isolate | Refactor | Evaluate
- 27. #gatsbyconf Install gatsby-plugin-webpack-bundle-analyser-v2 and addit to your gatsby-config.js Profile your code (2) Reduce bundle size || Triage | Isolate | Refactor | Evaluate
- 28. #gatsbyconf (2) Reduce bundlesize || Triage | Isolate | Refactor | Evaluate Experimental: gatsby-plugin-perf-budgets Visit /_report.html
- 29. #gatsbyconf Plugin output for a page (2)Reduce bundle size || Triage | Isolate | Refactor | Evaluate
- 30. #gatsbyconf Application level chunks (shared withall 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. #gatsbyconf Template-level chunks (shared with pageswith 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. #gatsbyconf 1. Order ofoperations 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. #gatsbyconf 1. Replace heavythird-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. #gatsbyconf 1. Address third-partyscript impact 2. Reduce JavaScript bundle size 3. Optimize image and media delivery 4. Optimize styling and font files 5. Resource requests & CDN configuration
- 35. #gatsbyconf ① “Defer offscreen images” ② “Serve imagesin next- gen formats” ③ “Efficiently encode images” (3) Images and Media|| Triage | Isolate | Refactor | Evaluate
- 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. #gatsbyconf 1. Address third-partyscript 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. #gatsbyconf (command-shift-P) (4) Styling andFonts || Triage | Isolate | Refactor | Evaluate
- 39. #gatsbyconf (4) Styling andFonts || Triage | Isolate | Refactor | Evaluate
- 40. #gatsbyconf (4) Styling andFonts || Triage | Isolate | Refactor | Evaluate
- 41. #gatsbyconf (4) Styling andFonts || Triage | Isolate | Refactor | Evaluate
- 42. #gatsbyconf ….consider refactoring toa more modular CSS solution (4) Styling and Fonts || Triage | Isolate | Refactor | Evaluate
- 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. #gatsbyconf 1. Address third-partyscript 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. #gatsbyconf ● Load criticalassets 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. #gatsbyconf ● Perf mattersbecause 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. #gatsbyconf ● Sign upfor Gatsby Cloud ● Use the new gatsby-plugin-image And...if you only have a couple hours
- 48. #gatsbyconf Oh, and onelast thing….
- 49. #gatsbyconf Want to dothis even better? We’re happy to help.
- 50. #gatsbyconf Want to dothis even better? We’re happy to help. gatsbyjs.com/concierge/
- 51.
Editor's Notes
- #2 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."
- #5 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.
- #6 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.
- #7 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.”
- #8 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.
- #9 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.
- #10 So let’s talk about what a performance process looks like. The good news is that it’s simpler than you might think.
- #11 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.
- #12 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.
- #13 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.
- #14 Okay, so you’ve got your performance process in place. Now time to get down to improving performance.
- #15 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.
- #16 This is one way to think about performance. All performance work is telling your user’s browser how to do less work
- #17 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.
- #18 Typically you’re going to get the most impact from tackling the first three. But we’re going to
- #19 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.
- #20 Let’s talk about addressing third-party scripts.
- #21 Split out into a couple of slides, add screenshots, talk track from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R57
- #22 Split out into a couple of slides, add screenshots, talk track from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R57
- #23 3rd party scripts are a black box for most developers. To improve things, you have to look into the box.
- #24 The first thing you should do is understand what’s going on.
- #25 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.
- #27 Split out into a couple of slides, add screenshots, talk track from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R57
- #30 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.
- #31 Looking at the naming structure, you can identify several “application” level chunks shared between all pages (Note: This is a pretty healthy bundle)
- #32 You can also see chunks that are specific to the particular “template” used to generate this page (Note: This is a pretty healthy bundle)
- #33 Once you’ve done
- #35 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!
- #36 Split out into a couple of slides, add screenshots, talk track from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R57
- #37 Split out into a couple of slides, add screenshots, talk track from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R57
- #38 Slim down from https://github.com/gatsbyjs/gatsby/pull/29373/files#diff-9247dd003bf5e2c2484bc03c00563897b16e095ec6d6682c997951ba1b78f654R139
- #39 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
- #40 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
- #41 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
- #42 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
- #43 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
- #44 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
- #46 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.
- #47 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.
- #48 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.