Note that we weren't able to analyze any text inside of images, so our reported metric is an upper-bound of the total number of websites passing the color contrast test.
+
### Zooming and scaling pages
diff --git a/src/content/en/2019/cdn.md b/src/content/en/2019/cdn.md
index 9ccdb924a9b..67dccbbe6ca 100644
--- a/src/content/en/2019/cdn.md
+++ b/src/content/en/2019/cdn.md
@@ -89,7 +89,7 @@ There are two categories of CDN providers: the generic and the purpose-fit CDN.
This is clearly represented when looking at the top CDNs found serving the base HTML content. The most frequent CDNs serving HTML are generic CDNs (Cloudflare, Akamai, Fastly) and cloud solution providers who offer a bundled CDN (Google, Amazon) as part of the platform service offerings. In contrast, there are only a few purpose-fit CDN providers, such as Wordpress and Netlify, that deliver base HTML markup.
-
Note: This does not reflect traffic or usage, only the number of sites using them.
+
{{ figure_markup(
image="html_cdn_usage.png",
@@ -478,7 +478,7 @@ Since TLS negotiations require multiple TCP round trips before data can be sent
In contrast, the median TLS negotiation for the majority of CDN providers is between 60 and 70 ms. Origin requests for HTML pages take almost 3x longer to complete TLS negotiation than those web pages that use a CDN. Even at the 90th percentile, this disparity perpetuates with origin TLS negotiation rates of 427 ms compared to most CDNs which complete under 140 ms!
-
A word of caution when interpreting these charts: it is important to focus on orders of magnitude when comparing vendors as there are many factors that impact the actual TLS negotiation performance. These tests were completed from a single datacenter under controlled conditions and do not reflect the variability of the internet and user experiences.
+
{{ figure_markup(
image="html_tls_negotiation_time.png",
@@ -1056,7 +1056,7 @@ Along with this general adoption of TLS, CDN use also sees higher adoption of em
In general, the use of a CDN is highly correlated with a more rapid adoption of stronger ciphers and stronger TLS versions compared to origin-hosted services where there is a higher usage of very old and compromised TLS versions like TLS 1.0.
-
It is important to emphasize that Chrome used in the Web Almanac will bias to the latest TLS versions and ciphers offered by the host. Also, these web pages were crawled in July 2019 and reflect the adoption of websites that have enabled the newer versions.
+
{{ figure_markup(
image="fig18.png",
@@ -1074,7 +1074,7 @@ Along with RTT management and improving TLS performance, CDNs also enable new st
CDNs have over 70% adoption of HTTP/2, compared to the nearly 27% of origin pages. Similarly, sub-domain and third-party resources on CDNs see an even higher adoption of HTTP/2 at 90% or higher while third-party resources served from origin infrastructure only has 31% adoption. The performance gains and other features of HTTP/2 are further covered in the [HTTP/2](./http) chapter.
-
Note: All requests were made with the latest version of Chrome which supports HTTP/2. When only HTTP/1.1 is reported, this would indicate either unencrypted (non-TLS) servers or servers that don't support HTTP/2.
+
{{ figure_markup(
image="fig19.png",
diff --git a/src/content/en/2019/css.md b/src/content/en/2019/css.md
index bb1d4e58111..c744a4e1ba8 100644
--- a/src/content/en/2019/css.md
+++ b/src/content/en/2019/css.md
@@ -107,7 +107,7 @@ Unsurprisingly, in Figure 2.5 above, `px` is the most used unit type, with about
When it comes to units based on physical space, the `cm` (or centimeter) unit is the most popular by far, followed by `in` (inches), and then `Q`. We know these types of units are specifically useful for print stylesheets, but we didn't even know the `Q` unit existed until this survey! Did you?
-
An earlier version of this chapter discussed the unexpected popularity of the Q unit. Thanks to the community discussion surrounding this chapter, we've identified that this was a bug in our analysis and have updated Figure 2.5 accordingly.
+
### Viewport-based units
diff --git a/src/content/en/2019/ecommerce.md b/src/content/en/2019/ecommerce.md
index a7d475090f5..8cb2db49db0 100644
--- a/src/content/en/2019/ecommerce.md
+++ b/src/content/en/2019/ecommerce.md
@@ -445,7 +445,7 @@ Mobile HTML payload sizes are not very different from desktop. In other words, i
)
}}
-
Note that because our data collection methodology does not simulate user interactions on pages like clicking or scrolling, images that are lazy loaded would not be represented in these results.
+
Figures 13.12 and 13.13 above show that the median ecommerce page has 37 images and an image payload of 1,517 KB on mobile, 40 images and 1,524 KB on desktop. 10% of home pages have 90 or more images and an image payload of nearly 6 MB!
@@ -472,7 +472,7 @@ We need to do more analysis to better understand why some sites are not using re
)
}}
-
Note that some image services or CDNs will automatically deliver WebP (rather than JPEG or PNG) to platforms that support WebP, even for a URL with a `.jpg` or `.png` suffix. For example, IMG_20190113_113201.jpg returns a WebP image in Chrome. However, the way HTTP Archive detects image formats is to check for keywords in the MIME type first, then fall back to the file extension. This means that the format for images with URLs such as the above will be given as WebP, since WebP is supported by HTTP Archive as a user agent.
+
### PNG
diff --git a/src/content/en/2019/javascript.md b/src/content/en/2019/javascript.md
index f5f9a9e7eb5..244e536dd38 100644
--- a/src/content/en/2019/javascript.md
+++ b/src/content/en/2019/javascript.md
@@ -299,7 +299,7 @@ Other top used JavaScript libraries include jQuery variants (jQuery migrate, jQu
### Frameworks and UI libraries
-
As mentioned in our methodology, the third-party detection library used in HTTP Archive (Wappalyzer) has a number of limitations with regards to how it detects certain tools. There is an open issue to improve detection of JavaScript libraries and frameworks, which will have impacted the results presented here.
+
In the past number of years, the JavaScript ecosystem has seen a rise in open-source libraries and frameworks to make building **single-page applications** (SPAs) easier. A single-page application is characterized as a web page that loads a single HTML page and uses JavaScript to modify the page on user interaction instead of fetching new pages from the server. Although this remains to be the main premise of single-page applications, different server-rendering approaches can still be used to improve the experience of such sites. How many sites use these types of frameworks?
diff --git a/src/content/en/2019/markup.md b/src/content/en/2019/markup.md
index 3d38dca120f..587be00b93b 100644
--- a/src/content/en/2019/markup.md
+++ b/src/content/en/2019/markup.md
@@ -38,7 +38,7 @@ Looking at a raw frequency count isn't especially helpful, even for standard ele
Instead, as in Hixie's original study, what we will look at is how many sites include each element at least once in their home page.
-
Note: This is, itself, not without some potential biases. Popular products can be used by several sites, which introduce non-standard markup, even "invisibly" to individual authors. Thus, care must be taken to acknowledge that usage doesn't necessarily imply direct author knowledge and conscious adoption as much as it does the servicing of a common need, in a common way. During our research, we found several examples of this, some we will call out.
+
## Top elements and general info
@@ -163,7 +163,7 @@ In the desktop dataset we collected data for the top 4,834 non-standard elements
Additionally, 15% of desktop pages and 16% of mobile pages contain deprecated elements.
-
Note: A lot of this is very likely due to the use of products rather than individual authors continuing to manually create this markup.
+
{{ figure_markup(
image="fig6.png",
diff --git a/src/content/en/2019/media.md b/src/content/en/2019/media.md
index 792ab033989..cf45474df52 100644
--- a/src/content/en/2019/media.md
+++ b/src/content/en/2019/media.md
@@ -86,7 +86,7 @@ For the mobile device used in the web page crawl, we have a display of `512 x 36
If we had one image that filled the entire screen perfectly, this would be a 1x pixel fill rate. Of course, rarely does a website fill the entire canvas with a single image. Media content tends to be mixed in with the design and other content. A value greater than 1x implies that the layout requires the user to scroll to see the additional image content.
-
Note: this is only looking at the CSS layout for both the DPR and the volume of layout content. It is not evaluating the effectiveness of the responsive images or the effectiveness of providing high DPR content.
+
{{ figure_markup(
image="fig5_image_pixel_volume_v_css_pixels.png",
@@ -111,7 +111,7 @@ While the strategies that are utilized for images, videos, and animations are—
* **Lazy loading** - to transfer content only when a human will see it
* **Accessibility** - ensuring a consistent experience for all humans
-
A word of caution when interpreting these results. The web pages crawled for the Web Almanac were crawled on a Chrome browser. This implies that any content negotiation that might better apply for Safari or Firefox might not be represented in this dataset. For example, the use of file formats like JPEG2000, JPEG-XR, HEVC and HEIC are absent because these are not supported natively by Chrome. This does not mean that the web does not contain these other formats or experiences. Likewise, Chrome has native support for lazy loading (since v76) which is not yet available in other browsers. Read more about these caveats in our Methodology.
+
It is rare to find a web page that does not utilize images. Over the years, many different file formats have emerged to help present content on the web, each addressing a different problem. Predominantly, there are 4 main universal image formats: JPEG, PNG, GIF, and SVG. In addition, Chrome has enhanced the media pipeline and added support for a fifth image format: WebP. Other browsers have likewise added support for JPEG2000 (Safari), JPEG-XL (IE and Edge) and HEIC (WebView only in Safari).
diff --git a/src/content/en/2019/mobile-web.md b/src/content/en/2019/mobile-web.md
index 46dd5520026..43ee011e72e 100644
--- a/src/content/en/2019/mobile-web.md
+++ b/src/content/en/2019/mobile-web.md
@@ -82,7 +82,7 @@ Let's delve deeper and look at another metric that focuses more on *how well* ea
- It's also delivered as text to the browser. So it compresses well, and should be delivered faster than just a screenshot of the page.
- So if the total amount of JavaScript a page downloads _alone_ (not including images, css, etc) is larger than a PNG screenshot of the viewport, we are using far too much JavaScript. At this point, it'd be faster just to send that screenshot to get the initial page state!
-
The *JavaScript Bloat Score* is defined as: (total JavaScript size) / (size of PNG screenshot of viewport). Any number greater than 1.0 means it's faster to send a screenshot.
+
The results of this? Of the 5+ million websites analyzed, 75.52% were bloated with JavaScript. We have a long way to go.
@@ -223,7 +223,7 @@ Some designers love to use icons in place of text — they can make our sites lo
This is why it's important to avoid any confusion and add supporting text and labels to your buttons. As of now, at least 28.59% of sites include a button with only a single icon with no supporting text.
-
Note: The reported number above is only a lower bound. During our analysis, we only included buttons using font icons with no supporting text. Many buttons now use SVGs instead of font-icons however, so in future runs we will be including them as well.
+
## Semantic form fields
@@ -278,7 +278,7 @@ Currently, only 29.62% of pages with input fields utilize this feature.
Enabling users to copy and paste their passwords into your page is one way that allows them to use password managers. Password managers help users generate (and remember) strong passwords and fill them out automatically on web pages. Only 0.02% of web pages tested disable this functionality.
-
Note: While this is very encouraging, this may be an underestimation due to the requirement of our Methodology to only test home pages. Interior pages, like login pages, are not tested.
+
## Conclusion
@@ -297,7 +297,7 @@ The mobile web has now been around long enough for there to be an entire generat
)
}}
-
Notes:
+
+
diff --git a/src/content/en/2019/page-weight.md b/src/content/en/2019/page-weight.md
index a62603439df..5479d760238 100644
--- a/src/content/en/2019/page-weight.md
+++ b/src/content/en/2019/page-weight.md
@@ -35,7 +35,7 @@ The common argument as to why page size doesn't matter anymore is that, thanks t
Yes, you can build large robust pages that feel fast… to some users. But you should care about page bloat in terms of how it affects all your users, especially mobile-only users who deal with bandwidth constraints or data limits.
-
Check out Tim Kadlec's fascinating online calculator, What Does My Site Cost?, which calculates the cost—in dollars and Gross National Income per capita—of your pages in countries around the world. It's an eye-opener. For instance, Amazon's home page, which at the time of writing weighs 2.79 MB, costs 1.89% of the daily per capita GNI of Mauritania. How global is the world wide web when people in some parts of the world would have to give up a day's wages just to visit a few dozen pages?
+
### More bandwidth isn't a magic bullet for web performance
diff --git a/src/content/en/2019/performance.md b/src/content/en/2019/performance.md
index e883271ee12..36faa275f9a 100644
--- a/src/content/en/2019/performance.md
+++ b/src/content/en/2019/performance.md
@@ -60,7 +60,7 @@ So let's dive in and see what insights we can find.
In Figure 7.1 above, you can see how FCP experiences are distributed across the web. Out of the millions of websites in the CrUX dataset, this chart compresses the distribution down to 1,000 websites, where each vertical slice represents a single website. The chart is sorted by the percent of fast FCP experiences, which are those occurring in less than 1 second. Slow experiences occur in 3 seconds or more, and moderate (formerly known as "average") experiences are everything in between. At the extremes of the chart, there are some websites with almost 100% fast experiences and some websites with almost 100% slow experiences. In between that, websites that have a combination of fast, moderate, and slow performance seem to lean more towards fast or moderate than slow, which is good.
-
Note: When a user experiences slow performance, it's hard to say what the reason might be. It could be that the website itself was built poorly and inefficiently. Or there could be other environmental factors like the user's slow connection, empty cache, etc. So, when looking at this field data we prefer to say that the user experiences themselves are slow, and not necessarily the websites.
+
In order to categorize whether a website is sufficiently **fast** we will use the new PageSpeed Insights (PSI) methodology, where at least 75% of the website's FCP experiences must be faster than 1 second. Similarly, a sufficiently **slow** website has 25% or more FCP experiences slower than 3 seconds. We say a website has **moderate** performance when it doesn't meet either of these conditions.
diff --git a/src/content/en/2019/resource-hints.md b/src/content/en/2019/resource-hints.md
index 9806df44217..6cf8263ad52 100644
--- a/src/content/en/2019/resource-hints.md
+++ b/src/content/en/2019/resource-hints.md
@@ -66,7 +66,7 @@ Because the usage of resource hints in HTTP headers is so low, the remainder of
## Resource hints
-
Note: There was no noticeable difference between the usage patterns for resource hints on mobile versus desktop. Thus, for the sake of conciseness, this chapter only includes the statistics for mobile.
+
diff --git a/src/content/en/2019/seo.md b/src/content/en/2019/seo.md
index acd2ef6f5f3..beab6e96c24 100644
--- a/src/content/en/2019/seo.md
+++ b/src/content/en/2019/seo.md
@@ -34,7 +34,7 @@ Our analysis includes data from [Lighthouse](./methodology#lighthouse), the [Chr
Our custom metrics provide insights that, up until now, have not been exposed before. We are now able to make claims about the adoption and implementation of elements such as the `hreflang` tag, rich results eligibility, heading tag usage, and even anchor-based navigation for single page apps.
-
Note: Our data is limited to analyzing home pages only and has not been gathered from site-wide crawls. This will impact many metrics we'll discuss, so we've added any relevant limitations in this case whenever we mention a specific metric. Learn more about these limitations in our Methodology.
+
Read on to find out more about the current state of the web and its search engine friendliness.
@@ -146,7 +146,7 @@ It is recommended to maintain a `200 OK` status code for any important pages tha
The next most commonly found status code on mobile was `302`, a temporary redirect, which was found on 10.45% of mobile pages. This was higher than on desktop, with only 6.71% desktop home pages returning a `302` status code. This could be due to the fact that the mobile home pages were alternates to an equivalent desktop page, such as on non-responsive sites that have separate versions of the website for each device.
-
Note: Our results didn't include 4xx or 5xx status codes.
+
#### `noindex`
@@ -154,7 +154,7 @@ A `noindex` directive can be served in the HTML `` or in the HTTP headers
96.93% of mobile pages passed the Lighthouse indexing audit, meaning that these pages didn't contain a `noindex` directive. However, this means that 3.07% of mobile home pages _did_ have a `noindex` directive, which is cause for concern, meaning that Google was prevented from indexing these pages.
-
The websites included in our research are sourced from the Chrome UX Report dataset, which excludes websites that are not publicly discoverable. This is a significant source of bias because we're unable to analyze sites that Chrome determines to be non-public. Learn more about our methodology.
+
#### Canonicalization
diff --git a/src/content/en/2019/third-parties.md b/src/content/en/2019/third-parties.md
index b717db69a13..ae93872351d 100644
--- a/src/content/en/2019/third-parties.md
+++ b/src/content/en/2019/third-parties.md
@@ -57,9 +57,9 @@ This chapter divides third-party providers into one of these broad categories. A
- **Video** - providers that host the arbitrary video content of their users
- **Other** - uncategorized or non-conforming activity
-
+
+
### Caveats
diff --git a/src/content/en/2020/caching.md b/src/content/en/2020/caching.md
index c84e0745b85..e349fd4de2e 100644
--- a/src/content/en/2020/caching.md
+++ b/src/content/en/2020/caching.md
@@ -72,9 +72,9 @@ Below figure shows how a typical request/response flow works for an object (e.g.
)
}}
-
Note: Unless specified otherwise, all statistics in this chapter are for mobile, on the understanding that desktop statistics are similar. Where mobile and desktop statistics differ significantly, that is called out.
+
+Many of the responses used in this chapter are from web servers which use commonly-available server packages. While we may indicate best practices, the practices may not be possible if the software package used has a limited number of cache options.
## Caching guiding principles
diff --git a/src/content/en/2020/css.md b/src/content/en/2020/css.md
index b30a5e7a138..19c490872fc 100644
--- a/src/content/en/2020/css.md
+++ b/src/content/en/2020/css.md
@@ -48,7 +48,7 @@ For certain metrics, looking at the CSS AST was not enough. We wanted to look at
Custom metrics were also used for part of the [custom properties analysis](#custom-properties). While we can get a lot of information about custom property usage from the stylesheets alone, we cannot build a dependency graph without being able to look at the DOM tree for context, as custom properties are inherited. Looking at the computed style of the DOM nodes also gives us information like what kinds of elements each property is applied to, and which of them are [registered](https://developer.mozilla.org/docs/Web/API/CSS/RegisterProperty)—information that we also cannot get from the stylesheets.
-
We crawl our pages in both desktop and mobile mode but for a lot of the data they give similar results so, unless otherwise noted, stats presented in this chapter refer to the set of mobile pages.
+
## Usage
diff --git a/src/content/en/2020/ecommerce.md b/src/content/en/2020/ecommerce.md
index 6da37b499f1..d4c050c51a1 100644
--- a/src/content/en/2020/ecommerce.md
+++ b/src/content/en/2020/ecommerce.md
@@ -64,7 +64,7 @@ Our methodology has the following limitations:
In total, 21.72% of mobile websites and 21.27% of desktop websites used an ecommerce platform. For 2019, the same number was 9.41% for mobile websites and 9.67% for desktop websites.
-
Note: This increase is primarily due to improvements made to Wappalyzer to detect ecommerce websites and shouldn't be attributed to other factors like growth due to Covid-19. Also a minor correction was applied to 2019 stats retrospectively to account for an error and hence the 2019 percentages are slightly different than those given in the 2019 Ecommerce chapter.
+
### Top ecommerce platforms
@@ -135,7 +135,7 @@ COVID-19 has had a huge impact on the world and necessitated an even bigger move
There is definitely a measurable increase WooCommerce and Shopify sites around the time COVID started really impacting the world.
-
Note: Wappalyzer detection for Wix doesn't differentiate if a site is using Wix as CMS or ecommerce platform. Due to this, growth of Wix as ecommerce platform may not be represented correctly in above graph.
+
## Page weight and requests
@@ -241,7 +241,7 @@ The figures above show that the median ecommerce page has 34 images and an image
sql_file="pagestats_image_bydevice_format.sql"
) }}
-
Note that some image services or CDNs will automatically deliver WebP (rather than JPEG or PNG) to platforms that support WebP, even for a URL with a .jpg or .png suffix. For example, IMG_20190113_113201.jpg returns a WebP image in Chrome. However, the way HTTP Archive detects image formats is to check for keywords in the MIME type first, then fall back to the file extension. This means that the format for images with URLs such as the above will be given as WebP, since WebP is supported by HTTP Archive as a user agent.
+
PNG usage remained roughly at the [same level as 2019](../2019/ecommerce#png) (at 27% for both desktop and mobile). We observed drop in JPEG usage (4% for desktop and 6% for mobile). Out of this drop, most of it went towards increased GIF usage. GIFs are quite common on ecommerce home pages whereas GIFs may not be much used on product detail pages. Since our methodology only looks at home pages, this explains the significantly high usage of GIFs across ecommerce sites. Lighthouse has an audit which recommends using "video formats for animated content". This is a technique ecommerce sites can use to optimize for performance but still retain animation properties of GIFs. See this article for more details.
@@ -437,7 +437,7 @@ Adoption of server-side tagging will depend on third parties to provide server s
{{ figure_link(caption="Tag manager usage on ecommerce sites.", sheets_gid="2045910168", sql_file="percent_of_ecommsites_using_each_tag_managers.sql") }}
-
Note: Above analysis is based on Wappalyzer detection which may differ from analysis done using Third Party Web dataset which is used for Third parties chapter.
+
### Consent Management Platforms
diff --git a/src/content/en/2020/http.md b/src/content/en/2020/http.md
index 3072b5a5ca2..fd3904968b2 100644
--- a/src/content/en/2020/http.md
+++ b/src/content/en/2020/http.md
@@ -98,9 +98,9 @@ When comparing Figure 22.3 with last year's results, there has been a **10% incr
{{ figure_link(caption="HTTP version usage by request.", sheets_gid="2122693316", sql_file="adoption_of_http_2_by_site_and_requests.sql") }}
-
+
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.
diff --git a/src/content/en/2020/jamstack.md b/src/content/en/2020/jamstack.md
index bc3865ecc6a..cf17ad3f1bb 100644
--- a/src/content/en/2020/jamstack.md
+++ b/src/content/en/2020/jamstack.md
@@ -30,7 +30,7 @@ The HTTP Archive crawls It should be noted that our analysis is limited by those Jamstacks that make themselves easily identifiable using Wappalyzer. This means our data does not include some popular Jamstacks like Eleventy which make a deliberate choice to not make themselves identifiable. While we would ideally include all Jamstacks, we believe there is still plenty of value in analyzing the significant data we do have.
+
## Adoption of Jamstack
diff --git a/src/content/en/2020/javascript.md b/src/content/en/2020/javascript.md
index 78bcab8721a..a65681f4135 100644
--- a/src/content/en/2020/javascript.md
+++ b/src/content/en/2020/javascript.md
@@ -200,9 +200,9 @@ We can start to offset some of the cost of loading JavaScript by loading scripts
On mobile, external scripts comprise 59.0% of all script elements found.
-
+
+
{{ figure_markup(
image="external-inline-mobile.png",
diff --git a/src/content/en/2020/markup.md b/src/content/en/2020/markup.md
index 91aaa76d07a..7214320fcae 100644
--- a/src/content/en/2020/markup.md
+++ b/src/content/en/2020/markup.md
@@ -30,9 +30,9 @@ How do we use HTML, then, how great of a foundation do we have? In the introduct
Last year's analysis was based on 5.8 million pages, of which 4.4 million were tested on desktop and 5.3 million on mobile. This year we analyzed 7.5 million pages, of which 5.6 million were tested on desktop and 6.3 million on mobile, using the [latest data](./methodology#websites) on the websites users are visiting in 2020. We do make some comparisons to last year, but just as we've tried to analyze additional metrics for new insights, we've also tried to impart our own personalities and perspectives throughout the chapter.
-
+
+
## General
@@ -1019,9 +1019,9 @@ We had a look at the data and in order to better understand the results, we norm
The results show that almost half of the pages we analyzed are using the typical viewport `content` value. Still, around 10% of mobile pages are entirely missing a proper `content` value for the viewport meta element, with the rest of them using an improper combination of `maximum-scale`, `minimum-scale`, `user-scalable=no`, or `user-scalable=0`.
-
+
+
### Favicons
@@ -1306,7 +1306,7 @@ Using `target="_blank"` has been known to be a usability reasons, it is recommended not to use `target="_blank"` in the first place.
-
Within the latest Safari and Firefox versions, setting target="_blank" on a elements implicitly provides the same rel behavior as setting rel="noopener". This is already implemented in Chromium as well and will land in Chrome 88.
+
## Conclusion
@@ -1336,6 +1336,6 @@ That compels us to close with an appeal: Pay attention to HTML. Focus on HTML. I
For the next edition of the Web Almanac's chapter, let's prepare to look closer at the craft of writing HTML and, hopefully, how we've been improving on it.
-
+
+
diff --git a/src/content/en/2020/media.md b/src/content/en/2020/media.md
index ac991f3f3f2..a368b0e7994 100644
--- a/src/content/en/2020/media.md
+++ b/src/content/en/2020/media.md
@@ -186,7 +186,7 @@ Of pages using `` for format-switching, around 68% are offering a singl
We see that WebP is the dominant usage across `` elements, followed by PNG, and that and JPG is only 4.83% of `` usage.
-
Note our crawler crawls as Chrome which supports WebP, but if using another browser which does not support this then you will see different results.
+
Here is an example of the markup syntax that could be used to offer multiple format variants:
@@ -223,7 +223,7 @@ There are three aspects to consider when implementing format-switching:
Several Dynamic Media Services and Image CDNs can greatly simplify this by automating it and endeavoring to track and keep in sync with the ever-changing browser format support landscape.
-
Note: though AVIF has been supported in Chrome since version 85 (released late August 2020), the data for this Almanac is predominantly from prior to this time. However running an ad hoc query on more recent data from early November 2020 shows tens of thousands of AVIF requests.
+
##### Picture: media art direction
diff --git a/src/content/en/2020/mobile-web.md b/src/content/en/2020/mobile-web.md
index 8db1a1640ef..56801acac6f 100644
--- a/src/content/en/2020/mobile-web.md
+++ b/src/content/en/2020/mobile-web.md
@@ -39,7 +39,7 @@ In addition to the above, we also used a non-public Chrome data source in the se
While this data is only collected from a subset of (opted in) Chrome users, it does not suffer from being limited to home pages. It is pseudonymous and consists of histograms and events.
-
NOTE: Reporting is enabled if the user has enabled a feature that syncs browser windows, unless they have disabled the "Make searches and browsing better / Sends URLs of pages you visit to Google" setting.
+
A fast page load ensures a good mobile user experience, particularly when slower cellular networks are taken into consideration. 27.56% of pages loaded fast enough for a PWA. Given how geographically distributed the web is, having a fast load time with lighter pages matter the most of the next billion users of the web, most of whom will be introduced to the internet via a mobile device.
diff --git a/src/content/en/2020/security.md b/src/content/en/2020/security.md
index c3aae40ba9f..66ac526ba82 100644
--- a/src/content/en/2020/security.md
+++ b/src/content/en/2020/security.md
@@ -623,7 +623,7 @@ In a similar fashion, by defining the `allow` attribute on `
