From d2f3627587a76cdcda00f8a4d7774c0bb3dc3757 Mon Sep 17 00:00:00 2001 From: Noah Date: Sat, 20 Mar 2021 23:25:32 +0100 Subject: [PATCH 01/11] create http2.md --- src/content/nl/2020/http2.md | 684 +++++++++++++++++++++++++++++++++++ 1 file changed, 684 insertions(+) create mode 100644 src/content/nl/2020/http2.md diff --git a/src/content/nl/2020/http2.md b/src/content/nl/2020/http2.md new file mode 100644 index 00000000000..96c4eeb9d0d --- /dev/null +++ b/src/content/nl/2020/http2.md @@ -0,0 +1,684 @@ +--- +#See https://github.com/HTTPArchive/almanac.httparchive.org/wiki/Authors'-Guide#metadata-to-add-at-the-top-of-your-chapters +title: HTTP/2 +description: HTTP/2 chapter of the 2020 Web Almanac covering adoption and impact of HTTP/2, HTTP/2 Push, HTTP/2 Issues, and HTTP/3. +authors: [dotjs, rmarx, MikeBishop] +reviewers: [LPardue, bazzadp, ibnesayeed] +analysts: [gregorywolf] +editors: [rviscomi] +translators: [] +dotjs_bio: Andrew works at Cloudflare helping to make the web faster and more secure. He spends his time deploying, measuring and improving new protocols and asset delivery to improve end-user website performance. +rmarx_bio: Robin is a web protocol and performance researcher at Hasselt University, Belgium. He has been working on getting QUIC and HTTP/3 ready to use by creating tools like qlog and qvis. +MikeBishop_bio: Editor of HTTP/3 with the QUIC Working Group. Architect in Akamai's Foundry group. +discuss: 2058 +results: https://docs.google.com/spreadsheets/d/1M1tijxf04wSN3KU0ZUunjPYCrVsaJfxzuRCXUeRQ-YU/ +featured_quote: This chapter reviews the current state of HTTP/2 and gQUIC deployment, to establish how well some of the newer features of the protocol, such as prioritization and server push, have been adopted. We then look at the motivations for HTTP/3, describe the major differences between the protocol versions and discuss the potential challenges in upgrading to a UDP-based transport protocol with QUIC. +featured_stat_1: 64% +featured_stat_label_1: Requests served over HTTP/2 +featured_stat_2: 31.7% +featured_stat_label_2: CDN Requests with incorrect HTTP/2 prioritization +featured_stat_3: 80% +featured_stat_label_3: Pages served over HTTP/2 if a CDN is used, 30% if CDN not used +--- + +## Introduction + +HTTP is an application layer protocol designed to transfer information between networked devices and runs on top of other layers of the network protocol stack. After HTTP/1.x was released, it took over 20 years until the first major update, HTTP/2, was made a standard in 2015. + +It didn't stop there: over the last four years, HTTP/3 and QUIC (a new latency-reducing, reliable, and secure transport protocol) have been under standards development in the IETF QUIC working group. There are actually two protocols that share the same name: "Google QUIC" ("gQUIC" for short), the original protocol that was designed and used by Google, and the newer IETF standardized version (IETF QUIC/QUIC). IETF QUIC was based on gQUIC, but has grown to be quite different in design and implementation. On October 21, 2020, draft 32 of IETF QUIC reached a significant milestone when it moved to Last Call. This is the part of the standardization process when the working group believes they are almost finished and requests a final review from the wider IETF community. + +This chapter reviews the current state of HTTP/2 and gQUIC deployment. It explores how well some of the newer features of the protocol, such as prioritization and server push, have been adopted. We then look at the motivations for HTTP/3, describe the major differences between the protocol versions, and discuss the potential challenges in upgrading to a UDP-based transport protocol with QUIC. + +### HTTP/1.0 to HTTP/2 + +As the HTTP protocol has evolved, the semantics of HTTP have stayed the same; there have been no changes to the HTTP methods (such as GET or POST), status codes (200, or the dreaded 404), URIs, or header fields. Where the HTTP protocol has changed, the differences have been the wire-encoding and the use of features of the underlying transport. + +HTTP/1.0, published in 1996, defined the text-based application protocol, allowing clients and servers to exchange messages in order to request resources. A new TCP connection was required for each request/response, which introduced overhead. TCP connections use a congestion control algorithm to maximize how much data can be in-flight. This process takes time for each new connection. This "slow-start" means that not all the available bandwidth is used immediately. + +In 1997, HTTP/1.1 was introduced to allow TCP connection reuse by adding "keep-alives", aimed at reducing the total cost of connection start-ups. Over time, increasing website performance expectations led to the need for concurrency of requests. HTTP/1.1 could only request another resource after the previous response had completed. Therefore, additional TCP connections had to be established, reducing the impact of the keep-alive connections and further increasing overhead. + +HTTP/2, published in 2015, is a binary-based protocol that introduced the concept of bidirectional streams between client and server. Using these streams, a browser can make optimal use of a single TCP connection to _multiplex_ multiple HTTP requests/responses concurrently. HTTP/2 also introduced a prioritization scheme to steer this multiplexing; clients can signal a request priority that allows more important resources to be sent ahead of others. + +## HTTP/2 Adoption + +The data used in this chapter is sourced from the HTTP Archive and tests over seven million websites with a Chrome browser. As with other chapters, the analysis is split by mobile and desktop websites. When the results between desktop and mobile are similar, statistics are presented from the mobile dataset. You can find more details on the [Methodology](./methodology) page. When reviewing this data, please bear in mind that each website will receive equal weight regardless of the number of requests. We suggest you think of this more as investigating the trends across a broad range of active websites. + +{{ figure_markup( + image="http2-h2-usage.png", + alt="HTTP/2 usage by request.", + link="https://httparchive.org/reports/state-of-the-web#h2", + caption='HTTP/2 usage by request. (Source: HTTP Archive)', + description="Timeseries chart of HTTP/2 usage showing adoption at 64% for both desktop and mobile as of July 2019. The trend is growing steadily at about 15 points per year.", + width=600, + height=321 + ) +}} + +Last year's analysis of HTTP Archive data showed that HTTP/2 was used for over 50% of requests and, as can be seen, linear growth has continued in 2020; now in excess of 60% of requests are served over HTTP/2. + +{{ figure_markup( + caption="The percentage of requests that use HTTP/2.", + content="64%", + classes="big-number", + sheets_gid="2122693316", + sql_file="adoption_of_http_2_by_site_and_requests.sql" +) +}} + +When comparing Figure 22.3 with last year's results, there has been a **10% increase in HTTP/2 requests** and a corresponding 10% decrease in HTTP/1.x requests. This is the first year that gQUIC can be seen in the dataset. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
ProtocolDesktopMobile
HTTP/1.1**34.47%34.11%
HTTP/263.70%63.80%
gQUIC1.72%1.71%
+ +
{{ figure_link(caption="HTTP version usage by request.", sheets_gid="2122693316", sql_file="adoption_of_http_2_by_site_and_requests.sql") }}
+
+ +

+ ** As with last year's crawl, around 4% of desktop requests did not report a protocol version. Analysis shows these to mostly be HTTP/1.1 and we worked to fix this gap in our statistics for future crawls and analysis. Although we base the data on the August 2020 crawl, we confirmed the fix in the October 2020 data set before publication which did indeed show these were HTTP/1.1 requests and so have added them to that statistic in above table. + + +When reviewing the total number of website requests, there will be a bias towards common third-party domains. To get a better understanding of the HTTP/2 adoption by server install, we will look instead at the protocol used to serve the HTML from the home page of a site. + +Last year around 37% of home pages were served over HTTP/2 and 63% over HTTP/1. This year, combining mobile and desktop, it is a roughly equal split, with slightly more desktop sites being served over HTTP/2 for the first time, as shown in Figure 22.4. + +

+ + + + + + + + + + + + + + + + + + + + + + + + + +
ProtocolDesktopMobile
HTTP/1.00.06%0.05%
HTTP/1.149.22%50.05%
HTTP/249.97%49.28%
+ +
{{ figure_link(caption="HTTP version usage for home pages.", sheets_gid="1447413141", sql_file="measure_of_all_http_versions_for_main_page_of_all_sites.sql") }}
+
+ +gQUIC is not seen in the home page data for two reasons. To measure a website over gQUIC, the HTTP Archive crawl would have to perform protocol negotiation via the [alternative services](#alternative-services) header and then use this endpoint to load the site over gQUIC. This was not supported this year, but expect it to be available in next year's Web Almanac. Also, gQUIC is predominantly used for third-party Google tools rather than serving home pages. + +The drive to increase [security](./security) and [privacy](./privacy) on the web has seen requests over TLS increase by over 150% in the last 4 years. Today, over 86% of all requests on mobile and desktop are encrypted. Looking only at home pages, the numbers are still an impressive 78.1% of desktop and 74.7% of mobile. This is important because HTTP/2 is only supported by browsers over TLS. The proportion served over HTTP/2, as shown in Figure 22.5, has also increased by 10 percentage points from [last year](../2019/http2#fig-5), from 55% to 65%. + +
+ + + + + + + + + + + + + + + + + + + + +
ProtocolDesktopMobile
HTTP/1.136.05%34.04%
HTTP/263.95%65.96%
+ +
{{ figure_link(caption="HTTP version usage for HTTPS home pages.", sheets_gid="900140630", sql_file="tls_adoption_by_http_version.sql") }}
+
+ +With over 60% of websites being served over HTTP/2 or gQUIC, let's look a little deeper into the pattern of protocol distribution for all requests made across individual sites. + +{{ figure_markup( + image="http2-h2-or-gquic-requests-per-page.png", + caption="Compare the distribution of fraction of HTTP/2 requests per page in 2020 with 2019.", + description="A bar chart of the fraction of HTTP/2 requests by page percentile. The median percentage of HTTP/2 or gQUIC requests per page has increased to 76% in 2020 from 46% in 2019. At the 10, 25, 75, and 90th percentiles, the fraction of HTTP/2 or gQUIC requests per page in 2020 is 5%, 24%, 98% and 100% compared to 3%, 15%, 93% and 100% in 2019.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=1328744214&format=interactive", + sheets_gid="152400778", + sql_file="percentiles_of_resources_loaded_over_HTTP2_or_better_per_site.sql" + ) +}} + +Figure 22.6 compares how much HTTP/2 or gQUIC is used on a website between this year and last year. The most noticeable change is that over half of sites now have 75% or more of their requests served over HTTP/2 or gQUIC compared to 46% last year. Less than 7% of sites make no HTTP/2 or gQUIC requests, while (only) 10% of sites are entirely HTTP/2 or gQUIC requests. + +What about the breakdown of the page itself? We typically talk about the difference between first-party and third-party content. Third-party is defined as content not within the direct control of the site owner, providing functionality such as advertising, marketing or analytics. The definition of known third parties is taken from the third party web repository. + +Figure 22.7 orders every website by the fraction of HTTP/2 requests for known third parties or first party requests compared to other requests. There is a noticeable difference as over 40% of all sites have no first-party HTTP/2 or gQUIC requests at all. By contrast, even the lowest 5% of pages have 30% of third-party content served over HTTP/2. This indicates that a large part of HTTP/2's broad adoption is driven by the third parties. + +{{ figure_markup( + image="http2-first-and-third-party-http2-usage.png", + caption="The distribution of the fraction of third-party and first-party HTTP/2 requests per page.", + description="A line chart comparing the fraction of first-party HTTP/2 requests with third-party HTTP/2 or gQUIC requests. The chart orders the websites by fraction of HTTP/2 requests. 45% of websites have no HTTP/2 first-party requests. Over half of websites serve third-party requests only over HTTP/2 or gQUIC. 80% of websites have 76% or more third-party HTTP/2 or gQUIC requests.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=1409316276&format=interactive", + sql_file="http2_1st_party_vs_3rd_party.sql", + sheets_gid="733872185" +) +}} + +Is there any difference in which content-types are served over HTTP/2 or gQUIC? Figure 22.8 shows, for example, that 90% of websites serve 100% of third party fonts and audio over HTTP/2 or gQUIC, only 5% over HTTP/1.1 and 5% are a mix. The majority of third-party assets are either scripts or images, and are solely served over HTTP/2 or gQUIC on 60% and 70% of websites respectively. + +{{ figure_markup( + image="http2-third-party-http2-usage-by-content-type.png", + caption="The fraction of known third-party HTTP/2 or gQUIC requests by content-type per website.", + description="A bar chart comparing the fraction of third-party HTTP/2 requests by content-type. All third-party requests are served over HTTP/2 or gQUIC for 90% of audio and fonts, 80% of css and video, 70% of html, image and text and 60% of scripts.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=1264128523&format=interactive", + sheets_gid="419557288", + sql_file="http2_1st_party_vs_3rd_party_by_type.sql" +) +}} + +Ads, analytics, content delivery network (CDN) resources, and tag-managers are predominantly served over HTTP/2 or gQUIC as shown in Figure 22.9. Customer-success and marketing content is more likely to be served over HTTP/1. + +{{ figure_markup( + image="http2-third-party-http2-usage-by-category.png", + caption="The fraction of known third-party HTTP/2 or gQUIC requests by category per website.", + description="A bar chart comparing the fraction of third-party HTTP/2 or gQUIC requests by category. All third-party requests for all websites are served over HTTP/2 or gQUIC for 95% of tag managers, 90% of analytics and CDN, 80% of ads, social, hosting and utility, 40% of marketing and 30% of customer-success.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=1419102835&format=interactive", + sheets_gid="1059610651", + sql_file="http2_3rd_party_by_types.sql" +) +}} + +### Server support + +Browser auto-update mechanisms are a driving factor for client-side adoption of new web standards. It's estimated that over 97% of global users support HTTP/2, up slightly from 95% measured last year. + +Unfortunately, the upgrade path for servers is more difficult, especially with the requirement to support TLS. For mobile and desktop, we can see from Figure 22.10, that the majority of HTTP/2 sites are served by nginx, Cloudflare, and Apache. Almost half of the HTTP/1.1 sites are served by Apache. + +{{ figure_markup( + image="http2-server-protocol-usage.png", + caption="Server usage by HTTP protocol on mobile", + description="A bar chart showing the number of websites served by either HTTP/1.x or HTTP/2 for the most popular servers to mobile clients. Nginx serves 727,181 HTTP/1.1 and 1,023,575 HTTP/2 sites. Cloudflare 59,981 HTTP/1.1 and 679,616 HTTP/2. Apache 1,521,753 HTTP/1.1 and 585,096 HTTP/2. Litespeed 50,502 HTTP/1.1 and 166,721 HTTP/2. Microsoft-IIS 284,047 HTTP/1.1 and 81,490 HTTP/2.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=718663369&format=interactive", + sheets_gid="306338094", + sql_file="count_of_h2_and_h3_sites_grouped_by_server.sql" +) +}} + +How has HTTP/2 adoption changed in the last year for each server? Figure 22.11 shows a general HTTP/2 adoption increase of around 10% across all servers since last year. Apache and IIS are still under 25% HTTP/2. This suggests that either new servers tend to be nginx or it is seen as too difficult or not worthwhile to upgrade Apache or IIS to HTTP/2 and/or TLS. + +{{ figure_markup( + image="http2-h2-usage-by-server.png", + caption="Percentage of pages served over HTTP/2 by server", + description="A bar chart comparing the percentage of websites served over HTTP/2 between 2019 and 2020. Cloudflare increased to 93.08% from 85.40%. Litespeed increased to 81.91% from 70.80%. Openresty increased to 66.24% from 51.40%. Nginx increased to 60.84% from 49.20%. Apache increased to 27.19% from 18.10% and MIcorsoft-IIS increased to 22.82% from 14.10%.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=936321266&format=interactive", + sheets_gid="306338094", + sql_file="count_of_h2_and_h3_sites_grouped_by_server.sql" + ) +}} + +A long-term recommendation to improve website performance has been to use a CDN. The benefit is a reduction in latency by both serving content and terminating connections closer to the end user. This helps mitigate the rapid evolution in protocol deployment and the additional complexities in tuning servers and operating systems (see the [Prioritization](#prioritization) section for more details). To utilize the new protocols effectively, using a CDN can be seen as the recommended approach. + +CDNs can be classed in two broad categories: those that serve the home page and/or asset subdomains, and those that are mainly used to serve third-party content. Examples of the first category are the larger generic CDNs (such as Cloudflare, Akamai, or Fastly) and the more specific (such as WordPress or Netlify). Looking at the difference in HTTP/2 adoption rates for home pages served with or without a CDN, we see: + +- **80%** of mobile home pages are served over HTTP/2 if a CDN is used +- **30%** of mobile home pages are served over HTTP/2 if a CDN is not used + +Figure 22.12 shows the more specific and the modern CDNs serve a higher proportion of traffic over HTTP/2. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
HTTP/2 (%)CDN
100%Bison Grid, CDNsun, LeaseWeb CDN, NYI FTW, QUIC.cloud, Roast.io, Sirv CDN, Twitter, Zycada Networks
90 - 99%Automattic, Azion, BitGravity, Facebook, KeyCDN, Microsoft Azure, NGENIX, Netlify, Yahoo, section.io, Airee, BunnyCDN, Cloudflare, GoCache, NetDNA, SFR, Sucuri Firewall
70 - 89%Amazon CloudFront, BelugaCDN, CDN, CDN77, Erstream, Fastly, Highwinds, OVH CDN, Yottaa, Edgecast, Myra Security CDN, StackPath, XLabs Security
20 - 69%Akamai, Aryaka, Google, Limelight, Rackspace, Incapsula, Level 3, Medianova, OnApp, Singular CDN, Vercel, Cachefly, Cedexis, Reflected Networks, Universal CDN, Yunjiasu, CDNetworks
< 20%Rocket CDN, BO.LT, ChinaCache, KINX CDN, Zenedge, ChinaNetCenter
+
{{ figure_link(caption="Percentage of HTTP/2 requests served by the first-party CDNs over mobile.", sheets_gid="781660433", sql_file="cdn_detail_by_cdn.sql") }}
+
+ +Types of content in the second category are typically shared resources (JavaScript or font CDNs), advertisements, or analytics. In all these cases, using a CDN will improve the performance and offload for the various SaaS solutions. + +{{ figure_markup( + image="http2-cdn-http2-usage.png", + caption="Comparison of HTTP/2 and gQUIC usage for websites using a CDN.", + description="A line chart comparing the fraction of requests served using HTTP/2 or gQUIC for websites that use a CDN compared to sites that do not. The x-axis show the percentiles of web page ordered by percentage of requests. 23% of websites that do not use a CDN have no HTTP/2 or gQUIC usage. In comparison the 60% of websites using a CDN have all HTTP/2 or gQUIC usage. 93% of websites that use a CDN and 47% of non-CDN sites have 50% or more HTTP/2 or gQUIC usage.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=1779365083&format=interactive", + sheets_gid="1457263817", + sql_file="cdn_summary.sql" +) +}} + +In Figure 22.13 we can see the stark difference in HTTP/2 and gQUIC adoption when a website is using a CDN. 70% of pages use HTTP/2 for all third-party requests when a CDN is used. Without a CDN, only 25% of pages use HTTP/2 for all third-party requests. + +## HTTP/2 impact + +Measuring the impact of how a protocol is performing is difficult with the current HTTP Archive [approach](./methodology). It would be really fascinating to be able to quantify the impact of concurrent connections, the effect of packet loss, and different congestion control mechanisms. To really compare performance, each website would have to be crawled over each protocol over different network conditions. What we can do instead is to look into the impact on the number of connections a website uses. + +### Reducing connections + +As discussed [earlier](#http10-to-http2), HTTP/1.1 only allows a single request at a time over a TCP connection. Most browsers get around this by allowing six parallel connections per host. The major improvement with HTTP/2 is that multiple requests can be multiplexed over a single TCP connection. This should reduce the total number of connections—and the associated time and resources—required to load a page. + +{{ figure_markup( + image="http2-total-number-of-connections-per-page.png", + caption="Distribution of total number of connections per page", + description="A percentile chart of total connections, comparing 2016 with 2020 on desktop. The median number of connections in 2016 is 23, in 2020 it is 13. At the 10th percentile, 6 connections in 2016, 5 in 2020. At the 25th percentile, 12 connections in 2016, 8 in 2020. At 75th percentile - 43 connections in 2016, 20 in 2020. At 90th percentile 76 connections in 2016 and 33 in 2020.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=17394219&format=interactive", + sheets_gid="1432183252", + sql_file="measure_number_of_tcp_connections_per_site.sql" +) +}} + +Figure 22.15 shows how the number of TCP connections per page has reduced in 2020 compared with 2016. Half of all websites now use 13 or fewer TCP connections in 2020 compared with 23 connections in 2016; a 44% decrease. In the same time period the median number of requests has only dropped from 74 to 73. The median number of requests per TCP connection has increased from 3.2 to 5.6. + +TCP was designed to maintain an average data flow that is both efficient and fair. Imagine a flow control process where each flow both exerts pressure on and is responsive to all other flows, to provide a fair share of the network. In a fair protocol, every TCP session does not crowd out any other session and over time will take 1/N of the path capacity. + +The majority of websites still open over 15 TCP connections. In HTTP/1.1, the six connections a browser could open to a domain can over time claim six times as much bandwidth as a single HTTP/2 connection. Over low capacity networks, this can slow down the delivery of content from the primary asset domains as the number of contending connections increases and takes bandwidth away from the important requests. This favors websites with a small number of third-party domains. + +HTTP/2 does allow for connection reuse across different, but related domains. For a TLS resource, it requires a certificate that is valid for the host in the URI. This can be used to reduce the number of connections required for domains under the control of the site author. + +### Prioritization + +As HTTP/2 responses can be split into many individual frames, and as frames from multiple streams can be multiplexed, the order in which the frames are interleaved and delivered by the server becomes a critical performance consideration. A typical website consists of many different types of resources: the visible content (HTML, CSS, images), the application logic (JavaScript), ads, analytics for tracking site usage, and marketing tracking beacons. With knowledge of how a browser works, an optimal ordering of the resources can be defined that will result in the fastest user experience. The difference between optimal and non-optimal can be significant—as much as a 50% performance improvement or more! + +HTTP/2 introduced the concept of prioritization to help the client communicate to the server how it thinks the multiplexing should be done. Every stream is assigned a weight (how much of the available bandwidth the stream should be allocated) and possibly a parent (another stream which should be delivered first). With the flexibility of HTTP/2's prioritization model, it is not altogether surprising that all of the current browser engines implemented different prioritization strategies, none of which are optimal. + +There are also problems on the server side, leading to many servers implementing prioritization either poorly or not at all. In the case of HTTP/1.x, tuning the server-side send buffers to be as big as possible has no downside, other than the increase in memory use (trading off memory for CPU), and is an effective way to increase the throughput of a web server. This is not true for HTTP/2, as data in the TCP send buffer cannot be re-prioritized if a request for a new, more important resource comes in. For an HTTP/2 server, the optimal send buffer size is thus the minimum amount of data required to fully utilize the available bandwidth. This allows the server to respond immediately if a higher-priority request is received. + +This problem of large buffers messing with (re-)prioritization also exists in the network, where it goes by the name "bufferbloat". Network equipment would rather buffer packets than drop them when there's a short burst. However, if the server sends more data than the path to the client can consume, these buffers fill to capacity. These bytes already "stored" on the network limit the server's ability to send a higher-priority response earlier, just as a large send buffer does. To minimize the amount of data held in buffers, a recent congestion control algorithm such as BBR should be used. + +This test suite maintained by Andy Davies measures and reports how various CDN and cloud hosting services perform. The bad news is that only 9 of the 36 services prioritize correctly. Figure 22.16 shows that for sites using a CDN, around 31.7% do not prioritize correctly. This is up from 26.82% last year, mainly due to the increase in Google CDN usage. Rather than relying on the browser-sent priorities, there are some servers that implement a server side prioritization scheme instead, improving upon the browser's hints with additional logic. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CDNPrioritize
correctly		DesktopMobile
Not using CDNUnknown59.47%60.85%
CloudflarePass22.03%21.32%
GoogleFail8.26%8.94%
Amazon CloudFrontFail2.64%2.27%
FastlyPass2.34%1.78%
AkamaiPass1.31%1.19%
AutomatticPass0.93%1.05%
Sucuri FirewallFail0.77%0.63%
IncapsulaFail0.42%0.34%
NetlifyFail0.27%0.20%
+
{{ figure_link(caption="HTTP/2 prioritization support in common CDNs.", sheets_gid="1152953475", sql_file="percentage_of_h2_and_h3_sites_affected_by_cdn_prioritization.sql") }}
+
+ +For non-CDN usage, we expect the number of servers that correctly apply HTTP/2 prioritization to be considerably smaller. For example, NodeJS's HTTP/2 implementation [does not support prioritization](https://twitter.com/jasnell/status/1245410283582918657). + +### Goodbye server push? + +Server push was one of the additional features of HTTP/2 that caused some confusion and complexity to implement in practice. Push seeks to avoid waiting for a browser/client to download a HTML page, parse that page, and only then discover that it requires additional resources (such as a stylesheet), which in turn have to be fetched and parsed to discover even more dependencies (such as fonts). All that work and round trips takes time. With server push, in theory, the server can just send multiple responses at once, avoiding the extra round trips. + +Unfortunately, with TCP congestion control in play, the data transfer starts off so slowly that not all the assets can be pushed until multiple round trips have increased the transfer rate sufficiently. There are also implementation differences between browsers as the client processing model had not been fully agreed. For example, each browser has a different implementation of a _push cache_. + +Another issue is that the server is not aware of resources the browser has already cached. When a server tries to push something that is unwanted, the client can send a `RST_STREAM` frame, but by the time this has happened, the server may well have already sent all the data. This wastes bandwidth and the server has lost the opportunity of immediately sending something that the browser actually did require. There were proposals to allow clients to inform the server of their cache status, but these suffered from privacy concerns. + +As can be seen from the Figure 20.17 below, a very small percentage of sites use server push. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
ClientHTTP/2 pagesHTTP/2 (%)gQUIC pagesgQUIC (%)
Desktop44,2570.85%2040.04%
Mobile62,8491.06%3260.06%
+
{{ figure_link(caption="Pages using HTTP/2 or gQUIC server push.", sheets_gid="698874709", sql_file="number_of_h2_and_h3_pushed_resources_and_bytes_transferred.sql") }}
+
+ +Looking further at the distributions for pushed assets in Figures 22.18 and 22.19, half of the sites push 4 or fewer resources with a total size of 140 KB on desktop and 3 or fewer resources with a size of 184 KB on mobile. For gQUIC, desktop is 7 or fewer and mobile 2. The worst offending page pushes _41 assets_ over gQUIC on desktop. + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PercentileHTTP/2Size (KB)gQUICSize (KB)
1013.95115.83
25236.32335.93
504139.587111.96
758346.7021203.59
9017440.0841390.91
+
{{ figure_link(caption="Distribution of pushed assets on desktop.", sheets_gid="698874709", sql_file="number_of_h2_and_h3_pushed_resources_and_bytes_transferred.sql") }}
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PercentileHTTP/2Size (KB)gQUICSize (KB)
10115.4810.06
25136.3410.06
503183.83224.06
7510225.415204.65
9012351.0518453.57
+
{{ figure_link(caption="Distribution of pushed assets on mobile.", sheets_gid="698874709", sql_file="number_of_h2_and_h3_pushed_resources_and_bytes_transferred.sql") }}
+
+ +Looking at the frequency of push by content type in Figure 22.20, we see 90% of pages push scripts and 56% push CSS. This makes sense, as these can be small files typically on the critical path to render a page. + +{{ figure_markup( + image="http2-pushed-content-types.png", + caption="Percentage of pages pushing specific content types", + description="A bar chart showing for pages that push resources on desktop; 89.1% push scripts, 67.9% css, 6.1% images, 1.3% fonts, 0.7% other and 0.7% html. On mobile 90.29% push scripts, 56.08% css, 3.69% images, 0.97% fonts, 0.36% other and 0.39% html.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=1708672642&format=interactive", + sheets_gid="238923402", + sql_file="number_of_h2_and_h3_pushed_resources_and_bytes_by_content_type.sql" +) +}} + +Given the low adoption, and after measuring how few of the pushed resources are actually useful (that is, they match a request that is not already cached), Google has announced the intent to remove push support from Chrome for both HTTP/2 and gQUIC. Chrome has also not implemented push for HTTP/3. + +Despite all these problems, there are circumstances where server push can provide an improvement. The ideal use case is to be able to send a push promise much earlier than the HTML response itself. A scenario where this can benefit is when a CDN is in use. The "dead time" between the CDN receiving the request and receiving a response from the origin can be used intelligently to warm up the TCP connection and push assets already cached at the CDN. + +There was however no standardized method for how to signal to a CDN edge server that an asset should be pushed. Implementations instead reused the preload HTTP link header to indicate this. This simple approach appears elegant, but it does not utilize the dead time before the HTML is generated unless the headers are sent before the actual content is ready. It triggers the edge to push resources as the HTML is received at the edge, which will contend with the delivery of the HTML. + +An alternative proposal being tested is RFC 8297, which defines an informative `103 (Early Hints)` response. This permits headers to be sent immediately, without having to wait for the server to generate the full response headers. This can be used by an origin to suggest pushed resources to a CDN, or by a CDN to alert the client to resources that need to be fetched. However, at present, support for this from both a client and server perspective is very low, but growing. + +## Getting to a better protocol + +Let's say a client and server support both HTTP/1.1 and HTTP/2. How do they choose which one to use? The most common method is TLS [Application Layer Protocol Negotiation](https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation) (ALPN), in which clients send a list of protocols they support to the server, which picks the one it prefers to use for that connection. Because the browser needs to negotiate the TLS parameters as part of setting up an HTTPS connection, it can also negotiate the HTTP version at the same time. Since both HTTP/2 and HTTP/1.1 can be served from the same TCP port (443), browsers don't need to make this selection before opening a connection. + +This doesn't work if the protocols aren't on the same port, use a different transport protocol (TCP versus QUIC), or if you're not using TLS. For those scenarios, you start with whatever is available on the first port you connect to, then discover other options. HTTP defines two mechanisms to change protocols for an origin after connecting: `Upgrade` and `Alt-Svc`. + +### `Upgrade` + +The Upgrade header has been part of HTTP for a long time. In HTTP/1.x, `Upgrade` allows a client to make a request using one protocol, but indicate its support for another protocol (like HTTP/2). If the server also supports the offered protocol, it responds with a status 101 (`Switching Protocols`) and proceeds to answer the request in the new protocol. If not, the server answers the request in HTTP/1.x. Servers can advertise their support of a different protocol using an `Upgrade` header on a response. + +The most common application of `Upgrade` is [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API). HTTP/2 also defines an `Upgrade` path, for use with its unencrypted cleartext mode. There is no support for this capability in web browsers, however. Therefore, it's not surprising that less than 3% of cleartext HTTP/1.1 requests in our dataset received an `Upgrade` header in the response. A very small number of requests using TLS (0.0011% of HTTP/2, 0.064% of HTTP/1.1) also received `Upgrade` headers in response; these are likely cleartext HTTP/1.1 servers behind intermediaries which speak HTTP/2 and/or terminate TLS, but don't properly remove `Upgrade` headers. + +### Alternative Services + +Alternative Services (`Alt-Svc`) enables an HTTP origin to indicate other endpoints which serve the same content, possibly over different protocols. Although uncommon, HTTP/2 might be located at a different port or different host from a site's HTTP/1.1 service. More importantly, since HTTP/3 uses QUIC (hence UDP) where prior versions of HTTP use TCP, HTTP/3 will always be at a different endpoint from the HTTP/1.x and HTTP/2 service. + +When using `Alt-Svc`, a client makes requests to the origin as normal. However, if the server includes a header or sends a frame containing a list of alternatives, the client can make a new connection to the other endpoint and use it for future requests to that origin. + +Unsurprisingly, `Alt-Svc` usage is found almost entirely from services using advanced HTTP versions: 12.0% of HTTP/2 requests and 60.1% of gQUIC requests received an `Alt-Svc` header in response, as compared to 0.055% of HTTP/1.x requests. Note that our methodology here only captures `Alt-Svc` headers, not `ALTSVC` frames in HTTP/2, so reality might be slightly understated. + +While `Alt-Svc` can point to an entirely different host, support for this capability varies among browsers. Only 4.71% of `Alt-Svc` headers advertised an endpoint on a different hostname; these were almost universally (99.5%) advertising gQUIC and HTTP/3 support on Google Ads. Google Chrome ignores cross-host `Alt-Svc` advertisements for HTTP/2, so many of the other instances would have been ignored. + +Given the rarity of support for cross-host HTTP/2, it's not surprising that there were virtually no (0.007%) advertisements for HTTP/2 endpoints using `Alt-Svc`. `Alt-Svc` was typically used to indicate support for HTTP/3 (74.6% of `Alt-Svc` headers) or gQUIC (38.7% of `Alt-Svc` headers). + +## Looking toward the future: HTTP/3 + +HTTP/2 is a powerful protocol, which has found considerable adoption in just a few years. However, HTTP/3 over QUIC is already peeking around the corner! Over four years in the making, this next version of HTTP is almost standardized at the IETF (expected in the first half of 2021). At this time, there are already many QUIC and HTTP/3 implementations available, both for servers and browsers. While these are relatively mature, they can still be said to be in an experimental state. + +This is reflected by the usage numbers in the HTTP Archive data, where no HTTP/3 requests were identified at all. This might seem a bit strange, since Cloudflare has had experimental HTTP/3 support for some time, as have Google and Facebook. This is mainly because Chrome hadn't enabled the protocol by default when the data was collected. + +However, even the numbers for the older gQUIC are relatively modest, accounting for less than 2% of requests overall. This is expected, since gQUIC was mostly deployed by Google and Akamai; other parties were waiting for IETF QUIC. As such, gQUIC is expected to be replaced entirely by HTTP/3 soon. + +{{ figure_markup( + caption="The percentage of requests that use gQUIC on desktop and mobile", + content="1.72%", + classes="big-number", + sheets_gid="2122693316", + sql_file="adoption_of_http_2_by_site_and_requests.sql" +) +}} + +It's important to note that this low adoption only reflects gQUIC and HTTP/3 usage for loading Web pages. For several years already, Facebook has had a much more extensive deployment of IETF QUIC and HTTP/3 for loading data inside of its native applications. QUIC and HTTP/3 already make up over 75% of their total internet traffic. It is clear that HTTP/3 is only just getting started! + +Now you might wonder: if not everyone is already using HTTP/2, why would we need HTTP/3 so soon? What benefits can we expect in practice? Let's take a closer look at its internal mechanisms. + +### QUIC and HTTP/3 + +Past attempts to deploy new transport protocols on the internet have proven difficult, for example [Stream Control Transmission Protocol](https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol) (SCTP). QUIC is a new transport protocol that runs on top of UDP. It provides similar features to TCP, such as reliable in-order delivery and congestion control to prevent flooding the network. + +As discussed in the [HTTP/1.0 to HTTP/2](#http10-to-http2) section, HTTP/2 _multiplexes_ multiple different streams on top of one connection. TCP itself is woefully unaware of this fact, leading to inefficiencies or performance impact when packet loss or delays occur. More details on this problem, known as _head-of-line blocking_ (HOL blocking), can be found here. + +QUIC solves the HOL blocking problem by bringing HTTP/2's streams down into the transport layer and performing per-stream loss detection and retransmission. So then we just put HTTP/2 over QUIC, right? Well, we've [already mentioned](#reducing-connections) some of the difficulties arising from having flow control in TCP and HTTP/2. Running two separate and competing streaming systems on top of each other would be an additional problem. Furthermore, because the QUIC streams are independent, it would mess with the strict ordering requirements HTTP/2 requires for several of its systems. + +In the end, it was deemed easier to define a new HTTP version that uses QUIC directly and thus, HTTP/3 was born. Its high-level features are very similar to those we know from HTTP/2, but internal implementation mechanisms are quite different. HPACK header compression is replaced with QPACK, which allows manual tuning of the compression efficiency versus HOL blocking risk tradeoff, and the prioritization system is being replaced by a simpler one. The latter could also be back-ported to HTTP/2, possibly helping resolve the prioritization issues discussed earlier in this article. HTTP/3 continues to provide a server push mechanism, but Chrome, for example, does not implement it. + +Another benefit of QUIC is that it is able to migrate connections and keep them alive even when the underlying network changes. A typical example is the so-called "parking lot problem". Imagine your smartphone is connected to the workplace Wi-Fi network and you've just started downloading a large file. As you leave Wi-Fi range, your phone automatically switches to the fancy new 5G cellular network. With plain old TCP, the connection would break and cause an interruption. But QUIC is smarter; it uses a _connection ID_, which is more robust to network changes, and provides an active _connection migration_ feature for clients to switch without interruption. + +Finally, TLS is already used to protect HTTP/1.1 and HTTP/2. QUIC, however, has a deep integration of TLS 1.3, protecting both HTTP/3 data and QUIC packet metadata, such as packet numbers. Using TLS in this way improves end-user privacy and security and makes continued protocol evolution easier. Combining the transport and cryptographic handshakes means that connection setup takes just a single RTT, compared to TCP's minimum of two and worst case of four. In some cases, QUIC can even go one step further and send HTTP data along with its very first message, which is called _0-RTT_. These fast connection setup times are expected to really help HTTP/3 outperform HTTP/2. + +**So, will HTTP/3 help?** + +On the surface, HTTP/3 is really not all that different from HTTP/2. It doesn't add any major features, but mainly changes how the existing ones work under the surface. The real improvements come from QUIC, which offers faster connection setups, increased robustness, and resilience to packet loss. As such, HTTP/3 is expected to do better than HTTP/2 on worse networks, while offering very similar performance on faster systems. However, that is if the web community can get HTTP/3 working, which can be challenging in practice. + +### Deploying and discovering HTTP/3 + +Since QUIC and HTTP/3 run over UDP, things aren't as simple as with HTTP/1.1 or HTTP/2. Typically, an HTTP/3 client has to first discover that QUIC is available at the server. The recommended method for this is [HTTP Alternative Services](#alternative-services) . On its first visit to a website, a client connects to a server using TCP. It then discovers via `Alt-Svc` that HTTP/3 is available, and can set up a new QUIC connection. The `Alt-Svc` entry can be cached, allowing subsequent visits to avoid the TCP step, but the entry will eventually become stale and need revalidation. This likely will have to be done for each domain separately, which will probably lead to most page loads using a mix of HTTP/1.1, HTTP/2, and HTTP/3. + +However, even if it is known that a server supports QUIC and HTTP/3, the network in between might block it. UDP traffic is commonly used in DDoS attacks and blocked by default in for example many company networks. While exceptions could be made for QUIC, its encryption makes it difficult for firewalls to assess the traffic. There are potential solutions to these issues, but in the meantime it is expected that QUIC is most likely to succeed on well-known ports like 443. And it is entirely possible that it is blocked QUIC altogether. In practice, clients will likely use sophisticated mechanisms to fall back to TCP if QUIC fails. One option is to "race" both a TCP and QUIC connection and use the one that completes first. + +There is ongoing work to define ways to discover HTTP/3 without needing the TCP step. This should be considered an optimization, though, as the UDP blocking issues are likely to mean that TCP-based HTTP sticks around. The HTTPS DNS record is similar to HTTP Alternative Services and some CDNs are already experimenting with these records. In the long run, when most servers offer HTTP/3, browsers might switch to attempting that by default; that will take a long time. + +
+| TLS version | HTTP/1.x
desktop | HTTP/1.x
mobile | HTTP/2
desktop | HTTP/2
mobile | +| ------------ | ------ | ------ | ---- | -----| +| unknown | 4.06% | 4.03% | 5.05% | 7.28% | +| TLS 1.2 | 26.56% | 24.75% | 23.12% | 23.14% | +| TLS 1.3 | 5.25% | 5.11% | 35.78% | 35.54% | + +
{{ figure_link(caption="TLS adoption by HTTP version.", sheets_gid="900140630", sql_file="tls_adoption_by_http_version.sql") }}
+
+ +QUIC is dependent on TLS 1.3, which is used for around 41% of requests, as shown in Figure 22.21. That leaves 59% of requests that will need to update their TLS stack to support HTTP/3. + +### Is HTTP/3 ready yet? + +So, when can we start using HTTP/3 and QUIC for real? Not quite yet, but hopefully soon. There is a large number of mature open source implementations and the major browsers have experimental support. However, most of the typical servers have suffered some delays: nginx is a bit behind other stacks, Apache hasn't announced official support, and NodeJS relies on OpenSSL, which won't add QUIC support anytime soon. Even so, we expect to see HTTP/3 and QUIC deployments rise throughout 2021. + +HTTP/3 and QUIC are highly advanced protocols with powerful performance and security features, such as a new HTTP prioritization system, HOL blocking removal, and 0-RTT connection establishment. This sophistication also makes them difficult to deploy and use correctly, as has turned out to be the case for HTTP/2. We predict that early deployments will mainly be done via the early adoption of CDNs such as Cloudflare, Fastly, and Akamai. This will probably mean that a large part of HTTP/2 traffic can and will be upgraded to HTTP/3 automatically in 2021, giving the new protocol a large traffic share almost out of the box. When and if smaller deployments will follow suit is more difficult to answer. Most likely, we will continue to see a healthy mix of HTTP/3, HTTP/2, and even HTTP/1.1 on the web for years to come. + +## Conclusion + +This year, HTTP/2 has become the dominant protocol, serving 64% of all requests, having grown by 10 percentage points during the year. Home pages have seen a 13% increase in HTTP/2 adoption, leading to an even split of pages served over HTTP/1.1 and HTTP/2. Using a CDN to serve your home page pushes HTTP/2 adoption up to 80%, compared with 30% for non-CDN usage. There remain some older servers, Apache and IIS, that are proving resistant to upgrading to HTTP/2 and TLS. A big success has been the decrease in website connection usage due to HTTP/2 connection multiplexing. The median number of connections in 2016 was 23 compared to 13 in 2020. + +HTTP/2 prioritization and server push have turned out to be way more complex to deploy at large. Under certain implementations they show clear performance benefits. There is, however, a significant barrier to deploying and tuning existing servers to use these features effectively. There are still a large proportion of CDNs who do not support prioritization effectively. There have also been issues with consistent browser support. + +HTTP/3 is just around the corner. It will be fascinating to follow the adoption rate, see how discovery mechanisms evolve, and find out which new features will be deployed successfully. We expect next year's Web Almanac to see some interesting new data. From 7e5746cf29125bf82bf01ff1e51e970d6e6e05b6 Mon Sep 17 00:00:00 2001 From: Noah Date: Wed, 31 Mar 2021 13:45:35 +0200 Subject: [PATCH 02/11] fix: "je" to "u" --- src/content/nl/2020/resource-hints.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/content/nl/2020/resource-hints.md b/src/content/nl/2020/resource-hints.md index 9e7a2aeabd3..1969f279c98 100644 --- a/src/content/nl/2020/resource-hints.md +++ b/src/content/nl/2020/resource-hints.md @@ -128,7 +128,7 @@ Vergeleken met [2019](../2019/resource-hints#resource-hints) had de `dns-prefetc sql_file="adoption.sql" ) }} -Het gebruik van `preload` heeft een langzamere groei doorgemaakt met slechts een stijging van 2% ten opzichte van 2019. Dit zou gedeeltelijk kunnen zijn omdat het wat meer specificatie vereist. Hoewel je alleen het domein nodig hebt om `dns-prefetch` en `preconnect` te gebruiken, moet je de bron specificeren om `preload` te gebruiken. Hoewel `dns-prefetch` en `preconnect` een redelijk laag risico vormen, maar nog steeds kunnen worden misbruikt, heeft `preload` een veel groter potentieel om de prestaties daadwerkelijk te schaden als het onjuist wordt gebruikt. +Het gebruik van `preload` heeft een langzamere groei doorgemaakt met slechts een stijging van 2% ten opzichte van 2019. Dit zou gedeeltelijk kunnen zijn omdat het wat meer specificatie vereist. Hoewel u alleen het domein nodig hebt om `dns-prefetch` en `preconnect` te gebruiken, moet u de bron specificeren om `preload` te gebruiken. Hoewel `dns-prefetch` en `preconnect` een redelijk laag risico vormen, maar nog steeds kunnen worden misbruikt, heeft `preload` een veel groter potentieel om de prestaties daadwerkelijk te schaden als het onjuist wordt gebruikt. `prefetch` wordt gebruikt door 3% van de sites op Desktop, waardoor het de minst gebruikte bronhint is. Dit lage gebruik kan worden verklaard door het feit dat `prefetch` nuttig is om volgende, in plaats van huidige, paginaladingen te verbeteren. Het wordt dus over het hoofd gezien als een site alleen is gericht op het verbeteren van de bestemmingspagina of de prestaties van de eerste pagina die wordt bekeken. In de komende jaren met een duidelijkere definitie van wat moet worden gemeten om de volgende pagina-ervaring te verbeteren, kan het teams helpen prioriteit te geven aan `prefetch`-acceptatie met duidelijke prestatiekwaliteitsdoelen om te bereiken. @@ -200,7 +200,7 @@ Houd er rekening mee dat lettertypen die vooraf zijn geladen zonder het attribuu ### Het `media` attribuut -Wanneer het tijd is om een bron te kiezen voor gebruik met verschillende schermformaten, grijp dan naar het `media`-attribuut met `preload` om je mediaquery's te optimaliseren. +Wanneer het tijd is om een bron te kiezen voor gebruik met verschillende schermformaten, grijp dan naar het `media`-attribuut met `preload` om uw mediaquery's te optimaliseren. ```html @@ -213,7 +213,7 @@ Het zien van meer dan 2100 verschillende combinaties van mediaquery's in de 2020 Het gebruik van bronhints kan soms verwarrend zijn, dus laten we enkele snelle beste praktijken bekijken die we kunnen volgen op basis van de geautomatiseerde audit van Lighthouse. -Om `dns-prefetch` en `preconnect` veilig te implementeren, moet je ervoor zorgen dat ze in aparte link-tags staan. +Om `dns-prefetch` en `preconnect` veilig te implementeren, moet u ervoor zorgen dat ze in aparte link-tags staan. ```html @@ -344,13 +344,13 @@ Priority hints hebben een duidelijk voordeel als hulpmiddel om verspillend laden ### 103 Early Hints in HTTP/2 Eerder vermeldden we dat HTTP/2-push daadwerkelijk regressie kan veroorzaken in gevallen waarin activa die worden gepusht zich al in de browsercache bevinden. Het 103 Early Hints voorstel beoogt vergelijkbare voordelen te bieden die worden beloofd door HTTP/2-push. Met een architectuur die in potentie 10x eenvoudiger is, pakt het de lange RTT's of serververwerking aan zonder te lijden aan het bekende worst-case-probleem van onnodige rondtrips met server-push. -Vanaf nu kun je het gesprek op Chromium volgen met issues 671310, 1093693, en 1096414. +Vanaf nu kunt u het gesprek op Chromium volgen met issues 671310, 1093693, en 1096414. ## Gevolgtrekking In het afgelopen jaar zijn bronhints toegenomen in acceptatie, en het zijn essentiële API's geworden voor ontwikkelaars om meer gedetailleerde controle te hebben over veel aspecten van bronnenprioritering en uiteindelijk de gebruikerservaring. Maar laten we niet vergeten dat dit hints zijn, geen instructies en helaas zullen de browser en het netwerk altijd het laatste woord hebben. -Natuurlijk kun je ze op een heleboel elementen plaatsen, en de browser kan doen wat je van hem vraagt. Of het negeert enkele hints en besluit dat de standaardprioriteit de beste keuze is voor de gegeven situatie. Zorg er in ieder geval voor dat je een playbook hebt voor het beste gebruik van deze hints: +Natuurlijk kunt u ze op een heleboel elementen plaatsen, en de browser kan doen wat u van hem vraagt. Of het negeert enkele hints en besluit dat de standaardprioriteit de beste keuze is voor de gegeven situatie. Zorg er in ieder geval voor dat u een playbook hebt voor het beste gebruik van deze hints: - Identificeer de belangrijkste pagina's voor de gebruikerservaring. - Analyseer de belangrijkste middelen om te optimaliseren. From f6ec56cb2785696e83194e942c610b0793665460 Mon Sep 17 00:00:00 2001 From: Noah Date: Wed, 31 Mar 2021 13:56:12 +0200 Subject: [PATCH 03/11] fix: consistency --- src/content/nl/2020/capabilities.md | 4 ++-- src/content/nl/2020/cms.md | 2 +- src/content/nl/2020/fonts.md | 4 ++-- src/content/nl/2020/javascript.md | 14 +++++++------- src/content/nl/2020/media.md | 6 +++--- src/content/nl/2020/mobile-web.md | 4 ++-- src/content/nl/2020/resource-hints.md | 2 +- src/content/nl/2020/security.md | 14 +++++++------- src/content/nl/2020/third-parties.md | 4 ++-- 9 files changed, 27 insertions(+), 27 deletions(-) diff --git a/src/content/nl/2020/capabilities.md b/src/content/nl/2020/capabilities.md index bc779a5c653..795d3c7948b 100644 --- a/src/content/nl/2020/capabilities.md +++ b/src/content/nl/2020/capabilities.md @@ -9,7 +9,7 @@ editors: [rviscomi] translators: [noah-vdv] discuss: 2049 results: https://docs.google.com/spreadsheets/d/1N6j1qKv7vc51p1W9z_RrbJX9Se3Pmb-Uersfz4gWqqs/ -christianliebel_bio: Christian Liebel is consultant bij Thinktecture en ondersteunt klanten uit verschillende bedrijfsgebieden bij het implementeren van eersteklas webapplicaties. Hij is een Microsoft MVP voor Developer Technologies, Google GDE voor Web/Capabilities en Angular, en neemt deel aan de W3C Web Applications Working Group. +christianliebel_bio: Christian Liebel is consultant bij Thinktecture en ondersteunt cliënten uit verschillende bedrijfsgebieden bij het implementeren van eersteklas webapplicaties. Hij is een Microsoft MVP voor Developer Technologies, Google GDE voor Web/Capabilities en Angular, en neemt deel aan de W3C Web Applications Working Group. featured_quote: De staat van de webmogelijkheden in 2020 is gezond, aangezien nieuwe krachtige API's regelmatig worden geleverd met nieuwe releases van op Chromium gebaseerde browsers. De eerste API's zijn ook al in andere browsers terechtgekomen. featured_stat_1: 0,0006% featured_stat_label_1: (Chrome) Pagina laden met de Async Clipboard API @@ -111,7 +111,7 @@ Met behulp van de Push- en Notifications-API's kunnen webapplicaties al lang pus ### Badging API {badging-api} -Op verschillende platforms is het gebruikelijk dat applicaties een badge presenteren op het pictogram van de applicatie die het aantal openstaande acties aangeeft. De badge kan bijvoorbeeld het aantal ongelezen e-mails, meldingen of taken weergeven dat moet worden voltooid. Met de Badging API (W3C Unofficial Draft) kunnen geïnstalleerde webapplicaties een dergelijke badge weergeven op het icoon. Door `navigator.setAppBadge()` aan te roepen, kunnen ontwikkelaars de badge instellen. Voor deze methode is een nummer nodig om op de badge van de applicatie te worden weergegeven. De browser zorgt er vervolgens voor dat de weergave zo goed mogelijk wordt weergegeven op het apparaat van de gebruiker. Als er geen nummer is opgegeven, wordt een algemene badge weergegeven (bijvoorbeeld een witte stip op macOS). Door `navigator.clearAppBadge()` aan te roepen, wordt de badge weer verwijderd. De Badging-API is een uitstekende keuze voor e-mailklanten, apps voor sociale media of messengers. De Twitter PWA maakt gebruik van de Badging API om het aantal ongelezen meldingen op de badge van de applicatie weer te geven. +Op verschillende platforms is het gebruikelijk dat applicaties een badge presenteren op het pictogram van de applicatie die het aantal openstaande acties aangeeft. De badge kan bijvoorbeeld het aantal ongelezen e-mails, meldingen of taken weergeven dat moet worden voltooid. Met de Badging API (W3C Unofficial Draft) kunnen geïnstalleerde webapplicaties een dergelijke badge weergeven op het icoon. Door `navigator.setAppBadge()` aan te roepen, kunnen ontwikkelaars de badge instellen. Voor deze methode is een nummer nodig om op de badge van de applicatie te worden weergegeven. De browser zorgt er vervolgens voor dat de weergave zo goed mogelijk wordt weergegeven op het apparaat van de gebruiker. Als er geen nummer is opgegeven, wordt een algemene badge weergegeven (bijvoorbeeld een witte stip op macOS). Door `navigator.clearAppBadge()` aan te roepen, wordt de badge weer verwijderd. De Badging-API is een uitstekende keuze voor e-mailcliënten, apps voor sociale media of messengers. De Twitter PWA maakt gebruik van de Badging API om het aantal ongelezen meldingen op de badge van de applicatie weer te geven. {{ figure_markup( image="badging_api.png", diff --git a/src/content/nl/2020/cms.md b/src/content/nl/2020/cms.md index 3af54fd71b1..a8b20bc1147 100644 --- a/src/content/nl/2020/cms.md +++ b/src/content/nl/2020/cms.md @@ -121,7 +121,7 @@ Deze cijfers zijn in grote lijnen consistent wanneer ze worden verdeeld over des {{ figure_markup( image="cms-top-5-cms-by-client.png", - caption="Top 5 CMS'en per klant.", + caption="Top 5 CMS'en per cliënt.", description="Staafdiagram dat laat zien dat WordPress domineert met een aandeel van 31,37% op desktop en 31,39% op mobiel vergeleken met minder dan 2,5% voor de andere CMS'en: Drupal heeft 2,32% op desktop en 1,99% op mobiel, Joomla heeft 1,96% op desktop en 2,12% op mobiel, Squarespace heeft 1,08% op desktop en 0,85% op mobiel, en Wiz heeft 1,05% op desktop en 1,24% op mobiel.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTkUxfuK-FCn3_IYDJiEsKDmdmyKb0TSEhG8dFc0XBIXej1NO2uUOmd-9NCbWuh-MZ3xzMhK_kNT-4u/pubchart?oid=2098327336&format=interactive", sheets_gid="908727245", diff --git a/src/content/nl/2020/fonts.md b/src/content/nl/2020/fonts.md index c8e55d24343..c0b94a48249 100644 --- a/src/content/nl/2020/fonts.md +++ b/src/content/nl/2020/fonts.md @@ -100,7 +100,7 @@ Het was interessant om de verschillen in snelheid op te merken voor sites die de ) }} -Bij het bekijken van commerciële services zoals Adobe (`use.typekit.net`) of Monotype (`fast.fonts.com`) is het interessant om op te merken dat ze op desktop net zo snel of iets sneller zijn dan Google Fonts, maar merkbaar langzamer op mobiel. De conventionele wijsheid heeft over het algemeen aangenomen dat de trackingscripts die door die services worden gebruikt, ze aanzienlijk vertragen, maar dat is blijkbaar tegenwoordig minder een probleem dan in de afgelopen jaren. Hoewel het waar is dat we de prestaties van de site meten en niet noodzakelijk de prestaties van de font-host, hebben deze trackingscripts invloed op het laden van lettertypen op de client, dus het lijkt relevant om deze observaties op te nemen. +Bij het bekijken van commerciële services zoals Adobe (`use.typekit.net`) of Monotype (`fast.fonts.com`) is het interessant om op te merken dat ze op desktop net zo snel of iets sneller zijn dan Google Fonts, maar merkbaar langzamer op mobiel. De conventionele wijsheid heeft over het algemeen aangenomen dat de trackingscripts die door die services worden gebruikt, ze aanzienlijk vertragen, maar dat is blijkbaar tegenwoordig minder een probleem dan in de afgelopen jaren. Hoewel het waar is dat we de prestaties van de site meten en niet noodzakelijk de prestaties van de font-host, hebben deze trackingscripts invloed op het laden van lettertypen op de cliënt, dus het lijkt relevant om deze observaties op te nemen. #### Zelfhosting is niet altijd beter @@ -130,7 +130,7 @@ Het zou niet logisch zijn om een causaliteit tussen de hostingstrategie af te le #### Lokaal is niet altijd beter -Een andere optie van self-hosting fonts op de server van de site, is om de door het systeem geïnstalleerde fonts op de client te gebruiken waar ze bestaan door het gebruik van `local` in de `font-face` declaratie. Het gebruik van `local` is controversieel, omdat het bytes kan besparen, maar het kan ook slechte resultaten opleveren als de lokaal geïnstalleerde versie van het lettertype is verouderd. Vanaf [november 2020](https://twitter.com/googlefonts/status/1328761547041148929?s=19) is Google Fonts overgeschakeld op het gebruik van `local` alleen voor Roboto op mobiele platforms, anders wordt het lettertype altijd opgehaald via de netwerk. +Een andere optie van self-hosting fonts op de server van de site, is om de door het systeem geïnstalleerde fonts op de cliënt te gebruiken waar ze bestaan door het gebruik van `local` in de `font-face` declaratie. Het gebruik van `local` is controversieel, omdat het bytes kan besparen, maar het kan ook slechte resultaten opleveren als de lokaal geïnstalleerde versie van het lettertype is verouderd. Vanaf [november 2020](https://twitter.com/googlefonts/status/1328761547041148929?s=19) is Google Fonts overgeschakeld op het gebruik van `local` alleen voor Roboto op mobiele platforms, anders wordt het lettertype altijd opgehaald via de netwerk. ## Racen naar eerste lak diff --git a/src/content/nl/2020/javascript.md b/src/content/nl/2020/javascript.md index 2053ac8bbb1..2717b001243 100644 --- a/src/content/nl/2020/javascript.md +++ b/src/content/nl/2020/javascript.md @@ -10,7 +10,7 @@ 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. U 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/ -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_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 cliëntzijde 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: Mediane JS-hoofdthread-tijd op mobiel featured_stat_2: 37,22% @@ -21,7 +21,7 @@ featured_stat_label_3: Percentage scripts dat asynchroon is geladen ## Inleiding -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. +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 cliëntzijde 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. 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. @@ -59,7 +59,7 @@ De trend lijkt ook in het voordeel te zijn van het gebruik van meer JavaScript, - + @@ -145,7 +145,7 @@ 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 cliëntzijde 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. @@ -363,7 +363,7 @@ De populaire bibliotheken die in gebruik zijn, zijn grotendeels ongewijzigd ten Vorig jaar stelde [Houssein een paar redenen voor waarom de dominantie van jQuery voortduurt](../2019/javascript#open-source-libraries-and-frameworks): > 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. +> Het overschakelen van jQuery naar een nieuwere cliëntzijde bibliotheek kan enige tijd duren, afhankelijk van hoe groot een applicatie is, en veel sites kunnen bestaan uit jQuery naast nieuwere cliëntzijde bibliotheken. Beide zijn zeer goede gissingen, en het lijkt erop dat de situatie op geen van beide fronten veel is veranderd. @@ -579,7 +579,7 @@ Wat nog belangrijker is, al deze hulpmiddelen betekenen doorgaans meer code en m 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 cliënt. {{ figure_markup( image="frameworks-bytes.png", @@ -592,7 +592,7 @@ 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 cliënt. 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. diff --git a/src/content/nl/2020/media.md b/src/content/nl/2020/media.md index 891fcda2b96..d10a04b90d1 100644 --- a/src/content/nl/2020/media.md +++ b/src/content/nl/2020/media.md @@ -1,7 +1,7 @@ --- #See https://github.com/HTTPArchive/almanac.httparchive.org/wiki/Authors'-Guide#metadata-to-add-at-the-top-of-your-chapters title: Media -description: Mediahoofdstuk van de Web Almanac 2020 met betrekking tot bestandsgroottes en -indelingen van afbeeldingen, responsieve afbeeldingen, klanthints, lazy loading, toegankelijkheid en video. +description: Mediahoofdstuk van de Web Almanac 2020 met betrekking tot bestandsgroottes en -indelingen van afbeeldingen, responsieve afbeeldingen, cliënthints, lazy loading, toegankelijkheid en video. authors: [tpiros, bseymour, eeeps] reviewers: [nhoizey, colinbendell, dougsillars, Navaneeth-akam] analysts: [smatei] @@ -53,7 +53,7 @@ Het aantal afbeeldingen dat aan de user agents wordt gepresenteerd om uit te kie 1. Breekpunten van afbeeldingen (om een prestatiebudget te halen) 2. Caching-efficiëntie -Hoe kleiner het aantal afbeeldingskandidaten, hoe groter de kans dat het item in de cache wordt opgeslagen, en als een CDN wordt gebruikt, hoe groter de kans dat het beschikbaar is op het dichtstbijzijnde edge-knooppunt van een klant. Hoe groter het verschil in media-afmetingen, hoe groter de kans dat we uiteindelijk media gaan aanbieden die minder geschikt zijn voor het apparaat en de context in kwestie. +Hoe kleiner het aantal afbeeldingskandidaten, hoe groter de kans dat het item in de cache wordt opgeslagen, en als een CDN wordt gebruikt, hoe groter de kans dat het beschikbaar is op het dichtstbijzijnde edge-knooppunt van een cliënt. Hoe groter het verschil in media-afmetingen, hoe groter de kans dat we uiteindelijk media gaan aanbieden die minder geschikt zijn voor het apparaat en de context in kwestie. ##### Srcset: hoeveelheid beeldkandidaten @@ -178,7 +178,7 @@ Van de pagina's die `` gebruiken om van formaat te wisselen, biedt onge {{ figure_markup( image="picture-format-usage-by-type.png", caption="Gebruik van beeldformaat op type.", - description="Staafdiagram met het gebruik van het beeldformaat per afbeeldingstype. WebP domineert het gebruik dat door 83,29% van de beeldelementen op desktop wordt gebruikt (84,64% op mobiel). De volgende is PNG met 18,18% en 17,46%, gevolgd door JPG gebruikt door respectievelijk 4,84% en 4,83%, en dan Gif met 0,53% en 0,53% en AVIF registreert niet boven 0 voor beide klanten.", + description="Staafdiagram met het gebruik van het beeldformaat per afbeeldingstype. WebP domineert het gebruik dat door 83,29% van de beeldelementen op desktop wordt gebruikt (84,64% op mobiel). De volgende is PNG met 18,18% en 17,46%, gevolgd door JPG gebruikt door respectievelijk 4,84% en 4,83%, en dan Gif met 0,53% en 0,53% en AVIF registreert niet boven 0 voor beide cliënten.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTLNnD9VNqXNxMu60VovxIEp_L6vmNo1oWt8-C18DOetXB3qIkee_-KjZwYYPIkkIM-7So-5wBwQ4QY/pubchart?oid=775091522&format=interactive", sheets_gid="1719719920", sql_file="picture_format_distribution.sql" diff --git a/src/content/nl/2020/mobile-web.md b/src/content/nl/2020/mobile-web.md index da1888171bf..135a931a2ee 100644 --- a/src/content/nl/2020/mobile-web.md +++ b/src/content/nl/2020/mobile-web.md @@ -386,7 +386,7 @@ Het is ook mogelijk om sommige formuliervelden helemaal te verwijderen. De API's ### 4. Retentie -De laatste fase in de reis is gebruikersbehoud, dit betekent de gebruiker opnieuw betrekken en van hem een terugkerende klant of een loyale bezoeker maken. +De laatste fase in de reis is gebruikersbehoud, dit betekent de gebruiker opnieuw betrekken en van hem een terugkerende cliënt of een loyale bezoeker maken. #### Installeerbaarheid met PWA @@ -396,7 +396,7 @@ Rakuten 24 is een online winkel van Rakuten, een van de grootste e-commercebedri Door installeerbaarheid te implementeren, zag Rakuten 24 ook deze verbeteringen over een tijdsbestek van 1 maand: * 310% stijging van de bezoekfrequentie per gebruiker, vergeleken met de rest van hun internetgebruikers -* 150% stijging van de omzet per klant met 150% +* 150% stijging van de omzet per cliënt met 150% * 200% stijging van de conversieratio #### Een naadloze ervaring op verschillende apparaten diff --git a/src/content/nl/2020/resource-hints.md b/src/content/nl/2020/resource-hints.md index 1969f279c98..46a2e05aaeb 100644 --- a/src/content/nl/2020/resource-hints.md +++ b/src/content/nl/2020/resource-hints.md @@ -264,7 +264,7 @@ Over het algemeen is voorspellend prefetchen nog onbekend terrein, maar in combi ## HTTP/2 Push -[HTTP/2](./http2) heeft een functie genaamd "server push" die de paginaprestaties mogelijk kan verbeteren wanneer uw product lange Round Trip Times ([RTTs](https://developer.mozilla.org/en-US/docs/Glossary/Round_Trip_Time_(RTT))) of serververwerking ervaart. Kort gezegd, in plaats van te wachten tot de client een verzoek verzendt, pusht de server preventief een bron waarvan hij voorspelt dat de cliënt deze spoedig daarna zal opvragen. +[HTTP/2](./http2) heeft een functie genaamd "server push" die de paginaprestaties mogelijk kan verbeteren wanneer uw product lange Round Trip Times ([RTTs](https://developer.mozilla.org/en-US/docs/Glossary/Round_Trip_Time_(RTT))) of serververwerking ervaart. Kort gezegd, in plaats van te wachten tot de cliënt een verzoek verzendt, pusht de server preventief een bron waarvan hij voorspelt dat de cliënt deze spoedig daarna zal opvragen. {{ figure_markup( caption="Het percentage HTTP / 2-push-pagina's dat gebruikmaakt van `preload`/`nopush`.", diff --git a/src/content/nl/2020/security.md b/src/content/nl/2020/security.md index 5a2cf929080..792330b97c8 100644 --- a/src/content/nl/2020/security.md +++ b/src/content/nl/2020/security.md @@ -197,7 +197,7 @@ Vervolgens zullen we kijken naar de certificaatautoriteiten (CA's) die de TLS-ce
{{ figure_link(caption="Top 10 uitgevers van certificaten voor websites.", sheets_gid="1486167130", sql_file="tls_ca_issuers_pages.sql") }}
-Het is geen verrassing om te zien dat Let's Encrypt met een goede voorsprong gemakkelijk de eerste plaats inneemt; de combinatie van gratis en geautomatiseerde certificaten is een winnaar bij zowel individuele website-eigenaren als platforms. Cloudflare biedt op dezelfde manier gratis certificaten aan voor zijn klanten die de nummer twee en nummer negen innemen. Wat daar interessanter is, is dat het de ECC Cloudflare-uitgever is die wordt gebruikt. ECC-certificaten zijn kleiner en dus efficiënter dan RSA-certificaten, maar kunnen gecompliceerd zijn om te implementeren omdat ondersteuning niet universeel is en het beheren van beide certificaten vaak extra inspanning vereist. Dit is het voordeel van een CDN of een gehoste provider als zij dit voor u kunnen beheren zoals Cloudflare hier doet. Browsers die ECC ondersteunen (zoals de Chrome-browser die we gebruiken in onze crawl) zullen dat gebruiken, en oudere browsers zullen RSA gebruiken. +Het is geen verrassing om te zien dat Let's Encrypt met een goede voorsprong gemakkelijk de eerste plaats inneemt; de combinatie van gratis en geautomatiseerde certificaten is een winnaar bij zowel individuele website-eigenaren als platforms. Cloudflare biedt op dezelfde manier gratis certificaten aan voor zijn cliënten die de nummer twee en nummer negen innemen. Wat daar interessanter is, is dat het de ECC Cloudflare-uitgever is die wordt gebruikt. ECC-certificaten zijn kleiner en dus efficiënter dan RSA-certificaten, maar kunnen gecompliceerd zijn om te implementeren omdat ondersteuning niet universeel is en het beheren van beide certificaten vaak extra inspanning vereist. Dit is het voordeel van een CDN of een gehoste provider als zij dit voor u kunnen beheren zoals Cloudflare hier doet. Browsers die ECC ondersteunen (zoals de Chrome-browser die we gebruiken in onze crawl) zullen dat gebruiken, en oudere browsers zullen RSA gebruiken. ### Browserhandhaving @@ -542,7 +542,7 @@ Als we de pagina's die ten minste één script hebben dat is beveiligd met SRI n
{{ figure_link(caption="De meest voorkomende hosts waarvan SRI-beveiligde scripts zijn opgenomen.", sheets_gid="2132259293", sql_file="sri_popular_hosts.sql") }}
-Als we kijken naar de meest populaire hosts waarvan SRI-beveiligde scripts zijn opgenomen, kunnen we enkele drijvende krachten zien die de acceptatie stimuleren. Bijna de helft van alle scripts die zijn beschermd met subresource-integrity, is bijvoorbeeld afkomstig van `cdn.shopify.com`, hoogstwaarschijnlijk omdat de Shopify SaaS dit standaard voor hun klanten inschakelt. +Als we kijken naar de meest populaire hosts waarvan SRI-beveiligde scripts zijn opgenomen, kunnen we enkele drijvende krachten zien die de acceptatie stimuleren. Bijna de helft van alle scripts die zijn beschermd met subresource-integrity, is bijvoorbeeld afkomstig van `cdn.shopify.com`, hoogstwaarschijnlijk omdat de Shopify SaaS dit standaard voor hun cliënten inschakelt. De rest van de top 5 hosts waarvan SRI-beveiligde scripts zijn opgenomen, bestaat uit drie CDN's: jQuery, cdnjs en Bootstrap. Het is waarschijnlijk niet toevallig dat alle drie deze CDN's het integrity attribuut hebben in de HTML-voorbeeldcode. @@ -791,7 +791,7 @@ De meeste van de cross-origin-beleidsregels zijn bedoeld om de mogelijk schadeli ### Web Cryptography API -De Web Cryptography API biedt geweldige JavaScript-functies voor ontwikkelaars die kunnen worden gebruikt om veilig en met weinig moeite cryptografische bewerkingen aan de clientzijde uit te voeren, zonder dat hiervoor externe bibliotheken nodig zijn. Deze JavaScript-API biedt niet alleen eenvoudige cryptografische bewerkingen, maar kan ook worden gebruikt om cryptografisch sterke willekeurige waarden, hashing, genereren en verifiëren van handtekeningen, codering en decodering te genereren. Met behulp van deze API kunnen we ook algoritmen implementeren voor het authenticeren van gebruikers, het ondertekenen van documenten, en het veilig beschermen van de vertrouwelijkheid en integriteit van communicatie. Bijgevolg maakt deze API meer veilige en gegevensbeschermingsconforme use-cases mogelijk op het gebied van end-to-end encryptie. Op deze manier levert de Web Cryptography API zijn bijdrage aan end-to-end encryptie. +De Web Cryptography API biedt geweldige JavaScript-functies voor ontwikkelaars die kunnen worden gebruikt om veilig en met weinig moeite cryptografische bewerkingen aan de cliëntzijde uit te voeren, zonder dat hiervoor externe bibliotheken nodig zijn. Deze JavaScript-API biedt niet alleen eenvoudige cryptografische bewerkingen, maar kan ook worden gebruikt om cryptografisch sterke willekeurige waarden, hashing, genereren en verifiëren van handtekeningen, codering en decodering te genereren. Met behulp van deze API kunnen we ook algoritmen implementeren voor het authenticeren van gebruikers, het ondertekenen van documenten, en het veilig beschermen van de vertrouwelijkheid en integriteit van communicatie. Bijgevolg maakt deze API meer veilige en gegevensbeschermingsconforme use-cases mogelijk op het gebied van end-to-end encryptie. Op deze manier levert de Web Cryptography API zijn bijdrage aan end-to-end encryptie.
klantcliënt 2019 2020 Verandering
@@ -880,7 +880,7 @@ Bovenstaande figuur toont het gebruik van botbescherming en ook het marktaandeel ## Verband tussen het aannemen van beveiligingskoppen en verschillende factoren -In de vorige secties hebben we de acceptatiegraad onderzocht van verschillende browserbeveiligingsmechanismen die moeten worden ingeschakeld door webpagina's via responsheaders. Vervolgens onderzoeken we wat websites ertoe aanzet om de beveiligingsfuncties over te nemen, of het nu verband houdt met beleid en regelgeving op landniveau, een algemeen belang om hun klanten te beschermen, of dat het wordt aangedreven door de technologiestack die wordt gebruikt om de website te bouwen . +In de vorige secties hebben we de acceptatiegraad onderzocht van verschillende browserbeveiligingsmechanismen die moeten worden ingeschakeld door webpagina's via responsheaders. Vervolgens onderzoeken we wat websites ertoe aanzet om de beveiligingsfuncties over te nemen, of het nu verband houdt met beleid en regelgeving op landniveau, een algemeen belang om hun cliënten te beschermen, of dat het wordt aangedreven door de technologiestack die wordt gebruikt om de website te bouwen . ### Land van de bezoekers van een website @@ -910,9 +910,9 @@ Als we kijken naar het percentage homepagina's dat via HTTPS is bezocht, kunnen Stimulansen op landniveau kunnen de acceptatie van beveiligingsmechanismen tot op zekere hoogte stimuleren, maar misschien nog wel belangrijker is de technologiestack die websiteontwikkelaars gebruiken bij het bouwen van websites. Lenen de frameworks zich gemakkelijk om een bepaalde functie mogelijk te maken, of is dit een moeizaam proces dat een volledige herziening van de applicatie vereist? Het zou nog beter zijn als ontwikkelaars beginnen met een reeds beveiligde omgeving met sterke standaardinstellingen. In deze sectie onderzoeken we verschillende programmeertalen, SaaS, CMS, e-commerce en CDN-technologieën die een aanzienlijk hogere acceptatiegraad hebben voor specifieke functies (en dus kunnen worden gezien als drijvende factoren voor brede acceptatie). Om het kort te houden, concentreren we ons op de meest gebruikte technologieën, maar het is belangrijk op te merken dat er veel kleinere technologieproducten bestaan die bedoeld zijn om hun gebruikers een betere beveiliging te bieden. -Voor beveiligingsfuncties die verband houden met de transportbeveiliging, zien we dat er 12 technologieproducten zijn (voornamelijk e-commerceplatforms en CMS'en) die de `Strict-Transport-Security`-header inschakelen op ten minste 90% van hun klantensites. Websites die worden aangedreven door de top 3 (volgens hun marktaandeel, namelijk Shopify, Squarespace en Automattic), maken 30,32% uit van alle homepagina's die Strict Transport Security hebben ingeschakeld. Interessant is dat de acceptatie van de `Expect-CT`-header voornamelijk wordt aangedreven door een enkele technologie, namelijk Cloudflare, die de header mogelijk maakt voor al hun klanten die HTTPS hebben ingeschakeld. Als resultaat kan 99,06% van de `Expect-CT`-headeraanwezigheid gerelateerd zijn aan Cloudflare. +Voor beveiligingsfuncties die verband houden met de transportbeveiliging, zien we dat er 12 technologieproducten zijn (voornamelijk e-commerceplatforms en CMS'en) die de `Strict-Transport-Security`-header inschakelen op ten minste 90% van hun cliëntensites. Websites die worden aangedreven door de top 3 (volgens hun marktaandeel, namelijk Shopify, Squarespace en Automattic), maken 30,32% uit van alle homepagina's die Strict Transport Security hebben ingeschakeld. Interessant is dat de acceptatie van de `Expect-CT`-header voornamelijk wordt aangedreven door een enkele technologie, namelijk Cloudflare, die de header mogelijk maakt voor al hun cliënten die HTTPS hebben ingeschakeld. Als resultaat kan 99,06% van de `Expect-CT`-headeraanwezigheid gerelateerd zijn aan Cloudflare. -Met betrekking tot beveiligingsheaders die de opname van inhoud beveiligen of die bedoeld zijn om aanvallen te dwarsbomen, zien we een soortgelijk fenomeen waarbij een paar partijen een veiligheidheader voor al hun klanten inschakelen en zo de acceptatie ervan stimuleren. Zes technologieproducten maken bijvoorbeeld de `Content-Security-Policy`-header voor meer dan 80% van hun klanten mogelijk. Als zodanig vertegenwoordigt de top 3 (Shopify, Sucuri en Tumblr) 52,53% van de homepagina's met de koptekst. Evenzo zien we voor `X-Frame-Options` dat de top 3 (Shopify, Drupal en Magento) 34,96% bijdraagt aan de wereldwijde prevalentie van de XFO-header. Dit is vooral interessant voor Drupal, aangezien het een open-source CMS is dat vaak door website-eigenaren zelf wordt opgezet. Het is duidelijk dat hun beslissing om standaard `X-Frame-Options: SAMEORIGIN` in te schakelen veel van hun gebruikers beschermt tegen clickjacking-aanvallen: 81,81% van websites aangedreven door Drupal hebben het XFO-mechanisme ingeschakeld. +Met betrekking tot beveiligingsheaders die de opname van inhoud beveiligen of die bedoeld zijn om aanvallen te dwarsbomen, zien we een soortgelijk fenomeen waarbij een paar partijen een veiligheidheader voor al hun cliënten inschakelen en zo de acceptatie ervan stimuleren. Zes technologieproducten maken bijvoorbeeld de `Content-Security-Policy`-header voor meer dan 80% van hun cliënten mogelijk. Als zodanig vertegenwoordigt de top 3 (Shopify, Sucuri en Tumblr) 52,53% van de homepagina's met de koptekst. Evenzo zien we voor `X-Frame-Options` dat de top 3 (Shopify, Drupal en Magento) 34,96% bijdraagt aan de wereldwijde prevalentie van de XFO-header. Dit is vooral interessant voor Drupal, aangezien het een open-source CMS is dat vaak door website-eigenaren zelf wordt opgezet. Het is duidelijk dat hun beslissing om standaard `X-Frame-Options: SAMEORIGIN` in te schakelen veel van hun gebruikers beschermt tegen clickjacking-aanvallen: 81,81% van websites aangedreven door Drupal hebben het XFO-mechanisme ingeschakeld. ### Gelijktijdig voorkomen van andere beveiligingsheaders @@ -927,7 +927,7 @@ Met betrekking tot beveiligingsheaders die de opname van inhoud beveiligen of di Het beveiligings "spel" is zeer onevenwichtig, en veel meer in het voordeel van aanvallers: een tegenstander hoeft slechts één fout te vinden om misbruik van te maken, terwijl de verdediger alle mogelijke kwetsbaarheden moet voorkomen. Hoewel het toepassen van een enkel beveiligingsmechanisme erg handig kan zijn bij de verdediging tegen een bepaalde aanval, hebben websites meerdere beveiligingsfuncties nodig om zich tegen alle mogelijke aanvallen te verdedigen. Om te bepalen of beveiligingsheaders op een eenmalige manier worden toegepast, of liever op een rigoureuze manier om diepgaande verdediging tegen zoveel mogelijk aanvallen te bieden, kijken we naar het naast elkaar voorkomen van beveiligingsheaders. Om precies te zijn, we bekijken hoe de acceptatie van de ene beveiligingsheader de acceptatie van andere headers beïnvloedt. Interessant is dat dit aantoont dat websites die een enkele beveiligingsheader gebruiken, veel vaker ook andere beveiligingsheader zullen gebruiken. Bijvoorbeeld, voor mobiele homepagina's die een CSP-header bevatten, de acceptatie van de andere headers (`Expect-CT`, `Referrer-Policy`, `Strict-Transport-Security`, `X-Content-Type-Options` en ` X-Frame-Options`) is gemiddeld 368% hoger in vergelijking met de algemene acceptatie van deze headers. -Over het algemeen hebben websites die een bepaalde beveiligingsheader gebruiken 2 tot 3 keer meer kans om ook andere beveiligingsheader te gebruiken. Dit is vooral het geval voor CSP, dat de acceptatie van andere beveiligingsheaders het meest bevordert. Dit is enerzijds te verklaren doordat CSP een van de uitgebreidere beveiligingsheaders is die veel inspanning vergt om te adopteren, waardoor websites die wel een beleid definiëren, eerder geïnvesteerd worden in de beveiliging van hun website. Aan de andere kant staat 44,31% van de CSP-headers op homepagina's die worden aangedreven door Shopify. Dit SaaS-product maakt ook een aantal andere beveiligingsheaders (`Strict-Transport-Security`, `X-Content-Type-Options` en `X-Frame-Options`) standaard mogelijk voor vrijwel al hun klanten. +Over het algemeen hebben websites die een bepaalde beveiligingsheader gebruiken 2 tot 3 keer meer kans om ook andere beveiligingsheader te gebruiken. Dit is vooral het geval voor CSP, dat de acceptatie van andere beveiligingsheaders het meest bevordert. Dit is enerzijds te verklaren doordat CSP een van de uitgebreidere beveiligingsheaders is die veel inspanning vergt om te adopteren, waardoor websites die wel een beleid definiëren, eerder geïnvesteerd worden in de beveiliging van hun website. Aan de andere kant staat 44,31% van de CSP-headers op homepagina's die worden aangedreven door Shopify. Dit SaaS-product maakt ook een aantal andere beveiligingsheaders (`Strict-Transport-Security`, `X-Content-Type-Options` en `X-Frame-Options`) standaard mogelijk voor vrijwel al hun cliënten. ## Software-updatepraktijken diff --git a/src/content/nl/2020/third-parties.md b/src/content/nl/2020/third-parties.md index e7eb1e3c121..01125f48958 100644 --- a/src/content/nl/2020/third-parties.md +++ b/src/content/nl/2020/third-parties.md @@ -55,7 +55,7 @@ In dit hoofdstuk worden providers van derden in verschillende categorieën onder * Analytics - het volgen van het gedrag van sitebezoekers * CDN - providers die openbare gedeelde hulpprogramma's of privé-inhoud van hun gebruikers hosten * Inhoud - providers die uitgevers faciliteren en gesyndiceerde inhoud hosten -* Klantsucces - ondersteuning en functionaliteit voor klantrelatiebeheer +* Cliëntsucces - ondersteuning en functionaliteit voor cliëntrelatiebeheer * Hosting - providers die de willekeurige inhoud van hun gebruikers hosten * Marketing - verkoop, leadgeneratie en e-mailmarketingfunctionaliteit * Sociaal - sociale netwerken en hun aangesloten integraties @@ -243,7 +243,7 @@ De onderstaande grafiek toont het percentage verzoeken dat vroeg wordt geladen, ## CPU-impact -Niet alle bytes op het web zijn gelijk: een afbeelding van 500KB is misschien veel gemakkelijker voor een browser om te verwerken dan een gecomprimeerde JavaScript-bundel van 500KB, die oploopt tot 1,8MB aan client-side code! De impact van scripts van derden op de CPU-tijd kan veel kritischer zijn dan de extra bytes of tijd die op het netwerk wordt doorgebracht. +Niet alle bytes op het web zijn gelijk: een afbeelding van 500KB is misschien veel gemakkelijker voor een browser om te verwerken dan een gecomprimeerde JavaScript-bundel van 500KB, die oploopt tot 1,8MB aan cliëntzijde code! De impact van scripts van derden op de CPU-tijd kan veel kritischer zijn dan de extra bytes of tijd die op het netwerk wordt doorgebracht. We kunnen de aanwezigheid van categorieën van derden correleren met de totale CPU-tijd op de pagina, dit stelt ons in staat om de impact van elke categorie van derden op de CPU-tijd te schatten. From 0515020a1009185c3bcc05c714b14030a5b22444 Mon Sep 17 00:00:00 2001 From: Noah Date: Thu, 1 Apr 2021 12:33:00 +0200 Subject: [PATCH 04/11] fix: change "bureaublad" to "desktop" --- src/content/nl/2020/accessibility.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/nl/2020/accessibility.md b/src/content/nl/2020/accessibility.md index dcd9a889057..bf2f331ec90 100644 --- a/src/content/nl/2020/accessibility.md +++ b/src/content/nl/2020/accessibility.md @@ -144,7 +144,7 @@ De top 5 bestandsextensies die expliciet zijn opgenomen in de `alt`-tekstwaarde - + @@ -284,7 +284,7 @@ Tabellen zijn een efficiënte manier om gegevens weer te geven met twee assen va - + From f2f64ce46f4518a89dd590659f517305b8a87b1c Mon Sep 17 00:00:00 2001 From: Noah Date: Thu, 1 Apr 2021 16:04:34 +0200 Subject: [PATCH 05/11] fix: "home" to "start" pagina --- src/content/nl/2020/accessibility.md | 6 +++--- src/content/nl/2020/capabilities.md | 2 +- src/content/nl/2020/markup.md | 4 ++-- src/content/nl/2020/mobile-web.md | 4 ++-- src/content/nl/2020/pwa.md | 2 +- src/content/nl/2020/security.md | 24 ++++++++++++------------ src/content/nl/2020/third-parties.md | 2 +- src/templates/nl/2019/methodology.html | 4 ++-- src/templates/nl/2020/methodology.html | 2 +- 9 files changed, 25 insertions(+), 25 deletions(-) diff --git a/src/content/nl/2020/accessibility.md b/src/content/nl/2020/accessibility.md index bf2f331ec90..24ea4652499 100644 --- a/src/content/nl/2020/accessibility.md +++ b/src/content/nl/2020/accessibility.md @@ -322,7 +322,7 @@ Als er een absolute behoefte is om naar deze techniek te reiken, moet de rol van ### Documenttitels -Beschrijvende paginatitels zijn handig voor de context wanneer u met ondersteunende technologie tussen pagina's, tabbladen en vensters wisselt, omdat de wijziging in de context zal worden aangekondigd. Uit onze gegevens blijkt dat 98,98% van de sites een titel heeft, wat een hoopvolle statistiek is. Het spreekt echter vanzelf dat homepagina's een hoger aantal paginatitels kunnen hebben dan minder belangrijke routes. +Beschrijvende paginatitels zijn handig voor de context wanneer u met ondersteunende technologie tussen pagina's, tabbladen en vensters wisselt, omdat de wijziging in de context zal worden aangekondigd. Uit onze gegevens blijkt dat 98,98% van de sites een titel heeft, wat een hoopvolle statistiek is. Het spreekt echter vanzelf dat startpagina's een hoger aantal paginatitels kunnen hebben dan minder belangrijke routes. ### Tabindex @@ -379,7 +379,7 @@ HTML5 introduceerde veel nieuwe native elementen, die allemaal `s en ``s deze rol hebben gekregen, is de kans groot dat een of meer van de 5 regels van ARIA zijn overtreden. @@ -473,7 +473,7 @@ De toegankelijke naam kan worden afgeleid van de inhoud van een element (zoals k We kunnen ARIA ook gebruiken om toegankelijke namen voor elementen op te geven. Er zijn twee ARIA-attributen die dit bewerkstelligen, `aria-label`, `aria-labelledby`. Elk van deze kenmerken zal de berekening van de toegankelijke naam "winnen" en de native afgeleide toegankelijke naam overschrijven, dus gebruik ze met de nodige voorzichtigheid en zorg ervoor dat u test met een schermlezer of bekijk de toegankelijkheidsboom om te bevestigen dat de toegankelijke naam is wat werd verwacht. Wanneer u ARIA gebruikt om een element een naam te geven, is het belangrijk om ervoor te zorgen dat de WCAG 2.5.3, Label in Name criterium niet geschonden is, dat verwacht dat zichtbare labels ten minste een deel van de toegankelijke naam zijn. -Met het `aria-label`-element kan een ontwikkelaar een tekenreekswaarde opgeven en deze wordt gebruikt voor de toegankelijke naam voor het element. We ontdekten dat 40,44% van de desktoppagina's en 38,72% van de mobiele homepagina's ten minste één element had met het kenmerk `aria-label`, waardoor dit het meest populaire ARIA-kenmerk is voor het verstrekken van toegankelijke namen. +Met het `aria-label`-element kan een ontwikkelaar een tekenreekswaarde opgeven en deze wordt gebruikt voor de toegankelijke naam voor het element. We ontdekten dat 40,44% van de desktoppagina's en 38,72% van de mobiele startpagina's ten minste één element had met het kenmerk `aria-label`, waardoor dit het meest populaire ARIA-kenmerk is voor het verstrekken van toegankelijke namen. Het `aria-labelledby` attribuut accepteert een `id` referentie als zijn waarde, die het associeert met een ander element in de interface om zijn toegankelijke naam te geven. Het element wordt "gelabeld door" dit andere element dat zijn toegankelijke naam geeft. We ontdekten dat 17,73% van de desktoppagina's en 16,21% van de mobiele pagina's ten minste één element had met het kenmerk `aria-labelledby`. diff --git a/src/content/nl/2020/capabilities.md b/src/content/nl/2020/capabilities.md index 795d3c7948b..1389486f3ac 100644 --- a/src/content/nl/2020/capabilities.md +++ b/src/content/nl/2020/capabilities.md @@ -255,7 +255,7 @@ In de loop van 2020 vertoont de `getInstalledRelatedApps()` API een gestage groe Webapps kunnen inhoud offline opslaan op verschillende manieren, zoals Cache Storage of IndexedDB. Voor gebruikers is het echter moeilijk om te ontdekken welke inhoud offline beschikbaar is. Met de Content Indexing API (WICG Editor's Draft) kunnen ontwikkelaars inhoud prominenter weergeven. Momenteel is Chrome op Android de enige browser die deze API ondersteunt. Deze browser toont een lijst met "Artikelen voor jou" in het menu Downloads. Inhoud die is geïndexeerd via de Content Indexing API, wordt daar weergegeven. -De Content Indexing API breidt de Service Worker API uit met een nieuwe `ContentIndex` interface. Deze interface is beschikbaar via de eigenschap `index` van de registratie van de Service Worker. Met de `add()` methode kunnen ontwikkelaars inhoud aan de index toevoegen: elk stukje inhoud moet een ID, een URL, een start-URL, titel, beschrijving en een reeks pictogrammen hebben. Optioneel kan de inhoud worden gegroepeerd in verschillende categorieën, zoals artikelen, homepagina's of video's. De `delete()` methode maakt het mogelijk om weer inhoud uit de index te verwijderen, en de `getAll()` methode geeft een lijst met alle geïndexeerde items terug. +De Content Indexing API breidt de Service Worker API uit met een nieuwe `ContentIndex` interface. Deze interface is beschikbaar via de eigenschap `index` van de registratie van de Service Worker. Met de `add()` methode kunnen ontwikkelaars inhoud aan de index toevoegen: elk stukje inhoud moet een ID, een URL, een start-URL, titel, beschrijving en een reeks pictogrammen hebben. Optioneel kan de inhoud worden gegroepeerd in verschillende categorieën, zoals artikelen, startpagina's of video's. De `delete()` methode maakt het mogelijk om weer inhoud uit de index te verwijderen, en de `getAll()` methode geeft een lijst met alle geïndexeerde items terug. {{ figure_markup( image="content_indexing_api.png", diff --git a/src/content/nl/2020/markup.md b/src/content/nl/2020/markup.md index 9c065326baa..b09fa1e4419 100644 --- a/src/content/nl/2020/markup.md +++ b/src/content/nl/2020/markup.md @@ -143,7 +143,7 @@ Opmerkingen toevoegen aan code is over het algemeen een goede gewoonte en HTML-o ``` -Hoewel veel pagina's voor productie zijn ontdaan van opmerkingen, ontdekten we dat homepagina's in het 90e percentiel ongeveer 73 reacties op mobiele apparaten gebruiken, respectievelijk 79 reacties op desktops, terwijl in het 10e percentiel het aantal reacties ongeveer 2 is. Mediaanpagina gebruikt 16 (mobiel) of 17 reacties (desktop). +Hoewel veel pagina's voor productie zijn ontdaan van opmerkingen, ontdekten we dat startpagina's in het 90e percentiel ongeveer 73 reacties op mobiele apparaten gebruiken, respectievelijk 79 reacties op desktops, terwijl in het 10e percentiel het aantal reacties ongeveer 2 is. Mediaanpagina gebruikt 16 (mobiel) of 17 reacties (desktop). Ongeveer 89% van de pagina's bevat minstens één HTML-opmerking, terwijl ongeveer 46% een voorwaardelijke opmerking bevat. @@ -611,7 +611,7 @@ In onze mobiele dataset van 6,3 miljoen pagina's bevatten ongeveer 0,9 miljoen p
{{ figure_link(caption="Verouderde elementen met meer dan 10.000 toepassingen.", sheets_gid="1972617631", sql_file="pages_element_count_by_device_and_obsolete_elements.sql") }}
-Zelfs `spacer` wordt nog 1.584 keer gebruikt en staat op elke 5.000ste pagina. We weten dat Google al 22 jaar een `center`-element op hun homepagina gebruikt, maar waarom zijn er zoveel navolgers? +Zelfs `spacer` wordt nog 1.584 keer gebruikt en staat op elke 5.000ste pagina. We weten dat Google al 22 jaar een `center`-element op hun startpagina gebruikt, maar waarom zijn er zoveel navolgers? #### `isindex` diff --git a/src/content/nl/2020/mobile-web.md b/src/content/nl/2020/mobile-web.md index 135a931a2ee..523d6cd2c36 100644 --- a/src/content/nl/2020/mobile-web.md +++ b/src/content/nl/2020/mobile-web.md @@ -36,7 +36,7 @@ Bezoek de bovenstaande links voor meer informatie over de methodologie en kantte Naast het bovenstaande hebben we ook een niet-openbare Chrome-gegevensbron gebruikt in het gedeelte over het laden van pagina's in Chrome. Lees voor meer informatie over de gegevensverzamelings-API van Chrome. -Hoewel deze gegevens alleen worden verzameld van een subset van (aangemelde) Chrome-gebruikers, hebben ze geen last van het feit dat ze beperkt zijn tot homepagina's. Het is pseudoniem en bestaat uit histogrammen en gebeurtenissen. +Hoewel deze gegevens alleen worden verzameld van een subset van (aangemelde) Chrome-gebruikers, hebben ze geen last van het feit dat ze beperkt zijn tot startpagina's. Het is pseudoniem en bestaat uit histogrammen en gebeurtenissen.

OPMERKING: Rapportage is ingeschakeld als de gebruiker een functie heeft ingeschakeld die browservensters synchroniseert, tenzij ze de instelling "Zoeken en browsen beter maken/URL's van pagina's die u bezoekt naar Google sturen" hebben uitgeschakeld.

@@ -254,7 +254,7 @@ Eenvoudige ontwerpaanpassingen gaan een lange weg, bijvoorbeeld een duidelijke c ) }} -Onderzoek heeft aangetoond dat carrousels met auto-forwarding schadelijk zijn voor de gebruikerservaring. Auto-forwarding carrousels op de homepagina moeten worden vermeden of hun frequentie moet worden verlaagd. +Onderzoek heeft aangetoond dat carrousels met auto-forwarding schadelijk zijn voor de gebruikerservaring. Auto-forwarding carrousels op de startpagina moeten worden vermeden of hun frequentie moet worden verlaagd. ##### Kleur en contrast diff --git a/src/content/nl/2020/pwa.md b/src/content/nl/2020/pwa.md index 61d6be0a97a..02e909c9c63 100644 --- a/src/content/nl/2020/pwa.md +++ b/src/content/nl/2020/pwa.md @@ -166,7 +166,7 @@ Een opstartscherm met De adresbalk van de browser kan een thema hebben dat bij uw site past. 4,00% van de pagina's had een omnibox thema. -Uw app zou wat inhoud moeten weergeven wanneer JavaScript is uitgeschakeld, ook al is het slechts een waarschuwing voor de gebruiker dat JavaScript vereist is om de app te gebruiken. 97,57% van de pagina's toont meer dan alleen een lege pagina met JavaScript uitgeschakeld. Aangezien we alleen de homepagina's onderzoeken, is het misschien meer verrassend dat 3,43% van de sites deze audit niet haalt! +Uw app zou wat inhoud moeten weergeven wanneer JavaScript is uitgeschakeld, ook al is het slechts een waarschuwing voor de gebruiker dat JavaScript vereist is om de app te gebruiken. 97,57% van de pagina's toont meer dan alleen een lege pagina met JavaScript uitgeschakeld. Aangezien we alleen de startpagina's onderzoeken, is het misschien meer verrassend dat 3,43% van de sites deze audit niet haalt! ## Gebeurtenissen voor service workers diff --git a/src/content/nl/2020/security.md b/src/content/nl/2020/security.md index 792330b97c8..6b063c4942c 100644 --- a/src/content/nl/2020/security.md +++ b/src/content/nl/2020/security.md @@ -33,7 +33,7 @@ We kijken niet alleen naar de acceptatie van beveiligingsmechanismen op individu ### Methodologie -In dit hoofdstuk rapporteren we over de invoering van verschillende beveiligingsmechanismen op internet. Deze analyse is gebaseerd op gegevens die zijn verzameld voor de homepagina van 5,6 miljoen desktopdomeinen en 6,3 miljoen mobiele domeinen. Tenzij expliciet anders vermeld, zijn de gerapporteerde cijfers gebaseerd op de mobiele dataset, aangezien deze groter is. Omdat de meeste websites in beide datasets zijn opgenomen, zijn de resulterende metingen grotendeels vergelijkbaar. Elk significant verschil tussen de twee datasets wordt in de hele tekst vermeld of blijkt uit de figuren. Raadpleeg de [Methodologie](./methodology) voor meer informatie over hoe de gegevens zijn verzameld. +In dit hoofdstuk rapporteren we over de invoering van verschillende beveiligingsmechanismen op internet. Deze analyse is gebaseerd op gegevens die zijn verzameld voor de startpagina van 5,6 miljoen desktopdomeinen en 6,3 miljoen mobiele domeinen. Tenzij expliciet anders vermeld, zijn de gerapporteerde cijfers gebaseerd op de mobiele dataset, aangezien deze groter is. Omdat de meeste websites in beide datasets zijn opgenomen, zijn de resulterende metingen grotendeels vergelijkbaar. Elk significant verschil tussen de twee datasets wordt in de hele tekst vermeld of blijkt uit de figuren. Raadpleeg de [Methodologie](./methodology) voor meer informatie over hoe de gegevens zijn verzameld. ## Transportbeveiliging @@ -209,7 +209,7 @@ Om deze problemen op te lossen, hebben browsers aanvullende functies geleverd di #### HTTP Strikte Transportbeveiliging (HTTP Strict Transport Security) -De eerste is HTTP Strict Transport Security (HSTS), die eenvoudig kan worden ingeschakeld door een antwoord header in te stellen die uit verschillende attributen bestaat. Voor deze header vinden we een acceptatiegraad van 16,88% binnen de mobiele homepagina's. Van de sites die HSTS inschakelen, doet 92,82% dit met succes. Dat wil zeggen, het kenmerk max-age (dat bepaalt hoeveel seconden de browser *alleen* de website via HTTPS mag bezoeken) heeft een waarde groter dan 0. +De eerste is HTTP Strict Transport Security (HSTS), die eenvoudig kan worden ingeschakeld door een antwoord header in te stellen die uit verschillende attributen bestaat. Voor deze header vinden we een acceptatiegraad van 16,88% binnen de mobiele startpagina's. Van de sites die HSTS inschakelen, doet 92,82% dit met succes. Dat wil zeggen, het kenmerk max-age (dat bepaalt hoeveel seconden de browser *alleen* de website via HTTPS mag bezoeken) heeft een waarde groter dan 0. {{ figure_markup( image="security-hsts-max-age-values-in-days.png", @@ -287,7 +287,7 @@ Het meest recent geïntroduceerde attribuut, `SameSite`, kan worden gebruikt om Onze resultaten, die zijn gebaseerd op 25 miljoen eerste-site cookies en 115 miljoen derden cookies, laten zien dat het gebruik van de cookie-attributen sterk afhankelijk is van de context waarin ze zijn ingesteld. We kunnen een soortgelijk gebruik van het attribuut `HttpOnly` zien bij cookies voor zowel eerste partij (30,5%) als derden (26,3%) cookies. -Voor de `Secure`- en `SameSite`-attributen zien we echter een significant verschil: het `Secure`-attribuut is aanwezig in 22,2% van alle cookies die zijn ingesteld in een eerste partij context, terwijl 68,0% van alle cookies die door derden zijn ingesteld verzoeken op mobiele homepagina's hebben dit cookie-attribuut. Interessant is dat voor desktoppagina's slechts 35,2% van de cookies van derden het kenmerk had. +Voor de `Secure`- en `SameSite`-attributen zien we echter een significant verschil: het `Secure`-attribuut is aanwezig in 22,2% van alle cookies die zijn ingesteld in een eerste partij context, terwijl 68,0% van alle cookies die door derden zijn ingesteld verzoeken op mobiele startpagina's hebben dit cookie-attribuut. Interessant is dat voor desktoppagina's slechts 35,2% van de cookies van derden het kenmerk had. Voor het `SameSite`-attribuut zien we een aanzienlijke toename in hun gebruik, vergeleken met [vorig jaar](../2019/security#samesite), toen slechts 0,1% van de cookies dit attribuut had. Vanaf augustus 2020 hebben we vastgesteld dat 13,7% van de eerste partij cookies en 53,2% van de cookies van derden het `SameSite`-attribuut hebben ingesteld. @@ -777,7 +777,7 @@ Een ander mechanisme om de adoptie van CSP gemakkelijker te maken, is het gebrui De twee andere trefwoorden, `unsafe-inline` en `unsafe-eval`, zijn aanwezig in de meeste CSP's: respectievelijk 97,28% en 77,79%. Dit kan worden gezien als een herinnering aan de moeilijkheid om een beleid te implementeren dat XSS-aanvallen kan dwarsbomen. Als het trefwoord `strict-dynamic` echter aanwezig is, worden de trefwoorden `unsafe-inline` en `unsafe-eval` effectief genegeerd. Omdat het trefwoord `strict-dynamic` mogelijk niet wordt ondersteund door oudere browsers, wordt het als een best practice beschouwd om de twee andere onveilige trefwoorden op te nemen om de compatibiliteit voor alle browserversies te behouden. -Terwijl de trefwoorden `strict-dynamic` en `nonce-` kunnen worden gebruikt ter verdediging tegen gereflecteerde en aanhoudende XSS-aanvallen, kan een beschermde pagina nog steeds kwetsbaar zijn voor op DOM gebaseerde XSS-kwetsbaarheden. Om zich te verdedigen tegen deze klasse van aanvallen, kunnen website-ontwikkelaars gebruik maken van Trusted Types, een vrij nieuw mechanisme dat momenteel alleen wordt ondersteund door op Chromium gebaseerde browsers. Ondanks de mogelijke problemen bij het adopteren van vertrouwde typen (websites zouden een beleid moeten opstellen en mogelijk hun JavaScript-code moeten aanpassen om aan dit beleid te voldoen), en gezien het feit dat het een nieuw mechanisme is, is het bemoedigend dat 11 homepagina's al vertrouwde typen hebben aangenomen via de richtlijn `require-trusted-types-for` in CSP. +Terwijl de trefwoorden `strict-dynamic` en `nonce-` kunnen worden gebruikt ter verdediging tegen gereflecteerde en aanhoudende XSS-aanvallen, kan een beschermde pagina nog steeds kwetsbaar zijn voor op DOM gebaseerde XSS-kwetsbaarheden. Om zich te verdedigen tegen deze klasse van aanvallen, kunnen website-ontwikkelaars gebruik maken van Trusted Types, een vrij nieuw mechanisme dat momenteel alleen wordt ondersteund door op Chromium gebaseerde browsers. Ondanks de mogelijke problemen bij het adopteren van vertrouwde typen (websites zouden een beleid moeten opstellen en mogelijk hun JavaScript-code moeten aanpassen om aan dit beleid te voldoen), en gezien het feit dat het een nieuw mechanisme is, is het bemoedigend dat 11 startpagina's al vertrouwde typen hebben aangenomen via de richtlijn `require-trusted-types-for` in CSP. ### Bescherming tegen XS-Leaks met Cross-Origin-Policies @@ -884,7 +884,7 @@ In de vorige secties hebben we de acceptatiegraad onderzocht van verschillende b ### Land van de bezoekers van een website -Er kunnen veel verschillende factoren zijn die van invloed zijn op de beveiliging op het niveau van een land: door de overheid gemotiveerde cyberbeveiligingsprogramma's kunnen het bewustzijn van goede beveiligingspraktijken vergroten, een focus op beveiliging in het hoger onderwijs kan leiden tot beter geïnformeerde ontwikkelaars of zelfs bepaalde regelgeving kunnen bedrijven en organisaties ertoe verplichten zich te houden aan de beste beveiligingspraktijken. Om de verschillen per land te evalueren, analyseren we de verschillende landen waarvoor er minimaal 100.000 homepagina's beschikbaar waren in onze dataset, die is gebaseerd op het Chrome User Experience Report (CrUX). Deze pagina's bestaan uit de pagina's die het meest werden bezocht door de gebruikers in dat land; als zodanig bevatten deze ook zeer populaire internationale websites. +Er kunnen veel verschillende factoren zijn die van invloed zijn op de beveiliging op het niveau van een land: door de overheid gemotiveerde cyberbeveiligingsprogramma's kunnen het bewustzijn van goede beveiligingspraktijken vergroten, een focus op beveiliging in het hoger onderwijs kan leiden tot beter geïnformeerde ontwikkelaars of zelfs bepaalde regelgeving kunnen bedrijven en organisaties ertoe verplichten zich te houden aan de beste beveiligingspraktijken. Om de verschillen per land te evalueren, analyseren we de verschillende landen waarvoor er minimaal 100.000 startpagina's beschikbaar waren in onze dataset, die is gebaseerd op het Chrome User Experience Report (CrUX). Deze pagina's bestaan uit de pagina's die het meest werden bezocht door de gebruikers in dat land; als zodanig bevatten deze ook zeer populaire internationale websites. {{ figure_markup( image="security-adoption-of-https-per-country.png", @@ -895,7 +895,7 @@ Er kunnen veel verschillende factoren zijn die van invloed zijn op de beveiligin sql_file="feature_adoption_by_country.sql" ) }} -Als we kijken naar het percentage homepagina's dat via HTTPS is bezocht, kunnen we al een significant verschil zien: voor de top 5 best presterende landen werd 93-95% van de homepagina's bediend via HTTPS. Voor de onderste 5 zien we een veel kleinere acceptatie in HTTPS, variërend van 71% tot 76%. Als we naar andere beveiligingsmechanismen kijken, zien we nog duidelijkere verschillen tussen de best presterende landen en landen met een lage acceptatiegraad. De top 5 landen op basis van de acceptatiegraad voor CSP scoren tussen 14% en 16%, terwijl de onderste 5 scoren tussen 2,5% en 5%. Interessant is dat de landen die goed/slecht presteren voor het ene beveiligingsmechanisme, dat ook doen voor andere mechanismen. Nieuw-Zeeland, Ierland en Australië behoren bijvoorbeeld consequent tot de top 5, terwijl Japan het slechtst scoort voor bijna elk beveiligingsmechanisme. +Als we kijken naar het percentage startpagina's dat via HTTPS is bezocht, kunnen we al een significant verschil zien: voor de top 5 best presterende landen werd 93-95% van de startpagina's bediend via HTTPS. Voor de onderste 5 zien we een veel kleinere acceptatie in HTTPS, variërend van 71% tot 76%. Als we naar andere beveiligingsmechanismen kijken, zien we nog duidelijkere verschillen tussen de best presterende landen en landen met een lage acceptatiegraad. De top 5 landen op basis van de acceptatiegraad voor CSP scoren tussen 14% en 16%, terwijl de onderste 5 scoren tussen 2,5% en 5%. Interessant is dat de landen die goed/slecht presteren voor het ene beveiligingsmechanisme, dat ook doen voor andere mechanismen. Nieuw-Zeeland, Ierland en Australië behoren bijvoorbeeld consequent tot de top 5, terwijl Japan het slechtst scoort voor bijna elk beveiligingsmechanisme. {{ figure_markup( image="security-adoption-of-csp-and-xfo-per-country.png", @@ -910,9 +910,9 @@ Als we kijken naar het percentage homepagina's dat via HTTPS is bezocht, kunnen Stimulansen op landniveau kunnen de acceptatie van beveiligingsmechanismen tot op zekere hoogte stimuleren, maar misschien nog wel belangrijker is de technologiestack die websiteontwikkelaars gebruiken bij het bouwen van websites. Lenen de frameworks zich gemakkelijk om een bepaalde functie mogelijk te maken, of is dit een moeizaam proces dat een volledige herziening van de applicatie vereist? Het zou nog beter zijn als ontwikkelaars beginnen met een reeds beveiligde omgeving met sterke standaardinstellingen. In deze sectie onderzoeken we verschillende programmeertalen, SaaS, CMS, e-commerce en CDN-technologieën die een aanzienlijk hogere acceptatiegraad hebben voor specifieke functies (en dus kunnen worden gezien als drijvende factoren voor brede acceptatie). Om het kort te houden, concentreren we ons op de meest gebruikte technologieën, maar het is belangrijk op te merken dat er veel kleinere technologieproducten bestaan die bedoeld zijn om hun gebruikers een betere beveiliging te bieden. -Voor beveiligingsfuncties die verband houden met de transportbeveiliging, zien we dat er 12 technologieproducten zijn (voornamelijk e-commerceplatforms en CMS'en) die de `Strict-Transport-Security`-header inschakelen op ten minste 90% van hun cliëntensites. Websites die worden aangedreven door de top 3 (volgens hun marktaandeel, namelijk Shopify, Squarespace en Automattic), maken 30,32% uit van alle homepagina's die Strict Transport Security hebben ingeschakeld. Interessant is dat de acceptatie van de `Expect-CT`-header voornamelijk wordt aangedreven door een enkele technologie, namelijk Cloudflare, die de header mogelijk maakt voor al hun cliënten die HTTPS hebben ingeschakeld. Als resultaat kan 99,06% van de `Expect-CT`-headeraanwezigheid gerelateerd zijn aan Cloudflare. +Voor beveiligingsfuncties die verband houden met de transportbeveiliging, zien we dat er 12 technologieproducten zijn (voornamelijk e-commerceplatforms en CMS'en) die de `Strict-Transport-Security`-header inschakelen op ten minste 90% van hun cliëntensites. Websites die worden aangedreven door de top 3 (volgens hun marktaandeel, namelijk Shopify, Squarespace en Automattic), maken 30,32% uit van alle startpagina's die Strict Transport Security hebben ingeschakeld. Interessant is dat de acceptatie van de `Expect-CT`-header voornamelijk wordt aangedreven door een enkele technologie, namelijk Cloudflare, die de header mogelijk maakt voor al hun cliënten die HTTPS hebben ingeschakeld. Als resultaat kan 99,06% van de `Expect-CT`-headeraanwezigheid gerelateerd zijn aan Cloudflare. -Met betrekking tot beveiligingsheaders die de opname van inhoud beveiligen of die bedoeld zijn om aanvallen te dwarsbomen, zien we een soortgelijk fenomeen waarbij een paar partijen een veiligheidheader voor al hun cliënten inschakelen en zo de acceptatie ervan stimuleren. Zes technologieproducten maken bijvoorbeeld de `Content-Security-Policy`-header voor meer dan 80% van hun cliënten mogelijk. Als zodanig vertegenwoordigt de top 3 (Shopify, Sucuri en Tumblr) 52,53% van de homepagina's met de koptekst. Evenzo zien we voor `X-Frame-Options` dat de top 3 (Shopify, Drupal en Magento) 34,96% bijdraagt aan de wereldwijde prevalentie van de XFO-header. Dit is vooral interessant voor Drupal, aangezien het een open-source CMS is dat vaak door website-eigenaren zelf wordt opgezet. Het is duidelijk dat hun beslissing om standaard `X-Frame-Options: SAMEORIGIN` in te schakelen veel van hun gebruikers beschermt tegen clickjacking-aanvallen: 81,81% van websites aangedreven door Drupal hebben het XFO-mechanisme ingeschakeld. +Met betrekking tot beveiligingsheaders die de opname van inhoud beveiligen of die bedoeld zijn om aanvallen te dwarsbomen, zien we een soortgelijk fenomeen waarbij een paar partijen een veiligheidheader voor al hun cliënten inschakelen en zo de acceptatie ervan stimuleren. Zes technologieproducten maken bijvoorbeeld de `Content-Security-Policy`-header voor meer dan 80% van hun cliënten mogelijk. Als zodanig vertegenwoordigt de top 3 (Shopify, Sucuri en Tumblr) 52,53% van de startpagina's met de koptekst. Evenzo zien we voor `X-Frame-Options` dat de top 3 (Shopify, Drupal en Magento) 34,96% bijdraagt aan de wereldwijde prevalentie van de XFO-header. Dit is vooral interessant voor Drupal, aangezien het een open-source CMS is dat vaak door website-eigenaren zelf wordt opgezet. Het is duidelijk dat hun beslissing om standaard `X-Frame-Options: SAMEORIGIN` in te schakelen veel van hun gebruikers beschermt tegen clickjacking-aanvallen: 81,81% van websites aangedreven door Drupal hebben het XFO-mechanisme ingeschakeld. ### Gelijktijdig voorkomen van andere beveiligingsheaders @@ -925,9 +925,9 @@ Met betrekking tot beveiligingsheaders die de opname van inhoud beveiligen of di sql_file="feature_adoption_by_other_features.sql" ) }} -Het beveiligings "spel" is zeer onevenwichtig, en veel meer in het voordeel van aanvallers: een tegenstander hoeft slechts één fout te vinden om misbruik van te maken, terwijl de verdediger alle mogelijke kwetsbaarheden moet voorkomen. Hoewel het toepassen van een enkel beveiligingsmechanisme erg handig kan zijn bij de verdediging tegen een bepaalde aanval, hebben websites meerdere beveiligingsfuncties nodig om zich tegen alle mogelijke aanvallen te verdedigen. Om te bepalen of beveiligingsheaders op een eenmalige manier worden toegepast, of liever op een rigoureuze manier om diepgaande verdediging tegen zoveel mogelijk aanvallen te bieden, kijken we naar het naast elkaar voorkomen van beveiligingsheaders. Om precies te zijn, we bekijken hoe de acceptatie van de ene beveiligingsheader de acceptatie van andere headers beïnvloedt. Interessant is dat dit aantoont dat websites die een enkele beveiligingsheader gebruiken, veel vaker ook andere beveiligingsheader zullen gebruiken. Bijvoorbeeld, voor mobiele homepagina's die een CSP-header bevatten, de acceptatie van de andere headers (`Expect-CT`, `Referrer-Policy`, `Strict-Transport-Security`, `X-Content-Type-Options` en ` X-Frame-Options`) is gemiddeld 368% hoger in vergelijking met de algemene acceptatie van deze headers. +Het beveiligings "spel" is zeer onevenwichtig, en veel meer in het voordeel van aanvallers: een tegenstander hoeft slechts één fout te vinden om misbruik van te maken, terwijl de verdediger alle mogelijke kwetsbaarheden moet voorkomen. Hoewel het toepassen van een enkel beveiligingsmechanisme erg handig kan zijn bij de verdediging tegen een bepaalde aanval, hebben websites meerdere beveiligingsfuncties nodig om zich tegen alle mogelijke aanvallen te verdedigen. Om te bepalen of beveiligingsheaders op een eenmalige manier worden toegepast, of liever op een rigoureuze manier om diepgaande verdediging tegen zoveel mogelijk aanvallen te bieden, kijken we naar het naast elkaar voorkomen van beveiligingsheaders. Om precies te zijn, we bekijken hoe de acceptatie van de ene beveiligingsheader de acceptatie van andere headers beïnvloedt. Interessant is dat dit aantoont dat websites die een enkele beveiligingsheader gebruiken, veel vaker ook andere beveiligingsheader zullen gebruiken. Bijvoorbeeld, voor mobiele startpagina's die een CSP-header bevatten, de acceptatie van de andere headers (`Expect-CT`, `Referrer-Policy`, `Strict-Transport-Security`, `X-Content-Type-Options` en ` X-Frame-Options`) is gemiddeld 368% hoger in vergelijking met de algemene acceptatie van deze headers. -Over het algemeen hebben websites die een bepaalde beveiligingsheader gebruiken 2 tot 3 keer meer kans om ook andere beveiligingsheader te gebruiken. Dit is vooral het geval voor CSP, dat de acceptatie van andere beveiligingsheaders het meest bevordert. Dit is enerzijds te verklaren doordat CSP een van de uitgebreidere beveiligingsheaders is die veel inspanning vergt om te adopteren, waardoor websites die wel een beleid definiëren, eerder geïnvesteerd worden in de beveiliging van hun website. Aan de andere kant staat 44,31% van de CSP-headers op homepagina's die worden aangedreven door Shopify. Dit SaaS-product maakt ook een aantal andere beveiligingsheaders (`Strict-Transport-Security`, `X-Content-Type-Options` en `X-Frame-Options`) standaard mogelijk voor vrijwel al hun cliënten. +Over het algemeen hebben websites die een bepaalde beveiligingsheader gebruiken 2 tot 3 keer meer kans om ook andere beveiligingsheader te gebruiken. Dit is vooral het geval voor CSP, dat de acceptatie van andere beveiligingsheaders het meest bevordert. Dit is enerzijds te verklaren doordat CSP een van de uitgebreidere beveiligingsheaders is die veel inspanning vergt om te adopteren, waardoor websites die wel een beleid definiëren, eerder geïnvesteerd worden in de beveiliging van hun website. Aan de andere kant staat 44,31% van de CSP-headers op startpagina's die worden aangedreven door Shopify. Dit SaaS-product maakt ook een aantal andere beveiligingsheaders (`Strict-Transport-Security`, `X-Content-Type-Options` en `X-Frame-Options`) standaard mogelijk voor vrijwel al hun cliënten. ## Software-updatepraktijken @@ -946,7 +946,7 @@ Een zeer groot deel van het web is gebouwd met componenten van derden, op versch height="575" ) }} -Als een van de meest populaire [Content Management Systemen](./cms) is WordPress een aantrekkelijk doelwit voor aanvallers. Daarom is het belangrijk voor websitebeheerders om hun installatie up-to-date te houden. Standaard worden updates automatisch uitgevoerd voor WordPress, hoewel het mogelijk is om deze functie uit te schakelen. De evolutie van de geïmplementeerde WordPress-versies wordt weergegeven in de bovenstaande afbeelding, met de laatste belangrijke versies die nog steeds actief worden onderhouden (5.5: paars, 5.4: blauw, 5.3 : rood, 5,2: groen, 4,9: oranje). Versies met een prevalentie van minder dan 4% worden bij elkaar gegroepeerd onder "Overig". Een eerste interessante observatie die gemaakt kan worden, is dat vanaf augustus 2020 74,89% van de WordPress-installaties op mobiele homepagina's de nieuwste versie binnen hun branche draaien. Het is ook te zien dat website-eigenaren geleidelijk upgraden naar de nieuwe hoofdversies. WordPress versie 5.5, die werd uitgebracht op 11 augustus 2020, omvatte bijvoorbeeld al 10,22% van de WordPress-installaties die werden waargenomen tijdens de crawl voor augustus. +Als een van de meest populaire [Content Management Systemen](./cms) is WordPress een aantrekkelijk doelwit voor aanvallers. Daarom is het belangrijk voor websitebeheerders om hun installatie up-to-date te houden. Standaard worden updates automatisch uitgevoerd voor WordPress, hoewel het mogelijk is om deze functie uit te schakelen. De evolutie van de geïmplementeerde WordPress-versies wordt weergegeven in de bovenstaande afbeelding, met de laatste belangrijke versies die nog steeds actief worden onderhouden (5.5: paars, 5.4: blauw, 5.3 : rood, 5,2: groen, 4,9: oranje). Versies met een prevalentie van minder dan 4% worden bij elkaar gegroepeerd onder "Overig". Een eerste interessante observatie die gemaakt kan worden, is dat vanaf augustus 2020 74,89% van de WordPress-installaties op mobiele startpagina's de nieuwste versie binnen hun branche draaien. Het is ook te zien dat website-eigenaren geleidelijk upgraden naar de nieuwe hoofdversies. WordPress versie 5.5, die werd uitgebracht op 11 augustus 2020, omvatte bijvoorbeeld al 10,22% van de WordPress-installaties die werden waargenomen tijdens de crawl voor augustus. {{ figure_markup( image="security-evolution-of-wordpress-5-3and5-4-after-update.png", @@ -974,7 +974,7 @@ Een ander interessant aspect dat uit de grafiek kan worden afgeleid, is dat binn sql_file="feature_adoption_by_technology.sql" ) }} -Een van de meest gebruikte JavaScript-bibliotheken is jQuery, dat drie hoofdversies heeft: 1.x, 2.x en 3.x. Zoals duidelijk is uit de evolutie van jQuery-versies die worden gebruikt op mobiele homepagina's, is de algehele distributie in de loop van de tijd erg statisch. Verrassend genoeg draait een aanzienlijk deel van de websites (18,21% vanaf augustus 2020) nog steeds een oude 1.x-versie van jQuery. Deze fractie neemt consequent af (van 33,39% in november 2019), ten gunste van versie 1.12.4, vrijgegeven in mei 2016 en helaas verschillende beveiligingsproblemen op middelhoog niveau heeft . +Een van de meest gebruikte JavaScript-bibliotheken is jQuery, dat drie hoofdversies heeft: 1.x, 2.x en 3.x. Zoals duidelijk is uit de evolutie van jQuery-versies die worden gebruikt op mobiele startpagina's, is de algehele distributie in de loop van de tijd erg statisch. Verrassend genoeg draait een aanzienlijk deel van de websites (18,21% vanaf augustus 2020) nog steeds een oude 1.x-versie van jQuery. Deze fractie neemt consequent af (van 33,39% in november 2019), ten gunste van versie 1.12.4, vrijgegeven in mei 2016 en helaas verschillende beveiligingsproblemen op middelhoog niveau heeft . ### nginx diff --git a/src/content/nl/2020/third-parties.md b/src/content/nl/2020/third-parties.md index 01125f48958..85587fe871e 100644 --- a/src/content/nl/2020/third-parties.md +++ b/src/content/nl/2020/third-parties.md @@ -70,7 +70,7 @@ _Opmerking over CDN's: de CDN-categorie hier omvat providers die bronnen leveren * Alle hier gepresenteerde gegevens zijn gebaseerd op een niet-interactieve, koude belasting. Deze waarden kunnen er na gebruikersinteractie behoorlijk anders uitzien. * De pagina's worden getest vanaf servers in de VS zonder dat er cookies zijn ingesteld, dus derde partijen die worden aangevraagd na de opt-in zijn niet inbegrepen. Dit heeft met name gevolgen voor pagina's die worden gehost en voornamelijk worden aangeboden aan landen die onder de [Algemene Verordening Gegevensbescherming](https://nl.wikipedia.org/wiki/Algemene_verordening_gegevensbescherming) of andere soortgelijke wetgeving vallen. -* Alleen de homepagina's worden getest. Andere pagina's kunnen andere vereisten van derden hebben. +* Alleen de startpagina's worden getest. Andere pagina's kunnen andere vereisten van derden hebben. * Ongeveer 84% van alle domeinen van derden op verzoekvolume zijn geïdentificeerd en gecategoriseerd. De overige 16% valt in de categorie "Overig". Lees meer over onze [methodologie](./methodology). diff --git a/src/templates/nl/2019/methodology.html b/src/templates/nl/2019/methodology.html index 990d7b33630..716b5300be9 100644 --- a/src/templates/nl/2019/methodology.html +++ b/src/templates/nl/2019/methodology.html @@ -123,11 +123,11 @@

Websites

- Vanwege beperkte bronnen kan het HTTP Archive slechts één pagina van elke website in het Chrome UX Report testen. Om dit te verzoenen, zijn alleen de homepagina's opgenomen. Houd er rekening mee dat dit enige vertekening in de resultaten zal introduceren, omdat een startpagina niet noodzakelijk representatief is voor de hele website. + Vanwege beperkte bronnen kan het HTTP Archive slechts één pagina van elke website in het Chrome UX Report testen. Om dit te verzoenen, zijn alleen de startpagina's opgenomen. Houd er rekening mee dat dit enige vertekening in de resultaten zal introduceren, omdat een startpagina niet noodzakelijk representatief is voor de hele website.

- HTTP Archive wordt ook beschouwd als een testhulpmiddel voor laboratoria, wat betekent dat het websites test vanuit een datacenter en geen gegevens verzamelt van echte gebruikerservaringen. Daarom worden alle homepagina's van websites getest met een lege cache in een uitgelogde staat. + HTTP Archive wordt ook beschouwd als een testhulpmiddel voor laboratoria, wat betekent dat het websites test vanuit een datacenter en geen gegevens verzamelt van echte gebruikerservaringen. Daarom worden alle startpagina's van websites getest met een lege cache in een uitgelogde staat.

diff --git a/src/templates/nl/2020/methodology.html b/src/templates/nl/2020/methodology.html index 53f81449252..f104ea5f9c2 100644 --- a/src/templates/nl/2020/methodology.html +++ b/src/templates/nl/2020/methodology.html @@ -132,7 +132,7 @@

Websites

- Vanwege beperkte bronnen kan het HTTP Archive slechts één pagina van elke website in het Chrome UX Report testen. Om dit te verzoenen, zijn alleen de homepagina's opgenomen. Houd er rekening mee dat dit enige vertekening in de resultaten zal introduceren, omdat een startpagina niet noodzakelijk representatief is voor de hele website. + Vanwege beperkte bronnen kan het HTTP Archive slechts één pagina van elke website in het Chrome UX Report testen. Om dit te verzoenen, zijn alleen de startpagina's opgenomen. Houd er rekening mee dat dit enige vertekening in de resultaten zal introduceren, omdat een startpagina niet noodzakelijk representatief is voor de hele website.

From 6c34968882d99d714f3f79ede88247a6ff04ab73 Mon Sep 17 00:00:00 2001 From: Noah Date: Fri, 2 Apr 2021 11:10:24 +0200 Subject: [PATCH 06/11] finish translation of http2 to Dutch fix: "home" to "start" scherm --- src/content/nl/2020/capabilities.md | 2 +- src/content/nl/2020/http2.md | 448 ++++++++++++++-------------- src/content/nl/2020/mobile-web.md | 2 +- src/content/nl/2020/pwa.md | 2 +- 4 files changed, 227 insertions(+), 227 deletions(-) diff --git a/src/content/nl/2020/capabilities.md b/src/content/nl/2020/capabilities.md index 1389486f3ac..7a87ef7e34b 100644 --- a/src/content/nl/2020/capabilities.md +++ b/src/content/nl/2020/capabilities.md @@ -211,7 +211,7 @@ self.addEventListener('periodicsync', (event) => { }); ``` -Op het moment van schrijven implementeren alleen op Chromium gebaseerde browsers deze API. Op deze browsers moet de applicatie eerst worden geïnstalleerd (d.w.z. toegevoegd aan het home scherm) voordat de API kan worden gebruikt. De site engagement score van de website bepaalt of en hoe vaak periodieke synchronisatiegebeurtenissen kunnen worden aangeroepen. In de huidige conservatieve implementatie kunnen websites inhoud één keer per dag synchroniseren. +Op het moment van schrijven implementeren alleen op Chromium gebaseerde browsers deze API. Op deze browsers moet de applicatie eerst worden geïnstalleerd (d.w.z. toegevoegd aan het start scherm) voordat de API kan worden gebruikt. De site engagement score van de website bepaalt of en hoe vaak periodieke synchronisatiegebeurtenissen kunnen worden aangeroepen. In de huidige conservatieve implementatie kunnen websites inhoud één keer per dag synchroniseren. {{ figure_markup( image="periodic_background_sync_api.png", diff --git a/src/content/nl/2020/http2.md b/src/content/nl/2020/http2.md index 96c4eeb9d0d..869060e8ebd 100644 --- a/src/content/nl/2020/http2.md +++ b/src/content/nl/2020/http2.md @@ -1,63 +1,63 @@ --- #See https://github.com/HTTPArchive/almanac.httparchive.org/wiki/Authors'-Guide#metadata-to-add-at-the-top-of-your-chapters title: HTTP/2 -description: HTTP/2 chapter of the 2020 Web Almanac covering adoption and impact of HTTP/2, HTTP/2 Push, HTTP/2 Issues, and HTTP/3. +description: HTTP/2-hoofdstuk van de Web Almanac 2020, dat de acceptatie en impact van HTTP/2, HTTP/2 Push, HTTP/2 Issues en HTTP/3 behandelt. authors: [dotjs, rmarx, MikeBishop] reviewers: [LPardue, bazzadp, ibnesayeed] analysts: [gregorywolf] editors: [rviscomi] -translators: [] -dotjs_bio: Andrew works at Cloudflare helping to make the web faster and more secure. He spends his time deploying, measuring and improving new protocols and asset delivery to improve end-user website performance. -rmarx_bio: Robin is a web protocol and performance researcher at Hasselt University, Belgium. He has been working on getting QUIC and HTTP/3 ready to use by creating tools like qlog and qvis. -MikeBishop_bio: Editor of HTTP/3 with the QUIC Working Group. Architect in Akamai's Foundry group. +translators: [noah-vdv] +dotjs_bio: Andrew werkt bij Cloudflare om het internet sneller en veiliger te maken. Hij besteedt zijn tijd aan het implementeren, meten en verbeteren van nieuwe protocollen en levering van activa om de prestaties van de website van eindgebruikers te verbeteren. +rmarx_bio: Robin is een webprotocol- en prestatieonderzoeker bij Universiteit Hasselt, België. Hij heeft gewerkt aan het gebruiksklaar maken van QUIC en HTTP/3 door hulpmiddelen te maken zoals qlog en qvis. +MikeBishop_bio: Editor van HTTP/3 met de QUIC Working Group. Architect in de Foundry-groep van Akamai. discuss: 2058 results: https://docs.google.com/spreadsheets/d/1M1tijxf04wSN3KU0ZUunjPYCrVsaJfxzuRCXUeRQ-YU/ -featured_quote: This chapter reviews the current state of HTTP/2 and gQUIC deployment, to establish how well some of the newer features of the protocol, such as prioritization and server push, have been adopted. We then look at the motivations for HTTP/3, describe the major differences between the protocol versions and discuss the potential challenges in upgrading to a UDP-based transport protocol with QUIC. +featured_quote: Dit hoofdstuk bespreekt de huidige status van de implementatie van HTTP/2 en gQUIC, om vast te stellen hoe goed sommige van de nieuwere functies van het protocol, zoals prioriteitstelling en serverpush, zijn overgenomen. Vervolgens kijken we naar de motivaties voor HTTP/3, beschrijven we de belangrijkste verschillen tussen de protocolversies en bespreken we de mogelijke uitdagingen bij het upgraden naar een UDP-gebaseerd transportprotocol met QUIC. featured_stat_1: 64% -featured_stat_label_1: Requests served over HTTP/2 -featured_stat_2: 31.7% -featured_stat_label_2: CDN Requests with incorrect HTTP/2 prioritization +featured_stat_label_1: Verzoeken geleverd via HTTP/2 +featured_stat_2: 31,7% +featured_stat_label_2: CDN-verzoeken met onjuiste HTTP/2-prioriteitstelling featured_stat_3: 80% -featured_stat_label_3: Pages served over HTTP/2 if a CDN is used, 30% if CDN not used +featured_stat_label_3: Pagina's die worden bediend via HTTP/2 als een CDN wordt gebruikt, 30% als CDN niet wordt gebruikt --- -## Introduction +## Inleiding -HTTP is an application layer protocol designed to transfer information between networked devices and runs on top of other layers of the network protocol stack. After HTTP/1.x was released, it took over 20 years until the first major update, HTTP/2, was made a standard in 2015. +HTTP is een applicatielaagprotocol dat is ontworpen om informatie tussen netwerkapparaten uit te wisselen en wordt uitgevoerd bovenop andere lagen van de netwerkprotocolstapel. Nadat HTTP/1.x was uitgebracht, duurde het meer dan 20 jaar voordat de eerste grote update, HTTP/2, in 2015 een standaard werd. -It didn't stop there: over the last four years, HTTP/3 and QUIC (a new latency-reducing, reliable, and secure transport protocol) have been under standards development in the IETF QUIC working group. There are actually two protocols that share the same name: "Google QUIC" ("gQUIC" for short), the original protocol that was designed and used by Google, and the newer IETF standardized version (IETF QUIC/QUIC). IETF QUIC was based on gQUIC, but has grown to be quite different in design and implementation. On October 21, 2020, draft 32 of IETF QUIC reached a significant milestone when it moved to Last Call. This is the part of the standardization process when the working group believes they are almost finished and requests a final review from the wider IETF community. +Daar bleef het niet bij: de afgelopen vier jaar zijn HTTP/3 en QUIC (een nieuw latentieverminderend, betrouwbaar en veilig transportprotocol) in standaarden ontwikkeld in de IETF QUIC-werkgroep. Er zijn eigenlijk twee protocollen die dezelfde naam hebben: "Google QUIC" (afgekort "gQUIC"), het oorspronkelijke protocol dat is ontworpen en gebruikt door Google, en de nieuwere IETF-gestandaardiseerde versie (IETF QUIC/QUIC). IETF QUIC was gebaseerd op gQUIC, maar is uitgegroeid tot een heel ander ontwerp en implementatie. Op 21 oktober 2020 bereikte concept 32 van IETF QUIC een belangrijke mijlpaal toen het werd verplaatst naar Last Call. Dit is het deel van het standaardisatieproces wanneer de werkgroep denkt dat ze bijna klaar zijn en vraagt om een laatste beoordeling van de bredere IETF-gemeenschap. -This chapter reviews the current state of HTTP/2 and gQUIC deployment. It explores how well some of the newer features of the protocol, such as prioritization and server push, have been adopted. We then look at the motivations for HTTP/3, describe the major differences between the protocol versions, and discuss the potential challenges in upgrading to a UDP-based transport protocol with QUIC. +In dit hoofdstuk wordt de huidige status van HTTP/2 en gQUIC-implementatie besproken. Het onderzoekt hoe goed sommige van de nieuwere functies van het protocol, zoals prioriteitstelling en server-push, zijn overgenomen. Vervolgens kijken we naar de motivaties voor HTTP/3, beschrijven we de belangrijkste verschillen tussen de protocolversies en bespreken we de mogelijke uitdagingen bij het upgraden naar een UDP-gebaseerd transportprotocol met QUIC. -### HTTP/1.0 to HTTP/2 +### HTTP/1.0 naar HTTP/2 -As the HTTP protocol has evolved, the semantics of HTTP have stayed the same; there have been no changes to the HTTP methods (such as GET or POST), status codes (200, or the dreaded 404), URIs, or header fields. Where the HTTP protocol has changed, the differences have been the wire-encoding and the use of features of the underlying transport. +Terwijl het HTTP-protocol is geëvolueerd, is de semantiek van HTTP hetzelfde gebleven; er zijn geen wijzigingen in de HTTP-methoden (zoals GET of POST), statuscodes (200 of de gevreesde 404), URI's of headervelden. Waar het HTTP-protocol is veranderd, zijn de verschillen de draadcodering en het gebruik van functies van het onderliggende transport. -HTTP/1.0, published in 1996, defined the text-based application protocol, allowing clients and servers to exchange messages in order to request resources. A new TCP connection was required for each request/response, which introduced overhead. TCP connections use a congestion control algorithm to maximize how much data can be in-flight. This process takes time for each new connection. This "slow-start" means that not all the available bandwidth is used immediately. +HTTP/1.0, gepubliceerd in 1996, definieerde het op tekst gebaseerde applicatieprotocol, waardoor cliënten en servers berichten kunnen uitwisselen om bronnen aan te vragen. Voor elk verzoek/antwoord was een nieuwe TCP-verbinding vereist, waardoor overhead werd geïntroduceerd. TCP-verbindingen gebruiken een algoritme voor congestiecontrole om te maximaliseren hoeveel gegevens er tijdens de vlucht kunnen zijn. Dit proces kost tijd voor elke nieuwe verbinding. Deze "langzame start" betekent dat niet alle beschikbare bandbreedte onmiddellijk wordt gebruikt. -In 1997, HTTP/1.1 was introduced to allow TCP connection reuse by adding "keep-alives", aimed at reducing the total cost of connection start-ups. Over time, increasing website performance expectations led to the need for concurrency of requests. HTTP/1.1 could only request another resource after the previous response had completed. Therefore, additional TCP connections had to be established, reducing the impact of the keep-alive connections and further increasing overhead. +In 1997 werd HTTP/1.1 geïntroduceerd om hergebruik van TCP-verbindingen mogelijk te maken door "keep-alives" toe te voegen, gericht op het verlagen van de totale kosten van het opstarten van verbindingen. Na verloop van tijd leidden de toenemende prestatieverwachtingen van de website tot de behoefte aan gelijktijdigheid van verzoeken. HTTP/1.1 kon alleen een andere bron opvragen nadat het vorige antwoord was voltooid. Daarom moesten extra TCP-verbindingen tot stand worden gebracht, waardoor de impact van de keep-alive-verbindingen werd verkleind en de overhead nog groter werd. -HTTP/2, published in 2015, is a binary-based protocol that introduced the concept of bidirectional streams between client and server. Using these streams, a browser can make optimal use of a single TCP connection to _multiplex_ multiple HTTP requests/responses concurrently. HTTP/2 also introduced a prioritization scheme to steer this multiplexing; clients can signal a request priority that allows more important resources to be sent ahead of others. +HTTP/2, gepubliceerd in 2015, is een binair protocol dat het concept van bidirectionele streams tussen cliënt en server introduceerde. Met behulp van deze streams kan een browser optimaal gebruik maken van een enkele TCP-verbinding om meerdere HTTP-verzoeken/-antwoorden tegelijkertijd te _multiplexen_. HTTP/2 introduceerde ook een prioriteitsschema om deze _multiplexing_ te sturen; cliënten kunnen een verzoekprioriteit aangeven waardoor belangrijkere bronnen vóór anderen kunnen worden verzonden. -## HTTP/2 Adoption +## HTTP/2-Adoptie -The data used in this chapter is sourced from the HTTP Archive and tests over seven million websites with a Chrome browser. As with other chapters, the analysis is split by mobile and desktop websites. When the results between desktop and mobile are similar, statistics are presented from the mobile dataset. You can find more details on the [Methodology](./methodology) page. When reviewing this data, please bear in mind that each website will receive equal weight regardless of the number of requests. We suggest you think of this more as investigating the trends across a broad range of active websites. +De gegevens die in dit hoofdstuk worden gebruikt, zijn afkomstig uit het HTTP Archive en testen meer dan zeven miljoen websites met een Chrome-browser. Net als bij andere hoofdstukken, wordt de analyse opgesplitst in mobiele en desktopwebsites. Wanneer de resultaten tussen desktop en mobiel vergelijkbaar zijn, worden statistieken uit de mobiele dataset gepresenteerd. U kunt meer details vinden op de pagina [Methodologie](./methodology). Houd er bij het bekijken van deze gegevens rekening mee dat elke website evenveel gewicht krijgt, ongeacht het aantal verzoeken. We raden u aan dit meer te zien als het onderzoeken van de trends op een breed scala aan actieve websites. {{ figure_markup( image="http2-h2-usage.png", - alt="HTTP/2 usage by request.", + alt="HTTP/2-gebruik op verzoek.", link="https://httparchive.org/reports/state-of-the-web#h2", - caption='HTTP/2 usage by request. (Source: HTTP Archive)', - description="Timeseries chart of HTTP/2 usage showing adoption at 64% for both desktop and mobile as of July 2019. The trend is growing steadily at about 15 points per year.", + caption='HTTP/2-gebruik op verzoek. (Bron: HTTP Archive)', + description="Tijdreeksdiagram van HTTP / 2-gebruik met een acceptatie van 64% voor zowel desktop als mobiel vanaf juli 2019. De trend groeit gestaag met ongeveer 15 punten per jaar.", width=600, height=321 ) }} -Last year's analysis of HTTP Archive data showed that HTTP/2 was used for over 50% of requests and, as can be seen, linear growth has continued in 2020; now in excess of 60% of requests are served over HTTP/2. +Uit de analyse van HTTP Archive-gegevens vorig jaar bleek dat HTTP/2 werd gebruikt voor meer dan 50% van de verzoeken en, zoals te zien is, is de lineaire groei in 2020 voortgezet; nu wordt meer dan 60% van de verzoeken bediend via HTTP/2. {{ figure_markup( - caption="The percentage of requests that use HTTP/2.", + caption="Het percentage verzoeken dat gebruikmaakt van HTTP/2.", content="64%", classes="big-number", sheets_gid="2122693316", @@ -65,7 +65,7 @@ Last year's analysis of HTTP Archive data showed that HTTP/2 was used for over 5 ) }} -When comparing Figure 22.3 with last year's results, there has been a **10% increase in HTTP/2 requests** and a corresponding 10% decrease in HTTP/1.x requests. This is the first year that gQUIC can be seen in the dataset. +Wanneer Figuur 22.3 wordt vergeleken met de resultaten van vorig jaar, is er een toename van **10% in HTTP/2-verzoeken** en een overeenkomstige afname van 10% in HTTP/1.x-verzoeken. Dit is het eerste jaar dat gQUIC in de dataset te zien is.

BestandsextensieBureaubladDesktop Mobiel
MetingBureaubladDesktop Mobiel
@@ -73,38 +73,38 @@ When comparing Figure 22.3 with last year's results, there has been a **10% incr - + - - + + - - + + - - + +
Protocol DesktopMobileMobiel
HTTP/1.1**34.47%34.11%**34,47%34,11%
HTTP/263.70%63.80%63,70%63,80%
gQUIC1.72%1.71%1,72%1,71%
-
{{ figure_link(caption="HTTP version usage by request.", sheets_gid="2122693316", sql_file="adoption_of_http_2_by_site_and_requests.sql") }}
+
{{ figure_link(caption="Gebruik van HTTP-versie op verzoek.", sheets_gid="2122693316", sql_file="adoption_of_http_2_by_site_and_requests.sql") }}

- ** As with last year's crawl, around 4% of desktop requests did not report a protocol version. Analysis shows these to mostly be HTTP/1.1 and we worked to fix this gap in our statistics for future crawls and analysis. Although we base the data on the August 2020 crawl, we confirmed the fix in the October 2020 data set before publication which did indeed show these were HTTP/1.1 requests and so have added them to that statistic in above table. + ** Net als bij de crawl van vorig jaar, meldde ongeveer 4% van de desktopverzoeken geen protocolversie. Analyse toont aan dat dit meestal HTTP/1.1 is en we hebben eraan gewerkt om dit gat in onze statistieken voor toekomstige crawls en analyses te dichten. Hoewel we de gegevens baseren op de crawl van augustus 2020, hebben we de correctie in de gegevensset van oktober 2020 vóór publicatie bevestigd, die inderdaad aantoonde dat dit HTTP/1.1-verzoeken waren en hebben ze daarom aan die statistiek in de bovenstaande tabel toegevoegd. -When reviewing the total number of website requests, there will be a bias towards common third-party domains. To get a better understanding of the HTTP/2 adoption by server install, we will look instead at the protocol used to serve the HTML from the home page of a site. +Bij het beoordelen van het totale aantal websiteverzoeken, zal er een voorkeur zijn voor algemene domeinen van derden. Om een beter begrip te krijgen van de HTTP/2-acceptatie door serverinstallatie, zullen we in plaats daarvan kijken naar het protocol dat wordt gebruikt om de HTML aan te bieden vanaf de startpagina van een site. -Last year around 37% of home pages were served over HTTP/2 and 63% over HTTP/1. This year, combining mobile and desktop, it is a roughly equal split, with slightly more desktop sites being served over HTTP/2 for the first time, as shown in Figure 22.4. +Vorig jaar werd ongeveer 37% van de startpagina's bediend via HTTP/2 en 63% via HTTP/1. Dit jaar is de combinatie van mobiel en desktop ongeveer gelijk, met iets meer desktopsites die voor het eerst via HTTP/2 worden bediend, zoals weergegeven in figuur 22.4.

@@ -112,34 +112,34 @@ Last year around 37% of home pages were served over HTTP/2 and 63% over HTTP/1. - + - - + + - - + + - - + +
Protocol DesktopMobileMobiel
HTTP/1.00.06%0.05%0,06%0,05%
HTTP/1.149.22%50.05%49,22%50,05%
HTTP/249.97%49.28%49,97%49,28%
-
{{ figure_link(caption="HTTP version usage for home pages.", sheets_gid="1447413141", sql_file="measure_of_all_http_versions_for_main_page_of_all_sites.sql") }}
+
{{ figure_link(caption="HTTP-versiegebruik voor startpagina's.", sheets_gid="1447413141", sql_file="measure_of_all_http_versions_for_main_page_of_all_sites.sql") }}
-gQUIC is not seen in the home page data for two reasons. To measure a website over gQUIC, the HTTP Archive crawl would have to perform protocol negotiation via the [alternative services](#alternative-services) header and then use this endpoint to load the site over gQUIC. This was not supported this year, but expect it to be available in next year's Web Almanac. Also, gQUIC is predominantly used for third-party Google tools rather than serving home pages. +gQUIC wordt om twee redenen niet gezien in de gegevens van de startpagina. Om een website over gQUIC te meten, zou de HTTP Archivecrawl protocolonderhandelingen moeten uitvoeren via de [alternative services](#alternative-services)-header en vervolgens dit eindpunt gebruiken om de site over gQUIC te laden. Dit werd dit jaar niet ondersteund, maar verwacht dat het volgend jaar beschikbaar zal zijn in de Web Almanac. gQUIC wordt ook voornamelijk gebruikt voor Google-tools van derden in plaats van startpagina's weer te geven. -The drive to increase [security](./security) and [privacy](./privacy) on the web has seen requests over TLS increase by over 150% in the last 4 years. Today, over 86% of all requests on mobile and desktop are encrypted. Looking only at home pages, the numbers are still an impressive 78.1% of desktop and 74.7% of mobile. This is important because HTTP/2 is only supported by browsers over TLS. The proportion served over HTTP/2, as shown in Figure 22.5, has also increased by 10 percentage points from [last year](../2019/http2#fig-5), from 55% to 65%. +De drang om [beveiliging](./security) en [privacy](./privacy) op het web te verbeteren, heeft geleid tot een toename van het aantal verzoeken over TLS met meer dan 150% in de afgelopen 4 jaar. Tegenwoordig is meer dan 86% van alle verzoeken op mobiel en desktop versleuteld. Als we alleen naar startpagina's kijken, zijn de cijfers nog steeds een indrukwekkende 78,1% van de desktop en 74,7% van de mobiele apparaten. Dit is belangrijk omdat HTTP/2 alleen wordt ondersteund door browsers via TLS. Het aandeel dat via HTTP/2 wordt bediend, zoals weergegeven in figuur 22.5, is ook met 10 procentpunten gestegen ten opzichte van [vorig jaar](../2019/http2#fig-5), van 55% naar 65%.
@@ -147,114 +147,114 @@ The drive to increase [security](./security) and [privacy](./privacy) on the web - + - - + + - - + +
Protocol DesktopMobileMobiel
HTTP/1.136.05%34.04%36,05%34,04%
HTTP/263.95%65.96%63,95%65,96%
-
{{ figure_link(caption="HTTP version usage for HTTPS home pages.", sheets_gid="900140630", sql_file="tls_adoption_by_http_version.sql") }}
+
{{ figure_link(caption="HTTP-versiegebruik voor HTTPS-startpagina's.", sheets_gid="900140630", sql_file="tls_adoption_by_http_version.sql") }}
-With over 60% of websites being served over HTTP/2 or gQUIC, let's look a little deeper into the pattern of protocol distribution for all requests made across individual sites. +Nu meer dan 60% van de websites wordt bediend via HTTP/2 of gQUIC, gaan we wat dieper kijken naar het patroon van protocoldistributie voor alle verzoeken die op individuele sites worden gedaan. {{ figure_markup( image="http2-h2-or-gquic-requests-per-page.png", - caption="Compare the distribution of fraction of HTTP/2 requests per page in 2020 with 2019.", - description="A bar chart of the fraction of HTTP/2 requests by page percentile. The median percentage of HTTP/2 or gQUIC requests per page has increased to 76% in 2020 from 46% in 2019. At the 10, 25, 75, and 90th percentiles, the fraction of HTTP/2 or gQUIC requests per page in 2020 is 5%, 24%, 98% and 100% compared to 3%, 15%, 93% and 100% in 2019.", + caption="Vergelijk de verdeling van fractie van HTTP/2-aanvragen per pagina in 2020 met 2019.", + description="Een staafdiagram van de fractie van HTTP/2-aanvragen per pagina percentage. Het mediane percentage van HTTP/2- of GQUIC-aanvragen per pagina is toegenomen tot 76% in 2020 van 46% in 2019. Op de 10, 25, 75 en 90e percentielen, de fractie van HTTP/2- of GQUIC-aanvragen per pagina in 2020 is 5%, 24%, 98% en 100% vergeleken met 3%, 15%, 93% en 100% in 2019.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=1328744214&format=interactive", sheets_gid="152400778", sql_file="percentiles_of_resources_loaded_over_HTTP2_or_better_per_site.sql" ) }} -Figure 22.6 compares how much HTTP/2 or gQUIC is used on a website between this year and last year. The most noticeable change is that over half of sites now have 75% or more of their requests served over HTTP/2 or gQUIC compared to 46% last year. Less than 7% of sites make no HTTP/2 or gQUIC requests, while (only) 10% of sites are entirely HTTP/2 or gQUIC requests. +Figuur 22.6 Vergelijkt hoeveel HTTP/2 of GQUIC wordt gebruikt op een website tussen dit jaar en vorig jaar. De meest opvallende verandering is dat meer dan de helft van de sites nu 75% of meer van hun verzoeken heeft geserveerd via HTTP/2 of GQUIC vergeleken met 46% vorig jaar. Minder dan 7% van de sites maakt geen HTTP/2- of GQUIC-aanvragen, terwijl (alleen) 10% van de sites volledig HTTP/2- of GQUIC-verzoeken is. -What about the breakdown of the page itself? We typically talk about the difference between first-party and third-party content. Third-party is defined as content not within the direct control of the site owner, providing functionality such as advertising, marketing or analytics. The definition of known third parties is taken from the third party web repository. +Hoe zit het met de uitsplitsing van de pagina zelf? We praten meestal over het verschil tussen inhoud van de eerste partij en derden. Derde-partij wordt gedefinieerd als inhoud die niet binnen de directe controle van de eigenaar van de site, functionaliteit, zoals reclame, marketing of analyse biedt. De definitie van bekende derden is afkomstig van de third party web repository. -Figure 22.7 orders every website by the fraction of HTTP/2 requests for known third parties or first party requests compared to other requests. There is a noticeable difference as over 40% of all sites have no first-party HTTP/2 or gQUIC requests at all. By contrast, even the lowest 5% of pages have 30% of third-party content served over HTTP/2. This indicates that a large part of HTTP/2's broad adoption is driven by the third parties. +Figuur 22.7 bestelt van elke website door de fractie van HTTP/2-verzoeken voor bekende derden of eerste partijverzoeken in vergelijking met andere verzoeken. Er is een merkbaar verschil als meer dan 40% van alle sites geen HTTP/2 of GQUIC-aanvragen heeft. Daarentegen heeft zelfs de laagste 5% van de pagina's 30% van de inhoud van derden geserveerd via HTTP/2. Dit geeft aan dat een groot deel van de brede goedkeuring van HTTP/2 wordt aangedreven door de derde partijen. {{ figure_markup( image="http2-first-and-third-party-http2-usage.png", - caption="The distribution of the fraction of third-party and first-party HTTP/2 requests per page.", - description="A line chart comparing the fraction of first-party HTTP/2 requests with third-party HTTP/2 or gQUIC requests. The chart orders the websites by fraction of HTTP/2 requests. 45% of websites have no HTTP/2 first-party requests. Over half of websites serve third-party requests only over HTTP/2 or gQUIC. 80% of websites have 76% or more third-party HTTP/2 or gQUIC requests.", + caption="De verdeling van de fractie van derden en eerste-Partij HTTP/2-aanvragen per pagina.", + description="Een lijndiagram vergelijkt de fractie van HTTP/2-aanvragen van de eerste partijen met HTTP/2- of GQUIC-verzoeken van derden. De grafiek bestelt de websites per fractie van HTTP/2-aanvragen. 45% van de websites heeft geen HTTP/2 eerste-partij-aanvragen. Meer dan de helft van de websites serveren alleen aanvragen van derden via HTTP/2 of GQUIC. 80% van de websites heeft 76% of meer HTTP/2- of GQUIC-aanvragen van derden.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=1409316276&format=interactive", sql_file="http2_1st_party_vs_3rd_party.sql", sheets_gid="733872185" ) }} -Is there any difference in which content-types are served over HTTP/2 or gQUIC? Figure 22.8 shows, for example, that 90% of websites serve 100% of third party fonts and audio over HTTP/2 or gQUIC, only 5% over HTTP/1.1 and 5% are a mix. The majority of third-party assets are either scripts or images, and are solely served over HTTP/2 or gQUIC on 60% and 70% of websites respectively. +Is er een verschil in welke inhoud-typen worden geserveerd via HTTP/2 of GQUIC? Figuur 22.8 toont bijvoorbeeld dat 90% van de websites 100% van de lettertypen van derden en audio via HTTP/2 of GQUIC serveert, slechts 5% boven HTTP/1.1 en 5% zijn een mix. De meerderheid van de activa van derden is scripts of afbeeldingen en worden uitsluitend geserveerd over HTTP/2 of GQUIC op respectievelijk 60% en 70% van de websites. {{ figure_markup( image="http2-third-party-http2-usage-by-content-type.png", - caption="The fraction of known third-party HTTP/2 or gQUIC requests by content-type per website.", - description="A bar chart comparing the fraction of third-party HTTP/2 requests by content-type. All third-party requests are served over HTTP/2 or gQUIC for 90% of audio and fonts, 80% of css and video, 70% of html, image and text and 60% of scripts.", + caption="De fractie van bekende HTTP/2- of GQUIC-verzoeken van derden door inhoudstype per website.", + description="Een staafdiagram vergelijken met de fractie van HTTP/2-aanvragen van derden door inhoudstype. Alle vragen van derden worden geserveerd via HTTP/2 of GQUIC voor 90% van audio en lettertypen, 80% van CSS en video, 70% van HTML, beeld en tekst en 60% van de scripts.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=1264128523&format=interactive", sheets_gid="419557288", sql_file="http2_1st_party_vs_3rd_party_by_type.sql" ) }} -Ads, analytics, content delivery network (CDN) resources, and tag-managers are predominantly served over HTTP/2 or gQUIC as shown in Figure 22.9. Customer-success and marketing content is more likely to be served over HTTP/1. +Advertenties, Analytics, Content Delivery Network (CDN)-bronnen en tag-managers worden voornamelijk geserveerd via HTTP/2 of GQUIC zoals getoond in Figuur 22.9. Customer-success en Marketing-inhoud wordt waarschijnlijk meer geserveerd via HTTP/1. {{ figure_markup( image="http2-third-party-http2-usage-by-category.png", - caption="The fraction of known third-party HTTP/2 or gQUIC requests by category per website.", - description="A bar chart comparing the fraction of third-party HTTP/2 or gQUIC requests by category. All third-party requests for all websites are served over HTTP/2 or gQUIC for 95% of tag managers, 90% of analytics and CDN, 80% of ads, social, hosting and utility, 40% of marketing and 30% of customer-success.", + caption="De fractie van bekende HTTP/2- of GQUIC-verzoeken van derden per categorie per website.", + description="Een staafdiagram die vergelijkt de fractie van HTTP/2- of GQUIC-aanvragen van derden per categorie. Alle vragen van derden voor alle websites worden geserveerd via HTTP / 2 of GQUIC voor 95% van de tagmanagers, 90% van de analyse en CDN, 80% van de advertenties, sociale, hosting en nut, 40% van de marketing en 30% van de klant -succes.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=1419102835&format=interactive", sheets_gid="1059610651", sql_file="http2_3rd_party_by_types.sql" ) }} -### Server support +### Serverondersteuning -Browser auto-update mechanisms are a driving factor for client-side adoption of new web standards. It's estimated that over 97% of global users support HTTP/2, up slightly from 95% measured last year. +Browser auto-update-mechanismen zijn een drijffactor voor de aanneming van de klantzijde van nieuwe webnormen. Het is geschat dat meer dan 97% van de wereldwijde gebruikers HTTP/2 ondersteunt, enigszins omhoog van 95% gemeten vorig jaar. -Unfortunately, the upgrade path for servers is more difficult, especially with the requirement to support TLS. For mobile and desktop, we can see from Figure 22.10, that the majority of HTTP/2 sites are served by nginx, Cloudflare, and Apache. Almost half of the HTTP/1.1 sites are served by Apache. +Helaas is het verbeteringspad voor servers moeilijker, vooral met de eis om TLS te ondersteunen. Voor mobiel en desktop kunnen we zien vanaf figuur 22.10, dat de meerderheid van de HTTP/2-sites worden bediend door NGINX, CloudFlare en Apache. Bijna de helft van de HTTP/1.1-sites wordt bediend door Apache. {{ figure_markup( image="http2-server-protocol-usage.png", - caption="Server usage by HTTP protocol on mobile", - description="A bar chart showing the number of websites served by either HTTP/1.x or HTTP/2 for the most popular servers to mobile clients. Nginx serves 727,181 HTTP/1.1 and 1,023,575 HTTP/2 sites. Cloudflare 59,981 HTTP/1.1 and 679,616 HTTP/2. Apache 1,521,753 HTTP/1.1 and 585,096 HTTP/2. Litespeed 50,502 HTTP/1.1 and 166,721 HTTP/2. Microsoft-IIS 284,047 HTTP/1.1 and 81,490 HTTP/2.", + caption="Servergebruik door HTTP-protocol op mobiel", + description="Een staafdiagram met het aantal websites dat wordt gediend door HTTP/1.x of HTTP/2 voor de populairste servers naar mobiele klanten. NGINX serveert 727.181 HTTP/1.1 en 1.023.575 HTTP/2 sites. Cloudflare 59.981 HTTP/1.1 en 679.616 HTTP/2. Apache 1.521.753 HTTP/1.1 en 585.096 HTTP/2. Litespeed 50.502 HTTP/1.1 en 166.721 HTTP/2. Microsoft-IIS 284.047 HTTP/1.1 en 81.490 HTTP/2.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=718663369&format=interactive", sheets_gid="306338094", sql_file="count_of_h2_and_h3_sites_grouped_by_server.sql" ) }} -How has HTTP/2 adoption changed in the last year for each server? Figure 22.11 shows a general HTTP/2 adoption increase of around 10% across all servers since last year. Apache and IIS are still under 25% HTTP/2. This suggests that either new servers tend to be nginx or it is seen as too difficult or not worthwhile to upgrade Apache or IIS to HTTP/2 and/or TLS. +Hoe wordt HTTP/2-adoptie in het laatste jaar voor elke server gewijzigd? Figuur 22.11 toont een algemene HTTP/2-goedkeuring van ongeveer 10% in alle servers sinds vorig jaar. Apache en IIS zijn nog steeds minder dan 25% HTTP/2. Dit suggereert dat nieuwe servers de neiging hebben NGINX te zijn of het wordt gezien als te moeilijk of niet de moeite waard om Apache of IIS naar HTTP/2 en/of TLS te upgraden. {{ figure_markup( image="http2-h2-usage-by-server.png", - caption="Percentage of pages served over HTTP/2 by server", - description="A bar chart comparing the percentage of websites served over HTTP/2 between 2019 and 2020. Cloudflare increased to 93.08% from 85.40%. Litespeed increased to 81.91% from 70.80%. Openresty increased to 66.24% from 51.40%. Nginx increased to 60.84% from 49.20%. Apache increased to 27.19% from 18.10% and MIcorsoft-IIS increased to 22.82% from 14.10%.", + caption="Percentage pagina's geserveerd via HTTP/2 per server", + description="Een staafdiagram die het percentage van websites die geserveerd worden via HTTP/2 tussen 2019 en 2020 vergelijkt. Cloudflare steeg tot 93,08% van 85,40%. Litespeed steeg tot 81,91% van 70,80%. Openstations steeg tot 66,24% van 51,40%. NGINX steeg tot 60,84% van 49,20%. Apache steeg tot 27,19% van 18,10% en MIcorSoft-IIS steeg tot 22,82% van 14,10%.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=936321266&format=interactive", sheets_gid="306338094", sql_file="count_of_h2_and_h3_sites_grouped_by_server.sql" ) }} -A long-term recommendation to improve website performance has been to use a CDN. The benefit is a reduction in latency by both serving content and terminating connections closer to the end user. This helps mitigate the rapid evolution in protocol deployment and the additional complexities in tuning servers and operating systems (see the [Prioritization](#prioritization) section for more details). To utilize the new protocols effectively, using a CDN can be seen as the recommended approach. +Een aanbeveling op lange termijn om de website-prestaties te verbeteren, is geweest om een CDN te gebruiken. Het voordeel is een vermindering van de latentie door zowel de inhoud en het beëindigen van verbindingen dichter bij de eindgebruiker. Dit helpt de snelle evolutie in Protocol-implementatie en de extra complexiteiten in tuningservers en besturingssystemen te beperken (zie de sectie [Prioritering](#prioritering) voor meer informatie). Om de nieuwe protocollen effectief te gebruiken, kan het gebruik van een CDN worden gezien als de aanbevolen aanpak. -CDNs can be classed in two broad categories: those that serve the home page and/or asset subdomains, and those that are mainly used to serve third-party content. Examples of the first category are the larger generic CDNs (such as Cloudflare, Akamai, or Fastly) and the more specific (such as WordPress or Netlify). Looking at the difference in HTTP/2 adoption rates for home pages served with or without a CDN, we see: +CDN's kunnen worden geclassificeerd in twee brede categorieën: degenen die de startpagina en/of activa-subdomeinen serveren, en degenen die voornamelijk worden gebruikt om inhoud van derden te dienen. Voorbeelden van de eerste categorie zijn de grotere generieke CDN's (zoals Cloudflare, Akamai of Fastly) en de specifieker (zoals WordPress of Netlify). Kijkend naar het verschil in HTTP/2-goedkeuringscijfers voor startpagina's geserveerd met of zonder een CDN, zien we: -- **80%** of mobile home pages are served over HTTP/2 if a CDN is used -- **30%** of mobile home pages are served over HTTP/2 if a CDN is not used +- **80%** van de mobiele startpagina's wordt bediend via HTTP/2 als een CDN wordt gebruikt +- **30%** van de mobiele startpagina's wordt bediend via HTTP/2 als er geen CDN wordt gebruikt -Figure 22.12 shows the more specific and the modern CDNs serve a higher proportion of traffic over HTTP/2. +Figuur 22.12 toont de meer specifieke en moderne CDN's die een groter deel van het verkeer bedienen via HTTP/2.
@@ -287,398 +287,398 @@ Figure 22.12 shows the more specific and the modern CDNs serve a higher proporti
-
{{ figure_link(caption="Percentage of HTTP/2 requests served by the first-party CDNs over mobile.", sheets_gid="781660433", sql_file="cdn_detail_by_cdn.sql") }}
+
{{ figure_link(caption="Percentage HTTP/2-verzoeken dat wordt geleverd door de eerste-partij CDN's via mobiel.", sheets_gid="781660433", sql_file="cdn_detail_by_cdn.sql") }}
-Types of content in the second category are typically shared resources (JavaScript or font CDNs), advertisements, or analytics. In all these cases, using a CDN will improve the performance and offload for the various SaaS solutions. +Typen inhoud in de tweede categorie zijn doorgaans gedeelde bronnen (JavaScript of lettertype-CDN's), advertenties of analyses. In al deze gevallen zal het gebruik van een CDN de prestaties en ontlasting voor de verschillende SaaS-oplossingen verbeteren. {{ figure_markup( image="http2-cdn-http2-usage.png", - caption="Comparison of HTTP/2 and gQUIC usage for websites using a CDN.", - description="A line chart comparing the fraction of requests served using HTTP/2 or gQUIC for websites that use a CDN compared to sites that do not. The x-axis show the percentiles of web page ordered by percentage of requests. 23% of websites that do not use a CDN have no HTTP/2 or gQUIC usage. In comparison the 60% of websites using a CDN have all HTTP/2 or gQUIC usage. 93% of websites that use a CDN and 47% of non-CDN sites have 50% or more HTTP/2 or gQUIC usage.", + caption="Vergelijking van HTTP/2- en gQUIC-gebruik voor websites die een CDN gebruiken.", + description="Een lijndiagram dat de fractie van verzoeken die met HTTP/2 of gQUIC worden bediend, voor websites die een CDN gebruiken, vergelijkt met sites die dat niet doen. De x-as toont de percentielen van webpagina's, gesorteerd op percentage verzoeken. 23% van de websites die geen CDN gebruiken, heeft geen HTTP/2- of gQUIC-gebruik. Ter vergelijking: de 60% van de websites die een CDN gebruiken, hebben allemaal HTTP/2- of gQUIC-gebruik. 93% van de websites die een CDN gebruiken en 47% van de niet-CDN-sites hebben 50% of meer HTTP/2- of gQUIC-gebruik.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=1779365083&format=interactive", sheets_gid="1457263817", sql_file="cdn_summary.sql" ) }} -In Figure 22.13 we can see the stark difference in HTTP/2 and gQUIC adoption when a website is using a CDN. 70% of pages use HTTP/2 for all third-party requests when a CDN is used. Without a CDN, only 25% of pages use HTTP/2 for all third-party requests. +In figuur 22.13 kunnen we het grote verschil zien in HTTP/2- en gQUIC-acceptatie wanneer een website een CDN gebruikt. 70% van de pagina's gebruikt HTTP/2 voor alle verzoeken van derden wanneer een CDN wordt gebruikt. Zonder CDN gebruikt slechts 25% van de pagina's HTTP/2 voor alle verzoeken van derden. -## HTTP/2 impact +## HTTP/2-impact -Measuring the impact of how a protocol is performing is difficult with the current HTTP Archive [approach](./methodology). It would be really fascinating to be able to quantify the impact of concurrent connections, the effect of packet loss, and different congestion control mechanisms. To really compare performance, each website would have to be crawled over each protocol over different network conditions. What we can do instead is to look into the impact on the number of connections a website uses. +Het meten van de impact van hoe een protocol presteert is moeilijk met de huidige HTTP Archive [benadering](./methodology). Het zou echt fascinerend zijn om de impact van gelijktijdige verbindingen, het effect van pakketverlies en verschillende mechanismen voor congestiecontrole te kunnen kwantificeren. Om de prestaties echt te kunnen vergelijken, zou elke website via elk protocol over verschillende netwerkomstandigheden moeten worden gecrawld. Wat we in plaats daarvan kunnen doen, is kijken naar de impact op het aantal verbindingen dat een website gebruikt. -### Reducing connections +### Verbindingen verminderen -As discussed [earlier](#http10-to-http2), HTTP/1.1 only allows a single request at a time over a TCP connection. Most browsers get around this by allowing six parallel connections per host. The major improvement with HTTP/2 is that multiple requests can be multiplexed over a single TCP connection. This should reduce the total number of connections—and the associated time and resources—required to load a page. +Zoals [eerder](#http10-naar-http2) besproken, staat HTTP/1.1 slechts één verzoek per keer via een TCP-verbinding toe. De meeste browsers omzeilen dit door zes parallelle verbindingen per host toe te staan. De belangrijkste verbetering met HTTP/2 is dat meerdere verzoeken via een enkele TCP-verbinding kunnen worden _gemultiplexed_. Dit zou het totale aantal verbindingen - en de bijbehorende tijd en middelen - die nodig zijn om een pagina te laden, moeten verminderen. {{ figure_markup( image="http2-total-number-of-connections-per-page.png", - caption="Distribution of total number of connections per page", - description="A percentile chart of total connections, comparing 2016 with 2020 on desktop. The median number of connections in 2016 is 23, in 2020 it is 13. At the 10th percentile, 6 connections in 2016, 5 in 2020. At the 25th percentile, 12 connections in 2016, 8 in 2020. At 75th percentile - 43 connections in 2016, 20 in 2020. At 90th percentile 76 connections in 2016 and 33 in 2020.", + caption="Verdeling van het totale aantal verbindingen per pagina", + description="Een percentielgrafiek van het totale aantal verbindingen, waarin 2016 wordt vergeleken met 2020 op desktop. Het mediane aantal aansluitingen in 2016 is 23, in 2020 13. Op het 10e percentiel, 6 aansluitingen in 2016, 5 in 2020. Op het 25e percentiel, 12 aansluitingen in 2016, 8 in 2020. Op 75e percentiel, 43 aansluitingen in 2016, 20 in 2020. Op 90e percentiel, 76 aansluitingen in 2016 en 33 in 2020.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=17394219&format=interactive", sheets_gid="1432183252", sql_file="measure_number_of_tcp_connections_per_site.sql" ) }} -Figure 22.15 shows how the number of TCP connections per page has reduced in 2020 compared with 2016. Half of all websites now use 13 or fewer TCP connections in 2020 compared with 23 connections in 2016; a 44% decrease. In the same time period the median number of requests has only dropped from 74 to 73. The median number of requests per TCP connection has increased from 3.2 to 5.6. +Figuur 22.15 laat zien hoe het aantal TCP-verbindingen per pagina in 2020 is afgenomen ten opzichte van 2016. De helft van alle websites gebruikt nu 13 of minder TCP-verbindingen in 2020 ten opzichte van 23 verbindingen in 2016; een afname van 44%. In dezelfde periode is het mediaan aantal verzoeken slechts gedaald van 74 naar 73. Het mediaan aantal verzoeken per TCP-verbinding is gestegen van 3,2 naar 5,6. -TCP was designed to maintain an average data flow that is both efficient and fair. Imagine a flow control process where each flow both exerts pressure on and is responsive to all other flows, to provide a fair share of the network. In a fair protocol, every TCP session does not crowd out any other session and over time will take 1/N of the path capacity. +TCP is ontworpen om een gemiddelde gegevensstroom te behouden die zowel efficiënt als eerlijk is. Stelt u een stroomcontroleproces voor waarbij elke stroom zowel druk uitoefent op als reageert op alle andere stromen, om een eerlijk deel van het netwerk te leveren. In een eerlijk protocol verdringt elke TCP-sessie geen enkele andere sessie en zal na verloop van tijd 1/N van de padcapaciteit in beslag nemen. -The majority of websites still open over 15 TCP connections. In HTTP/1.1, the six connections a browser could open to a domain can over time claim six times as much bandwidth as a single HTTP/2 connection. Over low capacity networks, this can slow down the delivery of content from the primary asset domains as the number of contending connections increases and takes bandwidth away from the important requests. This favors websites with a small number of third-party domains. +De meeste websites openen nog steeds meer dan 15 TCP-verbindingen. In HTTP/1.1 kunnen de zes verbindingen die een browser met een domein zou kunnen openen, na verloop van tijd zes keer zoveel bandbreedte claimen als een enkele HTTP/2-verbinding. Bij netwerken met een lage capaciteit kan dit de levering van inhoud van de primaire activadomeinen vertragen naarmate het aantal concurrerende verbindingen toeneemt en bandbreedte wegneemt van de belangrijke verzoeken. Dit is in het voordeel van websites met een klein aantal domeinen van derden. -HTTP/2 does allow for connection reuse across different, but related domains. For a TLS resource, it requires a certificate that is valid for the host in the URI. This can be used to reduce the number of connections required for domains under the control of the site author. +HTTP/2 staat hergebruik van verbindingen toe voor verschillende, maar gerelateerde domeinen. Voor een TLS-bron is een certificaat vereist dat geldig is voor de host in de URI. Dit kan worden gebruikt om het aantal verbindingen te verminderen dat nodig is voor domeinen die onder controle staan van de site-auteur. -### Prioritization +### Prioritering -As HTTP/2 responses can be split into many individual frames, and as frames from multiple streams can be multiplexed, the order in which the frames are interleaved and delivered by the server becomes a critical performance consideration. A typical website consists of many different types of resources: the visible content (HTML, CSS, images), the application logic (JavaScript), ads, analytics for tracking site usage, and marketing tracking beacons. With knowledge of how a browser works, an optimal ordering of the resources can be defined that will result in the fastest user experience. The difference between optimal and non-optimal can be significant—as much as a 50% performance improvement or more! +Omdat HTTP/2-reacties kunnen worden opgesplitst in veel individuele frames en omdat frames uit meerdere streams kunnen worden _gemultiplexed_, wordt de volgorde waarin de frames worden _interleaved_ en geleverd door de server een kritieke prestatie-overweging. Een typische website bestaat uit veel verschillende soorten bronnen: de zichtbare inhoud (HTML, CSS, afbeeldingen), de applicatielogica (JavaScript), advertenties, analyses voor het volgen van sitegebruik en marketing-trackingbakens. Met kennis van hoe een browser werkt, kan een optimale ordening van de bronnen worden gedefinieerd die zal resulteren in de snelste gebruikerservaring. Het verschil tussen optimaal en niet-optimaal kan aanzienlijk zijn - wel 50% prestatieverbetering of meer! -HTTP/2 introduced the concept of prioritization to help the client communicate to the server how it thinks the multiplexing should be done. Every stream is assigned a weight (how much of the available bandwidth the stream should be allocated) and possibly a parent (another stream which should be delivered first). With the flexibility of HTTP/2's prioritization model, it is not altogether surprising that all of the current browser engines implemented different prioritization strategies, none of which are optimal. +HTTP/2 introduceerde het concept van prioritering om de cliënt te helpen communiceren met de server hoe hij denkt dat het multiplexen moet worden uitgevoerd. Aan elke stream wordt een gewicht toegekend (hoeveel van de beschikbare bandbreedte de stream zou moeten worden toegewezen) en mogelijk een ouder (een andere stream die als eerste zou moeten worden afgeleverd). Met de flexibiliteit van het prioriteitsmodel van HTTP/2 is het niet helemaal verrassend dat alle huidige browser-engines verschillende prioriteitsstrategieën hebben geïmplementeerd, die geen van alle optimaal zijn. -There are also problems on the server side, leading to many servers implementing prioritization either poorly or not at all. In the case of HTTP/1.x, tuning the server-side send buffers to be as big as possible has no downside, other than the increase in memory use (trading off memory for CPU), and is an effective way to increase the throughput of a web server. This is not true for HTTP/2, as data in the TCP send buffer cannot be re-prioritized if a request for a new, more important resource comes in. For an HTTP/2 server, the optimal send buffer size is thus the minimum amount of data required to fully utilize the available bandwidth. This allows the server to respond immediately if a higher-priority request is received. +Er zijn ook problemen aan de serverzijde, wat ertoe leidt dat veel servers de prioriteitstelling slecht of helemaal niet implementeren. In het geval van HTTP/1.x heeft het afstemmen van de serverzijde verzendbuffers om zo groot mogelijk te zijn geen nadeel, behalve de toename van het geheugengebruik (inruilen van geheugen voor CPU), en is het een effectieve manier om de doorvoersnelheid van een webserver. Dit geldt niet voor HTTP/2, aangezien gegevens in de TCP-verzendbuffer niet opnieuw geprioriteerd kunnen worden als een verzoek om een nieuwe, belangrijkere bron binnenkomt. Voor een HTTP/2-server is de optimale grootte van de verzendbuffer dus het minimale hoeveelheid data die nodig is om de beschikbare bandbreedte volledig te benutten. Hierdoor kan de server onmiddellijk reageren als een verzoek met een hogere prioriteit wordt ontvangen. -This problem of large buffers messing with (re-)prioritization also exists in the network, where it goes by the name "bufferbloat". Network equipment would rather buffer packets than drop them when there's a short burst. However, if the server sends more data than the path to the client can consume, these buffers fill to capacity. These bytes already "stored" on the network limit the server's ability to send a higher-priority response earlier, just as a large send buffer does. To minimize the amount of data held in buffers, a recent congestion control algorithm such as BBR should be used. +Dit probleem van grote buffers die knoeien met (her)prioritering bestaat ook in het netwerk, waar het de naam "bufferbloat" draagt. Netwerkapparatuur buffert liever pakketten dan ze te laten vallen als er een korte burst is. Als de server echter meer gegevens verzendt dan het pad naar de cliënt kan verbruiken, worden deze buffers volledig gevuld. Deze bytes die al op het netwerk zijn "opgeslagen", beperken het vermogen van de server om eerder een antwoord met een hogere prioriteit te verzenden, net zoals een grote verzendbuffer dat doet. Om de hoeveelheid gegevens in buffers te minimaliseren, zou een recent algoritme voor congestiebeheer, zoals BBR gebruikt moeten worden gebruikt. -This test suite maintained by Andy Davies measures and reports how various CDN and cloud hosting services perform. The bad news is that only 9 of the 36 services prioritize correctly. Figure 22.16 shows that for sites using a CDN, around 31.7% do not prioritize correctly. This is up from 26.82% last year, mainly due to the increase in Google CDN usage. Rather than relying on the browser-sent priorities, there are some servers that implement a server side prioritization scheme instead, improving upon the browser's hints with additional logic. +Deze testsuite die wordt beheerd door Andy Davies, meet en rapporteert hoe verschillende CDN- en cloudhostingservices presteren. Het slechte nieuws is dat slechts 9 van de 36 services de juiste prioriteiten stellen. Figuur 22.16 laat zien dat voor sites die een CDN gebruiken, ongeveer 31,7% niet de juiste prioriteiten stelt. Dit is gestegen van 26,82% vorig jaar, voornamelijk als gevolg van de toename van het Google CDN-gebruik. In plaats van te vertrouwen op de door de browser verzonden prioriteiten, zijn er enkele servers die een prioriteitsschema aan de serverzijde implementeren, waarbij de hints van de browser worden verbeterd met extra logica.
- + - + - - - - + + + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + +
CDNPrioritize
correctly		Prioriteer
correct		 DesktopMobileMobiel
Not using CDNUnknown59.47%60.85%Zonder CDNOnbekend59,47%60,85%
Cloudflare Pass22.03%21.32%22,03%21,32%
Google Fail8.26%8.94%8,26%8,94%
Amazon CloudFront Fail2.64%2.27%2,64%2,27%
Fastly Pass2.34%1.78%2,34%1,78%
Akamai Pass1.31%1.19%1,31%1,19%
Automattic Pass0.93%1.05%0,93%1,05%
Sucuri Firewall Fail0.77%0.63%0,77%0,63%
Incapsula Fail0.42%0.34%0,42%0,34%
Netlify Fail0.27%0.20%0,27%0,20%
-
{{ figure_link(caption="HTTP/2 prioritization support in common CDNs.", sheets_gid="1152953475", sql_file="percentage_of_h2_and_h3_sites_affected_by_cdn_prioritization.sql") }}
+
{{ figure_link(caption="Ondersteuning voor HTTP/2-prioriteitstelling in veelgebruikte CDN's.", sheets_gid="1152953475", sql_file="percentage_of_h2_and_h3_sites_affected_by_cdn_prioritization.sql") }}
-For non-CDN usage, we expect the number of servers that correctly apply HTTP/2 prioritization to be considerably smaller. For example, NodeJS's HTTP/2 implementation [does not support prioritization](https://twitter.com/jasnell/status/1245410283582918657). +Voor niet-CDN-gebruik verwachten we dat het aantal servers dat correct HTTP/2-prioriteitstelling toepast aanzienlijk kleiner zal zijn. De HTTP/2-implementatie van NodeJS [ondersteunt bijvoorbeeld geen prioritering](https://twitter.com/jasnell/status/1245410283582918657). -### Goodbye server push? +### Vaarwel server push? -Server push was one of the additional features of HTTP/2 that caused some confusion and complexity to implement in practice. Push seeks to avoid waiting for a browser/client to download a HTML page, parse that page, and only then discover that it requires additional resources (such as a stylesheet), which in turn have to be fetched and parsed to discover even more dependencies (such as fonts). All that work and round trips takes time. With server push, in theory, the server can just send multiple responses at once, avoiding the extra round trips. +Server push was een van de extra functies van HTTP/2 die voor enige verwarring en complexiteit zorgde om in de praktijk te implementeren. Push probeert te voorkomen dat een browser/cliënt moet wachten om een HTML-pagina te downloaden, die pagina te parsen en pas dan te ontdekken dat er extra bronnen nodig zijn (zoals een stylesheet), die op hun beurt moeten worden opgehaald en geparseerd om nog meer dependencies te ontdekken (zoals lettertypen). Al dat werk en rondreizen kost tijd. Met server push kan de server in theorie gewoon meerdere reacties tegelijk verzenden, waardoor extra roundtrips worden vermeden. -Unfortunately, with TCP congestion control in play, the data transfer starts off so slowly that not all the assets can be pushed until multiple round trips have increased the transfer rate sufficiently. There are also implementation differences between browsers as the client processing model had not been fully agreed. For example, each browser has a different implementation of a _push cache_. +Helaas, met TCP-congestiecontrole in het spel, begint de gegevensoverdracht zo langzaam dat niet alle activa kan worden gepusht totdat meerdere roundtrips de overdrachtssnelheid voldoende hebben verhoogd. Er zijn ook implementatieverschillen tussen browsers als het cliëntverwerkingsmodel niet volledig was overeengekomen. Elke browser heeft bijvoorbeeld een andere implementatie van een _push cache_. -Another issue is that the server is not aware of resources the browser has already cached. When a server tries to push something that is unwanted, the client can send a `RST_STREAM` frame, but by the time this has happened, the server may well have already sent all the data. This wastes bandwidth and the server has lost the opportunity of immediately sending something that the browser actually did require. There were proposals to allow clients to inform the server of their cache status, but these suffered from privacy concerns. +Een ander probleem is dat de server niet weet welke bronnen de browser al in de cache heeft opgeslagen. Wanneer een server iets probeert te pushen dat ongewenst is, kan de cliënt een `RST_STREAM` frame verzenden, maar tegen de tijd dat dit is gebeurd, heeft de server mogelijk al alle gegevens verzonden. Dit verspilt bandbreedte en de server heeft de mogelijkheid verloren om onmiddellijk iets te verzenden dat de browser echt nodig had. Er waren voorstellen om klanten in staat te stellen de server te informeren over hun cachestatus, maar deze leden aan privacyproblemen. -As can be seen from the Figure 20.17 below, a very small percentage of sites use server push. +Zoals te zien is in figuur 20.17 hieronder, gebruikt een zeer klein percentage van de sites server push.
- - + + - + - - + + - + - - - + + + - +
ClientHTTP/2 pagesCliëntHTTP/2 pagina's HTTP/2 (%)gQUIC pagesgQUIC pagina's gQUIC (%)
Desktop44,2570.85%44.2570,85% 2040.04%0,04%
Mobile62,8491.06%Mobiel62.8491,06% 3260.06%0,06%
-
{{ figure_link(caption="Pages using HTTP/2 or gQUIC server push.", sheets_gid="698874709", sql_file="number_of_h2_and_h3_pushed_resources_and_bytes_transferred.sql") }}
+
{{ figure_link(caption="Pagina's die HTTP/2 of gQUIC server push gebruiken.", sheets_gid="698874709", sql_file="number_of_h2_and_h3_pushed_resources_and_bytes_transferred.sql") }}
-Looking further at the distributions for pushed assets in Figures 22.18 and 22.19, half of the sites push 4 or fewer resources with a total size of 140 KB on desktop and 3 or fewer resources with a size of 184 KB on mobile. For gQUIC, desktop is 7 or fewer and mobile 2. The worst offending page pushes _41 assets_ over gQUIC on desktop. +Als we verder kijken naar de verdelingen voor gepushte activa in figuur 22.18 en 22.19, pusht de helft van de sites 4 of minder bronnen met een totale grootte van 140 KB op desktop en 3 of minder bronnen met een grootte van 184 KB op mobiel. Voor gQUIC is desktop 7 of minder en mobiel 2. De ergste beledigende pagina duwt _41 activa_ over gQUIC op desktop.
- + - + - + - + - + - + - + - + - + - + - + - + - +
PercentilePercentiel HTTP/2Size (KB)Grootte (KB) gQUICSize (KB)Grootte (KB)
10 13.953,95 115.8315,83
25 236.3236,32 335.9335,93
50 4139.58139,58 7111.96111,96
75 8346.70346,70 21203.59203,59
90 17440.08440,08 41390.91390,91
-
{{ figure_link(caption="Distribution of pushed assets on desktop.", sheets_gid="698874709", sql_file="number_of_h2_and_h3_pushed_resources_and_bytes_transferred.sql") }}
+
{{ figure_link(caption="Distributie van gepushte middelen op desktop.", sheets_gid="698874709", sql_file="number_of_h2_and_h3_pushed_resources_and_bytes_transferred.sql") }}
- + - + - + - + - + - + - + - + - + - + - + - + - +
PercentilePercentiel HTTP/2Size (KB)Grootte (KB) gQUICSize (KB)Grootte (KB)
10 115.4815,48 10.060,06
25 136.3436,34 10.060,06
50 3183.83183,83 224.0624,06
75 10225.41225,41 5204.65204,65
90 12351.05351,05 18453.57453,57
-
{{ figure_link(caption="Distribution of pushed assets on mobile.", sheets_gid="698874709", sql_file="number_of_h2_and_h3_pushed_resources_and_bytes_transferred.sql") }}
+
{{ figure_link(caption="Distributie van gepushte activa op mobiel.", sheets_gid="698874709", sql_file="number_of_h2_and_h3_pushed_resources_and_bytes_transferred.sql") }}
-Looking at the frequency of push by content type in Figure 22.20, we see 90% of pages push scripts and 56% push CSS. This makes sense, as these can be small files typically on the critical path to render a page. +Als we kijken naar de frequentie van push per inhoudstype in figuur 22.20, zien we 90% van de pagina's scripts pushen en 56% CSS. Dit is logisch, aangezien dit kleine bestanden kunnen zijn die zich doorgaans op het kritieke pad bevinden om een pagina weer te geven. {{ figure_markup( image="http2-pushed-content-types.png", - caption="Percentage of pages pushing specific content types", - description="A bar chart showing for pages that push resources on desktop; 89.1% push scripts, 67.9% css, 6.1% images, 1.3% fonts, 0.7% other and 0.7% html. On mobile 90.29% push scripts, 56.08% css, 3.69% images, 0.97% fonts, 0.36% other and 0.39% html.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=1708672642&format=interactive", + caption="Percentage pagina's dat specifieke inhoudstypen pusht", + description="Een staafdiagram voor pagina's die bronnen op desktop pushen; pusht 89,1% scripts, 67,9% css, 6,1% afbeeldingen, 1,3% lettertypen, 0,7% overige en 0,7% html. Op mobiel pusht 90,29% scripts, 56,08% css, 3,69% afbeeldingen, 0,97% lettertypen, 0,36% overige en 0,39% html.", chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSOkWXtrbMfTLdhlKbBGDjRU3zKbnCQi3iPhfuKaFs5mj4smEzInDCYEnk63gBdgsJ3GFk2gf4FOKCU/pubchart?oid=1708672642&format=interactive", sheets_gid="238923402", sql_file="number_of_h2_and_h3_pushed_resources_and_bytes_by_content_type.sql" ) }} -Given the low adoption, and after measuring how few of the pushed resources are actually useful (that is, they match a request that is not already cached), Google has announced the intent to remove push support from Chrome for both HTTP/2 and gQUIC. Chrome has also not implemented push for HTTP/3. +Gezien de lage acceptatie en na te hebben gemeten hoe weinig van de gepushte bronnen daadwerkelijk nuttig zijn (dat wil zeggen, ze komen overeen met een verzoek dat nog niet in de cache is opgeslagen), heeft Google de intentie om push-ondersteuning van Chrome te verwijderen voor zowel HTTP/2 als gQUIC. Chrome heeft ook geen push geïmplementeerd voor HTTP/3. -Despite all these problems, there are circumstances where server push can provide an improvement. The ideal use case is to be able to send a push promise much earlier than the HTML response itself. A scenario where this can benefit is when a CDN is in use. The "dead time" between the CDN receiving the request and receiving a response from the origin can be used intelligently to warm up the TCP connection and push assets already cached at the CDN. +Ondanks al deze problemen zijn er omstandigheden waarin server push voor verbetering kan zorgen. De ideale use case is om een pushbelofte veel eerder te kunnen verzenden dan de HTML-respons zelf. Een scenario waarin dit kan profiteren is wanneer een CDN in gebruik is. De "dode tijd" tussen het CDN dat het verzoek ontvangt en het ontvangen van een antwoord van de oorsprong kan intelligent worden gebruikt om de TCP-verbinding op te warmen en activa te pushen die al in de cache zijn opgeslagen op het CDN. -There was however no standardized method for how to signal to a CDN edge server that an asset should be pushed. Implementations instead reused the preload HTTP link header to indicate this. This simple approach appears elegant, but it does not utilize the dead time before the HTML is generated unless the headers are sent before the actual content is ready. It triggers the edge to push resources as the HTML is received at the edge, which will contend with the delivery of the HTML. +Er was echter geen gestandaardiseerde methode om aan een CDN-edge-server te signaleren dat een activa moest worden gepusht. Implementaties hebben in plaats daarvan de vooraf geladen HTTP-link-header hergebruikt om dit aan te geven. Deze eenvoudige benadering lijkt elegant, maar maakt geen gebruik van de dode tijd voordat de HTML wordt gegenereerd, tenzij de headers worden verzonden voordat de daadwerkelijke inhoud gereed is. Het triggert de edge om bronnen te pushen wanneer de HTML aan de rand wordt ontvangen, wat zal strijden met de levering van de HTML. -An alternative proposal being tested is RFC 8297, which defines an informative `103 (Early Hints)` response. This permits headers to be sent immediately, without having to wait for the server to generate the full response headers. This can be used by an origin to suggest pushed resources to a CDN, or by a CDN to alert the client to resources that need to be fetched. However, at present, support for this from both a client and server perspective is very low, but growing. +Een alternatief voorstel dat wordt getest, is RFC 8297, dat een informatieve `103 (Early Hints)` reactie definieert . Hierdoor kunnen headers onmiddellijk worden verzonden, zonder dat u hoeft te wachten tot de server de volledige responsheaders heeft gegenereerd. Dit kan worden gebruikt door een oorsprong om gepushte bronnen naar een CDN voor te stellen, of door een CDN om de cliënt te waarschuwen voor bronnen die moeten worden opgehaald. Momenteel is de ondersteuning hiervoor vanuit zowel cliënt- als serverperspectief echter erg laag, maar blijft groeit. -## Getting to a better protocol +## Op weg naar een beter protocol -Let's say a client and server support both HTTP/1.1 and HTTP/2. How do they choose which one to use? The most common method is TLS [Application Layer Protocol Negotiation](https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation) (ALPN), in which clients send a list of protocols they support to the server, which picks the one it prefers to use for that connection. Because the browser needs to negotiate the TLS parameters as part of setting up an HTTPS connection, it can also negotiate the HTTP version at the same time. Since both HTTP/2 and HTTP/1.1 can be served from the same TCP port (443), browsers don't need to make this selection before opening a connection. +Laten we zeggen dat een cliënt en server zowel HTTP/1.1 als HTTP/2 ondersteunen. Hoe kiezen ze welke ze willen gebruiken? De meest gebruikelijke methode is TLS [Application Layer Protocol Negotiation](https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation) (ALPN), waarbij cliënten een lijst met protocollen die ze ondersteunen naar de server sturen, die kiest voor degene die het bij voorkeur gebruikt voor die verbinding. Omdat de browser moet onderhandelen over de TLS-parameters als onderdeel van het opzetten van een HTTPS-verbinding, kan hij tegelijkertijd ook onderhandelen over de HTTP-versie. Omdat zowel HTTP/2 als HTTP/1.1 kunnen worden bediend vanaf dezelfde TCP-poort (443), hoeven browsers deze selectie niet te maken voordat een verbinding wordt geopend. -This doesn't work if the protocols aren't on the same port, use a different transport protocol (TCP versus QUIC), or if you're not using TLS. For those scenarios, you start with whatever is available on the first port you connect to, then discover other options. HTTP defines two mechanisms to change protocols for an origin after connecting: `Upgrade` and `Alt-Svc`. +Dit werkt niet als de protocollen zich niet op dezelfde poort bevinden, een ander transportprotocol gebruiken (TCP versus QUIC) of als u geen TLS gebruikt. Voor die scenario's begint u met alles wat beschikbaar is op de eerste poort waarmee u verbinding maakt en ontdekt u vervolgens andere opties. HTTP definieert twee mechanismen om protocollen voor een oorsprong te wijzigen na verbinding: `Upgrade` en `Alt-Svc`. ### `Upgrade` -The Upgrade header has been part of HTTP for a long time. In HTTP/1.x, `Upgrade` allows a client to make a request using one protocol, but indicate its support for another protocol (like HTTP/2). If the server also supports the offered protocol, it responds with a status 101 (`Switching Protocols`) and proceeds to answer the request in the new protocol. If not, the server answers the request in HTTP/1.x. Servers can advertise their support of a different protocol using an `Upgrade` header on a response. +De Upgrade-header maakt al lange tijd deel uit van HTTP. In HTTP/1.x staat `Upgrade` een cliënt toe om een verzoek in te dienen met behulp van één protocol, maar de ondersteuning voor een ander protocol aan te geven (zoals HTTP/2). Als de server ook het aangeboden protocol ondersteunt, reageert deze met status 101 (`Switching Protocols`) en gaat verder met het beantwoorden van het verzoek in het nieuwe protocol. Als dit niet het geval is, beantwoordt de server het verzoek in HTTP/1.x. Servers kunnen hun ondersteuning van een ander protocol adverteren met behulp van een `Upgrade`-header bij een antwoord. -The most common application of `Upgrade` is [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API). HTTP/2 also defines an `Upgrade` path, for use with its unencrypted cleartext mode. There is no support for this capability in web browsers, however. Therefore, it's not surprising that less than 3% of cleartext HTTP/1.1 requests in our dataset received an `Upgrade` header in the response. A very small number of requests using TLS (0.0011% of HTTP/2, 0.064% of HTTP/1.1) also received `Upgrade` headers in response; these are likely cleartext HTTP/1.1 servers behind intermediaries which speak HTTP/2 and/or terminate TLS, but don't properly remove `Upgrade` headers. +De meest voorkomende toepassing van `Upgrade` is [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API). HTTP/2 definieert ook een `Upgrade`-pad, voor gebruik met zijn niet-versleutelde cleartext-modus. Er is echter geen ondersteuning voor deze mogelijkheid in webbrowsers. Daarom is het niet verwonderlijk dat minder dan 3% van de cleartext HTTP/1.1-verzoeken in onze dataset een `Upgrade`-header in het antwoord ontving. Een zeer klein aantal verzoeken met behulp van TLS (0,0011% van HTTP/2, 0,064% van HTTP/1.1) ontving ook `Upgrade`-headers als reactie; dit zijn waarschijnlijk duidelijke HTTP/1.1-servers achter tussenpersonen die HTTP/2 spreken en/of TLS beëindigen, maar de `Upgrade`-headers niet correct verwijderen. ### Alternative Services -Alternative Services (`Alt-Svc`) enables an HTTP origin to indicate other endpoints which serve the same content, possibly over different protocols. Although uncommon, HTTP/2 might be located at a different port or different host from a site's HTTP/1.1 service. More importantly, since HTTP/3 uses QUIC (hence UDP) where prior versions of HTTP use TCP, HTTP/3 will always be at a different endpoint from the HTTP/1.x and HTTP/2 service. +Alternative Services (`Alt-Svc`) stelt een HTTP-oorsprong in staat om andere eindpunten aan te duiden die dezelfde inhoud bedienen, mogelijk via verschillende protocollen. Hoewel ongebruikelijk, kan HTTP/2 zich op een andere poort of een andere host bevinden dan de HTTP/1.1-service van een site. Wat nog belangrijker is, aangezien HTTP/3 QUIC gebruikt (vandaar UDP) waar eerdere versies van HTTP TCP gebruiken, zal HTTP/3 zich altijd op een ander eindpunt bevinden dan de HTTP/1.x- en HTTP/2-service. -When using `Alt-Svc`, a client makes requests to the origin as normal. However, if the server includes a header or sends a frame containing a list of alternatives, the client can make a new connection to the other endpoint and use it for future requests to that origin. +Bij gebruik van `Alt-Svc`, doet een cliënt zoals normaal verzoeken aan de oorsprong. Als de server echter een header bevat of een frame met een lijst met alternatieven verzendt, kan de cliënt een nieuwe verbinding maken met het andere eindpunt en deze gebruiken voor toekomstige verzoeken naar die oorsprong. -Unsurprisingly, `Alt-Svc` usage is found almost entirely from services using advanced HTTP versions: 12.0% of HTTP/2 requests and 60.1% of gQUIC requests received an `Alt-Svc` header in response, as compared to 0.055% of HTTP/1.x requests. Note that our methodology here only captures `Alt-Svc` headers, not `ALTSVC` frames in HTTP/2, so reality might be slightly understated. +Het is niet verwonderlijk dat het gebruik van `Alt-Svc` bijna volledig wordt gevonden in services die geavanceerde HTTP-versies gebruiken: 12,0% van de HTTP/2-verzoeken en 60,1% van de gQUIC-verzoeken ontving een `Alt-Svc`-header als reactie, in vergelijking met 0,055% van HTTP/1.x-verzoeken. Merk op dat onze methodologie hier alleen `Alt-Svc`-headers vastlegt, niet `ALTSVC`-frames in HTTP/2, dus de realiteit kan enigszins onderschat zijn. -While `Alt-Svc` can point to an entirely different host, support for this capability varies among browsers. Only 4.71% of `Alt-Svc` headers advertised an endpoint on a different hostname; these were almost universally (99.5%) advertising gQUIC and HTTP/3 support on Google Ads. Google Chrome ignores cross-host `Alt-Svc` advertisements for HTTP/2, so many of the other instances would have been ignored. +Hoewel `Alt-Svc` naar een geheel andere host kan verwijzen, verschilt de ondersteuning voor deze mogelijkheid per browser. Slechts 4,71% van de `Alt-Svc` headers adverteerde een eindpunt op een andere hostnaam; dit waren bijna universeel (99,5%) advertenties voor gQUIC- en HTTP/3-ondersteuning op Google Ads. Google Chrome negeert cross-host `Alt-Svc`-advertenties voor HTTP/2, dus veel van de andere instanties zouden zijn genegeerd. -Given the rarity of support for cross-host HTTP/2, it's not surprising that there were virtually no (0.007%) advertisements for HTTP/2 endpoints using `Alt-Svc`. `Alt-Svc` was typically used to indicate support for HTTP/3 (74.6% of `Alt-Svc` headers) or gQUIC (38.7% of `Alt-Svc` headers). +Gezien de zeldzaamheid van ondersteuning voor cross-host HTTP/2, is het niet verwonderlijk dat er vrijwel geen (0,007%) advertenties waren voor HTTP/2-eindpunten met behulp van `Alt-Svc`. `Alt-Svc` werd typisch gebruikt om ondersteuning voor HTTP/3 (74,6% van `Alt-Svc` headers) of gQUIC (38,7% van `Alt-Svc` headers) aan te geven. -## Looking toward the future: HTTP/3 +## Kijkend naar de toekomst: HTTP/3 -HTTP/2 is a powerful protocol, which has found considerable adoption in just a few years. However, HTTP/3 over QUIC is already peeking around the corner! Over four years in the making, this next version of HTTP is almost standardized at the IETF (expected in the first half of 2021). At this time, there are already many QUIC and HTTP/3 implementations available, both for servers and browsers. While these are relatively mature, they can still be said to be in an experimental state. +HTTP/2 is een krachtig protocol dat in slechts een paar jaar tijd aanzienlijk is toegepast. HTTP/3 over QUIC gluurt echter al om de hoek! Na meer dan vier jaar in de maak is deze volgende versie van HTTP bijna gestandaardiseerd op de IETF (verwacht in de eerste helft van 2021). Op dit moment zijn er al veel QUIC- en HTTP/3-implementaties beschikbaar, beide voor servers en browsers. Hoewel deze relatief volwassen zijn, kan nog steeds worden gezegd dat ze zich in een experimentele staat bevinden. -This is reflected by the usage numbers in the HTTP Archive data, where no HTTP/3 requests were identified at all. This might seem a bit strange, since Cloudflare has had experimental HTTP/3 support for some time, as have Google and Facebook. This is mainly because Chrome hadn't enabled the protocol by default when the data was collected. +Dit wordt weerspiegeld door de gebruiksnummers in de HTTP Archive-gegevens, waar helemaal geen HTTP/3-verzoeken werden geïdentificeerd. Dit lijkt misschien een beetje vreemd, aangezien Cloudflare al enige tijd experimentele HTTP/3-ondersteuning heeft, net als Google en Facebook. Dit komt voornamelijk omdat Chrome het protocol niet standaard had ingeschakeld toen de gegevens werden verzameld. -However, even the numbers for the older gQUIC are relatively modest, accounting for less than 2% of requests overall. This is expected, since gQUIC was mostly deployed by Google and Akamai; other parties were waiting for IETF QUIC. As such, gQUIC is expected to be replaced entirely by HTTP/3 soon. +Maar zelfs de cijfers voor de oudere gQUIC zijn relatief bescheiden, goed voor minder dan 2% van de verzoeken in totaal. Dit wordt verwacht, aangezien gQUIC grotendeels werd ingezet door Google en Akamai; andere partijen wachtten op IETF QUIC. Als zodanig wordt verwacht dat gQUIC binnenkort volledig wordt vervangen door HTTP/3. {{ figure_markup( - caption="The percentage of requests that use gQUIC on desktop and mobile", - content="1.72%", + caption="Het percentage verzoeken dat gQUIC gebruikt op desktop en mobiel", + content="1,72%", classes="big-number", sheets_gid="2122693316", sql_file="adoption_of_http_2_by_site_and_requests.sql" ) }} -It's important to note that this low adoption only reflects gQUIC and HTTP/3 usage for loading Web pages. For several years already, Facebook has had a much more extensive deployment of IETF QUIC and HTTP/3 for loading data inside of its native applications. QUIC and HTTP/3 already make up over 75% of their total internet traffic. It is clear that HTTP/3 is only just getting started! +Het is belangrijk op te merken dat deze lage acceptatie alleen het gebruik van gQUIC en HTTP/3 voor het laden van webpagina's weerspiegelt. Facebook heeft al een aantal jaren een veel uitgebreider gebruik van IETF QUIC en HTTP/3 voor het laden van gegevens in zijn eigen applicaties. QUIC en HTTP/3 maken al meer dan 75% van hun totale internetverkeer uit. Het is duidelijk dat HTTP/3 nog maar net is begonnen! -Now you might wonder: if not everyone is already using HTTP/2, why would we need HTTP/3 so soon? What benefits can we expect in practice? Let's take a closer look at its internal mechanisms. +Nu vraagt u u misschien af: als niet iedereen al HTTP/2 gebruikt, waarom zouden we dan zo snel HTTP/3 nodig hebben? Welke voordelen kunnen we in de praktijk verwachten? Laten we de interne mechanismen eens nader bekijken. -### QUIC and HTTP/3 +### QUIC en HTTP/3 -Past attempts to deploy new transport protocols on the internet have proven difficult, for example [Stream Control Transmission Protocol](https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol) (SCTP). QUIC is a new transport protocol that runs on top of UDP. It provides similar features to TCP, such as reliable in-order delivery and congestion control to prevent flooding the network. +Eerdere pogingen om nieuwe transportprotocollen op internet in te zetten zijn moeilijk gebleken, bijvoorbeeld [Stream Control Transmission Protocol](https://nl.wikipedia.org/wiki/Stream_Control_Transmission_Protocol) (SCTP). QUIC is een nieuw transportprotocol dat bovenop UDP draait. Het biedt vergelijkbare functies als TCP, zoals betrouwbare levering op volgorde en congestiecontrole om overstroming van het netwerk te voorkomen. -As discussed in the [HTTP/1.0 to HTTP/2](#http10-to-http2) section, HTTP/2 _multiplexes_ multiple different streams on top of one connection. TCP itself is woefully unaware of this fact, leading to inefficiencies or performance impact when packet loss or delays occur. More details on this problem, known as _head-of-line blocking_ (HOL blocking), can be found here. +Zoals besproken in de sectie [HTTP/1.0 tot HTTP/2](#http10-naar-http2), HTTP/2 _multiplext_ meerdere verschillende streams bovenop één verbinding. TCP zelf is zich hier jammerlijk niet van bewust, wat leidt tot inefficiënties of invloed op de prestaties wanneer pakketverlies of vertragingen optreden. Meer informatie over dit probleem, bekend als _head-of-line blocking_ (HOL-blokkering), is hier te vinden. -QUIC solves the HOL blocking problem by bringing HTTP/2's streams down into the transport layer and performing per-stream loss detection and retransmission. So then we just put HTTP/2 over QUIC, right? Well, we've [already mentioned](#reducing-connections) some of the difficulties arising from having flow control in TCP and HTTP/2. Running two separate and competing streaming systems on top of each other would be an additional problem. Furthermore, because the QUIC streams are independent, it would mess with the strict ordering requirements HTTP/2 requires for several of its systems. +QUIC lost het HOL-blokkeerprobleem op door HTTP/2-streams naar de transportlaag te brengen en verliesdetectie en hertransmissie per stream uit te voeren. Dus dan zetten we HTTP/2 gewoon over QUIC, toch? Welnu, we hebben enkele van de moeilijkheden die ontstaan door het hebben van flow control in TCP en HTTP/2 [al genoemd](#verbindingen-verminderen). Het zou een bijkomend probleem zijn om twee afzonderlijke en concurrerende streaming-systemen op elkaar te laten draaien. Bovendien, omdat de QUIC-streams onafhankelijk zijn, zou het knoeien met de strikte bestelvereisten die HTTP/2 vereist voor verschillende van zijn systemen. -In the end, it was deemed easier to define a new HTTP version that uses QUIC directly and thus, HTTP/3 was born. Its high-level features are very similar to those we know from HTTP/2, but internal implementation mechanisms are quite different. HPACK header compression is replaced with QPACK, which allows manual tuning of the compression efficiency versus HOL blocking risk tradeoff, and the prioritization system is being replaced by a simpler one. The latter could also be back-ported to HTTP/2, possibly helping resolve the prioritization issues discussed earlier in this article. HTTP/3 continues to provide a server push mechanism, but Chrome, for example, does not implement it. +Uiteindelijk werd het gemakkelijker geacht om een nieuwe HTTP-versie te definiëren die QUIC direct gebruikt en zo werd HTTP/3 geboren. De functies op hoog niveau lijken erg op die we kennen van HTTP/2, maar de interne implementatiemechanismen zijn behoorlijk verschillend. HPACK-headercompressie is vervangen door QPACK, waardoor handmatige afstemming van de afweging tussen compressie-efficiëntie en HOL-blokkeerrisico, en de prioriteitstelling systeem wordt vervangen door een eenvoudigere. Dit laatste kan ook worden teruggevoerd naar HTTP/2, wat mogelijk helpt bij het oplossen van de prioriteitsproblemen die eerder in dit artikel zijn besproken. HTTP/3 blijft een server-push-mechanisme bieden, maar Chrome implementeert het bijvoorbeeld niet. -Another benefit of QUIC is that it is able to migrate connections and keep them alive even when the underlying network changes. A typical example is the so-called "parking lot problem". Imagine your smartphone is connected to the workplace Wi-Fi network and you've just started downloading a large file. As you leave Wi-Fi range, your phone automatically switches to the fancy new 5G cellular network. With plain old TCP, the connection would break and cause an interruption. But QUIC is smarter; it uses a _connection ID_, which is more robust to network changes, and provides an active _connection migration_ feature for clients to switch without interruption. +Een ander voordeel van QUIC is dat het in staat is om verbindingen te migreren en ze in leven te houden, zelfs wanneer het onderliggende netwerk verandert. Een typisch voorbeeld is het zogenaamde "parkeerprobleem". Stelt u voor dat uw smartphone is verbonden met het wifi-netwerk op de werkplek en dat u net bent begonnen met het downloaden van een groot bestand. Als u het Wi-Fi-bereik verlaat, schakelt uw telefoon automatisch over naar het mooie nieuwe mobiele 5G-netwerk. Met gewoon oud TCP zou de verbinding verbreken en een onderbreking veroorzaken. Maar QUIC is slimmer; het gebruikt een _connection ID_, die robuuster is voor netwerkveranderingen, en biedt een actieve _connection migratie_ functie voor cliënten om zonder onderbreking te schakelen. -Finally, TLS is already used to protect HTTP/1.1 and HTTP/2. QUIC, however, has a deep integration of TLS 1.3, protecting both HTTP/3 data and QUIC packet metadata, such as packet numbers. Using TLS in this way improves end-user privacy and security and makes continued protocol evolution easier. Combining the transport and cryptographic handshakes means that connection setup takes just a single RTT, compared to TCP's minimum of two and worst case of four. In some cases, QUIC can even go one step further and send HTTP data along with its very first message, which is called _0-RTT_. These fast connection setup times are expected to really help HTTP/3 outperform HTTP/2. +Ten slotte wordt TLS al gebruikt om HTTP/1.1 en HTTP/2 te beschermen. QUIC heeft echter een diepe integratie van TLS 1.3, waardoor zowel HTTP/3-gegevens als QUIC-pakketmetagegevens, zoals pakketnummers, worden beschermd. Door TLS op deze manier te gebruiken, wordt de privacy en beveiliging van de eindgebruiker verbeterd en wordt de voortdurende evolutie van het protocol eenvoudiger. De combinatie van transport en cryptografische handshakes betekent dat het opzetten van een verbinding slechts één RTT vereist, vergeleken met het minimum van twee van TCP en het slechtste geval van vier. In sommige gevallen kan QUIC zelfs nog een stap verder gaan en HTTP-gegevens verzenden samen met het allereerste bericht, genaamd _0-RTT_. Van deze snelle verbindingstijden wordt verwacht dat ze HTTP/3 echt helpen beter te presteren dan HTTP/2. -**So, will HTTP/3 help?** +**Dus, zal HTTP/3 helpen?** -On the surface, HTTP/3 is really not all that different from HTTP/2. It doesn't add any major features, but mainly changes how the existing ones work under the surface. The real improvements come from QUIC, which offers faster connection setups, increased robustness, and resilience to packet loss. As such, HTTP/3 is expected to do better than HTTP/2 on worse networks, while offering very similar performance on faster systems. However, that is if the web community can get HTTP/3 working, which can be challenging in practice. +Op het eerste gezicht verschilt HTTP/3 niet zo heel veel van HTTP/2. Het voegt geen belangrijke functies toe, maar verandert voornamelijk hoe de bestaande onder de oppervlakte werken. De echte verbeteringen zijn afkomstig van QUIC, dat snellere verbindingsopstellingen, grotere robuustheid en veerkracht bij pakketverlies biedt. Als zodanig wordt verwacht dat HTTP/3 het beter doet dan HTTP/2 op slechtere netwerken, terwijl het vergelijkbare prestaties biedt op snellere systemen. Als de webgemeenschap echter HTTP/3 kan laten werken, kan dat in de praktijk een uitdaging zijn. -### Deploying and discovering HTTP/3 +### HTTP/3 implementeren en ontdekken -Since QUIC and HTTP/3 run over UDP, things aren't as simple as with HTTP/1.1 or HTTP/2. Typically, an HTTP/3 client has to first discover that QUIC is available at the server. The recommended method for this is [HTTP Alternative Services](#alternative-services) . On its first visit to a website, a client connects to a server using TCP. It then discovers via `Alt-Svc` that HTTP/3 is available, and can set up a new QUIC connection. The `Alt-Svc` entry can be cached, allowing subsequent visits to avoid the TCP step, but the entry will eventually become stale and need revalidation. This likely will have to be done for each domain separately, which will probably lead to most page loads using a mix of HTTP/1.1, HTTP/2, and HTTP/3. +Omdat QUIC en HTTP/3 over UDP draaien, is het niet zo eenvoudig als met HTTP/1.1 of HTTP/2. Meestal moet een HTTP/3-cliënt eerst ontdekken dat QUIC beschikbaar is op de server. De aanbevolen methode hiervoor is [HTTP Alternative Services](#alternative-services). Bij het eerste bezoek aan een website maakt een cliënt via TCP verbinding met een server. Het ontdekt dan via `Alt-Svc` dat HTTP/3 beschikbaar is, en kan een nieuwe QUIC-verbinding opzetten. De `Alt-Svc`-vermelding kan in de cache worden opgeslagen, waardoor volgende bezoeken de TCP-stap kunnen vermijden, maar de vermelding zal uiteindelijk verouderd worden en moet opnieuw worden gevalideerd. Dit zal waarschijnlijk voor elk domein afzonderlijk moeten worden gedaan, wat waarschijnlijk zal leiden tot het laden van de meeste pagina's met een combinatie van HTTP/1.1, HTTP/2 en HTTP/3. -However, even if it is known that a server supports QUIC and HTTP/3, the network in between might block it. UDP traffic is commonly used in DDoS attacks and blocked by default in for example many company networks. While exceptions could be made for QUIC, its encryption makes it difficult for firewalls to assess the traffic. There are potential solutions to these issues, but in the meantime it is expected that QUIC is most likely to succeed on well-known ports like 443. And it is entirely possible that it is blocked QUIC altogether. In practice, clients will likely use sophisticated mechanisms to fall back to TCP if QUIC fails. One option is to "race" both a TCP and QUIC connection and use the one that completes first. +Maar zelfs als bekend is dat een server QUIC en HTTP/3 ondersteunt, kan het netwerk ertussen het blokkeren. UDP-verkeer wordt veel gebruikt bij DDoS-aanvallen en wordt standaard geblokkeerd in bijvoorbeeld veel bedrijfsnetwerken. Hoewel er uitzonderingen kunnen worden gemaakt voor QUIC, maakt de versleuteling ervan het moeilijk voor firewalls om het verkeer te beoordelen. Er zijn mogelijke oplossingen voor deze problemen, maar in de tussentijd wordt verwacht dat QUIC het meest waarschijnlijk zal slagen op bekende poorten zoals 443. En het is heel goed mogelijk dat QUIC helemaal wordt geblokkeerd. In de praktijk zullen klanten waarschijnlijk geavanceerde mechanismen gebruiken om terug te vallen op TCP als QUIC faalt. Een optie is om zowel een TCP- als een QUIC-verbinding te "racen" en degene te gebruiken die het eerst voltooit. -There is ongoing work to define ways to discover HTTP/3 without needing the TCP step. This should be considered an optimization, though, as the UDP blocking issues are likely to mean that TCP-based HTTP sticks around. The HTTPS DNS record is similar to HTTP Alternative Services and some CDNs are already experimenting with these records. In the long run, when most servers offer HTTP/3, browsers might switch to attempting that by default; that will take a long time. +Er wordt gewerkt aan het definiëren van manieren om HTTP/3 te ontdekken zonder dat de TCP-stap nodig is. Dit moet echter als een optimalisatie worden beschouwd, omdat de problemen met het blokkeren van UDP waarschijnlijk betekenen dat op TCP gebaseerde HTTP blijft hangen. De HTTPS DNS-record is vergelijkbaar met HTTP Alternative Services en sommige CDN's zijn al aan het experimenteren met deze records. Op de lange termijn, wanneer de meeste servers HTTP/3 aanbieden, kunnen browsers overschakelen naar een standaard poging dat te doen; dat zal lang duren.
-| TLS version | HTTP/1.x
desktop | HTTP/1.x
mobile | HTTP/2
desktop | HTTP/2
mobile | +| TLS versie | HTTP/1.x
desktop | HTTP/1.x
mobiel | HTTP/2
desktop | HTTP/2
mobiel | | ------------ | ------ | ------ | ---- | -----| -| unknown | 4.06% | 4.03% | 5.05% | 7.28% | -| TLS 1.2 | 26.56% | 24.75% | 23.12% | 23.14% | -| TLS 1.3 | 5.25% | 5.11% | 35.78% | 35.54% | +| onbekend | 4,06% | 4,03% | 5,05% | 7,28% | +| TLS 1.2 | 26,56% | 24,75% | 23,12% | 23,14% | +| TLS 1.3 | 5,25% | 5,11% | 35,78% | 35,54% | -
{{ figure_link(caption="TLS adoption by HTTP version.", sheets_gid="900140630", sql_file="tls_adoption_by_http_version.sql") }}
+
{{ figure_link(caption="TLS-acceptatie door HTTP-versie.", sheets_gid="900140630", sql_file="tls_adoption_by_http_version.sql") }}
-QUIC is dependent on TLS 1.3, which is used for around 41% of requests, as shown in Figure 22.21. That leaves 59% of requests that will need to update their TLS stack to support HTTP/3. +QUIC is afhankelijk van TLS 1.3, dat wordt gebruikt voor ongeveer 41% van de verzoeken, zoals weergegeven in figuur 22.21. Dat laat 59% van de verzoeken over die hun TLS-stack moeten bijwerken om HTTP/3 te ondersteunen. -### Is HTTP/3 ready yet? +### Is HTTP/3 al klaar? -So, when can we start using HTTP/3 and QUIC for real? Not quite yet, but hopefully soon. There is a large number of mature open source implementations and the major browsers have experimental support. However, most of the typical servers have suffered some delays: nginx is a bit behind other stacks, Apache hasn't announced official support, and NodeJS relies on OpenSSL, which won't add QUIC support anytime soon. Even so, we expect to see HTTP/3 and QUIC deployments rise throughout 2021. +Dus, wanneer kunnen we HTTP/3 en QUIC echt gaan gebruiken? Nog niet helemaal, maar hopelijk binnenkort. Er is een groot aantal volwassen open source-implementaties en de belangrijkste browsers hebben experimentele ondersteuning. De meeste typische servers hebben echter wat vertraging opgelopen: nginx loopt een beetje achter op andere stacks, Apache heeft geen officiële ondersteuning aangekondigd en NodeJS vertrouwt op OpenSSL, dat binnenkort geen QUIC-ondersteuning zal toevoegen. Toch verwachten we dat het aantal HTTP/3- en QUIC-implementaties in 2021 zal toenemen. -HTTP/3 and QUIC are highly advanced protocols with powerful performance and security features, such as a new HTTP prioritization system, HOL blocking removal, and 0-RTT connection establishment. This sophistication also makes them difficult to deploy and use correctly, as has turned out to be the case for HTTP/2. We predict that early deployments will mainly be done via the early adoption of CDNs such as Cloudflare, Fastly, and Akamai. This will probably mean that a large part of HTTP/2 traffic can and will be upgraded to HTTP/3 automatically in 2021, giving the new protocol a large traffic share almost out of the box. When and if smaller deployments will follow suit is more difficult to answer. Most likely, we will continue to see a healthy mix of HTTP/3, HTTP/2, and even HTTP/1.1 on the web for years to come. +HTTP/3 en QUIC zijn zeer geavanceerde protocollen met krachtige prestatie- en beveiligingsfuncties, zoals een nieuw HTTP-prioriteitssysteem, verwijdering van HOL-blokkering en het tot stand brengen van 0-RTT-verbindingen. Deze verfijning maakt het ook moeilijk om ze correct te implementeren en te gebruiken, zoals het geval is gebleken voor HTTP/2. We voorspellen dat vroege implementaties voornamelijk zullen plaatsvinden via de vroege acceptatie van CDN's zoals Cloudflare, Fastly en Akamai. Dit zal waarschijnlijk betekenen dat een groot deel van het HTTP/2-verkeer in 2021 automatisch kan en zal worden geüpgraded naar HTTP/3, waardoor het nieuwe protocol bijna uit de doos een groot verkeersaandeel krijgt. Wanneer en of kleinere implementaties zullen volgen, is moeilijker te beantwoorden. Hoogstwaarschijnlijk zullen we de komende jaren een gezonde mix van HTTP/3, HTTP/2 en zelfs HTTP/1.1 op internet blijven zien. -## Conclusion +## Gevolgtrekking -This year, HTTP/2 has become the dominant protocol, serving 64% of all requests, having grown by 10 percentage points during the year. Home pages have seen a 13% increase in HTTP/2 adoption, leading to an even split of pages served over HTTP/1.1 and HTTP/2. Using a CDN to serve your home page pushes HTTP/2 adoption up to 80%, compared with 30% for non-CDN usage. There remain some older servers, Apache and IIS, that are proving resistant to upgrading to HTTP/2 and TLS. A big success has been the decrease in website connection usage due to HTTP/2 connection multiplexing. The median number of connections in 2016 was 23 compared to 13 in 2020. +Dit jaar is HTTP/2 het dominante protocol geworden, dat 64% van alle verzoeken bedient, en in de loop van het jaar met 10 procentpunten is gegroeid. Startpagina's hebben een toename van 13% in HTTP/2-acceptatie gezien, wat heeft geleid tot een gelijkmatige opsplitsing van pagina's die worden bediend via HTTP/1.1 en HTTP/2. Het gebruik van een CDN om uw startpagina te bedienen, verhoogt de acceptatie van HTTP/2 tot 80%, vergeleken met 30% voor niet-CDN-gebruik. Er zijn nog enkele oudere servers, Apache en IIS, die resistent blijken te zijn tegen upgraden naar HTTP/2 en TLS. Een groot succes is de afname van het gebruik van websiteverbindingen als gevolg van HTTP/2-verbindingsmultiplexing. Het mediane aantal aansluitingen in 2016 was 23 ten opzichte van 13 in 2020. -HTTP/2 prioritization and server push have turned out to be way more complex to deploy at large. Under certain implementations they show clear performance benefits. There is, however, a significant barrier to deploying and tuning existing servers to use these features effectively. There are still a large proportion of CDNs who do not support prioritization effectively. There have also been issues with consistent browser support. +HTTP/2-prioriteitstelling en server push zijn veel complexer gebleken om in het algemeen te implementeren. Bij bepaalde implementaties laten ze duidelijke prestatievoordelen zien. Er is echter een aanzienlijke belemmering voor het inzetten en afstemmen van bestaande servers om deze functies effectief te gebruiken. Er is nog steeds een groot deel van de CDN's die het stellen van prioriteiten niet effectief ondersteunen. Er zijn ook problemen met consistente browserondersteuning. -HTTP/3 is just around the corner. It will be fascinating to follow the adoption rate, see how discovery mechanisms evolve, and find out which new features will be deployed successfully. We expect next year's Web Almanac to see some interesting new data. +HTTP/3 is net om de hoek. Het zal fascinerend zijn om de acceptatiegraad te volgen, te zien hoe ontdekkingsmechanismen evolueren en erachter te komen welke nieuwe functies met succes zullen worden geïmplementeerd. We verwachten dat de Web Almanac van volgend jaar interessante nieuwe gegevens zal bevatten. diff --git a/src/content/nl/2020/mobile-web.md b/src/content/nl/2020/mobile-web.md index 523d6cd2c36..a5e70cbf345 100644 --- a/src/content/nl/2020/mobile-web.md +++ b/src/content/nl/2020/mobile-web.md @@ -390,7 +390,7 @@ De laatste fase in de reis is gebruikersbehoud, dit betekent de gebruiker opnieu #### Installeerbaarheid met PWA -Terugkerende gebruikers profiteren van een native app-achtige ervaring met een [PWA](./pwa). Een belangrijk waardevoorstel voor gebruikersbehoud is de installeerbaarheid van een PWA. Wanneer een PWA is geïnstalleerd, is deze beschikbaar vanaf de plaatsen waar een mobiele gebruiker een app verwacht te vinden: het homescherm en de app-lade. Wanneer de gebruiker op de PWA tikt en deze start, wordt deze op volledig scherm geladen en is deze beschikbaar in de taakwisselaar, net als een native app. +Terugkerende gebruikers profiteren van een native app-achtige ervaring met een [PWA](./pwa). Een belangrijk waardevoorstel voor gebruikersbehoud is de installeerbaarheid van een PWA. Wanneer een PWA is geïnstalleerd, is deze beschikbaar vanaf de plaatsen waar een mobiele gebruiker een app verwacht te vinden: het startscherm en de app-lade. Wanneer de gebruiker op de PWA tikt en deze start, wordt deze op volledig scherm geladen en is deze beschikbaar in de taakwisselaar, net als een native app. Rakuten 24 is een online winkel van Rakuten, een van de grootste e-commercebedrijven in Japan. Een recente casestudy met Rakuten 24 toonde aan dat het maken van hun webapp installeerbaar, resulteerde in maar liefst 450% in bezoekersbehoud in vergelijking met de vorige mobiele webstroom, over een periode van 1 maand . diff --git a/src/content/nl/2020/pwa.md b/src/content/nl/2020/pwa.md index 02e909c9c63..78b3d42122f 100644 --- a/src/content/nl/2020/pwa.md +++ b/src/content/nl/2020/pwa.md @@ -144,7 +144,7 @@ Een snelle pag Als u een progressieve web-app bouwt, overweeg dan om een service worker te gebruiken zodat uw app offline kan werken, 0,92% van de pagina's was offline gereed. -Browsers kunnen gebruikers proactief vragen om uw app aan hun startscherm toe te voegen, wat kan leiden tot een grotere betrokkenheid. 2,21% van de pagina's had een installeerbaar manifest. Manifest speelt een belangrijke rol bij het starten van de applicatie, het uiterlijk en gevoel van het icoon op het homescherm en als direct impact op de betrokkenheidspercentage. +Browsers kunnen gebruikers proactief vragen om uw app aan hun startscherm toe te voegen, wat kan leiden tot een grotere betrokkenheid. 2,21% van de pagina's had een installeerbaar manifest. Manifest speelt een belangrijke rol bij het starten van de applicatie, het uiterlijk en gevoel van het icoon op het startscherm en als direct impact op de betrokkenheidspercentage. Alle sites moeten worden beschermd met HTTPS, zelfs sites die geen gevoelige gegevens verwerken. Dit omvat het vermijden van gemengde inhoud, waar sommige bronnen via HTTP worden geladen ondanks dat het eerste verzoek via HTTPS wordt bediend. HTTPS voorkomt dat indringers knoeien met of passief luisteren naar de communicatie tussen uw app en uw gebruikers en is een vereiste voor service workers en veel nieuwe webplatformfuncties en API's zoals [HTTP/2](./http2). De is-on-https-check laat zien dat 67,27% van de sites op HTTPS was zonder gemengde inhoud en het is verrassend dat we nog niet hoger zijn gekomen. Het hoofdstuk [Beveiliging](./security#transportbeveiliging) laat zien dat 86,91% van de sites HTTPS gebruikt, wat suggereert dat gemengde inhoud nu het grootste probleem kan zijn. Dit aantal wordt beter naarmate browsers de applicaties verplichten op HTTPS te staan ​​en die welke niet op HTTPS staan, meer nauwkeurig te bekijken. From bb02262bc699465cb355e4833b70e1d93b4990eb Mon Sep 17 00:00:00 2001 From: Noah Date: Fri, 2 Apr 2021 11:30:28 +0200 Subject: [PATCH 07/11] ci fix --- src/content/nl/2020/http2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/nl/2020/http2.md b/src/content/nl/2020/http2.md index 869060e8ebd..a4954b0cc15 100644 --- a/src/content/nl/2020/http2.md +++ b/src/content/nl/2020/http2.md @@ -635,7 +635,7 @@ Nu vraagt u u misschien af: als niet iedereen al HTTP/2 gebruikt, waarom zouden Eerdere pogingen om nieuwe transportprotocollen op internet in te zetten zijn moeilijk gebleken, bijvoorbeeld [Stream Control Transmission Protocol](https://nl.wikipedia.org/wiki/Stream_Control_Transmission_Protocol) (SCTP). QUIC is een nieuw transportprotocol dat bovenop UDP draait. Het biedt vergelijkbare functies als TCP, zoals betrouwbare levering op volgorde en congestiecontrole om overstroming van het netwerk te voorkomen. -Zoals besproken in de sectie [HTTP/1.0 tot HTTP/2](#http10-naar-http2), HTTP/2 _multiplext_ meerdere verschillende streams bovenop één verbinding. TCP zelf is zich hier jammerlijk niet van bewust, wat leidt tot inefficiënties of invloed op de prestaties wanneer pakketverlies of vertragingen optreden. Meer informatie over dit probleem, bekend als _head-of-line blocking_ (HOL-blokkering), is hier te vinden. +Zoals besproken in de sectie [HTTP/1.0 tot HTTP/2](#http10-naar-http2), HTTP/2 _multiplext_ meerdere verschillende streams bovenop één verbinding. TCP zelf is zich hier jammerlijk niet van bewust, wat leidt tot inefficiënties of invloed op de prestaties wanneer pakketverlies of vertragingen optreden. Meer informatie over dit probleem, bekend als _head-of-line blocking_ (HOL-blokkering), is hier te vinden. QUIC lost het HOL-blokkeerprobleem op door HTTP/2-streams naar de transportlaag te brengen en verliesdetectie en hertransmissie per stream uit te voeren. Dus dan zetten we HTTP/2 gewoon over QUIC, toch? Welnu, we hebben enkele van de moeilijkheden die ontstaan door het hebben van flow control in TCP en HTTP/2 [al genoemd](#verbindingen-verminderen). Het zou een bijkomend probleem zijn om twee afzonderlijke en concurrerende streaming-systemen op elkaar te laten draaien. Bovendien, omdat de QUIC-streams onafhankelijk zijn, zou het knoeien met de strikte bestelvereisten die HTTP/2 vereist voor verschillende van zijn systemen. From ffb25e16c6dfd03e580b2f343741ec830a92f689 Mon Sep 17 00:00:00 2001 From: Noah van der Veer <46689362+noah-vdv@users.noreply.github.com> Date: Fri, 2 Apr 2021 16:30:42 +0200 Subject: [PATCH 08/11] Capitalisation fix Co-authored-by: Barry Pollard --- src/content/nl/2020/http2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/nl/2020/http2.md b/src/content/nl/2020/http2.md index a4954b0cc15..c8929747f46 100644 --- a/src/content/nl/2020/http2.md +++ b/src/content/nl/2020/http2.md @@ -39,7 +39,7 @@ In 1997 werd HTTP/1.1 geïntroduceerd om hergebruik van TCP-verbindingen mogelij HTTP/2, gepubliceerd in 2015, is een binair protocol dat het concept van bidirectionele streams tussen cliënt en server introduceerde. Met behulp van deze streams kan een browser optimaal gebruik maken van een enkele TCP-verbinding om meerdere HTTP-verzoeken/-antwoorden tegelijkertijd te _multiplexen_. HTTP/2 introduceerde ook een prioriteitsschema om deze _multiplexing_ te sturen; cliënten kunnen een verzoekprioriteit aangeven waardoor belangrijkere bronnen vóór anderen kunnen worden verzonden. -## HTTP/2-Adoptie +## HTTP/2-adoptie De gegevens die in dit hoofdstuk worden gebruikt, zijn afkomstig uit het HTTP Archive en testen meer dan zeven miljoen websites met een Chrome-browser. Net als bij andere hoofdstukken, wordt de analyse opgesplitst in mobiele en desktopwebsites. Wanneer de resultaten tussen desktop en mobiel vergelijkbaar zijn, worden statistieken uit de mobiele dataset gepresenteerd. U kunt meer details vinden op de pagina [Methodologie](./methodology). Houd er bij het bekijken van deze gegevens rekening mee dat elke website evenveel gewicht krijgt, ongeacht het aantal verzoeken. We raden u aan dit meer te zien als het onderzoeken van de trends op een breed scala aan actieve websites. From efc776f9bee776aaf36d7e0bf4889cbafa899faf Mon Sep 17 00:00:00 2001 From: Noah Date: Fri, 2 Apr 2021 16:33:39 +0200 Subject: [PATCH 09/11] Capitalisation fix --- src/content/en/2020/security.md | 2 +- src/content/nl/2020/security.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/content/en/2020/security.md b/src/content/en/2020/security.md index 8972a1334cd..70823a99997 100644 --- a/src/content/en/2020/security.md +++ b/src/content/en/2020/security.md @@ -779,7 +779,7 @@ The two other keywords, `unsafe-inline` and `unsafe-eval`, are present on the ma Whereas the `strict-dynamic` and `nonce-` keywords can be used to defend against reflected and persistent XSS attacks, a protected page could still be vulnerable to DOM-based XSS vulnerabilities. To defend against this class of attacks, website developers can make use of Trusted Types, a fairly new mechanism that is currently only supported by Chromium-based browsers. Despite the potential difficulties in adopting Trusted Types (websites would need to create a policy and potentially adjust their JavaScript code to comply with this policy), and given that it is a new mechanism, it is encouraging that 11 homepages already adopted Trusted Types through the `require-trusted-types-for` directive in CSP. -### Defending against XS-Leaks with Cross-Origin Policies +### Defending against XS-leaks with Cross-Origin policies To defend against the novel class of attacks called XS-Leaks, various new security mechanisms have been introduced very recently (some are still under development). Generally, these security mechanisms give website administrators more control over how other sites can interact with their site. For instance, the [`Cross-Origin-Opener-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP) response header can be used to instruct browsers that the page should be process-isolated from other, potentially malicious, browser contexts. As such, an adversary would not be able to obtain a reference to the page's global object. As a result, attacks such as frame counting are prevented with this mechanism. We found 31 early-adopters of this mechanism, which was only supported in Chrome, Edge and Firefox a few days before the data collection started. diff --git a/src/content/nl/2020/security.md b/src/content/nl/2020/security.md index 6b063c4942c..10f18628877 100644 --- a/src/content/nl/2020/security.md +++ b/src/content/nl/2020/security.md @@ -779,7 +779,7 @@ De twee andere trefwoorden, `unsafe-inline` en `unsafe-eval`, zijn aanwezig in d Terwijl de trefwoorden `strict-dynamic` en `nonce-` kunnen worden gebruikt ter verdediging tegen gereflecteerde en aanhoudende XSS-aanvallen, kan een beschermde pagina nog steeds kwetsbaar zijn voor op DOM gebaseerde XSS-kwetsbaarheden. Om zich te verdedigen tegen deze klasse van aanvallen, kunnen website-ontwikkelaars gebruik maken van Trusted Types, een vrij nieuw mechanisme dat momenteel alleen wordt ondersteund door op Chromium gebaseerde browsers. Ondanks de mogelijke problemen bij het adopteren van vertrouwde typen (websites zouden een beleid moeten opstellen en mogelijk hun JavaScript-code moeten aanpassen om aan dit beleid te voldoen), en gezien het feit dat het een nieuw mechanisme is, is het bemoedigend dat 11 startpagina's al vertrouwde typen hebben aangenomen via de richtlijn `require-trusted-types-for` in CSP. -### Bescherming tegen XS-Leaks met Cross-Origin-Policies +### Bescherming tegen XS-leaks met Cross-Origin policies Ter verdediging tegen de nieuwe klasse van aanvallen, XS-Leaks genaamd, zijn zeer recent verschillende nieuwe beveiligingsmechanismen geïntroduceerd (sommige zijn nog in ontwikkeling). Over het algemeen geven deze beveiligingsmechanismen websitebeheerders meer controle over hoe andere sites kunnen communiceren met hun site. Bijvoorbeeld het [`Cross-Origin-Opener-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP) antwoord header kan worden gebruikt om browsers te instrueren dat de pagina proces-geïsoleerd moet worden van andere, mogelijk schadelijke browsercontexten. Als zodanig zou een tegenstander geen verwijzing kunnen krijgen naar het globale object van de pagina. Als gevolg hiervan worden aanvallen zoals frame counting met dit mechanisme voorkomen. We vonden 31 early-adopters van dit mechanisme, dat pas een paar dagen voordat de gegevensverzameling begon, werd ondersteund in Chrome, Edge en Firefox. From 1957f286a33fb6fb21a7183582cba42bb0dbd8d4 Mon Sep 17 00:00:00 2001 From: Barry Pollard Date: Fri, 2 Apr 2021 15:42:53 +0100 Subject: [PATCH 10/11] Apply suggestions from code review --- src/content/en/2020/security.md | 4 ++-- src/content/nl/2020/security.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/content/en/2020/security.md b/src/content/en/2020/security.md index 70823a99997..98ebfae9ed6 100644 --- a/src/content/en/2020/security.md +++ b/src/content/en/2020/security.md @@ -779,9 +779,9 @@ The two other keywords, `unsafe-inline` and `unsafe-eval`, are present on the ma Whereas the `strict-dynamic` and `nonce-` keywords can be used to defend against reflected and persistent XSS attacks, a protected page could still be vulnerable to DOM-based XSS vulnerabilities. To defend against this class of attacks, website developers can make use of Trusted Types, a fairly new mechanism that is currently only supported by Chromium-based browsers. Despite the potential difficulties in adopting Trusted Types (websites would need to create a policy and potentially adjust their JavaScript code to comply with this policy), and given that it is a new mechanism, it is encouraging that 11 homepages already adopted Trusted Types through the `require-trusted-types-for` directive in CSP. -### Defending against XS-leaks with Cross-Origin policies +### Defending against XS-Leaks with Cross-Origin Policies -To defend against the novel class of attacks called XS-Leaks, various new security mechanisms have been introduced very recently (some are still under development). Generally, these security mechanisms give website administrators more control over how other sites can interact with their site. For instance, the [`Cross-Origin-Opener-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP) response header can be used to instruct browsers that the page should be process-isolated from other, potentially malicious, browser contexts. As such, an adversary would not be able to obtain a reference to the page's global object. As a result, attacks such as frame counting are prevented with this mechanism. We found 31 early-adopters of this mechanism, which was only supported in Chrome, Edge and Firefox a few days before the data collection started. +To defend against the novel class of attacks called XS-Leaks, various new security mechanisms have been introduced very recently (some are still under development). Generally, these security mechanisms give website administrators more control over how other sites can interact with their site. For instance, the [`Cross-Origin-Opener-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP) response header can be used to instruct browsers that the page should be process-isolated from other, potentially malicious, browser contexts. As such, an adversary would not be able to obtain a reference to the page's global object. As a result, attacks such as frame counting are prevented with this mechanism. We found 31 early-adopters of this mechanism, which was only supported in Chrome, Edge and Firefox a few days before the data collection started. The [`Cross-Origin-Resource-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)) (CORP) header, which has been supported by Chrome, Firefox and Edge only slightly longer, has already been adopted on 1,712 pages (note that CORP can/should be enabled on all resource types, not just documents, hence this number may be an underestimation). The header is used to instruct the browser how the web resource is expected to be included: same-origin, same-site, or cross-origin (going from more to less restrictive). The browser will prevent loading resources that are included in a way that is in violation with CORP. As such, sensitive resources protected with this response header are safeguarded from Spectre attacks and various XS-Leaks attacks. The Cross-Origin Read Blocking (CORB) mechanism provides a similar protection but is enabled by default in the browser (currently only in Chromium-based browsers) for "sensitive" resources. diff --git a/src/content/nl/2020/security.md b/src/content/nl/2020/security.md index 10f18628877..6149bee0374 100644 --- a/src/content/nl/2020/security.md +++ b/src/content/nl/2020/security.md @@ -779,9 +779,9 @@ De twee andere trefwoorden, `unsafe-inline` en `unsafe-eval`, zijn aanwezig in d Terwijl de trefwoorden `strict-dynamic` en `nonce-` kunnen worden gebruikt ter verdediging tegen gereflecteerde en aanhoudende XSS-aanvallen, kan een beschermde pagina nog steeds kwetsbaar zijn voor op DOM gebaseerde XSS-kwetsbaarheden. Om zich te verdedigen tegen deze klasse van aanvallen, kunnen website-ontwikkelaars gebruik maken van Trusted Types, een vrij nieuw mechanisme dat momenteel alleen wordt ondersteund door op Chromium gebaseerde browsers. Ondanks de mogelijke problemen bij het adopteren van vertrouwde typen (websites zouden een beleid moeten opstellen en mogelijk hun JavaScript-code moeten aanpassen om aan dit beleid te voldoen), en gezien het feit dat het een nieuw mechanisme is, is het bemoedigend dat 11 startpagina's al vertrouwde typen hebben aangenomen via de richtlijn `require-trusted-types-for` in CSP. -### Bescherming tegen XS-leaks met Cross-Origin policies +### Bescherming tegen XS-Leaks met Cross-Origin Policies -Ter verdediging tegen de nieuwe klasse van aanvallen, XS-Leaks genaamd, zijn zeer recent verschillende nieuwe beveiligingsmechanismen geïntroduceerd (sommige zijn nog in ontwikkeling). Over het algemeen geven deze beveiligingsmechanismen websitebeheerders meer controle over hoe andere sites kunnen communiceren met hun site. Bijvoorbeeld het [`Cross-Origin-Opener-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP) antwoord header kan worden gebruikt om browsers te instrueren dat de pagina proces-geïsoleerd moet worden van andere, mogelijk schadelijke browsercontexten. Als zodanig zou een tegenstander geen verwijzing kunnen krijgen naar het globale object van de pagina. Als gevolg hiervan worden aanvallen zoals frame counting met dit mechanisme voorkomen. We vonden 31 early-adopters van dit mechanisme, dat pas een paar dagen voordat de gegevensverzameling begon, werd ondersteund in Chrome, Edge en Firefox. +Ter verdediging tegen de nieuwe klasse van aanvallen, XS-Leaks genaamd, zijn zeer recent verschillende nieuwe beveiligingsmechanismen geïntroduceerd (sommige zijn nog in ontwikkeling). Over het algemeen geven deze beveiligingsmechanismen websitebeheerders meer controle over hoe andere sites kunnen communiceren met hun site. Bijvoorbeeld het [`Cross-Origin-Opener-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP) antwoord header kan worden gebruikt om browsers te instrueren dat de pagina proces-geïsoleerd moet worden van andere, mogelijk schadelijke browsercontexten. Als zodanig zou een tegenstander geen verwijzing kunnen krijgen naar het globale object van de pagina. Als gevolg hiervan worden aanvallen zoals frame counting met dit mechanisme voorkomen. We vonden 31 early-adopters van dit mechanisme, dat pas een paar dagen voordat de gegevensverzameling begon, werd ondersteund in Chrome, Edge en Firefox. De [`Cross-Origin-Resource-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)) (CORP) header, die werd ondersteund door Chrome, Firefox en Edge, slechts iets langer, is al aangenomen op 1.712 pagina's (merk op dat CORP kan/moet worden ingeschakeld op alle brontypen, niet alleen op documenten, vandaar dat dit aantal een onderschatting kan zijn). De header wordt gebruikt om de browser te instrueren hoe de webresource naar verwachting wordt opgenomen: same-origin, same-site of cross-origin (gaande van meer naar minder beperkend). De browser voorkomt dat bronnen worden geladen die zijn opgenomen op een manier die in strijd is met CORP. Als zodanig worden gevoelige bronnen die met deze responskop worden beschermd, beschermd tegen Spectre-aanvallen en verschillende XS-Leaks-aanvallen. Het Cross-Origin Read Blocking (CORB)-mechanisme biedt een vergelijkbare bescherming, maar is standaard ingeschakeld in de browser (momenteel alleen in Chromium-gebaseerde browsers) voor "gevoelige" bronnen. From 67390ba5345131584650eb77fe0e931e15a4c652 Mon Sep 17 00:00:00 2001 From: Barry Date: Fri, 2 Apr 2021 15:47:45 +0100 Subject: [PATCH 11/11] Fix links --- src/content/en/2020/security.md | 2 +- src/content/ja/2020/security.md | 2 +- src/content/nl/2020/security.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/content/en/2020/security.md b/src/content/en/2020/security.md index 98ebfae9ed6..773288461fe 100644 --- a/src/content/en/2020/security.md +++ b/src/content/en/2020/security.md @@ -781,7 +781,7 @@ Whereas the `strict-dynamic` and `nonce-` keywords can be used to defend against ### Defending against XS-Leaks with Cross-Origin Policies -To defend against the novel class of attacks called XS-Leaks, various new security mechanisms have been introduced very recently (some are still under development). Generally, these security mechanisms give website administrators more control over how other sites can interact with their site. For instance, the [`Cross-Origin-Opener-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP) response header can be used to instruct browsers that the page should be process-isolated from other, potentially malicious, browser contexts. As such, an adversary would not be able to obtain a reference to the page's global object. As a result, attacks such as frame counting are prevented with this mechanism. We found 31 early-adopters of this mechanism, which was only supported in Chrome, Edge and Firefox a few days before the data collection started. +To defend against the novel class of attacks called XS-Leaks, various new security mechanisms have been introduced very recently (some are still under development). Generally, these security mechanisms give website administrators more control over how other sites can interact with their site. For instance, the [`Cross-Origin-Opener-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP) response header can be used to instruct browsers that the page should be process-isolated from other, potentially malicious, browser contexts. As such, an adversary would not be able to obtain a reference to the page's global object. As a result, attacks such as frame counting are prevented with this mechanism. We found 31 early-adopters of this mechanism, which was only supported in Chrome, Edge and Firefox a few days before the data collection started. The [`Cross-Origin-Resource-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)) (CORP) header, which has been supported by Chrome, Firefox and Edge only slightly longer, has already been adopted on 1,712 pages (note that CORP can/should be enabled on all resource types, not just documents, hence this number may be an underestimation). The header is used to instruct the browser how the web resource is expected to be included: same-origin, same-site, or cross-origin (going from more to less restrictive). The browser will prevent loading resources that are included in a way that is in violation with CORP. As such, sensitive resources protected with this response header are safeguarded from Spectre attacks and various XS-Leaks attacks. The Cross-Origin Read Blocking (CORB) mechanism provides a similar protection but is enabled by default in the browser (currently only in Chromium-based browsers) for "sensitive" resources. diff --git a/src/content/ja/2020/security.md b/src/content/ja/2020/security.md index 97c79519e5f..4cde6f33174 100644 --- a/src/content/ja/2020/security.md +++ b/src/content/ja/2020/security.md @@ -781,7 +781,7 @@ CSPの採用を容易にするもう1つのメカニズムはnoncesの使用で ### クロスオリジンポリシーによるXSリークの防御 -XS-Leaksと呼ばれる新しいクラスの攻撃から身を守るために、最近、様々な新しいセキュリティメカニズムが導入されました（いくつかはまだ開発中です）。一般的に、これらのセキュリティメカニズムは、他のサイトが自分のサイトとどのように相互作用するかをウェブサイトの管理者がコントロールできるようにしています。例えば、[`Cross-Origin-Openener-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP) レスポンスヘッダーは、ページを他の悪意のある可能性のあるブラウザコンテキストから分離処理すべきであることをブラウザに指示するために使用できます。そのため、敵対者はページのグローバルオブジェクトへの参照を取得することができません。その結果、frame countingのような攻撃は、このメカニズムで防ぐことができます。データ収集が始まる数日前にChrome、Edge、Firefoxでしかサポートされていなかったこのメカニズムのアーリーアダプターが31件見つかりました。 +XS-Leaksと呼ばれる新しいクラスの攻撃から身を守るために、最近、様々な新しいセキュリティメカニズムが導入されました（いくつかはまだ開発中です）。一般的に、これらのセキュリティメカニズムは、他のサイトが自分のサイトとどのように相互作用するかをウェブサイトの管理者がコントロールできるようにしています。例えば、[`Cross-Origin-Openener-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP) レスポンスヘッダーは、ページを他の悪意のある可能性のあるブラウザコンテキストから分離処理すべきであることをブラウザに指示するために使用できます。そのため、敵対者はページのグローバルオブジェクトへの参照を取得することができません。その結果、frame countingのような攻撃は、このメカニズムで防ぐことができます。データ収集が始まる数日前にChrome、Edge、Firefoxでしかサポートされていなかったこのメカニズムのアーリーアダプターが31件見つかりました。 `Cross-Origin-Resource-Policy`(https://developer.mozilla.org/ja/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP))(CORP)ヘッダーは、Chrome、Firefox、Edgeでサポートされていますが、すでに1,712ページで採用されています（CORPはドキュメントだけでなく、すべてのリソースタイプで有効にできます/すべきであることに注意してください、したがってこの数は過小評価かもしれません）。ヘッダーは、ウェブリソースがどのように含まれることが予想されるかをブラウザに指示するために使用されます: 同一オリジン、同一サイト、クロスオリジン（制限が多いものから少ないものへ）。ブラウザは、CORPに違反する方法で含まれるリソースの読み込みを阻止します。このように、この応答ヘッダーで保護された機密リソースは、Spectre攻撃や様々なXS-Leaks攻撃から保護されています。Cross-Origin Read Blocking(CORB)メカニズムも同様の保護を提供しますが、ブラウザではデフォルトで有効になっています（現在はChromiumベースのブラウザのみ）。 diff --git a/src/content/nl/2020/security.md b/src/content/nl/2020/security.md index 6149bee0374..d90a2334fc9 100644 --- a/src/content/nl/2020/security.md +++ b/src/content/nl/2020/security.md @@ -781,7 +781,7 @@ Terwijl de trefwoorden `strict-dynamic` en `nonce-` kunnen worden gebruikt ter v ### Bescherming tegen XS-Leaks met Cross-Origin Policies -Ter verdediging tegen de nieuwe klasse van aanvallen, XS-Leaks genaamd, zijn zeer recent verschillende nieuwe beveiligingsmechanismen geïntroduceerd (sommige zijn nog in ontwikkeling). Over het algemeen geven deze beveiligingsmechanismen websitebeheerders meer controle over hoe andere sites kunnen communiceren met hun site. Bijvoorbeeld het [`Cross-Origin-Opener-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP) antwoord header kan worden gebruikt om browsers te instrueren dat de pagina proces-geïsoleerd moet worden van andere, mogelijk schadelijke browsercontexten. Als zodanig zou een tegenstander geen verwijzing kunnen krijgen naar het globale object van de pagina. Als gevolg hiervan worden aanvallen zoals frame counting met dit mechanisme voorkomen. We vonden 31 early-adopters van dit mechanisme, dat pas een paar dagen voordat de gegevensverzameling begon, werd ondersteund in Chrome, Edge en Firefox. +Ter verdediging tegen de nieuwe klasse van aanvallen, XS-Leaks genaamd, zijn zeer recent verschillende nieuwe beveiligingsmechanismen geïntroduceerd (sommige zijn nog in ontwikkeling). Over het algemeen geven deze beveiligingsmechanismen websitebeheerders meer controle over hoe andere sites kunnen communiceren met hun site. Bijvoorbeeld het [`Cross-Origin-Opener-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy) (COOP) antwoord header kan worden gebruikt om browsers te instrueren dat de pagina proces-geïsoleerd moet worden van andere, mogelijk schadelijke browsercontexten. Als zodanig zou een tegenstander geen verwijzing kunnen krijgen naar het globale object van de pagina. Als gevolg hiervan worden aanvallen zoals frame counting met dit mechanisme voorkomen. We vonden 31 early-adopters van dit mechanisme, dat pas een paar dagen voordat de gegevensverzameling begon, werd ondersteund in Chrome, Edge en Firefox. De [`Cross-Origin-Resource-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)) (CORP) header, die werd ondersteund door Chrome, Firefox en Edge, slechts iets langer, is al aangenomen op 1.712 pagina's (merk op dat CORP kan/moet worden ingeschakeld op alle brontypen, niet alleen op documenten, vandaar dat dit aantal een onderschatting kan zijn). De header wordt gebruikt om de browser te instrueren hoe de webresource naar verwachting wordt opgenomen: same-origin, same-site of cross-origin (gaande van meer naar minder beperkend). De browser voorkomt dat bronnen worden geladen die zijn opgenomen op een manier die in strijd is met CORP. Als zodanig worden gevoelige bronnen die met deze responskop worden beschermd, beschermd tegen Spectre-aanvallen en verschillende XS-Leaks-aanvallen. Het Cross-Origin Read Blocking (CORB)-mechanisme biedt een vergelijkbare bescherming, maar is standaard ingeschakeld in de browser (momenteel alleen in Chromium-gebaseerde browsers) voor "gevoelige" bronnen.