From 5177079daf1673143d882817da80f82864cc92b1 Mon Sep 17 00:00:00 2001 From: Noah van der Veer Date: Thu, 17 Dec 2020 22:27:23 +0100 Subject: [PATCH 1/7] Create javascript.md --- src/content/nl/2020/javascript.md | 782 ++++++++++++++++++++++++++++++ 1 file changed, 782 insertions(+) create mode 100644 src/content/nl/2020/javascript.md diff --git a/src/content/nl/2020/javascript.md b/src/content/nl/2020/javascript.md new file mode 100644 index 00000000000..bf7608aa0b6 --- /dev/null +++ b/src/content/nl/2020/javascript.md @@ -0,0 +1,782 @@ +--- +part_number: I +chapter_number: 2 +title: JavaScript +description: JavaScript chapter of the 2020 Web Almanac covering how much JavaScript we use on the web, compression, libraries and frameworks, loading, and source maps. +authors: [tkadlec] +reviewers: [ibnesayeed, denar90] +analysts: [rviscomi, paulcalvano] +translators: [] +tkadlec_bio: Tim is a web performance consultant and trainer focused on building a web everyone can use. He is the author of High Performance Images (O'Reilly, 2016) and Implementing Responsive Design (New Riders, 2012). He writes about all things web at timkadlec.com. You can find him sharing his thoughts in a briefer format on Twitter at @tkadlec. +discuss: 2038 +results: https://docs.google.com/spreadsheets/d/1cgXJrFH02SHPKDGD0AelaXAdB3UI7PIb5dlS0dxVtfY/ +queries: 02_JavaScript +featured_quote: JavaScript has come a long way from its humble origins as the last of the three web cornerstones—alongside CSS and HTML. Today, JavaScript has started to infiltrate a broad spectrum of the technical stack. It is no longer confined to the client-side and it's an increasingly popular choice for build tools and server-side scripting. JavaScript is also creeping its way into the CDN layer as well thanks to edge computing solutions. +featured_stat_1: 1,897ms +featured_stat_label_1: Median JS main thread time on mobile +featured_stat_2: 37.22% +featured_stat_label_2: Percentage of unused JS on mobile +featured_stat_3: 12.2% +featured_stat_label_3: Percentage of scripts loaded asynchronously +--- + +## Introduction + +JavaScript has come a long way from its humble origins as the last of the three web cornerstones—alongside CSS and HTML. Today, JavaScript has started to infiltrate a broad spectrum of the technical stack. It is no longer confined to the client-side and it's an increasingly popular choice for build tools and server-side scripting. JavaScript is also creeping its way into the CDN layer as well thanks to edge computing solutions. + +Developers love us some JavaScript. According to the Markup chapter, the `script` element is the [6th most popular HTML element](./markup) in use (ahead of elements like `p` and `i`, among countless others). We spend around 14 times as many bytes on it as we do on HTML, the building block of the web, and 6 times as many bytes as CSS. + +{{ figure_markup( + image="page-weight-per-content-type.png", + caption="Median page weight per content type.", + description="Bar chart showing the median page weight for desktop and mobile pages across images, JS, CSS, and HTML. The median amounts of bytes for each content type on mobile pages are: 916 KB of images, 411 KB of JS, 62 KB of CSS, and 25 KB of HTML. Desktop pages tend to have significantly heavier images (about 1000 KB) and slightly higher amounts of JS (about 450 KB).", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQlN4Clqeb8aPc63h0J58WfBxoJluSFT6kXn45JGPghw1LGU28hzabMYAATXNY5st9TtjKrr2HnbfGd/pubchart?oid=1147150650&format=interactive" +) }} + +But nothing is free, and that's especially true for JavaScript—all that code has a cost. Let's dig in and take a closer look at how much script we use, how we use it, and what the fallout is. + +## How much JavaScript do we use? + +We mentioned that the `script` tag is the 6th most used HTML element. Let's dig in a bit deeper to see just how much JavaScript that actually amounts to. + +The median site (the 50th percentile) sends 444 KB of JavaScript when loaded on a desktop device, and slightly fewer (411 KB) to a mobile device. + +{{ figure_markup( + image="page-weight-per-content-type.png", + caption="Distribution of the amount of JavaScript kilobytes loaded per page.", + description="Bar chart showing the distribution of JavaScript bytes per page by about 10%. Desktop pages consistently load more JavaScript bytes than mobile pages. The 10th, 25th, 50th, 75th, and 90th percentiles for desktop are: 87 KB, 209 KB, 444 KB, 826 KB, and 1,322 KB.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=441749673&format=interactive", + sheets_gid="2139688512", + sql_file="bytes_2020.sql" +) }} + +It's a bit disappointing that there isn't a bigger gap here. While it's dangerous to make too many assumptions about network or processing power based on whether the device in use is a phone or a desktop (or somewhere in between), it's worth noting that [HTTP Archive mobile tests](./methodology#webpagetest) are done by emulating a Moto G4 and a 3G network. In other words, if there was any work being done to adapt to less-than-ideal circumstances by passing down less code, these tests should be showing it. + +The trend also seems to be in favor of using more JavaScript, not less. Comparing to [last year's results](../2019/javascript#how-much-javascript-do-we-use), at the median we see a 13.4% increase in JavaScript as tested on a desktop device, and a 14.4% increase in the amount of JavaScript sent to a mobile device. + +
+ + + + + + + + + + + + + + + + + + + + + + + +
Client20192020Change
Desktop39144413.4%
Mobile35941114.4%
+
+ {{ figure_link( + caption="Year-over-year change in the median number of JavaScript kilobytes per page.", + sheets_gid="86213362", + sql_file="bytes_2020.sql" + ) }} +
+
+ +At least some of this weight seems to be unnecessary. If we look at a breakdown of how much of that JavaScript is unused on any given page load, we see that the median page is shipping 152 KB of unused JavaScript. That number jumps to 334 KB at the 75th percentile and 567 KB at the 90th percentile. + +{{ figure_markup( + image="unused-js-bytes-distribution.png", + caption="Distribution of the amount of wasted JavaScript bytes per mobile page.", + description="Bar chart showing the distribution of amount of wasted JavaScript bytes per page. From the 10, 25, 50, 75, and 90th percentiles, the distribution goes: 0, 57, 153, 335, and 568 KB.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=773002950&format=interactive", + sheets_gid="611267860", + sql_file="unused_js_bytes_distribution.sql" +) }} + +As raw numbers, those may or may not jump out at you depending on how much of a performance nut you are, but when you look at it as a percentage of the total JavaScript used on each page, it becomes a bit easier to see just how much waste we're sending. + +{{ figure_markup( + caption="Percent of the median mobile page's JavaScript bytes that are unused.", + content="37.22%", + classes="big-number", + sheets_gid="611267860", + sql_file="unused_js_bytes_distribution.sql" +) }} + +That 153 KB equates to ~37% of the total script size that we send down to mobile devices. There's definitely some room for improvement here. + +### `module` and `nomodule` +One mechanism we have to potentially reduce the amount of code we send down is to take advantage of the [`module`/`nomodule` pattern](https://web.dev/serve-modern-code-to-modern-browsers/). With this pattern, we create two sets of bundles: one bundle intended for modern browsers and one intended for legacy browsers. The bundle intended for modern browsers gets a `type=module` and the bundle intended for legacy browsers gets a `type=nomodule`. + +This approach lets us create smaller bundles with modern syntax optimized for the browsers that support it, while providing conditionally loaded polyfills and different syntax to the browsers that don't. + +Support for `module` and `nomodule` is broadening, but still relatively new. As a result, adoption is still a bit low. Only 3.6% of mobile pages use at least one script with `type=module` and only 0.7% of mobile pages use at least one script with `type=nomodule` to support legacy browsers. + +### Request count + +Another way of looking at how much JavaScript we use is to explore how many JavaScript requests are made on each page. While reducing the number of requests was paramount to maintaining good performance with HTTP/1.1, with HTTP/2 the opposite is the case: breaking JavaScript down into [smaller, individual files](https://web.dev/granular-chunking-nextjs/) is [typically better for performance](../2019/http2#impact-of-http2). + +{{ figure_markup( + image="requests-2020.png", + caption="Distribution of JavaScript requests per page.", + description="Bar chart showing the distribution of JavaScript requests per page in 2020. The 10, 25, 50, 75, and 90th percentiles for mobile pages are: 4, 10, 19, 34, and 55. Desktop pages only tend to have 0 or 1 more JavaScript request per page.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=153746548&format=interactive", + sheets_gid="1804671297", + sql_file="requests_2020.sql" +) }} + +At the median, pages make 20 JavaScript requests. That's only a minor increase over last year, when the median page made 19 JavaScript requests. + +{{ figure_markup( + image="requests-2019.png", + caption="Distribution of JavaScript requests per page in 2019.", + description="Bar chart showing the distribution of JavaScript requests per page in 2019. The 10, 25, 50, 75, and 90th percentiles for mobile pages are: 4, 9, 18, 32, and 52. Similar to the 2020 results, desktop pages only tend to have 0 or 1 more request per page. These results are slightly lower than the 2020 results.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=528431485&format=interactive", + sheets_gid="1983394384", + sql_file="requests_2019.sql" +) }} + +## Where does it come from? + +One trend that likely contributes to the increase in JavaScript used on our pages is the seemingly ever-increasing amount of third-party scripts that get added to pages to help with everything from client-side A/B testing and analytics, to serving ads and handling personalization. + +Let's drill into that a bit to see just how much third-party script we're serving up. + +Right up until the median, sites serve roughly the same number of first-party scripts as they do third-party scripts. At the median, 9 scripts per page are first-party, compared to 10 per page from third-parties. From there, the gap widens a bit: the more scripts a site serves in the total, the more likely it is that the majority of those scripts are from third-party sources. + +{{ figure_markup( + image="requests-by-3p-desktop.png", + caption="Distribution of the number of JavaScript requests by host for desktop.", + description="Bar chart showing the distribution of JavaScript requests per host for desktop. The 10, 25, 50, 75, and 90th percentiles for first party requests are: 2, 4, 9, 17, and 30 requests per page. The number of third party requests per page is slightly higher in the upper percentiles by 1 to 6 requests.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1566679225&format=interactive", + sheets_gid="978380311", + sql_file="requests_by_3p.sql" +) }} + +{{ figure_markup( + image="requests-by-3p-mobile.png", + caption="Distribution of the number of JavaScript requests by host for mobile.", + description="Bar chart showing the distribution of JavaScript requests per host for mobile. The 10, 25, 50, 75, and 90th percentiles for first party requests are: 2, 4, 9, 17, and 30 requests per page. This is the same as for desktop. The number of third party requests per page is slightly higher in the upper percentiles by 1 to 5 requests, similar to desktop.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1465647946&format=interactive", + sheets_gid="978380311", + sql_file="requests_by_3p.sql" +) }} + +While the amount of JavaScript requests are similar at the median, the actual size of those scripts is weighted (pun intended) a bit more heavily toward third-party sources. The median site sends 267 KB of JavaScript from third-parties to desktop devices ,compared to 147 KB from first-parties. The situation is very similar on mobile, where the median site ships 255 KB of third-party scripts compared to 134 KB of first-party scripts. + + +{{ figure_markup( + image="bytes-by-3p-desktop.png", + caption="Distribution of the number of JavaScript bytes by host for desktop.", + description="Bar chart showing the distribution of JavaScript bytes per host for desktop. The 10, 25, 50, 75, and 90th percentiles for first party bytes are: 21, 67, 147, 296, and 599 KB per page. The number of third party requests per page grows much higher in the upper percentiles by up to 343 KB.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1749995505&format=interactive", + sheets_gid="1145367011", + sql_file="bytes_by_3p.sql" +) }} + +{{ figure_markup( + image="bytes-by-3p-mobile.png", + caption="Distribution of the number of JavaScript bytes by host for mobile.", + description="Bar chart showing the distribution of JavaScript bytes per host for mobile. The 10, 25, 50, 75, and 90th percentiles for first party bytes are: 18, 60, 134, 275, and 560 KB. These values are consistently smaller than the desktop values, but only by 10-30 KB. Similar to desktop, the third party bytes are higher than first party, on mobile this difference is not as wide, only up to 328 KB at the 90th percentile.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=231883913&format=interactive", + sheets_gid="1145367011", + sql_file="bytes_by_3p.sql" +) }} + +## How do we load our JavaScript? + +The way we load JavaScript has a significant impact on the overall experience. + +By default, JavaScript is _parser-blocking_. In other words, when the browser discovers a `script` element, it must pause parsing of the HTML until the script has been downloaded, parsed, and executed. It's a significant bottleneck and a common contributor to pages that are slow to render. + +We can start to offset some of the cost of loading JavaScript by loading scripts either asynchronously (with the `async` attribute), which only halts the HTML parser during the parse and execution phases and not during the download phase, or deferred (with the `defer` attribute), which doesn't halt the HTML parser at all. Both attributes are only available on external scripts—inline scripts cannot have them applied. + +On mobile, external scripts comprise 59.0% of all script elements found. + +

+ As an aside, when we talked about how much JavaScript is loaded on a page earlier, that total didn't account for the size of these inline scripts—because they're part of the HTML document, they're counted against the markup size. This means we load even more script that the numbers show. +

+ +{{ figure_markup( + image="external-inline-mobile.png", + caption="Distribution of the number of external and inline scripts per mobile page.", + description="Pie chart showing 41.0% of mobile scripts are inline and 59.0% are external.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1326937127&format=interactive", + sheets_gid="1991661912", + sql_file="breakdown_of_scripts_using_async_defer_module_nomodule.sql" +) }} + +Of those external scripts, only 12.2% of them are loaded with the `async` attribute and 6.0% of them are loaded with the `defer` attribute. + +{{ figure_markup( + image="async-defer-mobile.png", + caption="Distribution of the number of `async` and `defer` scripts per mobile page.", + description="Pie chart showing 12.2% of external mobile scripts use async, 6.0% use defer, and 81.8% use neither.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=662584253&format=interactive", + sheets_gid="1991661912", + sql_file="breakdown_of_scripts_using_async_defer_module_nomodule.sql" +) }} + +Considering that `defer` provides us with the best loading performance (by ensuring downloading the script happens in parallel to other work, and execution waits until after the page can be displayed), we would hope to see that percentage a bit higher. In fact, as it is that 6.0% is slightly inflated. + +Back when supporting IE8 and IE9 was more common, it was relatively common to use _both_ the `async` and `defer` attributes. With both attributes in place, any browser supporting both will use `async`. IE8 and IE9, which don't support `async` will fall back to defer. + +Nowadays, the pattern is unnecessary for the vast majority of sites and any script loaded with the pattern in place will interrupt the HTML parser when it needs to be executed, instead of deferring until the page has loaded. The pattern is still used surprisingly often, with 11.4% of mobile pages serving at least one script with that pattern in place. In other words, at least some of the 6% of scripts that use `defer` aren't getting the full benefits of the `defer` attribute. + +There is an encouraging story here, though. + +Harry Roberts [tweeted about the antipattern on Twitter](https://twitter.com/csswizardry/status/1331721659498319873), which is what prompted us to check to see how frequently this was occurring in the wild. [Rick Viscomi checked to see who the top culprits were](https://twitter.com/rick_viscomi/status/1331735748060524551), and it turns out "stats.wp.com" was the source of the most common offenders. @Kraft from Automattic replied, and the pattern will now be [removed going forward](https://twitter.com/Kraft/status/1336772912414601224). + +One of the great things about the openness of the web is how one observation can lead to meaningful change and that's exactly what happened here. + +### Resource hints + +Another tool we have at our disposal for offsetting some of the network costs of loading JavaScript are [resource hints](./resource-hints), specifically, `prefetch` and `preload`. + +The `prefetch` hint lets developers signify that a resource will be used on the next page navigation, therefore the browser should try to download it when the browser is idle. + +The `preload` hint signifies that a resource will be used on the current page and that the browser should download it right away at a higher priority. + +Overall, we see 16.7% of mobile pages using at least one of the two resource hints to load JavaScript more proactively. + +Of those, nearly all of the usage is coming from `preload`. While 16.6% of mobile pages use at least one `preload` hint to load JavaScript, only 0.4% of mobile pages use at least one `prefetch` hint. + +There's a risk, particularly with `preload`, of using too many hints and reducing their effectiveness, so it's worth looking at the pages that do use these hints to see how many they're using. + +{{ figure_markup( + image="prefetch-distribution.png", + caption="Distribution of the number `prefetch` hints per page with any `prefetch` hints.", + description="Bar chart showing the distribution of prefetch hints per page with any prefetch hints. The 10, 25 and 50th percentiles for desktop and mobile pages is 1, 2, and 3 prefetch hints per page. At the 75th percentile for desktop pages it's 6 and 4 for mobile. At the 90th percentile, desktop pages use 14 prefetch hints per page and 12 for mobile pages.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1874381460&format=interactive", + sheets_gid="1910228743", + sql_file="resource-hints-preload-prefetch-distribution.sql" +) }} + +{{ figure_markup( + image="preload-distribution.png", + caption="Distribution of the number `preload` hints per page with any `preload` hints.", + description="Bar chart showing the distribution of preload hints per page with any preload hints. 75% of desktop and mobile pages that use preload hints use it exactly once. The 90th percentile is 5 preload hints per page for desktop and 7 for mobile.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=320533828&format=interactive", + sheets_gid="1910228743", + sql_file="resource-hints-preload-prefetch-distribution.sql" +) }} + +At the median, pages that use a `prefetch` hint to load JavaScript use three, while pages that use a `preload` hint only use one. The long tail gets a bit more interesting, with 12 `prefetch` hints used at the 90th percentile and 7 `preload` hints used on the 90th as well. For more detail on resource hints, check out this year's [Resource Hints](./resource-hints) chapter. + +## How do we serve JavaScript? + +As with any text-based resource on the web, we can save a significant number of bytes through minimization and compression. Neither of these are new optimizations—they've been around for quite awhile—so we should expect to see them applied in more cases than not. + +One of the audits in [Lighthouse](./methodology#lighthouse) checks for unminified JavaScript, and provides a score (0.00 being the worst, 1.00 being the best) based on the findings. + +{{ figure_markup( + image="lighthouse-unminified-js.png", + caption="Distribution of unminified JavaScript Lighthouse audit scores per mobile page.", + description="Bar chart showing 0% of mobile pages getting unminified JavaScript Lighthouse audit scores under 0.25, 4% of pages getting a score between 0.25 and 0.5, 10% of pages between 0.5 and 0.75, 8% of pages between 0.75 and 0.9, and 77% of pages between 0.9 and 1.0.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=158284816&format=interactive", + sheets_gid="362705605", + sql_file="lighthouse_unminified_js.sql" +) }} + +The chart above shows that most pages tested (77%) get a score of 0.90 or above, meaning that few unminified scripts are found. + +Overall, only 4.5% of the JavaScript requests recorded are unminified. + +Interestingly, while we've picked on third-party requests a bit, this is one area where third-party scripts are doing better than first-party scripts. 82% of the average mobile page's unminified JavaScript bytes come from first-party code. + +{{ figure_markup( + image="lighthouse-unminified-js-by-3p.png", + caption="Average distribution of unminified JavaScript bytes by host.", + description="Pie chart showing that 17.7% of unminified JS bytes are third party scripts and 82.3% are first party scripts.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=2073491355&format=interactive", + sheets_gid="1169731612", + sql_file="lighthouse_unminified_js_by_3p.sql" +) }} + +### Compression + +Minification is a great way to help reduce file size, but compression is even more effective and, therefore, more important—it provides the bulk of network savings more often than not. + +{{ figure_markup( + image="compression-method-request.png", + caption="Distribution of the percent of JavaScript requests by compression method.", + description="Bar chart showing the distribution of the percent of JavaScript requests by compression method. Desktop and mobile values are very similar. 65% of JavaScript requests use Gzip compression, 20% use br (Brotli), 15% don't use any compression, and deflate, UTF-8, identity, and none appear as having 0%", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=263239275&format=interactive", + sheets_gid="1270710983", + sql_file="compression_method.sql" +) }} + +85% of all JavaScript requests have some level of network compression applied. Gzip makes up the majority of that, with 65% of scripts having Gzip compression applied compared to 20% for Brotli (br). While the percentage of Brotli (which is more effective than Gzip) is low compared to its browser support, it's trending in the right direction, increasing by 5 percentage points in the last year. + +Once again, this appears to be an area where third-party scripts are actually doing better than first-party scripts. If we break the compression methods out by first- and third-party, we see that 24% of third-party scripts have Brotli applied, compared to only 15% of third-party scripts. + +{{ figure_markup( + image="compression-method-3p.png", + caption="Distribution of the percent of mobile JavaScript requests by compression method and host.", + description="Bar chart showing the distribution of the percent of mobile JavaScript requests by compression method and host. 66% and 64% of first and third party JavaScript requests use Gzip. 15% of first party and 24% of third party scripts requests use Brotli. And 19% of first party and 12% of third party scripts do not have a compression method set.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1402692197&format=interactive", + sheets_gid="564760060", + sql_file="compression_method_by_3p.sql" +) }} + +Third-party scripts are also least likely to be served without any compression at all: 12% of third-party scripts have neither Gzip nor Brotli applied, compared to 19% of first-party scripts. + +It's worth taking a closer look those scripts that _don't_ have compression applied. Compression becomes more efficient in terms of savings the more content it has to work with. In other words, if the file is tiny, sometimes the cost of compressing the file doesn't outweight the miniscule reduction in file size. + +{{ figure_markup( + caption="Percent of uncompressed third-party JavaScript requests under 5 KB.", + content="90.25%", + classes="big-number", + sheets_gid="347926930", + sql_file="compression_none_by_bytes.sql" +) }} + +Thankfully, that's exactly what we see, particularly in third-party scripts where 90% of uncompressed scripts are less than 5 KB in size. On the other hand, 49% of uncompressed first-party scripts are less than 5 KB and 37% of uncompressed first-party scripts are over 10 KB. So while we do see a lot of small uncompressed first-party scripts, there are still quite a few that would benefit from some compression. + +## What do we use? + +As we've increasingly used more JavaScript to power our sites and applications, there has also been an increasing demand for open-source libraries and frameworks to help with improving developer productivity and overall code maintainability. Sites that _don't_ wield one of these tools are definitely the minority on today's web—jQuery alone is found on nearly 85% of the mobile pages tracked by HTTP Archive. + +It's important that we think critically about the tools we use to build the web and what the trade-offs are, so it makes sense to look closely at what we see in use today. + +### Libraries + +HTTP Archive uses [Wappalyzer](./methodology#wappalyzer) to detect technologies in use on a given page. Wappalazyer tracks both JavaScript libraries (think of these as a collection of snippets or helper functions to ease development, like jQuery) and JavaScript frameworks (these are more likely scaffolding and provide templating and structure, like React). + +The popular libraries in use are largely unchanged from last year, with jQuery continuing to dominate usage and only one of the top 21 libraries falling out (lazy.js, replaced by DataTables). In fact, even the percentages of the top libraries has barely changed from last year. + +{# TODO(analysts): table? showing rank, library, percentage and last years rank #} + +{{ figure_markup( + image="frameworks-libraries.png", + caption="Adoption of the top JavaScript frameworks and libraries as a percent of pages.", + description="Bar chart showing the adoption of the top frameworks and libraries as a percent of pages (not page views or npm downloads). jQuery is the overwhelming leader, found on 83% of mobile pages. It's followed by jQuery migrate on 30%, jQuery UI on 21%, Modernizr on 15%, FancyBox on 7%, Slick and Lightbox on 6%, and the remaining frameworks and libraries on 4% or 3%: Moment.js, Underscore.js, Lodash, React, GSAP, Select2, RequireJS, and prettyPhoto.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=419887153&format=interactive", + sheets_gid="1654577118", + sql_file="frameworks_libraries.sql" +) }} + +Last year, [Houssein posited a few reasons for why jQuery's dominance continues](../2019/javascript#open-source-libraries-and-frameworks): + +> WordPress, which is used in more than 30% of sites, includes jQuery by default. +> Switching from jQuery to a newer client-side library can take time depending on how large an application is, and many sites may consist of jQuery in addition to newer client-side libraries. + +Both are very sound guesses, and it seems the situation hasn't changed much on either front. + +In fact, the dominance of jQuery is supported even further when you stop to consider that, of the top 10 libraries, 6 of them are either jQuery or require jQuery in order to be used: jQuery UI, jQuery Migrate, FancyBox, Lightbox and Slick. + +### Frameworks + +When we look at the frameworks, we also don't see much of a dramatic change in terms of adoption in the main frameworks that were highlighted last year. Vue.js has seen a significant increase, and AMP grew a bit, but most of them are more or less where they were a year ago. + +{# TODO(analysts): Compare same frameworks from last year's chapter to this year in bar chart? #} + +It's worth noting that the [detection issue that was noted last year still applies](https://github.com/AliasIO/wappalyzer/issues/2450), and still impacts the results here. It's possible that there _has_ been a significant change in popularity for a few more of these tools, but we just don't see it with the way the data is currently collected. + +### What it all means + +More interesting to us than the popularity of the tools themselves is the impact they have on the things we build. + +First, it's worth noting that while we may think of the usage of one tool versus another, in reality, we rarely only use a single library or framework in production. Only 21% of pages analyzed report only one library or framework. Two or three frameworks are pretty common, and the long-tail gets very long, very quickly. + +When we look at the common combinations that we see in production, most of them are to be expected. Knowing jQuery's dominance, it's unsurprising that most of the popular combinations include jQuery and any number of jQuery-related plugins. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CombinationsPages(%)
jQuery1,312,60120.7%
jQuery, jQuery Migrate658,62810.4%
jQuery, jQuery UI289,0744.6%
Modernizr, jQuery155,0822.4%
jQuery, jQuery Migrate, jQuery UI140,4662.2%
Modernizr, jQuery, jQuery Migrate85,2961.3%
FancyBox, jQuery84,3921.3%
Slick, jQuery72,5911.1%
GSAP, Lodash, React, RequireJS, Zepto61,9351.0%
Modernizr, jQuery, jQuery UI61,1521.0%
Lightbox, jQuery60,3951.0%
Modernizr, jQuery, jQuery Migrate, jQuery UI53,9240.8%
Slick, jQuery, jQuery Migrate51,6860.8%
Lightbox, jQuery, jQuery Migrate50,5570.8%
FancyBox, jQuery, jQuery UI44,1930.7%
Modernizr, YUI42,4890.7%
React, jQuery37,7530.6%
Moment.js, jQuery32,7930.5%
FancyBox, jQuery, jQuery Migrate31,2590.5%
MooTools, jQuery, jQuery Migrate28,7950.5%
+ +
+ {{ figure_link( + caption="The most popular combinations of libraries and frameworks on mobile pages.", + sheets_gid="795160444", + sql_file="frameworks_libraries_combos.sql" + ) }} +
+
+ +We do also see a fair amount of more "modern" frameworks like React, Vue, and Angular paired with jQuery, for example as a result of migration or inclusion by third-parties. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CombinationWithout jQueryWith jQuery
GSAP, Lodash, React, RequireJS, Zepto1.0% 
React, jQuery 0.6%
React0.4% 
React, jQuery, jQuery Migrate 0.4%
Vue.js, jQuery 0.3%
Vue.js0.2% 
AngularJS, jQuery 0.2%
GSAP, Hammer.js, Lodash, React, RequireJS, Zepto0.2% 
Grand Total1.7%1.4%
+
+ {{ figure_link( + caption="The most popular combinations of React, Angular, and Vue with and without jQuery.", + sheets_gid="795160444", + sql_file="frameworks_libraries_combos.sql" + ) }} +
+
+ +More importantly, all these tools typically mean more code and more processing time. + +Looking specifically at the frameworks in use, we see that the median JavaScript bytes for pages using them varies dramatically depending on _what_ is being used. + +The graph below shows the median bytes for pages where any of the top 35 most commonly detected frameworks were found, broken down by client. + +{{ figure_markup( + image="frameworks-bytes.png", + caption="The median number of JavaScript kilobytes per page by JavaScript framework.", + description="Bar chart showing the median number of JavaScript kilobytes per page broken down and sorted by JavaScript framework popularity. The most popular framework, React, has a median amount of JS at 1,328 on mobile pages. Other frameworks like RequireJS and Angular have high numbers of median JS bytes per page. Pages with MooTools, Prototype, AMP, RightJS, Alpine.js, and Svelte have medians under 500 KB per mobile page. Ember.js has an outlier of about 1,800 KB of median JS per mobile page.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=955720480&format=interactive", + sheets_gid="1206934500", + width="600", + height="835", + sql_file="frameworks-bytes-by-framework.sql" +) }} + +On one of the spectrum are frameworks like React or Angular or Ember, which tend to ship a lot of code regardless of the client. On the other end, we see minimalist frameworks like Alpine.js and Svelte showing very promising results. Defaults are very important, and it seems that by starting with highly performant defaults, Svelte and Alpine are both succeeding (so far… the sample size is pretty small) in creating a lighter set of pages. + +We get a very similar picture when looking at main thread time for pages where these tools were detected. + +{{ figure_markup( + image="frameworks-main-thread.png", + caption="The median main thread time per page by JavaScript framework.", + description="Bar chart showing the median main thread time by framework. It's hard to notice anything other than Ember.js, whose median mobile main thread time is over 20,000 milliseconds (20 seconds). The rest of the frameworks are tiny by comparison.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=691531699&format=interactive", + sheets_gid="160832134", + sql_file="main_thread_time_frameworks.sql" +) }} + +Ember's mobile main thread time jumps out and kind of distorts the graph with how long it takes. Pulling it out makes the picture a bit easier to understand. + +{{ figure_markup( + image="frameworks-main-thread-no-ember.png", + caption="The median main thread time per page by JavaScript framework, excluding Ember.js.", + description="Bar chart showing the median main thread time by framework, excluding Ember.js. Mobile main thread times are all higher due to the testing methodology of using slower CPU speeds for mobile. The most popular frameworks like React, GSAP, and RequireJS have high main thread times around 2-3 seconds for desktop and 5-7 seconds for mobile. Polymer also sticks out further down the popularity list. MooToos, Prototype, Alpine.js, and Svelte tend to have lower main thread times, under 2 seconds.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=77448759&format=interactive", + sheets_gid="160832134", + sql_file="main_thread_time_frameworks.sql" +) }} + +Tools like React, GSAP, and RequireJS tend to spend a lot of time on the main thread of the browser, regardless of whether it's a desktop or mobile page view. The same tools that tend to lead to less code overall—tools like Alpine and Svelte—also tend to lead to lower impact on the main thread. + +The gap between the experience a framework provides for desktop and mobile is also worth digging into. Mobile traffic is becoming increasingly dominant, and it's critical that our tools perform as well as possible for mobile pageviews. The bigger the gap we see between desktop and mobile performance for a framework, the bigger the red flag. + +{{ figure_markup( + image="frameworks-main-thread-no-ember-diff.png", + caption="Difference between desktop and mobile median main thread time per page by JavaScript framework, excluding Ember.js.", + description="Bar chart showing the absolute and relative differences between desktop and mobile's median main thread time per page by JavaScript framework, excluding Ember.js. Polymer jumps out later in the popularity list as having a high difference: about 5 seconds and 250% slower median main thread time on mobile pages than desktop pages. Other frameworks that stand out are GSAP and RequireJS has having a 4 second or 150% difference. Frameworks with the lowest difference are Mustache and RxJS, which are only about 20-30% slower on mobile.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1758266664&format=interactive", + sheets_gid="160832134", + sql_file="main_thread_time_frameworks.sql" +) }} + +As you would expect, there's a gap for all tools in use due to the lower processing power of the [emulated Moto G4](methodology#webpagetest). Ember and Polymer seem to jump out as particularly egregious examples, while tools like RxJS and Mustache vary only minorly from desktop to mobile. + +## What's the impact? + +We have a pretty good picture now of how much JavaScript we use, where it comes from, and what we use it for. While that's interesting enough on its own, the real kicker is the "so what?" What impact does all this script actually have on the experience of our pages? + +The first thing we should consider is what happens with all that JavaScript once its been downloaded. Downloading is only the first part of the JavaScript journey. The browser still has to parse all that script, compile it, and eventually execute it. While browsers are constantly on the lookout for ways to offload some of that cost to other threads, much of that work still happens on the main thread, blocking the browser from being able to do layout or paint-related work, as well as from being able to respond to user interaction. + +If you recall, there was only a 30 KB difference between what is shipped to a mobile device versus a desktop device. Depending on your point of view, you could be forgiven for not getting too upset about the small gap in the amount of code sent to a desktop browser versus a mobile one—after all, what's an extra 30 KB or so at the median, right? + +The biggest problem comes when all of that code gets served to a low-to-middle-end device, something a bit less like the kind of devices most developers are likely to have, and a bit more like the kind of devices you'll see from the majority of people across the world. That relatively small gap between desktop and mobile is much more dramatic when we look at it in terms of processing time. + +The median desktop site spends 891 ms on the main thread of a browser working with all that JavaScript. The median mobile site, however, spends 1,897 ms—over two times the time spent on the desktop. It's even worse for the long tail of sites. At the 90th percentile, mobile sites spend a staggering 8,921 ms of main thread time dealing with JavaScript, compared to 3,838 ms for desktop sites. + +{{ figure_markup( + image="main-thread-time.png", + caption="Distribution of main thread time.", + description="Bar chart showing the distribution of main thread time for desktop and mobile. Mobile is 2-3 times higher throughout the distribution. The 10, 25, 50, 75, and 90th percentiles for desktop are: 137, 356, 891, 1,988, and 3,838 milliseconds.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=740020507&format=interactive", + sheets_gid="2039579122", + sql_file="main_thread_time.sql" +) }} + +### Correlating JavaScript use to Lighthouse scoring + +One way of looking at how this translates into impacting the user experience is to try to correlate some of the JavaScript metrics we've identified earlier with Lighthouse scores for different metrics and categories. + +{{ figure_markup( + image="correlations.png", + caption="Correlations of JavaScript on various aspects of user experience.", + description="Bar chart showing the Pearson coefficient of correlation for various aspects of user experience. The correlation of bytes to the Lighthouse performance score has a coefficient of correlation of -0.47. Bytes and Lighthouse accessibility score: 0.08. Bytes and Total Blocking Time (TBT): 0.55. Third party bytes and Lighthouse performance score: -0.37. Third party bytes and the Lighthouse accessibility score: 0.00. Third party bytes and TBT: 0.48. The number of async scripts per page and Lighthouse performance score: -0.19. Async scripts and Lighthouse accessibility score: 0.08. Async scripts and TBT: 0.36.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=649523941&format=interactive", + sheets_gid="2035770638", + sql_file="correlations.sql" +) }} + +The above chart uses the [Pearson coefficient of correlation](https://en.wikipedia.org/wiki/Pearson_correlation_coefficient). There's a long, kinda complex definition of what that means precisely, but the gist is that we're looking for the strength of the correlation between two different numbers. If we find a coefficient of 1.00, we'd have a direct positive correlation. A correlation of 0.00 would show no connection between two numbers. Anything below 0.00 indicates a negative correlation—in other words, as one number goes up the other one decreases. + +First, there doesn't seem to be much of a measurable correlation between our JavaScript metrics and the Lighthouse accessibility ("LH A11y" in the chart) score here. That stands in stark opposition to what's been found elsewhere, notably through [WebAim's annual research](https://webaim.org/projects/million/#frameworks). + +The most likely explanation for this is that Lighthouse's accessibility tests aren't as comprehensive (yet!) as what is available through other tools, like WebAIM, that have accessibility as their primary focus. + +Where we do see a strong correlation is between the amount of JavaScript bytes ("Bytes") and both the overall Lighthouse performance ("LH Perf") score and Total Blocking Time ("TBT"). + +The correlation between JavaScript bytes and Lighthouse performance scores is -0.47. In other words, as JS bytes increase, Lighthouse performance scores decrease. The overall bytes has a stronger correlation than the amount of third-party bytes ("3P bytes"), hinting that while they certainly play a role, we can't place all the blame on third-parties. + +The connection between Total Blocking Time and JavaScript bytes is even more significant (0.55 for overall bytes, 0.48 for third-party bytes). That's not too surprising given what we know about all the work browsers have to do to get JavaScript to run in a page—more bytes means more time. + +### Security vulnerabilities + +One other helpful audit that Lighthouse runs is to check for known security vulnerabilities in third-party libraries. It does this by detecting which libraries and frameworks are used on a given page, and what version is used of each. Then it checks [Snyk's open-source vulnerability database](https://snyk.io/vuln?type=npm) to see what vulnerabilities have been discovered in the identified tools. + +{{ figure_markup( + caption="Percent of mobile pages contain at least one vulnerable JavaScript library.", + content="83.50%", + classes="big-number", + sheets_gid="1326928130", + sql_file="lighthouse_vulnerabilities.sql" +) }} + +According to the audit, 83.5% of mobile pages use a JavaScript library or framework with at least one known security vulnerability. + +This is what we call the jQuery effect. Remember how we saw that jQuery is used on a whopping 83% of pages? Several older versions of jQuery contain known vulnerabilities, which comprises the vast majority of the vulnerabilities this audit checks. + +Of the roughly 5 million or so mobile pages that are tested against, 81% of them contain a vulnerable version of jQuery—a sizeable lead over the second most commonly found vulnerable library—jQuery UI at 15.6%. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LibraryVulnerable pages
jQuery80.86%
jQuery UI15.61%
Bootstrap13.19%
Lodash4.90%
Moment.js2.61%
Handlebars1.38%
AngularJS1.26%
Mustache0.77%
Dojo0.58%
jQuery Mobile0.53%
+
+ {{ figure_link( + caption="Top 10 libraries contributing to the highest numbers of vulnerable mobile pages according to Lighthouse.", + sheets_gid="1803013938", + sql_file="lighthouse_vulnerable_libraries.sql" + ) }} +
+
+ + +In other words, if we can get folks to migrate away from those outdated, vulnerable versions of jQuery, we would see the number of sites with known vulnerabilities plummet (at least, until we start finding some in the newer frameworks). + +The bulk of the vulnerabilities found fall into the "medium" severity category. + +{{ figure_markup( + image="vulnerabilities-by-severity.png", + caption="Distribution of the percent of mobile pages having JavaScript vulnerabilities by severity.", + description="Pie chart showing 13.7% of mobile pages having no JavaScript vulnerabilities, 0.7% having low severity vulnerabilities, 69.1% having medium severity, and 16.4% having high severity.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1932740277&format=interactive", + sheets_gid="1409147642", + sql_file="lighthouse_vulnerabilities_by_severity.sql" +) }} + +## Conclusion + +JavaScript is steadily rising in popularity, and there's a lot that's positive about that. It's incredible to consider what we're able to accomplish on today's web thanks to JavaScript that, even a few years ago, would have been unimaginable. + +But it's clear we've also got to tread carefully. The amount of JavaScript consistently rises each year (if the stock market were that predictable, we'd all be incredibly wealthy), and that comes with trade-offs. More JavaScript is connected to an increase in processing time which negatively impacts key metrics like Total Blocking Time. And, if we let those libraries languish without keeping them updated, they carry the risk of exposing users through known security vulnerabilities. + +Carefully weighing the cost of the scripts we add to our pages and being willing to place a critical eye on our tools and ask more of them are our best bets for ensuring that we build a web that is accessible, performant, and safe. From 5df3cc47ec6949b344154462d8f96381ed7fee5d Mon Sep 17 00:00:00 2001 From: Noah van der Veer Date: Fri, 18 Dec 2020 22:15:04 +0100 Subject: [PATCH 2/7] finsihed translation of 2020/javascript in Dutch --- src/content/nl/2020/javascript.md | 538 +++++++++++++++--------------- 1 file changed, 269 insertions(+), 269 deletions(-) diff --git a/src/content/nl/2020/javascript.md b/src/content/nl/2020/javascript.md index bf7608aa0b6..40d8e036423 100644 --- a/src/content/nl/2020/javascript.md +++ b/src/content/nl/2020/javascript.md @@ -2,66 +2,66 @@ part_number: I chapter_number: 2 title: JavaScript -description: JavaScript chapter of the 2020 Web Almanac covering how much JavaScript we use on the web, compression, libraries and frameworks, loading, and source maps. +description: JavaScript-hoofdstuk van de Web Almanac 2020 waarin wordt beschreven hoeveel JavaScript we gebruiken op het web, compressie, bibliotheken en frameworks, laden en bronkaarten. authors: [tkadlec] reviewers: [ibnesayeed, denar90] analysts: [rviscomi, paulcalvano] -translators: [] -tkadlec_bio: Tim is a web performance consultant and trainer focused on building a web everyone can use. He is the author of High Performance Images (O'Reilly, 2016) and Implementing Responsive Design (New Riders, 2012). He writes about all things web at timkadlec.com. You can find him sharing his thoughts in a briefer format on Twitter at @tkadlec. +translators: [noah-vdv] +tkadlec_bio: Tim is een webprestatieadviseur en trainer gericht op het bouwen van een web dat iedereen kan gebruiken. Hij is de auteur van High Performance Images (O'Reilly, 2016) en Implementing Responsive Design (New Riders, 2012). Hij schrijft over alles wat met internet te maken heeft op timkadlec.com. Je kunt hem vinden op Twitter @tkadlec waar hij zijn gedachten in een beknopter formaat deelt. discuss: 2038 results: https://docs.google.com/spreadsheets/d/1cgXJrFH02SHPKDGD0AelaXAdB3UI7PIb5dlS0dxVtfY/ queries: 02_JavaScript -featured_quote: JavaScript has come a long way from its humble origins as the last of the three web cornerstones—alongside CSS and HTML. Today, JavaScript has started to infiltrate a broad spectrum of the technical stack. It is no longer confined to the client-side and it's an increasingly popular choice for build tools and server-side scripting. JavaScript is also creeping its way into the CDN layer as well thanks to edge computing solutions. +featured_quote: JavaScript heeft een lange weg afgelegd sinds zijn bescheiden oorsprong als de laatste van de drie web-hoekstenen, naast CSS en HTML. Tegenwoordig begint JavaScript een breed spectrum van de technische stack te infiltreren. Het is niet langer beperkt tot de client-side en het wordt een steeds populairdere keuze voor build-tools en server-side scripting. JavaScript sluipt ook zijn weg naar de CDN-laag dankzij edge computing-oplossingen. featured_stat_1: 1,897ms -featured_stat_label_1: Median JS main thread time on mobile -featured_stat_2: 37.22% -featured_stat_label_2: Percentage of unused JS on mobile -featured_stat_3: 12.2% -featured_stat_label_3: Percentage of scripts loaded asynchronously +featured_stat_label_1: Mediane JS-hoofdthread-tijd op mobiel +featured_stat_2: 37,22% +featured_stat_label_2: Percentage ongebruikte JS op mobiel +featured_stat_3: 12,2% +featured_stat_label_3: Percentage scripts dat asynchroon is geladen --- -## Introduction +## Introductie -JavaScript has come a long way from its humble origins as the last of the three web cornerstones—alongside CSS and HTML. Today, JavaScript has started to infiltrate a broad spectrum of the technical stack. It is no longer confined to the client-side and it's an increasingly popular choice for build tools and server-side scripting. JavaScript is also creeping its way into the CDN layer as well thanks to edge computing solutions. +JavaScript heeft een lange weg afgelegd sinds zijn bescheiden oorsprong als de laatste van de drie web-hoekstenen, naast CSS en HTML. Tegenwoordig begint JavaScript een breed spectrum van de technische stack te infiltreren. Het is niet langer beperkt tot de klantzijde en het wordt een steeds populairdere keuze voor build-tools en server-side scripting. JavaScript sluipt ook zijn weg naar de CDN-laag dankzij edge computing-oplossingen. -Developers love us some JavaScript. According to the Markup chapter, the `script` element is the [6th most popular HTML element](./markup) in use (ahead of elements like `p` and `i`, among countless others). We spend around 14 times as many bytes on it as we do on HTML, the building block of the web, and 6 times as many bytes as CSS. +Ontwikkelaars houden van wat JavaScript. Volgens het hoofdstuk Opmaak is het `script` -element het [6e meest populaire HTML-element](./markup) dat in gebruik is (vóór elementen zoals `p` en `i`, naast talloze andere). We besteden er ongeveer 14 keer zoveel bytes aan als aan HTML, de bouwsteen van het web, en 6 keer zoveel bytes als CSS. {{ figure_markup( image="page-weight-per-content-type.png", - caption="Median page weight per content type.", - description="Bar chart showing the median page weight for desktop and mobile pages across images, JS, CSS, and HTML. The median amounts of bytes for each content type on mobile pages are: 916 KB of images, 411 KB of JS, 62 KB of CSS, and 25 KB of HTML. Desktop pages tend to have significantly heavier images (about 1000 KB) and slightly higher amounts of JS (about 450 KB).", + caption="Mediane paginagewicht per inhoudstype.", + description="Staafdiagram met het gemiddelde paginagewicht voor desktop- en mobiele pagina's in afbeeldingen, JS, CSS en HTML. De gemiddelde hoeveelheid bytes voor elk inhoudstype op mobiele pagina's zijn: 916 KB afbeeldingen, 411 KB JS, 62 KB CSS en 25 KB HTML. Desktoppagina's hebben doorgaans aanzienlijk zwaardere afbeeldingen (ongeveer 1000 KB) en iets grotere hoeveelheden JS (ongeveer 450 KB).", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vQlN4Clqeb8aPc63h0J58WfBxoJluSFT6kXn45JGPghw1LGU28hzabMYAATXNY5st9TtjKrr2HnbfGd/pubchart?oid=1147150650&format=interactive" ) }} -But nothing is free, and that's especially true for JavaScript—all that code has a cost. Let's dig in and take a closer look at how much script we use, how we use it, and what the fallout is. +Maar niets is gratis, en dat geldt vooral voor JavaScript - al die code heeft een prijs. Laten we eens kijken hoeveel script we gebruiken, hoe we het gebruiken en wat de gevolgen zijn. -## How much JavaScript do we use? +## Hoeveel JavaScript gebruiken we? -We mentioned that the `script` tag is the 6th most used HTML element. Let's dig in a bit deeper to see just how much JavaScript that actually amounts to. +We zeiden dat de `script`-tag het 6e meest gebruikte HTML-element is. Laten we wat dieper graven om te zien hoeveel JavaScript dat eigenlijk is. -The median site (the 50th percentile) sends 444 KB of JavaScript when loaded on a desktop device, and slightly fewer (411 KB) to a mobile device. +De gemiddelde site (het 50e percentiel) verzendt 444 KB JavaScript wanneer deze op een desktopapparaat wordt geladen, en iets minder (411 KB) naar een mobiel apparaat. {{ figure_markup( image="page-weight-per-content-type.png", - caption="Distribution of the amount of JavaScript kilobytes loaded per page.", - description="Bar chart showing the distribution of JavaScript bytes per page by about 10%. Desktop pages consistently load more JavaScript bytes than mobile pages. The 10th, 25th, 50th, 75th, and 90th percentiles for desktop are: 87 KB, 209 KB, 444 KB, 826 KB, and 1,322 KB.", + caption="Verdeling van het aantal geladen JavaScript-kilobytes per pagina.", + description="Staafdiagram met de verdeling van JavaScript-bytes per pagina met ongeveer 10%. Desktoppagina's laden consequent meer JavaScript-bytes dan mobiele pagina's. Het 10e, 25e, 50e, 75e en 90e percentiel voor desktop zijn: 87 KB, 209 KB, 444 KB, 826 KB en 1.322 KB.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=441749673&format=interactive", sheets_gid="2139688512", sql_file="bytes_2020.sql" ) }} -It's a bit disappointing that there isn't a bigger gap here. While it's dangerous to make too many assumptions about network or processing power based on whether the device in use is a phone or a desktop (or somewhere in between), it's worth noting that [HTTP Archive mobile tests](./methodology#webpagetest) are done by emulating a Moto G4 and a 3G network. In other words, if there was any work being done to adapt to less-than-ideal circumstances by passing down less code, these tests should be showing it. +Het valt een beetje tegen dat er hier geen grotere kloof is. Hoewel het gevaarlijk is om te veel aannames te doen over netwerk- of verwerkingskracht op basis van of het gebruikte apparaat een telefoon of een desktop is (of ergens tussenin), is het vermeldenswaard dat [HTTP Archive mobiele tests](./methodology#webpagetest) worden gedaan door een Moto G4 en een 3G-netwerk te emuleren. Met andere woorden, als er werk werd verzet om zich aan te passen aan minder dan ideale omstandigheden door minder code door te geven, zouden deze tests dat moeten laten zien. -The trend also seems to be in favor of using more JavaScript, not less. Comparing to [last year's results](../2019/javascript#how-much-javascript-do-we-use), at the median we see a 13.4% increase in JavaScript as tested on a desktop device, and a 14.4% increase in the amount of JavaScript sent to a mobile device. +De trend lijkt ook in het voordeel te zijn van het gebruik van meer JavaScript, niet minder. In vergelijking met [de resultaten van vorig jaar](../2019/javascript#how-much-javascript-do-we-use), zien we bij de mediaan een toename van 13,4% in JavaScript zoals getest op een desktopapparaat, en een 14,4% toename van de hoeveelheid JavaScript die naar een mobiel apparaat wordt verzonden.
- + - + @@ -69,91 +69,91 @@ The trend also seems to be in favor of using more JavaScript, not less. Comparin - + - +
Clientklant 2019 2020ChangeVerandering
Desktop 391 44413.4%13,4%
Mobile 359 41114.4%14,4%
{{ figure_link( - caption="Year-over-year change in the median number of JavaScript kilobytes per page.", + caption="Jaar-op-jaar verandering in het mediaan aantal JavaScript-kilobytes per pagina.", sheets_gid="86213362", sql_file="bytes_2020.sql" ) }}
-At least some of this weight seems to be unnecessary. If we look at a breakdown of how much of that JavaScript is unused on any given page load, we see that the median page is shipping 152 KB of unused JavaScript. That number jumps to 334 KB at the 75th percentile and 567 KB at the 90th percentile. +Een deel van dit gewicht lijkt in ieder geval niet nodig te zijn. Als we kijken naar een uitsplitsing van hoeveel van dat JavaScript ongebruikt is bij het laden van een bepaalde pagina, zien we dat de mediaanpagina 152 KB ongebruikt JavaScript verzendt. Dat aantal springt naar 334 KB op het 75e percentiel en 567 KB op het 90e percentiel. {{ figure_markup( image="unused-js-bytes-distribution.png", - caption="Distribution of the amount of wasted JavaScript bytes per mobile page.", - description="Bar chart showing the distribution of amount of wasted JavaScript bytes per page. From the 10, 25, 50, 75, and 90th percentiles, the distribution goes: 0, 57, 153, 335, and 568 KB.", + caption="Verdeling van de hoeveelheid verspilde JavaScript-bytes per mobiele pagina.", + description="Staafdiagram met de verdeling van de hoeveelheid verspilde JavaScript-bytes per pagina. Van de 10, 25, 50, 75 en 90 percentielen gaat de distributie: 0, 57, 153, 335 en 568 KB.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=773002950&format=interactive", sheets_gid="611267860", sql_file="unused_js_bytes_distribution.sql" ) }} -As raw numbers, those may or may not jump out at you depending on how much of a performance nut you are, but when you look at it as a percentage of the total JavaScript used on each page, it becomes a bit easier to see just how much waste we're sending. +Als onbewerkte cijfers, kunnen die al dan niet naar je uitspringen, afhankelijk van hoeveel je van prestatie houdt, maar als je ernaar kijkt als een percentage van het totale JavaScript dat op elke pagina wordt gebruikt, wordt het een beetje gemakkelijker om te zien hoeveel afval we sturen. {{ figure_markup( - caption="Percent of the median mobile page's JavaScript bytes that are unused.", + caption="Percentage van de mediaan JavaScript-bytes van de mobiele pagina dat niet wordt gebruikt.", content="37.22%", classes="big-number", sheets_gid="611267860", sql_file="unused_js_bytes_distribution.sql" ) }} -That 153 KB equates to ~37% of the total script size that we send down to mobile devices. There's definitely some room for improvement here. +Die 153 KB komt overeen met ~ 37% van de totale scriptgrootte die we naar mobiele apparaten verzenden. Er is hier zeker ruimte voor verbetering. -### `module` and `nomodule` -One mechanism we have to potentially reduce the amount of code we send down is to take advantage of the [`module`/`nomodule` pattern](https://web.dev/serve-modern-code-to-modern-browsers/). With this pattern, we create two sets of bundles: one bundle intended for modern browsers and one intended for legacy browsers. The bundle intended for modern browsers gets a `type=module` and the bundle intended for legacy browsers gets a `type=nomodule`. +### `module` en `nomodule` +Een van de mechanismen die we hebben om de hoeveelheid code die we naar beneden sturen mogelijk te verminderen, is om te profiteren van het [`module` / `nomodule` patroon](https://web.dev/serve-modern-code-to-modern-browsers/). Met dit patroon maken we twee sets bundels: één bundel bedoeld voor moderne browsers en één bedoeld voor oudere browsers. De bundel bedoeld voor moderne browsers krijgt een `type=module` en de bundel bedoeld voor oudere browsers krijgt een `type=nomodule`. -This approach lets us create smaller bundles with modern syntax optimized for the browsers that support it, while providing conditionally loaded polyfills and different syntax to the browsers that don't. +Met deze benadering kunnen we kleinere bundels maken met moderne syntaxis die zijn geoptimaliseerd voor de browsers die dit ondersteunen, terwijl we voorwaardelijk geladen polyfills en verschillende syntaxis bieden aan de browsers die dat niet doen. -Support for `module` and `nomodule` is broadening, but still relatively new. As a result, adoption is still a bit low. Only 3.6% of mobile pages use at least one script with `type=module` and only 0.7% of mobile pages use at least one script with `type=nomodule` to support legacy browsers. +Ondersteuning voor `module` en `nomodule` wordt steeds breder, maar nog relatief nieuw. Als gevolg hiervan is de acceptatie nog steeds een beetje laag. Slechts 3,6% van de mobiele pagina's gebruikt ten minste één script met 'type=module' en slechts 0,7% van de mobiele pagina's gebruikt ten minste één script met `type=nomodule` om oudere browsers te ondersteunen. -### Request count +### Aantal aanvragen -Another way of looking at how much JavaScript we use is to explore how many JavaScript requests are made on each page. While reducing the number of requests was paramount to maintaining good performance with HTTP/1.1, with HTTP/2 the opposite is the case: breaking JavaScript down into [smaller, individual files](https://web.dev/granular-chunking-nextjs/) is [typically better for performance](../2019/http2#impact-of-http2). +Een andere manier om te kijken hoeveel JavaScript we gebruiken, is door te kijken hoeveel JavaScript-verzoeken er op elke pagina worden gedaan. Hoewel het verminderen van het aantal verzoeken van cruciaal belang was om goede prestaties te behouden met HTTP/1.1, is met HTTP/2 het tegenovergestelde het geval: JavaScript opsplitsen in [kleinere, individuele bestanden](https://web.dev/granular-chunking-nextjs/) is [doorgaans beter voor prestaties](../2019/http2#impact-of-http2). {{ figure_markup( image="requests-2020.png", - caption="Distribution of JavaScript requests per page.", - description="Bar chart showing the distribution of JavaScript requests per page in 2020. The 10, 25, 50, 75, and 90th percentiles for mobile pages are: 4, 10, 19, 34, and 55. Desktop pages only tend to have 0 or 1 more JavaScript request per page.", + caption="Verdeling van JavaScript-verzoeken per pagina.", + description="Staafdiagram met de verdeling van JavaScript-verzoeken per pagina in 2020. De 10, 25, 50, 75 en 90 percentielen voor mobiele pagina's zijn: 4, 10, 19, 34 en 55. Desktoppagina's hebben meestal alleen 0 of 1 meer JavaScript-verzoeken per pagina.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=153746548&format=interactive", sheets_gid="1804671297", sql_file="requests_2020.sql" ) }} -At the median, pages make 20 JavaScript requests. That's only a minor increase over last year, when the median page made 19 JavaScript requests. +Bij de mediaan doen pagina's 20 JavaScript-verzoeken. Dat is slechts een kleine stijging ten opzichte van vorig jaar, toen de mediaanpagina 19 JavaScript-verzoeken deed. {{ figure_markup( image="requests-2019.png", - caption="Distribution of JavaScript requests per page in 2019.", - description="Bar chart showing the distribution of JavaScript requests per page in 2019. The 10, 25, 50, 75, and 90th percentiles for mobile pages are: 4, 9, 18, 32, and 52. Similar to the 2020 results, desktop pages only tend to have 0 or 1 more request per page. These results are slightly lower than the 2020 results.", + caption="Verdeling van JavaScript-verzoeken per pagina in 2019.", + description="Staafdiagram met de verdeling van JavaScript-verzoeken per pagina in 2019. De 10, 25, 50, 75 en 90 percentielen voor mobiele pagina's zijn: 4, 9, 18, 32 en 52. Vergelijkbaar met de resultaten van 2020, alleen desktoppagina's hebben meestal 0 of 1 meer verzoeken per pagina. Deze resultaten zijn iets lager dan de resultaten van 2020.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=528431485&format=interactive", sheets_gid="1983394384", sql_file="requests_2019.sql" ) }} -## Where does it come from? +## Waar komt het vandaan? -One trend that likely contributes to the increase in JavaScript used on our pages is the seemingly ever-increasing amount of third-party scripts that get added to pages to help with everything from client-side A/B testing and analytics, to serving ads and handling personalization. +Een trend die waarschijnlijk bijdraagt aan de toename van JavaScript dat op onze pagina's wordt gebruikt, is het schijnbaar steeds groter wordende aantal scripts van derden dat aan pagina's wordt toegevoegd om te helpen met alles, van A / B-tests en analyses aan de klantzijde tot het weergeven van advertenties en omgaan met personalisatie. -Let's drill into that a bit to see just how much third-party script we're serving up. +Laten we daar een beetje op ingaan om te zien hoeveel script van derden we serveren. -Right up until the median, sites serve roughly the same number of first-party scripts as they do third-party scripts. At the median, 9 scripts per page are first-party, compared to 10 per page from third-parties. From there, the gap widens a bit: the more scripts a site serves in the total, the more likely it is that the majority of those scripts are from third-party sources. +Tot aan de mediaan gebruiken sites ongeveer hetzelfde aantal first-party scripts als scripts van derden. Bij de mediaan zijn 9 scripts per pagina first-party, vergeleken met 10 per pagina van derden. Vanaf daar wordt de kloof een beetje groter: hoe meer scripts een site in het totaal gebruikt, hoe waarschijnlijker het is dat de meerderheid van die scripts afkomstig is van externe bronnen. {{ figure_markup( image="requests-by-3p-desktop.png", - caption="Distribution of the number of JavaScript requests by host for desktop.", - description="Bar chart showing the distribution of JavaScript requests per host for desktop. The 10, 25, 50, 75, and 90th percentiles for first party requests are: 2, 4, 9, 17, and 30 requests per page. The number of third party requests per page is slightly higher in the upper percentiles by 1 to 6 requests.", + caption="Verdeling van het aantal JavaScript-verzoeken per host voor desktop.", + description="Staafdiagram met de verdeling van JavaScript-verzoeken per host voor desktop. De 10, 25, 50, 75 en 90 percentielen voor eerste partij-verzoeken zijn: 2, 4, 9, 17 en 30 verzoeken per pagina. Het aantal verzoeken van derden per pagina is iets hoger in de bovenste percentielen met 1 tot 6 verzoeken.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1566679225&format=interactive", sheets_gid="978380311", sql_file="requests_by_3p.sql" @@ -161,20 +161,20 @@ Right up until the median, sites serve roughly the same number of first-party sc {{ figure_markup( image="requests-by-3p-mobile.png", - caption="Distribution of the number of JavaScript requests by host for mobile.", - description="Bar chart showing the distribution of JavaScript requests per host for mobile. The 10, 25, 50, 75, and 90th percentiles for first party requests are: 2, 4, 9, 17, and 30 requests per page. This is the same as for desktop. The number of third party requests per page is slightly higher in the upper percentiles by 1 to 5 requests, similar to desktop.", + caption="Verdeling van het aantal JavaScript-verzoeken per host voor mobiel.", + description="Staafdiagram met de verdeling van JavaScript-verzoeken per host voor mobiel. De 10, 25, 50, 75 en 90 percentielen voor eerste partij-verzoeken zijn: 2, 4, 9, 17 en 30 verzoeken per pagina. Dit is hetzelfde als voor desktop. Het aantal verzoeken van derden per pagina is iets hoger in de bovenste percentielen met 1 tot 5 verzoeken, vergelijkbaar met desktop.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1465647946&format=interactive", sheets_gid="978380311", sql_file="requests_by_3p.sql" ) }} -While the amount of JavaScript requests are similar at the median, the actual size of those scripts is weighted (pun intended) a bit more heavily toward third-party sources. The median site sends 267 KB of JavaScript from third-parties to desktop devices ,compared to 147 KB from first-parties. The situation is very similar on mobile, where the median site ships 255 KB of third-party scripts compared to 134 KB of first-party scripts. +Hoewel het aantal JavaScript-verzoeken vergelijkbaar is bij de mediaan, wordt de werkelijke grootte van die scripts iets zwaarder gewogen (bedoelde woordspeling) ten opzichte van bronnen van derden. De gemiddelde site stuurt 267 KB JavaScript van derden naar desktopapparaten, vergeleken met 147 KB van eerste partijen. De situatie is vergelijkbaar op mobiele apparaten, waar de mediaan-site 255 KB aan scripts van derden verzendt, vergeleken met 134 KB aan eigen scripts. {{ figure_markup( image="bytes-by-3p-desktop.png", - caption="Distribution of the number of JavaScript bytes by host for desktop.", - description="Bar chart showing the distribution of JavaScript bytes per host for desktop. The 10, 25, 50, 75, and 90th percentiles for first party bytes are: 21, 67, 147, 296, and 599 KB per page. The number of third party requests per page grows much higher in the upper percentiles by up to 343 KB.", + caption="Verdeling van het aantal JavaScript-bytes per host voor desktop.", + description="Staafdiagram met de verdeling van JavaScript-bytes per host voor desktop. De 10, 25, 50, 75 en 90 percentielen voor eerste partij bytes zijn: 21, 67, 147, 296 en 599 KB per pagina. Het aantal verzoeken van derden per pagina stijgt veel hoger in de bovenste percentielen tot 343 KB.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1749995505&format=interactive", sheets_gid="1145367011", sql_file="bytes_by_3p.sql" @@ -182,77 +182,77 @@ While the amount of JavaScript requests are similar at the median, the actual si {{ figure_markup( image="bytes-by-3p-mobile.png", - caption="Distribution of the number of JavaScript bytes by host for mobile.", - description="Bar chart showing the distribution of JavaScript bytes per host for mobile. The 10, 25, 50, 75, and 90th percentiles for first party bytes are: 18, 60, 134, 275, and 560 KB. These values are consistently smaller than the desktop values, but only by 10-30 KB. Similar to desktop, the third party bytes are higher than first party, on mobile this difference is not as wide, only up to 328 KB at the 90th percentile.", + caption="Verdeling van het aantal JavaScript-bytes per host voor mobiel.", + description="Staafdiagram met de verdeling van JavaScript-bytes per host voor mobiel. De 10, 25, 50, 75 en 90 percentielen voor first party bytes zijn: 18, 60, 134, 275 en 560 KB. Deze waarden zijn constant kleiner dan de desktopwaarden, maar slechts 10-30 KB. Net als bij desktops zijn de bytes van derden hoger dan die van de eerste partij, op mobiel is dit verschil niet zo groot, slechts tot 328 KB bij het 90e percentiel.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=231883913&format=interactive", sheets_gid="1145367011", sql_file="bytes_by_3p.sql" ) }} -## How do we load our JavaScript? +## Hoe laden we ons JavaScript? -The way we load JavaScript has a significant impact on the overall experience. +De manier waarop we JavaScript laden, heeft een aanzienlijke invloed op de algehele ervaring. -By default, JavaScript is _parser-blocking_. In other words, when the browser discovers a `script` element, it must pause parsing of the HTML until the script has been downloaded, parsed, and executed. It's a significant bottleneck and a common contributor to pages that are slow to render. +JavaScript is standaard _parser-blokkerend_. Met andere woorden, wanneer de browser een `script`-element ontdekt, moet hij het parseren van de HTML pauzeren totdat het script is gedownload, geparseerd en uitgevoerd. Het is een aanzienlijk knelpunt en een veelvoorkomende oorzaak van pagina's die traag worden weergegeven. -We can start to offset some of the cost of loading JavaScript by loading scripts either asynchronously (with the `async` attribute), which only halts the HTML parser during the parse and execution phases and not during the download phase, or deferred (with the `defer` attribute), which doesn't halt the HTML parser at all. Both attributes are only available on external scripts—inline scripts cannot have them applied. +We kunnen beginnen met het compenseren van een deel van de kosten van het laden van JavaScript door scripts asynchroon te laden (met het `async`-attribuut), waardoor de HTML-parser alleen wordt gestopt tijdens de ontleed- en uitvoeringsfase en niet tijdens de downloadfase, of uitgesteld (met het `defer`-attribuut), wat de HTML-parser helemaal niet stopt. Beide attributen zijn alleen beschikbaar op externe scripts; inline scripts kunnen ze niet laten toepassen. -On mobile, external scripts comprise 59.0% of all script elements found. +Op mobiele apparaten omvatten externe scripts 59,0% van alle gevonden scriptelementen.

- As an aside, when we talked about how much JavaScript is loaded on a page earlier, that total didn't account for the size of these inline scripts—because they're part of the HTML document, they're counted against the markup size. This means we load even more script that the numbers show. + Even terzijde: toen we het hadden over hoeveel JavaScript eerder op een pagina is geladen, hield dat totaal geen rekening met de grootte van deze inline scripts - omdat ze deel uitmaken van het HTML-document, worden ze meegeteld bij de markup-grootte . Dit betekent dat we nog meer script laden dat de cijfers laten zien.

{{ figure_markup( image="external-inline-mobile.png", - caption="Distribution of the number of external and inline scripts per mobile page.", - description="Pie chart showing 41.0% of mobile scripts are inline and 59.0% are external.", + caption="Verdeling van het aantal externe en inline scripts per mobiele pagina.", + description="Cirkeldiagram laat zien dat 41,0% van de mobiele scripts inline is en 59,0% extern.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1326937127&format=interactive", sheets_gid="1991661912", sql_file="breakdown_of_scripts_using_async_defer_module_nomodule.sql" ) }} -Of those external scripts, only 12.2% of them are loaded with the `async` attribute and 6.0% of them are loaded with the `defer` attribute. +Van die externe scripts wordt slechts 12,2% geladen met het `async`-attribuut en 6,0% ervan wordt geladen met het `defer`-attribuut. {{ figure_markup( image="async-defer-mobile.png", - caption="Distribution of the number of `async` and `defer` scripts per mobile page.", - description="Pie chart showing 12.2% of external mobile scripts use async, 6.0% use defer, and 81.8% use neither.", + caption="Verdeling van het aantal `async` en `defer`-scripts per mobiele pagina.", + description="Cirkeldiagram dat laat zien dat 12,2% van de externe mobiele scripts asynchroon gebruikt, 6,0% gebruikt uitstel en 81,8% geen van beide.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=662584253&format=interactive", sheets_gid="1991661912", sql_file="breakdown_of_scripts_using_async_defer_module_nomodule.sql" ) }} -Considering that `defer` provides us with the best loading performance (by ensuring downloading the script happens in parallel to other work, and execution waits until after the page can be displayed), we would hope to see that percentage a bit higher. In fact, as it is that 6.0% is slightly inflated. +Gezien het feit dat `defer` ons de beste laadprestaties biedt (door ervoor te zorgen dat het downloaden van het script parallel met ander werk gebeurt, en de uitvoering wacht tot nadat de pagina kan worden weergegeven), hopen we dat dit percentage iets hoger ligt. In feite is die 6,0% lichtjes opgeblazen. -Back when supporting IE8 and IE9 was more common, it was relatively common to use _both_ the `async` and `defer` attributes. With both attributes in place, any browser supporting both will use `async`. IE8 and IE9, which don't support `async` will fall back to defer. +Toen het ondersteunen van IE8 en IE9 vaker voorkwam, was het relatief gebruikelijk om _allebei_ de `async`- en `defer`-attributen te gebruiken. Met beide attributen op hun plaats, zal elke browser die beide ondersteunt `async` gebruiken. IE8 en IE9, die `async` niet ondersteunen, vallen terug op `defer`. -Nowadays, the pattern is unnecessary for the vast majority of sites and any script loaded with the pattern in place will interrupt the HTML parser when it needs to be executed, instead of deferring until the page has loaded. The pattern is still used surprisingly often, with 11.4% of mobile pages serving at least one script with that pattern in place. In other words, at least some of the 6% of scripts that use `defer` aren't getting the full benefits of the `defer` attribute. +Tegenwoordig is het patroon voor de overgrote meerderheid van de sites niet nodig en elk script dat met het patroon wordt geladen, zal de HTML-parser onderbreken wanneer deze moet worden uitgevoerd, in plaats van uit te stellen totdat de pagina is geladen. Het patroon wordt nog steeds verrassend vaak gebruikt, met 11,4% van de mobiele pagina's die ten minste één script met dat patroon weergeven. Met andere woorden, ten minste enkele van de 6% van de scripts die `defer` gebruiken, profiteren niet van de volledige voordelen van het `defer`-attribuut. There is an encouraging story here, though. -Harry Roberts [tweeted about the antipattern on Twitter](https://twitter.com/csswizardry/status/1331721659498319873), which is what prompted us to check to see how frequently this was occurring in the wild. [Rick Viscomi checked to see who the top culprits were](https://twitter.com/rick_viscomi/status/1331735748060524551), and it turns out "stats.wp.com" was the source of the most common offenders. @Kraft from Automattic replied, and the pattern will now be [removed going forward](https://twitter.com/Kraft/status/1336772912414601224). +Harry Roberts [tweette over het antipatroon op Twitter](https://twitter.com/csswizardry/status/1331721659498319873), wat ons ertoe aanzette om te kijken hoe vaak dit in het wild voorkwam. [Rick Viscomi controleerde wie de grootste boosdoeners waren](https://twitter.com/rick_viscomi/status/1331735748060524551), en het blijkt dat "stats.wp.com" de bron was van de meest voorkomende overtreders. @Kraft van Automattic antwoordde, en het patroon wordt nu [in de toekomst verwijderd](https://twitter.com/Kraft/status/1336772912414601224). -One of the great things about the openness of the web is how one observation can lead to meaningful change and that's exactly what happened here. +Een van de geweldige dingen aan de openheid van het web is hoe één observatie kan leiden tot betekenisvolle verandering en dat is precies wat hier gebeurde. -### Resource hints +### Hulpbronnenhints -Another tool we have at our disposal for offsetting some of the network costs of loading JavaScript are [resource hints](./resource-hints), specifically, `prefetch` and `preload`. +Een ander hulpmiddel dat we tot onze beschikking hebben om een deel van de netwerkkosten voor het laden van JavaScript te compenseren, zijn [hulpbronnenhints](./resource-hints), in het bijzonder `prefetch` en `preload`. -The `prefetch` hint lets developers signify that a resource will be used on the next page navigation, therefore the browser should try to download it when the browser is idle. +Met de `prefetch`-hint kunnen ontwikkelaars aangeven dat een bron zal worden gebruikt bij de volgende paginanavigatie, daarom moet de browser proberen om het te downloaden wanneer de browser niet actief is. -The `preload` hint signifies that a resource will be used on the current page and that the browser should download it right away at a higher priority. +De `preload`-hint geeft aan dat een bron op de huidige pagina zal worden gebruikt en dat de browser deze meteen met een hogere prioriteit moet downloaden. -Overall, we see 16.7% of mobile pages using at least one of the two resource hints to load JavaScript more proactively. +In totaal zien we 16,7% van de mobiele pagina's die ten minste één van de twee bronhints gebruiken om JavaScript proactiever te laden. -Of those, nearly all of the usage is coming from `preload`. While 16.6% of mobile pages use at least one `preload` hint to load JavaScript, only 0.4% of mobile pages use at least one `prefetch` hint. +Daarvan is bijna al het gebruik afkomstig van `preload`. Terwijl 16,6% van de mobiele pagina's ten minste één `preload` hint gebruikt om JavaScript te laden, gebruikt slechts 0,4% van de mobiele pagina's ten minste één `prefetch`-hint. -There's a risk, particularly with `preload`, of using too many hints and reducing their effectiveness, so it's worth looking at the pages that do use these hints to see how many they're using. +Er is een risico, vooral bij `preload`, dat er te veel hints worden gebruikt en de effectiviteit ervan wordt verminderd, dus het is de moeite waard om naar de pagina's te kijken die deze hints gebruiken om te zien hoeveel ze gebruiken. {{ figure_markup( image="prefetch-distribution.png", - caption="Distribution of the number `prefetch` hints per page with any `prefetch` hints.", - description="Bar chart showing the distribution of prefetch hints per page with any prefetch hints. The 10, 25 and 50th percentiles for desktop and mobile pages is 1, 2, and 3 prefetch hints per page. At the 75th percentile for desktop pages it's 6 and 4 for mobile. At the 90th percentile, desktop pages use 14 prefetch hints per page and 12 for mobile pages.", + caption="Verdeling van het aantal `prefetch`-hints per pagina met eventuele `prefetch`-hints.", + description="Staafdiagram met de verdeling van `prefetch`-hints per pagina met eventuele `prefetch`-hints. Het 10, 25 en 50e percentiel voor desktop- en mobiele pagina's is 1, 2 en 3 `prefetch`-hints per pagina. Bij het 75e percentiel voor desktoppagina's is dat 6 en 4 voor mobiel. Op het 90e percentiel gebruiken desktoppagina's 14 `prefetch`-hints per pagina en 12 voor mobiele pagina's.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1874381460&format=interactive", sheets_gid="1910228743", sql_file="resource-hints-preload-prefetch-distribution.sql" @@ -260,335 +260,335 @@ There's a risk, particularly with `preload`, of using too many hints and reducin {{ figure_markup( image="preload-distribution.png", - caption="Distribution of the number `preload` hints per page with any `preload` hints.", - description="Bar chart showing the distribution of preload hints per page with any preload hints. 75% of desktop and mobile pages that use preload hints use it exactly once. The 90th percentile is 5 preload hints per page for desktop and 7 for mobile.", + caption="Verdeling van het aantal `preload`-hints per pagina met eventuele `preload`-hints.", + description="Staafdiagram met de verdeling van `preload` hints per pagina met eventuele `preload` hints. 75% van de desktop- en mobiele pagina's die `preload`-hints gebruiken, gebruikt dit precies één keer. Het 90e percentiel is 5 `preload` hints per pagina voor desktop en 7 voor mobiel.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=320533828&format=interactive", sheets_gid="1910228743", sql_file="resource-hints-preload-prefetch-distribution.sql" ) }} -At the median, pages that use a `prefetch` hint to load JavaScript use three, while pages that use a `preload` hint only use one. The long tail gets a bit more interesting, with 12 `prefetch` hints used at the 90th percentile and 7 `preload` hints used on the 90th as well. For more detail on resource hints, check out this year's [Resource Hints](./resource-hints) chapter. +Bij de mediaan gebruiken pagina's die een `prefetch`-hint gebruiken om JavaScript te laden er drie, terwijl pagina's die een `preload`-hint gebruiken er slechts één gebruiken. De lange staart wordt een beetje interessanter, met 12 `prefetch`-hints gebruikt op het 90e percentiel en 7 `preload`-hints die ook op de 90e worden gebruikt. Voor meer informatie over hulpbronnenhints, bekijk het hoofdstuk [Hulpbronnenhints](./resource-hints) van dit jaar. -## How do we serve JavaScript? +## Hoe serveren we JavaScript? -As with any text-based resource on the web, we can save a significant number of bytes through minimization and compression. Neither of these are new optimizations—they've been around for quite awhile—so we should expect to see them applied in more cases than not. +Zoals met elke op tekst gebaseerde bron op internet, kunnen we een aanzienlijk aantal bytes besparen door middel van minimalisatie en compressie. Dit zijn geen van beide nieuwe optimalisaties - ze bestaan al een tijdje - dus we zouden verwachten dat ze in meer gevallen worden toegepast dan niet. -One of the audits in [Lighthouse](./methodology#lighthouse) checks for unminified JavaScript, and provides a score (0.00 being the worst, 1.00 being the best) based on the findings. +Een van de audits in [Lighthouse](./methodology#lighthouse) controleert op niet-geminimaliseerd JavaScript en geeft een score (0,00 is de slechtste, 1,00 is de beste) op basis van de bevindingen. {{ figure_markup( image="lighthouse-unminified-js.png", - caption="Distribution of unminified JavaScript Lighthouse audit scores per mobile page.", - description="Bar chart showing 0% of mobile pages getting unminified JavaScript Lighthouse audit scores under 0.25, 4% of pages getting a score between 0.25 and 0.5, 10% of pages between 0.5 and 0.75, 8% of pages between 0.75 and 0.9, and 77% of pages between 0.9 and 1.0.", + caption="Verdeling van niet-verkleinde JavaScript Lighthouse-auditscores per mobiele pagina.", + description="Staafdiagram toont 0% van de mobiele pagina's die niet-verkleinde JavaScript krijgen Lighthouse-auditscores onder de 0,25, 4% van de pagina's met een score tussen 0,25 en 0,5, 10% van de pagina's tussen 0,5 en 0,75, 8% van de pagina's tussen 0,75 en 0,9 en 77% van de pagina's tussen 0.9 en 1.0.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=158284816&format=interactive", sheets_gid="362705605", sql_file="lighthouse_unminified_js.sql" ) }} -The chart above shows that most pages tested (77%) get a score of 0.90 or above, meaning that few unminified scripts are found. +De bovenstaande grafiek laat zien dat de meeste geteste pagina's (77%) een score van 0,90 of hoger halen, wat betekent dat er maar weinig niet-verkleinde scripts worden gevonden. -Overall, only 4.5% of the JavaScript requests recorded are unminified. +In totaal is slechts 4,5% van de geregistreerde JavaScript-verzoeken niet geminimaliseerd. -Interestingly, while we've picked on third-party requests a bit, this is one area where third-party scripts are doing better than first-party scripts. 82% of the average mobile page's unminified JavaScript bytes come from first-party code. +Interessant is dat, hoewel we een beetje hebben gekozen voor verzoeken van derden, dit een gebied is waar scripts van derden het beter doen dan scripts van eersten. 82% van de gemiddelde niet-verkleinde JavaScript-bytes van een mobiele pagina is afkomstig van eigen code. {{ figure_markup( image="lighthouse-unminified-js-by-3p.png", - caption="Average distribution of unminified JavaScript bytes by host.", - description="Pie chart showing that 17.7% of unminified JS bytes are third party scripts and 82.3% are first party scripts.", + caption="Gemiddelde distributie van niet-verkleinde JavaScript-bytes per host.", + description="Cirkeldiagram dat laat zien dat 17,7% van de niet-verkleinde JS-bytes scripts van derden zijn en 82,3% eigen scripts.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=2073491355&format=interactive", sheets_gid="1169731612", sql_file="lighthouse_unminified_js_by_3p.sql" ) }} -### Compression +### Compressie -Minification is a great way to help reduce file size, but compression is even more effective and, therefore, more important—it provides the bulk of network savings more often than not. +Minificatie is een geweldige manier om de bestandsgrootte te helpen verkleinen, maar compressie is nog effectiever en daarom belangrijker: het levert vaker wel dan niet het grootste deel van de netwerkbesparingen op. {{ figure_markup( image="compression-method-request.png", - caption="Distribution of the percent of JavaScript requests by compression method.", - description="Bar chart showing the distribution of the percent of JavaScript requests by compression method. Desktop and mobile values are very similar. 65% of JavaScript requests use Gzip compression, 20% use br (Brotli), 15% don't use any compression, and deflate, UTF-8, identity, and none appear as having 0%", + caption="Verdeling van het percentage JavaScript-verzoeken per compressiemethode.", + description="Staafdiagram met de verdeling van het percentage JavaScript-verzoeken per compressiemethode. De waarden voor desktop en mobiel lijken erg op elkaar. 65% van de JavaScript-verzoeken gebruikt Gzip-compressie, 20% gebruikt br (Brotli), 15% gebruikt geen compressie, en lopen leeg, UTF-8, identiteit, en geen enkele lijkt 0% te hebben", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=263239275&format=interactive", sheets_gid="1270710983", sql_file="compression_method.sql" ) }} -85% of all JavaScript requests have some level of network compression applied. Gzip makes up the majority of that, with 65% of scripts having Gzip compression applied compared to 20% for Brotli (br). While the percentage of Brotli (which is more effective than Gzip) is low compared to its browser support, it's trending in the right direction, increasing by 5 percentage points in the last year. +Bij 85% van alle JavaScript-verzoeken is een bepaald niveau van netwerkcompressie toegepast. Gzip maakt het grootste deel daarvan uit, met 65% van de scripts waarop Gzip-compressie is toegepast, vergeleken met 20% voor Brotli (br). Hoewel het percentage van Brotli (dat effectiever is dan Gzip) laag is in vergelijking met de browserondersteuning, gaat het in de goede richting, met een stijging van 5 procentpunten in het afgelopen jaar. -Once again, this appears to be an area where third-party scripts are actually doing better than first-party scripts. If we break the compression methods out by first- and third-party, we see that 24% of third-party scripts have Brotli applied, compared to only 15% of third-party scripts. +Nogmaals, dit lijkt een gebied te zijn waar scripts van derden het eigenlijk beter doen dan eerste partij scripts. Als we de compressiemethoden uitsplitsen door eerste en derde partij, zien we dat 24% van de scripts van derden Brotli heeft toegepast, vergeleken met slechts 15% van de scripts van derden. {{ figure_markup( image="compression-method-3p.png", - caption="Distribution of the percent of mobile JavaScript requests by compression method and host.", - description="Bar chart showing the distribution of the percent of mobile JavaScript requests by compression method and host. 66% and 64% of first and third party JavaScript requests use Gzip. 15% of first party and 24% of third party scripts requests use Brotli. And 19% of first party and 12% of third party scripts do not have a compression method set.", + caption="Verdeling van het percentage mobiele JavaScript-verzoeken per compressiemethode en host.", + description="Staafdiagram met de verdeling van het percentage mobiele JavaScript-verzoeken per compressiemethode en host. 66% en 64% van de JavaScript-verzoeken van eerste en derde partijen gebruiken Gzip. 15% van de eerste partij en 24% van de derden scriptverzoeken gebruikt Brotli. En 19% van de eerste partij scripts en 12% van de derden scripts hebben geen compressiemethode ingesteld.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1402692197&format=interactive", sheets_gid="564760060", sql_file="compression_method_by_3p.sql" ) }} -Third-party scripts are also least likely to be served without any compression at all: 12% of third-party scripts have neither Gzip nor Brotli applied, compared to 19% of first-party scripts. +Scripts van derden worden ook het minst waarschijnlijk zonder enige compressie aangeboden: 12% van de scripts van derden heeft noch Gzip noch Brotli toegepast, vergeleken met 19% van de eerste partij scripts. -It's worth taking a closer look those scripts that _don't_ have compression applied. Compression becomes more efficient in terms of savings the more content it has to work with. In other words, if the file is tiny, sometimes the cost of compressing the file doesn't outweight the miniscule reduction in file size. +Het is de moeite waard om die scripts die _geen_ compressie hebben van naderbij te bekijken. Compressie wordt efficiënter in termen van besparingen naarmate het meer inhoud moet gebruiken. Met andere woorden, als het bestand klein is, wegen de kosten voor het comprimeren van het bestand soms niet op tegen de minuscule verkleining van de bestandsgrootte. {{ figure_markup( - caption="Percent of uncompressed third-party JavaScript requests under 5 KB.", - content="90.25%", + caption="Percentage niet-gecomprimeerde JavaScript-verzoeken van derden onder 5 KB.", + content="90,25%", classes="big-number", sheets_gid="347926930", sql_file="compression_none_by_bytes.sql" ) }} -Thankfully, that's exactly what we see, particularly in third-party scripts where 90% of uncompressed scripts are less than 5 KB in size. On the other hand, 49% of uncompressed first-party scripts are less than 5 KB and 37% of uncompressed first-party scripts are over 10 KB. So while we do see a lot of small uncompressed first-party scripts, there are still quite a few that would benefit from some compression. +Gelukkig is dat precies wat we zien, vooral in scripts van derden, waar 90% van de niet-gecomprimeerde scripts minder dan 5 KB groot is. Aan de andere kant is 49% van de niet-gecomprimeerde eerste partij scripts minder dan 5 KB en 37% van de ongecomprimeerde eerste partij scripts groter dan 10 KB. Dus hoewel we veel kleine niet-gecomprimeerde eerste partij scripts zien, zijn er nog steeds een flink aantal die baat zouden hebben bij enige compressie. -## What do we use? +## Wat gebruiken we? -As we've increasingly used more JavaScript to power our sites and applications, there has also been an increasing demand for open-source libraries and frameworks to help with improving developer productivity and overall code maintainability. Sites that _don't_ wield one of these tools are definitely the minority on today's web—jQuery alone is found on nearly 85% of the mobile pages tracked by HTTP Archive. +Omdat we steeds meer JavaScript hebben gebruikt om onze sites en applicaties van stroom te voorzien, is er ook een toenemende vraag naar open-source bibliotheken en frameworks om de productiviteit van ontwikkelaars en de algehele onderhoudbaarheid van de code te verbeteren. Sites die _niet_ een van deze hulpmiddelen gebruiken, zijn beslist de minderheid op het internet van vandaag - jQuery alleen is te vinden op bijna 85% van de mobiele pagina's die worden bijgehouden door HTTP Archive. -It's important that we think critically about the tools we use to build the web and what the trade-offs are, so it makes sense to look closely at what we see in use today. +Het is belangrijk dat we kritisch nadenken over de hulpmidellen die we gebruiken om het web te bouwen en wat de afwegingen zijn, dus het is logisch om goed te kijken naar wat we vandaag in gebruik zien. -### Libraries +### Bibliotheken -HTTP Archive uses [Wappalyzer](./methodology#wappalyzer) to detect technologies in use on a given page. Wappalazyer tracks both JavaScript libraries (think of these as a collection of snippets or helper functions to ease development, like jQuery) and JavaScript frameworks (these are more likely scaffolding and provide templating and structure, like React). +HTTP Archive gebruikt [Wappalyzer](./methodology#wappalyzer) om technologieën te detecteren die op een bepaalde pagina worden gebruikt. Wappalazyer houdt zowel JavaScript-bibliotheken bij (zie deze als een verzameling fragmenten of helperfuncties om de ontwikkeling te vergemakkelijken, zoals jQuery) en JavaScript-frameworks (dit zijn waarschijnlijker steigers en bieden sjablonen en structuur, zoals React). -The popular libraries in use are largely unchanged from last year, with jQuery continuing to dominate usage and only one of the top 21 libraries falling out (lazy.js, replaced by DataTables). In fact, even the percentages of the top libraries has barely changed from last year. +De populaire bibliotheken die in gebruik zijn, zijn grotendeels ongewijzigd ten opzichte van vorig jaar, waarbij jQuery het gebruik blijft domineren en slechts één van de 21 beste bibliotheken valt uit (lazy.js, vervangen door DataTables). Zelfs de percentages van de topbibliotheken zijn nauwelijks veranderd ten opzichte van vorig jaar. {# TODO(analysts): table? showing rank, library, percentage and last years rank #} {{ figure_markup( image="frameworks-libraries.png", - caption="Adoption of the top JavaScript frameworks and libraries as a percent of pages.", - description="Bar chart showing the adoption of the top frameworks and libraries as a percent of pages (not page views or npm downloads). jQuery is the overwhelming leader, found on 83% of mobile pages. It's followed by jQuery migrate on 30%, jQuery UI on 21%, Modernizr on 15%, FancyBox on 7%, Slick and Lightbox on 6%, and the remaining frameworks and libraries on 4% or 3%: Moment.js, Underscore.js, Lodash, React, GSAP, Select2, RequireJS, and prettyPhoto.", + caption="Overname van de beste JavaScript-frameworks en -bibliotheken als percentage van de pagina's.", + description="Staafdiagram dat de acceptatie van de belangrijkste frameworks en bibliotheken weergeeft als percentage van de pagina's (niet paginaweergaven of npm-downloads). jQuery is de overweldigende leider, te vinden op 83% van de mobiele pagina's. Het wordt gevolgd door jQuery migrate op 30%, jQuery UI op 21%, Modernizr op 15%, FancyBox op 7%, Slick en Lightbox op 6%, en de resterende frameworks en bibliotheken op 4% of 3%: Moment.js, Underscore.js, Lodash, React, GSAP, Select2, RequireJS en prettyPhoto.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=419887153&format=interactive", sheets_gid="1654577118", sql_file="frameworks_libraries.sql" ) }} -Last year, [Houssein posited a few reasons for why jQuery's dominance continues](../2019/javascript#open-source-libraries-and-frameworks): +Vorig jaar stelde [Houssein een paar redenen voor waarom de dominantie van jQuery voortduurt](../2019/javascript#open-source-libraries-and-frameworks): -> WordPress, which is used in more than 30% of sites, includes jQuery by default. -> Switching from jQuery to a newer client-side library can take time depending on how large an application is, and many sites may consist of jQuery in addition to newer client-side libraries. +> WordPress, dat op meer dan 30% van de sites wordt gebruikt, bevat standaard jQuery. +> Het overschakelen van jQuery naar een nieuwere klantzijde bibliotheek kan enige tijd duren, afhankelijk van hoe groot een applicatie is, en veel sites kunnen bestaan uit jQuery naast nieuwere klantzijde bibliotheken. -Both are very sound guesses, and it seems the situation hasn't changed much on either front. +Beide zijn zeer goede gissingen, en het lijkt erop dat de situatie op geen van beide fronten veel is veranderd. -In fact, the dominance of jQuery is supported even further when you stop to consider that, of the top 10 libraries, 6 of them are either jQuery or require jQuery in order to be used: jQuery UI, jQuery Migrate, FancyBox, Lightbox and Slick. +In feite wordt de dominantie van jQuery nog verder ondersteund als je bedenkt dat van de top 10 bibliotheken er 6 jQuery zijn of jQuery nodig hebben om te kunnen worden gebruikt: jQuery UI, jQuery Migrate, FancyBox, Lightbox en Slick . ### Frameworks -When we look at the frameworks, we also don't see much of a dramatic change in terms of adoption in the main frameworks that were highlighted last year. Vue.js has seen a significant increase, and AMP grew a bit, but most of them are more or less where they were a year ago. +Als we naar de frameworks kijken, zien we ook niet veel van een dramatische verandering in termen van adoptie in de belangrijkste frameworks die vorig jaar naar voren kwamen. Vue.js heeft een aanzienlijke toename gezien en AMP is een beetje gegroeid, maar de meeste zijn min of meer waar ze een jaar geleden waren. {# TODO(analysts): Compare same frameworks from last year's chapter to this year in bar chart? #} -It's worth noting that the [detection issue that was noted last year still applies](https://github.com/AliasIO/wappalyzer/issues/2450), and still impacts the results here. It's possible that there _has_ been a significant change in popularity for a few more of these tools, but we just don't see it with the way the data is currently collected. +Het is vermeldenswaard dat het [detectieprobleem dat vorig jaar werd opgemerkt nog steeds van toepassing is](https://github.com/AliasIO/wappalyzer/issues/2450), en nog steeds van invloed is op de resultaten hier. Het is mogelijk dat er een aanzienlijke verandering in populariteit _is_ opgetreden voor nog een paar van deze hulpmddelen, maar we zien het gewoon niet met de manier waarop de gegevens momenteel worden verzameld. -### What it all means +### Wat het allemaal betekent -More interesting to us than the popularity of the tools themselves is the impact they have on the things we build. +Interessanter voor ons dan de populariteit van de hulpmiddelen zelf is de impact die ze hebben op de dingen die we bouwen. -First, it's worth noting that while we may think of the usage of one tool versus another, in reality, we rarely only use a single library or framework in production. Only 21% of pages analyzed report only one library or framework. Two or three frameworks are pretty common, and the long-tail gets very long, very quickly. +Ten eerste is het vermeldenswaard dat hoewel we misschien denken aan het gebruik van de ene hulpmiddel in plaats van de andere, we in werkelijkheid zelden slechts één enkele bibliotheek of framework gebruiken bij de productie. Slechts 21% van de geanalyseerde pagina's rapporteert slechts één bibliotheek of framework. Twee of drie frameworks komen vrij vaak voor, en de lange staart wordt erg lang, erg snel. -When we look at the common combinations that we see in production, most of them are to be expected. Knowing jQuery's dominance, it's unsurprising that most of the popular combinations include jQuery and any number of jQuery-related plugins. +Als we kijken naar de veel voorkomende combinaties die we in de productie zien, zijn de meeste te verwachten. Gezien de dominantie van jQuery, is het niet verwonderlijk dat de meeste populaire combinaties jQuery en een willekeurig aantal jQuery-gerelateerde plug-ins bevatten.
- - + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + + - - - + + +
CombinationsPagesCombinatiesPagina's (%)
jQuery1,312,60120.7%jQuery1.312.60120,7%
jQuery, jQuery Migrate658,62810.4%jQuery, jQuery Migrate658.62810,4%
jQuery, jQuery UI289,0744.6%jQuery, jQuery UI289.0744,6%
Modernizr, jQuery155,0822.4%Modernizr, jQuery155.0822,4%
jQuery, jQuery Migrate, jQuery UI140,4662.2%jQuery, jQuery Migrate, jQuery UI140.4662,2%
Modernizr, jQuery, jQuery Migrate85,2961.3%Modernizr, jQuery, jQuery Migrate85.2961,3%
FancyBox, jQuery84,3921.3%FancyBox, jQuery84.3921,3%
Slick, jQuery72,5911.1%Slick, jQuery72.5911,1%
GSAP, Lodash, React, RequireJS, Zepto61,9351.0%GSAP, Lodash, React, RequireJS, Zepto61.9351,0%
Modernizr, jQuery, jQuery UI61,1521.0%Modernizr, jQuery, jQuery UI61.1521,0%
Lightbox, jQuery60,3951.0%Lightbox, jQuery60.3951,0%
Modernizr, jQuery, jQuery Migrate, jQuery UI53,9240.8%Modernizr, jQuery, jQuery Migrate, jQuery UI53.9240,8%
Slick, jQuery, jQuery Migrate51,6860.8%Slick, jQuery, jQuery Migrate51.6860,8%
Lightbox, jQuery, jQuery Migrate50,5570.8%Lightbox, jQuery, jQuery Migrate50.5570,8%
FancyBox, jQuery, jQuery UI44,1930.7%FancyBox, jQuery, jQuery UI44.1930,7%
Modernizr, YUI42,4890.7%Modernizr, YUI42.4890,7%
React, jQuery37,7530.6%React, jQuery37.7530,6%
Moment.js, jQuery32,7930.5%Moment.js, jQuery32.7930,5%
FancyBox, jQuery, jQuery Migrate31,2590.5%FancyBox, jQuery, jQuery Migrate31.2590,5%
MooTools, jQuery, jQuery Migrate28,7950.5%MooTools, jQuery, jQuery Migrate28.7950,5%
{{ figure_link( - caption="The most popular combinations of libraries and frameworks on mobile pages.", + caption="De meest populaire combinaties van bibliotheken en frameworks op mobiele pagina's.", sheets_gid="795160444", sql_file="frameworks_libraries_combos.sql" ) }}
-We do also see a fair amount of more "modern" frameworks like React, Vue, and Angular paired with jQuery, for example as a result of migration or inclusion by third-parties. +We zien ook een behoorlijk aantal meer "moderne" frameworks zoals React, Vue en Angular in combinatie met jQuery, bijvoorbeeld als gevolg van migratie of opname door derden.
- - - + + + - + - + - + - + - + - + - + - + - - - + + +
CombinationWithout jQueryWith jQueryCombinatieZonder jQueryMet jQuery
GSAP, Lodash, React, RequireJS, Zepto1.0%1,0%  
React, jQuery  0.6%0,6%
React0.4%0,4%  
React, jQuery, jQuery Migrate  0.4%0,4%
Vue.js, jQuery  0.3%0,3%
Vue.js0.2%0,2%  
AngularJS, jQuery  0.2%0,2%
GSAP, Hammer.js, Lodash, React, RequireJS, Zepto0.2%0,2%  
Grand Total1.7%1.4%Eindtotaal1,7%1,4%
{{ figure_link( - caption="The most popular combinations of React, Angular, and Vue with and without jQuery.", + caption="De meest populaire combinaties van React, Angular en Vue met en zonder jQuery.", sheets_gid="795160444", sql_file="frameworks_libraries_combos.sql" ) }}
-More importantly, all these tools typically mean more code and more processing time. +Wat nog belangrijker is, al deze hulpmiddelen betekenen doorgaans meer code en meer verwerkingstijd. -Looking specifically at the frameworks in use, we see that the median JavaScript bytes for pages using them varies dramatically depending on _what_ is being used. +Als we specifiek naar de gebruikte frameworks kijken, zien we dat de mediaan JavaScript-bytes voor pagina's die deze gebruiken, enorm variëren, afhankelijk van _wat_ wordt gebruikt. -The graph below shows the median bytes for pages where any of the top 35 most commonly detected frameworks were found, broken down by client. +De onderstaande grafiek toont de mediaan bytes voor pagina's waar een van de top 35 meest gedetecteerde frameworks is gevonden, uitgesplitst naar client. {{ figure_markup( image="frameworks-bytes.png", - caption="The median number of JavaScript kilobytes per page by JavaScript framework.", - description="Bar chart showing the median number of JavaScript kilobytes per page broken down and sorted by JavaScript framework popularity. The most popular framework, React, has a median amount of JS at 1,328 on mobile pages. Other frameworks like RequireJS and Angular have high numbers of median JS bytes per page. Pages with MooTools, Prototype, AMP, RightJS, Alpine.js, and Svelte have medians under 500 KB per mobile page. Ember.js has an outlier of about 1,800 KB of median JS per mobile page.", + caption="Het gemiddelde aantal JavaScript-kilobytes per pagina door JavaScript-framework.", + description="Staafdiagram met het gemiddelde aantal JavaScript-kilobytes per pagina, uitgesplitst en gesorteerd op populariteit van het JavaScript-framework. Het meest populaire framework, React, heeft een mediaan van 1.328 JS op mobiele pagina's. Andere frameworks zoals RequireJS en Angular hebben een hoog aantal mediane JS-bytes per pagina. Pagina's met MooTools, Prototype, AMP, RightJS, Alpine.js en Svelte hebben medianen van minder dan 500 KB per mobiele pagina. Ember.js heeft een uitbijter van ongeveer 1.800 KB mediane JS per mobiele pagina.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=955720480&format=interactive", sheets_gid="1206934500", width="600", @@ -596,163 +596,163 @@ The graph below shows the median bytes for pages where any of the top 35 most co sql_file="frameworks-bytes-by-framework.sql" ) }} -On one of the spectrum are frameworks like React or Angular or Ember, which tend to ship a lot of code regardless of the client. On the other end, we see minimalist frameworks like Alpine.js and Svelte showing very promising results. Defaults are very important, and it seems that by starting with highly performant defaults, Svelte and Alpine are both succeeding (so far… the sample size is pretty small) in creating a lighter set of pages. +Op een van de spectrums staan frameworks zoals React of Angular of Ember, die de neiging hebben om veel code te verzenden, ongeacht de klant. Aan de andere kant zien we minimalistische frameworks zoals Alpine.js en Svelte veelbelovende resultaten laten zien. Defaults zijn erg belangrijk, en het lijkt erop dat Svelte en Alpine er allebei in slagen (tot dusver… de steekproefomvang is vrij klein) om een lichtere set pagina's te creëren door te beginnen met zeer performante defaults. -We get a very similar picture when looking at main thread time for pages where these tools were detected. +We krijgen een vergelijkbaar beeld als we kijken naar de hoofdthread-tijd voor pagina's waarop deze hulpmiddelen zijn gedetecteerd. {{ figure_markup( image="frameworks-main-thread.png", - caption="The median main thread time per page by JavaScript framework.", - description="Bar chart showing the median main thread time by framework. It's hard to notice anything other than Ember.js, whose median mobile main thread time is over 20,000 milliseconds (20 seconds). The rest of the frameworks are tiny by comparison.", + caption="De mediane hoofdthread-tijd per pagina door JavaScript-framework.", + description="Staafdiagram met de mediane hoofdthread-tijd per framework. Het is moeilijk om iets anders op te merken dan Ember.js, waarvan de mediane mobiele hoofdthread-tijd meer dan 20.000 milliseconden (20 seconden) is. De rest van de frameworks zijn in vergelijking klein.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=691531699&format=interactive", sheets_gid="160832134", sql_file="main_thread_time_frameworks.sql" ) }} -Ember's mobile main thread time jumps out and kind of distorts the graph with how long it takes. Pulling it out makes the picture a bit easier to understand. +Ember's mobiele hoofdthread-tijd springt eruit en vervormt de grafiek enigszins met hoe lang het duurt. Door het eruit te trekken, wordt de afbeelding een beetje gemakkelijker te begrijpen. {{ figure_markup( image="frameworks-main-thread-no-ember.png", - caption="The median main thread time per page by JavaScript framework, excluding Ember.js.", - description="Bar chart showing the median main thread time by framework, excluding Ember.js. Mobile main thread times are all higher due to the testing methodology of using slower CPU speeds for mobile. The most popular frameworks like React, GSAP, and RequireJS have high main thread times around 2-3 seconds for desktop and 5-7 seconds for mobile. Polymer also sticks out further down the popularity list. MooToos, Prototype, Alpine.js, and Svelte tend to have lower main thread times, under 2 seconds.", + caption="De mediane hoofdthread-tijd per pagina door JavaScript-framework, met uitzondering van Ember.js.", + description="Staafdiagram met de mediane hoofdthread-tijd per framework, exclusief Ember.js. De mobiele hoofdthread-tijden zijn allemaal hoger vanwege de testmethodologie van het gebruik van langzamere CPU-snelheden voor mobiel. De meest populaire frameworks zoals React, GSAP en RequireJS hebben hoge threads van ongeveer 2-3 seconden voor desktop en 5-7 seconden voor mobiel. Polymer valt ook verderop op de populariteitslijst op. MooToos, Prototype, Alpine.js en Svelte hebben meestal lagere hoofdthread-tijden, minder dan 2 seconden.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=77448759&format=interactive", sheets_gid="160832134", sql_file="main_thread_time_frameworks.sql" ) }} -Tools like React, GSAP, and RequireJS tend to spend a lot of time on the main thread of the browser, regardless of whether it's a desktop or mobile page view. The same tools that tend to lead to less code overall—tools like Alpine and Svelte—also tend to lead to lower impact on the main thread. +Hulpmiddelen zoals React, GSAP en RequireJS besteden vaak veel tijd aan de hoofdthread van de browser, ongeacht of het een desktop- of mobiele paginaweergave is. Dezelfde hulpmiddelen die in het algemeen tot minder code leiden - hulpmiddelen zoals Alpine en Svelte - hebben ook de neiging om de impact op de hoofdthread te verkleinen. -The gap between the experience a framework provides for desktop and mobile is also worth digging into. Mobile traffic is becoming increasingly dominant, and it's critical that our tools perform as well as possible for mobile pageviews. The bigger the gap we see between desktop and mobile performance for a framework, the bigger the red flag. +De kloof tussen de ervaring die een framework biedt voor desktop en mobiel, is ook de moeite waard om in te graven. Mobiel verkeer wordt steeds dominanter en het is van cruciaal belang dat onze hulpmiddelen zo goed mogelijk presteren voor mobiele paginaweergaven. Hoe groter de kloof die we zien tussen desktop- en mobiele prestaties voor een framework, hoe groter de rode vlag. {{ figure_markup( image="frameworks-main-thread-no-ember-diff.png", - caption="Difference between desktop and mobile median main thread time per page by JavaScript framework, excluding Ember.js.", - description="Bar chart showing the absolute and relative differences between desktop and mobile's median main thread time per page by JavaScript framework, excluding Ember.js. Polymer jumps out later in the popularity list as having a high difference: about 5 seconds and 250% slower median main thread time on mobile pages than desktop pages. Other frameworks that stand out are GSAP and RequireJS has having a 4 second or 150% difference. Frameworks with the lowest difference are Mustache and RxJS, which are only about 20-30% slower on mobile.", + caption="Verschil tussen de mediaan van de hoofdthread-tijd voor desktop en mobiel per pagina volgens JavaScript-framework, met uitzondering van Ember.js.", + description="Staafdiagram met de absolute en relatieve verschillen tussen de mediaan van de hoofdthread-tijd op desktop en mobiel per pagina volgens JavaScript-framework, met uitzondering van Ember.js. Polymer springt later in de populariteitslijst naar voren met een groot verschil: ongeveer 5 seconden en 250% langzamere mediane hoofdthread-tijd op mobiele pagina's dan op desktoppagina's. Andere frameworks die opvallen zijn GSAP en RequireJS heeft een verschil van 4 seconden of 150%. Frameworks met het laagste verschil zijn Mustache en RxJS, die slechts ongeveer 20-30% langzamer zijn op mobiel.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1758266664&format=interactive", sheets_gid="160832134", sql_file="main_thread_time_frameworks.sql" ) }} -As you would expect, there's a gap for all tools in use due to the lower processing power of the [emulated Moto G4](methodology#webpagetest). Ember and Polymer seem to jump out as particularly egregious examples, while tools like RxJS and Mustache vary only minorly from desktop to mobile. +Zoals je zou verwachten, is er een gat voor alle gebruikte hulpmiddelen vanwege de lagere verwerkingskracht van de [geëmuleerde Moto G4](methodology#webpagetest). Ember en Polymer lijken eruit te springen als bijzonder flagrante voorbeelden, terwijl hulpmiddelen zoals RxJS en Mustache slechts in geringe mate variëren van desktop tot mobiel. -## What's the impact? +## Wat is de impact? -We have a pretty good picture now of how much JavaScript we use, where it comes from, and what we use it for. While that's interesting enough on its own, the real kicker is the "so what?" What impact does all this script actually have on the experience of our pages? +We hebben nu een redelijk goed beeld van hoeveel JavaScript we gebruiken, waar het vandaan komt en waarvoor we het gebruiken. Hoewel dat op zichzelf al interessant genoeg is, is de echte kicker de "so what?" Welke impact heeft al dit script eigenlijk op de beleving van onze pagina's? -The first thing we should consider is what happens with all that JavaScript once its been downloaded. Downloading is only the first part of the JavaScript journey. The browser still has to parse all that script, compile it, and eventually execute it. While browsers are constantly on the lookout for ways to offload some of that cost to other threads, much of that work still happens on the main thread, blocking the browser from being able to do layout or paint-related work, as well as from being able to respond to user interaction. +Het eerste dat we moeten overwegen, is wat er gebeurt met al dat JavaScript nadat het is gedownload. Downloaden is slechts het eerste deel van de JavaScript-reis. De browser moet nog steeds al dat script ontleden, compileren en uiteindelijk uitvoeren. Hoewel browsers constant op zoek zijn naar manieren om een deel van die kosten over te dragen aan andere threads, gebeurt veel van dat werk nog steeds op de hoofdthread, waardoor de browser wordt geblokkeerd om lay-out- of verfgerelateerd werk te doen, en ook om te kunnen reageren op gebruikersinteractie. -If you recall, there was only a 30 KB difference between what is shipped to a mobile device versus a desktop device. Depending on your point of view, you could be forgiven for not getting too upset about the small gap in the amount of code sent to a desktop browser versus a mobile one—after all, what's an extra 30 KB or so at the median, right? +Als u zich herinnert, was er slechts een verschil van 30 KB tussen wat naar een mobiel apparaat wordt verzonden en een desktopapparaat. Afhankelijk van uw standpunt, zou het u kunnen worden vergeven dat u niet al te boos bent over het kleine verschil in de hoeveelheid code die naar een desktopbrowser wordt verzonden versus een mobiele browser - wat is tenslotte ongeveer 30 KB extra bij de mediaan? -The biggest problem comes when all of that code gets served to a low-to-middle-end device, something a bit less like the kind of devices most developers are likely to have, and a bit more like the kind of devices you'll see from the majority of people across the world. That relatively small gap between desktop and mobile is much more dramatic when we look at it in terms of processing time. +Het grootste probleem ontstaat wanneer al die code wordt geserveerd op een low-to-middle-end apparaat, iets minder dan het soort apparaten dat de meeste ontwikkelaars waarschijnlijk hebben, en een beetje meer het soort apparaten dat je zult hebben. zie van de meerderheid van de mensen over de hele wereld. Die relatief kleine kloof tussen desktop en mobiel is veel dramatischer als we ernaar kijken in termen van verwerkingstijd. -The median desktop site spends 891 ms on the main thread of a browser working with all that JavaScript. The median mobile site, however, spends 1,897 ms—over two times the time spent on the desktop. It's even worse for the long tail of sites. At the 90th percentile, mobile sites spend a staggering 8,921 ms of main thread time dealing with JavaScript, compared to 3,838 ms for desktop sites. +De gemiddelde desktopsite besteedt 891 ms aan de hoofdthread van een browser die met al dat JavaScript werkt. De gemiddelde mobiele site besteedt echter 1897 ms, meer dan twee keer de tijd die op de desktop wordt doorgebracht. Het is zelfs nog erger voor de lange staart van sites. Op het 90e percentiel besteden mobiele sites maar liefst 8.921 ms aan hoofdthread-tijd aan JavaScript, vergeleken met 3.838 ms voor desktopsites. {{ figure_markup( image="main-thread-time.png", - caption="Distribution of main thread time.", - description="Bar chart showing the distribution of main thread time for desktop and mobile. Mobile is 2-3 times higher throughout the distribution. The 10, 25, 50, 75, and 90th percentiles for desktop are: 137, 356, 891, 1,988, and 3,838 milliseconds.", + caption="Verdeling van de hoofdthread-tijd.", + description="Staafdiagram met de verdeling van de hoofdthread-tijd voor desktop en mobiel. Mobiel is 2-3 keer hoger tijdens de distributie. De 10, 25, 50, 75 en 90 percentielen voor desktop zijn: 137, 356, 891, 1.988 en 3.838 milliseconden.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=740020507&format=interactive", sheets_gid="2039579122", sql_file="main_thread_time.sql" ) }} -### Correlating JavaScript use to Lighthouse scoring +### Het correleren van JavaScript-gebruik met Lighthouse-scores -One way of looking at how this translates into impacting the user experience is to try to correlate some of the JavaScript metrics we've identified earlier with Lighthouse scores for different metrics and categories. +Een manier om te zien hoe dit zich vertaalt in het beïnvloeden van de gebruikerservaring, is door te proberen een aantal JavaScript-statistieken die we eerder hebben geïdentificeerd te correleren met Lighthouse-scores voor verschillende statistieken en categorieën. {{ figure_markup( image="correlations.png", - caption="Correlations of JavaScript on various aspects of user experience.", - description="Bar chart showing the Pearson coefficient of correlation for various aspects of user experience. The correlation of bytes to the Lighthouse performance score has a coefficient of correlation of -0.47. Bytes and Lighthouse accessibility score: 0.08. Bytes and Total Blocking Time (TBT): 0.55. Third party bytes and Lighthouse performance score: -0.37. Third party bytes and the Lighthouse accessibility score: 0.00. Third party bytes and TBT: 0.48. The number of async scripts per page and Lighthouse performance score: -0.19. Async scripts and Lighthouse accessibility score: 0.08. Async scripts and TBT: 0.36.", + caption="Correlaties van JavaScript op verschillende aspecten van gebruikerservaring.", + description="Staafdiagram met de Pearson-correlatiecoëfficiënt voor verschillende aspecten van gebruikerservaring. De correlatie van bytes met de prestatiescore van Lighthouse heeft een correlatiecoëfficiënt van -0,47. Bytes en Lighthouse toegankelijkheidsscore: 0,08. Bytes en Total Blocking Time (TBT): 0,55. Bytes van derden en prestatiescore van Lighthouse: -0,37. Bytes van derden en de toegankelijkheidsscore van Lighthouse: 0,00. Bytes van derden en TBT: 0,48. Het aantal asynchrone scripts per pagina en de prestatiescore van Lighthouse: -0,19. Asynchrone scripts en Lighthouse toegankelijkheidsscore: 0,08. Asynchrone scripts en TBT: 0,36.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=649523941&format=interactive", sheets_gid="2035770638", sql_file="correlations.sql" ) }} -The above chart uses the [Pearson coefficient of correlation](https://en.wikipedia.org/wiki/Pearson_correlation_coefficient). There's a long, kinda complex definition of what that means precisely, but the gist is that we're looking for the strength of the correlation between two different numbers. If we find a coefficient of 1.00, we'd have a direct positive correlation. A correlation of 0.00 would show no connection between two numbers. Anything below 0.00 indicates a negative correlation—in other words, as one number goes up the other one decreases. +De bovenstaande grafiek gebruikt de [Pearson correlatiecoëfficiënt](https://en.wikipedia.org/wiki/Pearson_correlation_coefficient). Er is een lange, nogal complexe definitie van wat dat precies betekent, maar de kern is dat we zoeken naar de sterkte van de correlatie tussen twee verschillende getallen. Als we een coëfficiënt van 1,00 vinden, hebben we een directe positieve correlatie. Een correlatie van 0,00 zou geen verband tussen twee getallen aantonen. Alles onder de 0,00 duidt op een negatieve correlatie - met andere woorden, als het ene getal stijgt, neemt het andere af. -First, there doesn't seem to be much of a measurable correlation between our JavaScript metrics and the Lighthouse accessibility ("LH A11y" in the chart) score here. That stands in stark opposition to what's been found elsewhere, notably through [WebAim's annual research](https://webaim.org/projects/million/#frameworks). +Ten eerste lijkt er niet echt een meetbare correlatie te bestaan tussen onze JavaScript-statistieken en de Lighthouse-score voor toegankelijkheid ("LH A11y" in de grafiek) hier. Dat staat in schril contrast met wat elders is gevonden, met name via [het jaarlijkse onderzoek van WebAim](https://webaim.org/projects/million/#frameworks). -The most likely explanation for this is that Lighthouse's accessibility tests aren't as comprehensive (yet!) as what is available through other tools, like WebAIM, that have accessibility as their primary focus. +De meest waarschijnlijke verklaring hiervoor is dat de toegankelijkheidstests van Lighthouse (nog!) Niet zo uitgebreid zijn als wat beschikbaar is via andere tools, zoals WebAIM, die toegankelijkheid als hun primaire focus hebben. -Where we do see a strong correlation is between the amount of JavaScript bytes ("Bytes") and both the overall Lighthouse performance ("LH Perf") score and Total Blocking Time ("TBT"). +Waar we wel een sterke correlatie zien, is tussen het aantal JavaScript-bytes ("Bytes") en zowel de algehele prestatie van Lighthouse ("LH Perf") score als de Total Blocking Time ("TBT"). -The correlation between JavaScript bytes and Lighthouse performance scores is -0.47. In other words, as JS bytes increase, Lighthouse performance scores decrease. The overall bytes has a stronger correlation than the amount of third-party bytes ("3P bytes"), hinting that while they certainly play a role, we can't place all the blame on third-parties. +De correlatie tussen JavaScript-bytes en de prestatiescores van Lighthouse is -0,47. Met andere woorden, naarmate JS-bytes toenemen, nemen de prestatiescores van Lighthouse af. De totale bytes hebben een sterkere correlatie dan het aantal bytes van derden ("3P bytes"), wat erop duidt dat hoewel ze zeker een rol spelen, we niet alle schuld bij derden kunnen leggen. -The connection between Total Blocking Time and JavaScript bytes is even more significant (0.55 for overall bytes, 0.48 for third-party bytes). That's not too surprising given what we know about all the work browsers have to do to get JavaScript to run in a page—more bytes means more time. +Het verband tussen de totale blokkeringstijd en JavaScript-bytes is zelfs nog belangrijker (0,55 voor totale bytes, 0,48 voor bytes van derden). Dat is niet zo verwonderlijk, gezien wat we weten over al het werk dat browsers moeten doen om JavaScript op een pagina te laten werken - meer bytes betekent meer tijd. -### Security vulnerabilities +### Beveiligingskwetsbaarheden -One other helpful audit that Lighthouse runs is to check for known security vulnerabilities in third-party libraries. It does this by detecting which libraries and frameworks are used on a given page, and what version is used of each. Then it checks [Snyk's open-source vulnerability database](https://snyk.io/vuln?type=npm) to see what vulnerabilities have been discovered in the identified tools. +Een andere nuttige audit die Lighthouse uitvoert, is om te controleren op bekende beveiligingsproblemen in bibliotheken van derden. Het doet dit door te detecteren welke bibliotheken en frameworks op een bepaalde pagina worden gebruikt en welke versie van elk wordt gebruikt. Vervolgens controleert het [Snyk's open-source kwetsbaarheidsdatabase](https://snyk.io/vuln?type=npm) om te zien welke kwetsbaarheden zijn ontdekt in de geïdentificeerde hulpmiddelen. {{ figure_markup( - caption="Percent of mobile pages contain at least one vulnerable JavaScript library.", - content="83.50%", + caption="Het percentage mobiele pagina's bevat ten minste één kwetsbare JavaScript-bibliotheek.", + content="83,50%", classes="big-number", sheets_gid="1326928130", sql_file="lighthouse_vulnerabilities.sql" ) }} -According to the audit, 83.5% of mobile pages use a JavaScript library or framework with at least one known security vulnerability. +Volgens de audit gebruikt 83,5% van de mobiele pagina's een JavaScript-bibliotheek of -framework met minstens één bekende beveiligingslek. -This is what we call the jQuery effect. Remember how we saw that jQuery is used on a whopping 83% of pages? Several older versions of jQuery contain known vulnerabilities, which comprises the vast majority of the vulnerabilities this audit checks. +Dit is wat we het jQuery-effect noemen. Weet je nog hoe we zagen dat jQuery op maar liefst 83% van de pagina's wordt gebruikt? Verschillende oudere versies van jQuery bevatten bekende kwetsbaarheden, die de overgrote meerderheid van de kwetsbaarheden omvatten die deze audit controleert. -Of the roughly 5 million or so mobile pages that are tested against, 81% of them contain a vulnerable version of jQuery—a sizeable lead over the second most commonly found vulnerable library—jQuery UI at 15.6%. +Van de ongeveer 5 miljoen mobiele pagina's waartegen wordt getest, bevat 81% een kwetsbare versie van jQuery - een aanzienlijke voorsprong op de tweede meest gevonden kwetsbare bibliotheek - jQuery UI met 15,6%.
- - + + - + - + - + - + - + - + - + - + - + - +
LibraryVulnerable pagesBibliotheekKwetsbare pagina's
jQuery80.86%80,86%
jQuery UI15.61%15,61%
Bootstrap13.19%13,19%
Lodash4.90%4,90%
Moment.js2.61%2,61%
Handlebars1.38%1,38%
AngularJS1.26%1,26%
Mustache0.77%0,77%
Dojo0.58%0,58%
jQuery Mobile0.53%0,53%
{{ figure_link( - caption="Top 10 libraries contributing to the highest numbers of vulnerable mobile pages according to Lighthouse.", + caption="Top 10 bibliotheken die volgens Lighthouse bijdragen aan het hoogste aantal kwetsbare mobiele pagina's.", sheets_gid="1803013938", sql_file="lighthouse_vulnerable_libraries.sql" ) }} @@ -760,23 +760,23 @@ Of the roughly 5 million or so mobile pages that are tested against, 81% of them
-In other words, if we can get folks to migrate away from those outdated, vulnerable versions of jQuery, we would see the number of sites with known vulnerabilities plummet (at least, until we start finding some in the newer frameworks). +Met andere woorden, als we mensen zover kunnen krijgen om weg te migreren van die verouderde, kwetsbare versies van jQuery, zouden we het aantal sites met bekende kwetsbaarheden zien dalen (tenminste, totdat we er enkele in de nieuwere frameworks beginnen te vinden). -The bulk of the vulnerabilities found fall into the "medium" severity category. +Het merendeel van de gevonden kwetsbaarheden valt in de categorie "gemiddeld". {{ figure_markup( image="vulnerabilities-by-severity.png", - caption="Distribution of the percent of mobile pages having JavaScript vulnerabilities by severity.", - description="Pie chart showing 13.7% of mobile pages having no JavaScript vulnerabilities, 0.7% having low severity vulnerabilities, 69.1% having medium severity, and 16.4% having high severity.", + caption="Verdeling van het percentage mobiele pagina's met JavaScript-kwetsbaarheden naar ernst.", + description="Cirkeldiagram toont 13,7% van de mobiele pagina's zonder JavaScript-kwetsbaarheden, 0,7% met zwakke kwetsbaarheden, 69,1% met middelmatige ernst en 16,4% met zeer ernstige kwetsbaarheden.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1932740277&format=interactive", sheets_gid="1409147642", sql_file="lighthouse_vulnerabilities_by_severity.sql" ) }} -## Conclusion +## Conclusie -JavaScript is steadily rising in popularity, and there's a lot that's positive about that. It's incredible to consider what we're able to accomplish on today's web thanks to JavaScript that, even a few years ago, would have been unimaginable. +JavaScript wordt gestaag populair, en daar is veel positiefs over. Het is ongelooflijk om te bedenken wat we dankzij JavaScript op het internet van vandaag kunnen bereiken, dat zelfs een paar jaar geleden onvoorstelbaar zou zijn geweest. -But it's clear we've also got to tread carefully. The amount of JavaScript consistently rises each year (if the stock market were that predictable, we'd all be incredibly wealthy), and that comes with trade-offs. More JavaScript is connected to an increase in processing time which negatively impacts key metrics like Total Blocking Time. And, if we let those libraries languish without keeping them updated, they carry the risk of exposing users through known security vulnerabilities. +Maar het is duidelijk dat we ook voorzichtig moeten zijn. De hoeveelheid JavaScript stijgt elk jaar consequent (als de aandelenmarkt zo voorspelbaar was, zouden we allemaal ongelooflijk rijk zijn), en dat komt met afwegingen. Meer JavaScript is verbonden met een toename van de verwerkingstijd, wat een negatief effect heeft op belangrijke statistieken zoals de totale blokkeringstijd. En als we die bibliotheken laten wegkwijnen zonder ze up-to-date te houden, lopen ze het risico gebruikers bloot te stellen aan bekende beveiligingsproblemen. -Carefully weighing the cost of the scripts we add to our pages and being willing to place a critical eye on our tools and ask more of them are our best bets for ensuring that we build a web that is accessible, performant, and safe. +Een zorgvuldige afweging van de kosten van de scripts die we aan onze pagina's toevoegen en bereid zijn om onze hulpmiddelen kritisch in de gaten te houden en er meer van te vragen, zijn onze beste weddenschappen om ervoor te zorgen dat we een web bouwen dat toegankelijk, performant en veilig is. From d8b5e82b5ca04a63e1a746d15fb751e7118b4b8e Mon Sep 17 00:00:00 2001 From: Noah van der Veer Date: Fri, 18 Dec 2020 23:25:48 +0100 Subject: [PATCH 3/7] double-checked for errors and added lang="en" --- src/content/nl/2020/javascript.md | 138 +++++++++++++++--------------- 1 file changed, 69 insertions(+), 69 deletions(-) diff --git a/src/content/nl/2020/javascript.md b/src/content/nl/2020/javascript.md index 40d8e036423..57378c63887 100644 --- a/src/content/nl/2020/javascript.md +++ b/src/content/nl/2020/javascript.md @@ -116,7 +116,7 @@ Een van de mechanismen die we hebben om de hoeveelheid code die we naar beneden Met deze benadering kunnen we kleinere bundels maken met moderne syntaxis die zijn geoptimaliseerd voor de browsers die dit ondersteunen, terwijl we voorwaardelijk geladen polyfills en verschillende syntaxis bieden aan de browsers die dat niet doen. -Ondersteuning voor `module` en `nomodule` wordt steeds breder, maar nog relatief nieuw. Als gevolg hiervan is de acceptatie nog steeds een beetje laag. Slechts 3,6% van de mobiele pagina's gebruikt ten minste één script met 'type=module' en slechts 0,7% van de mobiele pagina's gebruikt ten minste één script met `type=nomodule` om oudere browsers te ondersteunen. +Ondersteuning voor `module` en `nomodule` wordt steeds breder, maar nog relatief nieuw. Als gevolg hiervan is de acceptatie nog steeds een beetje laag. Slechts 3,6% van de mobiele pagina's gebruikt ten minste één script met `type=module` en slechts 0,7% van de mobiele pagina's gebruikt ten minste één script met `type=nomodule` om oudere browsers te ondersteunen. ### Aantal aanvragen @@ -144,11 +144,11 @@ Bij de mediaan doen pagina's 20 JavaScript-verzoeken. Dat is slechts een kleine ## Waar komt het vandaan? -Een trend die waarschijnlijk bijdraagt aan de toename van JavaScript dat op onze pagina's wordt gebruikt, is het schijnbaar steeds groter wordende aantal scripts van derden dat aan pagina's wordt toegevoegd om te helpen met alles, van A / B-tests en analyses aan de klantzijde tot het weergeven van advertenties en omgaan met personalisatie. +Een trend die waarschijnlijk bijdraagt aan de toename van JavaScript dat op onze pagina's wordt gebruikt, is het schijnbaar steeds groter wordende aantal scripts van derden dat aan pagina's wordt toegevoegd om te helpen met alles, van A/B-tests en analyses aan de klantzijde tot het weergeven van advertenties en omgaan met personalisatie. Laten we daar een beetje op ingaan om te zien hoeveel script van derden we serveren. -Tot aan de mediaan gebruiken sites ongeveer hetzelfde aantal first-party scripts als scripts van derden. Bij de mediaan zijn 9 scripts per pagina first-party, vergeleken met 10 per pagina van derden. Vanaf daar wordt de kloof een beetje groter: hoe meer scripts een site in het totaal gebruikt, hoe waarschijnlijker het is dat de meerderheid van die scripts afkomstig is van externe bronnen. +Tot aan de mediaan gebruiken sites ongeveer hetzelfde aantal eerste partij scripts als scripts van derden. Bij de mediaan zijn 9 scripts per pagina eerste partij, vergeleken met 10 per pagina van derden. Vanaf daar wordt de kloof een beetje groter: hoe meer scripts een site in het totaal gebruikt, hoe waarschijnlijker het is dat de meerderheid van die scripts afkomstig is van externe bronnen. {{ figure_markup( image="requests-by-3p-desktop.png", @@ -193,14 +193,14 @@ Hoewel het aantal JavaScript-verzoeken vergelijkbaar is bij de mediaan, wordt de De manier waarop we JavaScript laden, heeft een aanzienlijke invloed op de algehele ervaring. -JavaScript is standaard _parser-blokkerend_. Met andere woorden, wanneer de browser een `script`-element ontdekt, moet hij het parseren van de HTML pauzeren totdat het script is gedownload, geparseerd en uitgevoerd. Het is een aanzienlijk knelpunt en een veelvoorkomende oorzaak van pagina's die traag worden weergegeven. +JavaScript is standaard _parser-blokkerend_. Met andere woorden, wanneer de browser een `script`-element ontdekt, moet hij het ontleden van de HTML pauzeren totdat het script is gedownload, ontleed en uitgevoerd. Het is een aanzienlijk knelpunt en een veelvoorkomende oorzaak van pagina's die traag worden weergegeven. We kunnen beginnen met het compenseren van een deel van de kosten van het laden van JavaScript door scripts asynchroon te laden (met het `async`-attribuut), waardoor de HTML-parser alleen wordt gestopt tijdens de ontleed- en uitvoeringsfase en niet tijdens de downloadfase, of uitgesteld (met het `defer`-attribuut), wat de HTML-parser helemaal niet stopt. Beide attributen zijn alleen beschikbaar op externe scripts; inline scripts kunnen ze niet laten toepassen. Op mobiele apparaten omvatten externe scripts 59,0% van alle gevonden scriptelementen.

- Even terzijde: toen we het hadden over hoeveel JavaScript eerder op een pagina is geladen, hield dat totaal geen rekening met de grootte van deze inline scripts - omdat ze deel uitmaken van het HTML-document, worden ze meegeteld bij de markup-grootte . Dit betekent dat we nog meer script laden dat de cijfers laten zien. + Even terzijde: toen we het hadden over hoeveel JavaScript eerder op een pagina is geladen, hield dat totaal geen rekening met de grootte van deze inline scripts - omdat ze deel uitmaken van het HTML-document, worden ze meegeteld bij de opmaak-grootte . Dit betekent dat we nog meer script laden dat de cijfers laten zien.

{{ figure_markup( @@ -217,7 +217,7 @@ Van die externe scripts wordt slechts 12,2% geladen met het `async`-attribuut en {{ figure_markup( image="async-defer-mobile.png", caption="Verdeling van het aantal `async` en `defer`-scripts per mobiele pagina.", - description="Cirkeldiagram dat laat zien dat 12,2% van de externe mobiele scripts asynchroon gebruikt, 6,0% gebruikt uitstel en 81,8% geen van beide.", + description="Cirkeldiagram dat laat zien dat 12,2% van de externe mobiele scripts `async` gebruikt, 6,0% gebruikt `defer` en 81,8% geen van beide.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=662584253&format=interactive", sheets_gid="1991661912", sql_file="breakdown_of_scripts_using_async_defer_module_nomodule.sql" @@ -277,8 +277,8 @@ Een van de audits in [Lighthouse](./methodology#lighthouse) controleert op niet- {{ figure_markup( image="lighthouse-unminified-js.png", - caption="Verdeling van niet-verkleinde JavaScript Lighthouse-auditscores per mobiele pagina.", - description="Staafdiagram toont 0% van de mobiele pagina's die niet-verkleinde JavaScript krijgen Lighthouse-auditscores onder de 0,25, 4% van de pagina's met een score tussen 0,25 en 0,5, 10% van de pagina's tussen 0,5 en 0,75, 8% van de pagina's tussen 0,75 en 0,9 en 77% van de pagina's tussen 0.9 en 1.0.", + caption="Verdeling van niet-verkleinde JavaScript Lighthouse-auditscores per mobiele pagina.", + description="Staafdiagram toont 0% van de mobiele pagina's die niet-verkleinde JavaScript krijgen Lighthouse-auditscores onder de 0,25, 4% van de pagina's met een score tussen 0,25 en 0,5, 10% van de pagina's tussen 0,5 en 0,75, 8% van de pagina's tussen 0,75 en 0,9 en 77% van de pagina's tussen 0.9 en 1.0.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=158284816&format=interactive", sheets_gid="362705605", sql_file="lighthouse_unminified_js.sql" @@ -341,13 +341,13 @@ Gelukkig is dat precies wat we zien, vooral in scripts van derden, waar 90% van ## Wat gebruiken we? -Omdat we steeds meer JavaScript hebben gebruikt om onze sites en applicaties van stroom te voorzien, is er ook een toenemende vraag naar open-source bibliotheken en frameworks om de productiviteit van ontwikkelaars en de algehele onderhoudbaarheid van de code te verbeteren. Sites die _niet_ een van deze hulpmiddelen gebruiken, zijn beslist de minderheid op het internet van vandaag - jQuery alleen is te vinden op bijna 85% van de mobiele pagina's die worden bijgehouden door HTTP Archive. +Omdat we steeds meer JavaScript hebben gebruikt om onze sites en applicaties van stroom te voorzien, is er ook een toenemende vraag naar open-source bibliotheken en frameworks om de productiviteit van ontwikkelaars en de algehele onderhoudbaarheid van de code te verbeteren. Sites die _niet_ een van deze hulpmiddelen gebruiken, zijn beslist de minderheid op het internet van vandaag - jQuery alleen is te vinden op bijna 85% van de mobiele pagina's die worden bijgehouden door HTTP Archive. Het is belangrijk dat we kritisch nadenken over de hulpmidellen die we gebruiken om het web te bouwen en wat de afwegingen zijn, dus het is logisch om goed te kijken naar wat we vandaag in gebruik zien. ### Bibliotheken -HTTP Archive gebruikt [Wappalyzer](./methodology#wappalyzer) om technologieën te detecteren die op een bepaalde pagina worden gebruikt. Wappalazyer houdt zowel JavaScript-bibliotheken bij (zie deze als een verzameling fragmenten of helperfuncties om de ontwikkeling te vergemakkelijken, zoals jQuery) en JavaScript-frameworks (dit zijn waarschijnlijker steigers en bieden sjablonen en structuur, zoals React). +HTTP Archive gebruikt [Wappalyzer](./methodology#wappalyzer) om technologieën te detecteren die op een bepaalde pagina worden gebruikt. Wappalazyer houdt zowel JavaScript-bibliotheken bij (zie deze als een verzameling fragmenten of helperfuncties om de ontwikkeling te vergemakkelijken, zoals jQuery) en JavaScript-frameworks (dit zijn waarschijnlijker steigers en bieden sjablonen en structuur, zoals React). De populaire bibliotheken die in gebruik zijn, zijn grotendeels ongewijzigd ten opzichte van vorig jaar, waarbij jQuery het gebruik blijft domineren en slechts één van de 21 beste bibliotheken valt uit (lazy.js, vervangen door DataTables). Zelfs de percentages van de topbibliotheken zijn nauwelijks veranderd ten opzichte van vorig jaar. @@ -355,8 +355,8 @@ De populaire bibliotheken die in gebruik zijn, zijn grotendeels ongewijzigd ten {{ figure_markup( image="frameworks-libraries.png", - caption="Overname van de beste JavaScript-frameworks en -bibliotheken als percentage van de pagina's.", - description="Staafdiagram dat de acceptatie van de belangrijkste frameworks en bibliotheken weergeeft als percentage van de pagina's (niet paginaweergaven of npm-downloads). jQuery is de overweldigende leider, te vinden op 83% van de mobiele pagina's. Het wordt gevolgd door jQuery migrate op 30%, jQuery UI op 21%, Modernizr op 15%, FancyBox op 7%, Slick en Lightbox op 6%, en de resterende frameworks en bibliotheken op 4% of 3%: Moment.js, Underscore.js, Lodash, React, GSAP, Select2, RequireJS en prettyPhoto.", + caption="Overname van de beste JavaScript-frameworks en -bibliotheken als percentage van de pagina's.", + description="Staafdiagram dat de acceptatie van de belangrijkste frameworks en bibliotheken weergeeft als percentage van de pagina's (niet paginaweergaven of npm-downloads). jQuery is de overweldigende leider, te vinden op 83% van de mobiele pagina's. Het wordt gevolgd door jQuery migrate op 30%, jQuery UI op 21%, Modernizr op 15%, FancyBox op 7%, Slick en Lightbox op 6%, en de resterende frameworks en bibliotheken op 4% of 3%: Moment.js, Underscore.js, Lodash, React, GSAP, Select2, RequireJS en prettyPhoto.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=419887153&format=interactive", sheets_gid="1654577118", sql_file="frameworks_libraries.sql" @@ -371,9 +371,9 @@ Beide zijn zeer goede gissingen, en het lijkt erop dat de situatie op geen van b In feite wordt de dominantie van jQuery nog verder ondersteund als je bedenkt dat van de top 10 bibliotheken er 6 jQuery zijn of jQuery nodig hebben om te kunnen worden gebruikt: jQuery UI, jQuery Migrate, FancyBox, Lightbox en Slick . -### Frameworks +### Frameworks {frameworks} -Als we naar de frameworks kijken, zien we ook niet veel van een dramatische verandering in termen van adoptie in de belangrijkste frameworks die vorig jaar naar voren kwamen. Vue.js heeft een aanzienlijke toename gezien en AMP is een beetje gegroeid, maar de meeste zijn min of meer waar ze een jaar geleden waren. +Als we naar de frameworks kijken, zien we ook niet veel van een dramatische verandering in termen van adoptie in de belangrijkste frameworks die vorig jaar naar voren kwamen. Vue.js heeft een aanzienlijke toename gezien en AMP is een beetje gegroeid, maar de meeste zijn min of meer waar ze een jaar geleden waren. {# TODO(analysts): Compare same frameworks from last year's chapter to this year in bar chart? #} @@ -383,7 +383,7 @@ Het is vermeldenswaard dat het [detectieprobleem dat vorig jaar werd opgemerkt n Interessanter voor ons dan de populariteit van de hulpmiddelen zelf is de impact die ze hebben op de dingen die we bouwen. -Ten eerste is het vermeldenswaard dat hoewel we misschien denken aan het gebruik van de ene hulpmiddel in plaats van de andere, we in werkelijkheid zelden slechts één enkele bibliotheek of framework gebruiken bij de productie. Slechts 21% van de geanalyseerde pagina's rapporteert slechts één bibliotheek of framework. Twee of drie frameworks komen vrij vaak voor, en de lange staart wordt erg lang, erg snel. +Ten eerste is het vermeldenswaard dat hoewel we misschien denken aan het gebruik van de ene hulpmiddel in plaats van de andere, we in werkelijkheid zelden slechts één enkele bibliotheek of framework gebruiken bij de productie. Slechts 21% van de geanalyseerde pagina's rapporteert slechts één bibliotheek of framework. Twee of drie frameworks komen vrij vaak voor, en de lange staart wordt erg lang, erg snel. Als we kijken naar de veel voorkomende combinaties die we in de productie zien, zijn de meeste te verwachten. Gezien de dominantie van jQuery, is het niet verwonderlijk dat de meeste populaire combinaties jQuery en een willekeurig aantal jQuery-gerelateerde plug-ins bevatten. @@ -398,102 +398,102 @@ Als we kijken naar de veel voorkomende combinaties die we in de productie zien, - jQuery + jQuery 1.312.601 20,7% - jQuery, jQuery Migrate + jQuery, jQuery Migrate 658.628 10,4% - jQuery, jQuery UI + jQuery, jQuery UI 289.074 4,6% - Modernizr, jQuery + Modernizr, jQuery 155.082 2,4% - jQuery, jQuery Migrate, jQuery UI + jQuery, jQuery Migrate, jQuery UI 140.466 2,2% - Modernizr, jQuery, jQuery Migrate + Modernizr, jQuery, jQuery Migrate 85.296 1,3% - FancyBox, jQuery + FancyBox, jQuery 84.392 1,3% - Slick, jQuery + Slick, jQuery 72.591 1,1% - GSAP, Lodash, React, RequireJS, Zepto + GSAP, Lodash, React, RequireJS, Zepto 61.935 1,0% - Modernizr, jQuery, jQuery UI + Modernizr, jQuery, jQuery UI 61.152 1,0% - Lightbox, jQuery + Lightbox, jQuery 60.395 1,0% - Modernizr, jQuery, jQuery Migrate, jQuery UI + Modernizr, jQuery, jQuery Migrate, jQuery UI 53.924 0,8% - Slick, jQuery, jQuery Migrate + Slick, jQuery, jQuery Migrate 51.686 0,8% - Lightbox, jQuery, jQuery Migrate + Lightbox, jQuery, jQuery Migrate 50.557 0,8% - FancyBox, jQuery, jQuery UI + FancyBox, jQuery, jQuery UI 44.193 0,7% - Modernizr, YUI + Modernizr, YUI 42.489 0,7% - React, jQuery + React, jQuery 37.753 0,6% - Moment.js, jQuery + Moment.js, jQuery 32.793 0,5% - FancyBox, jQuery, jQuery Migrate + FancyBox, jQuery, jQuery Migrate 31.259 0,5% - MooTools, jQuery, jQuery Migrate + MooTools, jQuery, jQuery Migrate 28.795 0,5% @@ -502,14 +502,14 @@ Als we kijken naar de veel voorkomende combinaties die we in de productie zien,
{{ figure_link( - caption="De meest populaire combinaties van bibliotheken en frameworks op mobiele pagina's.", + caption="De meest populaire combinaties van bibliotheken en frameworks op mobiele pagina's.", sheets_gid="795160444", sql_file="frameworks_libraries_combos.sql" ) }}
-We zien ook een behoorlijk aantal meer "moderne" frameworks zoals React, Vue en Angular in combinatie met jQuery, bijvoorbeeld als gevolg van migratie of opname door derden. +We zien ook een behoorlijk aantal meer "moderne" frameworks zoals React, Vue en Angular in combinatie met jQuery, bijvoorbeeld als gevolg van migratie of opname door derden.
@@ -522,7 +522,7 @@ We zien ook een behoorlijk aantal meer "moderne" frameworks zoals React, Vue en - + @@ -537,7 +537,7 @@ We zien ook een behoorlijk aantal meer "moderne" frameworks zoals React, Vue en - + @@ -557,7 +557,7 @@ We zien ook een behoorlijk aantal meer "moderne" frameworks zoals React, Vue en - + @@ -581,14 +581,14 @@ We zien ook een behoorlijk aantal meer "moderne" frameworks zoals React, Vue en Wat nog belangrijker is, al deze hulpmiddelen betekenen doorgaans meer code en meer verwerkingstijd. -Als we specifiek naar de gebruikte frameworks kijken, zien we dat de mediaan JavaScript-bytes voor pagina's die deze gebruiken, enorm variëren, afhankelijk van _wat_ wordt gebruikt. +Als we specifiek naar de gebruikte frameworks kijken, zien we dat de mediaan JavaScript-bytes voor pagina's die deze gebruiken, enorm variëren, afhankelijk van _wat_ wordt gebruikt. -De onderstaande grafiek toont de mediaan bytes voor pagina's waar een van de top 35 meest gedetecteerde frameworks is gevonden, uitgesplitst naar client. +De onderstaande grafiek toont de mediaan bytes voor pagina's waar een van de top 35 meest gedetecteerde frameworks is gevonden, uitgesplitst naar client. {{ figure_markup( image="frameworks-bytes.png", - caption="Het gemiddelde aantal JavaScript-kilobytes per pagina door JavaScript-framework.", - description="Staafdiagram met het gemiddelde aantal JavaScript-kilobytes per pagina, uitgesplitst en gesorteerd op populariteit van het JavaScript-framework. Het meest populaire framework, React, heeft een mediaan van 1.328 JS op mobiele pagina's. Andere frameworks zoals RequireJS en Angular hebben een hoog aantal mediane JS-bytes per pagina. Pagina's met MooTools, Prototype, AMP, RightJS, Alpine.js en Svelte hebben medianen van minder dan 500 KB per mobiele pagina. Ember.js heeft een uitbijter van ongeveer 1.800 KB mediane JS per mobiele pagina.", + caption="Het gemiddelde aantal JavaScript-kilobytes per pagina door JavaScript-framework.", + description="Staafdiagram met het gemiddelde aantal JavaScript-kilobytes per pagina, uitgesplitst en gesorteerd op populariteit van het JavaScript-framework. Het meest populaire framework, React, heeft een mediaan van 1.328 JS op mobiele pagina's. Andere frameworks zoals RequireJS en Angular hebben een hoog aantal mediane JS-bytes per pagina. Pagina's met MooTools, Prototype, AMP, RightJS, Alpine.js en Svelte hebben medianen van minder dan 500 KB per mobiele pagina. Ember.js heeft een uitbijter van ongeveer 1.800 KB mediane JS per mobiele pagina.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=955720480&format=interactive", sheets_gid="1206934500", width="600", @@ -596,14 +596,14 @@ De onderstaande grafiek toont de mediaan bytes voor pagina's waar een van de top sql_file="frameworks-bytes-by-framework.sql" ) }} -Op een van de spectrums staan frameworks zoals React of Angular of Ember, die de neiging hebben om veel code te verzenden, ongeacht de klant. Aan de andere kant zien we minimalistische frameworks zoals Alpine.js en Svelte veelbelovende resultaten laten zien. Defaults zijn erg belangrijk, en het lijkt erop dat Svelte en Alpine er allebei in slagen (tot dusver… de steekproefomvang is vrij klein) om een lichtere set pagina's te creëren door te beginnen met zeer performante defaults. +Op één van de spectrums staan frameworks zoals React of Angular of Ember, die de neiging hebben om veel code te verzenden, ongeacht de klant. Aan de andere kant zien we minimalistische frameworks zoals Alpine.js en Svelte veelbelovende resultaten laten zien. Standaarden zijn erg belangrijk, en het lijkt erop dat Svelte en Alpine er allebei in slagen (tot dusver… is de steekproefomvang vrij klein) om een lichtere set pagina's te creëren door te beginnen met zeer performante standaarden. We krijgen een vergelijkbaar beeld als we kijken naar de hoofdthread-tijd voor pagina's waarop deze hulpmiddelen zijn gedetecteerd. {{ figure_markup( image="frameworks-main-thread.png", - caption="De mediane hoofdthread-tijd per pagina door JavaScript-framework.", - description="Staafdiagram met de mediane hoofdthread-tijd per framework. Het is moeilijk om iets anders op te merken dan Ember.js, waarvan de mediane mobiele hoofdthread-tijd meer dan 20.000 milliseconden (20 seconden) is. De rest van de frameworks zijn in vergelijking klein.", + caption="De mediane hoofdthread-tijd per pagina door JavaScript-framework.", + description="Staafdiagram met de mediane hoofdthread-tijd per framework. Het is moeilijk om iets anders op te merken dan Ember.js, waarvan de mediane mobiele hoofdthread-tijd meer dan 20.000 milliseconden (20 seconden) is. De rest van de frameworks zijn in vergelijking klein.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=691531699&format=interactive", sheets_gid="160832134", sql_file="main_thread_time_frameworks.sql" @@ -613,21 +613,21 @@ Ember's mobiele hoofdthread-tijd springt eruit en vervormt de grafiek enigszins {{ figure_markup( image="frameworks-main-thread-no-ember.png", - caption="De mediane hoofdthread-tijd per pagina door JavaScript-framework, met uitzondering van Ember.js.", - description="Staafdiagram met de mediane hoofdthread-tijd per framework, exclusief Ember.js. De mobiele hoofdthread-tijden zijn allemaal hoger vanwege de testmethodologie van het gebruik van langzamere CPU-snelheden voor mobiel. De meest populaire frameworks zoals React, GSAP en RequireJS hebben hoge threads van ongeveer 2-3 seconden voor desktop en 5-7 seconden voor mobiel. Polymer valt ook verderop op de populariteitslijst op. MooToos, Prototype, Alpine.js en Svelte hebben meestal lagere hoofdthread-tijden, minder dan 2 seconden.", + caption="De mediane hoofdthread-tijd per pagina door JavaScript-framework, met uitzondering van Ember.js.", + description="Staafdiagram met de mediane hoofdthread-tijd per framework, exclusief Ember.js. De mobiele hoofdthread-tijden zijn allemaal hoger vanwege de testmethodologie van het gebruik van langzamere CPU-snelheden voor mobiel. De meest populaire frameworks zoals React, GSAP en RequireJS hebben hoge threads van ongeveer 2-3 seconden voor desktop en 5-7 seconden voor mobiel. Polymer valt ook verderop op de populariteitslijst op. MooToos, Prototype, Alpine.js en Svelte hebben meestal lagere hoofdthread-tijden, minder dan 2 seconden.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=77448759&format=interactive", sheets_gid="160832134", sql_file="main_thread_time_frameworks.sql" ) }} -Hulpmiddelen zoals React, GSAP en RequireJS besteden vaak veel tijd aan de hoofdthread van de browser, ongeacht of het een desktop- of mobiele paginaweergave is. Dezelfde hulpmiddelen die in het algemeen tot minder code leiden - hulpmiddelen zoals Alpine en Svelte - hebben ook de neiging om de impact op de hoofdthread te verkleinen. +Hulpmiddelen zoals React, GSAP en RequireJS besteden vaak veel tijd aan de hoofdthread van de browser, ongeacht of het een desktop- of mobiele paginaweergave is. Dezelfde hulpmiddelen die in het algemeen tot minder code leiden - hulpmiddelen zoals Alpine en Svelte - hebben ook de neiging om de impact op de hoofdthread te verkleinen. -De kloof tussen de ervaring die een framework biedt voor desktop en mobiel, is ook de moeite waard om in te graven. Mobiel verkeer wordt steeds dominanter en het is van cruciaal belang dat onze hulpmiddelen zo goed mogelijk presteren voor mobiele paginaweergaven. Hoe groter de kloof die we zien tussen desktop- en mobiele prestaties voor een framework, hoe groter de rode vlag. +De kloof tussen de ervaring die een framework biedt voor desktop en mobiel, is ook de moeite waard om in te graven. Mobiel verkeer wordt steeds dominanter en het is van cruciaal belang dat onze hulpmiddelen zo goed mogelijk presteren voor mobiele paginaweergaven. Hoe groter de kloof die we zien tussen desktop- en mobiele prestaties voor een framework, hoe groter de rode vlag. {{ figure_markup( image="frameworks-main-thread-no-ember-diff.png", - caption="Verschil tussen de mediaan van de hoofdthread-tijd voor desktop en mobiel per pagina volgens JavaScript-framework, met uitzondering van Ember.js.", - description="Staafdiagram met de absolute en relatieve verschillen tussen de mediaan van de hoofdthread-tijd op desktop en mobiel per pagina volgens JavaScript-framework, met uitzondering van Ember.js. Polymer springt later in de populariteitslijst naar voren met een groot verschil: ongeveer 5 seconden en 250% langzamere mediane hoofdthread-tijd op mobiele pagina's dan op desktoppagina's. Andere frameworks die opvallen zijn GSAP en RequireJS heeft een verschil van 4 seconden of 150%. Frameworks met het laagste verschil zijn Mustache en RxJS, die slechts ongeveer 20-30% langzamer zijn op mobiel.", + caption="Verschil tussen de mediaan van de hoofdthread-tijd voor desktop en mobiel per pagina volgens JavaScript-framework, met uitzondering van Ember.js.", + description="Staafdiagram met de absolute en relatieve verschillen tussen de mediaan van de hoofdthread-tijd op desktop en mobiel per pagina volgens JavaScript-framework, met uitzondering van Ember.js. Polymer springt later in de populariteitslijst naar voren met een groot verschil: ongeveer 5 seconden en 250% langzamere mediane hoofdthread-tijd op mobiele pagina's dan op desktoppagina's. Andere frameworks die opvallen zijn GSAP en RequireJS heeft een verschil van 4 seconden of 150%. Frameworks met het laagste verschil zijn Mustache en RxJS, die slechts ongeveer 20-30% langzamer zijn op mobiel.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1758266664&format=interactive", sheets_gid="160832134", sql_file="main_thread_time_frameworks.sql" @@ -643,7 +643,7 @@ Het eerste dat we moeten overwegen, is wat er gebeurt met al dat JavaScript nada Als u zich herinnert, was er slechts een verschil van 30 KB tussen wat naar een mobiel apparaat wordt verzonden en een desktopapparaat. Afhankelijk van uw standpunt, zou het u kunnen worden vergeven dat u niet al te boos bent over het kleine verschil in de hoeveelheid code die naar een desktopbrowser wordt verzonden versus een mobiele browser - wat is tenslotte ongeveer 30 KB extra bij de mediaan? -Het grootste probleem ontstaat wanneer al die code wordt geserveerd op een low-to-middle-end apparaat, iets minder dan het soort apparaten dat de meeste ontwikkelaars waarschijnlijk hebben, en een beetje meer het soort apparaten dat je zult hebben. zie van de meerderheid van de mensen over de hele wereld. Die relatief kleine kloof tussen desktop en mobiel is veel dramatischer als we ernaar kijken in termen van verwerkingstijd. +Het grootste probleem ontstaat wanneer al die code wordt geserveerd op een low-to-middle-end apparaat, iets minder dan het soort apparaten dat de meeste ontwikkelaars waarschijnlijk hebben, en een beetje meer het soort apparaten dat je zult zien van de meerderheid van de mensen over de hele wereld. Die relatief kleine kloof tussen desktop en mobiel is veel dramatischer als we ernaar kijken in termen van verwerkingstijd. De gemiddelde desktopsite besteedt 891 ms aan de hoofdthread van een browser die met al dat JavaScript werkt. De gemiddelde mobiele site besteedt echter 1897 ms, meer dan twee keer de tijd die op de desktop wordt doorgebracht. Het is zelfs nog erger voor de lange staart van sites. Op het 90e percentiel besteden mobiele sites maar liefst 8.921 ms aan hoofdthread-tijd aan JavaScript, vergeleken met 3.838 ms voor desktopsites. @@ -656,14 +656,14 @@ De gemiddelde desktopsite besteedt 891 ms aan de hoofdthread van een browser die sql_file="main_thread_time.sql" ) }} -### Het correleren van JavaScript-gebruik met Lighthouse-scores +### Het correleren van JavaScript-gebruik met Lighthouse-scores {het-correleren-van-javascript-gebruik-met-lighthouse-scores} -Een manier om te zien hoe dit zich vertaalt in het beïnvloeden van de gebruikerservaring, is door te proberen een aantal JavaScript-statistieken die we eerder hebben geïdentificeerd te correleren met Lighthouse-scores voor verschillende statistieken en categorieën. +Een manier om te zien hoe dit zich vertaalt in het beïnvloeden van de gebruikerservaring, is door te proberen een aantal JavaScript-statistieken die we eerder hebben geïdentificeerd te correleren met Lighthouse-scores voor verschillende statistieken en categorieën. {{ figure_markup( image="correlations.png", caption="Correlaties van JavaScript op verschillende aspecten van gebruikerservaring.", - description="Staafdiagram met de Pearson-correlatiecoëfficiënt voor verschillende aspecten van gebruikerservaring. De correlatie van bytes met de prestatiescore van Lighthouse heeft een correlatiecoëfficiënt van -0,47. Bytes en Lighthouse toegankelijkheidsscore: 0,08. Bytes en Total Blocking Time (TBT): 0,55. Bytes van derden en prestatiescore van Lighthouse: -0,37. Bytes van derden en de toegankelijkheidsscore van Lighthouse: 0,00. Bytes van derden en TBT: 0,48. Het aantal asynchrone scripts per pagina en de prestatiescore van Lighthouse: -0,19. Asynchrone scripts en Lighthouse toegankelijkheidsscore: 0,08. Asynchrone scripts en TBT: 0,36.", + description="Staafdiagram met de Pearson-correlatiecoëfficiënt voor verschillende aspecten van gebruikerservaring. De correlatie van bytes met de prestatiescore van Lighthouse heeft een correlatiecoëfficiënt van -0,47. Bytes en Lighthouse toegankelijkheidsscore: 0,08. Bytes en Total Blocking Time (TBT): 0,55. Bytes van derden en prestatiescore van ighthouse: -0,37. Bytes van derden en de toegankelijkheidsscore van Lighthouse: 0,00. Bytes van derden en TBT: 0,48. Het aantal asynchrone scripts per pagina en de prestatiescore van Lighthouse: -0,19. Asynchrone scripts en Lighthouse toegankelijkheidsscore: 0,08. Asynchrone scripts en TBT: 0,36.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=649523941&format=interactive", sheets_gid="2035770638", sql_file="correlations.sql" @@ -671,19 +671,19 @@ Een manier om te zien hoe dit zich vertaalt in het beïnvloeden van de gebruiker De bovenstaande grafiek gebruikt de [Pearson correlatiecoëfficiënt](https://en.wikipedia.org/wiki/Pearson_correlation_coefficient). Er is een lange, nogal complexe definitie van wat dat precies betekent, maar de kern is dat we zoeken naar de sterkte van de correlatie tussen twee verschillende getallen. Als we een coëfficiënt van 1,00 vinden, hebben we een directe positieve correlatie. Een correlatie van 0,00 zou geen verband tussen twee getallen aantonen. Alles onder de 0,00 duidt op een negatieve correlatie - met andere woorden, als het ene getal stijgt, neemt het andere af. -Ten eerste lijkt er niet echt een meetbare correlatie te bestaan tussen onze JavaScript-statistieken en de Lighthouse-score voor toegankelijkheid ("LH A11y" in de grafiek) hier. Dat staat in schril contrast met wat elders is gevonden, met name via [het jaarlijkse onderzoek van WebAim](https://webaim.org/projects/million/#frameworks). +Ten eerste lijkt er niet echt een meetbare correlatie te bestaan tussen onze JavaScript-statistieken en de Lighthouse-score voor toegankelijkheid ("LH A11y" in de grafiek) hier. Dat staat in schril contrast met wat elders is gevonden, met name via [het jaarlijkse onderzoek van WebAim](https://webaim.org/projects/million/#frameworks). -De meest waarschijnlijke verklaring hiervoor is dat de toegankelijkheidstests van Lighthouse (nog!) Niet zo uitgebreid zijn als wat beschikbaar is via andere tools, zoals WebAIM, die toegankelijkheid als hun primaire focus hebben. +De meest waarschijnlijke verklaring hiervoor is dat de toegankelijkheidstests van Lighthouse (nog!) Niet zo uitgebreid zijn als wat beschikbaar is via andere hulpmiddelen, zoals WebAIM, die toegankelijkheid als hun primaire focus hebben. -Waar we wel een sterke correlatie zien, is tussen het aantal JavaScript-bytes ("Bytes") en zowel de algehele prestatie van Lighthouse ("LH Perf") score als de Total Blocking Time ("TBT"). +Waar we wel een sterke correlatie zien, is tussen het aantal JavaScript-bytes ("Bytes") en zowel de algehele prestatie van Lighthouse ("LH Perf") score als de Total Blocking Time ("TBT"). -De correlatie tussen JavaScript-bytes en de prestatiescores van Lighthouse is -0,47. Met andere woorden, naarmate JS-bytes toenemen, nemen de prestatiescores van Lighthouse af. De totale bytes hebben een sterkere correlatie dan het aantal bytes van derden ("3P bytes"), wat erop duidt dat hoewel ze zeker een rol spelen, we niet alle schuld bij derden kunnen leggen. +De correlatie tussen JavaScript-bytes en de prestatiescores van Lighthouse is -0,47. Met andere woorden, naarmate JS-bytes toenemen, nemen de prestatiescores van Lighthouse af. De totale bytes hebben een sterkere correlatie dan het aantal bytes van derden ("3P bytes"), wat erop duidt dat hoewel ze zeker een rol spelen, we niet alle schuld bij derden kunnen leggen. Het verband tussen de totale blokkeringstijd en JavaScript-bytes is zelfs nog belangrijker (0,55 voor totale bytes, 0,48 voor bytes van derden). Dat is niet zo verwonderlijk, gezien wat we weten over al het werk dat browsers moeten doen om JavaScript op een pagina te laten werken - meer bytes betekent meer tijd. ### Beveiligingskwetsbaarheden -Een andere nuttige audit die Lighthouse uitvoert, is om te controleren op bekende beveiligingsproblemen in bibliotheken van derden. Het doet dit door te detecteren welke bibliotheken en frameworks op een bepaalde pagina worden gebruikt en welke versie van elk wordt gebruikt. Vervolgens controleert het [Snyk's open-source kwetsbaarheidsdatabase](https://snyk.io/vuln?type=npm) om te zien welke kwetsbaarheden zijn ontdekt in de geïdentificeerde hulpmiddelen. +Een andere nuttige audit die Lighthouse uitvoert, is om te controleren op bekende beveiligingsproblemen in bibliotheken van derden. Het doet dit door te detecteren welke bibliotheken en frameworks op een bepaalde pagina worden gebruikt en welke versie van elk wordt gebruikt. Vervolgens controleert het [Snyk's open-source kwetsbaarheidsdatabase](https://snyk.io/vuln?type=npm) om te zien welke kwetsbaarheden zijn ontdekt in de geïdentificeerde hulpmiddelen. {{ figure_markup( caption="Het percentage mobiele pagina's bevat ten minste één kwetsbare JavaScript-bibliotheek.", @@ -693,7 +693,7 @@ Een andere nuttige audit die Lighthouse uitvoert, is om te controleren op bekend sql_file="lighthouse_vulnerabilities.sql" ) }} -Volgens de audit gebruikt 83,5% van de mobiele pagina's een JavaScript-bibliotheek of -framework met minstens één bekende beveiligingslek. +Volgens de audit gebruikt 83,5% van de mobiele pagina's een JavaScript-bibliotheek of -framework met minstens één bekende beveiligingslek. Dit is wat we het jQuery-effect noemen. Weet je nog hoe we zagen dat jQuery op maar liefst 83% van de pagina's wordt gebruikt? Verschillende oudere versies van jQuery bevatten bekende kwetsbaarheden, die de overgrote meerderheid van de kwetsbaarheden omvatten die deze audit controleert. @@ -717,7 +717,7 @@ Van de ongeveer 5 miljoen mobiele pagina's waartegen wordt getest, bevat 81% een - + @@ -729,7 +729,7 @@ Van de ongeveer 5 miljoen mobiele pagina's waartegen wordt getest, bevat 81% een - + @@ -745,14 +745,14 @@ Van de ongeveer 5 miljoen mobiele pagina's waartegen wordt getest, bevat 81% een - +
GSAP, Lodash, React, RequireJS, ZeptoGSAP, Lodash, React, RequireJS, Zepto 1,0%  
 
React, jQuery, jQuery MigrateReact, jQuery, jQuery Migrate   0,4%
0,2%
GSAP, Hammer.js, Lodash, React, RequireJS, ZeptoGSAP, Hammer.js, Lodash, React, RequireJS, Zepto 0,2%  
15,61%
BootstrapBootstrap 13,19%
2,61%
HandlebarsHandlebars 1,38%
0,58%
jQuery MobilejQuery Mobile 0,53%
{{ figure_link( - caption="Top 10 bibliotheken die volgens Lighthouse bijdragen aan het hoogste aantal kwetsbare mobiele pagina's.", + caption="Top 10 bibliotheken die volgens Lighthouse bijdragen aan het hoogste aantal kwetsbare mobiele pagina's.", sheets_gid="1803013938", sql_file="lighthouse_vulnerable_libraries.sql" ) }} @@ -760,7 +760,7 @@ Van de ongeveer 5 miljoen mobiele pagina's waartegen wordt getest, bevat 81% een
-Met andere woorden, als we mensen zover kunnen krijgen om weg te migreren van die verouderde, kwetsbare versies van jQuery, zouden we het aantal sites met bekende kwetsbaarheden zien dalen (tenminste, totdat we er enkele in de nieuwere frameworks beginnen te vinden). +Met andere woorden, als we mensen zover kunnen krijgen om weg te migreren van die verouderde, kwetsbare versies van jQuery, zouden we het aantal sites met bekende kwetsbaarheden zien dalen (tenminste, totdat we er enkele in de nieuwere frameworks beginnen te vinden). Het merendeel van de gevonden kwetsbaarheden valt in de categorie "gemiddeld". @@ -777,6 +777,6 @@ Het merendeel van de gevonden kwetsbaarheden valt in de categorie "gemiddeld". JavaScript wordt gestaag populair, en daar is veel positiefs over. Het is ongelooflijk om te bedenken wat we dankzij JavaScript op het internet van vandaag kunnen bereiken, dat zelfs een paar jaar geleden onvoorstelbaar zou zijn geweest. -Maar het is duidelijk dat we ook voorzichtig moeten zijn. De hoeveelheid JavaScript stijgt elk jaar consequent (als de aandelenmarkt zo voorspelbaar was, zouden we allemaal ongelooflijk rijk zijn), en dat komt met afwegingen. Meer JavaScript is verbonden met een toename van de verwerkingstijd, wat een negatief effect heeft op belangrijke statistieken zoals de totale blokkeringstijd. En als we die bibliotheken laten wegkwijnen zonder ze up-to-date te houden, lopen ze het risico gebruikers bloot te stellen aan bekende beveiligingsproblemen. +Maar het is duidelijk dat we ook voorzichtig moeten zijn. De hoeveelheid JavaScript stijgt elk jaar consequent (als de aandelenmarkt zo voorspelbaar was, zouden we allemaal ongelooflijk rijk zijn), en dat komt met afwegingen. Meer JavaScript is verbonden met een toename van de verwerkingstijd, wat een negatief effect heeft op belangrijke statistieken zoals de totale blokkeringstijd. En als we die bibliotheken laten wegkwijnen zonder ze actueel te houden, lopen ze het risico gebruikers bloot te stellen aan bekende beveiligingsproblemen. Een zorgvuldige afweging van de kosten van de scripts die we aan onze pagina's toevoegen en bereid zijn om onze hulpmiddelen kritisch in de gaten te houden en er meer van te vragen, zijn onze beste weddenschappen om ervoor te zorgen dat we een web bouwen dat toegankelijk, performant en veilig is. From 563178b41afd7b79b8c3828fd9feea18e113fd69 Mon Sep 17 00:00:00 2001 From: Barry Date: Sat, 19 Dec 2020 08:16:37 +0000 Subject: [PATCH 4/7] Fix span errors --- src/content/nl/2020/javascript.md | 70 +++++++++++++++---------------- 1 file changed, 35 insertions(+), 35 deletions(-) diff --git a/src/content/nl/2020/javascript.md b/src/content/nl/2020/javascript.md index 57378c63887..ad8ef6cbb6f 100644 --- a/src/content/nl/2020/javascript.md +++ b/src/content/nl/2020/javascript.md @@ -277,8 +277,8 @@ Een van de audits in [Lighthouse](./methodology#lighthouse) controleert op niet- {{ figure_markup( image="lighthouse-unminified-js.png", - caption="Verdeling van niet-verkleinde JavaScript Lighthouse-auditscores per mobiele pagina.", - description="Staafdiagram toont 0% van de mobiele pagina's die niet-verkleinde JavaScript krijgen Lighthouse-auditscores onder de 0,25, 4% van de pagina's met een score tussen 0,25 en 0,5, 10% van de pagina's tussen 0,5 en 0,75, 8% van de pagina's tussen 0,75 en 0,9 en 77% van de pagina's tussen 0.9 en 1.0.", + alt="Verdeling van niet-verkleinde JavaScript Lighthouse-auditscores per mobiele pagina.", caption='Verdeling van niet-verkleinde JavaScript Lighthouse-auditscores per mobiele pagina.', + description="Staafdiagram toont 0% van de mobiele pagina's die niet-verkleinde JavaScript krijgen Lighthouse-auditscores onder de 0,25, 4% van de pagina's met een score tussen 0,25 en 0,5, 10% van de pagina's tussen 0,5 en 0,75, 8% van de pagina's tussen 0,75 en 0,9 en 77% van de pagina's tussen 0.9 en 1.0.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=158284816&format=interactive", sheets_gid="362705605", sql_file="lighthouse_unminified_js.sql" @@ -341,13 +341,13 @@ Gelukkig is dat precies wat we zien, vooral in scripts van derden, waar 90% van ## Wat gebruiken we? -Omdat we steeds meer JavaScript hebben gebruikt om onze sites en applicaties van stroom te voorzien, is er ook een toenemende vraag naar open-source bibliotheken en frameworks om de productiviteit van ontwikkelaars en de algehele onderhoudbaarheid van de code te verbeteren. Sites die _niet_ een van deze hulpmiddelen gebruiken, zijn beslist de minderheid op het internet van vandaag - jQuery alleen is te vinden op bijna 85% van de mobiele pagina's die worden bijgehouden door HTTP Archive. +Omdat we steeds meer JavaScript hebben gebruikt om onze sites en applicaties van stroom te voorzien, is er ook een toenemende vraag naar open-source bibliotheken en frameworks om de productiviteit van ontwikkelaars en de algehele onderhoudbaarheid van de code te verbeteren. Sites die _niet_ een van deze hulpmiddelen gebruiken, zijn beslist de minderheid op het internet van vandaag - jQuery alleen is te vinden op bijna 85% van de mobiele pagina's die worden bijgehouden door HTTP Archive. Het is belangrijk dat we kritisch nadenken over de hulpmidellen die we gebruiken om het web te bouwen en wat de afwegingen zijn, dus het is logisch om goed te kijken naar wat we vandaag in gebruik zien. ### Bibliotheken -HTTP Archive gebruikt [Wappalyzer](./methodology#wappalyzer) om technologieën te detecteren die op een bepaalde pagina worden gebruikt. Wappalazyer houdt zowel JavaScript-bibliotheken bij (zie deze als een verzameling fragmenten of helperfuncties om de ontwikkeling te vergemakkelijken, zoals jQuery) en JavaScript-frameworks (dit zijn waarschijnlijker steigers en bieden sjablonen en structuur, zoals React). +HTTP Archive gebruikt [Wappalyzer](./methodology#wappalyzer) om technologieën te detecteren die op een bepaalde pagina worden gebruikt. Wappalazyer houdt zowel JavaScript-bibliotheken bij (zie deze als een verzameling fragmenten of helperfuncties om de ontwikkeling te vergemakkelijken, zoals jQuery) en JavaScript-frameworks (dit zijn waarschijnlijker steigers en bieden sjablonen en structuur, zoals React). De populaire bibliotheken die in gebruik zijn, zijn grotendeels ongewijzigd ten opzichte van vorig jaar, waarbij jQuery het gebruik blijft domineren en slechts één van de 21 beste bibliotheken valt uit (lazy.js, vervangen door DataTables). Zelfs de percentages van de topbibliotheken zijn nauwelijks veranderd ten opzichte van vorig jaar. @@ -355,8 +355,8 @@ De populaire bibliotheken die in gebruik zijn, zijn grotendeels ongewijzigd ten {{ figure_markup( image="frameworks-libraries.png", - caption="Overname van de beste JavaScript-frameworks en -bibliotheken als percentage van de pagina's.", - description="Staafdiagram dat de acceptatie van de belangrijkste frameworks en bibliotheken weergeeft als percentage van de pagina's (niet paginaweergaven of npm-downloads). jQuery is de overweldigende leider, te vinden op 83% van de mobiele pagina's. Het wordt gevolgd door jQuery migrate op 30%, jQuery UI op 21%, Modernizr op 15%, FancyBox op 7%, Slick en Lightbox op 6%, en de resterende frameworks en bibliotheken op 4% of 3%: Moment.js, Underscore.js, Lodash, React, GSAP, Select2, RequireJS en prettyPhoto.", + alt="Overname van de beste JavaScript-frameworks en -bibliotheken als percentage van de pagina's.", caption="Overname van de beste JavaScript-frameworks en -bibliotheken als percentage van de pagina's.", + description="Staafdiagram dat de acceptatie van de belangrijkste frameworks en bibliotheken weergeeft als percentage van de pagina's (niet paginaweergaven of npm-downloads). jQuery is de overweldigende leider, te vinden op 83% van de mobiele pagina\'s. Het wordt gevolgd door jQuery migrate op 30%, jQuery UI op 21%, Modernizr op 15%, FancyBox op 7%, Slick en Lightbox op 6%, en de resterende frameworks en bibliotheken op 4% of 3%: Moment.js, Underscore.js, Lodash, React, GSAP, Select2, RequireJS en prettyPhoto.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=419887153&format=interactive", sheets_gid="1654577118", sql_file="frameworks_libraries.sql" @@ -371,9 +371,9 @@ Beide zijn zeer goede gissingen, en het lijkt erop dat de situatie op geen van b In feite wordt de dominantie van jQuery nog verder ondersteund als je bedenkt dat van de top 10 bibliotheken er 6 jQuery zijn of jQuery nodig hebben om te kunnen worden gebruikt: jQuery UI, jQuery Migrate, FancyBox, Lightbox en Slick . -### Frameworks {frameworks} +### Frameworks -Als we naar de frameworks kijken, zien we ook niet veel van een dramatische verandering in termen van adoptie in de belangrijkste frameworks die vorig jaar naar voren kwamen. Vue.js heeft een aanzienlijke toename gezien en AMP is een beetje gegroeid, maar de meeste zijn min of meer waar ze een jaar geleden waren. +Als we naar de frameworks kijken, zien we ook niet veel van een dramatische verandering in termen van adoptie in de belangrijkste frameworks die vorig jaar naar voren kwamen. Vue.js heeft een aanzienlijke toename gezien en AMP is een beetje gegroeid, maar de meeste zijn min of meer waar ze een jaar geleden waren. {# TODO(analysts): Compare same frameworks from last year's chapter to this year in bar chart? #} @@ -383,7 +383,7 @@ Het is vermeldenswaard dat het [detectieprobleem dat vorig jaar werd opgemerkt n Interessanter voor ons dan de populariteit van de hulpmiddelen zelf is de impact die ze hebben op de dingen die we bouwen. -Ten eerste is het vermeldenswaard dat hoewel we misschien denken aan het gebruik van de ene hulpmiddel in plaats van de andere, we in werkelijkheid zelden slechts één enkele bibliotheek of framework gebruiken bij de productie. Slechts 21% van de geanalyseerde pagina's rapporteert slechts één bibliotheek of framework. Twee of drie frameworks komen vrij vaak voor, en de lange staart wordt erg lang, erg snel. +Ten eerste is het vermeldenswaard dat hoewel we misschien denken aan het gebruik van de ene hulpmiddel in plaats van de andere, we in werkelijkheid zelden slechts één enkele bibliotheek of framework gebruiken bij de productie. Slechts 21% van de geanalyseerde pagina's rapporteert slechts één bibliotheek of framework. Twee of drie frameworks komen vrij vaak voor, en de lange staart wordt erg lang, erg snel. Als we kijken naar de veel voorkomende combinaties die we in de productie zien, zijn de meeste te verwachten. Gezien de dominantie van jQuery, is het niet verwonderlijk dat de meeste populaire combinaties jQuery en een willekeurig aantal jQuery-gerelateerde plug-ins bevatten. @@ -502,14 +502,14 @@ Als we kijken naar de veel voorkomende combinaties die we in de productie zien,
{{ figure_link( - caption="De meest populaire combinaties van bibliotheken en frameworks op mobiele pagina's.", + caption='De meest populaire combinaties van bibliotheken en frameworks op mobiele pagina\'s.', sheets_gid="795160444", sql_file="frameworks_libraries_combos.sql" ) }}
-We zien ook een behoorlijk aantal meer "moderne" frameworks zoals React, Vue en Angular in combinatie met jQuery, bijvoorbeeld als gevolg van migratie of opname door derden. +We zien ook een behoorlijk aantal meer "moderne" frameworks zoals React, Vue en Angular in combinatie met jQuery, bijvoorbeeld als gevolg van migratie of opname door derden.
@@ -581,14 +581,14 @@ We zien ook een behoorlijk aantal meer "moderne" frameworksframeworks kijken, zien we dat de mediaan JavaScript-bytes voor pagina's die deze gebruiken, enorm variëren, afhankelijk van _wat_ wordt gebruikt. +Als we specifiek naar de gebruikte frameworks kijken, zien we dat de mediaan JavaScript-bytes voor pagina's die deze gebruiken, enorm variëren, afhankelijk van _wat_ wordt gebruikt. -De onderstaande grafiek toont de mediaan bytes voor pagina's waar een van de top 35 meest gedetecteerde frameworks is gevonden, uitgesplitst naar client. +De onderstaande grafiek toont de mediaan bytes voor pagina's waar een van de top 35 meest gedetecteerde frameworks is gevonden, uitgesplitst naar client. {{ figure_markup( image="frameworks-bytes.png", - caption="Het gemiddelde aantal JavaScript-kilobytes per pagina door JavaScript-framework.", - description="Staafdiagram met het gemiddelde aantal JavaScript-kilobytes per pagina, uitgesplitst en gesorteerd op populariteit van het JavaScript-framework. Het meest populaire framework, React, heeft een mediaan van 1.328 JS op mobiele pagina's. Andere frameworks zoals RequireJS en Angular hebben een hoog aantal mediane JS-bytes per pagina. Pagina's met MooTools, Prototype, AMP, RightJS, Alpine.js en Svelte hebben medianen van minder dan 500 KB per mobiele pagina. Ember.js heeft een uitbijter van ongeveer 1.800 KB mediane JS per mobiele pagina.", + caption="Het gemiddelde aantal JavaScript-kilobytes per pagina door JavaScript-framework.", + description="Staafdiagram met het gemiddelde aantal JavaScript-kilobytes per pagina, uitgesplitst en gesorteerd op populariteit van het JavaScript-framework. Het meest populaire framework, React, heeft een mediaan van 1.328 JS op mobiele pagina's. Andere frameworks zoals RequireJS en Angular hebben een hoog aantal mediane JS-bytes per pagina. Pagina's met MooTools, Prototype, AMP, RightJS, Alpine.js en Svelte hebben medianen van minder dan 500 KB per mobiele pagina. Ember.js heeft een uitbijter van ongeveer 1.800 KB mediane JS per mobiele pagina.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=955720480&format=interactive", sheets_gid="1206934500", width="600", @@ -596,14 +596,14 @@ De onderstaande grafiek toont de mediaan bytes voor pagina's waar een van de top sql_file="frameworks-bytes-by-framework.sql" ) }} -Op één van de spectrums staan frameworks zoals React of Angular of Ember, die de neiging hebben om veel code te verzenden, ongeacht de klant. Aan de andere kant zien we minimalistische frameworks zoals Alpine.js en Svelte veelbelovende resultaten laten zien. Standaarden zijn erg belangrijk, en het lijkt erop dat Svelte en Alpine er allebei in slagen (tot dusver… is de steekproefomvang vrij klein) om een lichtere set pagina's te creëren door te beginnen met zeer performante standaarden. +Op één van de spectrums staan frameworks zoals React of Angular of Ember, die de neiging hebben om veel code te verzenden, ongeacht de klant. Aan de andere kant zien we minimalistische frameworks zoals Alpine.js en Svelte veelbelovende resultaten laten zien. Standaarden zijn erg belangrijk, en het lijkt erop dat Svelte en Alpine er allebei in slagen (tot dusver… is de steekproefomvang vrij klein) om een lichtere set pagina's te creëren door te beginnen met zeer performante standaarden. We krijgen een vergelijkbaar beeld als we kijken naar de hoofdthread-tijd voor pagina's waarop deze hulpmiddelen zijn gedetecteerd. {{ figure_markup( image="frameworks-main-thread.png", - caption="De mediane hoofdthread-tijd per pagina door JavaScript-framework.", - description="Staafdiagram met de mediane hoofdthread-tijd per framework. Het is moeilijk om iets anders op te merken dan Ember.js, waarvan de mediane mobiele hoofdthread-tijd meer dan 20.000 milliseconden (20 seconden) is. De rest van de frameworks zijn in vergelijking klein.", + caption="De mediane hoofdthread-tijd per pagina door JavaScript-framework.", + description="Staafdiagram met de mediane hoofdthread-tijd per framework. Het is moeilijk om iets anders op te merken dan Ember.js, waarvan de mediane mobiele hoofdthread-tijd meer dan 20.000 milliseconden (20 seconden) is. De rest van de frameworks zijn in vergelijking klein.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=691531699&format=interactive", sheets_gid="160832134", sql_file="main_thread_time_frameworks.sql" @@ -613,21 +613,21 @@ Ember's mobiele hoofdthread-tijd springt eruit en vervormt de grafiek enigszins {{ figure_markup( image="frameworks-main-thread-no-ember.png", - caption="De mediane hoofdthread-tijd per pagina door JavaScript-framework, met uitzondering van Ember.js.", - description="Staafdiagram met de mediane hoofdthread-tijd per framework, exclusief Ember.js. De mobiele hoofdthread-tijden zijn allemaal hoger vanwege de testmethodologie van het gebruik van langzamere CPU-snelheden voor mobiel. De meest populaire frameworks zoals React, GSAP en RequireJS hebben hoge threads van ongeveer 2-3 seconden voor desktop en 5-7 seconden voor mobiel. Polymer valt ook verderop op de populariteitslijst op. MooToos, Prototype, Alpine.js en Svelte hebben meestal lagere hoofdthread-tijden, minder dan 2 seconden.", + caption="De mediane hoofdthread-tijd per pagina door JavaScript-framework, met uitzondering van Ember.js.", + description="Staafdiagram met de mediane hoofdthread-tijd per framework, exclusief Ember.js. De mobiele hoofdthread-tijden zijn allemaal hoger vanwege de testmethodologie van het gebruik van langzamere CPU-snelheden voor mobiel. De meest populaire frameworks zoals React, GSAP en RequireJS hebben hoge threads van ongeveer 2-3 seconden voor desktop en 5-7 seconden voor mobiel. Polymer valt ook verderop op de populariteitslijst op. MooToos, Prototype, Alpine.js en Svelte hebben meestal lagere hoofdthread-tijden, minder dan 2 seconden.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=77448759&format=interactive", sheets_gid="160832134", sql_file="main_thread_time_frameworks.sql" ) }} -Hulpmiddelen zoals React, GSAP en RequireJS besteden vaak veel tijd aan de hoofdthread van de browser, ongeacht of het een desktop- of mobiele paginaweergave is. Dezelfde hulpmiddelen die in het algemeen tot minder code leiden - hulpmiddelen zoals Alpine en Svelte - hebben ook de neiging om de impact op de hoofdthread te verkleinen. +Hulpmiddelen zoals React, GSAP en RequireJS besteden vaak veel tijd aan de hoofdthread van de browser, ongeacht of het een desktop- of mobiele paginaweergave is. Dezelfde hulpmiddelen die in het algemeen tot minder code leiden - hulpmiddelen zoals Alpine en Svelte - hebben ook de neiging om de impact op de hoofdthread te verkleinen. -De kloof tussen de ervaring die een framework biedt voor desktop en mobiel, is ook de moeite waard om in te graven. Mobiel verkeer wordt steeds dominanter en het is van cruciaal belang dat onze hulpmiddelen zo goed mogelijk presteren voor mobiele paginaweergaven. Hoe groter de kloof die we zien tussen desktop- en mobiele prestaties voor een framework, hoe groter de rode vlag. +De kloof tussen de ervaring die een framework biedt voor desktop en mobiel, is ook de moeite waard om in te graven. Mobiel verkeer wordt steeds dominanter en het is van cruciaal belang dat onze hulpmiddelen zo goed mogelijk presteren voor mobiele paginaweergaven. Hoe groter de kloof die we zien tussen desktop- en mobiele prestaties voor een framework, hoe groter de rode vlag. {{ figure_markup( image="frameworks-main-thread-no-ember-diff.png", - caption="Verschil tussen de mediaan van de hoofdthread-tijd voor desktop en mobiel per pagina volgens JavaScript-framework, met uitzondering van Ember.js.", - description="Staafdiagram met de absolute en relatieve verschillen tussen de mediaan van de hoofdthread-tijd op desktop en mobiel per pagina volgens JavaScript-framework, met uitzondering van Ember.js. Polymer springt later in de populariteitslijst naar voren met een groot verschil: ongeveer 5 seconden en 250% langzamere mediane hoofdthread-tijd op mobiele pagina's dan op desktoppagina's. Andere frameworks die opvallen zijn GSAP en RequireJS heeft een verschil van 4 seconden of 150%. Frameworks met het laagste verschil zijn Mustache en RxJS, die slechts ongeveer 20-30% langzamer zijn op mobiel.", + caption="Verschil tussen de mediaan van de hoofdthread-tijd voor desktop en mobiel per pagina volgens JavaScript-framework, met uitzondering van Ember.js.", + description="Staafdiagram met de absolute en relatieve verschillen tussen de mediaan van de hoofdthread-tijd op desktop en mobiel per pagina volgens JavaScript-framework, met uitzondering van Ember.js. Polymer springt later in de populariteitslijst naar voren met een groot verschil: ongeveer 5 seconden en 250% langzamere mediane hoofdthread-tijd op mobiele pagina's dan op desktoppagina's. Andere frameworks die opvallen zijn GSAP en RequireJS heeft een verschil van 4 seconden of 150%. frameworks met het laagste verschil zijn Mustache en RxJS, die slechts ongeveer 20-30% langzamer zijn op mobiel.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=1758266664&format=interactive", sheets_gid="160832134", sql_file="main_thread_time_frameworks.sql" @@ -656,14 +656,14 @@ De gemiddelde desktopsite besteedt 891 ms aan de hoofdthread van een browser die sql_file="main_thread_time.sql" ) }} -### Het correleren van JavaScript-gebruik met Lighthouse-scores {het-correleren-van-javascript-gebruik-met-lighthouse-scores} +### Het correleren van JavaScript-gebruik met Lighthouse-scores -Een manier om te zien hoe dit zich vertaalt in het beïnvloeden van de gebruikerservaring, is door te proberen een aantal JavaScript-statistieken die we eerder hebben geïdentificeerd te correleren met Lighthouse-scores voor verschillende statistieken en categorieën. +Een manier om te zien hoe dit zich vertaalt in het beïnvloeden van de gebruikerservaring, is door te proberen een aantal JavaScript-statistieken die we eerder hebben geïdentificeerd te correleren met Lighthouse-scores voor verschillende statistieken en categorieën. {{ figure_markup( image="correlations.png", caption="Correlaties van JavaScript op verschillende aspecten van gebruikerservaring.", - description="Staafdiagram met de Pearson-correlatiecoëfficiënt voor verschillende aspecten van gebruikerservaring. De correlatie van bytes met de prestatiescore van Lighthouse heeft een correlatiecoëfficiënt van -0,47. Bytes en Lighthouse toegankelijkheidsscore: 0,08. Bytes en Total Blocking Time (TBT): 0,55. Bytes van derden en prestatiescore van ighthouse: -0,37. Bytes van derden en de toegankelijkheidsscore van Lighthouse: 0,00. Bytes van derden en TBT: 0,48. Het aantal asynchrone scripts per pagina en de prestatiescore van Lighthouse: -0,19. Asynchrone scripts en Lighthouse toegankelijkheidsscore: 0,08. Asynchrone scripts en TBT: 0,36.", + description="Staafdiagram met de Pearson-correlatiecoëfficiënt voor verschillende aspecten van gebruikerservaring. De correlatie van bytes met de prestatiescore van Lighthouse heeft een correlatiecoëfficiënt van -0,47. Bytes en Lighthouse toegankelijkheidsscore: 0,08. Bytes en Total Blocking Time (TBT): 0,55. Bytes van derden en prestatiescore van Lighthouse: -0,37. Bytes van derden en de toegankelijkheidsscore van Lighthouse: 0,00. Bytes van derden en TBT: 0,48. Het aantal asynchrone scripts per pagina en de prestatiescore van Lighthouse: -0,19. Asynchrone scripts en Lighthouse toegankelijkheidsscore: 0,08. Asynchrone scripts en TBT: 0,36.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=649523941&format=interactive", sheets_gid="2035770638", sql_file="correlations.sql" @@ -671,19 +671,19 @@ Een manier om te zien hoe dit zich vertaalt in het beïnvloeden van de gebruiker De bovenstaande grafiek gebruikt de [Pearson correlatiecoëfficiënt](https://en.wikipedia.org/wiki/Pearson_correlation_coefficient). Er is een lange, nogal complexe definitie van wat dat precies betekent, maar de kern is dat we zoeken naar de sterkte van de correlatie tussen twee verschillende getallen. Als we een coëfficiënt van 1,00 vinden, hebben we een directe positieve correlatie. Een correlatie van 0,00 zou geen verband tussen twee getallen aantonen. Alles onder de 0,00 duidt op een negatieve correlatie - met andere woorden, als het ene getal stijgt, neemt het andere af. -Ten eerste lijkt er niet echt een meetbare correlatie te bestaan tussen onze JavaScript-statistieken en de Lighthouse-score voor toegankelijkheid ("LH A11y" in de grafiek) hier. Dat staat in schril contrast met wat elders is gevonden, met name via [het jaarlijkse onderzoek van WebAim](https://webaim.org/projects/million/#frameworks). +Ten eerste lijkt er niet echt een meetbare correlatie te bestaan tussen onze JavaScript-statistieken en de Lighthouse-score voor toegankelijkheid ("LH A11y" in de grafiek) hier. Dat staat in schril contrast met wat elders is gevonden, met name via [het jaarlijkse onderzoek van WebAim](https://webaim.org/projects/million/#frameworks). -De meest waarschijnlijke verklaring hiervoor is dat de toegankelijkheidstests van Lighthouse (nog!) Niet zo uitgebreid zijn als wat beschikbaar is via andere hulpmiddelen, zoals WebAIM, die toegankelijkheid als hun primaire focus hebben. +De meest waarschijnlijke verklaring hiervoor is dat de toegankelijkheidstests van Lighthouse (nog!) Niet zo uitgebreid zijn als wat beschikbaar is via andere hulpmiddelen, zoals WebAIM, die toegankelijkheid als hun primaire focus hebben. -Waar we wel een sterke correlatie zien, is tussen het aantal JavaScript-bytes ("Bytes") en zowel de algehele prestatie van Lighthouse ("LH Perf") score als de Total Blocking Time ("TBT"). +Waar we wel een sterke correlatie zien, is tussen het aantal JavaScript-bytes ("Bytes") en zowel de algehele prestatie van Lighthouse ("LH Perf") score als de Total Blocking Time ("TBT"). -De correlatie tussen JavaScript-bytes en de prestatiescores van Lighthouse is -0,47. Met andere woorden, naarmate JS-bytes toenemen, nemen de prestatiescores van Lighthouse af. De totale bytes hebben een sterkere correlatie dan het aantal bytes van derden ("3P bytes"), wat erop duidt dat hoewel ze zeker een rol spelen, we niet alle schuld bij derden kunnen leggen. +De correlatie tussen JavaScript-bytes en de prestatiescores van Lighthouse is -0,47. Met andere woorden, naarmate JS-bytes toenemen, nemen de prestatiescores van Lighthouse af. De totale bytes hebben een sterkere correlatie dan het aantal bytes van derden ("3P bytes"), wat erop duidt dat hoewel ze zeker een rol spelen, we niet alle schuld bij derden kunnen leggen. Het verband tussen de totale blokkeringstijd en JavaScript-bytes is zelfs nog belangrijker (0,55 voor totale bytes, 0,48 voor bytes van derden). Dat is niet zo verwonderlijk, gezien wat we weten over al het werk dat browsers moeten doen om JavaScript op een pagina te laten werken - meer bytes betekent meer tijd. ### Beveiligingskwetsbaarheden -Een andere nuttige audit die Lighthouse uitvoert, is om te controleren op bekende beveiligingsproblemen in bibliotheken van derden. Het doet dit door te detecteren welke bibliotheken en frameworks op een bepaalde pagina worden gebruikt en welke versie van elk wordt gebruikt. Vervolgens controleert het [Snyk's open-source kwetsbaarheidsdatabase](https://snyk.io/vuln?type=npm) om te zien welke kwetsbaarheden zijn ontdekt in de geïdentificeerde hulpmiddelen. +Een andere nuttige audit die Lighthouse uitvoert, is om te controleren op bekende beveiligingsproblemen in bibliotheken van derden. Het doet dit door te detecteren welke bibliotheken en frameworks op een bepaalde pagina worden gebruikt en welke versie van elk wordt gebruikt. Vervolgens controleert het [Snyk's open-source kwetsbaarheidsdatabase](https://snyk.io/vuln?type=npm) om te zien welke kwetsbaarheden zijn ontdekt in de geïdentificeerde hulpmiddelen. {{ figure_markup( caption="Het percentage mobiele pagina's bevat ten minste één kwetsbare JavaScript-bibliotheek.", @@ -693,7 +693,7 @@ Een andere nuttige audit die Lighthouse uitvoert, is om t sql_file="lighthouse_vulnerabilities.sql" ) }} -Volgens de audit gebruikt 83,5% van de mobiele pagina's een JavaScript-bibliotheek of -framework met minstens één bekende beveiligingslek. +Volgens de audit gebruikt 83,5% van de mobiele pagina's een JavaScript-bibliotheek of -framework met minstens één bekende beveiligingslek. Dit is wat we het jQuery-effect noemen. Weet je nog hoe we zagen dat jQuery op maar liefst 83% van de pagina's wordt gebruikt? Verschillende oudere versies van jQuery bevatten bekende kwetsbaarheden, die de overgrote meerderheid van de kwetsbaarheden omvatten die deze audit controleert. @@ -752,7 +752,7 @@ Van de ongeveer 5 miljoen mobiele pagina's waartegen wordt getest, bevat 81% een
{{ figure_link( - caption="Top 10 bibliotheken die volgens Lighthouse bijdragen aan het hoogste aantal kwetsbare mobiele pagina's.", + caption="Top 10 bibliotheken die volgens Lighthouse bijdragen aan het hoogste aantal kwetsbare mobiele pagina's.", sheets_gid="1803013938", sql_file="lighthouse_vulnerable_libraries.sql" ) }} @@ -760,7 +760,7 @@ Van de ongeveer 5 miljoen mobiele pagina's waartegen wordt getest, bevat 81% een
-Met andere woorden, als we mensen zover kunnen krijgen om weg te migreren van die verouderde, kwetsbare versies van jQuery, zouden we het aantal sites met bekende kwetsbaarheden zien dalen (tenminste, totdat we er enkele in de nieuwere frameworks beginnen te vinden). +Met andere woorden, als we mensen zover kunnen krijgen om weg te migreren van die verouderde, kwetsbare versies van jQuery, zouden we het aantal sites met bekende kwetsbaarheden zien dalen (tenminste, totdat we er enkele in de nieuwere frameworks beginnen te vinden). Het merendeel van de gevonden kwetsbaarheden valt in de categorie "gemiddeld". From 2aa2fef4a30eb129528dc021fb1f928971b6fb6b Mon Sep 17 00:00:00 2001 From: Barry Date: Sat, 19 Dec 2020 08:20:41 +0000 Subject: [PATCH 5/7] More changes --- src/content/nl/2020/javascript.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/nl/2020/javascript.md b/src/content/nl/2020/javascript.md index ad8ef6cbb6f..d594cb2f76a 100644 --- a/src/content/nl/2020/javascript.md +++ b/src/content/nl/2020/javascript.md @@ -277,7 +277,7 @@ Een van de audits in [Lighthouse](./methodology#lighthouse) controleert op niet- {{ figure_markup( image="lighthouse-unminified-js.png", - alt="Verdeling van niet-verkleinde JavaScript Lighthouse-auditscores per mobiele pagina.", caption='Verdeling van niet-verkleinde JavaScript Lighthouse-auditscores per mobiele pagina.', + caption="Verdeling van niet-verkleinde JavaScript Lighthouse-auditscores per mobiele pagina.", description="Staafdiagram toont 0% van de mobiele pagina's die niet-verkleinde JavaScript krijgen Lighthouse-auditscores onder de 0,25, 4% van de pagina's met een score tussen 0,25 en 0,5, 10% van de pagina's tussen 0,5 en 0,75, 8% van de pagina's tussen 0,75 en 0,9 en 77% van de pagina's tussen 0.9 en 1.0.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=158284816&format=interactive", sheets_gid="362705605", @@ -502,7 +502,7 @@ Als we kijken naar de veel voorkomende combinaties die we in de productie zien,
{{ figure_link( - caption='De meest populaire combinaties van bibliotheken en frameworks op mobiele pagina\'s.', + caption="De meest populaire combinaties van bibliotheken en frameworks op mobiele pagina's.", sheets_gid="795160444", sql_file="frameworks_libraries_combos.sql" ) }} From 67609a811fce60f771737f43127b7dbce60c3b22 Mon Sep 17 00:00:00 2001 From: Barry Date: Sat, 19 Dec 2020 08:24:47 +0000 Subject: [PATCH 6/7] More changes --- src/content/nl/2020/javascript.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/content/nl/2020/javascript.md b/src/content/nl/2020/javascript.md index d594cb2f76a..20b1c493638 100644 --- a/src/content/nl/2020/javascript.md +++ b/src/content/nl/2020/javascript.md @@ -278,7 +278,7 @@ Een van de audits in [Lighthouse](./methodology#lighthouse) controleert op niet- {{ figure_markup( image="lighthouse-unminified-js.png", caption="Verdeling van niet-verkleinde JavaScript Lighthouse-auditscores per mobiele pagina.", - description="Staafdiagram toont 0% van de mobiele pagina's die niet-verkleinde JavaScript krijgen Lighthouse-auditscores onder de 0,25, 4% van de pagina's met een score tussen 0,25 en 0,5, 10% van de pagina's tussen 0,5 en 0,75, 8% van de pagina's tussen 0,75 en 0,9 en 77% van de pagina's tussen 0.9 en 1.0.", + description="Staafdiagram toont 0% van de mobiele pagina's die niet-verkleinde JavaScript krijgen Lighthouse-auditscores onder de 0,25, 4% van de pagina's met een score tussen 0,25 en 0,5, 10% van de pagina's tussen 0,5 en 0,75, 8% van de pagina's tussen 0,75 en 0,9 en 77% van de pagina's tussen 0.9 en 1.0.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=158284816&format=interactive", sheets_gid="362705605", sql_file="lighthouse_unminified_js.sql" @@ -355,8 +355,8 @@ De populaire bibliotheken die in gebruik zijn, zijn grotendeels ongewijzigd ten {{ figure_markup( image="frameworks-libraries.png", - alt="Overname van de beste JavaScript-frameworks en -bibliotheken als percentage van de pagina's.", caption="Overname van de beste JavaScript-frameworks en -bibliotheken als percentage van de pagina's.", - description="Staafdiagram dat de acceptatie van de belangrijkste frameworks en bibliotheken weergeeft als percentage van de pagina's (niet paginaweergaven of npm-downloads). jQuery is de overweldigende leider, te vinden op 83% van de mobiele pagina\'s. Het wordt gevolgd door jQuery migrate op 30%, jQuery UI op 21%, Modernizr op 15%, FancyBox op 7%, Slick en Lightbox op 6%, en de resterende frameworks en bibliotheken op 4% of 3%: Moment.js, Underscore.js, Lodash, React, GSAP, Select2, RequireJS en prettyPhoto.", + caption="Overname van de beste JavaScript-frameworks en -bibliotheken als percentage van de pagina's.", + description="Staafdiagram dat de acceptatie van de belangrijkste frameworks en bibliotheken weergeeft als percentage van de pagina's (niet paginaweergaven of npm-downloads). jQuery is de overweldigende leider, te vinden op 83% van de mobiele pagina\'s. Het wordt gevolgd door jQuery migrate op 30%, jQuery UI op 21%, Modernizr op 15%, FancyBox op 7%, Slick en Lightbox op 6%, en de resterende frameworks en bibliotheken op 4% of 3%: Moment.js, Underscore.js, Lodash, React, GSAP, Select2, RequireJS en prettyPhoto.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=419887153&format=interactive", sheets_gid="1654577118", sql_file="frameworks_libraries.sql" @@ -663,7 +663,7 @@ Een manier om te zien hoe dit zich vertaalt in het beïnvloeden van de gebruiker {{ figure_markup( image="correlations.png", caption="Correlaties van JavaScript op verschillende aspecten van gebruikerservaring.", - description="Staafdiagram met de Pearson-correlatiecoëfficiënt voor verschillende aspecten van gebruikerservaring. De correlatie van bytes met de prestatiescore van Lighthouse heeft een correlatiecoëfficiënt van -0,47. Bytes en Lighthouse toegankelijkheidsscore: 0,08. Bytes en Total Blocking Time (TBT): 0,55. Bytes van derden en prestatiescore van Lighthouse: -0,37. Bytes van derden en de toegankelijkheidsscore van Lighthouse: 0,00. Bytes van derden en TBT: 0,48. Het aantal asynchrone scripts per pagina en de prestatiescore van Lighthouse: -0,19. Asynchrone scripts en Lighthouse toegankelijkheidsscore: 0,08. Asynchrone scripts en TBT: 0,36.", + description='Staafdiagram met de Pearson-correlatiecoëfficiënt voor verschillende aspecten van gebruikerservaring. De correlatie van bytes met de prestatiescore van Lighthouse heeft een correlatiecoëfficiënt van -0,47. Bytes en Lighthouse toegankelijkheidsscore: 0,08. Bytes en Total Blocking Time (TBT): 0,55. Bytes van derden en prestatiescore van Lighthouse: -0,37. Bytes van derden en de toegankelijkheidsscore van Lighthouse: 0,00. Bytes van derden en TBT: 0,48. Het aantal asynchrone scripts per pagina en de prestatiescore van Lighthouse: -0,19. Asynchrone scripts en Lighthouse toegankelijkheidsscore: 0,08. Asynchrone scripts en TBT: 0,36.', chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRn1IaMxnTl0jhdC-C-vC5VLN_boJfLAaOfGJ968IalK1vPc8-dz0OkVmNY0LjMxZ6BIwSRB7xtRmIE/pubchart?oid=649523941&format=interactive", sheets_gid="2035770638", sql_file="correlations.sql" From 4f71833dceff3d7a19ca7decf37522f801ef65c7 Mon Sep 17 00:00:00 2001 From: Barry Pollard Date: Sat, 19 Dec 2020 08:56:07 +0000 Subject: [PATCH 7/7] Update src/content/nl/2020/javascript.md --- src/content/nl/2020/javascript.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/nl/2020/javascript.md b/src/content/nl/2020/javascript.md index 20b1c493638..0311ce1283b 100644 --- a/src/content/nl/2020/javascript.md +++ b/src/content/nl/2020/javascript.md @@ -669,7 +669,7 @@ Een manier om te zien hoe dit zich vertaalt in het beïnvloeden van de gebruiker sql_file="correlations.sql" ) }} -De bovenstaande grafiek gebruikt de [Pearson correlatiecoëfficiënt](https://en.wikipedia.org/wiki/Pearson_correlation_coefficient). Er is een lange, nogal complexe definitie van wat dat precies betekent, maar de kern is dat we zoeken naar de sterkte van de correlatie tussen twee verschillende getallen. Als we een coëfficiënt van 1,00 vinden, hebben we een directe positieve correlatie. Een correlatie van 0,00 zou geen verband tussen twee getallen aantonen. Alles onder de 0,00 duidt op een negatieve correlatie - met andere woorden, als het ene getal stijgt, neemt het andere af. +De bovenstaande grafiek gebruikt de [Pearson correlatiecoëfficiënt](https://nl.wikipedia.org/wiki/Correlatieco%C3%ABffici%C3%ABnt). Er is een lange, nogal complexe definitie van wat dat precies betekent, maar de kern is dat we zoeken naar de sterkte van de correlatie tussen twee verschillende getallen. Als we een coëfficiënt van 1,00 vinden, hebben we een directe positieve correlatie. Een correlatie van 0,00 zou geen verband tussen twee getallen aantonen. Alles onder de 0,00 duidt op een negatieve correlatie - met andere woorden, als het ene getal stijgt, neemt het andere af. Ten eerste lijkt er niet echt een meetbare correlatie te bestaan tussen onze JavaScript-statistieken en de Lighthouse-score voor toegankelijkheid ("LH A11y" in de grafiek) hier. Dat staat in schril contrast met wat elders is gevonden, met name via [het jaarlijkse onderzoek van WebAim](https://webaim.org/projects/million/#frameworks).