From 0a0a8dcaf4fd821aebe0f12171ee2122e25d73c2 Mon Sep 17 00:00:00 2001
From: Dave Smart <dave@tamethebots.com>
Date: Mon, 30 Dec 2024 19:14:16 +0000
Subject: [PATCH 1/4] fixes typo Mopbile > Mobile (#3984)

---
 src/content/en/2024/page-weight.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/content/en/2024/page-weight.md b/src/content/en/2024/page-weight.md
index f3db4dcbad2..aa1cc1fe54c 100644
--- a/src/content/en/2024/page-weight.md
+++ b/src/content/en/2024/page-weight.md
@@ -252,7 +252,7 @@ In comparing homepages to inner pages, we saw that homepages consistently called
 JavaScript is a high-level, dynamic and interpreted programming language. It is one of the core technologies of the web, enabling interactive web pages and web applications. JavaScript allows developers to add interactivity, animations, and effects to web pages. This includes features such as drop-down menus, image sliders, personalized content, and analytics tracking.
 
 {{ figure_markup(
-  caption="Mopbile home pages using JavaScript.",
+  caption="Mobile home pages using JavaScript.",
   content="97.8%",
   classes="big-number",
   sheets_gid="799485869",

From 3b516f7214a4a85040fb8e4627855d485bf390eb Mon Sep 17 00:00:00 2001
From: Mike Gifford <mike.gifford@civicactions.com>
Date: Thu, 2 Jan 2025 12:26:09 -0500
Subject: [PATCH 2/4] Update accessibility.md (#3985)

* Update accessibility.md

Adding an update for manifests and limitations of our survey.

* Put in aside

---------

Co-authored-by: Barry Pollard <barrypollard@google.com>
---
 src/content/en/2024/accessibility.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/content/en/2024/accessibility.md b/src/content/en/2024/accessibility.md
index 8cea60c402b..e9553934b61 100644
--- a/src/content/en/2024/accessibility.md
+++ b/src/content/en/2024/accessibility.md
@@ -562,6 +562,8 @@ The `<track>` element is used to provide timed text for `<audio>` and `<video>`
 
 For `<video>` elements, the figure is slightly higher at 0.5% for both desktops and 0.65% for mobile sites. These statistics do not cover audio or video embedded via `<iframe>`, where third-party services are less likely to offer text alternatives. Our industry can do a lot better.
 
+<aside class="note">The methodology to collect the data for this report did not include modern HLS (HTTP Live Streaming) which would would include a manifest file to include subtitles for the deaf and hard-of-hearing (SDH). In the future, scanning for this would allow better understanding of what languages are supported with closed captions and also collect information about the use of audio description.</aside>
+
 ## Assistive technology with ARIA
 
 <a hreflang="en" href="https://www.w3.org/TR/using-aria/">Accessible Rich Internet Applications (ARIA)</a> provides a set of attributes for HTML5 elements designed to enhance web accessibility for individuals with disabilities. However, excessive use of ARIA attributes can sometimes create more problems than it solves. ARIA should be employed only when native HTML5 elements are inadequate for ensuring a fully accessible experience and should not replace or be used beyond what is necessary.

From 6e864c6691c3088b35ab7632a689586dd5b7b6c8 Mon Sep 17 00:00:00 2001
From: Barry Pollard <barrypollard@google.com>
Date: Thu, 2 Jan 2025 19:40:32 +0000
Subject: [PATCH 3/4] Put notes in asides (#3986)

---
 src/content/en/2019/accessibility.md               |  2 +-
 src/content/en/2019/cdn.md                         |  8 ++++----
 src/content/en/2019/css.md                         |  2 +-
 src/content/en/2019/ecommerce.md                   |  4 ++--
 src/content/en/2019/javascript.md                  |  2 +-
 src/content/en/2019/markup.md                      |  4 ++--
 src/content/en/2019/media.md                       |  4 ++--
 src/content/en/2019/mobile-web.md                  | 10 +++++-----
 src/content/en/2019/page-weight.md                 |  2 +-
 src/content/en/2019/performance.md                 |  2 +-
 src/content/en/2019/resource-hints.md              |  2 +-
 src/content/en/2019/seo.md                         |  6 +++---
 src/content/en/2019/third-parties.md               |  4 ++--
 src/content/en/2020/caching.md                     |  4 ++--
 src/content/en/2020/css.md                         |  2 +-
 src/content/en/2020/ecommerce.md                   |  8 ++++----
 src/content/en/2020/http.md                        |  4 ++--
 src/content/en/2020/jamstack.md                    |  2 +-
 src/content/en/2020/javascript.md                  |  4 ++--
 src/content/en/2020/markup.md                      | 14 +++++++-------
 src/content/en/2020/media.md                       |  4 ++--
 src/content/en/2020/mobile-web.md                  |  4 ++--
 src/content/en/2020/pwa.md                         |  2 +-
 src/content/en/2020/security.md                    |  6 +++---
 src/content/en/2020/seo.md                         |  4 ++--
 src/content/en/2021/accessibility.md               |  4 ++--
 src/content/en/2021/cdn.md                         |  2 +-
 src/content/en/2021/cms.md                         |  4 ++--
 src/content/en/2021/ecommerce.md                   |  4 ++--
 src/content/en/2021/http.md                        |  2 +-
 src/content/en/2021/jamstack.md                    |  2 +-
 src/content/en/2021/markup.md                      |  2 +-
 src/content/en/2021/page-weight.md                 |  2 +-
 src/content/en/2021/performance.md                 |  6 +++---
 src/content/en/2021/privacy.md                     |  6 +++---
 src/content/en/2021/pwa.md                         | 12 ++++++------
 src/content/en/2021/resource-hints.md              |  6 +++---
 src/content/en/2021/security.md                    |  4 ++--
 src/content/en/2021/third-parties.md               |  2 +-
 src/content/en/2022/cdn.md                         |  2 +-
 src/content/en/2022/jamstack.md                    |  2 +-
 src/content/en/2022/markup.md                      |  2 +-
 src/content/en/2022/media.md                       |  2 +-
 src/content/en/2022/performance.md                 |  2 +-
 src/content/en/2022/security.md                    |  4 ++--
 src/content/en/2022/sustainability.md              |  6 +++---
 src/content/en/2024/fonts.md                       |  6 +++---
 src/content/en/2024/http.md                        |  8 ++++----
 src/content/en/2024/media.md                       |  4 ++--
 src/content/en/2024/privacy.md                     |  2 +-
 src/content/en/2024/third-parties.md               |  4 ++--
 src/content/es/2019/css.md                         |  2 +-
 src/content/es/2019/ecommerce.md                   |  4 ++--
 src/content/es/2019/markup.md                      |  4 ++--
 src/content/es/2019/media.md                       |  4 ++--
 src/content/es/2019/performance.md                 |  2 +-
 src/content/es/2020/ecommerce.md                   |  8 ++++----
 src/content/es/2020/http.md                        |  4 ++--
 src/content/es/2020/javascript.md                  |  4 ++--
 src/content/es/2020/seo.md                         |  4 ++--
 src/content/fr/2019/accessibility.md               |  2 +-
 src/content/fr/2019/css.md                         |  2 +-
 src/content/fr/2019/javascript.md                  |  2 +-
 src/content/fr/2019/markup.md                      |  4 ++--
 src/content/fr/2019/media.md                       |  4 ++--
 src/content/fr/2019/mobile-web.md                  | 10 +++++-----
 src/content/fr/2019/resource-hints.md              |  2 +-
 src/content/fr/2019/seo.md                         |  6 +++---
 src/content/fr/2019/third-parties.md               |  4 ++--
 src/content/fr/2022/jamstack.md                    |  4 ++--
 src/content/it/2020/css.md                         |  2 +-
 src/content/it/2020/http.md                        |  4 ++--
 src/content/it/2020/javascript.md                  |  4 ++--
 src/content/it/2020/markup.md                      | 14 +++++++-------
 src/content/it/2020/seo.md                         |  4 ++--
 src/content/it/2022/markup.md                      |  2 +-
 src/content/ja/2019/accessibility.md               |  2 +-
 src/content/ja/2019/cdn.md                         |  8 ++++----
 src/content/ja/2019/css.md                         |  2 +-
 src/content/ja/2019/ecommerce.md                   |  4 ++--
 src/content/ja/2019/javascript.md                  |  2 +-
 src/content/ja/2019/markup.md                      |  4 ++--
 src/content/ja/2019/media.md                       |  4 ++--
 src/content/ja/2019/mobile-web.md                  | 10 +++++-----
 src/content/ja/2019/page-weight.md                 |  2 +-
 src/content/ja/2019/performance.md                 |  2 +-
 src/content/ja/2019/resource-hints.md              |  2 +-
 src/content/ja/2019/seo.md                         |  6 +++---
 src/content/ja/2019/third-parties.md               |  4 ++--
 src/content/ja/2020/caching.md                     |  4 ++--
 src/content/ja/2020/css.md                         |  2 +-
 src/content/ja/2020/ecommerce.md                   |  8 ++++----
 src/content/ja/2020/http.md                        |  4 ++--
 src/content/ja/2020/jamstack.md                    |  2 +-
 src/content/ja/2020/javascript.md                  |  4 ++--
 src/content/ja/2020/markup.md                      | 14 +++++++-------
 src/content/ja/2020/media.md                       |  4 ++--
 src/content/ja/2020/mobile-web.md                  |  4 ++--
 src/content/ja/2020/pwa.md                         |  2 +-
 src/content/ja/2020/security.md                    |  6 +++---
 src/content/ja/2020/seo.md                         |  4 ++--
 src/content/ja/2021/accessibility.md               |  4 ++--
 src/content/ja/2021/cdn.md                         |  2 +-
 src/content/ja/2021/cms.md                         |  4 ++--
 src/content/ja/2021/ecommerce.md                   |  4 ++--
 src/content/ja/2021/http.md                        |  2 +-
 src/content/ja/2021/jamstack.md                    |  2 +-
 src/content/ja/2021/markup.md                      |  2 +-
 src/content/ja/2021/page-weight.md                 |  2 +-
 src/content/ja/2021/performance.md                 |  6 +++---
 src/content/ja/2021/privacy.md                     |  6 +++---
 src/content/ja/2021/pwa.md                         | 12 ++++++------
 src/content/ja/2021/resource-hints.md              |  6 +++---
 src/content/ja/2021/security.md                    |  4 ++--
 src/content/ja/2021/third-parties.md               |  2 +-
 src/content/ja/2022/cdn.md                         |  2 +-
 src/content/ja/2022/jamstack.md                    |  4 ++--
 src/content/ja/2022/markup.md                      |  2 +-
 src/content/ja/2022/media.md                       |  2 +-
 src/content/ja/2022/performance.md                 |  2 +-
 src/content/ja/2022/security.md                    |  4 ++--
 src/content/ja/2022/sustainability.md              |  6 +++---
 src/content/nl/2019/accessibility.md               |  2 +-
 src/content/nl/2020/caching.md                     |  4 ++--
 src/content/nl/2020/ecommerce.md                   |  8 ++++----
 src/content/nl/2020/http.md                        |  4 ++--
 src/content/nl/2020/jamstack.md                    |  2 +-
 src/content/nl/2020/markup.md                      | 14 +++++++-------
 src/content/nl/2020/media.md                       |  4 ++--
 src/content/nl/2020/mobile-web.md                  |  4 ++--
 src/content/nl/2020/pwa.md                         |  2 +-
 src/content/nl/2020/security.md                    |  6 +++---
 src/content/nl/2021/privacy.md                     |  6 +++---
 src/content/pt/2019/css.md                         |  2 +-
 src/content/pt/2019/ecommerce.md                   |  4 ++--
 src/content/pt/2019/javascript.md                  |  2 +-
 src/content/pt/2019/resource-hints.md              |  2 +-
 src/content/pt/2020/css.md                         |  2 +-
 src/content/pt/2022/cdn.md                         |  2 +-
 src/content/ru/2020/css.md                         |  2 +-
 src/content/ru/2021/pwa.md                         | 12 ++++++------
 src/content/zh-CN/2019/accessibility.md            |  2 +-
 src/content/zh-CN/2019/performance.md              |  2 +-
 src/content/zh-CN/2022/security.md                 |  4 ++--
 src/templates/en/2019/methodology.html             |  8 ++++----
 src/templates/en/2020/methodology.html             |  4 ++--
 src/templates/en/2021/methodology.html             |  4 ++--
 src/templates/en/2022/methodology.html             |  4 ++--
 src/templates/en/2024/methodology.html             |  4 ++--
 src/templates/fr/2019/methodology.html             |  8 ++++----
 src/templates/fr/2020/methodology.html             |  4 ++--
 src/templates/hi/2019/methodology.html             |  8 ++++----
 src/templates/hi/2020/methodology.html             |  4 ++--
 src/templates/ja/2019/methodology.html             |  8 ++++----
 src/templates/ja/2020/methodology.html             |  4 ++--
 src/templates/ja/2021/methodology.html             |  4 ++--
 src/templates/ja/2022/methodology.html             |  4 ++--
 src/templates/nl/2019/methodology.html             |  8 ++++----
 src/templates/nl/2020/methodology.html             |  4 ++--
 src/templates/pt/2019/methodology.html             |  8 ++++----
 src/templates/ru/2019/methodology.html             |  8 ++++----
 src/templates/ru/2020/methodology.html             |  4 ++--
 src/templates/zh-CN/2019/methodology.html          |  8 ++++----
 src/templates/zh-CN/2020/methodology.html          |  4 ++--
 src/templates/zh-TW/2020/methodology.html          |  4 ++--
 .../generate_extra_markdown_conversions.js         |  1 +
 166 files changed, 359 insertions(+), 358 deletions(-)

diff --git a/src/content/en/2019/accessibility.md b/src/content/en/2019/accessibility.md
index bbbedd91c74..a1d063b970f 100644
--- a/src/content/en/2019/accessibility.md
+++ b/src/content/en/2019/accessibility.md
@@ -57,7 +57,7 @@ In order to make sure your website is readable under these conditions, making su
 
 Only 22.04% of sites gave all of their text sufficient color contrast. Or in other words: 4 out of every 5 sites have text which easily blends into the background, making it unreadable.
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 ### 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.
 
-<p class="note">Note: This does not reflect traffic or usage, only the number of sites using them.</p>
+<aside class="note">Note: This does not reflect traffic or usage, only the number of sites using them.</aside>
 
 {{ 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!
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 {{ 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.
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 {{ 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.
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 {{ 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?
 
-<p class="note">An earlier version of this chapter discussed the unexpected popularity of the <code>Q</code> unit. Thanks to the <a hreflang="en" href="https://discuss.httparchive.org/t/chapter-2-css/1757/6">community discussion</a> surrounding this chapter, we've identified that this was a bug in our analysis and have updated Figure 2.5 accordingly.</p>
+<aside class="note">An earlier version of this chapter discussed the unexpected popularity of the <code>Q</code> unit. Thanks to the <a hreflang="en" href="https://discuss.httparchive.org/t/chapter-2-css/1757/6">community discussion</a> surrounding this chapter, we've identified that this was a bug in our analysis and have updated Figure 2.5 accordingly.</aside>
 
 ### 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
   )
 }}
 
-<p class="note">Note that because our data collection <a href="./methodology">methodology</a> does not simulate user interactions on pages like clicking or scrolling, images that are lazy loaded would not be represented in these results.</p>
+<aside class="note">Note that because our data collection <a href="./methodology">methodology</a> does not simulate user interactions on pages like clicking or scrolling, images that are lazy loaded would not be represented in these results.</aside>
 
 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
   )
 }}
 
-<p class="note">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, <a hreflang="en" href="https://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg">IMG_20190113_113201.jpg</a> returns a WebP image in Chrome. However, the way HTTP Archive <a hreflang="en" href="https://github.com/HTTPArchive/legacy.httparchive.org/blob/31a25b9064a365d746d4811a1d6dda516c0e4985/bulktest/batch_lib.inc#L994">detects image formats</a> 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.</p>
+<aside class="note">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, <a hreflang="en" href="https://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg">IMG_20190113_113201.jpg</a> returns a WebP image in Chrome. However, the way HTTP Archive <a hreflang="en" href="https://github.com/HTTPArchive/legacy.httparchive.org/blob/31a25b9064a365d746d4811a1d6dda516c0e4985/bulktest/batch_lib.inc#L994">detects image formats</a> 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.</aside>
 
 ### 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
 
-<p class="note">As mentioned in our <a href="./methodology#wappalyzer">methodology</a>, 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 <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/issues/2450">to improve detection of JavaScript libraries and frameworks</a>, which will have impacted the results presented here.</p>
+<aside class="note">As mentioned in our <a href="./methodology#wappalyzer">methodology</a>, 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 <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/issues/2450">to improve detection of JavaScript libraries and frameworks</a>, which will have impacted the results presented here.</aside>
 
 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.
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 ## 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.
 
-<p class="note">Note: A lot of this is very likely due to the use of products rather than individual authors continuing to manually create this markup.</p>
+<aside class="note">Note: A lot of this is very likely due to the use of products rather than individual authors continuing to manually create this markup.</aside>
 
 {{ 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.
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 {{ 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
 
-<p class="note">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 <a href="./methodology">Methodology</a>.</p>
+<aside class="note">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 <a href="./methodology">Methodology</a>.</aside>
 
 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!
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 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.
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 ## 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.
 
-<p class="note">Note: While this is very encouraging, this may be an underestimation due to the requirement of our <a href="./methodology">Methodology</a> to only test home pages. Interior pages, like login pages, are not tested.</p>
+<aside class="note">Note: While this is very encouraging, this may be an underestimation due to the requirement of our <a href="./methodology">Methodology</a> to only test home pages. Interior pages, like login pages, are not tested.</aside>
 
 ## Conclusion
 
@@ -297,7 +297,7 @@ The mobile web has now been around long enough for there to be an entire generat
   )
 }}
 
-<p class="note" data-markdown="1">Notes:
+<aside class="note" data-markdown="1">Notes:
 
 1. We defined sites making a mobile effort as those who adjust their designs for smaller screens. Or rather, those which have at least one CSS breakpoint at 600px or less.
 
@@ -308,4 +308,4 @@ The mobile web has now been around long enough for there to be an entire generat
 4. The total number of active smartphones was found by totaling the number of active Androids and iPhones (made public by Apple and Google), and a bit of math to account for Chinese internet-connected phones. <a hreflang="en" href="https://www.ben-evans.com/benedictevans/2019/5/28/the-end-of-mobile">More info here</a>.
 
 5. The 1.6 billion desktops is calculated by numbers made public by <a hreflang="en" href="https://web.archive.org/web/20181030132235/https://news.microsoft.com/bythenumbers/en/windowsdevices">Microsoft</a> and <a hreflang="en" href="https://web.archive.org/web/20190628161024/https://appleinsider.com/articles/18/10/30/apple-passes-100m-active-mac-milestone-thanks-to-high-numbers-of-new-users">Apple</a>. It does not include linux PC users.
-</p>
+</aside>
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.
 
-<p class="note" data-markdown="1">Check out Tim Kadlec's fascinating online calculator, <a hreflang="en" href="https://whatdoesmysitecost.com/">What Does My Site Cost?</a>, 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?</p>
+<aside class="note">Check out Tim Kadlec's fascinating online calculator, <a hreflang="en" href="https://whatdoesmysitecost.com/">What Does My Site Cost?</a>, 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?</aside>
 
 ### 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.
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 In order to categorize whether a website is sufficiently **fast** we will use the new <a hreflang="en" href="https://developers.google.com/speed/docs/insights/v5/about#categories">PageSpeed Insights</a> (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
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 <figure>
   <table>
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.
 
-<p class="note">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 <a href="./methodology">Methodology</a>.</p>
+<aside class="note">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 <a href="./methodology">Methodology</a>.</aside>
 
 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 <a hreflang="en" href="https://developers.google.com/search/mobile-sites/mobile-seo/separate-urls">mobile home pages were alternates</a> to an equivalent desktop page, such as on non-responsive sites that have separate versions of the website for each device.
 
-<p class="note">Note: Our results didn't include <code>4xx</code> or <code>5xx</code> status codes.</p>
+<aside class="note">Note: Our results didn't include <code>4xx</code> or <code>5xx</code> status codes.</aside>
 
 #### `noindex`
 
@@ -154,7 +154,7 @@ A `noindex` directive can be served in the HTML `<head>` or in the HTTP headers
 
 96.93% of mobile pages passed the <a hreflang="en" href="https://developers.google.com/web/tools/lighthouse/audits/indexing">Lighthouse indexing audit</a>, 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.
 
-<p class="note">The websites included in our research are sourced from the <a href="./methodology#chrome-ux-report">Chrome UX Report</a> 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 <a href="./methodology#websites">methodology</a>.</p>
+<aside class="note">The websites included in our research are sourced from the <a href="./methodology#chrome-ux-report">Chrome UX Report</a> 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 <a href="./methodology#websites">methodology</a>.</aside>
 
 #### 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
 
-<p class="note">
+<aside class="note">
   <strong>Note on CDNs</strong>: The CDN category here includes providers that provide resources on <strong>public</strong> CDN domains (e.g. bootstrapcdn.com, cdnjs.cloudflare.com, etc.) and does <strong>not</strong> include resources that are simply served over a CDN. i.e. putting Cloudflare in front of a page would not influence its first-party designation according to our criteria.
-</p>
+</aside>
 
 ### 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.
   )
 }}
 
-<p class="note">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.
+<aside class="note">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.</p>
+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.</aside>
 
 ## 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.
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 ## 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.
 
-<p class="note">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 <a href="../2019/ecommerce">2019 Ecommerce</a> chapter.</p>
+<aside class="note">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 <a href="../2019/ecommerce">2019 Ecommerce</a> chapter.</aside>
 
 ### 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.
 
-<p class="note">Note: <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/pull/2731/commits/f44f20f03618f6a5fd868dd38ce9db5e2e2f1407">Wappalyzer detection for Wix</a> 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.</p>
+<aside class="note">Note: <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/pull/2731/commits/f44f20f03618f6a5fd868dd38ce9db5e2e2f1407">Wappalyzer detection for Wix</a> 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.</aside>
 
 ## 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"
 ) }}
 
-<p class="note">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 <code>.jpg</code> or <code>.png</code> suffix. For example, <code>IMG_20190113_113201.jpg</code> 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.</p>
+<aside class="note">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 <code>.jpg</code> or <code>.png</code> suffix. For example, <code>IMG_20190113_113201.jpg</code> 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.</aside>
 
 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 <a hreflang="en" href="https://web.dev/replace-gifs-with-videos/">this article</a> for more details.
 
@@ -437,7 +437,7 @@ Adoption of server-side tagging will depend on third parties to provide server s
   <figcaption>{{ figure_link(caption="Tag manager usage on ecommerce sites.", sheets_gid="2045910168", sql_file="percent_of_ecommsites_using_each_tag_managers.sql") }}</figcaption>
 </figure>
 
-<p class="note">Note: Above analysis is based on Wappalyzer detection which may differ from analysis done using <a href="./methodology#third-party-web">Third Party Web</a> dataset which is used for <a href="./third-parties">Third parties</a> chapter.</p>
+<aside class="note">Note: Above analysis is based on Wappalyzer detection which may differ from analysis done using <a href="./methodology#third-party-web">Third Party Web</a> dataset which is used for <a href="./third-parties">Third parties</a> chapter.</aside>
 
 ### 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
   <figcaption>{{ figure_link(caption="HTTP version usage by request.", sheets_gid="2122693316", sql_file="adoption_of_http_2_by_site_and_requests.sql") }}</figcaption>
 </figure>
 
-<p class="note">
+<aside class="note">
   ** 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.
-</note>
+</aside>
 
 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 <a hreflang="en" href="https://httparchive.org/">HTTP Archive</a> crawls <a
 
 The goals of this chapter are to estimate and analyze the growth of the Jamstack sites, the performance of popular Jamstack frameworks, as well as an analysis of real user experience using the Core Web Vitals metrics.
 
-<p class="note">It should be noted that our analysis is limited by those Jamstacks that make themselves easily identifiable using <a href="./methodology#wappalyzer">Wappalyzer</a>. This means our data does not include some popular Jamstacks like <a hreflang="en" href="https://github.com/11ty/eleventy/">Eleventy</a> which <a href="https://x.com/eleven_ty/status/1334225624110608387?s=20">make a deliberate choice to not make themselves identifiable</a>. While we would ideally include all Jamstacks, we believe there is still plenty of value in analyzing the significant data we do have.</p>
+<aside class="note">It should be noted that our analysis is limited by those Jamstacks that make themselves easily identifiable using <a href="./methodology#wappalyzer">Wappalyzer</a>. This means our data does not include some popular Jamstacks like <a hreflang="en" href="https://github.com/11ty/eleventy/">Eleventy</a> which <a href="https://x.com/eleven_ty/status/1334225624110608387?s=20">make a deliberate choice to not make themselves identifiable</a>. While we would ideally include all Jamstacks, we believe there is still plenty of value in analyzing the significant data we do have.</aside>
 
 ## 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.
 
-<p class="note">
+<aside class="note">
   As an aside, when we talked about how much JavaScript is loaded on a page earlier, that total didn't account for the size of these inline scripts—because they're part of the HTML document, they're counted against the markup size. This means we load even more script that the numbers show.
-</p>
+</aside>
 
 {{ 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.
 
-<p class="note">
+<aside class="note">
   In this Markup chapter, we're focusing almost exclusively on HTML, rather than SVG or MathML, which are also considered markup languages. Unless otherwise noted, stats presented in this chapter refer to the set of mobile pages. Additionally, the data for all Web Almanac chapters is open and available. Take a look at <a hreflang="en" href="https://docs.google.com/spreadsheets/d/1Ta7amoUeaL4pILhWzH-SCzMX9PsZeb1x_mwrX2C4eY8/">the results</a> and <a hreflang="en" href="https://discuss.httparchive.org/t/2039">share your observations</a> with the community!
-</p>
+</aside>
 
 ## 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`.
 
-<p class="note">
+<aside class="note">
   For a while now, the Edge mobile browser allows users to zoom into a web page to <a hreflang="en" href="https://blogs.windows.com/windows-insider/2017/01/12/announcing-windows-10-insider-preview-build-15007-pc-mobile/">at least 500%</a>, regardless of the zoom settings defined by a web page employing the viewport meta element.
-</p>
+</aside>
 
 ### Favicons
 
@@ -1306,7 +1306,7 @@ Using `target="_blank"` has been known to be a <a hreflang="en" href="https://ma
 
 As a rule of thumb and for <a hreflang="en" href="https://www.nngroup.com/articles/new-browser-windows-and-tabs/">usability reasons</a>, it is recommended not to use `target="_blank"` in the first place.
 
-<p class="note">Within the latest Safari and Firefox versions, setting <code>target="_blank"</code> on <code>a</code> elements implicitly provides the same <code>rel</code> behavior as setting <code>rel="noopener"</code>. This is already <a hreflang="en" href="https://chromium-review.googlesource.com/c/chromium/src/+/1630010">implemented in Chromium</a> as well and will land in Chrome 88.</p>
+<aside class="note">Within the latest Safari and Firefox versions, setting <code>target="_blank"</code> on <code>a</code> elements implicitly provides the same <code>rel</code> behavior as setting <code>rel="noopener"</code>. This is already <a hreflang="en" href="https://chromium-review.googlesource.com/c/chromium/src/+/1630010">implemented in Chromium</a> as well and will land in Chrome 88.</aside>
 
 ## 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.
 
-<p class="note">
+<aside class="note">
   We're leaving the rest open to you. What are your observations? What has caught your eye? What do you think has taken a turn for the worse, and what has improved? <a hreflang="en" href="https://discuss.httparchive.org/t/2039">Leave a comment</a> to share your thoughts!
-</p>
+</aside>
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 `<picture>` for format-switching, around 68% are offering a singl
 
 We see that WebP is the dominant usage across `<source>` elements, followed by PNG, and that and JPG is only 4.83% of `<picture>` usage.
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 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.
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 ##### 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.
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 ## Mobile web & desktop traffic trends
 
@@ -51,7 +51,7 @@ A <a hreflang="en" href="https://www.perficient.com/insights/research-hub/mobile
 
 Note that this section references stats that have been made available specifically for this chapter from non-public Chrome data source, [see details here](#data-sources). We use this data to assess page loads on Android and Windows—as a proxy for mobile and desktop respectively.
 
-<p class="note">NOTE: we may refer to the data in this section as mobile for Android and desktop for Windows.</p>
+<aside class="note">NOTE: we may refer to the data in this section as mobile for Android and desktop for Windows.</aside>
 
 #### Page loads across origins ranked by popularity
 
diff --git a/src/content/en/2020/pwa.md b/src/content/en/2020/pwa.md
index b7ba59c8108..253490250ab 100644
--- a/src/content/en/2020/pwa.md
+++ b/src/content/en/2020/pwa.md
@@ -141,7 +141,7 @@ While that usage may seem low, it is important that we realize that other measur
   <figcaption>{{ figure_link(caption="Lighthouse PWA audits.", sheets_gid="814184412", sql_file="lighthouse_pwa_audits.sql") }}</figcaption>
 </figure>
 
-<p class="note">Note the performance statistic for our Lighthouse tests were incorrect for our August crawl so the <code>load-fast-enough-for-pwa</code> result has been replaced with September results.</p>
+<aside class="note">Note the performance statistic for our Lighthouse tests were incorrect for our August crawl so the <code>load-fast-enough-for-pwa</code> result has been replaced with September results.</aside>
 
 A <a hreflang="en" href="https://web.dev/load-fast-enough-for-pwa/">fast page load</a> 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 `<iframe>` elements,
 
 The `Feature-Policy` response header has a fairly low adoption rate, at 0.60% of the desktop pages and 0.51% of mobile pages. On the other hand, Feature Policy was enabled on 11.8% of the 13.2 million frames that were found on the desktop pages. On mobile pages, 10.8% of the 13.9 million frames contained the `allow` attribute.
 
-<p class="note">An earlier version of this chapter reported incorrect values for the total number of frames and the percentage of frames with the `allow` attribute. More information can be found in this <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</p>
+<aside class="note">An earlier version of this chapter reported incorrect values for the total number of frames and the percentage of frames with the `allow` attribute. More information can be found in this <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</aside>
 
 Based on the most commonly used directives in the Feature Policy on iframes, we can see that these are mainly used to control how the frames play videos. For instance the most prevalent directive, `encrypted-media`, is used to control access to the Encrypted Media Extensions API, which is required to play DRM-protected videos. The most common iframe origins with a Feature Policy were `https://www.facebook.com` and `https://www.youtube.com` (49.87% and 26.18% of the frames with a Feature Policy on desktop pages respectively).
 
@@ -633,7 +633,7 @@ By including an untrusted third-party in an iframe, that third-party can try to
 
 The `sandbox` attribute on iframes can be used to restrict the capabilities, and therefore also the opportunities for launching attacks, of the embedded web page. As embedding third-party content such as advertisements or videos is common practice on the web, it is not surprising that many of these are restricted via the `sandbox` attribute: 18.3% of the iframes on desktop pages have a `sandbox` attribute while on mobile pages this is 21.9%.
 
-<p class="note">An earlier version of this chapter reported incorrect values for the percentage of frames with the `sandbox` attribute. More information can be found in this <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</p>
+<aside class="note">An earlier version of this chapter reported incorrect values for the percentage of frames with the `sandbox` attribute. More information can be found in this <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</aside>
 
 <figure>
   <table>
@@ -838,7 +838,7 @@ The <a hreflang="en" href="https://www.w3.org/TR/WebCryptoAPI/">Web Cryptography
 
 Our results show that the  `Cypto.getRandomValues` function, which allows for generating a random number (in a secure, cryptographic manner) is by far the most widely used one (desktop: 70% and mobile: 68%). We believe Google Analytic's use of this function has a major effect on the usage measured. In general, we see that mobile websites perform slightly fewer cryptographic operations, although mobile browsers [fully support](https://developer.mozilla.org/docs/Web/API/Web_Crypto_API#Browser_compatibility) this API.
 
-<p class="note">It should be noted that, since we perform passive crawling, our results in this section will be limited by this. We're not able to identify cases where any interaction is required before the functions are executed.</p>
+<aside class="note">It should be noted that, since we perform passive crawling, our results in this section will be limited by this. We're not able to identify cases where any interaction is required before the functions are executed.</aside>
 
 ### Utilizing bot protection services
 
diff --git a/src/content/en/2020/seo.md b/src/content/en/2020/seo.md
index cef38f3bad9..d97ba78a392 100644
--- a/src/content/en/2020/seo.md
+++ b/src/content/en/2020/seo.md
@@ -425,9 +425,9 @@ The growth of these objects is a general indication of increased adoption of str
 * `HowTo` markup grew 605% on desktop and 623% on mobile.
 * `QAPage` markup grew 166.7% on desktop and 192.1% on mobile.
 
-<p class="note">
+<aside class="note">
   Again, it's important to note that this data might not be representative of their actual level of growth, since these objects are usually placed on internal pages.
-</p>
+</aside>
 
 The adoption of structured data is a boon for the web as extracting data is valuable to a wealth of use cases. We expect this to continue to grow as search engines expand their usage and as it begins to power applications beyond web search.
 
diff --git a/src/content/en/2021/accessibility.md b/src/content/en/2021/accessibility.md
index 27821794b45..6c04d1c14ae 100644
--- a/src/content/en/2021/accessibility.md
+++ b/src/content/en/2021/accessibility.md
@@ -49,7 +49,7 @@ We've split up our most interesting insights into six categories:
 
 We hope that this chapter, full of sobering metrics and demonstrable accessibility negligence on the Web, will inspire readers to prioritize this work and change their practices, shifting towards a more inclusive internet.
 
-<p class="note">We chose to use the person-first term "people with disabilities" throughout this chapter. We acknowledge that the identity-first term "disabled people" is preferred for many. Our choice in terminology is in no way prescriptive of which term is appropriate.</p>
+<aside class="note">We chose to use the person-first term "people with disabilities" throughout this chapter. We acknowledge that the identity-first term "disabled people" is preferred for many. Our choice in terminology is in no way prescriptive of which term is appropriate.</aside>
 
 ## Ease of reading
 
@@ -673,7 +673,7 @@ The `aria-labelledby` attribute accepts an `id` reference as its value, which as
 
 The `aria-describedby` attribute can be used in cases where a more robust description is needed for an element. It also accepts an id reference as its value to connect with descriptive text that exists elsewhere in the interface. It does not supply the accessible name; it should be used in conjunction with an accessible name as a supplement, not a replacement. We found that 13% of desktop pages and 12% of mobile pages had at least one element with the `aria-describedby` attribute.
 
-<p class="note">Fun fact! We found 1,886 websites with the attribute `aria-lavel`, which is a misspelling of the `aria-label` attribute! Be sure to run those automated checks to pick up these easily avoidable errors.</p>
+<aside class="note">Fun fact! We found 1,886 websites with the attribute `aria-lavel`, which is a misspelling of the `aria-label` attribute! Be sure to run those automated checks to pick up these easily avoidable errors.</aside>
 
 #### Where do buttons get their accessible names from?
 
diff --git a/src/content/en/2021/cdn.md b/src/content/en/2021/cdn.md
index 2cc075b1e8e..ae7d9b82553 100644
--- a/src/content/en/2021/cdn.md
+++ b/src/content/en/2021/cdn.md
@@ -288,7 +288,7 @@ CDNs act as the proxy to bridge the gap by providing a layer to consolidate host
 
 The trend cannot be clearer than what the graph shows below. There is high HTTP/2+ adoption by domains on CDNs compared to the ones not using a CDN.
 
-<p class="note">Note that due to the way HTTP/3 works (see the [HTTP](./http) chapter for more information), HTTP/3 is often not used for first connections which is why we are instead measuring "HTTP/2+", since many of those HTTP/2 connections may actually be HTTP/3 for repeat visitors (we have assumed that no servers implement HTTP/3 without HTTP/3).</p>
+<aside class="note">Note that due to the way HTTP/3 works (see the [HTTP](./http) chapter for more information), HTTP/3 is often not used for first connections which is why we are instead measuring "HTTP/2+", since many of those HTTP/2 connections may actually be HTTP/3 for repeat visitors (we have assumed that no servers implement HTTP/3 without HTTP/3).</aside>
 
 {{ figure_markup(
   image="http-versions-desktop.png",
diff --git a/src/content/en/2021/cms.md b/src/content/en/2021/cms.md
index 46167ccb2e8..4248d3d4a0f 100644
--- a/src/content/en/2021/cms.md
+++ b/src/content/en/2021/cms.md
@@ -35,7 +35,7 @@ In some of the sections, we focus only on the top CMSs in terms of adoption, due
 
 Let's dive into our analysis.
 
-<p class="note">**Disclaimer:** Alon works at Wix where he leads the web performance efforts, but opinions are his own.</a>
+<aside class="note">**Disclaimer:** Alon works at Wix where he leads the web performance efforts, but opinions are his own.</aside>
 
 ## What is a CMS?
 
@@ -215,7 +215,7 @@ In July, for mobile devices, TYPO3 CMS (used mostly in European countries) had t
 
 Desktop device experience was slightly better, with 1C-Bitrix (used mostly in Russia) having the largest percentage of 56% sites passing CWVs. WordPress had the lowest ratio of passing sites, with only 26%.
 
-<p class="note">Duda deserves an honorable mention, with 47% sites passing in August and overall great progress since last year. They were not included in this report due to broken data collection in July, related to a wrong detection in <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/pull/4189">Wappalyzer</a>, incorrectly inflating their origins, and reducing their CWV percentage.</p>
+<aside class="note">Duda deserves an honorable mention, with 47% sites passing in August and overall great progress since last year. They were not included in this report due to broken data collection in July, related to a wrong detection in <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/pull/4189">Wappalyzer</a>, incorrectly inflating their origins, and reducing their CWV percentage.</aside>
 
 We can also evaluate the progress of these CMS platforms compared to last year's data, focusing on mobile views:
 
diff --git a/src/content/en/2021/ecommerce.md b/src/content/en/2021/ecommerce.md
index 1d126614780..a8e7d98da27 100644
--- a/src/content/en/2021/ecommerce.md
+++ b/src/content/en/2021/ecommerce.md
@@ -102,7 +102,7 @@ Our analysis detected 215 ecommerce platforms, a 48% increase in platforms compa
 
 6 of the 10 platforms are SaaS (or have SaaS versions): Shopify, <a hreflang="en" href="https://www.wix.com/ecommerce/website">Wix eCommerce</a>, <a hreflang="en" href="https://www.squarespace.com/ecommerce-website">Squarespace Commerce</a>, <a hreflang="en" href="https://www.bigcommerce.com/">BigCommerce</a>, Shopware, and <a hreflang="pt" href="https://lojaintegrada.com.br/">Loja Integrada</a>.
 
-<p class="note">Note: There was <a hreflang="en" href="https://github.com/HTTPArchive/httparchive.org/issues/414">an issue</a> with the July 2021 HTTP Archive data which resulted in the number of <a hreflang="en" href="https://www.opencart.com/">OpenCart</a> sites being under-reported. It is worth acknowledging that in the September results 10,801 OpenCart sites were detected. If a similar number of OpenCart sites were to have been detected in July, it would put it in between BigCommerce and Shopware in terms of popularity.</p>
+<aside class="note">Note: There was <a hreflang="en" href="https://github.com/HTTPArchive/httparchive.org/issues/414">an issue</a> with the July 2021 HTTP Archive data which resulted in the number of <a hreflang="en" href="https://www.opencart.com/">OpenCart</a> sites being under-reported. It is worth acknowledging that in the September results 10,801 OpenCart sites were detected. If a similar number of OpenCart sites were to have been detected in July, it would put it in between BigCommerce and Shopware in terms of popularity.</aside>
 
 ### Top ecommerce platforms by website popularity
 
@@ -531,7 +531,7 @@ Given we have seen that the number of image requests is slightly down, the avera
   sql_file="pagestats_image_bydevice_format.sql"
 ) }}
 
-<p class="note">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 <code>.jpg</code> or <code>.png</code> suffix. For example, <code>IMG_20190113_113201.jpg</code> 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.</p>
+<aside class="note">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 <code>.jpg</code> or <code>.png</code> suffix. For example, <code>IMG_20190113_113201.jpg</code> 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.</aside>
 
 The most popular image format was JPG with 54% of images being in this format on mobile. This is an 8% increase on last year when 50% of images were JPGs.
 
diff --git a/src/content/en/2021/http.md b/src/content/en/2021/http.md
index f572763265a..5d8802c7a6d 100644
--- a/src/content/en/2021/http.md
+++ b/src/content/en/2021/http.md
@@ -55,7 +55,7 @@ HTTP/2 aimed to address many of the problems web developers were facing when try
 
 In the thirty years since HTTP version 0.9, there has been a shift in the protocol's adoption. With over 6 million web pages analyzed, the HTTP Archive found only a single instance of HTTP 0.9 being used for the initial page request, only a couple of thousand pages still using 1.0. Almost 40% of pages were still using version 1.1 however, with the remaining 60% using HTTP/2 or above. HTTP/2 adoption is thus up 10% since the same analysis was performed in 2020.
 
-<p class="note">Note: Due to the way HTTP/3 works, as we will discuss below, and how our crawl works with a fresh instance each time, HTTP/3 is unlikely to be used for the initial page request, or even subsequent requests. Therefore, we report some statistics in this chapter as "HTTP/2+" to indicate HTTP/2 or HTTP/3 might be used in the real world. We will investigate how much HTTP/3 is actually supported (even if not used in our crawl) later in the chapter.</p>
+<aside class="note">Note: Due to the way HTTP/3 works, as we will discuss below, and how our crawl works with a fresh instance each time, HTTP/3 is unlikely to be used for the initial page request, or even subsequent requests. Therefore, we report some statistics in this chapter as "HTTP/2+" to indicate HTTP/2 or HTTP/3 might be used in the real world. We will investigate how much HTTP/3 is actually supported (even if not used in our crawl) later in the chapter.</aside>
 
 ### Adoption by request
 
diff --git a/src/content/en/2021/jamstack.md b/src/content/en/2021/jamstack.md
index 146994ee9e4..ad6746be4ab 100644
--- a/src/content/en/2021/jamstack.md
+++ b/src/content/en/2021/jamstack.md
@@ -84,7 +84,7 @@ In 2020 the amount of desktop websites increased 2.76 times, while mobile just 1
 
 Let's begin with understanding which SSG is most popular. Next.js covers 43.6% of Jamstack sites. Nuxt.js is in second place with 31.1%, third is Gatsby with 16.0%, followed by Hugo at 6.0%.
 
-<p class="note">Please note the original publication of this chapter had different figures due to incorrect over-counting of Nuxt and Next sites. This has been corrected in above figures and, to a lesser degree, in other figures in this chapter.</p>
+<aside class="note">Please note the original publication of this chapter had different figures due to incorrect over-counting of Nuxt and Next sites. This has been corrected in above figures and, to a lesser degree, in other figures in this chapter.</aside>
 
 All top 3 SSGs are JavaScript based: Next.js and Gatsby use <a hreflang="en" href="https://reactjs.org/">React.js</a> at it's core and supplements this by adding their own functionality on top of it. Nuxt.js is based on <a hreflang="en" href="https://vuejs.org">Vue.js</a>. Having these popular front-end frameworks with huge ecosystems out of the box makes development way easier. <a hreflang="en" href="https://nodejs.org/en/">Node.js</a> allows JavaScript to run on the server as well as the browser where it has traditionally been used, enabling developers stick to one language. That makes adopting these SSGs easier from a server perspective, comparing to Hugo which is based on the <a hreflang="en" href="https://go.dev/">Go programming language</a>, and Jekyll based on <a hreflang="en" href="https://go.dev/">Ruby</a>.
 
diff --git a/src/content/en/2021/markup.md b/src/content/en/2021/markup.md
index 1ac40218aa3..90c7ad5f737 100644
--- a/src/content/en/2021/markup.md
+++ b/src/content/en/2021/markup.md
@@ -350,7 +350,7 @@ The `canvas` element can be used with either the [Canvas API](https://developer.
 
 While the `html`, `head`, `body`, `title`, and `meta` elements are all optional, they're the most common elements this year, all present on more than 99% of the pages.
 
-<p class="note">Note that as we are looking at the rendered HTML, and the browsers will automatically add the `html` and `head` elements, this chart shows we have an error rate of 0.2% of pages in our crawl due to sites no longer being accessible at the time of the crawl.</p>
+<aside class="note">Note that as we are looking at the rendered HTML, and the browsers will automatically add the `html` and `head` elements, this chart shows we have an error rate of 0.2% of pages in our crawl due to sites no longer being accessible at the time of the crawl.</aside>
 
 {{ figure_markup(
   image="element-popularity.png",
diff --git a/src/content/en/2021/page-weight.md b/src/content/en/2021/page-weight.md
index cf0f65637b1..032b6903206 100644
--- a/src/content/en/2021/page-weight.md
+++ b/src/content/en/2021/page-weight.md
@@ -81,7 +81,7 @@ Static files reside by themselves and are used as resources to help build out an
 
 Image formats like PNG and JPEG are widely supported by all browsers. More recent image formats, such as WebP and AVIF offer higher quality with smaller file sizes have gained popularity. WebP is supported by most modern browsers, while AVIF is newer and less supported. With the `<picture>` tag, you can use modern image formats while providing JPEG and PNG fallbacks. Make sure your images are optimized for the web-the [Media](./media) chapter covers this in much more detail. Failing to properly size and compress images for your site will exact a high price on performance.
 
-<p class="note">**Note**: If you need an online service that will optimize and allow you to compare different image sizes formats, there is no better source I've found than Google's <a hreflang="en" href="https://squoosh.app/">Squoosh</a> application. Similarly, [Jake Archibald](https://x.com/jaffathecake)'s <a hreflang="en" href="https://jakearchibald.github.io/svgomg/">SVGOMG</a> is great for optimizing SVG's.</p>
+<aside class="note">**Note**: If you need an online service that will optimize and allow you to compare different image sizes formats, there is no better source I've found than Google's <a hreflang="en" href="https://squoosh.app/">Squoosh</a> application. Similarly, [Jake Archibald](https://x.com/jaffathecake)'s <a hreflang="en" href="https://jakearchibald.github.io/svgomg/">SVGOMG</a> is great for optimizing SVG's.</aside>
 
 #### A word about the proliferation in the use of JavaScript
 
diff --git a/src/content/en/2021/performance.md b/src/content/en/2021/performance.md
index 1d56f13aab0..8e763bf3fc0 100644
--- a/src/content/en/2021/performance.md
+++ b/src/content/en/2021/performance.md
@@ -68,7 +68,7 @@ This section focuses on websites that reached the "good" threshold on all three
   )
 }}
 
-<p class="note"><strong>Note:</strong> As the CLS calculation changed since last year, this is not an apples-to-apples comparison.</p>
+<aside class="note"><strong>Note:</strong> As the CLS calculation changed since last year, this is not an apples-to-apples comparison.</aside>
 
 Core Web Vitals for websites in the Chrome User Experience Report improved year-over-year. But, a good part of this improvement could be due to a change in the CLS calculation, not necessarily to a performance improvement in CLS. The resulting CLS "improvement" was 8 points on desktop (2 for mobile). LCP improved by 7 points for desktop (2 for mobile). FID was already at 100% for desktop for both years and improved by 10 points on mobile.
 
@@ -242,7 +242,7 @@ Only 5% of origins on WordPress experienced good TTFB in July 2021. Considering
 
 FCP was faster on desktop than mobile, likely due to both faster average network speeds and faster processors. Only 38% of origins had good FCP on mobile. Render-blocking resources such as synchronous JavaScript can be a common culprit. Because TTFB is the first part of FCP, poor TTFB will make it difficult to achieve a good FCP.
 
-<p class="note"><strong>Note:</strong> The thresholds for FCP have changed since last year. Be careful if you try to compare this year's data to last year's data.</p>
+<aside class="note"><strong>Note:</strong> The thresholds for FCP have changed since last year. Be careful if you try to compare this year's data to last year's data.</aside>
 
 {{ figure_markup(
   image="performance-FCP-by-ect.png",
@@ -482,7 +482,7 @@ Unfortunately, TBT is not measured in the Chrome User Experience Report. But, we
   )
 }}
 
-<p class="note"><strong>Note:</strong> The groups in the chart are based off of the Lighthouse score for TBT (e.g., >= 0.9 results in "good"). Due to rounding of the score, some TBT values slightly above 200ms get categorized as "good" (and similarly at the 600ms threshold).</p>
+<aside class="note"><strong>Note:</strong> The groups in the chart are based off of the Lighthouse score for TBT (e.g., >= 0.9 results in "good"). Due to rounding of the score, some TBT values slightly above 200ms get categorized as "good" (and similarly at the 600ms threshold).</aside>
 
 Remember that the data is a single, throttled-CPU Lighthouse run through WebPageTest and does not reflect real user experiences. Yet, potential interactivity looked much worse when looking at TBT versus FID. The "real" evaluation of your interactivity is probably somewhere between. Thus, if your FID is "good", take a look at TBT in case you're missing some poor user experiences that FID can't catch yet. The same issues that cause poor FID also cause poor TBT.
 
diff --git a/src/content/en/2021/privacy.md b/src/content/en/2021/privacy.md
index 61a45c04878..b042bdc504b 100644
--- a/src/content/en/2021/privacy.md
+++ b/src/content/en/2021/privacy.md
@@ -272,7 +272,7 @@ Geolocation data can also be accessed by websites through a [web browser API](ht
 
 Poor security management within a company can have a significant impact on its customers' private data. <a hreflang="en" href="https://haveibeenpwned.com/">Have I Been Pwned</a> allows users to check whether their email address or phone number was leaked in a data breach. At the time of this writing, Have I Been Pwned has tracked 562 breaches, leaking 640 million records. In 2020 alone, 40 services were breached and personal data about millions of users leaked. Three of these breaches were marked as _sensitive_, referring to the possibility of a negative impact on the user if someone were to find that user's data in the breach. One example of a sensitive breach is "[Carding Mafia](https://www.vice.com/en/article/v7m9jx/credit-card-hacking-forum-gets-hacked-exposing-300000-hackers-accounts)", a platform where stolen credit cards are traded.
 
-<p class="note">Note that 40 breaches in the previous year is a lower bound, since many breaches are only discovered, or made public, several months after they have occurred.</p>
+<aside class="note">Note that 40 breaches in the previous year is a lower bound, since many breaches are only discovered, or made public, several months after they have occurred.</aside>
 
 {{ figure_markup(
   image="data_breaches_pwned_accounts_per_class.png",
@@ -361,7 +361,7 @@ The most common Referrer Policy that is explicitly set is `no-referrer-when-down
 
 In addition, around 0.5% of websites set the value of the referrer policy to `unsafe-url`, which allows the origin, host and query string to be sent with _any_ request, regardless of the security level of the receiver. In this case, a referrer could be sent in the clear, potentially leaking private information. Worryingly, sites are actively being configured to enable this behavior.
 
-<p class="note">Note: Websites may also send the referrer information as a URL parameter to the destination site. We did not measure usage of that mechanism for this report.</p>
+<aside class="note">Note: Websites may also send the referrer information as a URL parameter to the destination site. We did not measure usage of that mechanism for this report.</aside>
 
 ### User-Agent Client Hints
 
@@ -509,7 +509,7 @@ Beyond blocking trackers, Chrome has launched the <a hreflang="en" href="https:/
 
 To seek ecosystem feedback, early and experimental versions of Privacy Sandbox APIs are made available initially behind <a hreflang="en" href="https://www.chromium.org/developers/how-tos/run-chromium-with-flags">feature flags</a> for testing by individual developers, and then in Chrome via <a hreflang="en" href="https://developer.chrome.com/blog/origin-trials">_origin trials_</a>. Sites can take part in these origin trials to test experimental web platform features, and give feedback to the web standards community on a feature's usability, practicality, and effectiveness, before it's made available to all websites by default.
 
-<p class="note">**Disclaimer:** Origin trials are only available for a limited amount of time. The numbers below represent the state or Privacy Sandbox origin trials at the time of this writing, in October 2021.</p>
+<aside class="note">**Disclaimer:** Origin trials are only available for a limited amount of time. The numbers below represent the state or Privacy Sandbox origin trials at the time of this writing, in October 2021.</aside>
 
 ### FLoC
 
diff --git a/src/content/en/2021/pwa.md b/src/content/en/2021/pwa.md
index 056b03a27a6..6960ac174a4 100644
--- a/src/content/en/2021/pwa.md
+++ b/src/content/en/2021/pwa.md
@@ -40,7 +40,7 @@ Despite that, it's still difficult to draw a clear line between what is a PWA or
 In this year's PWA chapter, we'll focus on all the measurable aspects of a PWA: usage of service workers and its related APIs, web app manifests, and the most popular libraries and tools to build PWAs. A PWA can use all or some of these functionalities. We'll look at the level of adoption of each component and API to get an idea of the level of penetration of these technologies in the web ecosystem.
 
 
-<p class="note">**Note:** This chapter will focus mostly on service worker related APIs in common use. For more cutting-edge APIs, make sure to check out the <a href="./capabilities">Capabilities</a> chapter.</p>
+<aside class="note">**Note:** This chapter will focus mostly on service worker related APIs in common use. For more cutting-edge APIs, make sure to check out the <a href="./capabilities">Capabilities</a> chapter.</aside>
 
 ## Service workers
 
@@ -153,7 +153,7 @@ As seen, background sync techniques don't have wide adoption yet compared to the
 
 Despite that, there are some important reasons for using background sync in modern web apps: one of them being offline analytics (<a hreflang="en" href="https://developers.google.com/web/tools/workbox/modules/workbox-google-analytics">Workbox Analytics uses Background Sync for this</a>), or retrying failed queries due to lack of connectivity (as <a hreflang="en" href="https://web.dev/google-search-sw/">some search engines do</a>).
 
-<p class="note">**Note:** Unlike previous years, we have decided not to include the `fetch` and `message` events in this analysis, as those can also appear outside service workers, which could lead to a high number of false positives. So, the above analysis is for service worker-specific events. <a hreflang="en" href="../2020/pwa#service-worker-events">According to 2020 data, `fetch` was used almost as much as `install`.</a></p>
+<aside class="note">**Note:** Unlike previous years, we have decided not to include the `fetch` and `message` events in this analysis, as those can also appear outside service workers, which could lead to a high number of false positives. So, the above analysis is for service worker-specific events. <a hreflang="en" href="../2020/pwa#service-worker-events">According to 2020 data, `fetch` was used almost as much as `install`.</a></aside>
 
 #### Other popular service worker features
 
@@ -313,7 +313,7 @@ Finally, we'll analyze `prefer_related_applications`. If the value of this prope
 
 Despite the fact that the vast majority of PWA developers prefer promoting their PWA experiences to native applications, some well-known PWAs (like Twitter), still prefer recommending the native app over the PWA experience. This might be due to a preference of the teams building these experiences, or some specific business needs (lack of some API in the web).
 
-<p class="note">**Note:** Instead of making this decision statically at configuration, developers can also <a hreflang="en" href="https://web.dev/define-install-strategy/">create more dynamic heuristics</a> to promote an experience, for example, based on the user's behavior or other characteristics (device, connection, location, etc.).</p>
+<aside class="note">**Note:** Instead of making this decision statically at configuration, developers can also <a hreflang="en" href="https://web.dev/define-install-strategy/">create more dynamic heuristics</a> to promote an experience, for example, based on the user's behavior or other characteristics (device, connection, location, etc.).</aside>
 
 ### Top manifest categories
 
@@ -398,8 +398,8 @@ Workbox is still the most popular library, being used by 15.43% of desktop and 1
 
 It's also important to note that the Workbox predecessor `sw_toolbox`, which had <a hreflang="en" href="../2020/pwa#popular-import-scripts">13.92% of usage in desktop and 12.84% in mobile last year</a> dropped to 0.51% and 0.36% respectively this year. This is in part due to the fact that `sw_toolbox` was <a hreflang="en" href="https://github.com/GoogleChromeLabs/sw-toolbox/pull/288">deprecated in 2019</a>. It might have taken some time for some popular frameworks and build tools to remove this package, so we are seeing the drop in adoption more clearly this year. Also, our measurement has changed compared to 2020, by adding more sites, which made this metric decrease even more, making it difficult to do a direct year on year comparison.
 
-<p class="note">**Note:** Take into account that [`importScripts()`](https://developer.mozilla.org/docs/Web/API/WorkerGlobalScope/importScripts) is an API of [`WorkerGlobalScope`](https://developer.mozilla.org/docs/Web/API/WorkerGlobalScope) that can be used in other types of worker context like [Web Workers](https://developer.mozilla.org/docs/Web/API/Web_Workers_API/Using_web_workers). <a hreflang="en" href="https://www.google.com/recaptcha/about/">reCaptcha</a>, for example, appears as the second most widely used library, as it uses a web worker that contains an `importScripts()` call to retrieve the reCaptcha JavaScript code. For that reason, we should consider <a hreflang="en" href="https://firebase.google.com/docs/web/setup">Firebase</a> instead as the second most widely used library in service worker contexts.
-</p>
+<aside class="note">**Note:** Take into account that [`importScripts()`](https://developer.mozilla.org/docs/Web/API/WorkerGlobalScope/importScripts) is an API of [`WorkerGlobalScope`](https://developer.mozilla.org/docs/Web/API/WorkerGlobalScope) that can be used in other types of worker context like [Web Workers](https://developer.mozilla.org/docs/Web/API/Web_Workers_API/Using_web_workers). <a hreflang="en" href="https://www.google.com/recaptcha/about/">reCaptcha</a>, for example, appears as the second most widely used library, as it uses a web worker that contains an `importScripts()` call to retrieve the reCaptcha JavaScript code. For that reason, we should consider <a hreflang="en" href="https://firebase.google.com/docs/web/setup">Firebase</a> instead as the second most widely used library in service worker contexts.
+</aside>
 
 ### Workbox usage
 
@@ -501,7 +501,7 @@ Also as shown in [Figure 16.4](#fig-4) related to service worker events,  the `p
 <!-- markdownlint-disable-next-line MD051 -->
 The service worker interface also allows listening to some events to handle user interactions on notifications. [Figure 16.4](#fig-4) shows that `notificationclick` (which captures clicks on notifications) is used by 45.64% of desktop and 46.62% of mobile PWAs. `notificationclose` is used less frequently: 5.98% of desktop and 6.34% of mobile PWAs. This is expected as there are fewer use cases where it makes sense to listen for the notification "close" event, than for notification "clicks".
 
-<p class="note">**Note:** It's interesting to see that service worker notification events (e.g., `push`, `notificationclick`) have even more usage the `pushManager` property, which is used, for example, to request permission for web push notifications (via `pushManager.subscribe`). One of the reasons for this might be that some sites have implemented web push and decided to roll them back at some point, by eliminating the code to request permission for them, but leaving the service worker code unchanged.</p>
+<aside class="note">**Note:** It's interesting to see that service worker notification events (e.g., `push`, `notificationclick`) have even more usage the `pushManager` property, which is used, for example, to request permission for web push notifications (via `pushManager.subscribe`). One of the reasons for this might be that some sites have implemented web push and decided to roll them back at some point, by eliminating the code to request permission for them, but leaving the service worker code unchanged.</aside>
 
 ### Web Push notification acceptance rates
 
diff --git a/src/content/en/2021/resource-hints.md b/src/content/en/2021/resource-hints.md
index b9e4d56d47b..0710d55ecfa 100644
--- a/src/content/en/2021/resource-hints.md
+++ b/src/content/en/2021/resource-hints.md
@@ -262,7 +262,7 @@ This same observation may be seen on a page's LCP, indicating that in many cases
 
 While this doesn't prove that having preload hints causes a page to get slower, having many hints does correlate with having slower performance. Every page has its unique requirements and it is impossible to apply a "one size fits all" approach, but in the majority of cases the number of preloaded resources should be kept low and resource prioritization should be delegated to the browser when possible.
 
-<p class="note">Note: In addition to the number of hints, the size of each preloaded resource has an impact on the website performance. The above figure does not take into consideration the size of each preloaded resource.</p>
+<aside class="note">Note: In addition to the number of hints, the size of each preloaded resource has an impact on the website performance. The above figure does not take into consideration the size of each preloaded resource.</aside>
 
 ## `rel="preload"`
 
@@ -351,7 +351,7 @@ An oft-neglected feature available to `rel="preload"` is the ability to specify
 
 In addition to the `media` attribute, the `<link>` element supports `imagesrcset` and `imagesizes` attributes which correspond to the `srcset` and `sizes` attributes on `<img>` elements. Using these attributes, you can use the same resource selection criteria that you would use on your image. Unfortunately, their adoption is very low (less than 1%); most likely owing to the lack of <a hreflang="en" href="https://caniuse.com/mdn-html_elements_link_imagesizes">support</a> on Safari.
 
-<p class="note">Note: The `media` attribute is not available on all `<link>` elements as the spec suggests, but it is only available on `rel="preload"`.</p>
+<aside class="note">Note: The `media` attribute is not available on all `<link>` elements as the spec suggests, but it is only available on `rel="preload"`.</aside>
 
 ### Bad practices
 
@@ -411,7 +411,7 @@ There are 17,861 cases of unrecognized values, with the most frequent error bein
 
 When using an incorrect `as` attribute value—as opposed to unrecognized value, such as using `style` instead of `script`—the browser will duplicate the file download as the request won't match the resource stored in the preload cache.
 
-<p class="note">Note: While <code>video</code> is included in the spec, it isn't supported by any browser and would be treated as an invalid value and ignored.</p>
+<aside class="note">Note: While <code>video</code> is included in the spec, it isn't supported by any browser and would be treated as an invalid value and ignored.</aside>
 
 #### Unused font files
 
diff --git a/src/content/en/2021/security.md b/src/content/en/2021/security.md
index 6e3e2f81dc8..c5c05abcb5f 100644
--- a/src/content/en/2021/security.md
+++ b/src/content/en/2021/security.md
@@ -643,7 +643,7 @@ We see 1.3% of websites on the mobile using the `Permissions-Policy` already. A
 
 One can also use the `allow` attribute in `<iframe>` elements to enable or disable features allowed to be used in the embedded frame. 18.3% of 16.8 million frames in mobile contained the `allow` attribute to enable permission or feature policies.
 
-<p class="note">An earlier version of this chapter reported incorrect values for the total number of frames and the percentage of frames with the `allow` attribute. These errors have now been corrected. More information can be found in this <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</p>
+<aside class="note">An earlier version of this chapter reported incorrect values for the total number of frames and the percentage of frames with the `allow` attribute. These errors have now been corrected. More information can be found in this <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</aside>
 
 As in previous years, the most used directives in `allow` attributes on iframes are still related to controls for embedded videos and media. The most used directive continues to be `encrypted-media` which is used to control access to the Encrypted Media Extensions API.
 
@@ -653,7 +653,7 @@ An untrusted third-party in an iframe could launch a number of attacks on the pa
 
 The `sandbox` attribute on iframes applies restrictions to the content, and therefore reduces the opportunities for launching attacks from the embedded web page. The value of the attribute can either be empty to apply all restrictions (the embedded page cannot execute any JavaScript code, no forms can be submitted, and no popups can be created, to name a few restrictions), or space-separated tokens to lift particular restrictions. As embedding third-party content such as advertisements or videos via iframes is common practice on the web, it is not surprising that many of these are restricted via the `sandbox` attribute: 19.7% of the iframes on desktop pages have a `sandbox` attribute while on mobile pages this is 21.0%.
 
-<p class="note">An earlier version of this chapter reported incorrect values for the percentage of frames with the `sandbox` attribute. More information can be found in this <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</p>
+<aside class="note">An earlier version of this chapter reported incorrect values for the percentage of frames with the `sandbox` attribute. More information can be found in this <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</aside>
 
 {{ figure_markup(
   image="security-prevalence-of-sandbox-directives-on-frames.png",
diff --git a/src/content/en/2021/third-parties.md b/src/content/en/2021/third-parties.md
index 015a10dc10b..34679af54fb 100644
--- a/src/content/en/2021/third-parties.md
+++ b/src/content/en/2021/third-parties.md
@@ -66,7 +66,7 @@ This year we will, again, be drawing heavily on the <a hreflang="en" href="https
 - **Video** - These scripts enable video player and streaming functionality.
 - **Other** - These are miscellaneous scripts delivered via a shared origin with no precise category or attribution.
 
-<p class="note">Note: The CDN category here includes providers that provide resources on public CDN domains (e.g. bootstrapcdn.com, cdnjs.cloudflare.com, etc.) and does not include resources that are simply served over a CDN. For example, putting Cloudflare in front of a page would not influence its first-party designation according to our criteria.</p>
+<aside class="note">Note: The CDN category here includes providers that provide resources on public CDN domains (e.g. bootstrapcdn.com, cdnjs.cloudflare.com, etc.) and does not include resources that are simply served over a CDN. For example, putting Cloudflare in front of a page would not influence its first-party designation according to our criteria.</aside>
 
 One change that we have made to our methodology this year is to remove the Hosting category from our analysis. If you happen to use WordPress.com for your blog, or Shopify for your ecommerce platform, then we're going to ignore other requests for those domains by that site as not truly "third-party", as they are in many ways part of hosting on those platforms. Similar to the note above, we do not consider CDNs in front of a page to be "third party". In reality this made very little difference to the numbers, but we feel it's a more accurate reflection of what we should consider "third party" by the above definition, and also aligns more closely with how the other chapters use this term.
 
diff --git a/src/content/en/2022/cdn.md b/src/content/en/2022/cdn.md
index 024739aefe7..6c163790be5 100644
--- a/src/content/en/2022/cdn.md
+++ b/src/content/en/2022/cdn.md
@@ -274,7 +274,7 @@ Despite the hype of HTTP/2 and the promise of reduced latency and other function
 
 CDNs act as the proxy to bridge the gap by providing a layer to consolidate hostnames and route traffic to relevant endpoints with minimal change to their hosting infrastructure. Features like prioritizing content in the queue and server push can be managed from the CDNs side and a few CDNs even provide hands-off automated solutions to run these features without any inputs from website owners, thus providing a boost to HTTP/2 adoption.
 
-<p class="note">Note that due to the way HTTP/3 works (see the [HTTP](./http) chapter for more information), HTTP/3 is often not used for first connections which is why we are instead measuring "HTTP/2+", since many of those HTTP/2 connections may actually be HTTP/3 for repeat visitors (we have assumed that no servers implement HTTP/3 without HTTP/3).</p>
+<aside class="note">Note that due to the way HTTP/3 works (see the [HTTP](./http) chapter for more information), HTTP/3 is often not used for first connections which is why we are instead measuring "HTTP/2+", since many of those HTTP/2 connections may actually be HTTP/3 for repeat visitors (we have assumed that no servers implement HTTP/3 without HTTP/3).</aside>
 
 {{ figure_markup(
   image="cdn-http-versions-mobile.png",
diff --git a/src/content/en/2022/jamstack.md b/src/content/en/2022/jamstack.md
index 2c2df2312ee..4d4b7ea5989 100644
--- a/src/content/en/2022/jamstack.md
+++ b/src/content/en/2022/jamstack.md
@@ -34,7 +34,7 @@ All three of the above definitions come from <a hreflang="en" href="https://jams
 
 But as the emphasized words demonstrate, there's clearly some continuity: the sites should be fast, they should be pre-rendered, and they should use an architectural approach that decouples "where you get your data" from "how you render your data". Even if a precise dictionary definition is hard to come by, Jamstack developers know what you mean when you say "Jamstack": you've got a site that loads really quickly, renders a lot of its useful content once, at build time, and retrieves additional data (if it needs to) via JavaScript.
 
-<p class="note">Disclosure: the two authors of this report were Netlify employees. Netlify invented the term Jamstack and owns Jamstack.org. This report and the underlying analysis were reviewed and approved by others not affiliated with Netlify.</p>
+<aside class="note">Disclosure: the two authors of this report were Netlify employees. Netlify invented the term Jamstack and owns Jamstack.org. This report and the underlying analysis were reviewed and approved by others not affiliated with Netlify.</aside>
 
 ## Quantifying the Jamstack: what counts?
 
diff --git a/src/content/en/2022/markup.md b/src/content/en/2022/markup.md
index da225315dc7..7c50ad8f006 100644
--- a/src/content/en/2022/markup.md
+++ b/src/content/en/2022/markup.md
@@ -155,7 +155,7 @@ One way to counter this trend is to <a hreflang="en" href="https://css-tricks.co
 
 If you're not including the `svg` and `math` elements—because they're specified outside of HTML—the current HTML specification currently consists of 111 elements.
 
-<p class="note">Elements, not tags, because we're not referring to mere start or end tags, like `<li>` or `</ins>`. And some people count HTML elements differently, but most important is to <a hreflang="en" href="https://meiert.com/en/blog/the-number-of-html-elements/">be clear about how you're counting</a>.</p>
+<aside class="note">Elements, not tags, because we're not referring to mere start or end tags, like `<li>` or `</ins>`. And some people count HTML elements differently, but most important is to <a hreflang="en" href="https://meiert.com/en/blog/the-number-of-html-elements/">be clear about how you're counting</a>.</aside>
 
 What can we observe?
 
diff --git a/src/content/en/2022/media.md b/src/content/en/2022/media.md
index 3b0235f6e52..a44c6ae52ab 100644
--- a/src/content/en/2022/media.md
+++ b/src/content/en/2022/media.md
@@ -656,7 +656,7 @@ On desktop, where the difference between the default `sizes` value (`100vw`) and
 
 We estimate that one-quarter of desktop pages are loading more than 83 KB of extra image data, based purely on bad `sizes` attributes. That is to say: A better, smaller resource is there for the picking in the `srcset`, but because the `sizes` attribute is so erroneous, the browser doesn't pick it. Additionally, 10% of desktop pages that use sizes load more than a half-megabyte of excess image data because of bad `sizes` attributes!
 
-<p class="note">Note: Our crawlers didn't actually load the correct resources, so the numbers here are estimates, based in part on the byte sizes of the incorrect resources, which the crawlers actually did load.</p>
+<aside class="note">Note: Our crawlers didn't actually load the correct resources, so the numbers here are estimates, based in part on the byte sizes of the incorrect resources, which the crawlers actually did load.</aside>
 
 In the short term, individual developers can and should use <a hreflang="en" href="https://ausi.github.io/respimagelint/">RespImageLint</a> to audit and fix their badly broken `sizes` attributes and prevent this kind of waste.
 
diff --git a/src/content/en/2022/performance.md b/src/content/en/2022/performance.md
index d0333d05cf5..b5054dbe667 100644
--- a/src/content/en/2022/performance.md
+++ b/src/content/en/2022/performance.md
@@ -35,7 +35,7 @@ Although the spotlight of this chapter, it's important to note that CWV are rela
 
 The CWV program suggests a clearly defined approach to measuring how users actually experience performance—a first for the industry. Are CWV the answer to helping the web become more performant? This chapter examines where the web is currently with CWV and takes a look into the future.
 
-<p class="note">Disclosure: This chapter is coauthored by an employee of Google, which created the Core Web Vitals program. This chapter and its underlying analysis were reviewed and approved by others not affiliated with Google.</p>
+<aside class="note">Disclosure: This chapter is coauthored by an employee of Google, which created the Core Web Vitals program. This chapter and its underlying analysis were reviewed and approved by others not affiliated with Google.</aside>
 
 ## Core Web Vitals
 
diff --git a/src/content/en/2022/security.md b/src/content/en/2022/security.md
index f5a9b8cb854..81bf558cbfa 100644
--- a/src/content/en/2022/security.md
+++ b/src/content/en/2022/security.md
@@ -634,7 +634,7 @@ Besides being used as an HTTP header, this feature can be used within `<iframe>`
 
 12.6% of 17.4 million frames in mobile contained the `allow` attribute to enable permission or feature policies.
 
-<p class="note">An earlier version of this chapter reported incorrect values for the total number of frames and the percentage of frames with the `allow` attribute. More information can be found in this <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</p>
+<aside class="note">An earlier version of this chapter reported incorrect values for the total number of frames and the percentage of frames with the `allow` attribute. More information can be found in this <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</aside>
 
 The following is a list of the top 10 `allow` directives that were detected in frames:
 
@@ -741,7 +741,7 @@ The above chart of the 2022 data shows that more than 99% of websites with a `sa
 
 For all iframes found on desktop websites, 21.08% include the `sandbox` attribute.
 
-<p class="note">An earlier version of this chapter reported the incorrect percentage of frames with the `sandbox` attribute. More information can be found in this <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</p>
+<aside class="note">An earlier version of this chapter reported the incorrect percentage of frames with the `sandbox` attribute. More information can be found in this <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</aside>
 
 We find that `Content-Security-Policy` headers which include a `sandbox` directive are at a mere 0.3% usage for mobile (desktop is similar at 0.4%) which may speak to the fact that this attribute is only applied on a per-case basis for the practice of embedding iframe content within pages, rather than ahead-of-time planning through a content security policy definition.
 
diff --git a/src/content/en/2022/sustainability.md b/src/content/en/2022/sustainability.md
index dff3a94b432..da9b7770deb 100644
--- a/src/content/en/2022/sustainability.md
+++ b/src/content/en/2022/sustainability.md
@@ -117,7 +117,7 @@ At the 90th percentile, desktop pages were over 9 MB and mobile pages over 8 MB.
 
 ### Carbon emissions
 
-<p class="note">Note: The notion of "carbon emissions" is a simplification since we are considering Greenhouse Gas Emissions, not only carbon emissions.</p>
+<aside class="note">Note: The notion of "carbon emissions" is a simplification since we are considering Greenhouse Gas Emissions, not only carbon emissions.</aside>
 
 {{ figure_markup(
   image="carbon-emissions-by-percentile.png",
@@ -190,7 +190,7 @@ There are almost as many HTTP requests for images and JavaScript but the overall
 
 ### More sustainable hosting
 
-<p class="note">Note: Here (and elsewhere), you should find mention of "Green Hosting". This is kind of a shortcut since no hosting will be truly green, carbon neutral or other such things. We will focus here on how to use more sustainable hosting.</p>
+<aside class="note">Note: Here (and elsewhere), you should find mention of "Green Hosting". This is kind of a shortcut since no hosting will be truly green, carbon neutral or other such things. We will focus here on how to use more sustainable hosting.</aside>
 
 For the majority of this chapter, we focus on how changes in the quantity of resources like network, compute and storage affect the environmental impact of digital services—you might think of this as in terms of _consumption_ as a lever for sustainability. However there are other levers too. You can't efficiency your way to zero, and the same code, run on the same kind of server, but running on greener energy will have a lower environmental impact than otherwise. We can think of this lever as _intensity_.
 
@@ -215,7 +215,7 @@ An increasing number of technology firms are also taking steps to green **all**
 
 Overall, only 10 percent of the measured websites rely on green hosting. This highlights that a lot could and should be done on both sides: websites opting for green hosting as well as hosting companies aiming for more sustainability.
 
-<p class="note">Note: these figures for green domains are based on the information that is either shared directly with The Green Web Foundation, or placed in the public domain, where it is linked in API responses for their lookup service. See <a hreflang="en" href="https://www.thegreenwebfoundation.org/support/why-does-my-website-show-up-as-grey-in-the-green-web-checker/">their explainer page</a> for why a site might show up as "not green" when you think it should.</p>
+<aside class="note">Note: these figures for green domains are based on the information that is either shared directly with The Green Web Foundation, or placed in the public domain, where it is linked in API responses for their lookup service. See <a hreflang="en" href="https://www.thegreenwebfoundation.org/support/why-does-my-website-show-up-as-grey-in-the-green-web-checker/">their explainer page</a> for why a site might show up as "not green" when you think it should.</aside>
 
 ## Reducing the environmental impact of websites
 
diff --git a/src/content/en/2024/fonts.md b/src/content/en/2024/fonts.md
index 712207d3f94..6b94aad0f6e 100644
--- a/src/content/en/2024/fonts.md
+++ b/src/content/en/2024/fonts.md
@@ -139,7 +139,7 @@ About 39% of desktop and mobile websites crawled by the HTTP Archive this year u
 
 Overall, the trend is clear: more and more people prefer to self-host their web fonts. This is a great choice in many cases because self-hosting avoids external dependencies for something as critical to rendering as fonts are. Plus, when self-hosted fonts are well optimized, they give you the best performance (but more on that later).
 
-<p class="note">NB: The numbers presented in this section are slightly different from those in the 2022 chapter. The 2022 chapter attempted to include base64 encoded fonts embedded in CSS files for some (somewhat) popular web font service. Fortunately, encoding base64 fonts in CSS is no longer a popular method of serving fonts. For this reason the 2024 chapter switched to counting fonts served as separate files only. The spreadsheet for this year includes the recalculated figures for 2022 and 2023 as well (and they are mentioned where appropriate in this section).</p>
+<aside class="note">NB: The numbers presented in this section are slightly different from those in the 2022 chapter. The 2022 chapter attempted to include base64 encoded fonts embedded in CSS files for some (somewhat) popular web font service. Fortunately, encoding base64 fonts in CSS is no longer a popular method of serving fonts. For this reason the 2024 chapter switched to counting fonts served as separate files only. The spreadsheet for this year includes the recalculated figures for 2022 and 2023 as well (and they are mentioned where appropriate in this section).</aside>
 
 ## File formats
 
@@ -461,7 +461,7 @@ Emoji fonts do not suffer from this problem as emoji are encoded in Unicode so t
 
 Which font families were most popular this year, and which foundries made them? Taking a look at the top 20 there are few surprises in the first ten entries compared to 2022. Roboto still leads the pack, with a small increase in use*. Font Awesome use has remained fairly stable, and so has Noto usage (unlike 2022, Noto is now split into script specific items). The only surprise is the decline of Lato, which has been overtaken by Poppins and Montserrat.
 
-<p class="note">\* As noted in 2022 the discrepancy between desktop and mobile use of Roboto is mostly likely due to the use of `local()` which loads a locally installed version of Roboto; due to it being the system font on Android, usage on mobile is low.</p>
+<aside class="note">\* As noted in 2022 the discrepancy between desktop and mobile use of Roboto is mostly likely due to the use of `local()` which loads a locally installed version of Roboto; due to it being the system font on Android, usage on mobile is low.</aside>
 
 Looking at the remainder of the top 20, Proxima Nova usage has increased slightly to reach about 1% of websites. As the only commercial, non-icon font in the top 20, this level of popularity is extremely impressive. Like in 2022, icon fonts make up about 18% of web fonts in 2024. The meteoric rise of Inter should also not go unnoticed, as it also stands around 1%. Due to its prominence in frameworks and libraries, we expect Inter to rise into the top 10 within the next few years.
 
@@ -1552,7 +1552,7 @@ It's worth noting a point of complexity in the data gathered on color fonts. Our
 
 We plan to refine our analysis of color fonts in future editions of the Almanac, but our expectation is that `COLR` usage will continue to grow and it will soon become the dominant color font format (if it isn't already).
 
-<p class="note">The observant reader may have noticed that the color font usage percentages between the 2022 fonts chapter and 2024 font chapter are slightly different. On closer inspection of the color font data we noticed that some popular font tools include an empty `SVG` table, even though the font does not contain any color glyphs. This erroneously caused the popularity of `SVG` to be inflated. We have corrected this in 2024 and included the 2022 and 2023 data for comparison.</p>
+<aside class="note">The observant reader may have noticed that the color font usage percentages between the 2022 fonts chapter and 2024 font chapter are slightly different. On closer inspection of the color font data we noticed that some popular font tools include an empty `SVG` table, even though the font does not contain any color glyphs. This erroneously caused the popularity of `SVG` to be inflated. We have corrected this in 2024 and included the 2022 and 2023 data for comparison.</aside>
 
 ## Font smoothing
 
diff --git a/src/content/en/2024/http.md b/src/content/en/2024/http.md
index fd5f5ad14b8..e58e708f041 100644
--- a/src/content/en/2024/http.md
+++ b/src/content/en/2024/http.md
@@ -112,9 +112,9 @@ As discussed above, if the browser hasn't connected to a domain before, it will
 
 In order to make results comparable and fair across websites, we want to load each page with a fresh browser profile and nothing in the HTTP/file/DNS/alt-svc/... caches. As such, the `alt-svc` mechanism is conceptually useless in our methodology, as we'd only use the initial HTTP/2 connection and never get to HTTP/3. This is why measuring HTTP/3 adoption directly by protocol used in our dataset (as we did in the first image above) is misleading, with HTTP/3 getting underreported.
 
-<p class="note">
+<aside class="note">
   Note: at this point, you might wonder how we're even seeing HTTP/3 page loads at all since with just <code>alt-svc</code> we should be seeing 0% HTTP/3. This is of course mainly due to the use of the 2nd discovery method via DNS, which we'll discuss later.
-</p>
+</aside>
 
 Let's now look purely at how HTTP/3 support is being announced via `alt-svc` to get an idea of how much support sites claim to have, even if it doesn't actually show up in our dataset:
 
@@ -184,9 +184,9 @@ This most likely has to do with how exactly the CDNs enable the new protocol. Fo
 
 Finally, it is somewhat surprising that some more specialized deployments, like Automattic, heavily lean into HTTP/3 (99.92%) while others like Vercel and Netlify show near-zero HTTP/3 support. I can only speculate on the reasons for the latter, but assume it is mostly due to the complexity of setting up and maintaining the new protocol at scale, while these newer up-and-coming companies might prefer to focus on other parts of their stacks first.
 
-<p class="note">
+<aside class="note">
   Note: These results might not give a 100% accurate impression of what CDNs are actually doing, as firstly <a hreflang="en" href="https://github.com/HTTPArchive/wptagent/blob/5ef2c870a90a3492cd6170893812270d627df107/internal/optimization_checks.py#L67">the CDN detection logic</a> might be inaccurate/incomplete (for example, Shopify nor Apple are tracked separately yet), and secondly a lot of the tracked requests are for analytics/trackers, which might not be indicative of HTTP/3 support for normal page/resource loads—especially for sites like Facebook.
-</p>
+</aside>
 
 In conclusion, we see that currently around 27% of all websites in the Web Almanac dataset announce HTTP/3 support through `alt-svc`. This number could potentially be much higher, if all websites that use a compatible CDN would enable it. At the same time however, the actual number of HTTP/3 requests we've seen in the dataset is much lower, between 7-9%. As we've explained, this is due to the used methodology and most of those 7-9% will come from another HTTP/3 discovery method using DNS records, so let's look at those next.
 
diff --git a/src/content/en/2024/media.md b/src/content/en/2024/media.md
index 8dcd6a20285..6a314b76550 100644
--- a/src/content/en/2024/media.md
+++ b/src/content/en/2024/media.md
@@ -630,7 +630,7 @@ We estimate that a quarter of all desktop pages that use `w` descriptors are loa
 
 This is quite troubling, but what's worse is that all of these numbers are almost twice as bad as they were just two years ago. Things are bad and getting worse.
 
-<p class="note">Note: Our crawlers didn't actually load the correct resources, so the numbers here are estimates, based on the compression densities and aspect ratios of the incorrect resources, which the crawlers actually did load.</p>
+<aside class="note">Note: Our crawlers didn't actually load the correct resources, so the numbers here are estimates, based on the compression densities and aspect ratios of the incorrect resources, which the crawlers actually did load.</aside>
 
 There are two solutions here that developers should pursue.
 
@@ -677,7 +677,7 @@ While usage of the `media` attribute is down three percentage points from 2022,
 
 We already saw [how the web's image resources size up](#image-dimensions). But before they can be shown to a user, embedded images must be placed within a layout and potentially squished or stretched to fit it.
 
-<p class="note">Note: It will be useful to keep in mind the [crawlers' viewports](./methodology#webpagetest) throughout this analysis. The desktop crawler was 1376px wide, with a DPR of 1x, the mobile crawler was 360px wide, with a DPR of 3x.</p>
+<aside class="note">Note: It will be useful to keep in mind the [crawlers' viewports](./methodology#webpagetest) throughout this analysis. The desktop crawler was 1376px wide, with a DPR of 1x, the mobile crawler was 360px wide, with a DPR of 3x.</aside>
 
 ### Layout widths
 
diff --git a/src/content/en/2024/privacy.md b/src/content/en/2024/privacy.md
index c2653940fd3..8568e9a1d69 100644
--- a/src/content/en/2024/privacy.md
+++ b/src/content/en/2024/privacy.md
@@ -376,7 +376,7 @@ Since most of the popular browsers are competing with each other in the space of
 
 We observe that 14.6% distinct advertisers are using ARA to register themselves using attribution-reporting-register-trigger header on 8.8% distinct publishers on the top 1,000 websites. In total, we observe 1.6% (0.5%) distinct advertisers have adopted ARA across 5.1% (2.4%) publishers in top million (top 10 million) websites. This shows that not many publishers have adopted ARA as compared to the advertiser adoption—preparing themselves for the post-cookie world where they will need to rely on ARA to attribute user conversions to ad clicks.
 
-<p class="note"><b>Limitation</b>: Note that by "presence", we refer to the mere presence of privacy sandbox API calls in the JavaScript in this analysis. This does not mean that the APIs are guaranteed to be executed or used during the runtime.</a>
+<aside class="note"><b>Limitation</b>: Note that by "presence", we refer to the mere presence of privacy sandbox API calls in the JavaScript in this analysis. This does not mean that the APIs are guaranteed to be executed or used during the runtime.</aside>
 
 ### Related Websites Sets
 
diff --git a/src/content/en/2024/third-parties.md b/src/content/en/2024/third-parties.md
index 241ad0c1bc9..fc47935176f 100644
--- a/src/content/en/2024/third-parties.md
+++ b/src/content/en/2024/third-parties.md
@@ -63,9 +63,9 @@ As previously indicated, third parties can be used for various use cases—for e
 - **Consent provider**: These scripts allow sites to manage the user consent (eg. for the [General Data Protection Regulation](https://wikipedia.org/wiki/General_Data_Protection_Regulation) compliance). They are also known as the 'Cookie Consent' popups and are usually loaded on the critical path.
 - **Other**: These are miscellaneous scripts delivered via a shared origin with no precise category or attribution.
 
-<p class="note">Note: The CDN category here includes providers that provide resources on public CDN domains (for example <code>bootstrapcdn.com</code>, <code>cdnjs.cloudflare.com</code>, etc.) and does not include resources that are simply served over a CDN. For example, putting Cloudflare in front of a page would not influence its first-party designation according to our criteria.</p>
+<aside class="note">Note: The CDN category here includes providers that provide resources on public CDN domains (for example <code>bootstrapcdn.com</code>, <code>cdnjs.cloudflare.com</code>, etc.) and does not include resources that are simply served over a CDN. For example, putting Cloudflare in front of a page would not influence its first-party designation according to our criteria.</aside>
 
-<p class="note">Similar to previous years, the Hosting category is removed from our analysis. For example, if you happen to use WordPress.com for your blog, or Shopify for your e-commerce platform, then we're going to ignore other requests for those domains by that site as not truly "third-party" as they are, in many ways, part of hosting on those platforms.</p>
+<aside class="note">Similar to previous years, the Hosting category is removed from our analysis. For example, if you happen to use WordPress.com for your blog, or Shopify for your e-commerce platform, then we're going to ignore other requests for those domains by that site as not truly "third-party" as they are, in many ways, part of hosting on those platforms.</aside>
 
 ### `Content Type`
 
diff --git a/src/content/es/2019/css.md b/src/content/es/2019/css.md
index 7ece1890c5e..50f3cfa0362 100644
--- a/src/content/es/2019/css.md
+++ b/src/content/es/2019/css.md
@@ -107,7 +107,7 @@ Como era de esperar, en la Figura 2.5, `px` es el tipo de unidad más utilizado,
 
 Cuando se trata de unidades basadas en el espacio físico, la unidad `cm` (or centímetros) es la más popular por mucho, seguida por `in` (pulgadas), y luego por  `Q`.Sabemos que este tipo de unidades son específicamente útiles para imprimir hojas de estilo, ¡pero ni siquiera sabíamos que la unidad `Q` existía hasta esta encuesta! ¿Sabías?
 
-<p class="note">Una versión anterior de este capítulo discutia la inesperada popularidad de la unidad<code>Q</code>. Gracias a la <a hreflang="en" href="https://discuss.httparchive.org/t/chapter-2-css/1757/6">discusión de la comunidad</a> alrededor de este capítulo, hemos identificado que esto fue un error en nuestro análisis y hemos actualizado la Figura 2.5 en consecuencia.</p>
+<aside class="note">Una versión anterior de este capítulo discutia la inesperada popularidad de la unidad<code>Q</code>. Gracias a la <a hreflang="en" href="https://discuss.httparchive.org/t/chapter-2-css/1757/6">discusión de la comunidad</a> alrededor de este capítulo, hemos identificado que esto fue un error en nuestro análisis y hemos actualizado la Figura 2.5 en consecuencia.</aside>
 
 ### Unidades basadas en el viewport
 
diff --git a/src/content/es/2019/ecommerce.md b/src/content/es/2019/ecommerce.md
index 8c38edd3b9f..5e9b6de740b 100644
--- a/src/content/es/2019/ecommerce.md
+++ b/src/content/es/2019/ecommerce.md
@@ -445,7 +445,7 @@ Los tamaños de HTML en móvil no son muy diferentes de los de escritorio. En ot
   )
 }}
 
-<p class="note">Tenga en cuenta que debido a que nuestra <a href="./methodology">metodología</a> de recopilación de datos no simula las interacciones del usuario en páginas como hacer clic o scroll, las imágenes cargadas de forma diferida (_lazy loading_) no se representarían en estos resultados.</p>
+<aside class="note">Tenga en cuenta que debido a que nuestra <a href="./methodology">metodología</a> de recopilación de datos no simula las interacciones del usuario en páginas como hacer clic o scroll, las imágenes cargadas de forma diferida (_lazy loading_) no se representarían en estos resultados.</aside>
 
 Las Figuras 13.12 y 13.13 muestran que la página de comercio electrónico promedio tiene 37 imágenes y representan un tráfico de 1.517 KB en dispositivos móviles, 40 imágenes y 1.524 KB en computadoras de escritorio. ¡El 10% de las páginas de inicio tienen 90 o más imágenes y representan en total casi 6 MB!
 
@@ -472,7 +472,7 @@ Necesitamos hacer más análisis para comprender mejor por qué algunos sitios n
   )
 }}
 
-<p class="note">Tenga en cuenta que algunos servicios de imágenes o CDN entregarán automáticamente WebP (en lugar de JPEG o PNG) a plataformas que admitan WebP, incluso para una URL con el sufijo `.jpg` o` .png`. Por ejemplo, <a hreflang="en" href="https://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg">IMG_20190113_113201.jpg</a> devuelve una imagen WebP en Chrome. Sin embargo, la forma en que HTTP Archive <a hreflang="en" href="https://github.com/HTTPArchive/legacy.httparchive.org/blob/31a25b9064a365d746d4811a1d6dda516c0e4985/bulktest/batch_lib.inc#L994">detecta los formatos de imagen</a> es verificar primero las palabras clave en el tipo MIME y usar como alternativa la extensión de archivo. Esto significa que el formato para imágenes con una URL como la anterior se clasifica como WebP, ya que WebP es compatible con HTTP Archive como agente de usuario.</p>
+<aside class="note">Tenga en cuenta que algunos servicios de imágenes o CDN entregarán automáticamente WebP (en lugar de JPEG o PNG) a plataformas que admitan WebP, incluso para una URL con el sufijo `.jpg` o` .png`. Por ejemplo, <a hreflang="en" href="https://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg">IMG_20190113_113201.jpg</a> devuelve una imagen WebP en Chrome. Sin embargo, la forma en que HTTP Archive <a hreflang="en" href="https://github.com/HTTPArchive/legacy.httparchive.org/blob/31a25b9064a365d746d4811a1d6dda516c0e4985/bulktest/batch_lib.inc#L994">detecta los formatos de imagen</a> es verificar primero las palabras clave en el tipo MIME y usar como alternativa la extensión de archivo. Esto significa que el formato para imágenes con una URL como la anterior se clasifica como WebP, ya que WebP es compatible con HTTP Archive como agente de usuario.</aside>
 
 ### PNG
 
diff --git a/src/content/es/2019/markup.md b/src/content/es/2019/markup.md
index 4bd96ceb13a..cb6af6ebaee 100644
--- a/src/content/es/2019/markup.md
+++ b/src/content/es/2019/markup.md
@@ -38,7 +38,7 @@ Mirar un recuento de frecuencia sin procesar no es especialmente útil, incluso
 
 En lugar, como en el estudio original de Hixie, Lo que veremos es cuántos sitios incluyen cada elemento al menos una vez en su página de inicio.
 
-<p class="note">Nota: Esto es, en sí mismo, no sin algunos sesgos potenciales. Varios sitios pueden utilizar productos populares, lo que introduce un marcado no estándar, incluso "invisible" para autores individuales. Por lo tanto, se debe tener cuidado al reconocer que el uso no implica necesariamente el conocimiento directo del autor y la adopción consciente tanto como el servicio de una necesidad común, de una manera común. Durante nuestra investigación, encontramos varios ejemplos de esto, algunos los indicaremos.</p>
+<aside class="note">Nota: Esto es, en sí mismo, no sin algunos sesgos potenciales. Varios sitios pueden utilizar productos populares, lo que introduce un marcado no estándar, incluso "invisible" para autores individuales. Por lo tanto, se debe tener cuidado al reconocer que el uso no implica necesariamente el conocimiento directo del autor y la adopción consciente tanto como el servicio de una necesidad común, de una manera común. Durante nuestra investigación, encontramos varios ejemplos de esto, algunos los indicaremos.</aside>
 
 ## Principales elementos e información general
 
@@ -163,7 +163,7 @@ En el conjunto de datos de escritorio, recopilamos datos para los principales 4,
 
 Además, el 15% de las páginas de escritorio y el 16% de las páginas móviles contienen elementos obsoletos.
 
-<p class="note">Nota: Mucho de esto es muy probable debido al uso de productos en lugar de que los autores individuales sigan creando manualmente el marcado.</p>
+<aside class="note">Nota: Mucho de esto es muy probable debido al uso de productos en lugar de que los autores individuales sigan creando manualmente el marcado.</aside>
 
 {{ figure_markup(
   image="fig6.png",
diff --git a/src/content/es/2019/media.md b/src/content/es/2019/media.md
index fd2287ea67d..b1bce3297f9 100644
--- a/src/content/es/2019/media.md
+++ b/src/content/es/2019/media.md
@@ -86,7 +86,7 @@ Para los dispositivos móviles usados en el rastreo (<i lang="en">crawl</i>) de
 
 Si tuviéramos una imagen que ocupase perfectamente la totalidad de la pantalla, el ratio de relleno de píxeles sería de 1x. Por supuesto, rara vez una página web ocupa la pantalla completa con una única imagen. El contenido multimedia suele mezclarse con el diseño y otro tipo de contenido. Un valor superior a 1x significa que el diseño requiere que el usuario haga scroll para ver el resto de la imagen.
 
-<p class="note">Nota: esto es únicamente analizando el diseño CSS para tanto el <i lang="en">DPR</i> como para la cantidad de contenido del diseño. No está evaluándose la efectividad de las imágenes <i lang="en">responsive</i> o la efectividad de facilitar un contenido con alto DPR.</p>
+<aside class="note">Nota: esto es únicamente analizando el diseño CSS para tanto el <i lang="en">DPR</i> como para la cantidad de contenido del diseño. No está evaluándose la efectividad de las imágenes <i lang="en">responsive</i> o la efectividad de facilitar un contenido con alto DPR.</aside>
 
 {{ figure_markup(
   image="fig5_image_pixel_volume_v_css_pixels.png",
@@ -111,7 +111,7 @@ Mientras que el enfoque utilizado para imágenes, vídeos y animaciones son, a g
 * **<i lang="en">Lazy loading</i>** - para trasladar solamente contenido que pueda ser visto por un humano.
 * **Accesibilidad** - asegurando una experiencia consistente para todos los seres humanos.
 
-<p class="note">Una advertencia a la hora de interpretar estos resultados. Las páginas webs rastreadas para el Web Almanac fueron rastreadas con un navegador Chrome. Esto significa que la negociación de contenido que pueda estar mejor integrada para Safari o Firefox podría no estar representada en este conjunto de datos. Por ejemplo, el uso de formatos de archivos como JPEG2000, JPEG-XR, HEVC, y HEIC no están representados porque estos no son compatibles de forma nativa con Chrome. Esto no significa que la web no contenga estos otros formatos o experiencias. Del mismo modo, Chrome tiene soporte nativo para <i lang="en">lazy loading</i> (desde la v76) el cual no está disponible en otros navegadores. Puedes leer más sobre estas excepciones en <a href="./methodology">Metodología</a>.</p>
+<aside class="note">Una advertencia a la hora de interpretar estos resultados. Las páginas webs rastreadas para el Web Almanac fueron rastreadas con un navegador Chrome. Esto significa que la negociación de contenido que pueda estar mejor integrada para Safari o Firefox podría no estar representada en este conjunto de datos. Por ejemplo, el uso de formatos de archivos como JPEG2000, JPEG-XR, HEVC, y HEIC no están representados porque estos no son compatibles de forma nativa con Chrome. Esto no significa que la web no contenga estos otros formatos o experiencias. Del mismo modo, Chrome tiene soporte nativo para <i lang="en">lazy loading</i> (desde la v76) el cual no está disponible en otros navegadores. Puedes leer más sobre estas excepciones en <a href="./methodology">Metodología</a>.</aside>
 
 Es raro encontrar una página web que no utilice imágenes. A lo largo de los años, han aparecido muchos formatos de archivo diferentes para ayudar a mostrar el contenido en la web, cada uno abordando un problema diferente. Principalmente, hay 4 formatos de imagen universales: JPEG, PNG, GIF, y SVG. Además, Chrome ha mejorado el canal multimedia y añadido soporte a un quinto formato de imagen: WebP. Otros navegadores, del mismo modo, han añadido soporte para JPEG2000 (Safari), JPEG-XL (IE y Edge) y HEIC (WebView solamente en Safari).
 
diff --git a/src/content/es/2019/performance.md b/src/content/es/2019/performance.md
index 9830d1e0225..e6cbab55a22 100644
--- a/src/content/es/2019/performance.md
+++ b/src/content/es/2019/performance.md
@@ -60,7 +60,7 @@ Así que vamos a profundizar y ver qué resultados podemos encontrar.
 
 En la Figura 7.1 anterior, se puede ver cómo se distribuyen las experiencias de FCP en la web. De los millones de sitios web en el conjunto de datos de CrUX, este gráfico comprime la distribución a 1.000 sitios web, donde cada segmento vertical representa un sólo sitio web. El cuadro está ordenado por el porcentaje de experiencias rápidas de FCP, que son las que ocurren en menos de 1 segundo. Las experiencias lentas ocurren en 3 segundos o más, y las experiencias moderadas (anteriormente conocidas como "promedias") son todo lo que hay en medio. En los extremos de la tabla hay algunos sitios web con experiencias casi 100% rápidas y algunos sitios web con experiencias casi 100% lentas. Entre medias, los sitios web que tienen una combinación de rendimiento rápido, moderado y lento parecen inclinarse más hacia rápido o moderado que lento, lo cual es bueno.
 
-<p class="note">Nota: cuando un usuario experimenta un rendimiento lento es difícil decir cuál podría ser el motivo. Podría ser que el sitio web en sí mismo se construyó de manera deficiente e ineficiente. O podría haber otros factores ambientales como la conexión lenta del usuario, la caché vacía, etc. Por lo tanto, cuando miramos estos datos de campo, preferimos decir que las experiencias del usuario son lentas y no necesariamente los sitios web.</p>
+<aside class="note">Nota: cuando un usuario experimenta un rendimiento lento es difícil decir cuál podría ser el motivo. Podría ser que el sitio web en sí mismo se construyó de manera deficiente e ineficiente. O podría haber otros factores ambientales como la conexión lenta del usuario, la caché vacía, etc. Por lo tanto, cuando miramos estos datos de campo, preferimos decir que las experiencias del usuario son lentas y no necesariamente los sitios web.</aside>
 
 Para clasificar si un sitio web es lo suficientemente **rápido** utilizaremos la nueva metodología <a hreflang="en" href="https://developers.google.com/speed/docs/insights/v5/about#categories">PageSpeed Insights</a> (PSI), donde al menos el 75% de las experiencias de FCP del sitio web deben ser más rápidas que 1 segundo. Del mismo modo, un sitio web lo suficientemente **lento** tiene un 25% o más de experiencias FCP más lentas que 3 segundos. Decimos que un sitio web tiene un rendimiento **moderado** cuando no cumple con ninguna de estas condiciones.
 
diff --git a/src/content/es/2020/ecommerce.md b/src/content/es/2020/ecommerce.md
index 8c272d12f06..eeceabf162e 100644
--- a/src/content/es/2020/ecommerce.md
+++ b/src/content/es/2020/ecommerce.md
@@ -64,7 +64,7 @@ Nuestra metodología tiene las siguientes limitaciones:
 
 En total, 21.72% de los sitios móviles y 21.27% de los sitios de escritorio usan una plataforma de comercio electrónico. Para 2019, el porcentaje era 9.41% para sitios móviles y 9.67% en sitios de escritorio.
 
-<p class="note">Nota: Este aumento se debe principalmente a mejoras hechas a Wappalyzer para detectar los sitios de comercio electrónico y no debe ser atribuido a otros factores como el crecimiento debido al Covid-19. Además, una corrección menor fue aplicada a las estadísticas del 2019 de forma retrospectiva para compensar un error y, por lo tanto, los porcentajes de 2019 son ligeramente diferentes de los mencionados en el capítulo de <a href="../2019/ecommerce">Comercio Electrónico 2019</a>.</p>
+<aside class="note">Nota: Este aumento se debe principalmente a mejoras hechas a Wappalyzer para detectar los sitios de comercio electrónico y no debe ser atribuido a otros factores como el crecimiento debido al Covid-19. Además, una corrección menor fue aplicada a las estadísticas del 2019 de forma retrospectiva para compensar un error y, por lo tanto, los porcentajes de 2019 son ligeramente diferentes de los mencionados en el capítulo de <a href="../2019/ecommerce">Comercio Electrónico 2019</a>.</aside>
 
 ### Principales plataformas de comercio electrónico
 
@@ -135,7 +135,7 @@ El COVID-19 ha tenido un gran impacto mundial y ha hecho necesario un cambio onl
 
 Definitivamente existe un crecimiento significativo en los sitios WooCommerce y Shopify alrededor del tiempo que el COVID empezó a afectar realmente al mundo.
 
-<p class="note">Nota: <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/pull/2731/commits/f44f20f03618f6a5fd868dd38ce9db5e2e2f1407">La detección de Wappalyzer para Wix</a> no diferencia si un sitio esta usando Wix como CMS o como plataforma de comercio electrónico. Debido a ello, el crecimiento de Wix como plataforma de comercio electrónico puede no estar representado correctamente en la gráfica anterior.</p>
+<aside class="note">Nota: <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/pull/2731/commits/f44f20f03618f6a5fd868dd38ce9db5e2e2f1407">La detección de Wappalyzer para Wix</a> no diferencia si un sitio esta usando Wix como CMS o como plataforma de comercio electrónico. Debido a ello, el crecimiento de Wix como plataforma de comercio electrónico puede no estar representado correctamente en la gráfica anterior.</aside>
 
 ## Tamaño de página y peticiones
 
@@ -241,7 +241,7 @@ Las imágenes anteriores muestran que la página de comercio electrónico promed
   sql_file="pagestats_image_bydevice_format.sql"
 ) }}
 
-<p class="note">Hay que mencionar que algunos servicios de imágenes o CDNs entregan automáticamente imágenes en formato WebP (en vez de JPEG o PNG) a plataformas que soportan WebP, aún cuando la URL tiene un sufijo <code>.jpg</code> o <code>.png</code>. Por ejemplo, la imagen <code>IMG_20190113_113201.jpg</code> muestra una imagen WebP en Chrome. Sin embargo, la forma en la que el HTTP Archive detecta los formatos de imágenes es revisar las palabras clave en tipo MIME primero, después se verifica la extensión del archivo. Esto significa que el formato para imágenes con URLs como la anterior, son identificadas como WebP, ya que WebP es soportado por HTTP Archive como agente de usuario.</p>
+<aside class="note">Hay que mencionar que algunos servicios de imágenes o CDNs entregan automáticamente imágenes en formato WebP (en vez de JPEG o PNG) a plataformas que soportan WebP, aún cuando la URL tiene un sufijo <code>.jpg</code> o <code>.png</code>. Por ejemplo, la imagen <code>IMG_20190113_113201.jpg</code> muestra una imagen WebP en Chrome. Sin embargo, la forma en la que el HTTP Archive detecta los formatos de imágenes es revisar las palabras clave en tipo MIME primero, después se verifica la extensión del archivo. Esto significa que el formato para imágenes con URLs como la anterior, son identificadas como WebP, ya que WebP es soportado por HTTP Archive como agente de usuario.</aside>
 
 El uso de PNG se mantuvo casi al [mismo nivel que en 2019](../2019/ecommerce#png) (en 27% tanto para escritorio como para móvil). Observamos una reducción en el uso de JPEG (4% para escritorio y 6% para móvil). Como resultado de esta reducción, vimos que se compensan los porcentajes con un aumento en el uso de GIF. Los GIFs son muy comunes en páginas de inicio de comercio electrónico, aunque no se usan mucho los GIFs en las páginas de producto. Ya que nuestra metodología solo toma en cuenta las páginas de inicio, esto explica el incremento en el uso de GIFs en los sitios de comercio electrónico. Lighthouse tiene una auditoría que recomienda usar "formatos de video para contenido animado". Esta es una técnica que los sitios de comercio electrónico pueden usar para optimizar su rendimiento y así mantener las propiedades de animación de los GIFs. Revisa <a hreflang="es" href="https://web.dev/i18n/es/replace-gifs-with-videos/">este artículo</a> para más información.
 
@@ -437,7 +437,7 @@ La adopción del etiquetado del lado del servidor dependerá en que los terceros
   <figcaption>{{ figure_link(caption="Tag manager usage on ecommerce sites.", sheets_gid="2045910168", sql_file="percent_of_ecommsites_using_each_tag_managers.sql") }}</figcaption>
 </figure>
 
-<p class="note">Nota: El análisis anterior está basado en la detección de Wappalyzer, que puede diferir del análisis realizado con los datos de <a href="./methodology#third-party-web">Third Party Web</a> que es usado en el capítulo de <a href="./third-parties">Contenido de Terceros</a>.</p>
+<aside class="note">Nota: El análisis anterior está basado en la detección de Wappalyzer, que puede diferir del análisis realizado con los datos de <a href="./methodology#third-party-web">Third Party Web</a> que es usado en el capítulo de <a href="./third-parties">Contenido de Terceros</a>.</aside>
 
 ### Plataformas de Gestión de Consentimiento
 
diff --git a/src/content/es/2020/http.md b/src/content/es/2020/http.md
index f3c760fdc43..56635ca6dcb 100644
--- a/src/content/es/2020/http.md
+++ b/src/content/es/2020/http.md
@@ -98,9 +98,9 @@ Al comparar la Figura 22.3 con los resultados del año pasado, ha habido un **au
   <figcaption>{{ figure_link(caption="Uso de la versión de HTTP por solicitud.", sheets_gid="2122693316", sql_file="adoption_of_http_2_by_site_and_requests.sql") }}</figcaption>
 </figure>
 
-<p class="note">
+<aside class="note">
   ** Al igual que con el rastreo del año pasado, alrededor del 4% de las solicitudes desde un dispositivo de escritorio no reportaron una versión del protocolo. El análisis muestra que en su mayoría son HTTP/1.1 y trabajamos para corregir esta brecha en nuestras estadísticas para futuros rastreos y análisis. Aunque basamos los datos en el rastreo de agosto de 2020, confirmamos la corrección en el conjunto de datos de octubre de 2020 antes de la publicación, que de hecho mostró que se trataba de solicitudes HTTP/1.1 y, por lo tanto, las agregamos a esa estadística en la tabla anterior.
-</note>
+</aside>
 
 Al revisar el número total de solicitudes de sitios web, habrá un sesgo hacia los dominios de terceros que son usuales. Para comprender mejor la adopción de HTTP/2 por instalación de servidor, veremos en su lugar el protocolo utilizado para servir el HTML desde la página de inicio de un sitio.
 
diff --git a/src/content/es/2020/javascript.md b/src/content/es/2020/javascript.md
index ef361a10dc5..c758fc334e9 100644
--- a/src/content/es/2020/javascript.md
+++ b/src/content/es/2020/javascript.md
@@ -200,9 +200,9 @@ Podemos comenzar a compensar el costo de cargar JavaScript haciendo que los scri
 
 En móviles, los scripts externos representan el 59.0% de todos los scripts encontrados.
 
-<p class="note">
+<aside class="note">
   Como nota, cuando hablamos anteriormente acerca de cuánto JavaScript es cargado en una página, ese total no tomaba en cuenta el tamaño de los scripts _inline_. Debido a que son parte del documento HTML, se cuentan como parte del tamaño de marcado. Esto significa que cargamos aún más scripts de lo que los números muestran.
-</p>
+</aside>
 
 {{ figure_markup(
   image="external-inline-mobile.png",
diff --git a/src/content/es/2020/seo.md b/src/content/es/2020/seo.md
index c54e99261c0..5a4e62932fe 100644
--- a/src/content/es/2020/seo.md
+++ b/src/content/es/2020/seo.md
@@ -425,9 +425,9 @@ El crecimiento en el uso de estos objetos es una señal general de un aumento en
 * El uso del marcado `HowTo` creció 605% en escritorio y 623% en móvil.
 * El uso del marcado `QAPage` creció 166.7% en escritorio y 192.1% en móvil.
 
-<p class="note">
+<aside class="note">
   De nuevo, es importante aclarar que estos datos pueden no ser representativos de su nivel de crecimiento real, pues estos objetos son usualmente usados en página internas.
-</p>
+</aside>
 
 La adopción de los datos estructurados es una ventaja para la web ya que la extracción de datos es valiosa para una gran cantidad de casos de uso. Esperamos que esto siga creciendo a medida que los buscadores expanden su uso y empiecen a impulsar aplicaciones más allá de la búsqueda web.
 
diff --git a/src/content/fr/2019/accessibility.md b/src/content/fr/2019/accessibility.md
index c168e7d9476..67d1d3f1fc0 100644
--- a/src/content/fr/2019/accessibility.md
+++ b/src/content/fr/2019/accessibility.md
@@ -57,7 +57,7 @@ Afin de vous assurer que votre site web soit lisible dans ces conditions, un con
 
 Seuls 22,04&nbsp;% des sites ont donné à l’ensemble de leurs textes un contraste de couleurs suffisant. En d’autres termes&nbsp;: 4 sites sur 5 ont un texte qui se confond facilement avec son arrière-plan, le rendant illisible.
 
-<p class="note">Notez que nous n’avons pas été en mesure d’analyser du texte pris dans des images, de sorte que notre statistique est une limite supérieure du nombre total de sites web réussissant le test de contraste des couleurs.</p>
+<aside class="note">Notez que nous n’avons pas été en mesure d’analyser du texte pris dans des images, de sorte que notre statistique est une limite supérieure du nombre total de sites web réussissant le test de contraste des couleurs.</aside>
 
 ### Zoom et mise à l’échelle des pages
 
diff --git a/src/content/fr/2019/css.md b/src/content/fr/2019/css.md
index 067e82347eb..8d4b1f4f1b6 100644
--- a/src/content/fr/2019/css.md
+++ b/src/content/fr/2019/css.md
@@ -107,7 +107,7 @@ Sans surprise, dans la figure 2.5 ci-dessus, `px` est le type d’unité le plus
 
 En ce qui concerne les unités basées sur l’espace physique, l’unité `cm` (centimètre) est de loin la plus populaire, suivie de `in` (pouces), puis de `Q`. Nous savons que ces types d’unités sont particulièrement utiles pour les feuilles de style d’impression, mais nous ne savions même pas que l’unité `Q` existait avant cette enquête&nbsp;! Et vous&nbsp;?
 
-<p class="note">Une version antérieure de ce chapitre parlait de la popularité inattendue de l’unité <code>Q</code>. Grâce à la <a hreflang="en" href="https://discuss.httparchive.org/t/chapter-2-css/1757/6">discussion de la communauté</a> concernant ce chapitre, nous avons identifié qu’il s’agissait d’un bogue dans notre analyse et avons mis à jour la figure 2.5 en conséquence.</p>
+<aside class="note">Une version antérieure de ce chapitre parlait de la popularité inattendue de l’unité <code>Q</code>. Grâce à la <a hreflang="en" href="https://discuss.httparchive.org/t/chapter-2-css/1757/6">discussion de la communauté</a> concernant ce chapitre, nous avons identifié qu’il s’agissait d’un bogue dans notre analyse et avons mis à jour la figure 2.5 en conséquence.</aside>
 
 ### Unités basées sur la taille de fenêtre (<i lang="en">viewport</i> {unites-basees-sur-la-taille-de-fenetre-viewport}
 
diff --git a/src/content/fr/2019/javascript.md b/src/content/fr/2019/javascript.md
index 50912d63c58..e64016ddbd4 100644
--- a/src/content/fr/2019/javascript.md
+++ b/src/content/fr/2019/javascript.md
@@ -299,7 +299,7 @@ Les autres bibliothèques JavaScript les plus utilisées comprennent les variant
 
 ### Frameworks et bibliothèques d'interface
 
-<p class="note">Comme mentionné dans notre <a href="./methodology#wappalyzer">méthodologie</a>, la bibliothèque de détection tierce utilisée dans HTTP Archive (Wappalyzer) a un certain nombre de limitations en ce qui concerne la manière dont elle détecte certains outils. Un ticket est ouvert concernant <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/issues/2450">l’amélioration de la détection des bibliothèques et <span lang="en">frameworks</span> JavaScript</a>, ce qui aura eu un impact sur les résultats présentés ici.</p>
+<aside class="note">Comme mentionné dans notre <a href="./methodology#wappalyzer">méthodologie</a>, la bibliothèque de détection tierce utilisée dans HTTP Archive (Wappalyzer) a un certain nombre de limitations en ce qui concerne la manière dont elle détecte certains outils. Un ticket est ouvert concernant <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/issues/2450">l’amélioration de la détection des bibliothèques et <span lang="en">frameworks</span> JavaScript</a>, ce qui aura eu un impact sur les résultats présentés ici.</aside>
 
 Au cours des dernières années, l’écosystème JavaScript a connu une augmentation du nombre de bibliothèques et <span lang="en">frameworks</span> open-source pour faciliter la création d’applications monopages (SPA). Une application monopage se caractérise par une page web qui charge une seule page HTML et utilise JavaScript pour modifier la page lors de l’interaction avec l’utilisateur au lieu de télécharger de nouvelles pages depuis le serveur. Bien que cela reste la principale prémisse des applications monopages, différentes approches de rendu du serveur peuvent encore être utilisées pour améliorer l’expérience de ces sites. Combien de sites utilisent ces types de <span lang="en">frameworks</span>&nbsp;?
 
diff --git a/src/content/fr/2019/markup.md b/src/content/fr/2019/markup.md
index 433e109cd45..838fffec2f9 100644
--- a/src/content/fr/2019/markup.md
+++ b/src/content/fr/2019/markup.md
@@ -38,7 +38,7 @@ Examiner un nombre de fréquences brut n’est pas particulièrement utile, mêm
 
 Au lieu de faire ça, nous allons examiner combien de sites incluent chaque élément au moins une fois dans leur page d’accueil, comme dans l’étude originale de Hixie.
 
-<p class="note">Remarque : cette démarche n’est pas dénuée, en soi, de biais potentiels. Des solutions populaires, pouvant être utilisées par plusieurs sites, peuvent introduire un balisage non standard "invisible" à chaque auteur. Ainsi, il faut veiller à reconnaître que l’utilisation n’implique pas nécessairement la connaissance directe de l’auteur et l’adoption consciente puisqu’elle répond à un besoin commun, d’une manière commune. Au cours de notre recherche, nous avons trouvé plusieurs exemples, dont certains seront explicités.</p>
+<aside class="note">Remarque : cette démarche n’est pas dénuée, en soi, de biais potentiels. Des solutions populaires, pouvant être utilisées par plusieurs sites, peuvent introduire un balisage non standard "invisible" à chaque auteur. Ainsi, il faut veiller à reconnaître que l’utilisation n’implique pas nécessairement la connaissance directe de l’auteur et l’adoption consciente puisqu’elle répond à un besoin commun, d’une manière commune. Au cours de notre recherche, nous avons trouvé plusieurs exemples, dont certains seront explicités.</aside>
 
 ## Principaux éléments de balisage et généralités
 
@@ -163,7 +163,7 @@ Dans le jeu de données pour ordinateurs de bureau, nous avons collecté des don
 
 En outre, 15 % des pages pour ordinateurs de bureau et 16 % des pages mobiles contiennent des éléments obsolètes.
 
-<p class="note">Remarque : Il est très probable que cela soit dû en grande partie à l’utilisation de solutions plutôt qu’à des auteurs isolés qui continueraient à créer manuellement ce balisage.</p>
+<aside class="note">Remarque : Il est très probable que cela soit dû en grande partie à l’utilisation de solutions plutôt qu’à des auteurs isolés qui continueraient à créer manuellement ce balisage.</aside>
 
 {{ figure_markup(
   image="fig6.png",
diff --git a/src/content/fr/2019/media.md b/src/content/fr/2019/media.md
index 28b994f3aaa..f693cdca34c 100644
--- a/src/content/fr/2019/media.md
+++ b/src/content/fr/2019/media.md
@@ -86,7 +86,7 @@ Pour le terminal mobile utilisé pour le parcours des pages web, nous avons un a
 
 Si nous avions une image qui remplissait parfaitement tout l’écran, le taux de remplissage serait de 1x le taux de pixel. Bien sûr, il est rare qu’un site web remplisse toute la surface de la page avec une seule image. Le contenu des médias a tendance à se mélanger avec le design et d’autres contenus. Une valeur supérieure à 1x implique que la mise en page oblige l’utilisateur à faire défiler l’image pour voir le contenu supplémentaire.
 
-<p class="note">Remarque&nbsp;: ceci ne concerne que la mise en page CSS, à la fois pour le ratio de pixels et le volume du contenu de la mise en page. Il ne s’agit pas d’évaluer la pertinence des images adaptatives ou la pertinence de fournir des contenus à haute densité de pixels.</p>
+<aside class="note">Remarque&nbsp;: ceci ne concerne que la mise en page CSS, à la fois pour le ratio de pixels et le volume du contenu de la mise en page. Il ne s’agit pas d’évaluer la pertinence des images adaptatives ou la pertinence de fournir des contenus à haute densité de pixels.</aside>
 
 {{ figure_markup(
   image="fig5_image_pixel_volume_v_css_pixels.png",
@@ -111,7 +111,7 @@ Si les stratégies utilisées pour les images, les vidéos et les animations son
 * **Lazy loading** - ne transférer les contenus que lorsqu’un être humain les verra
 * **Accessibilité** - garantir une expérience de qualité pour tous les êtres humains
 
-<p class="note">Un avertissement concernant l’interprétation de ces résultats. Les pages web explorées pour le Web Almanac ont été explorées sur un navigateur Chrome. Cela implique que toute négociation de contenu qui pourrait mieux s’appliquer à Safari ou Firefox pourrait ne pas être représentée dans cet ensemble de données. Par exemple, l’utilisation de formats de fichiers comme JPEG2000, JPEG-XR, HEVC et HEIC est absente car ceux-ci ne sont pas pris en charge par Chrome. Cela ne signifie pas que le web ne contient pas ces autres formats ou expériences. De même, Chrome supporte en natif le <i lang="en">lazy loading</i> (depuis la version 76), ce qui n’est pas encore disponible dans les autres navigateurs. Pour en savoir plus sur ces réserves, consultez notre <a href="./methodology">Méthodologie</a>.</p>
+<aside class="note">Un avertissement concernant l’interprétation de ces résultats. Les pages web explorées pour le Web Almanac ont été explorées sur un navigateur Chrome. Cela implique que toute négociation de contenu qui pourrait mieux s’appliquer à Safari ou Firefox pourrait ne pas être représentée dans cet ensemble de données. Par exemple, l’utilisation de formats de fichiers comme JPEG2000, JPEG-XR, HEVC et HEIC est absente car ceux-ci ne sont pas pris en charge par Chrome. Cela ne signifie pas que le web ne contient pas ces autres formats ou expériences. De même, Chrome supporte en natif le <i lang="en">lazy loading</i> (depuis la version 76), ce qui n’est pas encore disponible dans les autres navigateurs. Pour en savoir plus sur ces réserves, consultez notre <a href="./methodology">Méthodologie</a>.</aside>
 
 Il est rare de trouver une page web qui n’utilise pas d’images. Au fil des ans, de nombreux formats de fichiers différents sont apparus pour aider à présenter le contenu sur le web, chacun répondant à un problème différent. Il existe principalement 4 principaux formats d’images universels&nbsp;: JPEG, PNG, GIF et SVG. En outre, Chrome a enrichi le catalogue de médias et a ajouté la prise en charge d’un cinquième format d’image&nbsp;: WebP. D’autres navigateurs ont également ajouté la prise en charge des formats JPEG2000 (Safari), JPEG-XL (IE et Edge) et HEIC (WebView uniquement dans Safari).
 
diff --git a/src/content/fr/2019/mobile-web.md b/src/content/fr/2019/mobile-web.md
index 6882e5ab59a..8588894b7aa 100644
--- a/src/content/fr/2019/mobile-web.md
+++ b/src/content/fr/2019/mobile-web.md
@@ -82,7 +82,7 @@ Allons plus loin et examinons une autre mesure qui se concentre davantage sur _c
 - il est également livré sous forme de texte au navigateur. Il se compresse donc bien et devrait être livré plus rapidement qu’une simple capture d’écran de la page&nbsp;;
 - ainsi, si la quantité totale de JavaScript qu’une page télécharge (sans compter les images, CSS, etc.) est supérieure à une capture d’écran PNG du viewport, nous utilisons beaucoup trop de JavaScript. À ce stade, il serait plus rapide d’envoyer cette capture d’écran pour obtenir l’état initial de la page&nbsp;!
 
-<p class="note">Le <strong>JavaScript Bloat Score</strong> est défini comme suit&nbsp;: (taille totale du JavaScript) / (taille de la capture d’écran PNG du port d’affichage). Tout nombre supérieur à 1 signifie qu’il est plus rapide d’envoyer une capture d’écran.</p>
+<aside class="note">Le <strong>JavaScript Bloat Score</strong> est défini comme suit&nbsp;: (taille totale du JavaScript) / (taille de la capture d’écran PNG du port d’affichage). Tout nombre supérieur à 1 signifie qu’il est plus rapide d’envoyer une capture d’écran.</aside>
 
 Quels en sont les résultats&nbsp;? Sur les plus de 5 millions de sites web analysés, 75,52&nbsp;% étaient surchargés de JavaScript. Nous avons encore un long chemin à parcourir.
 
@@ -223,7 +223,7 @@ Certains designers aiment utiliser des icônes à la place du texte&nbsp;; elles
 
 C’est pourquoi il est important d’éviter toute confusion et d’ajouter du texte complémentaire et des étiquettes à vos boutons. À l’heure actuelle, au moins 28,59&nbsp;% des sites incluent un bouton avec une seule icône sans texte complémentaire.
 
-<p class="note">Note&nbsp;: le nombre indiqué ci-dessus n’est qu’une limite inférieure. Au cours de notre analyse, nous n’avons inclus que les boutons utilisant des icônes de police sans texte complémentaire. Cependant, de nombreux boutons utilisent désormais des SVG au lieu d’icônes de police, aussi les inclurons-nous également dans les prochaines exécutions.</p>
+<aside class="note">Note&nbsp;: le nombre indiqué ci-dessus n’est qu’une limite inférieure. Au cours de notre analyse, nous n’avons inclus que les boutons utilisant des icônes de police sans texte complémentaire. Cependant, de nombreux boutons utilisent désormais des SVG au lieu d’icônes de police, aussi les inclurons-nous également dans les prochaines exécutions.</aside>
 
 ## Champs de formulaire sémantique
 
@@ -278,7 +278,7 @@ Actuellement, seules 29,62&nbsp;% des pages comportant des champs de saisie util
 
 Permettre aux utilisateurs de copier et de coller leurs mots de passe dans votre page leur permet d’utiliser un gestionnaire de mots de passe. Les gestionnaires de mots de passe aident les utilisateurs à générer (et à mémoriser) des mots de passe forts et à les remplir automatiquement sur les pages web. Seulement 0,02&nbsp;% des pages web testées désactivent cette fonctionnalité.
 
-<p class="note">Note&nbsp;: Bien que cela soit très encourageant, il s’agit peut-être d’une sous-estimation en raison de l’exigence de notre <a href="./methodology">méthodologie</a> de ne tester que les pages d’accueil. Les pages intérieures, comme les pages de connexion, ne sont pas testées.</p>
+<aside class="note">Note&nbsp;: Bien que cela soit très encourageant, il s’agit peut-être d’une sous-estimation en raison de l’exigence de notre <a href="./methodology">méthodologie</a> de ne tester que les pages d’accueil. Les pages intérieures, comme les pages de connexion, ne sont pas testées.</aside>
 
 ## Conclusion
 
@@ -297,7 +297,7 @@ Le web mobile existe maintenant depuis assez longtemps pour qu’il y ait toute
   )
 }}
 
-<p class="note" data-markdown="1">Notes&nbsp;:
+<aside class="note" data-markdown="1">Notes&nbsp;:
 
 1. Nous avons considéré que les sites faisant un effort en matière de mobile sont ceux qui adaptent leur design à des écrans plus petits. Ou plutôt, ceux qui ont au moins un point de rupture CSS à 600&nbsp;px ou moins.
 
@@ -308,4 +308,4 @@ Le web mobile existe maintenant depuis assez longtemps pour qu’il y ait toute
 4. Le nombre total de smartphones actifs a été trouvé en additionnant le nombre de téléphones Android et iPhone actifs (rendus publics par Apple et Google), et un peu de maths pour prendre en compte les téléphones chinois connectés à Internet. <a hreflang="en" href="https://www.ben-evans.com/benedictevans/2019/5/28/the-end-of-mobile">Plus d’infos ici</a>.
 
 5. Le nombre de 1,6 milliards d’ordinateurs de bureau est calculé à partir de nombres rendus publics par <a hreflang="en" href="https://web.archive.org/web/20181030132235/https://news.microsoft.com/bythenumbers/en/windowsdevices">Microsoft</a> et <a hreflang="en" href="https://web.archive.org/web/20190628161024/https://appleinsider.com/articles/18/10/30/apple-passes-100m-active-mac-milestone-thanks-to-high-numbers-of-new-users">Apple</a>. Il n’inclut pas les ordinateurs Linux.
-</p>
+</aside>
diff --git a/src/content/fr/2019/resource-hints.md b/src/content/fr/2019/resource-hints.md
index f848fb6e9a5..6c974e9fd1d 100644
--- a/src/content/fr/2019/resource-hints.md
+++ b/src/content/fr/2019/resource-hints.md
@@ -66,7 +66,7 @@ Comme l'utilisation des indices de ressources dans les en-têtes HTTP est très
 
 ## Les indices de ressources
 
-<p class="note">Note: il n'y a pas de différence notable entre l'usage des indices de ressources sur les pages web destinées aux ordinateurs ou périphériques mobiles. C'est pourquoi, par souci de concision, ce chapitre n'inclut que les statistiques relatives aux mobiles.</p>
+<aside class="note">Note: il n'y a pas de différence notable entre l'usage des indices de ressources sur les pages web destinées aux ordinateurs ou périphériques mobiles. C'est pourquoi, par souci de concision, ce chapitre n'inclut que les statistiques relatives aux mobiles.</aside>
 
 <figure>
   <table>
diff --git a/src/content/fr/2019/seo.md b/src/content/fr/2019/seo.md
index 9b1882a3179..fc18fac78db 100644
--- a/src/content/fr/2019/seo.md
+++ b/src/content/fr/2019/seo.md
@@ -34,7 +34,7 @@ Notre étude se base sur des données de [Lighthouse](./methodology#lighthouse),
 
 Nos métriques personnalisées fournissent des informations qui, jusqu'à présent, n'avaient pas été exposées auparavant. Nous sommes maintenant en mesure de faire des constats sur l'adoption et la mise en œuvre d'éléments tels que des balises `link` avec attribut `hreflang`, l'éligibilité des résultats enrichis, l'utilisation de la balise `title` et même la navigation basée sur les ancres pour les applications d'une seule page (SPA).
 
-<p class="note">Remarque&nbsp;: nos données se limitent à l'analyse des pages d'accueil uniquement et n'ont pas été collectées à partir d'analyses de toutes les pages des sites web. Cela aura un impact sur de nombreuses mesures dont nous discuterons, nous avons donc ajouté toutes les limitations pertinentes à chaque fois que nous mentionnons une mesure personnalisée. En savoir plus sur ces limitations dans notre <a href="./methodology">méthodologie</a>.</p>
+<aside class="note">Remarque&nbsp;: nos données se limitent à l'analyse des pages d'accueil uniquement et n'ont pas été collectées à partir d'analyses de toutes les pages des sites web. Cela aura un impact sur de nombreuses mesures dont nous discuterons, nous avons donc ajouté toutes les limitations pertinentes à chaque fois que nous mentionnons une mesure personnalisée. En savoir plus sur ces limitations dans notre <a href="./methodology">méthodologie</a>.</aside>
 
 Lisez la suite pour en savoir plus sur l'état actuel du web et sa compatibilité pour les moteurs de recherche.
 
@@ -146,7 +146,7 @@ Il est recommandé de conserver un code de réponse HTTP `200 OK` pour toutes le
 
 Le code de réponse suivant le plus fréquemment trouvé sur mobile était le `302`, une redirection temporaire, qui a été trouvée sur 10,45 % des pages mobiles. C'était plus élevé que sur le bureau, avec seulement 6,71 % des pages d'accueil du bureau renvoyant un code d'état `302`. Cela pourrait être dû au fait que les <a hreflang="en" href="https://developers.google.com/search/mobile-sites/mobile-seo/separate-urls">pages d'accueil mobiles étaient des alternatives</a> vers une page de bureau équivalente, comme sur des sites non responsive qui ont des versions distinctes du site web pour chaque appareil.
 
-<p class="note">Remarque&nbsp;: nos résultats n'incluaient pas les codes d'état 4xx ou 5xx.</p>
+<aside class="note">Remarque&nbsp;: nos résultats n'incluaient pas les codes d'état 4xx ou 5xx.</aside>
 
 #### `noindex`
 
@@ -154,7 +154,7 @@ La directive `noindex` peut être indiquée dans le `HTML` ou bien dans les ent
 
 96,93 % des pages mobiles ont réussi [l'audit d'indexation de Lighthouse](https://developers.google.com/web/tools/lighthouse/audits/indexing), ce qui signifie que ces pages ne contenaient pas de directive `noindex`. Cependant, cela signifie que 3,07 % des pages d'accueil mobiles ont une directive `noindex`, ce qui est préoccupant et signifie que Google n'a pas pu indexer ces pages.
 
-<p class="note">Les sites web inclus dans notre recherche proviennent de <a href="./methodology#chrome-ux-report">Chrome UX Report</a>, qui exclut les site web non publiques. Il s'agit d'une source importante de biais, car nous ne sommes pas en mesure d'analyser les sites que Chrome juge non publics. Plus de détails sur notre <a href="./methodology#websites">méthodologie</a>.</p>
+<aside class="note">Les sites web inclus dans notre recherche proviennent de <a href="./methodology#chrome-ux-report">Chrome UX Report</a>, qui exclut les site web non publiques. Il s'agit d'une source importante de biais, car nous ne sommes pas en mesure d'analyser les sites que Chrome juge non publics. Plus de détails sur notre <a href="./methodology#websites">méthodologie</a>.</aside>
 
 #### Canonicalisation
 
diff --git a/src/content/fr/2019/third-parties.md b/src/content/fr/2019/third-parties.md
index 9ac338a4e44..d3ad1c045b6 100644
--- a/src/content/fr/2019/third-parties.md
+++ b/src/content/fr/2019/third-parties.md
@@ -57,9 +57,9 @@ Le présent chapitre classe les fournisseurs tiers dans l’une de ces grandes c
 - **Video** - fournisseurs qui hébergent un contenu vidéo quelconque de leurs utilisateurs
 - **Autre (Other)** - activité non classée ou considérée comme non conforme
 
-<p class="note">
+<aside class="note">
   <strong>Note sur les CDN</strong> : d’après les critères que nous utilisons, seuls sont comptabilisés dans la catégorie CDN les fournisseurs qui fournissent des ressources sur des domaines de CDN <strong>publics</strong> (par exemple bootstrapcdn.com, cdnjs.cloudflare.com, etc.). Cela n’inclut <strong>pas</strong> les ressources qui sont simplement servies sur un CDN. Exemple : même si vous mettez Cloudflare devant une page, nous la considérerons comme une première partie.
-</p>
+</aside>
 
 ### Quelques réserves
 
diff --git a/src/content/fr/2022/jamstack.md b/src/content/fr/2022/jamstack.md
index 2487d537a07..9768dc91868 100644
--- a/src/content/fr/2022/jamstack.md
+++ b/src/content/fr/2022/jamstack.md
@@ -34,7 +34,7 @@ Les trois définition précédentes viennent de <a hreflang="en" href="https://j
 
 Mais, comme les mots en gras le démontre, il est clair qu'il y a une certaine continuité: les sites devraient être rapides, ils devraient être pré-rendus, et ils devraient être utilisé avec une approche architectural qui découple "où on récupère vos données" de "comment vous rendez vos données". Même s'il est difficile de trouver une définition précise, les développeurs Jamstack savent ce que vous voulez dire quand vous dites "Jamstack": vous avez un site qui charge rapidement, rend beaucoup de son contenu utile en une fois, à la construction, et récupère des données supplémentaires (si nécessaire) via JavaScript.
 
-<p class="note">Avertissement: les deux auteurs de ce rapport étaient des employés de Netlify. Netlify a inventé le terme Jamstack et détient Jamstack.org. Ce rapport et l'analyse sous-jacente ont été relus et approuvés par d'autres personnes non affilié à Netlify.</p>
+<aside class="note">Avertissement: les deux auteurs de ce rapport étaient des employés de Netlify. Netlify a inventé le terme Jamstack et détient Jamstack.org. Ce rapport et l'analyse sous-jacente ont été relus et approuvés par d'autres personnes non affilié à Netlify.</aside>
 
 ## Quantifier la Jamstack: qu'est-ce qui compte?
 
@@ -80,7 +80,7 @@ Nous savions que nous voulions mesurer: les sites qui chargent la plupart de leu
 
 **Cumulative Layout Shift (CLS)**: nous avons voulu éviter les sites qui chargent très vite un squelette mais qui prennent ensuite beaucoup plus de temps pour récupérer du vrai contenu. Le plus proche que nous avons pu obtenir est la métrique <a hreflang="en" href="https://web.dev/articles/cls">Cumulative Layout Shift</a>, une mesure qui nous dit combien de fois la structure page "saute" pendant le chargement. Même s'il y a des moyens de tricher sur la mesure CLS, nous pensons toujours que c'est une approximation raisonnable pour ce que nous essayons de mesurer. Nous aimons cette mesure parce que nous sentons que les sites qui "sautent" beaucoup sont aussi ceux qui semblent être le moins "Jamstack-y", un mot que nous allons finir par utiliser souvent. A nouveau, nous avons utilisé la médiane des données du rapport de Chrome UX.
 
-<p class="note">Les données du rapport Chrome UX arrondissent les données CLS à la valeur la plus proche, à 0.05 près, que qui est une honte, car la vrai médiane semble se trouver autour de 0.02-0.03, donc, sur appareil portable, il arrondi à 0, et sur appareil de bureau, cela est arrondi à 0.05. Puisque 0 exclu un énorme nombre de pages, nous avons décidé d'utiliser 0.05 comme le meilleur seuil disponible, à la fois pour les appareils portables et ceux de bureaux.</a>
+<aside class="note">Les données du rapport Chrome UX arrondissent les données CLS à la valeur la plus proche, à 0.05 près, que qui est une honte, car la vrai médiane semble se trouver autour de 0.02-0.03, donc, sur appareil portable, il arrondi à 0, et sur appareil de bureau, cela est arrondi à 0.05. Puisque 0 exclu un énorme nombre de pages, nous avons décidé d'utiliser 0.05 comme le meilleur seuil disponible, à la fois pour les appareils portables et ceux de bureaux.</aside>
 
 **Mise en cache**: cela a été particulièrement difficile à quantifier, puisque la plupart des pages d'accueil, même sur les sites Jamstack, demandent des revalidation même si elles sont, en pratique, en cache depuis longtemps. Nous sommes partis sur une combinaison d'entêtes HTTP intégrant `Age`, `Cache-Control`, et `Expires` que nous avons trouvé en commun dans les pages qui pouvaient être en cache pendant longtemps.
 
diff --git a/src/content/it/2020/css.md b/src/content/it/2020/css.md
index 247243b7ea7..96d581c2aec 100644
--- a/src/content/it/2020/css.md
+++ b/src/content/it/2020/css.md
@@ -48,7 +48,7 @@ Per alcune metriche, guardare al CSS AST non era sufficiente. Volevamo esaminare
 
 Le metriche personalizzate (custom metrics) sono state utilizzate anche per parte dell'[analisi delle proprietà personalizzate](#proprietà-personalizzate). Sebbene possiamo ottenere molte informazioni sull'utilizzo delle proprietà personalizzate solo dai fogli di stile, non possiamo costruire un grafico delle dipendenze senza essere in grado di guardare l'albero DOM per il contesto, poiché le proprietà personalizzate vengono ereditate. Guardando lo stile di calcolo dei nodi DOM ci dà anche informazioni come a quali tipi di elementi è applicata ciascuna proprietà e quali di essi sono [registrati](https://developer.mozilla.org/docs/Web/API/CSS/RegisterProperty) - informazioni che non possiamo ottenere dai fogli di stile.
 
-<p class="note">Eseguiamo la scansione delle nostre pagine sia in modalità desktop che mobile ma per molti dati danno risultati simili quindi, se non diversamente specificato, le statistiche presentate in questo capitolo si riferiscono al set di pagine mobile.</p>
+<aside class="note">Eseguiamo la scansione delle nostre pagine sia in modalità desktop che mobile ma per molti dati danno risultati simili quindi, se non diversamente specificato, le statistiche presentate in questo capitolo si riferiscono al set di pagine mobile.</aside>
 
 ## Utilizzo
 
diff --git a/src/content/it/2020/http.md b/src/content/it/2020/http.md
index b2bef44c7ea..7090b9207e2 100644
--- a/src/content/it/2020/http.md
+++ b/src/content/it/2020/http.md
@@ -98,9 +98,9 @@ Confrontando la Figura 22.3 con i risultati dello scorso anno, c'è stato un **a
   <figcaption>{{ figure_link(caption="Utilizzo della versione HTTP su richiesta.", sheets_gid="2122693316", sql_file="adoption_of_http_2_by_site_and_requests.sql") }}</figcaption>
 </figure>
 
-<p class="note">
+<aside class="note">
   ** Come per la scansione dello scorso anno, circa il 4% delle richieste desktop non riportava una versione del protocollo. L'analisi mostra che si tratta principalmente di HTTP/1.1 e abbiamo lavorato per correggere questa lacuna nelle nostre statistiche per future scansioni e analisi. Sebbene basiamo i dati sulla scansione di agosto 2020, abbiamo confermato la correzione nel set di dati di ottobre 2020 prima della pubblicazione che mostrava effettivamente che si trattava di richieste HTTP/1.1 e quindi le abbiamo aggiunte a quella statistica nella tabella sopra.
-</note>
+</aside>
 
 Quando si esamina il numero totale di richieste di siti web, ci sarà una preferenza per i comuni domini di terze parti. Per avere una migliore comprensione dell'adozione di HTTP/2 da parte dell'installazione del server, esamineremo invece il protocollo utilizzato per servire l'HTML dalla home page di un sito.
 
diff --git a/src/content/it/2020/javascript.md b/src/content/it/2020/javascript.md
index c113e277b5d..26911cea3c7 100644
--- a/src/content/it/2020/javascript.md
+++ b/src/content/it/2020/javascript.md
@@ -200,9 +200,9 @@ Possiamo iniziare a compensare parte del costo del caricamento di JavaScript car
 
 Sui dispositivi mobile, gli script esterni costituiscono il 59,0% di tutti gli elementi di script trovati.
 
-<p class="note">
+<aside class="note">
   Per inciso, quando abbiamo parlato di quanto JavaScript è stato caricato in una pagina in precedenza, quel totale non ha tenuto conto della dimensione di questi script inline, poiché fanno parte del documento HTML, vengono conteggiati rispetto alla dimensione del markup . Ciò significa che carichiamo ancora più script che mostrano i numeri.
-</p>
+</aside>
 
 {{ figure_markup(
   image="external-inline-mobile.png",
diff --git a/src/content/it/2020/markup.md b/src/content/it/2020/markup.md
index a04f6c2cb4c..b33b4b4b245 100644
--- a/src/content/it/2020/markup.md
+++ b/src/content/it/2020/markup.md
@@ -30,9 +30,9 @@ Come utilizziamo l'HTML, quindi, qual è la grande base che abbiamo? Nella sezio
 
 L'analisi dello scorso anno si è basata su 5.8 milioni di pagine, di cui 4.4 milioni testate su desktop e 5.3 milioni su dispositivi mobile. Quest'anno abbiamo analizzato 7.5 milioni di pagine, di cui 5.6 milioni testate su desktop e 6.3 milioni su mobile, utilizzando i [dati più recenti](./methodology#websites) sui siti web che gli utenti visiteranno nel 2020. Facciamo alcuni confronti con lo scorso anno, ma proprio come abbiamo cercato di analizzare ulteriori metriche per nuovi approfondimenti, abbiamo anche cercato di trasmettere le nostre personalità e prospettive durante il capitolo.
 
-<p class="note">
+<aside class="note">
   In questo capitolo Markup, ci stiamo concentrando quasi esclusivamente su HTML, piuttosto che su SVG o MathML, che sono anche considerati linguaggi di markup. Se non diversamente specificato, le statistiche presentate in questo capitolo si riferiscono al set di pagine mobile. Inoltre, i dati per tutti i capitoli di Web Almanac sono liberi e disponibili. Dai un'occhiata ai <a hreflang="en" href="https://docs.google.com/spreadsheets/d/1Ta7amoUeaL4pILhWzH-SCzMX9PsZeb1x_mwrX2C4eY8/">risultati</a> e <a hreflang="en" href="https://discuss.httparchive.org/t/2039">condividi le tue osservazioni</a> con la community!
-</p>
+</aside>
 
 ## Generale
 
@@ -1019,9 +1019,9 @@ Abbiamo esaminato i dati e per capire meglio i risultati, li abbiamo normalizzat
 
 I risultati mostrano che quasi la metà delle pagine che abbiamo analizzato utilizza il valore tipico di viewport `content`. Tuttavia, circa il 10% delle pagine per dispositivi mobile manca del tutto di un valore `content` appropriato per il meta elemento viewport, con il resto di esse che utilizzano una combinazione impropria di `maximum-scale`, `minimum-scale`, `user-scalable=no`, o `user-scalable=0`.
 
-<p class="note">
+<aside class="note">
   Da un po' di tempo, il browser mobile Edge consente agli utenti di ingrandire una pagina Web almeno <a hreflang="en" href="https://blogs.windows.com/windows-insider/2017/01/12/announcing-windows-10-insider-preview-build-15007-pc-mobile/">fino al 500%</a>, indipendentemente dalle impostazioni di zoom definite da una pagina web che utilizza il meta elemento viewport.
-</p>
+</aside>
 
 ### I Favicon
 
@@ -1306,7 +1306,7 @@ L'uso di `target="_blank"` è noto come una <a hreflang="en" href="https://mathi
 
 Come regola pratica e per <a hreflang="en" href="https://www.nngroup.com/articles/new-browser-windows-and-tabs/">ragioni di usabilità</a>, si raccomanda di non usare `target="_blank"` in primo luogo.
 
-<p class="note">Nelle ultime versioni di Safari e Firefox, l'impostazione di <code>target="_blank"</code> sugli elementi <code>a</code> fornisce implicitamente lo stesso comportamento <code>rel</code> dell'impostazione di <code>rel="noopener"</code>. Questo è già <a hreflang="en" href="https://chromium-review.googlesource.com/c/chromium/src/+/1630010">implementato anche in Chromium</a> e arriverà in Chrome 88.</p>
+<aside class="note">Nelle ultime versioni di Safari e Firefox, l'impostazione di <code>target="_blank"</code> sugli elementi <code>a</code> fornisce implicitamente lo stesso comportamento <code>rel</code> dell'impostazione di <code>rel="noopener"</code>. Questo è già <a hreflang="en" href="https://chromium-review.googlesource.com/c/chromium/src/+/1630010">implementato anche in Chromium</a> e arriverà in Chrome 88.</aside>
 
 ## Conclusione
 
@@ -1336,6 +1336,6 @@ Questo ci obbliga a chiudere con un appello: Fai attenzione all'HTML. Concentrat
 
 Per la prossima edizione del capitolo di Web Almanac, prepariamoci a guardare più da vicino l'arte di scrivere HTML e, si spera, come lo abbiamo migliorato.
 
-<p class="note">
+<aside class="note">
   Stiamo lasciando il resto aperto a te. Quali sono le tue osservazioni? Cosa ha attirato la tua attenzione? Cosa pensi che sia peggiorato e cosa è migliorato? <a hreflang="en" href="https://discuss.httparchive.org/t/2039">Lascia un commento</a> per condividere i tuoi pensieri!
-</p>
+</aside>
diff --git a/src/content/it/2020/seo.md b/src/content/it/2020/seo.md
index 7b408c6eccf..62270d04651 100644
--- a/src/content/it/2020/seo.md
+++ b/src/content/it/2020/seo.md
@@ -425,9 +425,9 @@ La crescita di questi oggetti è un'indicazione generale di una maggiore adozion
 * Il markup `HowTo` è cresciuto del 605% su desktop e del 623% su dispositivi mobile.
 * Il markup `QAPage` è cresciuto del 166.7% su desktop e del 192.1% su dispositivi mobili.
 
-<p class="note">
+<aside class="note">
   Ancora una volta, è importante notare che questi dati potrebbero non essere rappresentativi del loro effettivo livello di crescita, poiché questi oggetti sono solitamente posizionati su pagine interne.
-</p>
+</aside>
 
 L'adozione di dati strutturati è un vantaggio per il Web in quanto l'estrazione dei dati è preziosa per una vasta gamma di casi d'uso. Ci aspettiamo che questo continui a crescere man mano che i motori di ricerca espandono il loro utilizzo e quando inizia a potenziare le applicazioni oltre la ricerca sul web.
 
diff --git a/src/content/it/2022/markup.md b/src/content/it/2022/markup.md
index 34c48e269fc..7f4f8fe4095 100644
--- a/src/content/it/2022/markup.md
+++ b/src/content/it/2022/markup.md
@@ -155,7 +155,7 @@ Un modo per contrastare questa tendenza è <a hreflang="en" href="https://css-tr
 
 Se non si contano gli elementi `svg` e `math` (poiché sono specificati al di fuori dell'HTML) l'attuale specifica HTML consiste al momento di 111 elementi.
 
-<p class="note">Elementi, non tag, perché non ci riferiamo a semplici tag di inizio o fine, come `<li>` o `</ins>`. E alcune persone contano gli elementi HTML in modo diverso, ma la cosa più importante è <a hreflang="en" href="https://meiert.com/it/blog/the-number-of-html-elements/">essere chiari su come si contano</a>.</p>
+<aside class="note">Elementi, non tag, perché non ci riferiamo a semplici tag di inizio o fine, come `<li>` o `</ins>`. E alcune persone contano gli elementi HTML in modo diverso, ma la cosa più importante è <a hreflang="en" href="https://meiert.com/it/blog/the-number-of-html-elements/">essere chiari su come si contano</a>.</aside>
 
 Cosa possiamo osservare?
 
diff --git a/src/content/ja/2019/accessibility.md b/src/content/ja/2019/accessibility.md
index 441c2b469d9..c7130d36b81 100644
--- a/src/content/ja/2019/accessibility.md
+++ b/src/content/ja/2019/accessibility.md
@@ -57,7 +57,7 @@ Webページの主な目的はユーザーの興味を引くコンテンツを
 
 すべてのテキストに十分な色のコントラストが適用されているサイトは22.04％のみでした。これは言い換えると、5つのサイトのうち4つは背景に溶け込んで読みにくいテキストを持っていると言うことです。
 
-<p class="note">注意：画像中のテキストは分析できていないため、ここで報告されているメトリックはカラーコントラストテストに合格したWebサイトの総数の上限でしかありません。</p>
+<aside class="note">注意：画像中のテキストは分析できていないため、ここで報告されているメトリックはカラーコントラストテストに合格したWebサイトの総数の上限でしかありません。</aside>
 
 ### ズーミングとページのスケーリング
 
diff --git a/src/content/ja/2019/cdn.md b/src/content/ja/2019/cdn.md
index 19c5b12b14c..7ddb0ee605a 100644
--- a/src/content/ja/2019/cdn.md
+++ b/src/content/ja/2019/cdn.md
@@ -89,7 +89,7 @@ CDNプロバイダーには、汎用CDNと目的別CDNの2つのカテゴリが
 
 これは、ベースHTMLコンテンツを提供していることが判明した上位のCDNを見ると明確に表されています。 HTMLを提供する最も頻繁なCDNは、汎用CDN（Cloudflare、Akamai、Fastly）およびプラットフォームサービスの一部としてバンドルされたCDN（Google、Amazon）を提供するクラウドソリューションプロバイダーです。対照的に、WordpressやNetlifyなど、ベースHTMLマークアップを提供する目的に合ったCDNプロバイダーはわずかです。
 
-<p class="note">注：これにはトラフィックや使用量は反映されず、それらを使用するサイトの数のみが反映されます。</p>
+<aside class="note">注：これにはトラフィックや使用量は反映されず、それらを使用するサイトの数のみが反映されます。</aside>
 
 {{ figure_markup(
   image="html_cdn_usage.png",
@@ -478,7 +478,7 @@ TLSネゴシエーションでは、サーバーからデータを送信する
 
 対照的に、大半のCDNプロバイダーのTLSネゴシエーションの中央値は60〜70ミリ秒です。 HTMLページに対するOrigin要求は、CDNを使用するWebページよりも、TLSネゴシエーションを完了するのにほぼ3倍時間がかかります。 90パーセンタイルでも、140ミリ秒未満で完了するほとんどのCDNと比較して、この格差は427ミリ秒のoriginTLSネゴシエーションレートで永続します。
 
-<p class="note">これらのチャートを解釈する際の注意事項：実際のTLSネゴシエーションのパフォーマンスに影響する多くの要因があるため、ベンダーを比較するとき、桁の違いに焦点を合わせることが重要です。これらのテストは、制御された条件下で単一のデータセンターから完了したものであり、インターネットおよびユーザーエクスペリエンスの変動を反映していません。</p>
+<aside class="note">これらのチャートを解釈する際の注意事項：実際のTLSネゴシエーションのパフォーマンスに影響する多くの要因があるため、ベンダーを比較するとき、桁の違いに焦点を合わせることが重要です。これらのテストは、制御された条件下で単一のデータセンターから完了したものであり、インターネットおよびユーザーエクスペリエンスの変動を反映していません。</aside>
 
 {{ figure_markup(
   image="html_tls_negotiation_time.png",
@@ -1056,7 +1056,7 @@ TLSおよびRTTのパフォーマンスにCDNを使用することに加えて
 
 一般にCDNの使用は、TLS1.0のような非常に古くて侵害されたTLSバージョンの使用率が高いoriginホストサービスと比較して、強力な暗号およびTLSバージョンの迅速な採用と高い相関があります。
 
-<p class="note">Web Almanacで使用されるChromeは、ホストが提供する最新のTLSバージョンと暗号にバイアスをかけることを強調することが重要です。また、これらのWebページは2019年7月にクロールされ、新しいバージョンを有効にしたWebサイトの採用を反映しています。</p>
+<aside class="note">Web Almanacで使用されるChromeは、ホストが提供する最新のTLSバージョンと暗号にバイアスをかけることを強調することが重要です。また、これらのWebページは2019年7月にクロールされ、新しいバージョンを有効にしたWebサイトの採用を反映しています。</aside>
 
 {{ figure_markup(
   image="fig18.png",
@@ -1074,7 +1074,7 @@ RTT管理とTLSパフォーマンスの向上に加えて、CDNはHTTP/2やIPv6
 
 CDNのHTTP/2の採用率は70％を超えていますが、originページはほぼ27％です。同様にCDNのサブドメインリソースとサードパーティリソースでは90％以上がHTTP/2を採用していて、さらに高くなりますが、originインフラストラクチャから提供されるサードパーティリソースは31％しか採用されていません。 [HTTP/2](./http) のパフォーマンス向上およびその他の機能については、HTTP/2の章でさらに説明します。
 
-<p class="note">注：すべてのリクエストは、HTTP/2をサポートするChromeの最新バージョンで行われました。 HTTP/1.1のみが報告される場合、これは暗号化されていない（非TLS）サーバーまたはHTTP/2をサポートしないサーバーを示します。</p>
+<aside class="note">注：すべてのリクエストは、HTTP/2をサポートするChromeの最新バージョンで行われました。 HTTP/1.1のみが報告される場合、これは暗号化されていない（非TLS）サーバーまたはHTTP/2をサポートしないサーバーを示します。</aside>
 
 {{ figure_markup(
   image="fig19.png",
diff --git a/src/content/ja/2019/css.md b/src/content/ja/2019/css.md
index a4682c16fe9..25934d7d1d4 100644
--- a/src/content/ja/2019/css.md
+++ b/src/content/ja/2019/css.md
@@ -107,7 +107,7 @@ CSSには、異なるユニットタイプ（`rem`、`px`、`em`、`ch`、また
 
 物理的な空間に基づいた単位となると、`cm`（またはセンチメートル）ユニットが最も人気であり、次に`in`（インチ）、`Q`が続きます。これらのタイプのユニットは、印刷スタイルシートに特に役立つことがわかっていますが、この調査まで`Q`ユニットが存在することさえ知りませんでした！　知ってましたか？
 
-<p class="note">この章の以前のバージョンでは、<code>Q</code>ユニットの予想外の人気について説明しました。この章を取り巻く<a hreflang="en" href="https://discuss.httparchive.org/t/chapter-2-css/1757/6">コミュニティの議論</a>のおかげで、これは分析のバグであることがわかり、それに応じて図2.5を更新しました。</p>
+<aside class="note">この章の以前のバージョンでは、<code>Q</code>ユニットの予想外の人気について説明しました。この章を取り巻く<a hreflang="en" href="https://discuss.httparchive.org/t/chapter-2-css/1757/6">コミュニティの議論</a>のおかげで、これは分析のバグであることがわかり、それに応じて図2.5を更新しました。</aside>
 
 ### ビューポートベースのユニット
 
diff --git a/src/content/ja/2019/ecommerce.md b/src/content/ja/2019/ecommerce.md
index 652360b583d..df0fed3c2ef 100644
--- a/src/content/ja/2019/ecommerce.md
+++ b/src/content/ja/2019/ecommerce.md
@@ -445,7 +445,7 @@ HTMLペイロードには、外部リンクとして参照されるのではな
   )
 }}
 
-<p class="note">私たちのデータ収集<a href="./methodology">方法論</a>はクリックやスクロールなど、ページ上でのユーザー操作をシミュレートしていないため、遅延して読み込まれた画像はこれらの結果には表示されないことに注意してください。</p>
+<aside class="note">私たちのデータ収集<a href="./methodology">方法論</a>はクリックやスクロールなど、ページ上でのユーザー操作をシミュレートしていないため、遅延して読み込まれた画像はこれらの結果には表示されないことに注意してください。</aside>
 
 上記の図13.12と13.13で中央値のEコマースページには、モバイルでは37枚の画像と1,517KBの画像ペイロードがあり、デスクトップでは40枚の画像と1,524KBの画像ペイロードがあることを示しています。ホームページの10％は、90以上の画像と6MB近くの画像ペイロードを持っています！
 
@@ -472,7 +472,7 @@ Eコマースページのかなりの割合で、大きな画像ペイロード
   )
 }}
 
-<p class="note">画像サービスやCDNの中には、`.jpg`や`.png`という接尾辞を持つURLであっても、WebPをサポートしているプラットフォームには自動的にWebP(JPEGやPNGではなく)を配信するものがあることに注意してください。たとえば、<a hreflang="en" href="https://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg">IMG_20190113_113201.jpg</a>はChromeでWebP画像を返します。しかし、HTTP Archive<a hreflang="en" href="https://github.com/HTTPArchive/legacy.httparchive.org/blob/31a25b9064a365d746d4811a1d6dda516c0e4985/bulktest/batch_lib.inc#L994">画像フォーマットを検出する方法</a>は、最初にMIMEタイプのキーワードをチェックしてから、ファイルの拡張子にフォールバックするというものです。つまり、HTTP ArchiveがユーザーエージェントとしてWebPをサポートしているため、上記のようなURLを持つ画像のフォーマットはWebPとして与えられることになります。</p>
+<aside class="note">画像サービスやCDNの中には、`.jpg`や`.png`という接尾辞を持つURLであっても、WebPをサポートしているプラットフォームには自動的にWebP(JPEGやPNGではなく)を配信するものがあることに注意してください。たとえば、<a hreflang="en" href="https://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg">IMG_20190113_113201.jpg</a>はChromeでWebP画像を返します。しかし、HTTP Archive<a hreflang="en" href="https://github.com/HTTPArchive/legacy.httparchive.org/blob/31a25b9064a365d746d4811a1d6dda516c0e4985/bulktest/batch_lib.inc#L994">画像フォーマットを検出する方法</a>は、最初にMIMEタイプのキーワードをチェックしてから、ファイルの拡張子にフォールバックするというものです。つまり、HTTP ArchiveがユーザーエージェントとしてWebPをサポートしているため、上記のようなURLを持つ画像のフォーマットはWebPとして与えられることになります。</aside>
 
 ### PNG
 
diff --git a/src/content/ja/2019/javascript.md b/src/content/ja/2019/javascript.md
index a6a7ebbe16b..49c83de660d 100644
--- a/src/content/ja/2019/javascript.md
+++ b/src/content/ja/2019/javascript.md
@@ -299,7 +299,7 @@ JavaScriptのリソースを圧縮しているサイトはどれくらいある
 
 ### フレームワークとUIライブラリ
 
-<p class="note"><a href="./methodology#wappalyzer">方法論</a>で述べたように、HTTP Archive(Wappalyzer)で使用されているサードパーティ製の検出ライブラリには、特定のツールを検出する方法に関して多くの制限があります。<a hreflang="en" href="https://github.com/AliasIO/wappalyzer/issues/2450">JavaScriptライブラリやフレームワークの検出を改善するための未解決の問題があります</a>、それがここで紹介した結果に影響を与えています。
+<aside class="note"><a href="./methodology#wappalyzer">方法論</a>で述べたように、HTTP Archive(Wappalyzer)で使用されているサードパーティ製の検出ライブラリには、特定のツールを検出する方法に関して多くの制限があります。<a hreflang="en" href="https://github.com/AliasIO/wappalyzer/issues/2450">JavaScriptライブラリやフレームワークの検出を改善するための未解決の問題があります</a>、それがここで紹介した結果に影響を与えています。</aside>
 
 過去数年の間に、JavaScriptのエコシステムでは、**シングルページアプリケーション** (SPA) の構築を容易にするオープンソースのライブラリやフレームワークが増えてきました。シングルページアプリケーションとは、単一のHTMLページを読み込み、サーバーから新しいページを取得する代わりにJavaScriptを使用してユーザーの対話に応じてページを修正するWebページのことを指します。これはシングルページアプリケーションの大前提であることに変わりはありませんが、このようなサイトの体験を向上させるために、異なるサーバーレンダリングアプローチを使用できます。これらのタイプのフレームワークを使用しているサイトはどれくらいあるのでしょうか？
 
diff --git a/src/content/ja/2019/markup.md b/src/content/ja/2019/markup.md
index 1857c4e7556..95806eb78a0 100644
--- a/src/content/ja/2019/markup.md
+++ b/src/content/ja/2019/markup.md
@@ -38,7 +38,7 @@ featured_stat_label_3: カルーセルのバリエーションが見つかりま
 
 そのような方法を取らず、私達はHixieの元の研究のようにホームページに各要素が少なくとも1回は含まれているサイトの数に着目しました。
 
-<p class="note">注意: この方法は潜在的なバイアスが無いとは言い切れません。人気のある製品は複数のサイトで使われています。これにより個々の作成者は意識していない非標準のマークアップが導入されるでしょう。したがって、この方法は一般的なニーズに対応するのと同じように、作成者の直接的な知識や意識的な採用を意味しないことに注意する必要があります。調査中に、このような例はいくつか見つかりました。</p>
+<aside class="note">注意: この方法は潜在的なバイアスが無いとは言い切れません。人気のある製品は複数のサイトで使われています。これにより個々の作成者は意識していない非標準のマークアップが導入されるでしょう。したがって、この方法は一般的なニーズに対応するのと同じように、作成者の直接的な知識や意識的な採用を意味しないことに注意する必要があります。調査中に、このような例はいくつか見つかりました。</aside>
 
 ## 上位の要素と概説
 
@@ -163,7 +163,7 @@ featured_stat_label_3: カルーセルのバリエーションが見つかりま
 
 付け加えると、デスクトップページの15％とモバイルページの16％には、既に廃止された要素が含まれています。
 
-<p class="note">注意：この結果は、それぞれのの作成者がマークアップを手動で作成しているのではなく、何らかの製品を使っている為と考えられます。</p>
+<aside class="note">注意：この結果は、それぞれのの作成者がマークアップを手動で作成しているのではなく、何らかの製品を使っている為と考えられます。</aside>
 
 {{ figure_markup(
   image="fig6.png",
diff --git a/src/content/ja/2019/media.md b/src/content/ja/2019/media.md
index de5de214860..f491988a5ec 100644
--- a/src/content/ja/2019/media.md
+++ b/src/content/ja/2019/media.md
@@ -86,7 +86,7 @@ CSSピクセルと自然ピクセル量を見ると、中央値のウェブサ
 
 もし、画面全体を完璧に埋め尽くす画像が1枚あったとしたら、これは1xピクセルの塗りつぶし率になります。もちろん、ウェブサイトが1枚の画像でキャンバス全体を埋め尽くすことはほとんどありません。メディアコンテンツは、デザインや他のコンテンツと混在する傾向があります。1xよりも大きい値はレイアウトが追加の画像コンテンツを見るため、ユーザーが、スクロールする必要があることを意味します。
 
-<p class="note">注：これは、DPRとレイアウトコンテンツのボリュームの両方のCSSレイアウトを見ているだけです。レスポンシブ画像の効果や、DPRの高いコンテンツを提供することの効果を評価しているわけではありません。</p>
+<aside class="note">注：これは、DPRとレイアウトコンテンツのボリュームの両方のCSSレイアウトを見ているだけです。レスポンシブ画像の効果や、DPRの高いコンテンツを提供することの効果を評価しているわけではありません。</aside>
 
 {{ figure_markup(
   image="fig5_image_pixel_volume_v_css_pixels.png",
@@ -111,7 +111,7 @@ CSSピクセルと自然ピクセル量を見ると、中央値のウェブサ
 * **遅延ローディング** - 人が見たときだけコンテンツを転送する
 * **アクセシビリティ** - 全人類に一貫した体験を提供する
 
-<p class="note">これらの結果を解釈する際には注意が必要です。Web Almanacのためにクロールされたウェブページは、Chromeブラウザでクロールされました。これは、SafariやFirefoxに適したコンテンツネゴシエーションが、このデータセットでは表現されていない可能性があることを意味しています。例えば、JPEG2000、JPEG-XR、HEVC、HEICなどのファイル形式は、Chromeではネイティブにサポートされていないため、使用されていません。これは、ウェブにこれらの他の形式や経験が含まれていないことを意味するものではありません。同様に、Chrome には遅延読み込みのネイティブサポートがあります（v76 以降）が、他のブラウザではまだ利用できません。これらの注意事項については、<a href="./methodology">方法論</a>をご覧ください。</p>
+<aside class="note">これらの結果を解釈する際には注意が必要です。Web Almanacのためにクロールされたウェブページは、Chromeブラウザでクロールされました。これは、SafariやFirefoxに適したコンテンツネゴシエーションが、このデータセットでは表現されていない可能性があることを意味しています。例えば、JPEG2000、JPEG-XR、HEVC、HEICなどのファイル形式は、Chromeではネイティブにサポートされていないため、使用されていません。これは、ウェブにこれらの他の形式や経験が含まれていないことを意味するものではありません。同様に、Chrome には遅延読み込みのネイティブサポートがあります（v76 以降）が、他のブラウザではまだ利用できません。これらの注意事項については、<a href="./methodology">方法論</a>をご覧ください。</aside>
 
 画像を利用していないウェブページを見つけることは稀です。長年にわたり、ウェブ上でコンテンツを表示するためのさまざまなファイルフォーマットが登場してきましたが、それぞれが異なる問題に対処してきました。主に4つの普遍的な画像フォーマットがあります。JPEG、PNG、GIF、およびSVGです。さらに、Chromeではメディア パイプラインが強化され、5つ目の画像フォーマットのサポートが追加されました。WebP。他のブラウザでも同様にJPEG2000（Safari）、JPEG-XL（IEとEdge）、HEIC（SafariではWebViewのみ）のサポートが追加されています。
 
diff --git a/src/content/ja/2019/mobile-web.md b/src/content/ja/2019/mobile-web.md
index 4ab354e0700..099d01867c4 100644
--- a/src/content/ja/2019/mobile-web.md
+++ b/src/content/ja/2019/mobile-web.md
@@ -82,7 +82,7 @@ featured_stat_label_3: 十分なサイズのタップターゲットを持つサ
 - また、ブラウザにテキストとして配信されます。そのため、よく圧縮され、ただのページのスクリーンショットよりも速く配信されるはずです。
 - そのため、ページがダウンロードするJavaScriptの総量がビューポートのPNGスクリーンショットよりも多い場合（画像やCSSなどを含まない）、私たちはあまりにも多くのJavaScriptを使用していることになります。この時点では、スクリーンショットを送信してページの初期状態を取得した方が早いでしょう!
 
-<p class="note">*JavaScript Bloat Score*は以下のように定義されています。(JavaScriptの総サイズ)/(ビューポートのPNGスクリーンショットのサイズ)で定義されます。1.0より大きい数値は、スクリーンショットを送信するのが速いことを意味します。</p>
+<aside class="note">*JavaScript Bloat Score*は以下のように定義されています。(JavaScriptの総サイズ)/(ビューポートのPNGスクリーンショットのサイズ)で定義されます。1.0より大きい数値は、スクリーンショットを送信するのが速いことを意味します。</aside>
 
 その結果は？　分析した500万以上のウェブサイトのうち75.52％がJavaScriptで肥大化していました。まだまだ先は長いですね。
 
@@ -223,7 +223,7 @@ JavaScriptの効果をもっと詳しく知りたい方は、Addy Osmaniの<a hr
 
 だからこそ、混乱を避けるためにも、ボタンにサポートテキストやラベルを追加することが重要なのです。現在のところ、少なくとも28.59％のサイトでは、補助テキストを含まないアイコン1つだけのボタンが表示されています。
 
-<p class="note">注：上記の報告されている数字は下限値に過ぎません。今回の分析では、テキストをサポートしないフォントアイコンを使用したボタンのみを対象としました。しかし、現在では多くのボタンがフォントアイコンの代わりにSVGを使用しているため、将来的にはそれらも含める予定です。</p>
+<aside class="note">注：上記の報告されている数字は下限値に過ぎません。今回の分析では、テキストをサポートしないフォントアイコンを使用したボタンのみを対象としました。しかし、現在では多くのボタンがフォントアイコンの代わりにSVGを使用しているため、将来的にはそれらも含める予定です。</aside>
 
 ## セマンティックフォームフィールド
 
@@ -278,7 +278,7 @@ JavaScriptの効果をもっと詳しく知りたい方は、Addy Osmaniの<a hr
 
 ユーザーがパスワードをコピーしてページに貼り付けることができるようにすることは、パスワードマネージャーを使用するための1つの方法です。パスワードマネージャーは、ユーザーが強力なパスワードを生成（記憶）し、ウェブページ上で自動的に記入するのに役立ちます。テストしたウェブページの0.02％だけがこの機能を無効にしています。
 
-<p class="note">注: これは非常に励みになりますが、<a href="./methodology">方法論</a>ではホームページのみをテストするという要件があるため、過小評価されている可能性があります。ログインページのような内部ページはテストされません。</p>
+<aside class="note">注: これは非常に励みになりますが、<a href="./methodology">方法論</a>ではホームページのみをテストするという要件があるため、過小評価されている可能性があります。ログインページのような内部ページはテストされません。</aside>
 
 ## 結論
 
@@ -297,7 +297,7 @@ JavaScriptの効果をもっと詳しく知りたい方は、Addy Osmaniの<a hr
   )
 }}
 
-<p class="note" data-markdown="1">注:
+<aside class="note" data-markdown="1">注:
 
 1. モバイルに力を入れているサイトを、より小さな画面に合わせてデザインを調整しているサイトと定義しました。というか、CSSのブレークポイントが600px以下に1つ以上あるサイトを指します。
 
@@ -308,4 +308,4 @@ JavaScriptの効果をもっと詳しく知りたい方は、Addy Osmaniの<a hr
 4. アクティブなスマートフォンの総数は、アクティブなAndroidsとiPhone（AppleとGoogleが公開している）の数を合計し、中国のネット接続された電話を考慮し少し計算して判明しました。<a hreflang="en" href="https://www.ben-evans.com/benedictevans/2019/5/28/the-end-of-mobile">詳細はこちら</a>。
 
 5. 16億台のデスクトップは、<a hreflang="en" href="https://web.archive.org/web/20181030132235/https://news.microsoft.com/bythenumbers/en/windowsdevices">Microsoft</a>と<a hreflang="en" href="https://web.archive.org/web/20190628161024/https://appleinsider.com/articles/18/10/30/apple-passes-100m-active-mac-milestone-thanks-to-high-numbers-of-new-users">Apple</a>が公開している数字で計算しています。リナックスPCユーザーは含まれていません。
-</p>
+</aside>
diff --git a/src/content/ja/2019/page-weight.md b/src/content/ja/2019/page-weight.md
index c4a3b44a11e..7f6f35689c0 100644
--- a/src/content/ja/2019/page-weight.md
+++ b/src/content/ja/2019/page-weight.md
@@ -35,7 +35,7 @@ featured_stat_label_3: ホームページあたりのリクエストの中央値
 
 はい。一部のユーザーにとっては、高速で堅牢なページを構築できます。ただし、すべてのユーザー、特に帯域幅の制約やデータ制限へ対処するモバイル専用ユーザーにどのように影響するかという観点からページの肥大化に注意する必要があります。
 
-<p class="note" data-markdown="1">Tim Kadlecの魅力的なオンライン計算機、[What Does My Site Cost?]（https://whatdoesmysitecost.com/）をチェックしてください。これは、世界中の国のページのコスト（1人あたりのドルと国民総所得）を計算します。それは目を見張るものです。たとえば、執筆時点で2.79MBのAmazonのホームページの費用は、モーリタニアの1人当たりGNIの1日あたり1.89％です。世界のいくつかの地域の人々が数十ページを訪問するだけで一日の賃金をあきらめなければならないとき、ワールドワイドウェブはどれほどグローバルなのでしょうか？</p>
+<aside class="note">Tim Kadlecの魅力的なオンライン計算機、[What Does My Site Cost?]（https://whatdoesmysitecost.com/）をチェックしてください。これは、世界中の国のページのコスト（1人あたりのドルと国民総所得）を計算します。それは目を見張るものです。たとえば、執筆時点で2.79MBのAmazonのホームページの費用は、モーリタニアの1人当たりGNIの1日あたり1.89％です。世界のいくつかの地域の人々が数十ページを訪問するだけで一日の賃金をあきらめなければならないとき、ワールドワイドウェブはどれほどグローバルなのでしょうか？</aside>
 
 ### 帯域幅を増やすことは、Webパフォーマンスの魔法の弾丸ではありません
 
diff --git a/src/content/ja/2019/performance.md b/src/content/ja/2019/performance.md
index d493e45e08e..6afa6145455 100644
--- a/src/content/ja/2019/performance.md
+++ b/src/content/ja/2019/performance.md
@@ -60,7 +60,7 @@ Web Almanacにある他のほとんどの章は、<a hreflang="en" href="https:/
 
 図7.1では、FCPの体験がWeb全体でどのように分散しているかを見ることができます。このチャートは、CrUXデータセット内にある数百万のWebサイト分布を1,000個のWebサイトに圧縮しており、図の縦線一つ一つはWebサイトを表しています。このグラフは、１秒未満の高速なFCP体験、３秒以上かかる遅い体験、その中間にある適度な体験（以前は平均と言われていた）の割合で並べられています。グラフには、ほぼ100%高速な体験を備えたWebサイトと、ほぼ100%低速な体験となっているWebサイトが存在しています。その中間にある、高速、適度、及び低速のパフォーマンスが混じり合ったWebサイトは、低速よりも適度か高速に傾いており、良い結果になっています。
 
-<p class="note">注意：ユーザー体験の低下があった場合、その理由が何であるか突き止めるのは難しいでしょう。Webサイト自体が不十分で非効率な構築がされている可能性があるかもしれませんが、ユーザーの通信速度が遅い可能性やキャッシュが空など、他の環境要因がある可能性があります。そのため、このフィールドデータを見てユーザー体験が悪いとわかっても、理由は必ずしもWebサイトにあるとは言えません。</p>
+<aside class="note">注意：ユーザー体験の低下があった場合、その理由が何であるか突き止めるのは難しいでしょう。Webサイト自体が不十分で非効率な構築がされている可能性があるかもしれませんが、ユーザーの通信速度が遅い可能性やキャッシュが空など、他の環境要因がある可能性があります。そのため、このフィールドデータを見てユーザー体験が悪いとわかっても、理由は必ずしもWebサイトにあるとは言えません。</aside>
 
 Webサイトが十分に**高速**かどうかを分類するために、新しい方法論である PageSpeed Insights (PSI)を使います。この方法はWebサイトのFCP体験の少なくとも75%が１秒未満でなければなりません。同様に、FCP体験がとても**低速**となる25%のWebサイトでは３秒以上かかっています。どちらの条件も満たさない場合、Webサイトのパフォーマンスは**適度**です。
 
diff --git a/src/content/ja/2019/resource-hints.md b/src/content/ja/2019/resource-hints.md
index 62f7be80a9f..cc9970391d9 100644
--- a/src/content/ja/2019/resource-hints.md
+++ b/src/content/ja/2019/resource-hints.md
@@ -66,7 +66,7 @@ HTTPヘッダー内のリソースヒントの使用量が非常に少ないた
 
 ## リソースヒント
 
-<p class="note">注: モバイルとデスクトップでは、リソースヒントの利用パターンに目立った違いはありませんでした。そのため、簡潔にするために、本章ではモバイルの統計のみを掲載しています。</p>
+<aside class="note">注: モバイルとデスクトップでは、リソースヒントの利用パターンに目立った違いはありませんでした。そのため、簡潔にするために、本章ではモバイルの統計のみを掲載しています。</aside>
 
 <figure>
   <table>
diff --git a/src/content/ja/2019/seo.md b/src/content/ja/2019/seo.md
index 89f3cf25278..200a0a98fa7 100644
--- a/src/content/ja/2019/seo.md
+++ b/src/content/ja/2019/seo.md
@@ -34,7 +34,7 @@ Web AlmanacのSEOの章の目的は、検索エンジンによるコンテンツ
 
 カスタムメトリクスはこれまで公開されていなかった洞察を提供します。`hreflang`タグ、リッチリザルトの適格性、見出しタグの使用、さらにシングルページアプリケーションのアンカーによるナビゲーション要素などの採用と実装について断言できるようになりました。
 
-<p class="note">注意：データはホームページの分析のみに限定されており、サイト全体のクロールから集計はされていません。そのようにした理由は、以降説明する多くの指標に影響を与えるため、特定の指標について言及する場合に関連する制限を追加しました。制限の詳しい内容は<a href="./methodology">Methodology</a>を御覧ください。</p>
+<aside class="note">注意：データはホームページの分析のみに限定されており、サイト全体のクロールから集計はされていません。そのようにした理由は、以降説明する多くの指標に影響を与えるため、特定の指標について言及する場合に関連する制限を追加しました。制限の詳しい内容は<a href="./methodology">Methodology</a>を御覧ください。</aside>
 
 では、Webの現状と検索エンジンの使いやすさについての詳細をお読みください。
 
@@ -146,7 +146,7 @@ SERPでユーザーにページのコンテンツを表示するためには検
 
 モバイルでは次によく見られるステータスコードは一時的なリダイレクトである`302`となっており、これはモバイルページの10.45%で見つけることができました。この結果はデスクトップよりも多く、デスクトップ用のホームページで`302`ステータスコードを返すのは6.71%しかありませんでした。これは、モバイル用のホームページがレスポンシヴでなく<a hreflang="en" href="https://developers.google.com/search/mobile-sites/mobile-seo/separate-urls">デバイスごとにWebサイトのバージョンが異なるような</a>、デスクトップページの代替が用意されていることに起因している可能性があります。
 
-<p class="note">注意：この結果にはステータスコード<code>4xx</code>と<code>5xx</code>は含んでいません。</p>
+<aside class="note">注意：この結果にはステータスコード<code>4xx</code>と<code>5xx</code>は含んでいません。</aside>
 
 #### `noindex`
 
@@ -154,7 +154,7 @@ SERPでユーザーにページのコンテンツを表示するためには検
 
 モバイル用ページの96.93%が<a hreflang="en" href="https://developers.google.com/web/tools/lighthouse/audits/indexing">Lighthouseのインデックス作成監査に合格しており</a>、これらのページには`noindex`指示が含まれていませんでした。ただし、これはモバイルホームページの3.07%に`noindex`指示が含まれていたことも意味しています。これは心配の種であり、Googleはこれらのページのインデックスを作成できないことを意味しています。
 
-<p class="note">私達の調査に含まれるWebサイトは<a href="./methodology#chrome-ux-report">Chrome UX Report</a>のデータセットから提供されていますが、公開されていないWebサイトは除外されています。これはChromeが非公開であると判断したサイトは分析できないので、バイアスの重要な源です。これについては<a href="./methodology#websites">方法論</a>の詳細を御覧ください。</p>
+<aside class="note">私達の調査に含まれるWebサイトは<a href="./methodology#chrome-ux-report">Chrome UX Report</a>のデータセットから提供されていますが、公開されていないWebサイトは除外されています。これはChromeが非公開であると判断したサイトは分析できないので、バイアスの重要な源です。これについては<a href="./methodology#websites">方法論</a>の詳細を御覧ください。</aside>
 
 #### canonicalによる最適化
 
diff --git a/src/content/ja/2019/third-parties.md b/src/content/ja/2019/third-parties.md
index 72afa1ca0ff..b219d3878b6 100644
--- a/src/content/ja/2019/third-parties.md
+++ b/src/content/ja/2019/third-parties.md
@@ -57,9 +57,9 @@ featured_stat_label_3: サードパーティのバイト数
 - **Video** - ユーザーの任意の動画コンテンツ
 - **Other** - 未分類、上記に分類されないカテゴリ
 
-<p class="note">
+<aside class="note">
   <strong>CDNについての注意事項</strong>: ここでのCDNカテゴリには、<strong>パブリック</strong>CDNドメイン（例：bootstrapcdn.com、cdnjs.cloudflare.comなど）上でリソースを提供するプロバイダが含まれており、単にCDN上で提供されるリソースは含まれて<strong>いません</strong>。
-</p>
+</aside>
 
 ### 警告事項
 
diff --git a/src/content/ja/2020/caching.md b/src/content/ja/2020/caching.md
index e5371e94a3c..68a5b9ca189 100644
--- a/src/content/ja/2020/caching.md
+++ b/src/content/ja/2020/caching.md
@@ -72,9 +72,9 @@ featured_stat_label_3: キャッシングの改善により、再訪問時に2MB
   )
 }}
 
-<p class="note">注：本章では、特に明記しない限り、デスクトップの統計も同様であると理解した上で、すべての統計をモバイル用にしています。モバイルとデスクトップの統計が大きく異なる場合は、その旨を明記しています。
+<aside class="note">注：本章では、特に明記しない限り、デスクトップの統計も同様であると理解した上で、すべての統計をモバイル用にしています。モバイルとデスクトップの統計が大きく異なる場合は、その旨を明記しています。
 
-本章で使用するレスポンスの多くは、一般的に入手可能なサーバーパッケージを使用するウェブサーバーからのものです。ベストプラクティスを示すことはできても、使用しているソフトウェアパッケージのキャッシュオプションの数が限られている場合には、ベストプラクティスを実現できない可能性があります。</p>
+本章で使用するレスポンスの多くは、一般的に入手可能なサーバーパッケージを使用するウェブサーバーからのものです。ベストプラクティスを示すことはできても、使用しているソフトウェアパッケージのキャッシュオプションの数が限られている場合には、ベストプラクティスを実現できない可能性があります。</aside>
 
 ## キャッシングの基本原則
 
diff --git a/src/content/ja/2020/css.md b/src/content/ja/2020/css.md
index c4fee792d1a..dd51c115152 100644
--- a/src/content/ja/2020/css.md
+++ b/src/content/ja/2020/css.md
@@ -48,7 +48,7 @@ CSS（Cascading Stylesheets）とは、ウェブページやその他のメデ
 
 カスタムメトリクスは[カスタムプロパティの分析](#カスタムプロパティ)の一部にも使われていました。スタイルシートだけでもカスタムプロパティの使用状況に関する多くの情報を得ることができますが、カスタムプロパティは継承されているため、DOMツリーを見てコンテキストを確認できなければ依存関係グラフを構築することはできません。またDOMノードの計算されたスタイルを見ることで、各プロパティがどのような種類の要素に適用されているのか、どの要素が[registered](https://developer.mozilla.org/docs/Web/API/CSS/RegisterProperty)であるのかといった情報を得ることができます。
 
-<p class="note">我々はデスクトップとモバイルの両方のモードでページをクロールしていますが、多くのデータでは同様の結果が得られるため、特に断りのない限り、この章で提示されている統計はモバイルページのセットを参照しています。</p>
+<aside class="note">我々はデスクトップとモバイルの両方のモードでページをクロールしていますが、多くのデータでは同様の結果が得られるため、特に断りのない限り、この章で提示されている統計はモバイルページのセットを参照しています。</aside>
 
 ## 使用方法
 
diff --git a/src/content/ja/2020/ecommerce.md b/src/content/ja/2020/ecommerce.md
index 338327f3a99..b249d591f26 100644
--- a/src/content/ja/2020/ecommerce.md
+++ b/src/content/ja/2020/ecommerce.md
@@ -64,7 +64,7 @@ featured_stat_label_3: Eコマースサイトが行うJavaScriptリクエスト
 
 合計では、モバイルウェブサイトの21.72％、デスクトップウェブサイトの21.27％がECプラットフォームを利用していました。2019年は、同数値がモバイルWebサイトで9.41％、デスクトップWebサイトで9.67％でした。
 
-<p class="note">注：この増加は、主にECサイトを検出するためにWappalyzerに施された改良によるもので、Covid-19による成長などの他の要因に起因するものではありません。また、2019年の統計には誤りを考慮して遡及的に軽微な修正が適用されたため、2019年のパーセンテージは<a href="../2019/ecommerce">2019 Eコマース</a>の章で示されたものとは若干異なります。</p>
+<aside class="note">注：この増加は、主にECサイトを検出するためにWappalyzerに施された改良によるもので、Covid-19による成長などの他の要因に起因するものではありません。また、2019年の統計には誤りを考慮して遡及的に軽微な修正が適用されたため、2019年のパーセンテージは<a href="../2019/ecommerce">2019 Eコマース</a>の章で示されたものとは若干異なります。</aside>
 
 ### 主要なEコマースプラットフォーム
 
@@ -135,7 +135,7 @@ COVID-19は世界に大きな影響を与えており、オンラインへの移
 
 COVIDが世界に大きな影響を与え始めた頃、WooCommerceやShopifyのサイトが明らかに増加しています。
 
-<p class="note">注：<a hreflang="en" href="https://github.com/AliasIO/wappalyzer/pull/2731/commits/f44f20f03618f6a5fd868dd38ce9db5e2e2f1407">Wappalyzer Detection for Wix</a>は、サイトがCMSとしてWixを使用しているか、EコマースプラットフォームとしてWixを使用しているかを区別しません。このため、EコマースプラットフォームとしてのWixの成長は、上記のグラフでは正しく表されていない可能性があります。</p>
+<aside class="note">注：<a hreflang="en" href="https://github.com/AliasIO/wappalyzer/pull/2731/commits/f44f20f03618f6a5fd868dd38ce9db5e2e2f1407">Wappalyzer Detection for Wix</a>は、サイトがCMSとしてWixを使用しているか、EコマースプラットフォームとしてWixを使用しているかを区別しません。このため、EコマースプラットフォームとしてのWixの成長は、上記のグラフでは正しく表されていない可能性があります。</aside>
 
 ## ページの重さとリクエスト
 
@@ -241,7 +241,7 @@ Eコマースサイトでは、リクエスト数が少ないにもかかわら
   sql_file="pagestats_image_bydevice_format.sql"
 ) }}
 
-<p class="note">なお、画像サービスやCDNの中には、<code>.jpg</code>や<code>.png</code>などの接尾辞を持つURLであっても、WebPをサポートするプラットフォームには、JPEGやPNGではなくWebPを自動的に配信するものがあります。たとえば、<code>IMG_20190113_113201.jpg</code>は、ChromeではWebP画像を返します。しかし、HTTP Archiveが画像フォーマットを検出する方法は、まずMIMEタイプのキーワードをチェックし、次にファイル拡張子にフォールバックするというものです。つまり、HTTP ArchiveがユーザーエージェントとしてサポートしているのはWebPなので、上記のようなURLを持つ画像のフォーマットはWebPとして与えられることになります。</p>
+<aside class="note">なお、画像サービスやCDNの中には、<code>.jpg</code>や<code>.png</code>などの接尾辞を持つURLであっても、WebPをサポートするプラットフォームには、JPEGやPNGではなくWebPを自動的に配信するものがあります。たとえば、<code>IMG_20190113_113201.jpg</code>は、ChromeではWebP画像を返します。しかし、HTTP Archiveが画像フォーマットを検出する方法は、まずMIMEタイプのキーワードをチェックし、次にファイル拡張子にフォールバックするというものです。つまり、HTTP ArchiveがユーザーエージェントとしてサポートしているのはWebPなので、上記のようなURLを持つ画像のフォーマットはWebPとして与えられることになります。</aside>
 
 PNGの使用率は、ほぼ[2019年と同水準](../2019/ecommerce#png)で推移しました（デスクトップ、モバイルともに27％）。JPEGの使用率は減少しました（デスクトップ4%、モバイル6%）。この減少分のうち、ほとんどがGIFの使用増加につながっています。GIFはEコマースのホームページではよく使われていますが、商品の詳細ページではあまり使われていないかもしれません。私たちの手法ではホームページのみを対象としているため、このことが、EコマースサイトでGIFの使用率が著しく高いことを説明しています。Lighthouseの監査では、「アニメーションコンテンツ用のビデオフォーマット」の使用を推奨しています。これは、GIFのアニメーション特性を維持しつつ、パフォーマンスを最適化するためにEコマースサイトが利用できる手法です。詳しくは<a hreflang="en" href="https://web.dev/replace-gifs-with-videos/">この記事</a>をご覧ください。
 
@@ -437,7 +437,7 @@ Eコマースサイトでもっとも使用されているタグマネージャ
   <figcaption>{{ figure_link(caption="Eコマースサイトでのタグマネージャーの利用", sheets_gid="2045910168", sql_file="percent_of_ecommsites_using_each_tag_managers.sql") }}</figcaption>
 </figure>
 
-<p class="note">注：上記の分析はWappalyzerによる検出に基づいており、<a href="./third-parties">サードパーティー</a>の章で使用されている<a href="./methodology#third-party-web">サードパーティーウェブ</a>データセットを用いた分析とは異なる可能性があります。</p>
+<aside class="note">注：上記の分析はWappalyzerによる検出に基づいており、<a href="./third-parties">サードパーティー</a>の章で使用されている<a href="./methodology#third-party-web">サードパーティーウェブ</a>データセットを用いた分析とは異なる可能性があります。</aside>
 
 ### コンセントマネジメント・プラットフォーム
 
diff --git a/src/content/ja/2020/http.md b/src/content/ja/2020/http.md
index 264ba4efdf3..08af5b6f974 100644
--- a/src/content/ja/2020/http.md
+++ b/src/content/ja/2020/http.md
@@ -98,9 +98,9 @@ HTTPプロトコルが進化しても、HTTPのセマンティクスは変わり
   <figcaption>{{ figure_link(caption="HTTP version usage by request.", sheets_gid="2122693316", sql_file="adoption_of_http_2_by_site_and_requests.sql") }}</figcaption>
 </figure>
 
-<p class="note">
+<aside class="note">
   ** 昨年のクロールと同様に、デスクトップリクエストの約4%はプロトコルバージョンを報告していませんでした。分析によると、これらはほとんどがHTTP/1.1であり、今後のクロールと分析のためにこのギャップを修正しました。データは2020年8月のクロールに基づいていますが、公開前の2020年10月のデータセットで修正を確認したところ、これらのリクエストは確かにHTTP/1.1であったことが判明したため、上記の表の統計に追加しました。
-</note>
+</aside>
 
 ウェブサイトのリクエストの総数を確認すると、一般的なサードパーティのドメインに偏りが出てきます。サーバーインストールによるHTTP/2の採用状況をよりよく理解するために、代わりにサイトのホームページからHTMLを提供するために使用されるプロトコルを見てみましょう。
 
diff --git a/src/content/ja/2020/jamstack.md b/src/content/ja/2020/jamstack.md
index c4ead3f3205..57fc9039ea5 100644
--- a/src/content/ja/2020/jamstack.md
+++ b/src/content/ja/2020/jamstack.md
@@ -30,7 +30,7 @@ Jamstackの中核となる原則は、サイトページのプリレンダリン
 
 この章の目的は、Jamstackサイトの成長の推定と分析、人気のあるJamstackフレームワークのパフォーマンス、そしてCore Web Vitalsのメトリクスを使った実際のユーザー体験の分析です。
 
-<p class="note">我々の分析は、<a href="./methodology#wappalyzer">Wappalyzer</a>で簡単に識別できるJamstackによって制限されていることに注意してください。これは、<a hreflang="en" href="https://github.com/11ty/eleventy/">Eleventy</a>のように、<a href="https://x.com/eleven_ty/status/1334225624110608387?s=20">意図的に識別できないようにしている人気のあるJamstack</a>はデータに含まれていないことを意味します。理想的にはすべてのJamstacksを含むことになりますが、我々が持っている重要なデータを分析することにはまだ多くの価値があると考えています。</p>
+<aside class="note">我々の分析は、<a href="./methodology#wappalyzer">Wappalyzer</a>で簡単に識別できるJamstackによって制限されていることに注意してください。これは、<a hreflang="en" href="https://github.com/11ty/eleventy/">Eleventy</a>のように、<a href="https://x.com/eleven_ty/status/1334225624110608387?s=20">意図的に識別できないようにしている人気のあるJamstack</a>はデータに含まれていないことを意味します。理想的にはすべてのJamstacksを含むことになりますが、我々が持っている重要なデータを分析することにはまだ多くの価値があると考えています。</aside>
 
 ## Jamstackの採用
 
diff --git a/src/content/ja/2020/javascript.md b/src/content/ja/2020/javascript.md
index ab286235b9c..f834b883cfb 100644
--- a/src/content/ja/2020/javascript.md
+++ b/src/content/ja/2020/javascript.md
@@ -200,9 +200,9 @@ JavaScriptの読み込み方法は、全体的な体験に大きな影響を与
 
 モバイルでは外部スクリプトが、検出されたスクリプト要素全体の59.0%を占めています。
 
-<p class="note">
+<aside class="note">
   余談ですが、先ほどページに読み込まれるJavaScriptの量について話したとき、その合計にはこれらのインラインスクリプトのサイズは含まれていませんでした。つまり、数字が示す以上に多くのスクリプトが読み込まれているということです。
-</p>
+</aside>
 
 {{ figure_markup(
   image="external-inline-mobile.png",
diff --git a/src/content/ja/2020/markup.md b/src/content/ja/2020/markup.md
index 7e24541819e..1dcccb5b0db 100644
--- a/src/content/ja/2020/markup.md
+++ b/src/content/ja/2020/markup.md
@@ -30,9 +30,9 @@ HTMLをどのように使うのかでは、どれだけ素晴らしい基盤が
 
 昨年は580万ページを分析し、そのうち440万ページをデスクトップで、530万ページをモバイルでテストしました。今年は2020年にユーザーが訪れるWebサイトに関する[最新データ](./methodology#websites)を用いて750万ページを分析し、そのうち560万ページをデスクトップで、630万ページをモバイルでテストしました。昨年との比較も行っていますが、新たな洞察のために追加の指標を分析したのと同様に、私たち自身の個性や視点を章全体に付与しました。
 
-<p class="note">
+<aside class="note">
   このマークアップの章では、同じマークアップ言語であるSVGやMathMLではなく、ほぼHTMLのみを取り上げています。特に断りのない限り、この章で紹介する統計は、モバイルページのセットを指します。また、Web Almanacの全章のデータは公開されており、利用可能です。<a hreflang="en" href="https://docs.google.com/spreadsheets/d/1Ta7amoUeaL4pILhWzH-SCzMX9PsZeb1x_mwrX2C4eY8/">結果</a>を見て、<a hreflang="en" href="https://discuss.httparchive.org/t/2039">あなたの意見</a>をコミュニティに伝えてください！
-</p>
+</aside>
 
 ## 全般
 
@@ -1019,9 +1019,9 @@ HTML仕様によると、<a hreflang="en" href="https://html.spec.whatwg.org/mul
 
 その結果、分析したページのほぼ半分が、典型的なviewport `content` 値を使用していることがわかりました。しかし約10％のモバイルページでは、viewport meta要素の適切な`content`値が完全に欠落しており、残りのページでは、`maximum-scale`、`minimum-scale`、`user-scalable=no`、または`user-scalable=0`の不適切な組み合わせが使用されています。
 
-<p class="note">
+<aside class="note">
   しばらく前から、モバイルブラウザEdgeでは、viewport meta要素を採用しているWebページで定義されているズーム設定に関わらず、<a hreflang="en" href="https://blogs.windows.com/windows-insider/2017/01/12/announcing-windows-10-insider-preview-build-15007-pc-mobile/">最低でも500%</a>までWebページを拡大することができるようになりました。
-</p>
+</aside>
 
 ### ファビコン
 
@@ -1306,7 +1306,7 @@ HTML仕様によると、<a hreflang="en" href="https://html.spec.whatwg.org/mul
 
 経験則として、また、<a hreflang="en" href="https://www.nngroup.com/articles/new-browser-windows-and-tabs/">使いやすさの観点から</a>、そもそも`target="_blank"`を使用しないことをオススメします。
 
-<p class="note">最新のSafariとFirefoxでは、<code>a</code>要素に<code>target="_blank"</code>を設定すると、<code>rel="noopener"</code>を設定するのと同じ<code>rel</code>の動作が暗黙的に提供されます。これはすでに<a hreflang="en" href="https://chromium-review.googlesource.com/c/chromium/src/+/1630010">Chromium</a>でも実装されており、Chrome 88にも搭載される予定です</p>。
+<aside class="note">最新のSafariとFirefoxでは、<code>a</code>要素に<code>target="_blank"</code>を設定すると、<code>rel="noopener"</code>を設定するのと同じ<code>rel</code>の動作が暗黙的に提供されます。これはすでに<a hreflang="en" href="https://chromium-review.googlesource.com/c/chromium/src/+/1630010">Chromium</a>でも実装されており、Chrome 88にも搭載される予定です。</aside>
 
 ## 結論
 
@@ -1336,6 +1336,6 @@ HTML仕様によると、<a hreflang="en" href="https://html.spec.whatwg.org/mul
 
 次回のWeb Almanacの章では、HTMLを書く技術を詳しく見て、できれば私たちがどのように改善してきたかを見ていく準備をしましょう。
 
-<p class="note">
+<aside class="note">
   あとは、あなたにお任せします。あなたの観察力はどうですか？何があなたの目に留まりましたか？何が悪くなって、何が良くなったと思いますか？<a hreflang="en" href="https://discuss.httparchive.org/t/2039">Leave a comment</a>であなたの意見を聞かせてください。
-</p>
+</aside>
diff --git a/src/content/ja/2020/media.md b/src/content/ja/2020/media.md
index 7d950a620a5..ca6eb423800 100644
--- a/src/content/ja/2020/media.md
+++ b/src/content/ja/2020/media.md
@@ -186,7 +186,7 @@ JavaScriptを使ってメディアを埋め込むアプローチは無数にあ
 
 `<source>`の要素では、WebPが圧倒的に多く、次いでPNG、JPGは`<picture>`の4.83%に過ぎないことがわかります。
 
-<p class="note">なお、当社のクローラーはWebPをサポートしているChromeでクロールしていますが、サポートしていない他のブラウザを使用している場合には、異なる結果が表示されます。</p>
+<aside class="note">なお、当社のクローラーはWebPをサポートしているChromeでクロールしていますが、サポートしていない他のブラウザを使用している場合には、異なる結果が表示されます。</aside>
 
 以下は、複数のフォーマットバリエーションを提供するために使用できるマークアップ構文の例です。
 
@@ -223,7 +223,7 @@ JavaScriptを使ってメディアを埋め込むアプローチは無数にあ
 
 いくつかのダイナミックメディアサービスや画像CDNは、この作業を自動化し刻々と変化するブラウザフォーマットのサポート状況を追跡し、同期させるよう努力することで、この作業を大幅に簡素化できます。
 
-<p class="note">注：ChromeでAVIFがサポートされたのはバージョン85（2020年8月下旬リリース）からですが、このアルマナックのデータは主にそれ以前のものです。しかし、2020年11月初旬のより最近のデータにアドホッククエリを実行すると、数万件のAVIFリクエストが表示されます。</p>
+<aside class="note">注：ChromeでAVIFがサポートされたのはバージョン85（2020年8月下旬リリース）からですが、このアルマナックのデータは主にそれ以前のものです。しかし、2020年11月初旬のより最近のデータにアドホッククエリを実行すると、数万件のAVIFリクエストが表示されます。</aside>
 
 ##### 写真：メディアアートディレクション
 
diff --git a/src/content/ja/2020/mobile-web.md b/src/content/ja/2020/mobile-web.md
index 0e5e0c4efc5..7e86b41f360 100644
--- a/src/content/ja/2020/mobile-web.md
+++ b/src/content/ja/2020/mobile-web.md
@@ -39,7 +39,7 @@ featured_stat_label_3: 75パーセンタイルのモバイル用LCP
 
 このデータは、（オプトインした）Chromeユーザーのサブセットからのみ収集されていますが、ホームページに限定されているという問題はありません。このデータは仮名で、ヒストグラムとイベントで構成されています。
 
-<p class="note">注：レポートは、ユーザーがブラウザのウィンドウを同期する機能を有効にしている場合、「検索と閲覧をより快適にする/訪問したページのURLをGoogleに送信する」の設定を無効にしていない限り、有効になります。</p>
+<aside class="note">注：レポートは、ユーザーがブラウザのウィンドウを同期する機能を有効にしている場合、「検索と閲覧をより快適にする/訪問したページのURLをGoogleに送信する」の設定を無効にしていない限り、有効になります。</aside>
 
 ## モバイルウェブとデスクトップのトラフィック傾向
 
@@ -51,7 +51,7 @@ perficient.comで公開されている<a hreflang="en" href="https://www.perfici
 
 このセクションでは、本章のために特別に公開されたChromeの非公開データソース[詳細はこちら](#データソース)の統計データを参照しています。このデータを使って、AndroidとWindowsでのページロードを評価しています（それぞれモバイルとデスクトップの代理としています）。
 
-<p class="note">注：この項では、Androidの場合はモバイル、Windowsの場合はデスクトップと表記することがあります。</p>
+<aside class="note">注：この項では、Androidの場合はモバイル、Windowsの場合はデスクトップと表記することがあります。</aside>
 
 #### オリジン間のページロードを人気順に表示
 
diff --git a/src/content/ja/2020/pwa.md b/src/content/ja/2020/pwa.md
index f19f37c3709..e808fddcf6e 100644
--- a/src/content/ja/2020/pwa.md
+++ b/src/content/ja/2020/pwa.md
@@ -141,7 +141,7 @@ Web Almanacのこの章では、データ駆動の観点から、PWAを現在の
   <figcaption>{{ figure_link(caption="Lighthouse PWAの監査。", sheets_gid="814184412", sql_file="lighthouse_pwa_audits.sql") }}</figcaption>
 </figure>
 
-<p class="note">Lighthouseテストのパフォーマンス統計が8月のクロールでは正しくなかったので、<code>load-fast-enough-for-pwa</code>の結果は9月の結果に置き換えられています。</p>
+<aside class="note">Lighthouseテストのパフォーマンス統計が8月のクロールでは正しくなかったので、<code>load-fast-enough-for-pwa</code>の結果は9月の結果に置き換えられています。</aside>
 
 <a hreflang="ja" href="https://web.dev/i18n/ja/load-fast-enough-for-pwa/">高速なページロード</a>は、とくに遅い携帯電話ネットワークを考慮に入れた場合、良好なモバイルユーザー体験を保証します。27.56%のページがPWAで十分に高速に読み込まれました。ウェブがどのように地理的に分散しているかを考えると、次の10億人のウェブユーザー、そのほとんどがモバイルデバイスを介してインターネットを利用することになるであろう人々にとって、より軽量なページで高速なロードタイムを持つことはもっとも重要なことです。
 
diff --git a/src/content/ja/2020/security.md b/src/content/ja/2020/security.md
index 2f2358659a0..6da95519dcc 100644
--- a/src/content/ja/2020/security.md
+++ b/src/content/ja/2020/security.md
@@ -623,7 +623,7 @@ SRIで保護されたスクリプトが含まれている上位5ホストの残
 
 レスポンスヘッダー`Feature-Policy`の採用率は、デスクトップページでは0.60%、モバイルページでは0.51%とかなり低い。一方、デスクトップページでは、1320万フレームのうち11.8%でFeature Policyが有効になっていました。モバイルページでは、1390万フレームのうち10.8%が`allow`属性を含んでいました。
 
-<p class="note">この章の以前のバージョンでは、フレームの合計数と `allow` 属性を持つフレームの割合の値が間違っていました。詳細については、この <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> を参照してください。</p>
+<aside class="note">この章の以前のバージョンでは、フレームの合計数と `allow` 属性を持つフレームの割合の値が間違っていました。詳細については、この <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> を参照してください。</aside>
 
 iframeの機能ポリシーで最もよく使われているディレクティブを見ると、これらは主にフレームが動画を再生する方法を制御するために使われていることがわかります。例えば、最も一般的なディレクティブである`encrypted-media`は、DRMで保護された動画を再生するために必要なEncrypted Media Extensions APIへのアクセスを制御するために使用されます。フィーチャーポリシーを持つフレームの起源として最も多いのは `https://www.facebook.com`と`https://www.youtube.com`でした (デスクトップページのフィーチャーポリシーを持つフレームの49.87%と26.18%でした)。
 
@@ -633,7 +633,7 @@ iframeの機能ポリシーで最もよく使われているディレクティ
 
 iframeの`sandbox`属性は、埋め込まれたウェブページの機能を制限し、その結果、攻撃を開始する機会を制限するために使用することができます。広告や動画などのサードパーティコンテンツを埋め込むことはウェブ上では一般的なことなので、これらの多くが`sandbox`属性によって制限されていることは驚くべきことではありません。デスクトップページのiframeの18.3%が`sandbox`属性を持っているのに対し、モバイルページでは21.9%となっています。
 
-<p class="note">この章の以前のバージョンでは、`sandbox` 属性を持つフレームの割合の値が間違っていました。詳細については、この <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> を参照してください。</p>
+<aside class="note">この章の以前のバージョンでは、`sandbox` 属性を持つフレームの割合の値が間違っていました。詳細については、この <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> を参照してください。</aside>
 
 <figure>
   <table>
@@ -838,7 +838,7 @@ CORPに関連しているのは [`Cross-Origin-Embedder-Policy`](https://develop
 
 我々の結果によると、（安全で暗号化された方法で）乱数を生成できる`Cypto.getRandomValues`関数が最も広く利用されていることがわかりました(デスクトップ: 70%、モバイル: 68%)。Google Analyticでは、この機能を利用していることが利用状況の測定に大きく影響していると考えています。一般的に、モバイルブラウザはこのAPIを[完全にサポート](https://developer.mozilla.org/docs/Web/API/Web_Crypto_API#Browser_compatibility)していますが、モバイルサイトでは暗号化処理の実行数がわずかに少なくなっていることがわかります。
 
-<p class="note">注意すべき点は、受動的なクロールを行っているため、このセクションでの結果はこれによって制限されることです。関数が実行される前に何らかのインタラクションが必要なケースを特定することはできません。</p>
+<aside class="note">注意すべき点は、受動的なクロールを行っているため、このセクションでの結果はこれによって制限されることです。関数が実行される前に何らかのインタラクションが必要なケースを特定することはできません。</aside>
 
 ### ボット保護サービスの活用
 
diff --git a/src/content/ja/2020/seo.md b/src/content/ja/2020/seo.md
index 059637dbe91..20a61ac326f 100644
--- a/src/content/ja/2020/seo.md
+++ b/src/content/ja/2020/seo.md
@@ -425,9 +425,9 @@ Lighthouseのテストでmeta robotsタグの使用状況を分析したとこ
 * `HowTo`マークアップは、デスクトップでは605％、モバイルでは623％増加しました。
 * `QAPage`のマークアップは、デスクトップで166.7%、モバイルで192.1%増加しました。
 
-<p class="note">
+<aside class="note">
   繰り返しになりますが、これらのオブジェクトは通常、内部ページに配置されているため、このデータは彼らの実際の成長レベルを代表していない可能性があることに注意する必要があります。
-</p>
+</aside>
 
 構造化データの採用は、データを抽出することが豊富なユースケースにとって価値があるため、ウェブに恩恵をもたらします。検索エンジンの利用が拡大し、ウェブ検索以外のアプリケーションにも利用されるようになると、構造化データは今後も増加すると予想されます。
 
diff --git a/src/content/ja/2021/accessibility.md b/src/content/ja/2021/accessibility.md
index 8d85562a7e1..e52beaa1975 100644
--- a/src/content/ja/2021/accessibility.md
+++ b/src/content/ja/2021/accessibility.md
@@ -49,7 +49,7 @@ featured_stat_label_3: コンテンツからアクセス可能な名称を取得
 
 この章ではウェブにおける深刻な測定基準と実証されたアクセシビリティの過失を満載し、読者がこの作業を優先し、より包括的なインターネットへとシフトしていくよう、その実践を変えるきっかけになることを願っています。
 
-<p class="note">本章では、人物優先の用語として「障害者」を使用することにしました。私たちは、多くの人がアイデンティティを優先する「障害者」という用語を好むことを認めます。私たちが選んだ用語は、どの用語が適切かを規定するものでは決してありません。</p>
+<aside class="note">本章では、人物優先の用語として「障害者」を使用することにしました。私たちは、多くの人がアイデンティティを優先する「障害者」という用語を好むことを認めます。私たちが選んだ用語は、どの用語が適切かを規定するものでは決してありません。</aside>
 
 ## 読みやすさ
 
@@ -673,7 +673,7 @@ DOMと平行して、[アクセシビリティツリー](https://developer.mozil
 
 `aria-describedby` 属性は、要素に対してより堅牢な記述が必要な場合に使用できます。また、インターフェイスの他の場所に存在する記述的なテキストと接続するために、その値としてid参照を受け入れることができます。アクセシブルネームは提供されません。アクセシブルネームは、代替ではなく、補足として併用されるべきです。デスクトップページの13%、モバイルページの12%に `aria-describedby` 属性の要素を1つ以上持つことがわかりました。
 
-<p class="note">楽しい事実！1,886のウェブサイトに`aria-lavel`という属性があることがわかりました！これは`aria-label`属性のスペルミスです。このような簡単に回避できるエラーは、必ず自動チェックで拾ってください。</p>
+<aside class="note">楽しい事実！1,886のウェブサイトに`aria-lavel`という属性があることがわかりました！これは`aria-label`属性のスペルミスです。このような簡単に回避できるエラーは、必ず自動チェックで拾ってください。</aside>
 
 #### ボタンのアクセス可能な名称はどこから来ているのでしょうか？
 
diff --git a/src/content/ja/2021/cdn.md b/src/content/ja/2021/cdn.md
index ab4bdd600b2..e9c48c82a45 100644
--- a/src/content/ja/2021/cdn.md
+++ b/src/content/ja/2021/cdn.md
@@ -288,7 +288,7 @@ CDNはホスト名を統合するレイヤーを提供し、ホスティング
 
 この傾向は、以下のグラフが示すもの以上に明確なものではありません。CDNを利用しているドメインでは、利用していないドメインと比較して、高いHTTP/2+の採用率が見られます。
 
-<p class="note">HTTP/3の動作方法(より多くの情報のための[HTTP](./http)の章を参照)のために、HTTP/3はしばしば最初の接続に使われないので、それらのHTTP/2接続の多くが実際にリピート訪問者のためのHTTP/3であるかもしれないので、我々は代わりに「HTTP/2＋」を測定していることに注意します(我々は、HTTP/3を実装しないサーバーがないと仮定しました。).</p>
+<aside class="note">HTTP/3の動作方法(より多くの情報のための[HTTP](./http)の章を参照)のために、HTTP/3はしばしば最初の接続に使われないので、それらのHTTP/2接続の多くが実際にリピート訪問者のためのHTTP/3であるかもしれないので、我々は代わりに「HTTP/2＋」を測定していることに注意します(我々は、HTTP/3を実装しないサーバーがないと仮定しました。).</aside>
 
 {{ figure_markup(
   image="http-versions-desktop.png",
diff --git a/src/content/ja/2021/cms.md b/src/content/ja/2021/cms.md
index da58eaee68e..10cbb9f07c6 100644
--- a/src/content/ja/2021/cms.md
+++ b/src/content/ja/2021/cms.md
@@ -35,7 +35,7 @@ CMSのプラットフォームが多数あるため、採用実績の上位のCM
 
 それでは、分析に入りましょう。
 
-<p class="note">**免責事項:** AlonはWixに勤務し、ウェブパフォーマンスの取り組みを率いていますが、意見は彼個人のものです。</a>
+<aside class="note">**免責事項:** AlonはWixに勤務し、ウェブパフォーマンスの取り組みを率いていますが、意見は彼個人のものです。</aside>
 
 ## CMSとは？
 
@@ -215,7 +215,7 @@ CMSの重要な点は、そのプラットフォーム上に構築されたサ
 
 デスクトップ端末の体験はやや良好で、1C-Bitrix（主にロシアで使用）は、CWVを通過したサイトの割合が56%ともっとも高かった。WordPressは合格率がもっとも低く、26%にとどまりました。
 
-<p class="note">Dudaは、8月に47%のサイトが通過し、昨年から全体的に大きく進歩した点で、栄誉ある賞に値すると思います。彼らは、<a hreflang="en" href="https://github.com/AliasIO/wappalyzer/pull/4189">Wappalyzer</a>の誤った検出に関連して、7月に壊れたデータ収集のためにこのレポートに含まれておらず、彼らの起源を誤って膨らませ、彼らのCWV割合を減少させたのである。</p>
+<aside class="note">Dudaは、8月に47%のサイトが通過し、昨年から全体的に大きく進歩した点で、栄誉ある賞に値すると思います。彼らは、<a hreflang="en" href="https://github.com/AliasIO/wappalyzer/pull/4189">Wappalyzer</a>の誤った検出に関連して、7月に壊れたデータ収集のためにこのレポートに含まれておらず、彼らの起源を誤って膨らませ、彼らのCWV割合を減少させたのである。</aside>
 
 また、これらのCMSプラットフォームの進捗を、モバイルビューに着目して昨年のデータと比較して評価することもできます。
 
diff --git a/src/content/ja/2021/ecommerce.md b/src/content/ja/2021/ecommerce.md
index bde1b7458d7..7a517d803b0 100644
--- a/src/content/ja/2021/ecommerce.md
+++ b/src/content/ja/2021/ecommerce.md
@@ -102,7 +102,7 @@ eコマースサイトの全体のシェアは、21.3％（デスクトップは
 
 10のプラットフォームのうち6つがSaaSである（またはSaaS版がある）。Shopify、<a hreflang="en" href="https://www.wix.com/ecommerce/website">Wix eCommerce</a>、<a hreflang="en" href="https://www.squarespace.com/ecommerce-website">Squarespace Commerce</a>、<a hreflang="en" href="https://www.bigcommerce.com/">BigCommerce</a>、Shopwareと<a hreflang="pt" href="https://lojaintegrada.com.br/">Loja Integrada</a>。
 
-<p class="note">注：2021年7月のHTTP Archiveデータに、<a hreflang="en" href="https://www.opencart.com/">OpenCart</a>のサイト数が過小に報告される<a hreflang="en" href="https://github.com/HTTPArchive/httparchive.org/issues/414">問題</a>が発生しました。9月の結果では、10,801のOpenCartサイトが検出されたことは認めるに値します。もし7月に同数のOpenCartサイトが検出されていたとしたら、人気の点ではBigCommerceとShopwareの間に位置することになります。</p>
+<aside class="note">注：2021年7月のHTTP Archiveデータに、<a hreflang="en" href="https://www.opencart.com/">OpenCart</a>のサイト数が過小に報告される<a hreflang="en" href="https://github.com/HTTPArchive/httparchive.org/issues/414">問題</a>が発生しました。9月の結果では、10,801のOpenCartサイトが検出されたことは認めるに値します。もし7月に同数のOpenCartサイトが検出されていたとしたら、人気の点ではBigCommerceとShopwareの間に位置することになります。</aside>
 
 ### ウェブサイトの人気順で上位のeコマース・プラットフォーム
 
@@ -531,7 +531,7 @@ HTMLのペイロードの中央値は、モバイルで38KB、デスクトップ
   sql_file="pagestats_image_bydevice_format.sql"
 ) }}
 
-<p class="note">画像サービスや CDN の中には、WebP をサポートするプラットフォームには、接尾辞が <code>.jpg</code>や<code>.png</code> の URL でも (JPEG や PNG ではなく) WebP を自動的に配信するものがあることに注意してください。たとえば、<code>IMG_20190113_113201.jpg</code>は、ChromeではWebPの画像を返します。しかし、HTTP Archive が画像フォーマットを検出する方法は、まず MIME タイプのキーワードを確認し、次にファイル拡張子にフォールバックします。つまり、上記のような URL を持つ画像のフォーマットは、HTTP Archive がユーザーエージェントとしてサポートしている WebP が与えられることになります。</p>
+<aside class="note">画像サービスや CDN の中には、WebP をサポートするプラットフォームには、接尾辞が <code>.jpg</code>や<code>.png</code> の URL でも (JPEG や PNG ではなく) WebP を自動的に配信するものがあることに注意してください。たとえば、<code>IMG_20190113_113201.jpg</code>は、ChromeではWebPの画像を返します。しかし、HTTP Archive が画像フォーマットを検出する方法は、まず MIME タイプのキーワードを確認し、次にファイル拡張子にフォールバックします。つまり、上記のような URL を持つ画像のフォーマットは、HTTP Archive がユーザーエージェントとしてサポートしている WebP が与えられることになります。</aside>
 
 もっとも普及している画像形式はJPGで、モバイルでは54%がこの形式でした。これは、画像の50%がJPGであった昨年に比べ、8%増加しています。
 
diff --git a/src/content/ja/2021/http.md b/src/content/ja/2021/http.md
index ff8d2ef2414..17e26e0ca66 100644
--- a/src/content/ja/2021/http.md
+++ b/src/content/ja/2021/http.md
@@ -55,7 +55,7 @@ HTTP/2は、Web開発者がパフォーマンスの向上を図る際に直面
 
 HTTPバージョン0.9から30年の間に、プロトコルの採用状況に変化がありました。600万以上のウェブページを分析した結果、HTTP Archiveは最初のページリクエストにHTTP 0.9を使用した例は1つだけで、1.0を使用しているページはわずか数千件であることを発見しました。しかし、ほぼ40%のページがバージョン1.1を使用しており、残りの60%はHTTP/2以上を使用しています。このように、HTTP/2の採用率は、2020年に同じ分析を行ったときよりも10%増加しています。
 
-<p class="note">注: 後述するように、HTTP/3の動作方法と、毎回新鮮なインスタンスでクロールが動作する方法のため、HTTP/3は最初のページリクエスト、あるいはその後のリクエストに使用される可能性は低いです。そのため、本章ではいくつかの統計情報を「HTTP/2+」として報告し、現実世界でHTTP/2またはHTTP/3が使用される可能性があることを示す。私たちは、この章の後半で、（私たちのクロールで使用されていないとしても）実際にどの程度HTTP/3がサポートされているのかを調査します。</p>
+<aside class="note">注: 後述するように、HTTP/3の動作方法と、毎回新鮮なインスタンスでクロールが動作する方法のため、HTTP/3は最初のページリクエスト、あるいはその後のリクエストに使用される可能性は低いです。そのため、本章ではいくつかの統計情報を「HTTP/2+」として報告し、現実世界でHTTP/2またはHTTP/3が使用される可能性があることを示す。私たちは、この章の後半で、（私たちのクロールで使用されていないとしても）実際にどの程度HTTP/3がサポートされているのかを調査します。</aside>
 
 ### リクエストによる採用
 
diff --git a/src/content/ja/2021/jamstack.md b/src/content/ja/2021/jamstack.md
index 3bb4903dafa..4c937230bfb 100644
--- a/src/content/ja/2021/jamstack.md
+++ b/src/content/ja/2021/jamstack.md
@@ -84,7 +84,7 @@ SSGの採用は、一般的に前年比2倍で伸びています。2019年はモ
 
 まずは、もっとも普及しているSSGを把握することからはじめましょう。Next.jsはJamstackサイトの43.6%をカバーしています。2位はNuxt.jsで31.1％、3位はGatsbyで16.0％、4位はHugoで6.0％となっています。
 
-<p class="note">なお、本章の初出時においては、NuxtとNextのサイト数が誤って多く計上されていたため、数値が異なっています。本章の他の数値も含め、上記の数値は修正されています。</p>
+<aside class="note">なお、本章の初出時においては、NuxtとNextのサイト数が誤って多く計上されていたため、数値が異なっています。本章の他の数値も含め、上記の数値は修正されています。</aside>
 
 上位3つのSSGは、すべてJavaScriptベースです。Next.jsとGatsbyは、<a hreflang="en" href="https://reactjs.org/">React.js</a>をコアとして、その上に独自の機能を追加することで補完しています。Nuxt.jsは、<a hreflang="en" href="https://vuejs.org">Vue.js</a>をベースにしています。これらの人気のあるフロントエンドフレームワークは、巨大なエコシステムを備えているため、開発が非常に容易になります。<a hreflang="en" href="https://nodejs.org/en/">Node.js</a> は、従来使われているブラウザだけでなく、サーバ上でもJavaScriptを実行できるようにし、開発者が1つの言語に固執することを可能にしています。そのため、<a hreflang="en" href="https://go.dev/">プログラミング言語Go</a>をベースにしたHugoや、<a hreflang="en" href="https://go.dev/">Ruby</a>ベースのJekyllと比べて、サーバの観点からもこれらのSSGの採用が容易になるのだそうです。
 
diff --git a/src/content/ja/2021/markup.md b/src/content/ja/2021/markup.md
index ebafbdf22e3..29aff25dfb0 100644
--- a/src/content/ja/2021/markup.md
+++ b/src/content/ja/2021/markup.md
@@ -350,7 +350,7 @@ SVGはstyle要素と比較するとより多くのユースケースを持って
 
 `html`、`head`、`body`、`title`、`meta`要素はすべてオプションですが、今年もっともよく使われた要素で、いずれも99%以上のページに存在しています。
 
-<p class="note">ブラウザは自動的に `html` と `head` 要素を追加しますが、このグラフでは、クロール時にアクセスできなくなったサイトのために、クロールしたページの 0.2% がエラーになっていることに注意してください。</p>
+<aside class="note">ブラウザは自動的に `html` と `head` 要素を追加しますが、このグラフでは、クロール時にアクセスできなくなったサイトのために、クロールしたページの 0.2% がエラーになっていることに注意してください。</aside>
 
 {{ figure_markup(
   image="element-popularity.png",
diff --git a/src/content/ja/2021/page-weight.md b/src/content/ja/2021/page-weight.md
index fbaceeded5d..d349caa00cd 100644
--- a/src/content/ja/2021/page-weight.md
+++ b/src/content/ja/2021/page-weight.md
@@ -81,7 +81,7 @@ Googleは現在、コアウェブ・バイタルを良好に達成できてい
 
 PNGやJPEGなどの画像フォーマットは、すべてのブラウザーで広くサポートされています。最近の画像フォーマットでは、WebPやAVIFが、より小さなファイルサイズでより高い品質を提供し、人気を博しています。WebPはほとんどのブラウザでサポートされていますが、AVIFは新しく、あまりサポートされていません。`<picture>` タグを使えば、JPEGやPNGのフォールバックを提供しながら、最新の画像フォーマットを使用できます。[メディア](./media)の章では、この点についてより詳しく説明しています。画像のサイズや圧縮を適切に行わないと、パフォーマンスが低下します。
 
-<p class="note">**備考**: 最適化し、さまざまな画像サイズ形式を比較できるオンライン サービスが必要な場合、Google の <a hreflang="en" href="https://squoosh.app/">Squoosh</a> アプリケーションより優れたソースはないと私は考えています。同様に、[Jake Archibald](https://x.com/jaffathecake)'s <a hreflang="en" href="https://jakearchibald.github.io/svgomg/">SVGOMG</a> は SVG の最適化にはもってこいです。</p>
+<aside class="note">**備考**: 最適化し、さまざまな画像サイズ形式を比較できるオンライン サービスが必要な場合、Google の <a hreflang="en" href="https://squoosh.app/">Squoosh</a> アプリケーションより優れたソースはないと私は考えています。同様に、[Jake Archibald](https://x.com/jaffathecake)'s <a hreflang="en" href="https://jakearchibald.github.io/svgomg/">SVGOMG</a> は SVG の最適化にはもってこいです。</aside>
 
 #### JavaScriptの普及について一言
 
diff --git a/src/content/ja/2021/performance.md b/src/content/ja/2021/performance.md
index 483f55844c3..e1bdd742dbb 100644
--- a/src/content/ja/2021/performance.md
+++ b/src/content/ja/2021/performance.md
@@ -68,7 +68,7 @@ CrUX RUMのデータをHTTP ArchiveのWebPageTestのラボデータで補完し
   )
 }}
 
-<p class="note"><strong>備考:</strong>昨年からCLSの計算方法が変更になったため、この数値は単純比較ではありません。</p>
+<aside class="note"><strong>備考:</strong>昨年からCLSの計算方法が変更になったため、この数値は単純比較ではありません。</aside>
 
 Chromeユーザー体験レポートに掲載されたウェブサイトのコアウェブバイタルは、前年比で改善されました。しかし、この改善のかなりの部分は、必ずしもCLSの性能向上ではなく、CLSの計算方法の変更によるものです。その結果、CLSの「改善」はデスクトップで8ポイント（モバイルは2ポイント）となった。LCPはデスクトップで7ポイント改善（モバイルは2ポイント改善）。FIDは、デスクトップでは両年ともすでに100％で、モバイルでは10ポイント改善した。
 
@@ -242,7 +242,7 @@ TTFBはまだまだこれからです。当社のウェブサイトの75％は4G
 
 モバイルよりもデスクトップの方が、FCPが速いのは平均ネットワーク速度が速いことと、プロセッサが速いことの両方が原因だと思われます。モバイルでのFCPが良好だったのは、38%のオリジンだけでした。同期JavaScriptのようなレンダリングをブロックするリソースは、一般的な原因である可能性があります。TTFBはFCPの最初の部分なので、TTFBが悪いと、良好なFCPを達成するのが難しくなります。
 
-<p class="note"><strong>注：</strong>昨年からFCPの閾値が変更されています。今年のデータを昨年のデータと比較しようとする場合は、注意が必要です。</p>
+<aside class="note"><strong>注：</strong>昨年からFCPの閾値が変更されています。今年のデータを昨年のデータと比較しようとする場合は、注意が必要です。</aside>
 
 {{ figure_markup(
   image="performance-FCP-by-ect.png",
@@ -482,7 +482,7 @@ FIDのランク別実績は横ばい。
   )
 }}
 
-<p class="note"><strong>注：</strong>グラフのグループは、TBTのLighthouseスコアに基づいています（例：>= 0.9は「良い」結果）。スコアの四捨五入により、200msをわずかに超えるTBT値が「良好」に分類されています（600msの閾値でも同様です）。</p>
+<aside class="note"><strong>注：</strong>グラフのグループは、TBTのLighthouseスコアに基づいています（例：>= 0.9は「良い」結果）。スコアの四捨五入により、200msをわずかに超えるTBT値が「良好」に分類されています（600msの閾値でも同様です）。</aside>
 
 このデータは、WebPageTestでスロットルCPUのLighthouseを1回実行したものであり、実際のユーザー体験を反映したものではないことに留意してください。しかし、TBTとFIDを比較すると、潜在的なインタラクティビティははるかに悪く見えます。インタラクティブ性の「本当の」評価は、おそらくこの間のどこかにあるのでしょう。ですから、もしFIDが「良い」のであれば、FIDでは捉えられないような劣悪なユーザー体験を見逃しているかもしれないので、TBTを見てみてください。FIDが悪いのと同じ問題は、TBTも悪いのです。
 
diff --git a/src/content/ja/2021/privacy.md b/src/content/ja/2021/privacy.md
index bf731b1d491..c2b427df13e 100644
--- a/src/content/ja/2021/privacy.md
+++ b/src/content/ja/2021/privacy.md
@@ -272,7 +272,7 @@ Webサイトが機密性の高いリソースへのアクセスを要求する
 
 企業におけるセキュリティ管理の不備は、お客様の個人情報にも大きな影響を及ぼします。<a hreflang="en" href="https://haveibeenpwned.com/">Have I Been Pwned</a> は、ユーザーが自分のメールアドレスや電話番号がデータ漏洩で流出したかどうかを確認することができるサービスです。この記事を書いている時点で、Have I Been Pwnedは562件の情報漏えいを追跡し、6億4000万件の記録が漏れていることが判明しています。2020年だけでも40のサービスが侵入され、数百万人のユーザーの個人情報が流出した。このうち3件は_センシティブ_とされ、誰かがそのユーザーのデータを見つけた場合、ユーザーに悪影響が、及ぶ可能性があることを指しています。機密漏洩の一例として、盗まれたクレジットカードが、取引されるプラットフォーム「[Carding Mafia](https://www.vice.com/en/article/v7m9jx/credit-card-hacking-forum-gets-hacked-exposing-300000-hackers-accounts)」が挙げられます。
 
-<p class="note">なお、前年度の40件の違反は、多くの違反が発生してから数カ月後に発見、または公表されるため、下限値であることに注意してください。</p>
+<aside class="note">なお、前年度の40件の違反は、多くの違反が発生してから数カ月後に発見、または公表されるため、下限値であることに注意してください。</aside>
 
 {{ figure_markup(
   image="data_breaches_pwned_accounts_per_class.png",
@@ -361,7 +361,7 @@ HTTPリクエストはオプションで `Referer` ヘッダーを含むこと
 
 さらに、約0.5%のウェブサイトがリファラーポリシーの値を`unsafe-url`に設定しており、受信者のセキュリティレベルに関係なく、_あらゆる_リクエストでオリジン、ホスト、クエリー文字列が送信されるようになっています。この場合、リファラーが平文で送信され、個人情報を漏えいさせる可能性があります。心配なことに、この動作を可能にするようにサイトが積極的に設定されているのです。
 
-<p class="note">注：ウェブサイトは、リファラー情報をURLのパラメータとして送信先サイトに送ることもあります。このレポートでは、そのような仕組みの使用状況は測定していません。</p>
+<aside class="note">注：ウェブサイトは、リファラー情報をURLのパラメータとして送信先サイトに送ることもあります。このレポートでは、そのような仕組みの使用状況は測定していません。</aside>
 
 ### User-Agent クライアントヒント
 
@@ -509,7 +509,7 @@ DNTの後継となる<a hreflang="en" href="https://globalprivacycontrol.org/">
 
 エコシステムのフィードバックを求めるため、プライバシー サンドボックスAPIの初期および実験バージョンは、最初は個々の開発者によるテストのために <a hreflang="en" href="https://www.chromium.org/developers/how-tos/run-chromium-with-flags">機能フラグ</a> の背後に用意され、その後 <a hreflang="ja" href="https://developer.chrome.com/ja/blog/origin-trials/">_オリジントライアル_</a> を通じてChromeで使用されるようになります。このオリジントライアルに参加することで、Webプラットフォームの実験的な機能をテストし、その機能の使い勝手、実用性、有効性について、すべてのWebサイトにデフォルトで提供される前にWeb標準化コミュニティへフィードバックできます。
 
-<p class="note">**免責事項：** Originのトライアルは限られた時間のみ利用可能です。以下の数字は、この記事を書いている2021年10月時点のプライバシーサンドボックスのオリジントライアルの状態を表しています。</p>
+<aside class="note">**免責事項：** Originのトライアルは限られた時間のみ利用可能です。以下の数字は、この記事を書いている2021年10月時点のプライバシーサンドボックスのオリジントライアルの状態を表しています。</aside>
 
 ### FLoC
 
diff --git a/src/content/ja/2021/pwa.md b/src/content/ja/2021/pwa.md
index 552d4b39e46..132b95487de 100644
--- a/src/content/ja/2021/pwa.md
+++ b/src/content/ja/2021/pwa.md
@@ -40,7 +40,7 @@ featured_stat_label_3: サービスワーカーがいるモバイルサイトの
 今年のPWA編では、サービスワーカーとその関連APIの使用、Webアプリのマニフェスト、PWAを構築するためのもっとも人気のあるライブラリやツールなど、PWAの測定可能なすべての側面に焦点を当てます。PWAは、これらの機能のすべてまたは一部を使用できます。ここでは、ウェブエコシステムにおけるこれらの技術の浸透度合いを知るために、各コンポーネントとAPIの採用レベルについて見ていきます。
 
 
-<p class="note">**注:** この章では、一般的に使われているサービスワーカー関連のAPIに主に焦点を当てます。さらに最先端の API については、<a href="./capabilities">ケイパビリティ</a> の章を必ずご覧ください。</p>
+<aside class="note">**注:** この章では、一般的に使われているサービスワーカー関連のAPIに主に焦点を当てます。さらに最先端の API については、<a href="./capabilities">ケイパビリティ</a> の章を必ずご覧ください。</aside>
 
 ## サービスワーカー
 
@@ -153,7 +153,7 @@ this.oninstall = function(event) {
 
 その1つがオフライン分析（<a hreflang="en" href="https://developers.google.com/web/tools/workbox/modules/workbox-google-analytics">Workbox Analyticsはバックグラウンド同期を使用しています</a>）、または接続性の欠如による失敗したクエリの再試行（<a hreflang="en" href="https://web.dev/google-search-sw/">某検索エンジン</a>）などです。
 
-<p class="note">**備考:** 前回とは異なり、`fetch` と `message` イベントはサービスワーカーの外にも現れる可能性があり、誤検出が多くなる可能性があるため、この分析には含めないことにしました。つまり、上記の解析は、サービスワーカー固有のイベントに対するものです。<a hreflang="ja" href="../2020/pwa#サービスワーカーのイベント">2020年のデータでは、`fetch`は`install`とほぼ同じ頻度で使われています。</a></p>
+<aside class="note">**備考:** 前回とは異なり、`fetch` と `message` イベントはサービスワーカーの外にも現れる可能性があり、誤検出が多くなる可能性があるため、この分析には含めないことにしました。つまり、上記の解析は、サービスワーカー固有のイベントに対するものです。<a hreflang="ja" href="../2020/pwa#サービスワーカーのイベント">2020年のデータでは、`fetch`は`install`とほぼ同じ頻度で使われています。</a></aside>
 
 #### その他、人気のあるサービスワーカーの機能
 
@@ -313,7 +313,7 @@ displayプロパティは、開発者が好むウェブサイトのモードを
 
 PWA開発者の大多数がPWA体験をネイティブアプリケーションに推奨することを好むという事実にもかかわらず、一部の有名なPWA（Twitterなど）は依然としてPWA体験よりもネイティブアプリケーションを推奨することを好むようです。これは、これらの体験を構築するチームの好みによるものか、あるいは特定のビジネスニーズ（ウェブに何らかのAPIがない）によるものかもしれません。
 
-<p class="note">**備考:** 開発者は、設定時にこの決定を静的に行うのではなく、<a hreflang="en" href="https://web.dev/define-install-strategy/">より動的なヒューリスティック</a>を作成して、たとえば、ユーザーの行動やその他の特性 (デバイス、接続、場所など) に基づいて体験を促進することも可能です。</p>
+<aside class="note">**備考:** 開発者は、設定時にこの決定を静的に行うのではなく、<a hreflang="en" href="https://web.dev/define-install-strategy/">より動的なヒューリスティック</a>を作成して、たとえば、ユーザーの行動やその他の特性 (デバイス、接続、場所など) に基づいて体験を促進することも可能です。</aside>
 
 ### マニフェストのトップカテゴリー
 
@@ -398,8 +398,8 @@ Workboxは依然としてもっとも人気のあるライブラリで、サー
 
 また、Workboxの前身である`sw_toolbox`は、<a hreflang="ja" href="../2020/pwa#人気のインポートスクリプト"> 昨年の使用率がデスクトップで13.92％、モバイルで12.84％</a>でしたが、今年はそれぞれ0.51％と0.36％に低下しているのも重要な点です。これは、`sw_toolbox`が<a hreflang="en" href="https://github.com/GoogleChromeLabs/sw-toolbox/pull/288">2019年に非推奨</a>となったことが一因であると考えられます。人気のあるフレームワークやビルドツールの中には、このパッケージを削除するのに時間がかかったものもあるかもしれないので、今年はより明確に採用数の減少が見て取れます。また2020年と比較して、サイトを増やすなどして測定方法が変わったため、この指標はさらに減少し、直接の前年比は難しくなっています。
 
-<p class="note">**備考:** [`importScripts()`](https://developer.mozilla.org/docs/Web/API/WorkerGlobalScope/importScripts) は [`WorkerGlobalScope`](https://developer.mozilla.org/docs/Web/API/WorkerGlobalScope) の API で、[Web Workers](https://developer.mozilla.org/docs/Web/API/Web_Workers_API/Using_web_workers) など他のタイプの Worker コンテキストでも使用できることを考慮に入れておいてください。<a hreflang="en" href="https://www.google.com/recaptcha/about/">reCaptcha</a> は、例えば、reCaptcha JavaScript コードを取得する `importScripts()` コールを含むウェブワーカーを使用しているので、2番目に広く使われているライブラリとして表示されているようです。そのため、サービスワーカーのコンテキストで2番目に広く使われているライブラリとして、代わりに <a hreflang="en" href="https://firebase.google.com/docs/web/setup">Firebase</a> を考慮すべきです。
-</p>
+<aside class="note">**備考:** [`importScripts()`](https://developer.mozilla.org/docs/Web/API/WorkerGlobalScope/importScripts) は [`WorkerGlobalScope`](https://developer.mozilla.org/docs/Web/API/WorkerGlobalScope) の API で、[Web Workers](https://developer.mozilla.org/docs/Web/API/Web_Workers_API/Using_web_workers) など他のタイプの Worker コンテキストでも使用できることを考慮に入れておいてください。<a hreflang="en" href="https://www.google.com/recaptcha/about/">reCaptcha</a> は、例えば、reCaptcha JavaScript コードを取得する `importScripts()` コールを含むウェブワーカーを使用しているので、2番目に広く使われているライブラリとして表示されているようです。そのため、サービスワーカーのコンテキストで2番目に広く使われているライブラリとして、代わりに <a hreflang="en" href="https://firebase.google.com/docs/web/setup">Firebase</a> を考慮すべきです。
+</aside>
 
 ### Workboxの使用状況
 
@@ -501,7 +501,7 @@ Workboxライブラリは、特定の機能を含む <a hreflang="en" href="http
 <!-- markdownlint-disable-next-line MD051 -->
 サービスワーカーインターフェイスは、通知に関するユーザーインタラクションを処理するために、いくつかのイベントをリッスンすることもできます。[図16.4](#fig-4)は、`notificationclick`（通知へのクリックを捕捉）がデスクトップの45.64%、モバイルPWAの46.62%で使われていることを示しています。`notificationclose`は使用頻度が低く、デスクトップPWAの5.98%、モバイルPWAの6.34%です。これは、通知の「クリック」よりも、通知の「閉じる」イベントをリッスンすることが意味のあるユースケースが少ないと予想されます。
 
-<p class="note">**備考:** サービスワーカーの通知イベント（例： `push`、`notificationclick`）には、さらに `pushManager` プロパティが使われているのが興味深いです。このプロパティは、たとえば、Webプッシュ通知の許可を（ `pushManager.subscribe` を通じて）要求するために使用されます。この理由の1つは、いくつかのサイトがウェブプッシュを実装し、ある時点でロールバックすることを決定し、そのために許可を要求するコードを排除し、サービスワーカーのコードは変更しないままにしていることかもしれません。</p>
+<aside class="note">**備考:** サービスワーカーの通知イベント（例： `push`、`notificationclick`）には、さらに `pushManager` プロパティが使われているのが興味深いです。このプロパティは、たとえば、Webプッシュ通知の許可を（ `pushManager.subscribe` を通じて）要求するために使用されます。この理由の1つは、いくつかのサイトがウェブプッシュを実装し、ある時点でロールバックすることを決定し、そのために許可を要求するコードを排除し、サービスワーカーのコードは変更しないままにしていることかもしれません。</aside>
 
 ### Webプッシュ通知の受理率
 
diff --git a/src/content/ja/2021/resource-hints.md b/src/content/ja/2021/resource-hints.md
index 4acfc2f54ce..23568894738 100644
--- a/src/content/ja/2021/resource-hints.md
+++ b/src/content/ja/2021/resource-hints.md
@@ -262,7 +262,7 @@ CrUXデータセットにおけるページの <a hreflang="ja" href="https://we
 
 これは、プリロードヒントがあるとページが遅くなることを証明するものではありませんが、多くのヒントを持つことは、パフォーマンスが低下することと相関しています。しかし、多くの場合、プリロードされるリソースの数は少なくし、リソースの優先順位付けは可能な限りブラウザに委ねるべきです。
 
-<p class="note">注: ヒントの数だけでなく、プリロードされる各リソースのサイズもウェブサイトのパフォーマンスに影響を及ぼします。上図では、プリロードされた各リソースのサイズは考慮されていません。</p>
+<aside class="note">注: ヒントの数だけでなく、プリロードされる各リソースのサイズもウェブサイトのパフォーマンスに影響を及ぼします。上図では、プリロードされた各リソースのサイズは考慮されていません。</aside>
 
 ## `rel="preload"`
 
@@ -351,7 +351,7 @@ CSSの `background-image` のように、画像が最初のHTMLに含まれて
 
 `media` 属性に加えて、 `<link>` 要素は `imagesrcset` と `imagesizes` 属性をサポートしています。これは、 `<img>` 要素の `srcset` と `sizes` 属性に対応するものです。これらの属性を使用すると、画像に使用するのと同じリソースの選択基準を使用できます。残念ながら、その採用率は非常に低く（1％未満）、Safariの<a hreflang="en" href="https://caniuse.com/mdn-html_elements_link_imagesizes">サポート</a>がないためと思われます。
 
-<p class="note">注: `media` 属性は、仕様にあるようにすべての `<link>` 要素で利用できるわけではなく、 `rel="preload"` にのみ利用できます。</p>
+<aside class="note">注: `media` 属性は、仕様にあるようにすべての `<link>` 要素で利用できるわけではなく、 `rel="preload"` にのみ利用できます。</aside>
 
 ### 悪い習慣
 
@@ -411,7 +411,7 @@ Webサイトのパフォーマンスとプリロードヒントの数には、
 
 正しくない `as` 属性値（たとえば `script` の代わりに `style` を使用するような認識できない値）を使用すると、ブラウザはプリロードキャッシュに保存されているリソースと一致しないため、ファイルのダウンロードを重複して行うことになります。
 
-<p class="note">注: <code>video</code>は仕様に含まれていますが、どのブラウザでもサポートされていないため、無効な値として扱われ、無視されるでしょう。</p>
+<aside class="note">注: <code>video</code>は仕様に含まれていますが、どのブラウザでもサポートされていないため、無効な値として扱われ、無視されるでしょう。</aside>
 
 #### 未使用のフォントファイル
 
diff --git a/src/content/ja/2021/security.md b/src/content/ja/2021/security.md
index 2b172226e17..d0a941e6c89 100644
--- a/src/content/ja/2021/security.md
+++ b/src/content/ja/2021/security.md
@@ -643,7 +643,7 @@ SRIで保護されたスクリプトが含まれる一般的なホストのう
 
 また、`<iframe>` 要素の `allow` 属性を使用すると、埋め込みフレームで使用することを許可されている機能を有効または無効にできます。モバイルの1680万フレームの18.3%が、許可や機能のポリシーを有効にするため`allow`属性を含んでいます。
 
-<p class="note">この章の以前のバージョンでは、フレームの合計数と `allow` 属性を持つフレームの割合の値が間違っていました。これらのエラーは修正されました。詳細については、この <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> を参照してください。</p>
+<aside class="note">この章の以前のバージョンでは、フレームの合計数と `allow` 属性を持つフレームの割合の値が間違っていました。これらのエラーは修正されました。詳細については、この <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> を参照してください。</aside>
 
 例年通り、iframeの`allow` 属性でもっとも使用されているディレクティブは、埋め込みビデオやメディアのコントロールに関連するものです。もっともよく使われるディレクティブは、引き続き `encrypted-media` で、これは暗号化メディア拡張APIへのアクセスを制御するために使用されます。
 
@@ -653,7 +653,7 @@ iframe内に信頼できない第三者が存在すると、そのページに
 
 iframeの`sandbox`属性は、コンテンツに制限をかけるため、埋め込まれたWebページから攻撃を仕掛ける機会を減らすことができます。属性の値は、すべての制限を適用する場合は空、特定の制限を解除する場合はスペースで区切られたトークンのいずれかになります（いくつかの制限を挙げると埋め込みページはJavaScriptコードを実行できず、フォームは送信できず、ポップアップを作成できません）。広告やビデオなどのサードパーティーコンテンツをiframeで埋め込むことは、ウェブ上では一般的な行為であり、その多くが`sandbox`属性によって制限されていることは驚くことでありません。デスクトップ用ページのiframeの19.7%が `sandbox` 属性を持っており、モバイル用ページでは21.0%となっています。
 
-<p class="note">この章の以前のバージョンでは、`sandbox` 属性を持つフレームの割合の値が間違っていました。詳細については、この <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> を参照してください。</p>
+<aside class="note">この章の以前のバージョンでは、`sandbox` 属性を持つフレームの割合の値が間違っていました。詳細については、この <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> を参照してください。</aside>
 
 {{ figure_markup(
   image="security-prevalence-of-sandbox-directives-on-frames.png",
diff --git a/src/content/ja/2021/third-parties.md b/src/content/ja/2021/third-parties.md
index a5965437de1..0cbe9db8a7b 100644
--- a/src/content/ja/2021/third-parties.md
+++ b/src/content/ja/2021/third-parties.md
@@ -66,7 +66,7 @@ featured_stat_label_3: サードパーティのリクエスト
 - **Video** - ビデオプレーヤーやストリーミング機能を実現するスクリプトです。
 - **Other** - これらは共有のオリジンを介して配信される雑多なスクリプトで、正確なカテゴリや属性はありません。
 
-<p class="note">注：ここでいうCDNのカテゴリには、公開CDNドメイン（bootstrapcdn.com、cdnjs.cloudflare.comなど）でリソースを提供するプロバイダが含まれ、単にCDN経由で提供されるリソースは含まれません。たとえば、Cloudflareをページの前に置いても、私たちの基準によるファーストパーティの指定には影響しません。</p>
+<aside class="note">注：ここでいうCDNのカテゴリには、公開CDNドメイン（bootstrapcdn.com、cdnjs.cloudflare.comなど）でリソースを提供するプロバイダが含まれ、単にCDN経由で提供されるリソースは含まれません。たとえば、Cloudflareをページの前に置いても、私たちの基準によるファーストパーティの指定には影響しません。</aside>
 
 今年、私たちが行った方法の変更の1つは、ホスティングカテゴリを分析から除外することです。WordPress.comをブログに、Shopifyをeコマースプラットフォームに使用している場合、そのサイトによるこれらのドメインに対する他のリクエストは多くの点でこれらのプラットフォームのホスティングの一部であり、真の「サードパーティ」ではないとして無視することにしています。上記の注記と同様に、ページの前にあるCDNは「サードパーティ」とは見なしません。実際には、これは数字にほとんど影響を与えませんでしたが、上記の定義で「サードパーティ」と見なすべきものをより正確に反映し、また他の章がこの用語をどのように使用しているかにより近いと私たちは考えています。
 
diff --git a/src/content/ja/2022/cdn.md b/src/content/ja/2022/cdn.md
index 640d93b19c2..f8ddddda054 100644
--- a/src/content/ja/2022/cdn.md
+++ b/src/content/ja/2022/cdn.md
@@ -274,7 +274,7 @@ HTTP/2のハイプと遅延の削減などの機能の約束にもかかわら
 
 CDNは、ホスト名を一元化し、ホスティングインフラストラクチャに最小限の変更を加えてトラフィックを関連するエンドポイントにルーティングするための層を提供することで、このギャップを埋めるプロキシとして機能します。キュー内のコンテンツの優先順位付けやサーバープッシュなどの機能はCDN側で管理でき、いくつかのCDNはこれらの機能をウェブサイトオーナーからの入力なしに自動的に運用するソリューションを提供しており、HTTP/2の採用を促進しています。
 
-<p class="note">HTTP/3の動作方式により（詳細は[HTTP](./http)章を参照）、HTTP/3は初回接続にはほとんど使用されません。これは、多くのHTTP/2接続が実際にはリピート訪問者のためにHTTP/3である可能性があるため、"HTTP/2+"を測定しているからです（サーバーがHTTP/2なしでHTTP/3を実装することはないと仮定しています）。</p>
+<aside class="note">HTTP/3の動作方式により（詳細は[HTTP](./http)章を参照）、HTTP/3は初回接続にはほとんど使用されません。これは、多くのHTTP/2接続が実際にはリピート訪問者のためにHTTP/3である可能性があるため、"HTTP/2+"を測定しているからです（サーバーがHTTP/2なしでHTTP/3を実装することはないと仮定しています）。</aside>
 
 {{ figure_markup(
   image="cdn-http-versions-mobile.png",
diff --git a/src/content/ja/2022/jamstack.md b/src/content/ja/2022/jamstack.md
index 41ef1c5b284..4f91b54064b 100644
--- a/src/content/ja/2022/jamstack.md
+++ b/src/content/ja/2022/jamstack.md
@@ -34,7 +34,7 @@ Jamstackについて書く際の最大の問題の1つは、Jamstackが具体的
 
 しかし、強調された単語が示すように、明らかに一貫性があります。サイトは迅速であるべきで、事前にレンダリングされ、データを取得する場所とデータをレンダリングする方法を切り離すアーキテクチャアプローチを使用すべきです。正確な辞書の定義は得にくいですが、Jamstack開発者は「Jamstack」と言うと何を意味しているかを理解しています。それは、非常に迅速にロードされ、ビルド時に一度多くの有用なコンテンツをレンダリングし、必要に応じてJavaScriptを介して追加データを取得するサイトです。
 
-<p class="note">開示事項: このレポートの二人の著者はNetlifyの社員でした。NetlifyはJamstackという用語を発明し、Jamstack.orgを所有しています。このレポートとその基になる分析は、Netlifyと無関係の他者によってレビューおよび承認されました。</p>
+<aside class="note">開示事項: このレポートの二人の著者はNetlifyの社員でした。NetlifyはJamstackという用語を発明し、Jamstack.orgを所有しています。このレポートとその基になる分析は、Netlifyと無関係の他者によってレビューおよび承認されました。</aside>
 
 ## Jamstackを定量化する: 何をカウントすべきか？
 
@@ -80,7 +80,7 @@ __Largest Contentful Paint (LCP)__：すべてのページのすべてのLCP時
 
 __Cumulative Layout Shift (CLS)__：非常に迅速にスケルトンをロードするが、実際のコンテンツのロードに長い時間がかかるサイトを避けたいと思いました。それにもっとも近いものは<a hreflang="en" href="https://web.dev/cls/">Cumulative Layout Shift</a>で、ページのレイアウトがロード中にどれだけ跳ねるかを測定します。CLSを「操作」する方法がありますが、私たちはそれが測定しようとしているものの合理的な代理であるとまだ信じています。私たちはこの測定が好きでした、なぜなら「跳ねる」サイトもまた「Jamstack的」ではないと感じられるからです。「Jamstack的」という言葉を多く使うことになるでしょう。再び、Chrome UX Reportのデータの中央値を選びました。
 
-<p class="note">Chrome UX ReportのデータはCLSデータをもっとも近い0.05に丸めますが、それは残念なことです。なぜなら「実際の」中央値は約0.02-0.03のようで、モバイルではゼロに丸められ、デスクトップでは0.05に丸められるからです。0は膨大な数のページを除外するため、私たちはモバイルとデスクトップの両方に最適な閾値として0.05を使用することにしました。</p>
+<aside class="note">Chrome UX ReportのデータはCLSデータをもっとも近い0.05に丸めますが、それは残念なことです。なぜなら「実際の」中央値は約0.02-0.03のようで、モバイルではゼロに丸められ、デスクトップでは0.05に丸められるからです。0は膨大な数のページを除外するため、私たちはモバイルとデスクトップの両方に最適な閾値として0.05を使用することにしました。</aside>
 
 __キャッシュ__：これはとくに定量化が難しいものでした。なぜなら、Jamstackサイトであっても、ほとんどのホームページが実際には長時間キャッシュされているにもかかわらず、再検証を要求するからです。私たちは`Age`、`Cache-Control`、`Expires`を含むHTTPヘッダーの組み合わせを使用しました。これらは長時間キャッシュされる可能性のあるページで一般的に見られました。
 
diff --git a/src/content/ja/2022/markup.md b/src/content/ja/2022/markup.md
index 3c14c27dbe2..2384dfe7c4b 100644
--- a/src/content/ja/2022/markup.md
+++ b/src/content/ja/2022/markup.md
@@ -155,7 +155,7 @@ HTMLペイロードとドキュメントサイズは、この連載の定番で
 
 `svg` と `math` 要素を含めない場合（これらはHTMLの外部で指定されているから）、現在のHTML仕様は111個の要素で構成されています。
 
-<p class="note">タグではなく要素です。なぜなら、`<li>` や `</ins>` のような単なる開始タグや終了タグを指しているのではないからです。また、HTML 要素の数え方を変える人もいますが、もっとも重要なのは、<a hreflang="en" href="https://meiert.com/en/blog/the-number-of-html-elements/">どのように数えているかをはっきりさせることです。</a></p>
+<aside class="note">タグではなく要素です。なぜなら、`<li>` や `</ins>` のような単なる開始タグや終了タグを指しているのではないからです。また、HTML 要素の数え方を変える人もいますが、もっとも重要なのは、<a hreflang="en" href="https://meiert.com/en/blog/the-number-of-html-elements/">どのように数えているかをはっきりさせることです。</a></aside>
 
 何を観察できるのか？
 
diff --git a/src/content/ja/2022/media.md b/src/content/ja/2022/media.md
index 14d3d09933d..f53bb8cb492 100644
--- a/src/content/ja/2022/media.md
+++ b/src/content/ja/2022/media.md
@@ -656,7 +656,7 @@ So how accurate are our `sizes`?
 
 私たちは、デスクトップページの4分の1が、純粋に悪い`sizes`属性に基づいて、83KB以上の余分な画像データを読み込んでいると推定しています。つまり、次のようなことです。`srcset`にもっと小さくて良いリソースがあるのに、`sizes`属性が誤っているため、ブラウザがそれを選択しないのです。さらに、sizesを使用するデスクトップページの10%は、間違ったsizes属性のために、5メガバイト以上の過剰な画像データを読み込んでいます！
 
-<p class="note">注：当社のクローラーは実際には正しいリソースを読み込まなかったため、ここに記載した数字は、クローラーが実際に読み込んだ誤ったリソースのバイトサイズに基づく推定値です。</p>
+<aside class="note">注：当社のクローラーは実際には正しいリソースを読み込まなかったため、ここに記載した数字は、クローラーが実際に読み込んだ誤ったリソースのバイトサイズに基づく推定値です。</aside>
 
 短期的に個々の開発者は<a hreflang="en" href="https://ausi.github.io/respimagelint/">RespImageLint</a> を使用して、ひどく壊れた`sizes`属性を監査して修正し、この種のムダを防止できますし、そうすべきです。
 
diff --git a/src/content/ja/2022/performance.md b/src/content/ja/2022/performance.md
index 5d7bb77e6e7..b904f09f7ca 100644
--- a/src/content/ja/2022/performance.md
+++ b/src/content/ja/2022/performance.md
@@ -35,7 +35,7 @@ featured_stat_label_3: INPで良いCWVが期待できる上位1kサイト
 
 CWVプログラムは、業界ではじめて、ユーザーが実際にパフォーマンスをどのように体験しているかを測定する明確に定義されたアプローチを提案しています。CWVは、ウェブをよりパフォーマントにするための答えでしょうか？この章では、現在のウェブがCWVとどのような関係にあるか、そして未来に向けての展望を検討します。
 
-<p class="note">開示: この章は、Core Web Vitalsプログラムを作成したGoogleの従業員によって共同執筆されています。この章とその基礎となる分析は、Googleと無関係の他の人々によってレビューされ、承認されました。</p>
+<aside class="note">開示: この章は、Core Web Vitalsプログラムを作成したGoogleの従業員によって共同執筆されています。この章とその基礎となる分析は、Googleと無関係の他の人々によってレビューされ、承認されました。</aside>
 
 ## Core Web Vitals
 
diff --git a/src/content/ja/2022/security.md b/src/content/ja/2022/security.md
index bd42882bdb3..7c871cba570 100644
--- a/src/content/ja/2022/security.md
+++ b/src/content/ja/2022/security.md
@@ -634,7 +634,7 @@ HTTPヘッダーとして使用されるだけでなく、この機能は以下
 
 モバイルの1,740万フレームのうち12.6%に`allow`属性が含まれており、許可または機能ポリシーを有効にしています。
 
-<p class="note">この章の以前のバージョンでは、フレームの合計数と `allow` 属性を持つフレームの割合の値が間違っていました。詳細については、この <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> を参照してください。</p>
+<aside class="note">この章の以前のバージョンでは、フレームの合計数と `allow` 属性を持つフレームの割合の値が間違っていました。詳細については、この <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> を参照してください。</aside>
 
 以下は、フレームで検出されたトップ10の`allow`ディレクティブのリストです：
 
@@ -741,7 +741,7 @@ function clickToGo() {
 
 デスクトップ ウェブサイトにあるすべての iframe のうち、21.08% に `sandbox` 属性が含まれています。
 
-<p class="note">この章の以前のバージョンでは、`sandbox` 属性を持つフレームの割合が誤って報告されていました。詳細については、この <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> を参照してください。</p>
+<aside class="note">この章の以前のバージョンでは、`sandbox` 属性を持つフレームの割合が誤って報告されていました。詳細については、この <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> を参照してください。</aside>
 
 モバイルの`Content-Security-Policy`ヘッダーに`sandbox`指令を含むものはわずか0.3%（デスクトップも同様に0.4%）であり、この属性がページ内でiframeコンテンツを埋め込む際にケースバイケースで適用されることが多く、事前のコンテンツセキュリティポリシー定義を通じて計画することは少ないことを示しています。
 
diff --git a/src/content/ja/2022/sustainability.md b/src/content/ja/2022/sustainability.md
index 8535c97ebbb..5ac788e38ce 100644
--- a/src/content/ja/2022/sustainability.md
+++ b/src/content/ja/2022/sustainability.md
@@ -117,7 +117,7 @@ Ecograder、Website Carbon、Ecoping、CO2.jsなど、いくつかの利用可
 
 ### 炭素排出量
 
-<p class="note">注: 「炭素排出量」という概念は単純化されています。ここでは温室効果ガス排出量を考慮しており、単に炭素排出量のみではありません。</p>
+<aside class="note">注: 「炭素排出量」という概念は単純化されています。ここでは温室効果ガス排出量を考慮しており、単に炭素排出量のみではありません。</aside>
 
 {{ figure_markup(
   image="carbon-emissions-by-percentile.png",
@@ -190,7 +190,7 @@ Ecograder、Website Carbon、Ecoping、CO2.jsなど、いくつかの利用可
 
 ### より持続可能なホスティング
 
-<p class="note">注: ここでは（他の場所でも）「グリーンホスティング」という言及が見られます。これはある種の省略形で、実際に完全にグリーンである、またはカーボンニュートラルなどのホスティングは存在しません。ここでは、より持続可能なホスティングの使用方法に焦点を当てます。</p>
+<aside class="note">注: ここでは（他の場所でも）「グリーンホスティング」という言及が見られます。これはある種の省略形で、実際に完全にグリーンである、またはカーボンニュートラルなどのホスティングは存在しません。ここでは、より持続可能なホスティングの使用方法に焦点を当てます。</aside>
 
 この章の大部分では、ネットワーク、コンピュート、ストレージなどのリソース量の変化がデジタルサービスの環境への影響にどのように影響するかに焦点を当てています。これを持続可能性のためのレバーとしての_消費_と考えるかもしれません。しかし、他にもレバーは存在します。ゼロまで効率化することはできませんが、同じ種類のサーバーで実行される同じコードが、よりグリーンなエネルギーで実行される場合、それはそうでない場合よりも環境への影響が低くなります。このレバーを_強度_と考えることができます。
 
@@ -215,7 +215,7 @@ Ecograder、Website Carbon、Ecoping、CO2.jsなど、いくつかの利用可
 
 全体として、測定されたウェブサイトのわずか10パーセントがグリーンホスティングに依存しています。これはウェブサイトがグリーンホスティングを選択することと、ホスティング会社が持続可能性を目指すことの両方で、多くのことが行われるべきであり、行われるべきであることを強調しています。
 
-<p class="note">注: グリーンドメインのこれらの数字は、グリーンウェブ財団と直接共有された情報、または公開された情報に基づいています。彼らの検索サービスのAPIレスポンスでリンクされています。サイトがグリーンであると思われる場合に「グリーンではない」と表示される理由については、<a hreflang="en" href="https://www.thegreenwebfoundation.org/support/why-does-my-website-show-up-as-grey-in-the-green-web-checker/">彼らの説明ページ</a>を参照してください。</p>
+<aside class="note">注: グリーンドメインのこれらの数字は、グリーンウェブ財団と直接共有された情報、または公開された情報に基づいています。彼らの検索サービスのAPIレスポンスでリンクされています。サイトがグリーンであると思われる場合に「グリーンではない」と表示される理由については、<a hreflang="en" href="https://www.thegreenwebfoundation.org/support/why-does-my-website-show-up-as-grey-in-the-green-web-checker/">彼らの説明ページ</a>を参照してください。</aside>
 
 ### ウェブサイトの環境への影響を減らす
 
diff --git a/src/content/nl/2019/accessibility.md b/src/content/nl/2019/accessibility.md
index f5a4838650f..1a1c3755e16 100644
--- a/src/content/nl/2019/accessibility.md
+++ b/src/content/nl/2019/accessibility.md
@@ -57,7 +57,7 @@ Om ervoor te zorgen dat uw website onder deze omstandigheden leesbaar is, is het
 
 Slechts 22,04% van de sites gaf al hun tekst voldoende kleurcontrast. Of met andere woorden: 4 op de 5 sites hebben tekst die gemakkelijk op de achtergrond overgaat, waardoor deze onleesbaar wordt.
 
-<p class="note">Merk op dat we geen enkele tekst in afbeeldingen konden analyseren, dus onze gerapporteerde statistiek is een bovengrens van het totale aantal websites dat de kleurcontrasttest heeft doorstaan.</p>
+<aside class="note">Merk op dat we geen enkele tekst in afbeeldingen konden analyseren, dus onze gerapporteerde statistiek is een bovengrens van het totale aantal websites dat de kleurcontrasttest heeft doorstaan.</aside>
 
 ### Pagina's zoomen en schalen
 
diff --git a/src/content/nl/2020/caching.md b/src/content/nl/2020/caching.md
index 187528aad5c..3de1ca51126 100644
--- a/src/content/nl/2020/caching.md
+++ b/src/content/nl/2020/caching.md
@@ -72,9 +72,9 @@ De onderstaande afbeelding laat zien hoe een typische aanvraag-/reactiestroom we
   )
 }}
 
-<p class="note">Opmerking: tenzij anders aangegeven, zijn alle statistieken in dit hoofdstuk voor mobiel, met dien verstande dat desktopstatistieken vergelijkbaar zijn. Waar mobiele statistieken en desktopstatistieken aanzienlijk verschillen, wordt dat genoemd.
+<aside class="note">Opmerking: tenzij anders aangegeven, zijn alle statistieken in dit hoofdstuk voor mobiel, met dien verstande dat desktopstatistieken vergelijkbaar zijn. Waar mobiele statistieken en desktopstatistieken aanzienlijk verschillen, wordt dat genoemd.
 
-Veel van de reacties die in dit hoofdstuk worden gebruikt, zijn afkomstig van webservers die algemeen verkrijgbare serverpakketten gebruiken. Hoewel we beste praktijken kunnen aangeven, is het mogelijk dat de procedures niet mogelijk zijn als het gebruikte softwarepakket een beperkt aantal cache-opties heeft.</p>
+Veel van de reacties die in dit hoofdstuk worden gebruikt, zijn afkomstig van webservers die algemeen verkrijgbare serverpakketten gebruiken. Hoewel we beste praktijken kunnen aangeven, is het mogelijk dat de procedures niet mogelijk zijn als het gebruikte softwarepakket een beperkt aantal cache-opties heeft.</aside>
 
 ## Caching leidende principes
 
diff --git a/src/content/nl/2020/ecommerce.md b/src/content/nl/2020/ecommerce.md
index 4ef3ed1c21d..7d61f865d1f 100644
--- a/src/content/nl/2020/ecommerce.md
+++ b/src/content/nl/2020/ecommerce.md
@@ -64,7 +64,7 @@ Onze methodologie heeft de volgende beperkingen:
 
 In totaal gebruikte 21,72% van de mobiele websites en 21,27% van de desktopwebsites een e-commerceplatform. Voor 2019 was hetzelfde aantal 9,41% voor mobiele websites en 9,67% voor desktopwebsites.
 
-<p class="note">Opmerking: deze toename is voornamelijk het gevolg van verbeteringen die zijn aangebracht in Wappalyzer om e-commercewebsites te detecteren en mag niet worden toegeschreven aan andere factoren, zoals groei als gevolg van Covid-19. Ook werd achteraf een kleine correctie toegepast op 2019-statistieken om rekening te houden met een fout en daarom zijn de 2019-percentages iets anders dan die gegeven in het <a href="../2019/ecommerce">2019 E-commerce</a> hoofdstuk .</p>
+<aside class="note">Opmerking: deze toename is voornamelijk het gevolg van verbeteringen die zijn aangebracht in Wappalyzer om e-commercewebsites te detecteren en mag niet worden toegeschreven aan andere factoren, zoals groei als gevolg van Covid-19. Ook werd achteraf een kleine correctie toegepast op 2019-statistieken om rekening te houden met een fout en daarom zijn de 2019-percentages iets anders dan die gegeven in het <a href="../2019/ecommerce">2019 E-commerce</a> hoofdstuk .</aside>
 
 ### Top e-commerceplatforms
 
@@ -135,7 +135,7 @@ COVID-19 heeft een enorme impact op de wereld gehad en maakte een nog grotere on
 
 Er is absoluut een meetbare toename van WooCommerce- en Shopify-sites rond de tijd dat COVID echt invloed op de wereld begon te hebben.
 
-<p class="note">Opmerking: <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/pull/2731/commits/f44f20f03618f6a5fd868dd38ce9db5e2e2f1407">Wappalyzer-detectie voor Wix</a> maakt geen onderscheid als een site Wix gebruikt als CMS of e-commerceplatform. Hierdoor wordt de groei van Wix als e-commerceplatform mogelijk niet correct weergegeven in de bovenstaande grafiek.</p>
+<aside class="note">Opmerking: <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/pull/2731/commits/f44f20f03618f6a5fd868dd38ce9db5e2e2f1407">Wappalyzer-detectie voor Wix</a> maakt geen onderscheid als een site Wix gebruikt als CMS of e-commerceplatform. Hierdoor wordt de groei van Wix als e-commerceplatform mogelijk niet correct weergegeven in de bovenstaande grafiek.</aside>
 
 ## Paginagewicht en verzoeken
 
@@ -241,7 +241,7 @@ De bovenstaande cijfers laten zien dat de gemiddelde e-commercepagina 34 afbeeld
   sql_file="pagestats_image_bydevice_format.sql"
 ) }}
 
-<p class="note">Merk op dat sommige afbeeldingsservices of CDN's automatisch WebP (in plaats van JPEG of PNG) leveren aan platforms die WebP ondersteunen, zelfs voor een URL met een <code>.jpg</code> of <code>.png</code> achtervoegsel . <code>IMG_20190113_113201.jpg</code> retourneert bijvoorbeeld een WebP-afbeelding in Chrome. De manier waarop HTTP Archive afbeeldingsindelingen detecteert, is door eerst te controleren op trefwoorden in het MIME-type en vervolgens terug te vallen op de bestandsextensie. Dit betekent dat het formaat voor afbeeldingen met URL's zoals de bovenstaande wordt gegeven als WebP, aangezien WebP wordt ondersteund door HTTP Archive als user-agent.</p>
+<aside class="note">Merk op dat sommige afbeeldingsservices of CDN's automatisch WebP (in plaats van JPEG of PNG) leveren aan platforms die WebP ondersteunen, zelfs voor een URL met een <code>.jpg</code> of <code>.png</code> achtervoegsel . <code>IMG_20190113_113201.jpg</code> retourneert bijvoorbeeld een WebP-afbeelding in Chrome. De manier waarop HTTP Archive afbeeldingsindelingen detecteert, is door eerst te controleren op trefwoorden in het MIME-type en vervolgens terug te vallen op de bestandsextensie. Dit betekent dat het formaat voor afbeeldingen met URL's zoals de bovenstaande wordt gegeven als WebP, aangezien WebP wordt ondersteund door HTTP Archive als user-agent.</aside>
 
 Het PNG-gebruik bleef ongeveer op [hetzelfde niveau als 2019](../2019/ecommerce#png) (op 27% voor zowel desktop als mobiel). We zagen een daling van het JPEG-gebruik (4% voor desktop en 6% voor mobiel). Van deze daling ging het meeste naar een verhoogd GIF-gebruik. GIF's komen vrij vaak voor op e-commerce-homepagina's, terwijl GIF's misschien niet veel worden gebruikt op productdetailpagina's. Omdat onze methodologie alleen naar homepagina's kijkt, verklaart dit het aanzienlijk hoge gebruik van GIF's op e-commercesites. Lighthouse heeft een audit die het gebruik van "videoformaten voor geanimeerde inhoud" aanbeveelt. Dit is een techniek die e-commercesites kunnen gebruiken om de prestaties te optimaliseren, maar toch de animatie-eigenschappen van GIF's te behouden. Zie <a hreflang="en" href="https://web.dev/replace-gifs-with-videos/">dit artikel</a> voor meer details.
 
@@ -437,7 +437,7 @@ Het gebruik van tagging aan de serverzijde is afhankelijk van de vraag of derde
   <figcaption>{{ figure_link(caption="Tagmanager-gebruik op e-commercesites.", sheets_gid="2045910168", sql_file="percent_of_ecommsites_using_each_tag_managers.sql") }}</figcaption>
 </figure>
 
-<p class="note">Opmerking: de bovenstaande analyse is gebaseerd op Wappalyzer-detectie, die kan verschillen van de analyse die is uitgevoerd met behulp van de <a href="./methodology#third-party-web">Third Party Web</a> dataset die wordt gebruikt voor <a href="./third-parties">Derden</a> hoofdstuk.</p>
+<aside class="note">Opmerking: de bovenstaande analyse is gebaseerd op Wappalyzer-detectie, die kan verschillen van de analyse die is uitgevoerd met behulp van de <a href="./methodology#third-party-web">Third Party Web</a> dataset die wordt gebruikt voor <a href="./third-parties">Derden</a> hoofdstuk.</aside>
 
 ### Toestemmingsbeheerplatformen
 
diff --git a/src/content/nl/2020/http.md b/src/content/nl/2020/http.md
index e3792ccc590..4290e314d12 100644
--- a/src/content/nl/2020/http.md
+++ b/src/content/nl/2020/http.md
@@ -98,9 +98,9 @@ Wanneer Figuur 22.3 wordt vergeleken met de resultaten van vorig jaar, is er een
   <figcaption>{{ figure_link(caption="Gebruik van HTTP-versie op verzoek.", sheets_gid="2122693316", sql_file="adoption_of_http_2_by_site_and_requests.sql") }}</figcaption>
 </figure>
 
-<p class="note">
+<aside class="note">
   ** 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.
-</note>
+</aside>
 
 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.
 
diff --git a/src/content/nl/2020/jamstack.md b/src/content/nl/2020/jamstack.md
index 0f53e0f85d6..e0f82543c8d 100644
--- a/src/content/nl/2020/jamstack.md
+++ b/src/content/nl/2020/jamstack.md
@@ -30,7 +30,7 @@ Het <a hreflang="en" href="https://httparchive.org/">HTTP Archive</a> crawlt elk
 
 De doelen van dit hoofdstuk zijn het schatten en analyseren van de groei van de Jamstack-sites, de prestaties van populaire Jamstack-frameworks, evenals een analyse van de echte gebruikerservaring met behulp van de Core Web Vitals-statistieken.
 
-<p class="note">Opgemerkt moet worden dat onze analyse beperkt is tot die Jamstacks die zichzelf gemakkelijk identificeerbaar maken met behulp van <a href="./methodology#wappalyzer">Wappalyzer</a>. Dit betekent dat onze gegevens geen populaire Jamstacks bevatten, zoals <a hreflang="en" href="https://github.com/11ty/eleventy/">Eleventy</a> die <a href="https://x.com/eleven_ty/status/1334225624110608387?s=20">een bewuste keuze maken om zichzelf niet identificeerbaar te maken</a>. Hoewel we idealiter alle Jamstacks zouden opnemen, zijn we van mening dat het nog steeds waardevol is om de significante gegevens die we hebben te analyseren.</p>
+<aside class="note">Opgemerkt moet worden dat onze analyse beperkt is tot die Jamstacks die zichzelf gemakkelijk identificeerbaar maken met behulp van <a href="./methodology#wappalyzer">Wappalyzer</a>. Dit betekent dat onze gegevens geen populaire Jamstacks bevatten, zoals <a hreflang="en" href="https://github.com/11ty/eleventy/">Eleventy</a> die <a href="https://x.com/eleven_ty/status/1334225624110608387?s=20">een bewuste keuze maken om zichzelf niet identificeerbaar te maken</a>. Hoewel we idealiter alle Jamstacks zouden opnemen, zijn we van mening dat het nog steeds waardevol is om de significante gegevens die we hebben te analyseren.</aside>
 
 ## Adoptie van Jamstack
 
diff --git a/src/content/nl/2020/markup.md b/src/content/nl/2020/markup.md
index 03b2a2d82a4..96077884e15 100644
--- a/src/content/nl/2020/markup.md
+++ b/src/content/nl/2020/markup.md
@@ -30,9 +30,9 @@ Hoe gebruiken we HTML dan, hoe groot is onze basis? In het inleidende gedeelte v
 
 De analyse van vorig jaar was gebaseerd op 5,8 miljoen pagina's, waarvan 4,4 miljoen op desktop en 5,3 miljoen op mobiel. Dit jaar hebben we 7,5 miljoen pagina's geanalyseerd, waarvan 5,6 miljoen op desktopcomputers en 6,3 miljoen op mobiele apparaten, met behulp van de [laatste gegevens](./methodology#websites) op de websites die gebruikers in 2020 bezoeken. We maken enkele vergelijkingen met vorig jaar, maar net zoals we hebben geprobeerd om aanvullende statistieken te analyseren voor nieuwe inzichten, hebben we ook geprobeerd onze eigen persoonlijkheden en perspectieven door te geven in het hoofdstuk.
 
-<p class="note">
+<aside class="note">
   In dit Opmaak-hoofdstuk concentreren we ons bijna uitsluitend op HTML, in plaats van SVG of MathML, die ook als opmaaktalen worden beschouwd. Tenzij anders vermeld, verwijzen de statistieken in dit hoofdstuk naar de set mobiele pagina's. Bovendien zijn de gegevens voor alle Web Almanac-hoofdstukken open en beschikbaar. Bekijk <a hreflang="en" href="https://docs.google.com/spreadsheets/d/1Ta7amoUeaL4pILhWzH-SCzMX9PsZeb1x_mwrX2C4eY8/">de resultaten</a> en <a hreflang="en" href="https://discuss.httparchive.org/t/2039">deel uw observaties</a> met de community!
-</p>
+</aside>
 
 ## Algemeen
 
@@ -1019,9 +1019,9 @@ We hebben de gegevens bekeken en om de resultaten beter te begrijpen, hebben we
 
 De resultaten laten zien dat bijna de helft van de pagina's die we hebben geanalyseerd de typische viewport-`content`-waarde gebruikt. Toch mist ongeveer 10% van de mobiele pagina's volledig een juiste `content`-waarde voor het viewport-meta-element, terwijl de rest een onjuiste combinatie gebruikt van `maximum-scale`, `minimum-scale`, `user-scalable=no`, of `user-scalable=0`.
 
-<p class="note">
+<aside class="note">
   Met de mobiele Edge-browser kunnen gebruikers al een tijdje inzoomen op een webpagina naar <a hreflang="en" href="https://blogs.windows.com/windows-insider/2017/01/12/announcing-windows-10-insider-preview-build-15007-pc-mobile/">ten minste 500%</a>, ongeacht de zoominstellingen die zijn gedefinieerd door een webpagina die het viewport-meta-element gebruikt.
-</p>
+</aside>
 
 ### Favicons
 
@@ -1306,7 +1306,7 @@ Het gebruik van `target="_blank"` staat al enige tijd bekend als een <a hreflang
 
 Als vuistregel en om <a hreflang="en" href="https://www.nngroup.com/articles/new-browser-windows-and-tabs/">gebruiksredenen</a>, wordt het aangeraden `target="_blank"` niet te gebruiken in de eerste plaats.
 
-<p class="note">In de nieuwste Safari- en Firefox-versies biedt het instellen van <code>target="_blank"</code> op <code>a</code>-elementen impliciet hetzelfde <code>rel</code>-gedrag als het instellen van <code>rel="noopener"</code>. Dit is ook al <a hreflang="en" href="https://chromium-review.googlesource.com/c/chromium/src/+/1630010">geïmplementeerd in Chromium</a> en komt ook in Chrome 88 terecht.</p>
+<aside class="note">In de nieuwste Safari- en Firefox-versies biedt het instellen van <code>target="_blank"</code> op <code>a</code>-elementen impliciet hetzelfde <code>rel</code>-gedrag als het instellen van <code>rel="noopener"</code>. Dit is ook al <a hreflang="en" href="https://chromium-review.googlesource.com/c/chromium/src/+/1630010">geïmplementeerd in Chromium</a> en komt ook in Chrome 88 terecht.</aside>
 
 ## Gevolgtrekking
 
@@ -1336,6 +1336,6 @@ Dat dwingt ons om af te sluiten met een oproep: let op HTML. Focus op HTML. Het
 
 Laten we ons voor de volgende editie van het hoofdstuk over de Web Almanac voorbereiden om nader te kijken naar het vak van het schrijven van HTML en, hopelijk, hoe we het hebben verbeterd.
 
-<p class="note">
+<aside class="note">
   We laten dit voor u open. Wat zijn uw opmerkingen? Wat viel u op? Wat is er volgens u verslechterd, en wat is er verbeterd? <a hreflang="en" href="https://discuss.httparchive.org/t/2039">Laat een reactie achter</a> om uw mening te delen!
-</p>
+</aside>
diff --git a/src/content/nl/2020/media.md b/src/content/nl/2020/media.md
index c21f0f54cdb..f75096a64bc 100644
--- a/src/content/nl/2020/media.md
+++ b/src/content/nl/2020/media.md
@@ -186,7 +186,7 @@ Van de pagina's die `<picture>` gebruiken om van formaat te wisselen, biedt onge
 
 We zien dat WebP het dominante gebruik is van `<source>`-elementen, gevolgd door PNG, en dat en JPG slechts 4,83% van `<picture>`-gebruik is.
 
-<p class="note">Merk op dat onze crawler crawlt als Chrome die WebP ondersteunt, maar als u een andere browser gebruikt die dit niet ondersteunt, ziet u andere resultaten.</p>
+<aside class="note">Merk op dat onze crawler crawlt als Chrome die WebP ondersteunt, maar als u een andere browser gebruikt die dit niet ondersteunt, ziet u andere resultaten.</aside>
 
 Hier is een voorbeeld van de markup-syntaxis die kan worden gebruikt om meerdere indelingsvarianten aan te bieden:
 
@@ -223,7 +223,7 @@ Er zijn drie aspecten waarmee u rekening moet houden bij het implementeren van f
 
 Verschillende Dynamic Media Services en Image CDN's kunnen dit aanzienlijk vereenvoudigen door het te automatiseren en te trachten het steeds veranderende ondersteuningslandschap van browserformaten te volgen en er mee te synchroniseren.
 
-<p class="note">Let op: hoewel AVIF wordt ondersteund in Chrome sinds versie 85 (uitgebracht eind augustus 2020), zijn de gegevens voor deze Almanac voornamelijk van vóór deze tijd. Als u echter een ad-hoczoekopdracht uitvoert op recentere gegevens van begin november 2020, worden tienduizenden AVIF-verzoeken weergegeven.</p>
+<aside class="note">Let op: hoewel AVIF wordt ondersteund in Chrome sinds versie 85 (uitgebracht eind augustus 2020), zijn de gegevens voor deze Almanac voornamelijk van vóór deze tijd. Als u echter een ad-hoczoekopdracht uitvoert op recentere gegevens van begin november 2020, worden tienduizenden AVIF-verzoeken weergegeven.</aside>
 
 ##### Picture: media art direction
 
diff --git a/src/content/nl/2020/mobile-web.md b/src/content/nl/2020/mobile-web.md
index 4c1edcc039f..c7bda81ca0f 100644
--- a/src/content/nl/2020/mobile-web.md
+++ b/src/content/nl/2020/mobile-web.md
@@ -39,7 +39,7 @@ Naast het bovenstaande hebben we ook een niet-openbare Chrome-gegevensbron gebru
 
 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.
 
-<p class="note">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.</p>
+<aside class="note">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.</aside>
 
 ## Verkeerstrends voor mobiel internet en desktop
 
@@ -51,7 +51,7 @@ Een <a hreflang="en" href="https://www.perficient.com/insights/research-hub/mobi
 
 Merk op dat deze sectie verwijst naar statistieken die specifiek voor dit hoofdstuk beschikbaar zijn gemaakt vanuit de niet-openbare Chrome-gegevensbron, [zie details hier](#gegevensbronnen). We gebruiken deze gegevens om het laden van pagina's op Android en Windows te beoordelen — als een proxy voor respectievelijk mobiel en desktop.
 
-<p class="note">OPMERKING: we verwijzen naar de gegevens in deze sectie als mobiel voor Android en desktop voor Windows.</p>
+<aside class="note">OPMERKING: we verwijzen naar de gegevens in deze sectie als mobiel voor Android en desktop voor Windows.</aside>
 
 #### Paginaladingen in verschillende herkomsten, gerangschikt op populariteit
 
diff --git a/src/content/nl/2020/pwa.md b/src/content/nl/2020/pwa.md
index cedb2421a6a..a3a66631d61 100644
--- a/src/content/nl/2020/pwa.md
+++ b/src/content/nl/2020/pwa.md
@@ -141,7 +141,7 @@ Hoewel dat gebruik misschien laag lijkt, is het belangrijk dat we ons realiseren
   <figcaption>{{ figure_link(caption="Lighthouse PWA-audits.", sheets_gid="814184412", sql_file="lighthouse_pwa_audits.sql") }}</figcaption>
 </figure>
 
-<p class="note">Merk op dat de prestatiestatistieken voor onze Lighthouse-tests onjuist waren voor onze crawl van augustus, dus het resultaat <code lang="en">load-fast-done-for-pwa</code> is vervangen door de resultaten van september.</p>
+<aside class="note">Merk op dat de prestatiestatistieken voor onze Lighthouse-tests onjuist waren voor onze crawl van augustus, dus het resultaat <code lang="en">load-fast-done-for-pwa</code> is vervangen door de resultaten van september.</aside>
 
 Een <a hreflang="en" href="https://web.dev/load-fast-enough-for-pwa/">snelle paginalading</a> zorgt voor een goede mobiele gebruikerservaring, vooral wanneer rekening wordt gehouden met langzamere mobiele netwerken. 27,56% van de pagina's werd snel genoeg geladen voor een PWA. Gezien de geografische spreiding van het web, is een snelle laadtijd met lichtere pagina's de meeste van de volgende miljard gebruikers van het web, van wie de meesten via een mobiel apparaat op internet zullen komen.
 
diff --git a/src/content/nl/2020/security.md b/src/content/nl/2020/security.md
index 44222e3a022..74e439411e5 100644
--- a/src/content/nl/2020/security.md
+++ b/src/content/nl/2020/security.md
@@ -623,7 +623,7 @@ Op een vergelijkbare manier, door het `allow`-attribuut op `<iframe>`-elementen
 
 De antwoordkop van `Feature-Policy` heeft een vrij lage acceptatiegraad, met 0,60% van de desktoppagina's en 0,51% van de mobiele pagina's. Aan de andere kant was functiebeleid ingeschakeld voor 11,8% van de 13,2 miljoen frames die op de desktoppagina's werden gevonden. Op mobiele pagina's bevatte 10,8% van de 13,9 miljoen frames het attribuut `allow`.
 
-<p class="note">Een eerdere versie van dit hoofdstuk vermeldde onjuiste waarden voor het totale aantal frames en het percentage frames met het kenmerk `allow`. Meer informatie is te vinden in deze <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</p>
+<aside class="note">Een eerdere versie van dit hoofdstuk vermeldde onjuiste waarden voor het totale aantal frames en het percentage frames met het kenmerk `allow`. Meer informatie is te vinden in deze <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</aside>
 
 Op basis van de meest gebruikte richtlijnen in het functiebeleid voor iframes, kunnen we zien dat deze voornamelijk worden gebruikt om te bepalen hoe de frames video's afspelen. De meest voorkomende richtlijn, `encrypted-media`, wordt bijvoorbeeld gebruikt om de toegang tot de Encrypted Media Extensions API te controleren, die nodig is om DRM-beveiligde video's af te spelen. De meest voorkomende iframe-herkomsten met een functiebeleid waren `https://www.facebook.com` en `https://www.youtube.com` (respectievelijk 49,87% en 26,18% van de frames met een functiebeleid op desktoppagina's ).
 
@@ -633,7 +633,7 @@ Door een niet-vertrouwde derde partij op te nemen in een iframe, kan die derde p
 
 Het `sandbox`-attribuut op iframes kan worden gebruikt om de mogelijkheden, en dus ook de mogelijkheden om aanvallen uit te voeren, van de embedded webpagina te beperken. Aangezien het insluiten van inhoud van derden, zoals advertenties of video's, gebruikelijk is op internet, is het niet verrassend dat veel hiervan worden beperkt via het `sandbox`-attribuut: 18,3% van de iframes op desktoppagina's heeft een `sandbox`-attribuut terwijl op mobiele pagina's is dit 21,9%.
 
-<p class="note">Een eerdere versie van dit hoofdstuk vermeldde onjuiste waarden voor het percentage frames met het kenmerk `sandbox`. Meer informatie is te vinden in deze <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</p>
+<aside class="note">Een eerdere versie van dit hoofdstuk vermeldde onjuiste waarden voor het percentage frames met het kenmerk `sandbox`. Meer informatie is te vinden in deze <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a>.</aside>
 
 <figure>
   <table>
@@ -838,7 +838,7 @@ De <a hreflang="en" href="https://www.w3.org/TR/WebCryptoAPI/">Web Cryptography
 
 Onze resultaten laten zien dat de functie `Cypto.getRandomValues`, die het mogelijk maakt om een willekeurig getal te genereren (op een veilige, cryptografische manier) verreweg de meest gebruikte is (desktop: 70% en mobiel: 68%). We denken dat het gebruik van deze functie door Google Analytic een groot effect heeft op het gemeten gebruik. Over het algemeen zien we dat mobiele websites iets minder cryptografische bewerkingen uitvoeren, hoewel mobiele browsers deze API [volledig ondersteunen](https://developer.mozilla.org/docs/Web/API/Web_Crypto_API#Browser_compatibility).
 
-<p class="note">Opgemerkt moet worden dat, aangezien we passief crawlen, onze resultaten in deze sectie hierdoor worden beperkt. We kunnen geen gevallen identificeren waarin enige interactie vereist is voordat de functies worden uitgevoerd.</p>
+<aside class="note">Opgemerkt moet worden dat, aangezien we passief crawlen, onze resultaten in deze sectie hierdoor worden beperkt. We kunnen geen gevallen identificeren waarin enige interactie vereist is voordat de functies worden uitgevoerd.</aside>
 
 ### Gebruikmakend van botbeveiligingsservices
 
diff --git a/src/content/nl/2021/privacy.md b/src/content/nl/2021/privacy.md
index f26a06484b3..47350dd2f15 100644
--- a/src/content/nl/2021/privacy.md
+++ b/src/content/nl/2021/privacy.md
@@ -272,7 +272,7 @@ Geolocatiegegevens kunnen ook opgevraagd worden door websites via een [webbrowse
 
 Slecht beveiligingsbeheer binnen een bedrijf kan een {significante impact hebben op de privégegevens van hun klanten. <a hreflang="en" href="https://haveibeenpwned.com/">Have I Been Pwned</a> laat aan gebruikers toe om te controleren of hun e-mailadres of telefoonnummer gelekt werd in een gegevenslek. Op het moment van schrijven heeft Have I Been Pwned 562 gegevenslekken bijgehouden, waarin 640 miljoen gegevens gelekt werden. Alleen al in 2020 werden 40 diensten gekraakt en de persoonlijke gegevens van miljoenen gebruikers gelekt. Drie van deze lekken werden gemarkeerd als _gevoelig_, wat verwijst naar de mogelijkheid om een negatieve impact te hebben op de gebruiker als iemand de gegevens van die gebruikers in het gegevenslek zou vinden. Een voorbeeld van een gevoelig gegevenslek is "[Carding Mafia](https://www.vice.com/en/article/v7m9jx/credit-card-hacking-forum-gets-hacked-exposing-300000-hackers-accounts)", een platform waar gestolen kredietkaarten worden verhandeld.
 
-<p class="note">Merk op dat 40 gegevenslekken in het voorbije jaar een ondergrens is, aangezien veel gegevenslekken pas ontdekt of publiek gemaakt worden verschillende maanden nadat ze hebben plaatsgevonden.</p>
+<aside class="note">Merk op dat 40 gegevenslekken in het voorbije jaar een ondergrens is, aangezien veel gegevenslekken pas ontdekt of publiek gemaakt worden verschillende maanden nadat ze hebben plaatsgevonden.</aside>
 
 {{ figure_markup(
   image="data_breaches_pwned_accounts_per_class.png",
@@ -362,7 +362,7 @@ De meest voorkomende Referrer Policy die expliciet gezet wordt is `no-referrer-w
 
 Daarenboven zetten ongeveer 0,5% van de websites de waarde van de Referrer Policy op `unsafe-url`, wat toelaat dat de oorsprong, gastheer en vraagstring met _elk_ verzoek gestuurd worden, ongeacht het beveiligingsniveau van de ontvanger. In dit geval zou een verwijzer in klaartekst verzonden kunnen worden, wat potentieel privégegevens lekt. Wat verontrustend is, is dat er websites die actief geconfigureerd zijn om dit gedrag toe te laten.
 
-<p class="note">Merk op: Websites kunnen de verwijzerinformatie ook als een URL-parameter naar de bestemmingssite sturen. We hebben het gebruik van dat mechanisme in dit rapport niet gemeten.</p>
+<aside class="note">Merk op: Websites kunnen de verwijzerinformatie ook als een URL-parameter naar de bestemmingssite sturen. We hebben het gebruik van dat mechanisme in dit rapport niet gemeten.</aside>
 
 ### User-Agent Client Hints
 
@@ -509,7 +509,7 @@ Naast het blokkeren van trackers, heeft Chrome de <a hreflang="en" href="https:/
 
 Om feedback vanuit het ecosysteem te verkrijgen, worden vroege en experimentele versies van Privacy Sandbox-APIs initieel beschikbaar gemaakt door middel van <a hreflang="en" href="https://www.chromium.org/developers/how-tos/run-chromium-with-flags">functievlaggen</a> voor tests door individuele ontwikkelaars, en dan in Chrome via <a hreflang="en" href="https://developer.chrome.com/blog/origin-trials">_oorsprongsproeven_</a> ("origin trials"). Sites kunnen deelnemen in deze oorsprongsproeven}om experimentele webplatformfuncties te testen, en commentaar te geven naar de webstandaardengemeenschap over de gebruiksvriendelijkheid, uitvoerbaarheid en effectiviteit van een functie, vooraleer ze voor alle websites standaard beschikbaar wordt gemaakt.
 
-<p class="note">**Disclaimer:** Oorsprongsproeven zijn enkel beschikbaar voor een beperkte tijd. De getallen hieronder geven de toestand van Privacy Sandbox oorsprongsproeven weer op het moment van schrijven, in oktober 2021.</p>
+<aside class="note">**Disclaimer:** Oorsprongsproeven zijn enkel beschikbaar voor een beperkte tijd. De getallen hieronder geven de toestand van Privacy Sandbox oorsprongsproeven weer op het moment van schrijven, in oktober 2021.</aside>
 
 ### FLoC
 
diff --git a/src/content/pt/2019/css.md b/src/content/pt/2019/css.md
index db645dd3882..4b1f8ca9cab 100644
--- a/src/content/pt/2019/css.md
+++ b/src/content/pt/2019/css.md
@@ -107,7 +107,7 @@ Sem surpresa, na Figura 2.5 acima, a unidade `px` é o tipo de unidade mais util
 
 Quando se trata de unidades baseadas em espaço físico, a unidade `cm` (centímetro) é de longe a mais popular, seguida por `in` (polegadas) e, em seguida, `Q`. . Sabemos que esses tipos de unidades são especialmente úteis para folhas de estilo de impressão, mas nem sabíamos que a unidade `Q` existia até esta pesquisa! E você, sabia?
 
-<p class="note">Uma versão anterior deste capítulo discutiu a popularidade inesperada da unidade <code>Q</code>. Graças à  <a hreflang="en" href="https://discuss.httparchive.org/t/chapter-2-css/1757/6">discussão da comunidade</a> em torno deste capítulo, identificamos que isso foi um erro em nossa análise e atualizamos a Figura 2.5 de acordo.</p>
+<aside class="note">Uma versão anterior deste capítulo discutiu a popularidade inesperada da unidade <code>Q</code>. Graças à  <a hreflang="en" href="https://discuss.httparchive.org/t/chapter-2-css/1757/6">discussão da comunidade</a> em torno deste capítulo, identificamos que isso foi um erro em nossa análise e atualizamos a Figura 2.5 de acordo.</aside>
 
 ### Unidades baseadas na visualização
 
diff --git a/src/content/pt/2019/ecommerce.md b/src/content/pt/2019/ecommerce.md
index 16517c99f86..8684c1cd3ae 100644
--- a/src/content/pt/2019/ecommerce.md
+++ b/src/content/pt/2019/ecommerce.md
@@ -445,7 +445,7 @@ Os tamanhos da carga útil do HTML móvel não são muito diferentes dos do desk
   )
 }}
 
-<p class="note">Observe que, como nossa <a href="./methodology">metodologia</a> de coleta de dados não simula as interações do usuário em páginas como clicar ou rolar, as imagens com carregamento lento não seriam representadas nesses resultados.</p>
+<aside class="note">Observe que, como nossa <a href="./methodology">metodologia</a> de coleta de dados não simula as interações do usuário em páginas como clicar ou rolar, as imagens com carregamento lento não seriam representadas nesses resultados.</aside>
 
 As Figuras 13.12 e 13.13 acima mostram que a página média de comércio eletrônico tem 37 imagens e uma carga útil de imagens de 1.517 KB no celular, 40 imagens e 1.524 KB no desktop. 10% das páginas iniciais têm 90 ou mais imagens e uma carga útil de imagem de quase 6 MB!
 
@@ -472,7 +472,7 @@ Precisamos fazer mais análises para entender melhor por que alguns sites não e
   )
 }}
 
-<p class="note">Observe que alguns serviços de imagem ou CDNs entregarão automaticamente WebP (em vez de JPEG ou PNG) para plataformas que suportam WebP, mesmo para uma URL com sufixo `.jpg` ou `.png`. Por exemplo, <a hreflang="en" href="https://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg">IMG_20190113_113201.jpg</a> retorna uma imagem WebP no Chrome. No entanto, a maneira como o HTTP Archive <a hreflang="en" href="https://github.com/HTTPArchive/legacy.httparchive.org/blob/31a25b9064a365d746d4811a1d6dda516c0e4985/bulktest/batch_lib.inc#L994">detecta o formato da imagem como o texto original é</a> e verificar primeiro as palavras-chave no tipo MIME e, em seguida, recorrer à extensão do arquivo. Isso significa que o formato para imagens com URLs como o acima será fornecido como WebP, uma vez que WebP é suportado pelo HTTP Archive como um agente de usuário.</p>
+<aside class="note">Observe que alguns serviços de imagem ou CDNs entregarão automaticamente WebP (em vez de JPEG ou PNG) para plataformas que suportam WebP, mesmo para uma URL com sufixo `.jpg` ou `.png`. Por exemplo, <a hreflang="en" href="https://res.cloudinary.com/webdotdev/f_auto/w_500/IMG_20190113_113201.jpg">IMG_20190113_113201.jpg</a> retorna uma imagem WebP no Chrome. No entanto, a maneira como o HTTP Archive <a hreflang="en" href="https://github.com/HTTPArchive/legacy.httparchive.org/blob/31a25b9064a365d746d4811a1d6dda516c0e4985/bulktest/batch_lib.inc#L994">detecta o formato da imagem como o texto original é</a> e verificar primeiro as palavras-chave no tipo MIME e, em seguida, recorrer à extensão do arquivo. Isso significa que o formato para imagens com URLs como o acima será fornecido como WebP, uma vez que WebP é suportado pelo HTTP Archive como um agente de usuário.</aside>
 
 ### PNG
 
diff --git a/src/content/pt/2019/javascript.md b/src/content/pt/2019/javascript.md
index 7a727b78c5c..d0d596460bd 100644
--- a/src/content/pt/2019/javascript.md
+++ b/src/content/pt/2019/javascript.md
@@ -299,7 +299,7 @@ Outras bibliotecas JavaScript comumente usadas incluem variantes jQuery (jQuery
 
 ### Frameworks e bibliotecas de UI
 
-<p class="note">Conforme mencionado em nossa <a href="./methodology#wappalyzer">metodologia</a>, a biblioteca de detecção de terceiros usada no HTTP Archive (Wappalyzer) tem uma série de limitações com relação à maneira como detecta certas ferramentas. Há um problema aberto <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/issues/2450">para melhorar a detecção de bibliotecas e frameworks JavaScript</a>, que terá impactado os resultados apresentados aqui.</p>
+<aside class="note">Conforme mencionado em nossa <a href="./methodology#wappalyzer">metodologia</a>, a biblioteca de detecção de terceiros usada no HTTP Archive (Wappalyzer) tem uma série de limitações com relação à maneira como detecta certas ferramentas. Há um problema aberto <a hreflang="en" href="https://github.com/AliasIO/wappalyzer/issues/2450">para melhorar a detecção de bibliotecas e frameworks JavaScript</a>, que terá impactado os resultados apresentados aqui.</aside>
 
 Nos últimos anos, o ecossistema JavaScript tem visto um aumento em bibliotecas e frameworks de código aberto para facilitar a construção de **aplicativos de página única** (SPAs por sua sigla em Inglês). Um aplicativo de página única é caracterizado como uma página da web que carrega uma única página HTML e usa JavaScript para modificar a página na interação do usuário em vez de procurar novas páginas no servidor. Embora essa continue sendo a premissa principal dos aplicativos de página única, diferentes abordagens de renderização de servidor ainda podem ser usadas para aprimorar a experiência de tais sites. Quantos sites usam este tipo de framework?
 
diff --git a/src/content/pt/2019/resource-hints.md b/src/content/pt/2019/resource-hints.md
index aa3f8cc4e53..8ff2656e57e 100644
--- a/src/content/pt/2019/resource-hints.md
+++ b/src/content/pt/2019/resource-hints.md
@@ -66,7 +66,7 @@ Como o uso de dicas de recursos em cabeçalhos HTTP é muito baixo, o restante d
 
 ## Dicas de recursos
 
-<p class="note">Observação: não houve diferença perceptível entre os padrões de uso de dicas de recursos em dispositivos móveis e computadores. Assim, para fins de concisão, este capítulo inclui apenas as estatísticas para dispositivos móveis.</p>
+<aside class="note">Observação: não houve diferença perceptível entre os padrões de uso de dicas de recursos em dispositivos móveis e computadores. Assim, para fins de concisão, este capítulo inclui apenas as estatísticas para dispositivos móveis.</aside>
 
 <figure>
   <table>
diff --git a/src/content/pt/2020/css.md b/src/content/pt/2020/css.md
index cb260c2f072..154094fe025 100644
--- a/src/content/pt/2020/css.md
+++ b/src/content/pt/2020/css.md
@@ -48,7 +48,7 @@ Para algumas métricas, olhar para o AST CSS não foi suficiente. Queríamos olh
 
 Custom metrics também foram usadas para parte da análise de <a href="#propriedades-customizadas">propriedades customizadas</a>. Embora possamos obter muitas informações sobre o uso de propriedades customizadas apenas com as folhas de estilo, não podemos construir um gráfico de dependência sem ser capaz de olhar para o contexto da árvore DOM, pois as propriedades customizadas são herdadas. Observar o estilo computado dos nós da DOM também nos dá informações de quais tipos de elementos cada propriedade é aplicada e quais deles estão [registrados](https://developer.mozilla.org/docs/Web/API/CSS/RegisterProperty) - informações que também não podemos obter nas folhas de estilo.
 
-<p class="note">Rastreamos nossas páginas tanto no modo desktop quanto no modo celular, mas para a maioria dos dados eles fornecem resultados semelhantes, portanto, a menos que seja indicado de outra forma, as estatísticas apresentadas neste capítulo referem-se ao conjunto de páginas no celular.</p>
+<aside class="note">Rastreamos nossas páginas tanto no modo desktop quanto no modo celular, mas para a maioria dos dados eles fornecem resultados semelhantes, portanto, a menos que seja indicado de outra forma, as estatísticas apresentadas neste capítulo referem-se ao conjunto de páginas no celular.</aside>
 
 ## Uso
 
diff --git a/src/content/pt/2022/cdn.md b/src/content/pt/2022/cdn.md
index 6706c7e9993..0d8cee41acf 100644
--- a/src/content/pt/2022/cdn.md
+++ b/src/content/pt/2022/cdn.md
@@ -274,7 +274,7 @@ Apesar da empolgação em torno do HTTP/2 e a promessa de redução de latência
 
 As CDNs atuam como um proxy para preencher a lacuna, fornecendo uma camada para consolidar nomes de host e roteando o tráfego para os pontos finais relevantes com mudanças mínimas em sua infraestrutura de hospedagem. Recursos como priorização de conteúdo na fila e push do servidor podem ser gerenciados do lado das CDNs e algumas CDNs até fornecem soluções automatizadas para executar esses recursos sem qualquer input dos proprietários dos sites, oferecendo assim um impulso para a adoção do HTTP/2.
 
-<p class="note">Observe que, devido ao funcionamento do HTTP/3 (veja o capítulo sobre [HTTP](./http) para mais informações), o HTTP/3 frequentemente não é utilizado para conexões iniciais. Por isso, estamos medindo "HTTP/2+", já que muitas dessas conexões HTTP/2 podem, na verdade, ser HTTP/3 para visitantes recorrentes (presumimos que nenhum servidor implementa HTTP/3 sem HTTP/2).</p>
+<aside class="note">Observe que, devido ao funcionamento do HTTP/3 (veja o capítulo sobre [HTTP](./http) para mais informações), o HTTP/3 frequentemente não é utilizado para conexões iniciais. Por isso, estamos medindo "HTTP/2+", já que muitas dessas conexões HTTP/2 podem, na verdade, ser HTTP/3 para visitantes recorrentes (presumimos que nenhum servidor implementa HTTP/3 sem HTTP/2).</aside>
 
 {{ figure_markup(
   image="cdn-http-versions-mobile.png",
diff --git a/src/content/ru/2020/css.md b/src/content/ru/2020/css.md
index d97fecab69e..1454fe149aa 100644
--- a/src/content/ru/2020/css.md
+++ b/src/content/ru/2020/css.md
@@ -48,7 +48,7 @@ featured_stat_label_3: Самая популярная функция в SCSS
 
 Кастомные метрики также были использованы для части [анализа кастомных свойств](#custom-properties). Хотя мы и можем получить много информации о том, как используются кастомные свойства, прямо из таблиц стилей, мы не можем построить граф зависимостей без возможности смотреть на DOM-дерево для контекста, так как кастомные свойства наследуются. Исследование вычисленных стилей для DOM-узлов также даёт нам информацию вроде типов элементов, к которым каждое из свойств применяется, и какие из них [зарегистрированы](https://developer.mozilla.org/docs/Web/API/CSS/RegisterProperty) — данные, которые тоже не могут быть получены из таблиц стилей.<!-- markdownlint-disable-line MD051 -->
 
-<p class="note">Мы краулили наши страницы одновременно и в десктопном режиме, и в мобильном, но для многих данных они дают одинаковые результаты, поэтому, если не указано иное, статистика в этой главе относится к набору мобильных страниц.</p>
+<aside class="note">Мы краулили наши страницы одновременно и в десктопном режиме, и в мобильном, но для многих данных они дают одинаковые результаты, поэтому, если не указано иное, статистика в этой главе относится к набору мобильных страниц.</aside>
 
 ## Применение {usage}
 
diff --git a/src/content/ru/2021/pwa.md b/src/content/ru/2021/pwa.md
index 1ecbd447b6c..a87bde1c86a 100644
--- a/src/content/ru/2021/pwa.md
+++ b/src/content/ru/2021/pwa.md
@@ -40,7 +40,7 @@ featured_stat_label_3: Процент мобильных сайтов с сер
 В главе о PWA этого года мы сосредоточимся на всех измеримых аспектах PWA: использовании сервис-воркеров и связанных с ними API, манифестах веб-приложений, а также наиболее популярных библиотеках и инструментах для создания PWA. PWA может использовать все или некоторые из этих функций. Мы рассмотрим уровень внедрения каждого компонента и API, чтобы получить представление об уровне проникновения этих технологий в веб-экосистему.
 
 
-<p class="note">**Примечание:** в этой главе основное внимание будет уделено наиболее часто используемым API, связанным с сервис-воркерами. Чтобы узнать о других передовых API, обязательно ознакомьтесь с главой <a href="./capabilities">Возможности</a>.</p>
+<aside class="note">**Примечание:** в этой главе основное внимание будет уделено наиболее часто используемым API, связанным с сервис-воркерами. Чтобы узнать о других передовых API, обязательно ознакомьтесь с главой <a href="./capabilities">Возможности</a>.</aside>
 
 ## Сервис-воркеры {service-workers}
 
@@ -153,7 +153,7 @@ this.oninstall = function(event) {
 
 Несмотря на это, есть несколько важных причин для применения фоновой синхронизации в современных веб-приложениях: одна из них — офлайн-аналитика (<a hreflang="en" href="https://developers.google.com/web/tools/workbox/modules/workbox-google-analytics">Workbox Analytics использует для этого фоновую синхронизацию</a>), вторая — повтор неудачных запросов из-за отсутствия подключения (как <a hreflang="en" href="https://web.dev/google-search-sw/">делают некоторые поисковики</a>).
 
-<p class="note">**Примечание:** в отличие от предыдущих лет, мы решили не включать в этот анализ события `fetch` и `message`, поскольку они также могут появляться вне сервис-воркеров, что может привести к высокому количеству ложных срабатываний. Поэтому приведённый выше анализ относится к событиям, специфичным для сервис-воркеров. <a hreflang="en" href="../2020/pwa#service-worker-events">Согласно данным за 2020 год, `fetch` использовался почти столько же, сколько `install`.</a></p>
+<aside class="note">**Примечание:** в отличие от предыдущих лет, мы решили не включать в этот анализ события `fetch` и `message`, поскольку они также могут появляться вне сервис-воркеров, что может привести к высокому количеству ложных срабатываний. Поэтому приведённый выше анализ относится к событиям, специфичным для сервис-воркеров. <a hreflang="en" href="../2020/pwa#service-worker-events">Согласно данным за 2020 год, `fetch` использовался почти столько же, сколько `install`.</a></aside>
 
 #### Другие популярные функции сервис-воркеров {other-popular-service-worker-features}
 
@@ -313,7 +313,7 @@ this.oninstall = function(event) {
 
 Несмотря на то, что подавляющее большинство разработчиков PWA предпочитают продвигать свой PWA вместо нативных приложений, некоторые известные PWA (например, Twitter) по-прежнему предпочитают рекомендовать нативное приложение, а не PWA. Это может быть связано с предпочтениями команд, создающих эти приложения, или с некоторыми конкретными бизнес-потребностями (отсутствие некоторых API в вебе).
 
-<p class="note">**Примечание:** вместо того, чтобы принимать это решение статически во время настройки, разработчики также могут <a hreflang="en" href="https://web.dev/define-install-strategy/">создавать более динамические эвристики</a> для продвижения приложения, например, основанные на поведении пользователя или других характеристиках (устройство, соединение, местоположение и т.д.).</p>
+<aside class="note">**Примечание:** вместо того, чтобы принимать это решение статически во время настройки, разработчики также могут <a hreflang="en" href="https://web.dev/define-install-strategy/">создавать более динамические эвристики</a> для продвижения приложения, например, основанные на поведении пользователя или других характеристиках (устройство, соединение, местоположение и т.д.).</aside>
 
 ### Самые популярные категории манифеста {top-manifest-categories}
 
@@ -398,8 +398,8 @@ Workbox по-прежнему остаётся самой популярной 
 
 Также важно отметить, что предшественник Workbox `sw_toolbox`, который имел <a hreflang="en" href="../2020/pwa#popular-import-scripts">13,92% использования на десктопах и 12,84% на мобильных устройствах в прошлом году</a>, упал до 0,51% и 0,36% соответственно в этом году. Отчасти это связано с тем, что `sw_toolbox` был <a hreflang="en" href="https://github.com/GoogleChromeLabs/sw-toolbox/pull/288">признан устаревшим в 2019 году</a>. Некоторым популярным фреймворкам и инструментам сборки, возможно, потребовалось некоторое время, чтобы удалить этот пакет, поэтому в этом году мы более отчетливо наблюдаем снижение числа пользователей. Кроме того, наши измерения изменились по сравнению с 2020 годом из-за добавления большего количества сайтов, что ещё больше уменьшило этот показатель и затруднило прямое сравнение год-к-году.
 
-<p class="note">**Примечание:** учтите, что [`importScripts()`](https://developer.mozilla.org/docs/Web/API/WorkerGlobalScope/importScripts) представляет собой API из [`WorkerGlobalScope`](https://developer.mozilla.org/docs/Web/API/WorkerGlobalScope), который можно использовать в других типах контекста воркера, вроде [веб-воркеров](https://developer.mozilla.org/docs/Web/API/Web_Workers_API/Using_web_workers). <a hreflang="en" href="https://www.google.com/recaptcha/about/">reCaptcha</a>, например, является второй по популярности библиотекой, поскольку в ней используется веб-воркер, который содержит вызов `importScripts()` для получения JavaScript-кода reCaptcha. По этой причине мы должны рассматривать <a href="https://firebase.google.com/docs/web/setup">Firebase</a> как вторую по популярности библиотеку в контексте сервис-воркеров.
-</p>
+<aside class="note">**Примечание:** учтите, что [`importScripts()`](https://developer.mozilla.org/docs/Web/API/WorkerGlobalScope/importScripts) представляет собой API из [`WorkerGlobalScope`](https://developer.mozilla.org/docs/Web/API/WorkerGlobalScope), который можно использовать в других типах контекста воркера, вроде [веб-воркеров](https://developer.mozilla.org/docs/Web/API/Web_Workers_API/Using_web_workers). <a hreflang="en" href="https://www.google.com/recaptcha/about/">reCaptcha</a>, например, является второй по популярности библиотекой, поскольку в ней используется веб-воркер, который содержит вызов `importScripts()` для получения JavaScript-кода reCaptcha. По этой причине мы должны рассматривать <a href="https://firebase.google.com/docs/web/setup">Firebase</a> как вторую по популярности библиотеку в контексте сервис-воркеров.
+</aside>
 
 ### Использование Workbox {workbox-usage}
 
@@ -501,7 +501,7 @@ Workbox по-прежнему остаётся самой популярной 
 <!-- markdownlint-disable-next-line MD051 -->
 Интерфейс сервис-воркера также позволяет прослушивать некоторые события для обработки пользовательских взаимодействий с уведомлениями. [График 16.4](#fig-4) показывает, что `notificationclick` (который захватывает клики по уведомлениям) используется в 45,64% десктопных и 46,62% мобильных PWA. `notificationclose` используется реже: в 5,98% настольных и 6,34% мобильных PWA. Это ожидаемо, поскольку существует меньше вариантов применения, в которых имеет смысл прослушивать событие «закрытия» уведомления, чем для «кликов» по уведомлению.
 
-<p class="note">**Примечание:** интересно видеть, что в событиях уведомлений сервис-воркера (например, `push`, `notificationclick`) ещё больше используется свойство `pushManager`, которое применяется, например, чтобы запросить разрешение на push-уведомления (через `pushManager.subscribe`). Одна из причин этого может заключаться в том, что некоторые сайты реализовали веб-пуши и решили в какой-то момент откатить их, убрав код для запроса разрешения на них, но оставив код сервис-воркера без изменений.</p>
+<aside class="note">**Примечание:** интересно видеть, что в событиях уведомлений сервис-воркера (например, `push`, `notificationclick`) ещё больше используется свойство `pushManager`, которое применяется, например, чтобы запросить разрешение на push-уведомления (через `pushManager.subscribe`). Одна из причин этого может заключаться в том, что некоторые сайты реализовали веб-пуши и решили в какой-то момент откатить их, убрав код для запроса разрешения на них, но оставив код сервис-воркера без изменений.</aside>
 
 ### Показатели принятия пуш-нотификаций {web-push-notification-acceptance-rates}
 
diff --git a/src/content/zh-CN/2019/accessibility.md b/src/content/zh-CN/2019/accessibility.md
index da821f8ab75..140f9013882 100644
--- a/src/content/zh-CN/2019/accessibility.md
+++ b/src/content/zh-CN/2019/accessibility.md
@@ -57,7 +57,7 @@ featured_stat_label_3: 使用跳过链接的网站
 
 只有22.04%的网站给所有的文本提供了足够的颜色对比。或换句话说：每5个网站中就有4个网站的文字很容易和背景融合，导致难以阅读。
 
-<p class="note">请注意，我们无法分析图像中的任何文本，因此我们报告的指标是通过颜色对比测试的网站总数的上限。</p>
+<aside class="note">请注意，我们无法分析图像中的任何文本，因此我们报告的指标是通过颜色对比测试的网站总数的上限。</aside>
 
 ### 缩放页面
 
diff --git a/src/content/zh-CN/2019/performance.md b/src/content/zh-CN/2019/performance.md
index 22be2958a94..b1d0a1f5244 100644
--- a/src/content/zh-CN/2019/performance.md
+++ b/src/content/zh-CN/2019/performance.md
@@ -60,7 +60,7 @@ featured_stat_label_3: 有快速FID的站点
 
 在上面的图7.1中，您可以看到FCP体验是如何在Web上分布的。这个图表从CrUX数据集里面的数百万个网站之中，将分布缩减到1,000个网站，其中每个垂直切片代表一个站点。该图表按快速FCP的百分比排序，快速FCP体验是1秒之内发生的。慢速的体验会在3秒或更长时间内发生，而中速的体验（以前称为“平均”）介于两者之间。在图表的极端情况下，有些网站拥有近100％的快速体验，而有些网站则具有近100％的慢速体验。在这两者之间，兼具快速，中速和慢速性能的网站似乎更倾向于快速或中速，而不是慢速，这很好。
 
-<p class="note">注意：当用户的性能下降时，很难说出原因是什么。网站本身可能设计得很差且效率低下。或可能存在其他环境因素，例如用户的连接速度慢，没有缓存等。因此，在查看该现场数据时，我们更倾向于说用户自身的体验缓慢，而不一定是网站。</p>
+<aside class="note">注意：当用户的性能下降时，很难说出原因是什么。网站本身可能设计得很差且效率低下。或可能存在其他环境因素，例如用户的连接速度慢，没有缓存等。因此，在查看该现场数据时，我们更倾向于说用户自身的体验缓慢，而不一定是网站。</aside>
 
 为了对网站是否足够**快速**进行分类，我们将使用新的<a hreflang="en" href="https://developers.google.com/speed/docs/insights/v5/about#categories">PageSpeed Insights</a> (PSI) 方法，其中至少有75％的网站FCP体验必须快于1秒。同样，一个足够**慢速**的网站具有25％或更多的FCP体验慢于3秒。我们说一个网站不符合以上两个条件时，它们的性能就是**中速**。
 
diff --git a/src/content/zh-CN/2022/security.md b/src/content/zh-CN/2022/security.md
index 99b8f400859..7c0bc374e6d 100644
--- a/src/content/zh-CN/2022/security.md
+++ b/src/content/zh-CN/2022/security.md
@@ -634,7 +634,7 @@ CDNs 对子资源完整性并不陌生，通过在页面内容的 URL 引用中
 
 在移动端的 1740 万个框架中，有 12.6% 包含 `allow` 属性，以启用权限或特性策略。
 
-<p class="note">本章的早期版本报告了总帧数和具有 `allow` 属性的帧百分比的错误值。更多信息可在此 <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> 中找到。</p>
+<aside class="note">本章的早期版本报告了总帧数和具有 `allow` 属性的帧百分比的错误值。更多信息可在此 <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> 中找到。</aside>
 
 以下是在框架中检测到的前 10 条 `allow` 指令列表：
 
@@ -741,7 +741,7 @@ function clickToGo() {
 
 对于桌面网站上的所有 iframe，21.08％ 具有 `sandbox` 属性。
 
-<p class="note">本章的早期版本报告了具有 `sandbox` 属性的帧百分比不正确。更多信息可在此 <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> 中找到。</p>
+<aside class="note">本章的早期版本报告了具有 `sandbox` 属性的帧百分比不正确。更多信息可在此 <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/pull/3912">GitHub PR</a> 中找到。</aside>
 
 我们发现包含 `sandbox` 指令的 `Content-Security-Policy` 标头在移动端仅占 0.3% 的使用率（桌面端为 0.4%），这可能说明了这样一个事实，即该属性仅适用于在页面中嵌入 iframe 内容的实践，而不是通过内容安全策略定义进行预先规划。
 
diff --git a/src/templates/en/2019/methodology.html b/src/templates/en/2019/methodology.html
index 06098268747..ce812a70bc1 100644
--- a/src/templates/en/2019/methodology.html
+++ b/src/templates/en/2019/methodology.html
@@ -74,9 +74,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">About the dataset</a></h
           All of the metrics presented in the Web Almanac are publicly reproducible using the dataset on BigQuery. You can browse the queries used by all chapters in our <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2019">GitHub repository</a>.
         </p>
 
-        <p class="note">
+        <aside class="note">
           Please note that some of these queries are quite large and can be <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">expensive</a> to run yourself, as BigQuery is billed by the terabyte. For help controlling your spending, refer to Tim Kadlec&#8217;s post <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Using BigQuery Without Breaking the Bank</a>.
-        </p>
+        </aside>
 
         <p>
           For example, to understand the median number of bytes of JavaScript per desktop and mobile page, see <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a>:
@@ -286,9 +286,9 @@ <h3 id="lighthouse"><a href="#lighthouse" class="anchor-link">Lighthouse</a></h3
       </table>
       </div></div>
 
-      <p class="note">
+      <aside class="note">
         * Note that Lighthouse is normally configured to have a CPU slowdown of 4x, but due to a <a hreflang="en" href="https://github.com/GoogleChrome/lighthouse/issues/9668#issuecomment-535134232">bug</a> in WebPageTest, this was 1x at the time of the tests.
-      </p>
+      </aside>
 
       <p>
         For more information about Lighthouse and the audits available in HTTP Archive, refer to the <a hreflang="en" href="https://developers.google.com/web/tools/lighthouse/">Lighthouse developer documentation</a>.
diff --git a/src/templates/en/2020/methodology.html b/src/templates/en/2020/methodology.html
index 39e0168dd30..5cd79e32ed8 100644
--- a/src/templates/en/2020/methodology.html
+++ b/src/templates/en/2020/methodology.html
@@ -79,9 +79,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">About the dataset</a></h
           All of the metrics presented in the Web Almanac are publicly reproducible using the dataset on BigQuery. You can browse the queries used by all chapters in our <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2020">GitHub repository</a>.
         </p>
 
-        <p class="note">
+        <aside class="note">
           Please note that some of these queries are quite large and can be <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">expensive</a> to run yourself, as BigQuery is billed by the terabyte. For help controlling your spending, refer to Tim Kadlec&#8217;s post <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Using BigQuery Without Breaking the Bank</a>.
-        </p>
+        </aside>
 
         <p>
           For example, to understand the median number of bytes of JavaScript per desktop and mobile page, see <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a>:
diff --git a/src/templates/en/2021/methodology.html b/src/templates/en/2021/methodology.html
index 6cacf2c2d36..fd097202d82 100644
--- a/src/templates/en/2021/methodology.html
+++ b/src/templates/en/2021/methodology.html
@@ -80,9 +80,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">About the dataset</a></h
           All of the metrics presented in the Web Almanac are publicly reproducible using the dataset on BigQuery. You can browse the queries used by all chapters in our <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/{{ year }}">GitHub repository</a>.
         </p>
 
-        <p class="note">
+        <aside class="note">
           Please note that some of these queries are quite large and can be <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">expensive</a> to run yourself. For help controlling your spending, refer to Tim Kadlec&#8217;s post <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Using BigQuery Without Breaking the Bank</a>.
-        </p>
+        </aside>
 
         <p>
           For example, to understand the median number of bytes of JavaScript per desktop and mobile page, see <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2021/javascript/bytes_2021.sql">bytes_2021.sql</a>:
diff --git a/src/templates/en/2022/methodology.html b/src/templates/en/2022/methodology.html
index 76dbf5d0344..de2f734f096 100644
--- a/src/templates/en/2022/methodology.html
+++ b/src/templates/en/2022/methodology.html
@@ -80,9 +80,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">About the dataset</a></h
           All of the metrics presented in the Web Almanac are publicly reproducible using the dataset on BigQuery. You can browse the queries used by all chapters in our <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/{{ year }}">GitHub repository</a>.
         </p>
 
-        <p class="note">
+        <aside class="note">
           Please note that some of these queries are quite large and can be <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">expensive</a> to run yourself. For help controlling your spending, refer to Tim Kadlec&#8217;s post <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Using BigQuery Without Breaking the Bank</a>.
-        </p>
+        </aside>
 
         <p>
           For example, to understand the median number of bytes of JavaScript per desktop and mobile page, see <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2022/javascript/bytes_2022.sql">bytes_2022.sql</a>:
diff --git a/src/templates/en/2024/methodology.html b/src/templates/en/2024/methodology.html
index c3da0f341c6..eaacc32fb91 100644
--- a/src/templates/en/2024/methodology.html
+++ b/src/templates/en/2024/methodology.html
@@ -80,9 +80,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">About the dataset</a></h
           All of the metrics presented in the Web Almanac are publicly reproducible using the dataset on BigQuery. You can browse the queries used by all chapters in our <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/{{ year }}">GitHub repository</a>.
         </p>
 
-        <p class="note">
+        <aside class="note">
           Please note that some of these queries are quite large and can be <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">expensive</a> to run yourself. For help controlling your spending, refer to Tim Kadlec&#8217;s post <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Using BigQuery Without Breaking the Bank</a>.
-        </p>
+        </aside>
 
         <p>
           For example, to understand the median number of bytes of JavaScript per desktop and mobile page, see <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2024/javascript/bytes_2024.sql">bytes_2024.sql</a>:
diff --git a/src/templates/fr/2019/methodology.html b/src/templates/fr/2019/methodology.html
index 009bbd0424a..c8c97bd12d5 100644
--- a/src/templates/fr/2019/methodology.html
+++ b/src/templates/fr/2019/methodology.html
@@ -74,9 +74,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">À propos du jeu de donn
         Toutes les statistiques présentées dans le Web Almanac sont reproductibles publiquement à l’aide de l’ensemble de données sur BigQuery. Vous pouvez parcourir les requêtes utilisées par tous les chapitres dans notre <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2019">dépôt GitHub</a>.
         </p>
 
-        <p class="note">
+        <aside class="note">
           Veuillez noter que certaines de ces requêtes sont assez volumineuses et peuvent être <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">coûteuses</a> à exécuter par vous-même, dans la mesure où BigQuery facture au téraoctet. Pour vous aider à contrôler vos dépenses, consultez l'article de blog de Tim Kadlec <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Utiliser BigQuery sans faire sauter la banque (en anglais)</a>.
-        </p>
+        </aside>
 
         <p>
         Par exemple, pour obtenir le nombre médian d’octets de JavaScript servis sur les pages pour ordinateurs de bureau et périphériques mobiles, regardez <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a>:
@@ -286,9 +286,9 @@ <h3 id="lighthouse"><a href="#lighthouse" class="anchor-link">Lighthouse</a></h3
       </table>
       </div></div>
 
-      <p class="note">
+      <aside class="note">
         * Notez que Lighthouse est normalement configuré pour avoir un ralentissement CPU de 4x, mais en raison d’un <a hreflang="en" href="https://github.com/GoogleChrome/lighthouse/issues/9668#issuecomment-535134232">bug</a> dans WebPageTest, il était de 1x au moment des tests.
-      </p>
+      </aside>
 
       <p>
         Pour plus d’informations sur Lighthouse et les audits disponibles dans HTTP Archive, reportez-vous à la section <a hreflang="en" href="https://developers.google.com/web/tools/lighthouse/">documentation de Lighthouse relative au développement</a>.
diff --git a/src/templates/fr/2020/methodology.html b/src/templates/fr/2020/methodology.html
index 17d3c628889..144da8d9d1a 100644
--- a/src/templates/fr/2020/methodology.html
+++ b/src/templates/fr/2020/methodology.html
@@ -79,9 +79,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">À propos du jeu de donn
           Toutes les statistiques présentées dans le Web Almanac sont reproductibles publiquement à l’aide de l’ensemble de données sur BigQuery. Vous pouvez parcourir les requêtes utilisées par tous les chapitres dans notre <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2020">dépôt GitHub</a>.
         </p>
 
-        <p class="note">
+        <aside class="note">
           Veuillez noter que certaines de ces requêtes sont assez volumineuses et peuvent être <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">coûteuses</a> à exécuter par vous-même, dans la mesure où BigQuery facture au téraoctet. Pour vous aider à contrôler vos dépenses, consultez l’article de blog de Tim Kadlec <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Utiliser BigQuery sans faire sauter la banque (en anglais)</a>.
-        </p>
+        </aside>
 
         <p>
           Par exemple, pour obtenir le nombre médian d’octets de JavaScript servis sur les pages pour ordinateurs de bureau et périphériques mobiles, regardez <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a>:
diff --git a/src/templates/hi/2019/methodology.html b/src/templates/hi/2019/methodology.html
index b9c74fb614d..011bb0bb8c1 100644
--- a/src/templates/hi/2019/methodology.html
+++ b/src/templates/hi/2019/methodology.html
@@ -74,9 +74,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">डेटासेट 
           Web Almanac में प्रस्तुत सभी मैट्रिक्स BigQuery पर डेटासेट का उपयोग कर सार्वजनिक रूप से प्रतिलिपि प्रस्तुत करने योग्य हैं। आप हमारी <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2019">GitHub रिपॉजिटरी</a> में सभी अध्यायों द्वारा उपयोग किए गए क्वेरी को देख सकते हैं।
         </p>
 
-        <p class="note">
+        <aside class="note">
           कृपया ध्यान दें कि इनमें से कुछ क्वेरी काफी विशाल हैं और आप के प्रयोग के लिए <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">महंगे</a> हो सकते हैं, क्योंकि BigQuery को टेराबाइट द्वारा बिल किया जाता है। अपने खर्च को नियंत्रित करने में सहायता के लिए, टिम कडलेक की पोस्ट <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Using BigQuery Without Breaking the Bank</a> देखें।
-        </p>
+        </aside>
 
         <p>
           उदाहरण के लिए, डेस्कटॉप और मोबाइल पेज पर JavaScript बाइट्स की औसत संख्या को समझने के लिए, <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a> देखें:
@@ -286,9 +286,9 @@ <h3 id="lighthouse"><a href="#lighthouse" class="anchor-link">Lighthouse</a></h3
       </table>
       </div></div>
 
-      <p class="note">
+      <aside class="note">
         * ध्यान दें कि Lighthouse आमतौर पर 4x की सीपीयू मंदी के लिए कॉन्फ़िगर किया गया है, लेकिन WebPageTest में एक <a hreflang="en" href="https://github.com/GoogleChrome/lighthouse/issues/9668#issuecomment-535134232">बग</a> के कारण, यह परीक्षण के समय 1x था।
-      </p>
+      </aside>
 
       <p>
         Lighthouse और HTTP Archive में उपलब्ध ऑडिट के बारे में अधिक जानकारी के लिए, <a hreflang="en" href="https://developers.google.com/web/tools/lighthouse/">Lighthouse डेवलपर प्रलेखन</a> देखें।
diff --git a/src/templates/hi/2020/methodology.html b/src/templates/hi/2020/methodology.html
index da5d9828214..f428b3d2f8c 100644
--- a/src/templates/hi/2020/methodology.html
+++ b/src/templates/hi/2020/methodology.html
@@ -79,9 +79,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">डेटासेट 
           Web Almanac में प्रस्तुत सभी मैट्रिक्स BigQuery पर डेटासेट का उपयोग कर सार्वजनिक रूप से प्रतिलिपि प्रस्तुत करने योग्य हैं। आप हमारी <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2020">GitHub रिपॉजिटरी</a> में सभी अध्यायों द्वारा उपयोग किए गए क्वेरी को देख सकते हैं।
         </p>
 
-        <p class="note">
+        <aside class="note">
           कृपया ध्यान दें कि इनमें से कुछ क्वेरी काफी विशाल हैं और आप के प्रयोग के लिए <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">महंगे</a> हो सकते हैं, क्योंकि BigQuery को टेराबाइट द्वारा बिल किया जाता है। अपने खर्च को नियंत्रित करने में सहायता के लिए, टिम कडलेक की पोस्ट <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Using BigQuery Without Breaking the Bank</a> देखें।
-        </p>
+        </aside>
 
         <p>
           उदाहरण के लिए, डेस्कटॉप और मोबाइल पेज पर JavaScript बाइट्स की औसत संख्या को समझने के लिए, <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a> देखें:
diff --git a/src/templates/ja/2019/methodology.html b/src/templates/ja/2019/methodology.html
index c89bd4c012a..8f527ecdbd0 100644
--- a/src/templates/ja/2019/methodology.html
+++ b/src/templates/ja/2019/methodology.html
@@ -74,9 +74,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">データセットにつ
           Web Almanacで紹介されているすべてのメトリクスは、BigQuery上のデータセットを使用して一般に再現可能です。すべての章で使用されているクエリは、<a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2019">GitHubリポジトリ</a>で閲覧できます。
         </p>
 
-        <p class="note">
+        <aside class="note">
           BigQueryはテラバイト単位で課金されるため、これらのクエリの中には非常に大規模なものもあり、自分で実行するには<a hreflang="en" href="https://cloud.google.com/bigquery/pricing">費用がかかる</a>可能性があることに注意してください。支出のコントロールについては、Tim Kadlec氏の投稿<a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Using BigQuery Without Breaking the Bank</a>を参照してください。
-        </p>
+        </aside>
 
         <p>
           例えば、デスクトップページとモバイルページあたりのJavaScriptのバイト数の中央値を把握するには、<a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a>を参照してください。
@@ -286,9 +286,9 @@ <h3 id="lighthouse"><a href="#lighthouse" class="anchor-link">Lighthouse</a></h3
       </table>
       </div></div>
 
-      <p class="note">
+      <aside class="note">
         * 注 Lighthouseは通常、CPUが4倍遅くなるように設定されていますが、WebPageTestの<a hreflang="en" href="https://github.com/GoogleChrome/lighthouse/issues/9668#issuecomment-535134232">バグ</a>のため、テスト時には1倍になっていました。
-      </p>
+      </aside>
 
       <p>
         LighthouseとHTTP Archiveで利用可能な監査の詳細については、<a hreflang="en" href="https://developers.google.com/web/tools/lighthouse/">Lighthouse開発者向けドキュメント</a>を参照してください。
diff --git a/src/templates/ja/2020/methodology.html b/src/templates/ja/2020/methodology.html
index f2b2294fb66..81fc4144a52 100644
--- a/src/templates/ja/2020/methodology.html
+++ b/src/templates/ja/2020/methodology.html
@@ -79,9 +79,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">データセットにつ
           Web Almanacで紹介されているすべてのメトリクスは、BigQuery上のデータセットを使用して一般に再現可能です。すべての章で使用されているクエリは、<a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2020">GitHubリポジトリ</a>で閲覧できます。
         </p>
 
-        <p class="note">
+        <aside class="note">
           BigQueryはテラバイト単位で課金されるため、これらのクエリの中には非常に大規模なものもあり、自分で実行するには<a hreflang="en" href="https://cloud.google.com/bigquery/pricing">費用がかかる</a>可能性があることに注意してください。支出のコントロールについては、Tim Kadlec氏の投稿<a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Using BigQuery Without Breaking the Bank</a>を参照してください。
-        </p>
+        </aside>
 
         <p>
           例えば、デスクトップページとモバイルページあたりのJavaScriptのバイト数の中央値を把握するには、<a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a>を参照してください。
diff --git a/src/templates/ja/2021/methodology.html b/src/templates/ja/2021/methodology.html
index 4d12792eb77..9495b827c45 100644
--- a/src/templates/ja/2021/methodology.html
+++ b/src/templates/ja/2021/methodology.html
@@ -80,9 +80,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">データセットにつ
           Web Almanacに掲載されているすべてのメトリクスは、BigQuery上のデータセットを使用して一般に再現可能です。<a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/{{ year }}">GitHub リポジトリ</a>で、すべての章で使われているクエリを閲覧できます。
         </p>
 
-        <p class="note">
+        <aside class="note">
           これらのクエリの中には非常に大きなものがあり、自分で実行すると<a hreflang="en" href="https://cloud.google.com/bigquery/pricing">高くつく</a>可能性があることに注意してください。出費を抑えるには、Tim Kadlecのポスト <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">BigQueryを低コストで利用する</a> を参照してください。
-        </p>
+        </aside>
 
         <p>
           たとえば、デスクトップとモバイルのページあたりのJavaScriptのバイト数の中央値を理解するには、<a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2021/javascript/bytes_2021.sql">bytes_2021.sql</a> をご覧ください。
diff --git a/src/templates/ja/2022/methodology.html b/src/templates/ja/2022/methodology.html
index 5213431a5e7..53a763a5c2f 100644
--- a/src/templates/ja/2022/methodology.html
+++ b/src/templates/ja/2022/methodology.html
@@ -80,9 +80,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">データセットにつ
           Web Almanacで提示されているすべての指標は、BigQuery上のデータセットを使用して公開再現可能です。すべての章で使用されたクエリは、<a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/{{ year }}">GitHubリポジトリ</a>で閲覧できます。
         </p>
 
-        <p class="note">
+        <aside class="note">
           これらのクエリの一部は非常に大きく、自分で実行する場合、<a hreflang="en" href="https://cloud.google.com/bigquery/pricing">高額</a>になる可能性がありますのでご注意ください。費用を抑える方法については、Tim Kadlec氏の投稿<a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Using BigQuery Without Breaking the Bank</a>を参照してください。
-        </p>
+        </aside>
 
         <p>
           たとえば、デスクトップおよびモバイルページごとのJavaScriptの中央値のバイト数を理解するには、<a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2022/javascript/bytes_2022.sql">bytes_2022.sql</a>を参照してください。
diff --git a/src/templates/nl/2019/methodology.html b/src/templates/nl/2019/methodology.html
index a489b8d929a..24321392918 100644
--- a/src/templates/nl/2019/methodology.html
+++ b/src/templates/nl/2019/methodology.html
@@ -74,9 +74,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">Over de dataset</a></h2>
           Alle statistieken die in de Web Almanac worden gepresenteerd, zijn openbaar reproduceerbaar met behulp van de dataset op BigQuery. U kunt bladeren door de zoekopdrachten die door alle hoofdstukken worden gebruikt in onze <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2019">GitHub-repository</a>.
         </p>
 
-        <p class="note">
+        <aside class="note">
           Houd er rekening mee dat sommige van deze zoekopdrachten vrij groot zijn en <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">duur</a> kunnen zijn om zelf uit te voeren, aangezien BigQuery wordt gefactureerd per terabyte. Raadpleeg, voor hulp bij het beheersen van uw uitgaven, Tim Kadlec&#8217;s bericht <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">BigQuery gebruiken zonder de Bank te breken</a>.
-        </p>
+        </aside>
 
         <p>
           Zie bijvoorbeeld <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a> voor meer informatie over het gemiddelde aantal bytes van JavaScript per desktop- en mobiele pagina:
@@ -286,9 +286,9 @@ <h3 id="lighthouse"><a href="#lighthouse" class="anchor-link" lang="en">Lighthou
       </table>
       </div></div>
 
-      <p class="note">
+      <aside class="note">
         * Merk op dat Lighthouse normaal gesproken is geconfigureerd om een CPU-vertraging van 4x te hebben, maar vanwege een <a hreflang="en" href="https://github.com/GoogleChrome/lighthouse/issues/9668#issuecomment-535134232">bug</a> in WebPageTest was dit 1x ten tijde van de testen.
-      </p>
+      </aside>
 
       <p>
         Raadpleeg de <a hreflang="en" href="https://developers.google.com/web/tools/lighthouse/">Lighthouse-documentatie voor ontwikkelaars</a> voor meer informatie over Lighthouse en de audits die beschikbaar zijn in HTTP Archive.
diff --git a/src/templates/nl/2020/methodology.html b/src/templates/nl/2020/methodology.html
index 247ff997c95..cfdf26d9ff1 100644
--- a/src/templates/nl/2020/methodology.html
+++ b/src/templates/nl/2020/methodology.html
@@ -79,9 +79,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">Over de dataset</a></h2>
           Alle statistieken die in de Web Almanac worden gepresenteerd, zijn openbaar reproduceerbaar met behulp van de dataset op BigQuery. U kunt door de zoekopdrachten bladeren die door alle hoofdstukken worden gebruikt in onze <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2020">GitHub-repository</a>.
         </p>
 
-        <p class="note">
+        <aside class="note">
           Houd er rekening mee dat sommige van deze zoekopdrachten vrij groot zijn en <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">duur</a> kunnen zijn om zelf uit te voeren, aangezien BigQuery wordt gefactureerd per terabyte. Raadpleeg, voor hulp bij het beheersen van uw uitgaven, Tim Kadlec&#8217;s bericht <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">BigQuery gebruiken zonder de bank te breken</a>.
-        </p>
+        </aside>
 
         <p>
           Zie bijvoorbeeld <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a> voor meer informatie over het gemiddelde aantal bytes van JavaScript per desktop- en mobiele pagina:
diff --git a/src/templates/pt/2019/methodology.html b/src/templates/pt/2019/methodology.html
index cf589168612..d1c3dd86379 100644
--- a/src/templates/pt/2019/methodology.html
+++ b/src/templates/pt/2019/methodology.html
@@ -74,9 +74,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">Sobre o conjunto de dado
           Todas as métricas apresentadas no Web Almanac são publicamente reproduzíveis usando o conjunto de dados no BigQuery. Você pode verificar as consultas usadas por todos os capítulos em nosso <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2019">repositório no GitHub</a>.
         </p>
 
-        <p class="note">
+        <aside class="note">
           Por favor, observe que algumas dessas consultas são bastante extensas e podem ser <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">custosas</a> para executar, pois o BigQuery é cobrado por terabyte. Para obter ajuda para controlar seus gastos, consulte o artigo de Tim Kadlec&#8217;s <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Using BigQuery Without Breaking the Bank</a>.
-        </p>
+        </aside>
 
         <p>
           Por exemplo, para entender a mediana do número de bytes de JavaScript por página em desktop e dispositivos móveis, consulte <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a>:
@@ -286,9 +286,9 @@ <h3 id="lighthouse"><a href="#lighthouse" class="anchor-link">Lighthouse</a></h3
       </table>
       </div></div>
 
-      <p class="note">
+      <aside class="note">
         * Observe que o Lighthouse normalmente é configurado para ter uma desaceleração da CPU de 4x, mas devido a um <a hreflang="en" href="https://github.com/GoogleChrome/lighthouse/issues/9668#issuecomment-535134232">bug</a> no WebPageTest, isso foi de 1x no momento dos testes.
-      </p>
+      </aside>
 
       <p>
         Para obter mais informações sobre o Lighthouse e as auditorias disponíveis no HTTP Archive, consulte a <a hreflang="en" href="https://developers.google.com/web/tools/lighthouse/">documentação do desenvolvedor do Lighthouse</a>.
diff --git a/src/templates/ru/2019/methodology.html b/src/templates/ru/2019/methodology.html
index 3741d905d5f..e3ec0e6cf20 100644
--- a/src/templates/ru/2019/methodology.html
+++ b/src/templates/ru/2019/methodology.html
@@ -74,9 +74,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">О наборе данн
           Все метрики, представленные в Web Almanac, можно получить из набора данных на BigQuery. Вы можете посмотреть запросы, используемые во всех главах, в нашем <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2019">репозитории на GitHub</a>.
         </p>
 
-        <p class="note">
+        <aside class="note">
           Обратите внимание, что некоторые запросы могут быть достаточно большими и <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">дорогостоящими</a> для выполнения, так как оплата за пользование BigQuery начинается после обработки одного терабайта данных. Для того, чтобы помочь вам контролировать расходы, прочитайте пост Тима Кадлека (Tim Kadlec) <a lang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Using BigQuery Without Breaking the Bank</a>.
-        </p>
+        </aside>
 
         <p>
           Например, чтобы выяснить среднее количество байт JavaScript-кода в десктопной и мобильной версиях страницы, посмотрите запрос <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a>.
@@ -286,9 +286,9 @@ <h3 id="lighthouse"><a href="#lighthouse" class="anchor-link">Lighthouse</a></h3
       </table>
       </div></div>
 
-      <p class="note">
+      <aside class="note">
         * Обратите внимание, что Lighthouse обычно настроен на 4-кратное замедление процессора, но из-за <a hreflang="en" href="https://github.com/GoogleChrome/lighthouse/issues/9668#issuecomment-535134232">бага</a> в WebPageTest, на момент проведения тестов процессор был замедлен в 1 раз.
-      </p>
+      </aside>
 
       <p>
         Для получения более подробной информации о Lighthouse и аудитах, используемых HTTP Archive, обратитесь к <a hreflang="en" href="https://developers.google.com/web/tools/lighthouse/">документации Lighthouse для разработчиков</a>.
diff --git a/src/templates/ru/2020/methodology.html b/src/templates/ru/2020/methodology.html
index 2897f2d66f1..8c7f736e197 100644
--- a/src/templates/ru/2020/methodology.html
+++ b/src/templates/ru/2020/methodology.html
@@ -79,9 +79,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">О наборе данн
           Все метрики, представленные в Web Almanac, можно получить из набора данных на BigQuery. Вы можете посмотреть запросы, используемые во всех главах, в нашем <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2020">репозитории на GitHub</a>.
         </p>
 
-        <p class="note">
+        <aside class="note">
           Обратите внимание, что некоторые запросы могут быть достаточно большими и <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">дорогостоящими</a> для выполнения, так как оплата за пользование BigQuery начинается после обработки одного терабайта данных. Для того, чтобы помочь вам контролировать расходы, прочитайте пост Тима Кадлека (Tim Kadlec) <a lang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">Using BigQuery Without Breaking the Bank</a>.
-        </p>
+        </aside>
 
         <p>
           Например, чтобы выяснить среднее количество байт JavaScript-кода в десктопной и мобильной версиях страницы, посмотрите запрос <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a>.
diff --git a/src/templates/zh-CN/2019/methodology.html b/src/templates/zh-CN/2019/methodology.html
index 41b4802b288..001a481a9eb 100644
--- a/src/templates/zh-CN/2019/methodology.html
+++ b/src/templates/zh-CN/2019/methodology.html
@@ -74,9 +74,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">关于数据集</a></h2>
           Web Almanac中列出的所有指标都可以通过BigQuery上的数据集公开重现。您可以在我们的<a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2019">GitHub 仓库</a>浏览我们的所有章节使用的查询。
         </p>
 
-        <p class="note">
+        <aside class="note">
           请注意，其中一些查询相当大，如果你自己运行可能比较 <a hreflang="en" href="https://cloud.google.com/bigquery/pricing">昂贵</a> ，因为BigQuery是按TB收费。为了帮助控制你的开支，请看 Tim Kadlec的文章 <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">在不破产的情况下来使用BigQuery</a>。
-        </p>
+        </aside>
 
         <p>
           例如，要了解每个桌面和移动页面的JavaScript字节数的中位数，请参阅 <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a>:
@@ -286,9 +286,9 @@ <h3 id="lighthouse"><a href="#lighthouse" class="anchor-link">Lighthouse</a></h3
       </table>
       </div></div>
 
-      <p class="note">
+      <aside class="note">
         * 请注意，Lighthouse通常的配置是CPU降速4倍，但是因为一个WebPageTest的<a hreflang="en" href="https://github.com/GoogleChrome/lighthouse/issues/9668#issuecomment-535134232">bug</a> ， 在当时的测试是降速1倍。
-      </p>
+      </aside>
 
       <p>
         如需了解更多关于Lighthouse以及HTTP Archive中可用的审计，请参考 <a hreflang="en" href="https://developers.google.com/web/tools/lighthouse/">Lighthouse 开发者文档</a>。
diff --git a/src/templates/zh-CN/2020/methodology.html b/src/templates/zh-CN/2020/methodology.html
index ee3b382ab07..915f8d34736 100644
--- a/src/templates/zh-CN/2020/methodology.html
+++ b/src/templates/zh-CN/2020/methodology.html
@@ -79,9 +79,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">关于数据集</a></h2>
           Web Almanac中列出的所有指标都可以通过BigQuery上的数据集公开重现。您可以在我们的<a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2020">GitHub 仓库</a>浏览我们的所有章节使用的查询。
         </p>
 
-        <p class="note">
+        <aside class="note">
           请注意，其中一些查询相当大，如果你自己运行可能比较<a hreflang="en" href="https://cloud.google.com/bigquery/pricing">昂贵</a> ，因为BigQuery是按TB收费。为了帮助控制你的开支，请看 Tim Kadlec的文章 <a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">在不破产的情况下来使用BigQuery</a>。
-        </p>
+        </aside>
 
         <p>
           例如，要了解每个桌面和移动页面的JavaScript字节数的中位数，请参阅 <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a>:
diff --git a/src/templates/zh-TW/2020/methodology.html b/src/templates/zh-TW/2020/methodology.html
index 4c63270d35f..6bc52c75162 100644
--- a/src/templates/zh-TW/2020/methodology.html
+++ b/src/templates/zh-TW/2020/methodology.html
@@ -79,9 +79,9 @@ <h2 id="dataset"><a href="#dataset" class="anchor-link">關於資料集</a></h2>
           Web Almanac 網路年鑑列示的指標可以透過執行 BigQuery 公共資料集後重現。你可以瀏覽所有章節使用的查詢在 <a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/2020">GitHub</a> 程式庫。
         </p>
 
-        <p class="note">
+        <aside class="note">
           備註，這些查詢需要相當大的資源，這可能比較<a hreflang="en" href="https://cloud.google.com/bigquery/pricing">昂貴</a>，如果你自行查詢， BigQuery 的帳單是以TB計價。這篇文章可以幫助你控管花費，請閱讀 Tim Kadlec 說明，<a hreflang="en" href="https://timkadlec.com/remembers/2019-12-10-using-bigquery-without-breaking-the-bank/">如何不破產的使用 BigQuery</a>。
-        </p>
+        </aside>
 
         <p>
           例如，你可以瞭解 JavaScript 在桌機版與手機版網頁運行的中位數，請查閱<a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2019/javascript/01_01b.sql">01_01b.sql</a>：
diff --git a/src/tools/generate/generate_extra_markdown_conversions.js b/src/tools/generate/generate_extra_markdown_conversions.js
index 13e8d69561c..65f24372335 100644
--- a/src/tools/generate/generate_extra_markdown_conversions.js
+++ b/src/tools/generate/generate_extra_markdown_conversions.js
@@ -12,6 +12,7 @@ const generate_extra_markdown_conversions = (body) => {
 
   // Convert any markdown in Notes and BlockQuotes>
   body = body.replace(/(<p class="note">)(.*?)(<\/p>)/gs, function(a, b, c, d) { return b + convertSimpleMarkdown(c) + d});
+  body = body.replace(/(<aside class="note">)(.*?)(<\/aside>)/gs, function(a, b, c, d) { return b + convertSimpleMarkdown(c) + d});
   body = body.replace(/(<blockquote>)(.*?)(<\/blockquote>)/gs, function(a, b, c, d) { return b + convertSimpleMarkdown(c) + d});
 
   return body;

From 0cef888cbf2faa9407e519fa7fef73c49a8d3076 Mon Sep 17 00:00:00 2001
From: "github-actions[bot]"
 <41898282+github-actions[bot]@users.noreply.github.com>
Date: Thu, 2 Jan 2025 19:47:41 +0000
Subject: [PATCH 4/4] Update Timestamps (#3987)

Co-authored-by: tunetheweb <10931297+tunetheweb@users.noreply.github.com>
---
 src/config/last_updated.json | 766 +++++++++++++++++------------------
 1 file changed, 383 insertions(+), 383 deletions(-)

diff --git a/src/config/last_updated.json b/src/config/last_updated.json
index 345c6b071e9..eeff8a2af5f 100644
--- a/src/config/last_updated.json
+++ b/src/config/last_updated.json
@@ -51,138 +51,138 @@
   },
   "/static/pdfs/web_almanac_2019_en.pdf": {
     "date_published": "2020-05-15T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "062211187cd5fcb40c9d91453f48b8e2",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "d8300ad5d9a5b71fdc7028831a1ed315",
     "size": 17
   },
   "/static/pdfs/web_almanac_2019_en_cover_A5.pdf": {
     "date_published": "2020-05-15T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "16e8ff27e76c45c24f5640a979cd39e5"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "346486a54f7779e909175445a6595c9f"
   },
   "/static/pdfs/web_almanac_2019_en_print_A5.pdf": {
     "date_published": "2020-05-15T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "8136fe006e1995349e77ed30d97ebb62",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "6fb9531b450cebb0b63b2f0e030b4cec",
     "size": 16
   },
   "/static/pdfs/web_almanac_2019_ja.pdf": {
     "date_published": "2020-05-15T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "3186054c6d1df276046ead7b6f1b1816",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "f5001a321967b18b5becb9628402c41e",
     "size": 17
   },
   "/static/pdfs/web_almanac_2019_ja_cover_A5.pdf": {
     "date_published": "2020-05-15T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "f3652bde41d30d582317e643293658e3"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "ef4dfa256e0a861978fccbc6a88d0c55"
   },
   "/static/pdfs/web_almanac_2019_ja_print_A5.pdf": {
     "date_published": "2020-05-15T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "397e7111dd7daf6d70f4ec11d80d183c",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "7827d7c33f72187fa56713d32d63e28c",
     "size": 16
   },
   "/static/pdfs/web_almanac_2020_en.pdf": {
     "date_published": "2020-12-08T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "aef616d43959cedba999698db608d24d",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "d12a6ed4e86d4e0dda91321d7130df0e",
     "size": 24
   },
   "/static/pdfs/web_almanac_2020_en_cover_A5.pdf": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "0cbca8c883212a15a67bb282291742ad"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "af01c823ee44644f6892f7b871f0ebd7"
   },
   "/static/pdfs/web_almanac_2020_en_print_A5.pdf": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "768c318372eab9294698e36846b025db",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "8045fe3691df60c76347c5ffecbc25ae",
     "size": 24
   },
   "/static/pdfs/web_almanac_2020_ja.pdf": {
     "date_published": "2021-10-24T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "04d70f2f667fc85e1c5a6f3b83560a26",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "23527f842c1fb620d6d115334d212357",
     "size": 25
   },
   "/static/pdfs/web_almanac_2020_ja_cover_A5.pdf": {
     "date_published": "2021-10-24T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "d3dc57dbefcd6a425e1b23a8a08d9d6b"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "b4e4a06c328528befba1c0aa2a7eb2c4"
   },
   "/static/pdfs/web_almanac_2020_ja_print_A5.pdf": {
     "date_published": "2021-10-24T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "f7f86ce0fe7b51931879b72fe70ba439",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "e701f5c372195094b6622be4dd3bdc30",
     "size": 24
   },
   "/static/pdfs/web_almanac_2021_en.pdf": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "626d957e344d5ecdf52b8526f06fc0ff",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "2dcb95d1443049b9fc23753ba593bf3a",
     "size": 32
   },
   "/static/pdfs/web_almanac_2021_en_cover_A5.pdf": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "8345abce85ba2b7342edb47cd6e8fb33"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "8fc26e933baca3b08c012f84459779e2"
   },
   "/static/pdfs/web_almanac_2021_en_print_A5.pdf": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "93f60117c9ce7411a84449585dac85ec",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "db57e508d76703fc492ac3c09890e1d7",
     "size": 31
   },
   "/static/pdfs/web_almanac_2021_ja.pdf": {
     "date_published": "22-08-01T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "47ae9fe744bac39d0845764a81442aae",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "2343dfef65bc7586eb91d5de35ff7df5",
     "size": 32
   },
   "/static/pdfs/web_almanac_2021_ja_cover_A5.pdf": {
     "date_published": "22-08-01T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "ff20bfec1321d9c537a5c3acb6882871"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "b8a09491264f61abe8a4dbe951d75328"
   },
   "/static/pdfs/web_almanac_2021_ja_print_A5.pdf": {
     "date_published": "22-08-01T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "b976f35c7b617387bcfa639d614dce33",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "88bb50380e9f47eb610dcfcc81f73fd8",
     "size": 32
   },
   "/static/pdfs/web_almanac_2022_en.pdf": {
     "date_published": "2022-10-19T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "2ed183b407991642c94eb40ee5e22606",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "9f203598086bcc556a469ca5a6434783",
     "size": 32
   },
   "/static/pdfs/web_almanac_2022_en_cover_A5.pdf": {
     "date_published": "2022-10-19T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "55826f3cda5f4e0ef225aa214b070502"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "805a5442746707a67ee89391db0a0ee3"
   },
   "/static/pdfs/web_almanac_2022_en_print_A5.pdf": {
     "date_published": "2022-10-19T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "c90fee79013c69266567902f7b9e06bd",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "cae7997d37c810488abac57233ea2175",
     "size": 32
   },
   "/static/pdfs/web_almanac_2022_ja.pdf": {
     "date_published": "2024-09-26T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "699edcbb9d34dd7b1c3feb36b2adc86f",
-    "size": 33
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "5bf189ef722629158456b15474e84471",
+    "size": 32
   },
   "/static/pdfs/web_almanac_2022_ja_cover_A5.pdf": {
     "date_published": "2024-09-26T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "2676963768c633aaf0c9cf03f6978da2"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "fb371d2b013944daed0b5d9873f93a1e"
   },
   "/static/pdfs/web_almanac_2022_ja_print_A5.pdf": {
     "date_published": "2024-09-26T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "72800a43936ee7e8e3c30c2f0b1e25d8",
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "8bac075de8244c98917481a1bc353738",
     "size": 32
   },
   "/static/pdfs/web_almanac_2022_js_cover_A5.pdf": {
@@ -198,8 +198,8 @@
   },
   "en/2019/chapters/accessibility.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "eabd04d1709ad8f870008ac5c1b57d8b"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "71663c5d46765644214ce2182c48c49f"
   },
   "en/2019/chapters/caching.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
@@ -208,8 +208,8 @@
   },
   "en/2019/chapters/cdn.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-12-02T00:00:00.000Z",
-    "hash": "a5fd3b78c8bbffb23c885303a393e031"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "0e4c422568f55efe7981c9df93538205"
   },
   "en/2019/chapters/cms.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
@@ -223,13 +223,13 @@
   },
   "en/2019/chapters/css.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "2ad4d598cd30ed6b0223549a19532b47"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "36f5469a744a94e18976a6fe2f8ab9ed"
   },
   "en/2019/chapters/ecommerce.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "0a020bd1d06899246a2c1465877a7b47"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "dc04e754634171d96e15eba78c4e3dc9"
   },
   "en/2019/chapters/fonts.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
@@ -243,33 +243,33 @@
   },
   "en/2019/chapters/javascript.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "bf8c8f9f1e43b44961cf8ce0b7c6359d"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "10880fefb6346f65554f818649d4ff38"
   },
   "en/2019/chapters/markup.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-12-02T00:00:00.000Z",
-    "hash": "2300dd6b0977a27218a941951510b123"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "c6ef628f8f84605c8fce9d649d1306de"
   },
   "en/2019/chapters/media.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "3dc426a2521644a6c85a6657d7286120"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "3b24989690228d4e1625e145a0054574"
   },
   "en/2019/chapters/mobile-web.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "617b4debbb7c883dd65670fb71eb3db6"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "e9e05c7bb0865d4000e6d77a721e402e"
   },
   "en/2019/chapters/page-weight.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "462eddabd7ae608a0a1bd09988d9a038"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "354cea4049b28c882269fc6509ec13ea"
   },
   "en/2019/chapters/performance.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "d6ef194a0d63f1d2a982e931c294e5be"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "b751d34dda0260552f0750c3047f4a70"
   },
   "en/2019/chapters/pwa.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
@@ -278,8 +278,8 @@
   },
   "en/2019/chapters/resource-hints.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "7b5567323f36a95725206fdb45114d4f"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "c663ba3f2c3b3ed00794103e20c2f009"
   },
   "en/2019/chapters/security.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
@@ -288,13 +288,13 @@
   },
   "en/2019/chapters/seo.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "f1d585641cec3530d9bd42e0a515d331"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "4c5de785fe8fcbaa4454c65c1007b0ca"
   },
   "en/2019/chapters/third-parties.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "87ea7af61bd103fc0741641b265c5e9d"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "41b8dd372289255b69fd1ed4eb9a9ac0"
   },
   "en/2019/contributors.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
@@ -313,8 +313,8 @@
   },
   "en/2019/methodology.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
-    "date_modified": "2023-04-03T00:00:00.000Z",
-    "hash": "fdb1802a376a8632b8ce97609ed10b22"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "b285ac2281150d911a67b94958ca11ef"
   },
   "en/2019/table_of_contents.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
@@ -328,8 +328,8 @@
   },
   "en/2020/chapters/caching.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "219d06f00cc1e907d67ddb211824f02c"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "1e1e3841d66c9fbeed0ac7ba8c1cd572"
   },
   "en/2020/chapters/capabilities.html": {
     "date_published": "2020-11-09T00:00:00.000Z",
@@ -348,13 +348,13 @@
   },
   "en/2020/chapters/css.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-12-02T00:00:00.000Z",
-    "hash": "86ba7917b5e39748b54b5d80b559cf97"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "597ee42c3e5df6058c20c9c0f68bff83"
   },
   "en/2020/chapters/ecommerce.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-12-02T00:00:00.000Z",
-    "hash": "bd02037fd920f1242dcb5771989f04cc"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "460837f2e6be945c2435e5ff40a54a67"
   },
   "en/2020/chapters/fonts.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
@@ -363,33 +363,33 @@
   },
   "en/2020/chapters/http.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "50c89b6057bb463d9ea697a76229552f"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "5464055e27f9effaad80dc5d15dce1cc"
   },
   "en/2020/chapters/jamstack.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "58aef9b34b9f8a913d82d8a1b8736724"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "11562c501e4563acc0f0d2147569760f"
   },
   "en/2020/chapters/javascript.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "41f70a8e1b59334c16ac42d0045018a4"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "e91daa1bc898a543501ee5fabe9901f3"
   },
   "en/2020/chapters/markup.html": {
     "date_published": "2020-11-01T00:00:00.000Z",
-    "date_modified": "2024-12-02T00:00:00.000Z",
-    "hash": "0b4888024cad6fb5a4ba5e0eb6b46aa6"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "b4f7228d1c7b28a261f30a647b533f73"
   },
   "en/2020/chapters/media.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "99951187909afb120c18fd7fba7ae429"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "cd8675c5220ad92ec5625a5f83645bd2"
   },
   "en/2020/chapters/mobile-web.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-12-02T00:00:00.000Z",
-    "hash": "9f49c0a55459a3335b7c64480e98c24f"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "2740a4cc17fdbb48fd3b5a67c3310109"
   },
   "en/2020/chapters/page-weight.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
@@ -408,8 +408,8 @@
   },
   "en/2020/chapters/pwa.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "1dec4034cdccbc33e5cea1e7874a45b4"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "1f2ffba9e0adcb8e2ce2498e395b874d"
   },
   "en/2020/chapters/resource-hints.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
@@ -418,13 +418,13 @@
   },
   "en/2020/chapters/security.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "0496729fabf4e13e370a12aa9c5fb896"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "77581427806d34b84bf1ccd0350164a2"
   },
   "en/2020/chapters/seo.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "ef08559fdfddc990c83aad9836d1db3e"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "dcfdd030a0d3941d4b467ac2140214c2"
   },
   "en/2020/chapters/third-parties.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
@@ -448,8 +448,8 @@
   },
   "en/2020/methodology.html": {
     "date_published": "2020-10-24T00:00:00.000Z",
-    "date_modified": "2024-11-11T00:00:00.000Z",
-    "hash": "c020db2376f34be3ec1c6ce877b51d90"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "d9844429073283b1f091536f51b9a41f"
   },
   "en/2020/stories/content_distribution.html": {
     "date_published": "2021-01-18T00:00:00.000Z",
@@ -478,8 +478,8 @@
   },
   "en/2021/chapters/accessibility.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-12-02T00:00:00.000Z",
-    "hash": "a8eb58667051355c349308c6cc1c9352"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "1be0cb279662432b7d237a8fc456d6d3"
   },
   "en/2021/chapters/caching.html": {
     "date_published": "2021-12-15T00:00:00.000Z",
@@ -493,13 +493,13 @@
   },
   "en/2021/chapters/cdn.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "244cbc602d9d867bcb395c9084745841"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "3eae86d010541c8f7fae0f126ecc0fe9"
   },
   "en/2021/chapters/cms.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "59f75fc0b186fa3f88e96813175fe1bb"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "25ad042fe60ab85e49488c6a445219e5"
   },
   "en/2021/chapters/compression.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
@@ -513,18 +513,18 @@
   },
   "en/2021/chapters/ecommerce.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-12-02T00:00:00.000Z",
-    "hash": "039776b4e7569ecd5f9d37228849df8b"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "f9beab659869afeed26745ab020a8ba0"
   },
   "en/2021/chapters/http.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-12-02T00:00:00.000Z",
-    "hash": "7b86f1932e436b0b7a28acb8f40f028b"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "6717e4988e4e50574e821037d0235709"
   },
   "en/2021/chapters/jamstack.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "d67736e4e2e68acbea14e3c0456f88ed"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "3144661ad226202bd2a0f4a2b611e067"
   },
   "en/2021/chapters/javascript.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
@@ -533,8 +533,8 @@
   },
   "en/2021/chapters/markup.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-12-02T00:00:00.000Z",
-    "hash": "e045566badb13cbe62ba96320991502a"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "d8ab51fef1bc4c17f9bd049794f90cea"
   },
   "en/2021/chapters/media.html": {
     "date_published": "2021-12-15T00:00:00.000Z",
@@ -548,33 +548,33 @@
   },
   "en/2021/chapters/page-weight.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "a7f48059f4a0f085398eaf481aeebcce"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "a7b83217ec43bc8ecafa7ade63a7c927"
   },
   "en/2021/chapters/performance.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "11b8166bf097551da40d54e88ed46e07"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "28d4b2905255c8ea3e02454b23e0c932"
   },
   "en/2021/chapters/privacy.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "2ea0f8fb6cf5fdd1a44f043f0fe0550f"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "a20a060e60e0f76c1a696b3d9388538a"
   },
   "en/2021/chapters/pwa.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "d27974245beba7a1097757e07c05c763"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "cec447f9f5c272dd2280b6d0f7538563"
   },
   "en/2021/chapters/resource-hints.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "50861d8d9f8ddf6af61f5ee45b39a096"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "c9d830ddf9ef1d1647615d443e34efda"
   },
   "en/2021/chapters/security.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "51887e141e24db6ee1cb4e4d3847e138"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "c7a118992591d91f48faa1b0ccd6f249"
   },
   "en/2021/chapters/seo.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
@@ -588,8 +588,8 @@
   },
   "en/2021/chapters/third-parties.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "53396c657e83891d0ab6a34473dfe95e"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "69b20e5200b5242a3d39072824d49fb7"
   },
   "en/2021/chapters/webassembly.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
@@ -608,8 +608,8 @@
   },
   "en/2021/methodology.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
-    "date_modified": "2024-09-26T00:00:00.000Z",
-    "hash": "4329e55aa6dcc3e2d11a450b3244fe21"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "870796d080651bd001c1ad1b1a95620d"
   },
   "en/2021/table_of_contents.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
@@ -628,8 +628,8 @@
   },
   "en/2022/chapters/cdn.html": {
     "date_published": "2022-10-13T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "f1125537abed3057cfb5529f4d8cb0da"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "dacf6551f9699c3ecd0e1468b9a8418d"
   },
   "en/2022/chapters/cms.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
@@ -658,8 +658,8 @@
   },
   "en/2022/chapters/jamstack.html": {
     "date_published": "2022-10-13T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "382845eceb3c45ad08f840492ba8f0a0"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "6df6b9fe58f52eb1865ded4007589291"
   },
   "en/2022/chapters/javascript.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
@@ -668,13 +668,13 @@
   },
   "en/2022/chapters/markup.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2024-12-02T00:00:00.000Z",
-    "hash": "bb8a84eb49ef79021afeaa4e163b252d"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "6d09f6375f3812e1b41a96edad475384"
   },
   "en/2022/chapters/media.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "ded54d10e0c1e3a495c40fd04278f005"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "729463c0a9fa25ff5f1f9e1503fd9d45"
   },
   "en/2022/chapters/mobile-web.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
@@ -688,8 +688,8 @@
   },
   "en/2022/chapters/performance.html": {
     "date_published": "2022-10-25T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "39fa817671813c4dabb4df1f6a066186"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "1980f98f7820f9a72b01e8e0903e7c9e"
   },
   "en/2022/chapters/privacy.html": {
     "date_published": "2022-10-13T00:00:00.000Z",
@@ -703,8 +703,8 @@
   },
   "en/2022/chapters/security.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "58bb9ca7d10d6afb6cb0896e16221d56"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "ea16e83427428955c0bb97bbe283662f"
   },
   "en/2022/chapters/seo.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
@@ -718,8 +718,8 @@
   },
   "en/2022/chapters/sustainability.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2024-12-02T00:00:00.000Z",
-    "hash": "75f80054cceb5fe7f5dbf5eba38beb6d"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "eaf7cadd2637125adbda513eefb6f0c0"
   },
   "en/2022/chapters/third-parties.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
@@ -743,8 +743,8 @@
   },
   "en/2022/methodology.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2024-11-11T00:00:00.000Z",
-    "hash": "b1535a53345b59451b8ba79525d5b0ae"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "8443381d2b336c6114869e546c5ddeb3"
   },
   "en/2022/table_of_contents.html": {
     "date_published": "2022-07-02T00:00:00.000Z",
@@ -753,8 +753,8 @@
   },
   "en/2024/chapters/accessibility.html": {
     "date_published": "2024-11-11T00:00:00.000Z",
-    "date_modified": "2024-12-03T00:00:00.000Z",
-    "hash": "e7d6ea5ddc841a76fb8c4869fc46f2c7"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "6efc777f29985dc8f391dee695650feb"
   },
   "en/2024/chapters/cdn.html": {
     "date_published": "2024-11-11T00:00:00.000Z",
@@ -778,13 +778,13 @@
   },
   "en/2024/chapters/fonts.html": {
     "date_published": "2024-11-11T00:00:00.000Z",
-    "date_modified": "2024-12-02T00:00:00.000Z",
-    "hash": "0972e7e4c8b572e58aa8dead2b4d7e13"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "b77a206c8371d2bfa5120073c7483844"
   },
   "en/2024/chapters/http.html": {
     "date_published": "2024-12-10T00:00:00.000Z",
-    "date_modified": "2024-12-10T00:00:00.000Z",
-    "hash": "a9744be6286d7a7e9075408b61da77cc"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "10af2be114ff3d61ee95cadbb21f168b"
   },
   "en/2024/chapters/jamstack.html": {
     "date_published": "2024-11-11T00:00:00.000Z",
@@ -803,8 +803,8 @@
   },
   "en/2024/chapters/media.html": {
     "date_published": "2024-12-29T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "837328bd3fa8a34f513b094ab9bcead1"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "23fabd822e0eee93393e1a4812bd15f4"
   },
   "en/2024/chapters/mobile-web.html": {
     "date_published": "2024-11-11T00:00:00.000Z",
@@ -813,8 +813,8 @@
   },
   "en/2024/chapters/page-weight.html": {
     "date_published": "2024-12-30T00:00:00.000Z",
-    "date_modified": "2024-12-30T00:00:00.000Z",
-    "hash": "eeca57e801d371ab543cc3a1584d3c64"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "70a6c910d6b26add29e354f4e79fc8b3"
   },
   "en/2024/chapters/performance.html": {
     "date_published": "2024-11-11T00:00:00.000Z",
@@ -823,8 +823,8 @@
   },
   "en/2024/chapters/privacy.html": {
     "date_published": "2024-12-03T00:00:00.000Z",
-    "date_modified": "2024-12-03T00:00:00.000Z",
-    "hash": "4dc095e290f2a208a691693bafac0937"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "f3aacdeea7a2ec4ca42546cfa51dcc2c"
   },
   "en/2024/chapters/security.html": {
     "date_published": "2024-11-11T00:00:00.000Z",
@@ -848,8 +848,8 @@
   },
   "en/2024/chapters/third-parties.html": {
     "date_published": "2024-11-21T00:00:00.000Z",
-    "date_modified": "2024-11-30T00:00:00.000Z",
-    "hash": "f5e703ed3f81f6969d2000e33d06a7fd"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "e19f4e904de45abbdb8c5f460fce482f"
   },
   "en/2024/contributors.html": {
     "date_published": "2024-11-11T00:00:00.000Z",
@@ -863,8 +863,8 @@
   },
   "en/2024/methodology.html": {
     "date_published": "2024-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-12T00:00:00.000Z",
-    "hash": "e3bad70f7e1344cd514e68c2e00a4b19"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "6452daad950b27e0d3f0cd2e3847dc4b"
   },
   "en/2024/table_of_contents.html": {
     "date_published": "2024-11-11T00:00:00.000Z",
@@ -878,13 +878,13 @@
   },
   "es/2019/chapters/css.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "5e53a1f1450e7facee7bd0ae9b61a23b"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "f2270d0e12409b39834672618fbd4722"
   },
   "es/2019/chapters/ecommerce.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "afeac252b70811b1e834bea7cf5c0487"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "399949cccf5c81b16c595796cb333c25"
   },
   "es/2019/chapters/fonts.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
@@ -898,18 +898,18 @@
   },
   "es/2019/chapters/markup.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "15e1bbea696f750fc0c7f197933a4bfb"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "3b3225da993d4e5a01a7d8e4bc7bcc8a"
   },
   "es/2019/chapters/media.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "75caf7b09078284dc2db4e02344ab380"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "8e95046b60773216fe5cfd82c84e0f1e"
   },
   "es/2019/chapters/performance.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "846ec156d3efb4a00103da4fe6174b21"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "87be910848c007b6c2e31291d2832fc4"
   },
   "es/2019/contributors.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
@@ -928,23 +928,23 @@
   },
   "es/2020/chapters/ecommerce.html": {
     "date_published": "2021-12-02T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "e241651b4c73c9c80125c4de55a62f69"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "2f7d1097b5dddebb5d4735eb14ee2a3e"
   },
   "es/2020/chapters/http.html": {
     "date_published": "2021-01-03T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "49911ae94b85ca6f3689542da1d071a6"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "6383dca391fcbc7c95c596521fd867ac"
   },
   "es/2020/chapters/javascript.html": {
     "date_published": "2021-07-02T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "e9d5094302b69490ba3e09d0fd3d97ba"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "53cbe32c2dbd287222116db42e796fb4"
   },
   "es/2020/chapters/seo.html": {
     "date_published": "2021-06-25T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "f559f6d4e8fd8fe8f1e89e62c0d96647"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "8e82bd1ff9714d262898e2c5de5a3eaa"
   },
   "es/2020/contributors.html": {
     "date_published": "2020-07-14T00:00:00.000Z",
@@ -1023,8 +1023,8 @@
   },
   "fr/2019/chapters/accessibility.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "2281d5ba7aa6d1707ca8b5ab27d09551"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "fa1f2d840247541f71c12b19e89c16e5"
   },
   "fr/2019/chapters/caching.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
@@ -1043,8 +1043,8 @@
   },
   "fr/2019/chapters/css.html": {
     "date_published": "2020-11-18T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "b52b3de73b4dc36d11f71aa6aa1af18c"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "7a5f8abda4ad8eac51f5e9084499497c"
   },
   "fr/2019/chapters/fonts.html": {
     "date_published": "2021-05-04T00:00:00.000Z",
@@ -1053,38 +1053,38 @@
   },
   "fr/2019/chapters/javascript.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "bdb531361ae27f701eb19d1c73048656"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "c5afa2fe8a124710208412c3cfbc86a5"
   },
   "fr/2019/chapters/markup.html": {
     "date_published": "2019-12-23T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "ad4cf5fa567797741ea50724f416086a"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "8421bc91ded1b09a6670fb24e5c33370"
   },
   "fr/2019/chapters/media.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "c7a415c5a86cd031cdf254d9c8faab1f"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "10d09e31d5beecf898e2cbb277706879"
   },
   "fr/2019/chapters/mobile-web.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "589bad03c312af3414f610f5db727a01"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "cfb496e4ee2c0948230201e07bfc0f71"
   },
   "fr/2019/chapters/resource-hints.html": {
     "date_published": "2019-12-24T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "98578aed7b36a3fa467f4eb3c4712d60"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "e9b786d1bdcf8612aac0d4420c4c80ee"
   },
   "fr/2019/chapters/seo.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "fe231d8bdc6cbe51dc0bc221db8f062d"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "2130dc845f0b69542e39a390606a092b"
   },
   "fr/2019/chapters/third-parties.html": {
     "date_published": "2019-12-23T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "54d7359499a262a4fecd5835ea1edf34"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "9ae75b26462626ed8a4c7f424fd6bb22"
   },
   "fr/2019/contributors.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
@@ -1098,8 +1098,8 @@
   },
   "fr/2019/methodology.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
-    "date_modified": "2023-04-03T00:00:00.000Z",
-    "hash": "0d1b425966edea81d7079a68d15728d3"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "40c47355d0a58c11b9e8879605075173"
   },
   "fr/2019/table_of_contents.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
@@ -1123,8 +1123,8 @@
   },
   "fr/2020/methodology.html": {
     "date_published": "2020-10-24T00:00:00.000Z",
-    "date_modified": "2024-11-11T00:00:00.000Z",
-    "hash": "cc627d8249d69ab692a55a9ed99a02b6"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "338dad94b6f248dc191ac3d1bc14aaeb"
   },
   "fr/2020/table_of_contents.html": {
     "date_published": "2020-10-24T00:00:00.000Z",
@@ -1148,8 +1148,8 @@
   },
   "fr/2022/chapters/jamstack.html": {
     "date_published": "2022-11-08T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "776669066b6ce4801a4da9dc3d925e7f"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "0da9951652759b145309e07bec23ee93"
   },
   "fr/2022/contributors.html": {
     "date_published": "2022-07-02T00:00:00.000Z",
@@ -1198,8 +1198,8 @@
   },
   "hi/2019/methodology.html": {
     "date_published": "2020-11-26T00:00:00.000Z",
-    "date_modified": "2023-04-03T00:00:00.000Z",
-    "hash": "456daf53f56b366bf61b29be526d4e1a"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "e9c96066afba8314dae37066d96a918f"
   },
   "hi/2019/table_of_contents.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
@@ -1218,8 +1218,8 @@
   },
   "hi/2020/methodology.html": {
     "date_published": "2020-11-26T00:00:00.000Z",
-    "date_modified": "2024-11-11T00:00:00.000Z",
-    "hash": "048cdb50be7eb6949e912c9e245fe4bc"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "72742b1b7925de3697e4f0810ca6cc88"
   },
   "hi/2020/table_of_contents.html": {
     "date_published": "2020-10-24T00:00:00.000Z",
@@ -1298,23 +1298,23 @@
   },
   "it/2020/chapters/css.html": {
     "date_published": "2021-03-12T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "4c0413fed17d4bed3fe2f2da17bbf0eb"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "7dd4e492f8db369de4298658ef1c8c65"
   },
   "it/2020/chapters/http.html": {
     "date_published": "2021-03-17T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "96322494f7e14c15646ea55232b62652"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "2a941a9ba2200fb96728b1f5f354d488"
   },
   "it/2020/chapters/javascript.html": {
     "date_published": "2021-02-05T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "288a39559002a2af417c03f50d6ca0d9"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "c63fa52378c421ad1337aaf00b6992fe"
   },
   "it/2020/chapters/markup.html": {
     "date_published": "2021-02-05T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "b0181b306ca4dde4028900cc2449bf83"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "990b7fc912bd7373813feafb0b8d9f86"
   },
   "it/2020/chapters/page-weight.html": {
     "date_published": "2021-03-17T00:00:00.000Z",
@@ -1333,8 +1333,8 @@
   },
   "it/2020/chapters/seo.html": {
     "date_published": "2021-02-14T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "45e44a1238d9026848c5517bb662a0c6"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "df4d508e96a505e23cbbfc75a45f87cd"
   },
   "it/2020/chapters/third-parties.html": {
     "date_published": "2021-04-13T00:00:00.000Z",
@@ -1383,8 +1383,8 @@
   },
   "it/2022/chapters/markup.html": {
     "date_published": "2023-01-14T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "4e523f7b0fc87c5e485e113ebfdcf872"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "da92299cffee3bd388d93f6a066f320d"
   },
   "it/2022/chapters/structured-data.html": {
     "date_published": "2023-01-14T00:00:00.000Z",
@@ -1423,8 +1423,8 @@
   },
   "ja/2019/chapters/accessibility.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "b9838e43e721612698b885e66b784a96"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "556d73651a2474ad6ed6e7e217322933"
   },
   "ja/2019/chapters/caching.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
@@ -1433,8 +1433,8 @@
   },
   "ja/2019/chapters/cdn.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "94f5a03d0db3d68b2fc56a7f994aa051"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "ef71620d8090301b784e8c1549caabae"
   },
   "ja/2019/chapters/cms.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
@@ -1448,13 +1448,13 @@
   },
   "ja/2019/chapters/css.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "90fc258efe85e7656345238c9e428c28"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "29ea4634af1e4a5189a420fec2e88401"
   },
   "ja/2019/chapters/ecommerce.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "d3bb95eee77d52d6a22c6e7e0deae1ce"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "bc7fc9103e115e0b5466965ca12b4748"
   },
   "ja/2019/chapters/fonts.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
@@ -1468,33 +1468,33 @@
   },
   "ja/2019/chapters/javascript.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "39a8f258b75072561b5ff0a0921017c6"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "e45f943a7e861ac5677b4ac419e2c5a8"
   },
   "ja/2019/chapters/markup.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "987f5fe64c318fb31db44b78c2ceb84a"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "5fe77fcbe68107e6c8531a22925f1c92"
   },
   "ja/2019/chapters/media.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "36bc49c06e45cce0c4100eb3d3ffc88d"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "0f026d0ccf7bf34330dc26b81b8061ab"
   },
   "ja/2019/chapters/mobile-web.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "d504c4b2806cb3b86b2bda9ba8cf9490"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "ee09dae62fb9bcfdb278dd686f514fbf"
   },
   "ja/2019/chapters/page-weight.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "5944eebdbbba9a8f4595af75132e927d"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "f094df8a892e5ff4c00dea2bd89516f7"
   },
   "ja/2019/chapters/performance.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "45d384b2ebb1f00f79e42342cb77dcc1"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "5631d75ef9868bb72620b35e1e2cbdae"
   },
   "ja/2019/chapters/pwa.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
@@ -1503,8 +1503,8 @@
   },
   "ja/2019/chapters/resource-hints.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "ce1b97b80d976d3d6a7e7adc95eaab58"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "91da3a84841d121763e0a4e43fccdcd7"
   },
   "ja/2019/chapters/security.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
@@ -1513,13 +1513,13 @@
   },
   "ja/2019/chapters/seo.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "2e48615bb8c4a12b05d6746657d362a7"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "002f2bc1fa69a51d94bae2498749ce73"
   },
   "ja/2019/chapters/third-parties.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "ac0c9f48b17c659f977f2c96712b73a6"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "2b42f07a140125d094759448b9d408cb"
   },
   "ja/2019/contributors.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
@@ -1538,8 +1538,8 @@
   },
   "ja/2019/methodology.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
-    "date_modified": "2023-04-03T00:00:00.000Z",
-    "hash": "80f9e468e68076fd1d5e9398293b837a"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "6bae423b336002c3522f2cdb0fc33407"
   },
   "ja/2019/table_of_contents.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
@@ -1553,8 +1553,8 @@
   },
   "ja/2020/chapters/caching.html": {
     "date_published": "2021-05-31T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "71974b5aedbaa193cd7cd11d6a04e100"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "5f6a2229531167d894c61d881ee72b03"
   },
   "ja/2020/chapters/capabilities.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
@@ -1573,13 +1573,13 @@
   },
   "ja/2020/chapters/css.html": {
     "date_published": "2021-02-14T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "1f68599e2c3153db6e544bfb84599b84"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "f8a8ef4e9be3df2a79d9935154a8b369"
   },
   "ja/2020/chapters/ecommerce.html": {
     "date_published": "2021-06-20T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "c46e738450767093145dd1b09784fa96"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "0dd4659352eb1126756cddc49950f6a8"
   },
   "ja/2020/chapters/fonts.html": {
     "date_published": "2021-05-02T00:00:00.000Z",
@@ -1588,33 +1588,33 @@
   },
   "ja/2020/chapters/http.html": {
     "date_published": "2021-02-06T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "1f4aa712ab562a9576d0d66697093b95"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "0eb48548b3d59c163d0710834b6a380b"
   },
   "ja/2020/chapters/jamstack.html": {
     "date_published": "2021-03-06T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "dc3803efd53177fcc655e45f0a294177"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "13745b615446f4c1a1f33423acce2d32"
   },
   "ja/2020/chapters/javascript.html": {
     "date_published": "2021-01-31T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "c41b669c83f0a7b6f51a594077e7a85f"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "fe7aa3bfffd24fb09fd4326e417a3336"
   },
   "ja/2020/chapters/markup.html": {
     "date_published": "2021-04-13T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "f0907a36cbc0615e7148c4743ac8d9bc"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "03ec8620a708e655154c3b726f4a3f47"
   },
   "ja/2020/chapters/media.html": {
     "date_published": "2021-06-26T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "633869786655d827aab6191e708903d1"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "8a4ab8dc64713dc7efd37f51ec01ac67"
   },
   "ja/2020/chapters/mobile-web.html": {
     "date_published": "2021-05-04T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "c1ecd93e6eb2887f92210676478ac33c"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "c0649648d49dedb6b647a2d38685e74c"
   },
   "ja/2020/chapters/page-weight.html": {
     "date_published": "2021-02-20T00:00:00.000Z",
@@ -1633,8 +1633,8 @@
   },
   "ja/2020/chapters/pwa.html": {
     "date_published": "2021-03-19T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "2f2b9533985ad1ba022bc04f16d6eec0"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "071b8e42e3e152b66a49b74bb4167b23"
   },
   "ja/2020/chapters/resource-hints.html": {
     "date_published": "2021-05-31T00:00:00.000Z",
@@ -1643,13 +1643,13 @@
   },
   "ja/2020/chapters/security.html": {
     "date_published": "2021-02-28T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "f9a8c3901105ad40f45c43a829f307a2"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "2c4d47f2221d92911d9e0493580a3c33"
   },
   "ja/2020/chapters/seo.html": {
     "date_published": "2021-04-06T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "870688aafc0aea696cf1601a8f2c4bd7"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "b004bc9d6bbabcaad7cac6c26f8a016a"
   },
   "ja/2020/chapters/third-parties.html": {
     "date_published": "2021-02-16T00:00:00.000Z",
@@ -1668,8 +1668,8 @@
   },
   "ja/2020/methodology.html": {
     "date_published": "2020-10-24T00:00:00.000Z",
-    "date_modified": "2024-11-11T00:00:00.000Z",
-    "hash": "2bf92fbf3946d4876f1efbae9c12ade4"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "59d88df9252e70ca4155ecd9b20e2459"
   },
   "ja/2020/table_of_contents.html": {
     "date_published": "2020-10-24T00:00:00.000Z",
@@ -1678,8 +1678,8 @@
   },
   "ja/2021/chapters/accessibility.html": {
     "date_published": "2022-02-19T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "903d69dc2fe0cb99fbf251194dfd20ed"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "1eef195961d5d9b78ff45351d69837d6"
   },
   "ja/2021/chapters/caching.html": {
     "date_published": "2022-07-19T00:00:00.000Z",
@@ -1693,13 +1693,13 @@
   },
   "ja/2021/chapters/cdn.html": {
     "date_published": "2022-08-08T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "a8442565b1385f55f1c7541516f0d4be"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "a84ef282be6f674b553de2676f4f92f6"
   },
   "ja/2021/chapters/cms.html": {
     "date_published": "2022-06-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "df0ef45b816a27f06a2efc9cf3a953f0"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "c965a99113c45580ca0ad5dea1cd597c"
   },
   "ja/2021/chapters/compression.html": {
     "date_published": "2022-07-02T00:00:00.000Z",
@@ -1713,18 +1713,18 @@
   },
   "ja/2021/chapters/ecommerce.html": {
     "date_published": "2022-06-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "903327e79ceeddff7eed73c41725b421"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "fea84ccb8cdbe74096e97e04945fd400"
   },
   "ja/2021/chapters/http.html": {
     "date_published": "2022-08-08T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "7b2c0db41a39c49539ef2654925a2be9"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "2dfcbc094ec12c5046f94eba235a618d"
   },
   "ja/2021/chapters/jamstack.html": {
     "date_published": "2022-06-15T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "68619900142898d55e1c60ba0b91601d"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "690b9883b6428b655ee1ace6b17cc17d"
   },
   "ja/2021/chapters/javascript.html": {
     "date_published": "2021-12-15T00:00:00.000Z",
@@ -1733,8 +1733,8 @@
   },
   "ja/2021/chapters/markup.html": {
     "date_published": "2021-12-21T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "df1cb867ba5ece6116876caacaf3d6a2"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "29cbf495907175ac8ceeb088cf6eff78"
   },
   "ja/2021/chapters/media.html": {
     "date_published": "2022-01-04T00:00:00.000Z",
@@ -1748,33 +1748,33 @@
   },
   "ja/2021/chapters/page-weight.html": {
     "date_published": "2022-07-02T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "63f0788b0c3120c037392db761eaec1e"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "27229d3ad2cf2c6df3491e5c892dbb3d"
   },
   "ja/2021/chapters/performance.html": {
     "date_published": "2022-03-02T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "b9c8d6f5b33b2c9a5658d9a55c8a412d"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "ad0765af4f50eccb33743430fbf36604"
   },
   "ja/2021/chapters/privacy.html": {
     "date_published": "2022-03-14T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "fb3b16bc18fddc2c68f248601b9443b2"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "2167d45c766507eacf2c5e1be9ddaed1"
   },
   "ja/2021/chapters/pwa.html": {
     "date_published": "2022-04-29T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "499775ac2eb4516863c8eae4b62386dc"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "7d4ae99782c7d8b07b253a4fa46ea919"
   },
   "ja/2021/chapters/resource-hints.html": {
     "date_published": "2022-08-08T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "39a3a290751a27282bc66f38d9491e10"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "26abf37640e087446ee7d7de4e709fba"
   },
   "ja/2021/chapters/security.html": {
     "date_published": "2022-03-20T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "a01c448628055c5d33ae840814f5ff37"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "787d44ac51a6169cd34304d6f00998ec"
   },
   "ja/2021/chapters/seo.html": {
     "date_published": "2022-01-30T00:00:00.000Z",
@@ -1788,8 +1788,8 @@
   },
   "ja/2021/chapters/third-parties.html": {
     "date_published": "2022-01-21T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "1a29d7307ef1ab99f208fd3ba5e28a6c"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "91f7e35fb13b5e1521069b1671d3fa0e"
   },
   "ja/2021/chapters/webassembly.html": {
     "date_published": "2022-01-10T00:00:00.000Z",
@@ -1808,8 +1808,8 @@
   },
   "ja/2021/methodology.html": {
     "date_published": "2022-10-03T00:00:00.000Z",
-    "date_modified": "2024-09-26T00:00:00.000Z",
-    "hash": "5afe1d31c21fbc28486b549eb7d13967"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "2cab4075d63f4029c257333cd98d1965"
   },
   "ja/2021/table_of_contents.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
@@ -1828,8 +1828,8 @@
   },
   "ja/2022/chapters/cdn.html": {
     "date_published": "2024-09-26T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "9af182c27530535fb9c884734ec9cdeb"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "9e8cdefa4520581a03bcc098121dfdd2"
   },
   "ja/2022/chapters/cms.html": {
     "date_published": "2024-09-20T00:00:00.000Z",
@@ -1858,8 +1858,8 @@
   },
   "ja/2022/chapters/jamstack.html": {
     "date_published": "2024-09-20T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "cbadf18e7f842ad97e02c0e3f58a0a94"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "4b544040495828ef08812832befc7b02"
   },
   "ja/2022/chapters/javascript.html": {
     "date_published": "2023-01-09T00:00:00.000Z",
@@ -1868,13 +1868,13 @@
   },
   "ja/2022/chapters/markup.html": {
     "date_published": "2023-01-09T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "c22877ff0f6e2a71b3546d1eb0fd096a"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "2e9a051aee581ea84889d4a509b303c1"
   },
   "ja/2022/chapters/media.html": {
     "date_published": "2023-04-05T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "f43c453b206d08163a624867ca3e164f"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "e0bb46ae950db06e10f8198abcd84751"
   },
   "ja/2022/chapters/mobile-web.html": {
     "date_published": "2024-08-07T00:00:00.000Z",
@@ -1888,8 +1888,8 @@
   },
   "ja/2022/chapters/performance.html": {
     "date_published": "2024-02-18T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "9bfa820ee18a94f5a0b0b1e447381e92"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "e0fd012d03211a55ebc2a5c9e87315e0"
   },
   "ja/2022/chapters/privacy.html": {
     "date_published": "2024-05-07T00:00:00.000Z",
@@ -1903,8 +1903,8 @@
   },
   "ja/2022/chapters/security.html": {
     "date_published": "2024-06-21T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "758ab9ebf1a5cac0e22b13693a42c6bf"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "cbc45ef13181b3236737729e91df3f91"
   },
   "ja/2022/chapters/seo.html": {
     "date_published": "2023-10-19T00:00:00.000Z",
@@ -1918,8 +1918,8 @@
   },
   "ja/2022/chapters/sustainability.html": {
     "date_published": "2024-09-22T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "21cd95e258b156a141b765f96eb63c19"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "cdbe2028847586c5b1f24283181f6d63"
   },
   "ja/2022/chapters/third-parties.html": {
     "date_published": "2023-06-12T00:00:00.000Z",
@@ -1943,8 +1943,8 @@
   },
   "ja/2022/methodology.html": {
     "date_published": "2024-09-26T00:00:00.000Z",
-    "date_modified": "2024-11-11T00:00:00.000Z",
-    "hash": "d40482cdc50704e0f11f214d56a85e9f"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "8fa7918707a1463ed938d017c5830f5c"
   },
   "ja/2022/table_of_contents.html": {
     "date_published": "2022-07-02T00:00:00.000Z",
@@ -1973,8 +1973,8 @@
   },
   "nl/2019/chapters/accessibility.html": {
     "date_published": "2020-12-19T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "7d4c865aad90cd71b4a9f1a8a30d007c"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "b8e3f972d6d6dc6118edb9f1991cde48"
   },
   "nl/2019/contributors.html": {
     "date_published": "2020-12-16T00:00:00.000Z",
@@ -1988,8 +1988,8 @@
   },
   "nl/2019/methodology.html": {
     "date_published": "2020-12-16T00:00:00.000Z",
-    "date_modified": "2023-04-03T00:00:00.000Z",
-    "hash": "7f84e59aacf36b65f519491e46bd1313"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "23bccfdd497692881194d57e663b8e86"
   },
   "nl/2019/table_of_contents.html": {
     "date_published": "2020-12-16T00:00:00.000Z",
@@ -2003,8 +2003,8 @@
   },
   "nl/2020/chapters/caching.html": {
     "date_published": "2021-05-02T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "04485502ab6d94df5821b3707878ba31"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "d5101f0339903d4f95763a175839432f"
   },
   "nl/2020/chapters/capabilities.html": {
     "date_published": "2021-01-17T00:00:00.000Z",
@@ -2023,8 +2023,8 @@
   },
   "nl/2020/chapters/ecommerce.html": {
     "date_published": "2021-03-21T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "b0e3acbbe72b52dc910a6c6b57543922"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "46eee49b92b9d4c2faac8f94e6ef15c3"
   },
   "nl/2020/chapters/fonts.html": {
     "date_published": "2021-01-30T00:00:00.000Z",
@@ -2033,13 +2033,13 @@
   },
   "nl/2020/chapters/http.html": {
     "date_published": "2021-04-02T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "3c51c262ac50785a32dd1c276d9eea8a"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "e1d4f83272069d53ba05318a6068c551"
   },
   "nl/2020/chapters/jamstack.html": {
     "date_published": "2021-02-21T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "09acbd96788650ec27ea596eea269c4b"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "ea81807d0c63f4efe0182a8f62f605e0"
   },
   "nl/2020/chapters/javascript.html": {
     "date_published": "2020-12-19T00:00:00.000Z",
@@ -2048,18 +2048,18 @@
   },
   "nl/2020/chapters/markup.html": {
     "date_published": "2020-12-22T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "692b47bf59b227c3505e7071e496ccd4"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "13f031cb7b44031297c4895b81519c8a"
   },
   "nl/2020/chapters/media.html": {
     "date_published": "2021-03-14T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "83aa150f275469c910b12805a397efd7"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "d02742cd7e243e9b355fd2dcda90a5b8"
   },
   "nl/2020/chapters/mobile-web.html": {
     "date_published": "2021-03-12T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "2d3842ac4e06c21dfd1ecd034f65e65c"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "c8e3d95d52a70ecf9fe000a0f1585d8c"
   },
   "nl/2020/chapters/page-weight.html": {
     "date_published": "2021-02-21T00:00:00.000Z",
@@ -2078,8 +2078,8 @@
   },
   "nl/2020/chapters/pwa.html": {
     "date_published": "2021-03-02T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "895957954fdb4fed40950b1804634681"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "23110737386923eb7241b202136759b2"
   },
   "nl/2020/chapters/resource-hints.html": {
     "date_published": "2021-03-06T00:00:00.000Z",
@@ -2088,8 +2088,8 @@
   },
   "nl/2020/chapters/security.html": {
     "date_published": "2021-02-20T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "55a88aead1cf35786d9b324f9e9a7d39"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "57339c4ae00f028571adc0160a7f4cf3"
   },
   "nl/2020/chapters/third-parties.html": {
     "date_published": "2021-03-02T00:00:00.000Z",
@@ -2108,8 +2108,8 @@
   },
   "nl/2020/methodology.html": {
     "date_published": "2020-12-16T00:00:00.000Z",
-    "date_modified": "2024-11-11T00:00:00.000Z",
-    "hash": "b37b5ce3ff3653aadb85b641c75bba1c"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "e130aa4f0de0377f2a3d96d050530466"
   },
   "nl/2020/table_of_contents.html": {
     "date_published": "2020-12-16T00:00:00.000Z",
@@ -2118,8 +2118,8 @@
   },
   "nl/2021/chapters/privacy.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "896fc077fcf6e49985d85f763989cbf6"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "0f146a72c1227bbc7d2731fd84f783e3"
   },
   "nl/2021/contributors.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
@@ -2183,13 +2183,13 @@
   },
   "pt/2019/chapters/css.html": {
     "date_published": "2023-07-25T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "15f6c7b34bb3dde58f95a3bbed622082"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "9176f84db8157320cf083c920577acad"
   },
   "pt/2019/chapters/ecommerce.html": {
     "date_published": "2021-06-10T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "30babfa77ffdbb203340b8c298ce4bc0"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "0b274252b97883942ecb88d97e25ab9e"
   },
   "pt/2019/chapters/http.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
@@ -2198,13 +2198,13 @@
   },
   "pt/2019/chapters/javascript.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "65cd9504f7357d9c4eb31d29ad5e1a7b"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "7e7b989bd5a38c457c8b39c9d980e280"
   },
   "pt/2019/chapters/resource-hints.html": {
     "date_published": "2021-06-10T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "2797fbaf8a29b1619b52cc3546af4d0b"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "00fd2498afa3a542cad6dc4f805710c3"
   },
   "pt/2019/contributors.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
@@ -2218,8 +2218,8 @@
   },
   "pt/2019/methodology.html": {
     "date_published": "2023-07-25T00:00:00.000Z",
-    "date_modified": "2023-07-25T00:00:00.000Z",
-    "hash": "65988722b92d79a08c2259d5ef2d1d0e"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "ef6a5711d9603e52a19df2296ce1a9a2"
   },
   "pt/2019/table_of_contents.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
@@ -2228,8 +2228,8 @@
   },
   "pt/2020/chapters/css.html": {
     "date_published": "2021-03-12T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "28ff16ae35b82d460f02ab1825030f98"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "4ba02e9dd418394ce7cd401ab8d11165"
   },
   "pt/2020/contributors.html": {
     "date_published": "2020-07-14T00:00:00.000Z",
@@ -2268,8 +2268,8 @@
   },
   "pt/2022/chapters/cdn.html": {
     "date_published": "2024-08-14T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "7adf4bbc748979f89746d50a36b4d0c6"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "46b0136c090f9eba5875e7da165e12f8"
   },
   "pt/2022/chapters/http.html": {
     "date_published": "2023-09-28T00:00:00.000Z",
@@ -2328,8 +2328,8 @@
   },
   "ru/2019/methodology.html": {
     "date_published": "2020-11-21T00:00:00.000Z",
-    "date_modified": "2023-04-03T00:00:00.000Z",
-    "hash": "a15a042c3e0504d728cdf1b86fbbcc6b"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "2697e93e00d0162e4f5c291d1def5e79"
   },
   "ru/2019/table_of_contents.html": {
     "date_published": "2020-11-21T00:00:00.000Z",
@@ -2343,8 +2343,8 @@
   },
   "ru/2020/chapters/css.html": {
     "date_published": "2021-10-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "eea00473bd9e1ce250c97a08424e47b9"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "7aa9e8ab9a63d040685d01a397093b14"
   },
   "ru/2020/contributors.html": {
     "date_published": "2020-11-21T00:00:00.000Z",
@@ -2358,8 +2358,8 @@
   },
   "ru/2020/methodology.html": {
     "date_published": "2020-11-21T00:00:00.000Z",
-    "date_modified": "2024-11-11T00:00:00.000Z",
-    "hash": "dcea89ab28b1af4ca9b8fd5be34b7d03"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "4b6910f5861712cc40dd49cf2c6193cf"
   },
   "ru/2020/table_of_contents.html": {
     "date_published": "2020-11-21T00:00:00.000Z",
@@ -2368,8 +2368,8 @@
   },
   "ru/2021/chapters/pwa.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "730efc5e5798f651c5574ae7738413ff"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "a73238fb46ca14d6eeb3e3ef119c1fd7"
   },
   "ru/2021/chapters/seo.html": {
     "date_published": "2022-02-08T00:00:00.000Z",
@@ -2583,13 +2583,13 @@
   },
   "zh-CN/2019/chapters/accessibility.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "ed2c65c08c7e52246034e7d7b62c584e"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "9b6778adf964920657f92524465c2e08"
   },
   "zh-CN/2019/chapters/performance.html": {
     "date_published": "2019-11-11T00:00:00.000Z",
-    "date_modified": "2024-11-16T00:00:00.000Z",
-    "hash": "a87b415882041bad671c3fdede55597f"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "1fed4716a735014cf06c151a4e53017c"
   },
   "zh-CN/2019/contributors.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
@@ -2603,8 +2603,8 @@
   },
   "zh-CN/2019/methodology.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
-    "date_modified": "2023-04-03T00:00:00.000Z",
-    "hash": "71747232301985f39fcb1e5b24b23e9f"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "d8cd2fd1821bfaa5cd2bb4846aa54d0e"
   },
   "zh-CN/2019/table_of_contents.html": {
     "date_published": "2019-11-04T00:00:00.000Z",
@@ -2633,8 +2633,8 @@
   },
   "zh-CN/2020/methodology.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-11-11T00:00:00.000Z",
-    "hash": "09c2f1bb84b8153ce63a2f639ecf67a8"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "7ea744ae4c76bf0dddb392e716594ea9"
   },
   "zh-CN/2020/table_of_contents.html": {
     "date_published": "2020-10-24T00:00:00.000Z",
@@ -2663,8 +2663,8 @@
   },
   "zh-CN/2022/chapters/security.html": {
     "date_published": "2022-11-29T00:00:00.000Z",
-    "date_modified": "2024-12-29T00:00:00.000Z",
-    "hash": "12fc70432d7062c689357b5fcf70fa34"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "e3d30ebe9f58c4dc1fe2c682fa9d82dc"
   },
   "zh-CN/2022/chapters/webassembly.html": {
     "date_published": "2022-11-07T00:00:00.000Z",
@@ -2738,8 +2738,8 @@
   },
   "zh-TW/2020/methodology.html": {
     "date_published": "2020-12-22T00:00:00.000Z",
-    "date_modified": "2024-11-11T00:00:00.000Z",
-    "hash": "22bcbca11c33b55be12965c481efe93e"
+    "date_modified": "2025-01-02T00:00:00.000Z",
+    "hash": "3692ffc08a6bcf4fa8b495bb46da389f"
   },
   "zh-TW/2020/table_of_contents.html": {
     "date_published": "2020-10-24T00:00:00.000Z",