 Hi, everyone. Hope you're all staying safe. My name is Hussain Jurde, and I'm a developer advocate on the web team at Google. For this segment of Web.dev Live, we're going to talk about different ways to explore and analyze JavaScript bundles on a web page. Analyzing bundles is a good first step to optimizing the amount of JavaScript shipped to the browser, which can improve page load times and directly result in better logic-temporal paint and first input delay. JavaScript bundling is a term commonly used to describe the approach many websites take to group multiple JavaScript files or modules into a single file or bundle. Many tools that bundle JavaScript code for the browser usually include a number of different optimization steps, such as minification and score-poisoning. This is a good thing because code written across multiple files and modules can be combined into a single optimized bundle. Although this might be useful from a developer and user experience standpoint, this process usually obfuscates JavaScript code to the extent that it can't easily be read and analyzed without the help of additional tooling. Let's take a look at some examples to get a better idea. If you're using Chrome, the network panel on the DevTools is the easiest way to look at all the JavaScript downloaded on a page. Open DevTools by pressing Control-Shift-J or Command-Option-J on the Mac and click the Network tab to open the network panel. To take a look at all the network activity during page load, reload the page while DevTools is still open, click the JavaScript button to filter requests by JavaScript and click any URL to view the response body. The Format button can make a minified file more readable. Notice how with this simple static site, there's only a single JavaScript file and although minified, it's easily human readable. If we do the same for a site that bundles the JavaScript code, it gets harder trying to understand exactly what lives in the bundle. This is an example of a site that bundles many third-party libraries and hundreds of first-party modules into just a few discrete bundles. So let's take a look at some ways to analyze this code. The Coverage tab can show you how much JavaScript code is unused and any of your files or bundles directly in DevTools. Open the Command menu with Ctrl-Shift-P or Command-Shift-P for Mac, type coverage and select the Show Coverage command, click the Reload button to reload the page while capturing coverage and in the drop-down menu, select JavaScript. In the table, the unused bytes field shows exactly how much JavaScript is unused for each file. Click any URL to see a line by line breakdown. So although the Coverage tab gives us a lens on how much code is being used on a page, it still isn't easy to identify which modules make up the bundle. Now there are other tools out there that make this possible. If you're already bundling code for your site, chances are you're using a module bundler like Webpack or Rollup and many of these module bundlers provide either first-class or third-party tooling that you can use to visualize and map your bundles. Let's go over an example. If you use Webpack, you can generate a stats.json file that contains statistics about all bundled modules. A single CLI command emits the file. Although reading this file yourself can give some information about what modules live in the bundle, there are community-built libraries that can consume this file and display a more useful visualization. One such library is called Webpack Bundle Analyzer and it works by parsing the bundles generated by Webpack and then mapping them to the module names in the stats.json file. By doing this, it creates an interactive tree map visualization of an entire bundle, showing the sizes of each module as well as the relation to each other. Gzip and part sizes are also displayed to give you a better idea of how large each of the modules are. Bundler-specific visualization tools are great. They make it easier to see what makes up each of your bundles, but they are bundler-specific. For any site, regardless of whether a specific module bundler is used or not, source maps are a way to map original written code to its transformed output. This is useful because it can allow us to continue to obfuscate and transform our code during the build process, but still have a means to map it back to its original form. JavaScript files that have been transformed due to minification or other bundling optimizations need to point to the location of its source map file with a source mapping URL comment or a source map HTTP header. All newer browsers support source maps. And with Chrome, you can enable it in the DevTools by opening up settings and checking the enable JavaScript source maps option. When Chrome can detect that a source map is available, it'll show a message and we're able to open and debug the separate associated files as regular JavaScript files. Source map explorer is a library that you can use to see a tree map visualization of the bundle. This visualization is an example of using source map explorer with a production build. Just by looking at this, we can identify a few issues already. A few common JS models here, moment JS and low dash, are already larger than they need to be. If they were switched to use ES modules, they could be smaller and more optimized. There are duplicate copies of React and code needed for multiple different routes all live in this bundle. And they could easily be lazy loaded into their own separate bundles. These are all common issues that many sites run into and we can spot them by using a visualization tool like source map explorer. Other tooling that you may already be familiar with are also starting to consume source maps in different ways that can be useful. Lighthouse, an open source website auditing tool is currently experimenting with source map support for some of its audits. With source maps, the unused JavaScript audits could show how much unused code and potential savings live in bundled modules. There's also a new legacy JavaScript audit being developed that takes advantage of source maps to show legacy code within the bundle that contains polyfills and newer browsers don't need. And there we have it. We just went over a number of different techniques to analyze bundle JavaScript code. To recap, the network panel in DevTools is the easiest way to start seeing how much JavaScript code is being downloaded. The coverage tab could show you how much JavaScript is actually used. Many module bundlers have supported tooling that make it easier to visualize bundles. If you use Webpack, for example, you can emit a status JSON file and use Webpack Bundle Analyzer. Consider enabling source maps on your site and use Source Map Explorer to visualize your bundles. If you'd prefer not to emit source maps from production, you can set it up as part of your build process so that it's only generated during development. And Lighthouse is also working in collecting source maps to display more useful audit recommendations. These changes will land in a future version, so keep an eye out. So analyzing your bundles and limiting the amount of JavaScript on a webpage reduces the amount of time the browser needs to spend parsing, compiling, and executing JavaScript code. This speeds up how fast the browser can begin to respond to any user interactions, improving first input delay, and results in a faster render, improving largest content of paint. Thanks for watching. I hope you found this screencast super useful.