From 141fa46505d0b819ab78d36230c397621440aa44 Mon Sep 17 00:00:00 2001 From: Rick Viscomi Date: Mon, 19 Sep 2022 22:28:03 +0000 Subject: [PATCH 01/27] initial md conversion with figure placeholders --- src/content/en/2022/javascript.md | 940 +++++++++++++++++++++++++++++- 1 file changed, 939 insertions(+), 1 deletion(-) diff --git a/src/content/en/2022/javascript.md b/src/content/en/2022/javascript.md index 57736bd3fd4..4164a3bddb0 100644 --- a/src/content/en/2022/javascript.md +++ b/src/content/en/2022/javascript.md @@ -19,4 +19,942 @@ featured_stat_label_3: TODO unedited: true --- -## TODO +## Introduction + +JavaScript is a powerful force that provides the lion's share of interactivity on the web. It drives behaviors from the simple to the complex, and is making more things possible on the web than ever before. + +Yet, the increased usage of JavaScript to deliver rich user experiences comes at a cost. From the moment JavaScript is downloaded, parsed, and compiled, to every moment it executes, the browser must orchestrate all kinds of work to make everything possible. + +This work comes at a cost: doing too little with JavaScript means you _might_ fall short of fulfilling user experience and business goals. On the other hand, shipping too much on JavaScript means you might be creating user experiences that are slow to load, sluggish to respond, and frustrating to users. + +This year, we'll once again be looking at the role of JavaScript on the web, as we present our findings for 2022 and offering advice for creating delightful user experiences. + +## How much JavaScript do we load? + +To begin, the amount of JavaScript web developers ship on the web will be touched upon. After all, before improvements can be made, an assessment of the current landscape must be performed. + +{{ figure_markup( + image=".png", + caption="", + description="", + chart_url="", + sheets_gid="", + sql_file=".sql" + ) +}} + +_Figure 2.x. Distribution of the amount of JavaScript loaded per page._ + +As was the case last year, this year marks yet another increase in the amount of JavaScript shipped to browsers. [From 2021](https://almanac.httparchive.org/en/2021/javascript#how-much-javascript-do-we-load) to 2022, an increase of 7.4% for mobile devices was observed, whereas desktop devices saw an increase of 9%. While this increase is less steep than in previous years, it's nonetheless the continuation of a concerning trend. While device capabilities continue to improve, the fact remains that more JavaScript equates to more strain on a device's resources. + +{{ figure_markup( + image=".png", + caption="", + description="", + chart_url="", + sheets_gid="", + sql_file=".sql" + ) +}} + +_Figure 2.x. Distribution of the amount of unused JavaScript bytes._ + +According to [Lighthouse](https://almanac.httparchive.org/en/2021/methodology#lighthouse), the median mobile page loads 162 KB of unused JavaScript. At the 90th percentile, 604 KB of JavaScript are unused. This is a slight uptick from last year, where the median and 90th percentile of unused JavaScript was 155 KB and 598 KB, respectively. All of this represents a _very_ large amount of unused JavaScript, especially when you consider that this analysis tracks the _transfer size_ of JavaScript resources which, if compressed, means that the decompressed portion of used JavaScript may be a lot larger than the graph suggests. + +When contrasted with the total number of bytes loaded for mobile pages at the median, unused JavaScript accounts for 35.1% of all loaded scripts. This is down slightly from last year's figure of 36.2%, but is still a significantly large chunk of bytes loaded that go unused. This suggests that many pages are loading scripts that may not be used on the current page, or are triggered by interactions later on in the page lifecycle, and may benefit from [dynamic `import()](#heading=h.iuwaswfmp5kv)` to reduce startup costs. + +## JavaScript requests per page + +Every resource on a page accounts for one request, and scripts are no different. When many scripts are loaded, it's reasonable to think that more bytes of JavaScript may be loaded as a result. + +{{ figure_markup( + image=".png", + caption="", + description="", + chart_url="", + sheets_gid="", + sql_file=".sql" + ) +}} + +_Figure 2.3. Distribution of the number of JavaScript requests per page._ + +In 2022, the median mobile page responded to 21 JavaScript requests, whereas at the 90th percentile, there were 60. Compared to last year, this is an increase of 1 request at the median and 4 requests at the 90th percentile. + +Where desktop devices in 2022 are concerned, there are 22 JavaScript requests at the median, and 63 at the 90th percentile. Compared to last year, this is an increase of 1 JavaScript request at the median, and 4 at the 90th percentile—the same increase as noted for mobile devices. + +While not a large increase in the number of requests, it does continue the trend of increased requests year over year since the Web Almanac's inception in 2019. + +## How is JavaScript processed? + +Since the advent of JavaScript runtimes such as Node.js, it has become increasingly common to rely on build tools in order to bundle and transform JavaScript. These tools—while undeniably useful—can have effects on how much JavaScript is shipped. New to the Web Almanac this year, we're presenting data on the usage of bundlers and transpilers. + +### Bundlers + +JavaScript bundlers are build-time tools that process a project's JavaScript source code and then apply transformations and optimizations to it. The output is production-ready JavaScript. Take the following code as an example: + +``` +function sum (a, b) { + return a + b; +} +``` + +A bundler will transform this code to a much smaller, but more optimized equivalent that takes less time for the browser to download: + +``` +function n(n,r){return n+r} +``` + +Given the optimizations bundlers perform, they are a crucial part of optimizing source code for better performance in production environments. + +There are a wealth of choices when it comes to JavaScript bundlers, but one that pops into mind often is webpack. Fortunately, webpack's generated JavaScript contains a number of signatures (`webpackJsonp`, for example) that make it possible to detect if a website's production JavaScript has been bundled using webpack. + +{{ figure_markup( + image=".png", + caption="", + description="", + chart_url="", + sheets_gid="", + sql_file=".sql" + ) +}} + +_Figure 2.4. Pages that use webpack-bundled JavaScript by rank._ + +Of the top 1000 pages, 17% use webpack as a bundler. This makes sense, as many of the top pages HTTP Archive crawls are likely to be high-profile ecommerce sites that use webpack to bundle and optimize source code. Even so, the fact that 5% of the all pages in the HTTP Archive dataset use webpack is a significant statistic. However, webpack isn't the only bundler in use. + +{{ figure_markup( + image=".png", + caption="", + description="", + chart_url="", + sheets_gid="", + sql_file=".sql" + ) +}} + +_Figure 2.5. Pages that use Parcel-bundled JavaScript by rank._ + +Parcel is a noteworthy alternative to webpack, and its adoption is significant. Parcel's adoption is consistent across all ranks, accounting for a range of 1.2% to 2.0% across rankings. + +While HTTP Archive is unable to track the usage of _all_ bundlers in the ecosystem, bundler usage is significant in the overall picture of JavaScript in that they're not only important to the developer experience, but the overhead they can contribute in the form of dependency management code can be a factor in how much JavaScript is shipped. It's worth checking your overall project settings are configured to produce the most efficient possible output for the browsers your users use. + +### Transpilers + +Transpilers are often used in toolchains at build time to transform newer JavaScript features into a syntax that can be run in older browsers. Because JavaScript has evolved rapidly over the years, these tools are still in use. New to this year's Web Almanac is an analysis of the usage of Babel in delivering widely compatible production-ready JavaScript. The singular focus on Babel specifically is due to its wide usage in the developer community over alternatives. + +{{ figure_markup( + image=".png", + caption="", + description="", + chart_url="", + sheets_gid="", + sql_file=".sql" + ) +}} + +_Figure 2.x. Pages that use Babel by rank._ + +These results are not a surprising development when you consider how much JavaScript has evolved over the years. In order to maintain broad compatibility for a certain set of browsers, Babel uses [transforms](https://babeljs.io/docs/en/babel-plugin-transform-runtime#why) to output compatible JavaScript code. + +Transforms are often larger than their untransformed counterparts. When transforms are extensive or duplicated across a codebase, potentially unnecessary or even unused JavaScript may be shipped to users. This can adversely affect performance. + +Considering that even 26% of pages ranked in the top million are transforming their JavaScript source code using Babel, it's not unreasonable to assume that some of these experiences may be shipping transforms they don't need. If you use Babel in your projects, carefully review [Babel's available configuration options](https://babeljs.io/docs/en/options) and plugins to find opportunities to optimize its output. + +Since Babel also relies on [Browserslist](https://github.com/browserslist/browserslist) to figure out whether it needs to transform certain features to a legacy syntax, be sure to also review your browerslist configuration to ensure that your code is transformed to work in the browsers your users actually use. + +## How is JavaScript requested? + +The manner in which JavaScript is requested may also have performance implications. There are optimal ways you can request JavaScript, and in some cases, there are far less optimal methods. Here, we'll see how the web is shipping JavaScript overall, and how that aligns with performance expectations. + +### async, defer, module, and nomodule + +The `async` and `defer` attributes on the HTML `