diff --git a/src/config/2022.json b/src/config/2022.json
index d8a052016b4..0145e8a887d 100644
--- a/src/config/2022.json
+++ b/src/config/2022.json
@@ -3,7 +3,7 @@
     {
       "is_live": true,
       "supported_languages": ["en","es","fr","hi","it","ja","nl","pt","ru","tr","uk","zh-CN","zh-TW"],
-      "ebook_languages": ["en"]
+      "ebook_languages": ["en","ja"]
     }
   ],
   "outline": [
diff --git a/src/config/last_updated.json b/src/config/last_updated.json
index f477b16275b..8b86914ede6 100644
--- a/src/config/last_updated.json
+++ b/src/config/last_updated.json
@@ -51,119 +51,147 @@
   },
   "/static/pdfs/web_almanac_2019_en.pdf": {
     "date_published": "2020-05-15T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "e80049b17df4b133b6a69f6c0729c903",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "de4d2f46f85ed8151612ea6673ff7e41",
     "size": 17
   },
   "/static/pdfs/web_almanac_2019_en_cover_A5.pdf": {
     "date_published": "2020-05-15T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "5ddad5dc71d54eefe5042c2895689b6f"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "590a4d369da1675768700ac5fb354861"
   },
   "/static/pdfs/web_almanac_2019_en_print_A5.pdf": {
     "date_published": "2020-05-15T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "1b937e6dea7cab50f29c84787f005eb7",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "5e07c68a8e67b7a0d9117fee6de19b48",
     "size": 16
   },
   "/static/pdfs/web_almanac_2019_ja.pdf": {
     "date_published": "2020-05-15T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "6cd4b13f0063386592610f3034647f9a",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "778d734b2336ef197b7141d48ca8ccb4",
     "size": 17
   },
   "/static/pdfs/web_almanac_2019_ja_cover_A5.pdf": {
     "date_published": "2020-05-15T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "1ed4bf4f767c6f658362d9eeaa2cbb8d"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "c0cc60708401e617696bd6e6a211d140"
   },
   "/static/pdfs/web_almanac_2019_ja_print_A5.pdf": {
     "date_published": "2020-05-15T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "fb1c2b9e08ba25f0ec64c0c96216d499",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "6f2edc9b4255515f90ffc33bc96fe78e",
     "size": 16
   },
   "/static/pdfs/web_almanac_2020_en.pdf": {
     "date_published": "2020-12-08T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "b13183ee260f3a37266f2bad7c2673e3",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "763cf5b1fd511f103e3f53cb3a9b32c9",
     "size": 24
   },
   "/static/pdfs/web_almanac_2020_en_cover_A5.pdf": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "cea14c667bb61ce106bafd11b0b2d767"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "8e01d844082022e833031c9043e242b8"
   },
   "/static/pdfs/web_almanac_2020_en_print_A5.pdf": {
     "date_published": "2020-12-09T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "476403ac1536ffce56219b52545e799c",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "fa5c2452c986672beda64025269e3064",
     "size": 24
   },
   "/static/pdfs/web_almanac_2020_ja.pdf": {
     "date_published": "2021-10-24T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "8e97b4a96b6ef4b5cfbd029da6caec4b",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "d22b2662650d6c5966c735e488c6ecf2",
     "size": 25
   },
   "/static/pdfs/web_almanac_2020_ja_cover_A5.pdf": {
     "date_published": "2021-10-24T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "1637d0284f60cb77bdb0ae1d1dbddcbe"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "ad0f132a428ea20db54c644a24f42278"
   },
   "/static/pdfs/web_almanac_2020_ja_print_A5.pdf": {
     "date_published": "2021-10-24T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "c48edf4e22cdea379c135dfcf34ba570",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "20373c1368da2ae0f9aa23766ad79326",
     "size": 24
   },
   "/static/pdfs/web_almanac_2021_en.pdf": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "c073dc8c28219c0a0544ce36e15cf529",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "4a02c6b060414cbc0180c9da4f14f2d5",
     "size": 32
   },
   "/static/pdfs/web_almanac_2021_en_cover_A5.pdf": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "6cab11cbf61fecac967ffbce3b9e2aa2"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "0f2dcd32f833abbc6ce59f24fdd8f4ba"
   },
   "/static/pdfs/web_almanac_2021_en_print_A5.pdf": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "6ab4fa1a73746b9771ef0fffc94425a1",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "14c4d3c6d3893fb0a6172ebe3a4e7f4c",
     "size": 31
   },
   "/static/pdfs/web_almanac_2021_ja.pdf": {
     "date_published": "22-08-01T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "08f6ff7da0dc33547cf411132975cd53",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "f85945319dc9bc7321ff2c57292f0d28",
     "size": 32
   },
   "/static/pdfs/web_almanac_2021_ja_cover_A5.pdf": {
     "date_published": "22-08-01T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "aa25ae4f1df2899036e1201ea6185a48"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "7484af0eb0417b63ec576746c088040a"
   },
   "/static/pdfs/web_almanac_2021_ja_print_A5.pdf": {
     "date_published": "22-08-01T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "988c6b89ab91a811b5120d03ad69764a",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "5abf3459dedf418d4113957ed8c2d1bc",
     "size": 32
   },
   "/static/pdfs/web_almanac_2022_en.pdf": {
     "date_published": "2022-10-19T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "4bdffe8cb734b3813384e1a75c87b305",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "4c0517aa5ba9a7f03ba0a4e6bd20701a",
     "size": 32
   },
   "/static/pdfs/web_almanac_2022_en_cover_A5.pdf": {
     "date_published": "2022-10-19T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "ba776e3c29abaa9eea11517072e3e29d"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "51060daaca567bf20528f050615ba518"
   },
   "/static/pdfs/web_almanac_2022_en_print_A5.pdf": {
     "date_published": "2022-10-19T00:00:00.000Z",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "5ccad80ce33a7291dca50b2cc985fc16",
+    "size": 31
+  },
+  "/static/pdfs/web_almanac_2022_ja.pdf": {
+    "date_published": "2024-09-26T00:00:00.000Z",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "038ca788f55e6723d47e42d2af1da626",
+    "size": 32
+  },
+  "/static/pdfs/web_almanac_2022_ja_cover_A5.pdf": {
+    "date_published": "2024-09-26T00:00:00.000Z",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "6817fa08d6ccd7c0ab81136dffddecce"
+  },
+  "/static/pdfs/web_almanac_2022_ja_print_A5.pdf": {
+    "date_published": "2024-09-26T00:00:00.000Z",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "1f562a46fb2e957df5fbe9909c946652",
+    "size": 32
+  },
+  "/static/pdfs/web_almanac_2022_js_cover_A5.pdf": {
+    "date_published": "2024-09-26T00:00:00.000Z",
+    "date_modified": "2024-09-20T00:00:00.000Z",
+    "hash": "ba776e3c29abaa9eea11517072e3e29d"
+  },
+  "/static/pdfs/web_almanac_2022_js_print_A5.pdf": {
+    "date_published": "2024-09-26T00:00:00.000Z",
     "date_modified": "2024-09-20T00:00:00.000Z",
     "hash": "81e8470168d9c1cb3ec4fa87cb0bf335",
     "size": 31
@@ -305,8 +333,8 @@
   },
   "en/2020/chapters/capabilities.html": {
     "date_published": "2020-11-09T00:00:00.000Z",
-    "date_modified": "2022-12-12T00:00:00.000Z",
-    "hash": "a4e11354f7691210be5265fcc6d18fb0"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "bb6ff14c473499067cebc88d767fe28b"
   },
   "en/2020/chapters/cms.html": {
     "date_published": "2020-12-09T00:00:00.000Z",
@@ -460,8 +488,8 @@
   },
   "en/2021/chapters/capabilities.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
-    "date_modified": "2022-12-12T00:00:00.000Z",
-    "hash": "df71eeed0408dc1dfad45ff354e35f03"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "02a13b2daa8716c25c02d73a3567f24f"
   },
   "en/2021/chapters/cdn.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
@@ -530,18 +558,18 @@
   },
   "en/2021/chapters/privacy.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
-    "date_modified": "2022-12-12T00:00:00.000Z",
-    "hash": "a7708ca9d7402e0497cebbb23681097b"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "48b8b22e9877bd774bac20fd1078441d"
   },
   "en/2021/chapters/pwa.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
-    "date_modified": "2022-12-12T00:00:00.000Z",
-    "hash": "8d0ee232c1b094e10d4dd9e15e3538a9"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "0a1f6425dc1f5aea816111bce221731f"
   },
   "en/2021/chapters/resource-hints.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "2ae8ad5ae04e6b3d7649fe36de407895"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "71057e219be358b29053ab258e63188f"
   },
   "en/2021/chapters/security.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
@@ -580,8 +608,8 @@
   },
   "en/2021/methodology.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
-    "date_modified": "2023-04-03T00:00:00.000Z",
-    "hash": "c27daeeca25d6484f6534afb64b648cd"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "4329e55aa6dcc3e2d11a450b3244fe21"
   },
   "en/2021/table_of_contents.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
@@ -590,13 +618,13 @@
   },
   "en/2022/chapters/accessibility.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2023-04-03T00:00:00.000Z",
-    "hash": "a640fbf9eec27730e0d8a4c49d67a876"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "22693b82729f9bde147a6c241c1fb8d8"
   },
   "en/2022/chapters/capabilities.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2022-12-12T00:00:00.000Z",
-    "hash": "335cabce59d1f502910b9f09975004e5"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "5880cf9cbe65c1b87dc837834543645f"
   },
   "en/2022/chapters/cdn.html": {
     "date_published": "2022-10-13T00:00:00.000Z",
@@ -620,8 +648,8 @@
   },
   "en/2022/chapters/http.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2023-04-03T00:00:00.000Z",
-    "hash": "a864b6aa89de0ef9b6708d9ff83a8b9f"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "cd1dd5ce9e5f7e8ffe3bfaf5776588ba"
   },
   "en/2022/chapters/interoperability.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
@@ -630,8 +658,8 @@
   },
   "en/2022/chapters/jamstack.html": {
     "date_published": "2022-10-13T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "aedddb16dfc0483cf6be29ea0a05dcdb"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "58348fe6d3666406e764c655cf73a0a9"
   },
   "en/2022/chapters/javascript.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
@@ -650,28 +678,28 @@
   },
   "en/2022/chapters/mobile-web.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "67fabac0c018dd2fd816b3b383fba47c"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "cbb1910a3e4a5cef6651261f753a403a"
   },
   "en/2022/chapters/page-weight.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2024-06-05T00:00:00.000Z",
-    "hash": "2cf54309f51288c37ec3ae24e4ead8ca"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "3066928df713664ff1960fc96fb983ab"
   },
   "en/2022/chapters/performance.html": {
     "date_published": "2022-10-25T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "c5db4c5c9fe425a8e7ff8d6e94fb0337"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "ae92efee4d1b766d45d9412f5604702d"
   },
   "en/2022/chapters/privacy.html": {
     "date_published": "2022-10-13T00:00:00.000Z",
-    "date_modified": "2023-01-14T00:00:00.000Z",
-    "hash": "6e6acdc5a290060aef454d1a91c68417"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "f3cf5266288af5ec58ee229db038e43c"
   },
   "en/2022/chapters/pwa.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2024-09-14T00:00:00.000Z",
-    "hash": "1dd85cebe05af922f2ea42b3d5ce5edc"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "dacaa27f5d4cd0e12a6a6df6656e072d"
   },
   "en/2022/chapters/security.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
@@ -690,13 +718,13 @@
   },
   "en/2022/chapters/sustainability.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2023-01-09T00:00:00.000Z",
-    "hash": "70d490762be1a1b4f3096fcbc5ddb44a"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "73db9449eaee1723b2209f315600f5dd"
   },
   "en/2022/chapters/third-parties.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "a05528c9121aa4b76daa3850d9ae54e1"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "9cdf7a892b29e2c2c612116a0a7ccdd1"
   },
   "en/2022/chapters/webassembly.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
@@ -715,8 +743,8 @@
   },
   "en/2022/methodology.html": {
     "date_published": "2022-09-26T00:00:00.000Z",
-    "date_modified": "2023-04-03T00:00:00.000Z",
-    "hash": "ed0797d471f1ac97702dbb66275cc170"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "b3d219ec2bf75bcfd252de1c42495265"
   },
   "en/2022/table_of_contents.html": {
     "date_published": "2022-07-02T00:00:00.000Z",
@@ -1110,8 +1138,8 @@
   },
   "fr/2022/chapters/jamstack.html": {
     "date_published": "2022-11-08T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "17149ed8a7dced71a9c45fe8c46be2d0"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "7ea772a7c58d3d7f7f89823676df5fc3"
   },
   "fr/2022/contributors.html": {
     "date_published": "2022-07-02T00:00:00.000Z",
@@ -1605,8 +1633,8 @@
   },
   "ja/2021/chapters/capabilities.html": {
     "date_published": "2022-04-11T00:00:00.000Z",
-    "date_modified": "2022-12-12T00:00:00.000Z",
-    "hash": "0b35b794061352dc7d081e85550198d0"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "bc739b0cf651617c462f0185839869da"
   },
   "ja/2021/chapters/cdn.html": {
     "date_published": "2022-08-08T00:00:00.000Z",
@@ -1675,18 +1703,18 @@
   },
   "ja/2021/chapters/privacy.html": {
     "date_published": "2022-03-14T00:00:00.000Z",
-    "date_modified": "2022-12-12T00:00:00.000Z",
-    "hash": "69c97daab088490cd0eb4b928ca61740"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "b19f794fdee086140eff34437632faa6"
   },
   "ja/2021/chapters/pwa.html": {
     "date_published": "2022-04-29T00:00:00.000Z",
-    "date_modified": "2022-12-12T00:00:00.000Z",
-    "hash": "0328848c13430f7ab1e2a001f088f4cc"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "a19b77d9a5fda870f551a0e591889579"
   },
   "ja/2021/chapters/resource-hints.html": {
     "date_published": "2022-08-08T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "53669cc88a995a72e565fbc401dd524f"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "65f04cf6bd0c91419ecb904e51c8c1cf"
   },
   "ja/2021/chapters/security.html": {
     "date_published": "2022-03-20T00:00:00.000Z",
@@ -1725,8 +1753,8 @@
   },
   "ja/2021/methodology.html": {
     "date_published": "2022-10-03T00:00:00.000Z",
-    "date_modified": "2023-04-03T00:00:00.000Z",
-    "hash": "49c6e415396b23b434c967bf0992b664"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "5afe1d31c21fbc28486b549eb7d13967"
   },
   "ja/2021/table_of_contents.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
@@ -1735,13 +1763,18 @@
   },
   "ja/2022/chapters/accessibility.html": {
     "date_published": "2024-01-09T00:00:00.000Z",
-    "date_modified": "2024-01-09T00:00:00.000Z",
-    "hash": "2c6952d1da81ec9ffe4ef15d403378c6"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "737df84b92a3bf5729d1c382f58e5196"
   },
   "ja/2022/chapters/capabilities.html": {
     "date_published": "2024-08-21T00:00:00.000Z",
-    "date_modified": "2024-08-21T00:00:00.000Z",
-    "hash": "b04974725c3e7300e152ece7ac91b1e7"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "934af19df9e60775acc3ec8b516db5bf"
+  },
+  "ja/2022/chapters/cdn.html": {
+    "date_published": "2024-09-26T00:00:00.000Z",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "e4a77dd7866e606f833032fff0518b3f"
   },
   "ja/2022/chapters/cms.html": {
     "date_published": "2024-09-20T00:00:00.000Z",
@@ -1758,6 +1791,11 @@
     "date_modified": "2023-04-03T00:00:00.000Z",
     "hash": "9fe6314b5aa1535f05dabaf0e997f30e"
   },
+  "ja/2022/chapters/http.html": {
+    "date_published": "2024-09-26T00:00:00.000Z",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "57ce992dcbe5ccb760b9f8c5a41f9037"
+  },
   "ja/2022/chapters/interoperability.html": {
     "date_published": "2023-07-23T00:00:00.000Z",
     "date_modified": "2023-07-23T00:00:00.000Z",
@@ -1765,8 +1803,8 @@
   },
   "ja/2022/chapters/jamstack.html": {
     "date_published": "2024-09-20T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "8dde83df961bd5da9b1e75f5dd157952"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "c71bc20b15c07a64c678da88a1665abf"
   },
   "ja/2022/chapters/javascript.html": {
     "date_published": "2023-01-09T00:00:00.000Z",
@@ -1785,23 +1823,28 @@
   },
   "ja/2022/chapters/mobile-web.html": {
     "date_published": "2024-08-07T00:00:00.000Z",
-    "date_modified": "2024-08-07T00:00:00.000Z",
-    "hash": "9847699b89d16424f1dd2c4fab17b713"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "cf41d97cad298128f16542b30864ea83"
+  },
+  "ja/2022/chapters/page-weight.html": {
+    "date_published": "2024-09-26T00:00:00.000Z",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "5094e041c864875090a34d78b56d1c92"
   },
   "ja/2022/chapters/performance.html": {
     "date_published": "2024-02-18T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "cd5da479f2362838f95ad4903821d799"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "741e32a350fafbec722a115bcbae888e"
   },
   "ja/2022/chapters/privacy.html": {
     "date_published": "2024-05-07T00:00:00.000Z",
-    "date_modified": "2024-05-07T00:00:00.000Z",
-    "hash": "025f7034129e8d56d6b4a7ee0d699762"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "c1769e3d6049fa3bb88872768d266208"
   },
   "ja/2022/chapters/pwa.html": {
     "date_published": "2024-09-14T00:00:00.000Z",
-    "date_modified": "2024-09-14T00:00:00.000Z",
-    "hash": "ffc3db63d455f8d4f38722359975b9a3"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "6ce285cf723784ab748e32eedb750eab"
   },
   "ja/2022/chapters/security.html": {
     "date_published": "2024-06-21T00:00:00.000Z",
@@ -1820,13 +1863,13 @@
   },
   "ja/2022/chapters/sustainability.html": {
     "date_published": "2024-09-22T00:00:00.000Z",
-    "date_modified": "2024-09-23T00:00:00.000Z",
-    "hash": "36399a85ed7376b756d7f9dcaa8b3176"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "48499ff411b547843a14088931230dd2"
   },
   "ja/2022/chapters/third-parties.html": {
     "date_published": "2023-06-12T00:00:00.000Z",
-    "date_modified": "2024-09-20T00:00:00.000Z",
-    "hash": "5e6863de90062ff14e11967fbbcc354e"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "2d29ebd5e1c331ce7d9eb14c272a0d19"
   },
   "ja/2022/chapters/webassembly.html": {
     "date_published": "2023-05-16T00:00:00.000Z",
@@ -1843,6 +1886,11 @@
     "date_modified": "2022-07-02T00:00:00.000Z",
     "hash": "7556e9fcced2f9a42358ec931edc64d7"
   },
+  "ja/2022/methodology.html": {
+    "date_published": "2024-09-26T00:00:00.000Z",
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "b0702e6f07eeb6f4982e188b7137843a"
+  },
   "ja/2022/table_of_contents.html": {
     "date_published": "2022-07-02T00:00:00.000Z",
     "date_modified": "2022-07-02T00:00:00.000Z",
@@ -2000,8 +2048,8 @@
   },
   "nl/2021/chapters/privacy.html": {
     "date_published": "2021-12-01T00:00:00.000Z",
-    "date_modified": "2022-12-12T00:00:00.000Z",
-    "hash": "58d4270f5a2cc23637e10735218b3c0f"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "4d26fd216592f563e22b5af9a8f44e85"
   },
   "nl/2021/contributors.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
@@ -2130,8 +2178,8 @@
   },
   "pt/2022/chapters/capabilities.html": {
     "date_published": "2024-01-28T00:00:00.000Z",
-    "date_modified": "2024-01-28T00:00:00.000Z",
-    "hash": "029238591628c78fae7d061bc8276615"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "e9557066c8dcc2d6b038986c00b313ec"
   },
   "pt/2022/chapters/cdn.html": {
     "date_published": "2024-08-14T00:00:00.000Z",
@@ -2140,8 +2188,8 @@
   },
   "pt/2022/chapters/http.html": {
     "date_published": "2023-09-28T00:00:00.000Z",
-    "date_modified": "2023-09-28T00:00:00.000Z",
-    "hash": "d971bf6d571194ae0ae971782f558c7d"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "94591167bd8684cd41d0c75708a417d8"
   },
   "pt/2022/chapters/interoperability.html": {
     "date_published": "2023-09-28T00:00:00.000Z",
@@ -2220,8 +2268,8 @@
   },
   "ru/2021/chapters/pwa.html": {
     "date_published": "2021-11-17T00:00:00.000Z",
-    "date_modified": "2022-12-12T00:00:00.000Z",
-    "hash": "184df40613e4d90eb3a7f790b2b9bf61"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "e5b293f97c1cb8a549b29ce2f9bc6b6f"
   },
   "ru/2021/chapters/seo.html": {
     "date_published": "2022-02-08T00:00:00.000Z",
@@ -2465,8 +2513,8 @@
   },
   "zh-CN/2022/chapters/pwa.html": {
     "date_published": "2022-10-03T00:00:00.000Z",
-    "date_modified": "2022-12-12T00:00:00.000Z",
-    "hash": "e560cb39f64d77294a2f74c3d791aa86"
+    "date_modified": "2024-09-26T00:00:00.000Z",
+    "hash": "3cc6aa726a0df3a7862bf9638ad1a0ce"
   },
   "zh-CN/2022/chapters/security.html": {
     "date_published": "2022-11-29T00:00:00.000Z",
diff --git a/src/content/en/2020/capabilities.md b/src/content/en/2020/capabilities.md
index 73cae542017..0a4123bad0e 100644
--- a/src/content/en/2020/capabilities.md
+++ b/src/content/en/2020/capabilities.md
@@ -33,7 +33,7 @@ The <a hreflang="en" href="https://www.chromium.org/teams/web-capabilities-fugu"
 - <a hreflang="en" href="https://web.dev/shape-detection/">Shape Detection API</a> for efficient detection of faces or barcodes in images
 - <a hreflang="en" href="https://web.dev/nfc/">Web NFC</a>, <a hreflang="en" href="https://web.dev/serial/">Web Serial</a>, <a hreflang="en" href="https://web.dev/usb/">Web USB</a>, <a hreflang="en" href="https://web.dev/bluetooth/">Web Bluetooth</a>, and other APIs (for the entire list, see the <a hreflang="en" href="https://goo.gle/fugu-api-tracker">Fugu API Tracker</a>)
 
-Anyone can propose a new capability by <a hreflang="en" href="https://bit.ly/new-fugu-request">creating a ticket in the Chromium bug tracker</a>. The Chromium contributors examine the proposals and discuss all APIs with other developers and browser vendors through the appropriate standards bodies. Meanwhile, the Fugu team implements the API in Chromium, where it is initially implemented behind a flag. Later in the process, the API is made available to a limited audience via an <a hreflang="en" href="https://developer.chrome.com/blog/origin-trials/">origin trial</a>. During this phase, developers can sign up for a token to test the API on a specific origin. If the API turns out to be robust enough, the API ships in Chromium and, if the vendors decide so, other browsers. The <a hreflang="en" href="https://web.dev/fugu-status/">Capability Status</a> site shows where the different Capability APIs are in the process.
+Anyone can propose a new capability by <a hreflang="en" href="https://bit.ly/new-fugu-request">creating a ticket in the Chromium bug tracker</a>. The Chromium contributors examine the proposals and discuss all APIs with other developers and browser vendors through the appropriate standards bodies. Meanwhile, the Fugu team implements the API in Chromium, where it is initially implemented behind a flag. Later in the process, the API is made available to a limited audience via an <a hreflang="en" href="https://developer.chrome.com/blog/origin-trials">origin trial</a>. During this phase, developers can sign up for a token to test the API on a specific origin. If the API turns out to be robust enough, the API ships in Chromium and, if the vendors decide so, other browsers. The <a hreflang="en" href="https://web.dev/fugu-status/">Capability Status</a> site shows where the different Capability APIs are in the process.
 
 Project Fugu, the codename of the Capabilities Project, is named after a Japanese dish: correctly prepared, the meat of the blowfish is a special taste experience. If prepared incorrectly, however, it can be fatal. The powerful APIs of Project Fugu are extremely exciting for developers. However, they can affect the security and privacy of the user. Therefore, the Fugu team pays special attention to these issues. For instance, new interfaces require the website to be sent over a secure connection (HTTPS). Some of them require a user gesture, such as a click or key press, to prevent fraud. Other capabilities require explicit permission by the user. Developers can use all APIs as a progressive enhancement: by feature detecting the APIs, applications won't break in browsers lacking support for those capabilities. In browsers that support them, users can get a better experience. This way, web apps <a hreflang="en" href="https://web.dev/progressively-enhance-your-pwa/">progressively enhance</a> according to the user's particular browser.
 
diff --git a/src/content/en/2021/capabilities.md b/src/content/en/2021/capabilities.md
index cb58cf3929c..773feb420d0 100644
--- a/src/content/en/2021/capabilities.md
+++ b/src/content/en/2021/capabilities.md
@@ -229,7 +229,7 @@ With the help of <a hreflang="en" href="https://web.dev/pwa-url-handler/">URL Ha
 }
 ```
 
-If you want to register for origins other than your web app's origin, you need to <a hreflang="en" href="https://web.dev/pwa-url-handler/#the-web-app-origin-association-file">verify your ownership of them</a>. The capability is at a relatively early stage: it's only supported on Chrome and Edge on the desktop. URL Handling is currently available as an <a hreflang="en" href="https://developer.chrome.com/blog/origin-trials/">Origin Trial</a>. This means that the capability is not generally available yet. Instead, developers need to opt-in to using this experimental API by registering for an Origin Trial token first and deliver this token along with their website to use this capability. You can find more information in the <a hreflang="en" href="https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md">Origin Trials Guide for Web Developers</a>.
+If you want to register for origins other than your web app's origin, you need to <a hreflang="en" href="https://web.dev/pwa-url-handler/#the-web-app-origin-association-file">verify your ownership of them</a>. The capability is at a relatively early stage: it's only supported on Chrome and Edge on the desktop. URL Handling is currently available as an <a hreflang="en" href="https://developer.chrome.com/blog/origin-trials">Origin Trial</a>. This means that the capability is not generally available yet. Instead, developers need to opt-in to using this experimental API by registering for an Origin Trial token first and deliver this token along with their website to use this capability. You can find more information in the <a hreflang="en" href="https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md">Origin Trials Guide for Web Developers</a>.
 
 {{ figure_markup(
 caption="Desktop websites use URL Handling.",
diff --git a/src/content/en/2021/privacy.md b/src/content/en/2021/privacy.md
index b792011c9de..871ba7fc91b 100644
--- a/src/content/en/2021/privacy.md
+++ b/src/content/en/2021/privacy.md
@@ -506,7 +506,7 @@ Beyond blocking trackers, Chrome has launched the <a hreflang="en" href="https:/
 
 ### Privacy Sandbox
 
-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.
+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>
 
@@ -540,11 +540,11 @@ We saw that 4.10% of the top 1,000 websites have opted out of FLoC. Across all w
 
 Within Google's Privacy Sandbox initiative, a number of experiments are in various stages of development.
 
-The <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting/">_Attribution Reporting API_</a> (previously called _Conversion Measurement_) makes it possible to measure when user interaction with an ad leads to a conversion—for example, when an ad click eventually led to a purchase. We saw the first origin trial (which ended in October 2021) enabled on 10 origins.
+The <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting">_Attribution Reporting API_</a> (previously called _Conversion Measurement_) makes it possible to measure when user interaction with an ad leads to a conversion—for example, when an ad click eventually led to a purchase. We saw the first origin trial (which ended in October 2021) enabled on 10 origins.
 
-<a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/fledge/">_FLEDGE_</a> (First "Locally-Executed Decision over Groups" Experiment) seeks to address ad targeting. The API can be tested in current versions of Chrome <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/fledge/">locally by individual developers</a> but there is no origin trial as of October 2021.
+<a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/fledge">_FLEDGE_</a> (First "Locally-Executed Decision over Groups" Experiment) seeks to address ad targeting. The API can be tested in current versions of Chrome <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/fledge">locally by individual developers</a> but there is no origin trial as of October 2021.
 
-<a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/trust-tokens/">_Trust Tokens_</a> enable a website to convey a limited amount of information from one browsing context to another to help combat fraud, without passive tracking. We saw the first <a hreflang="en" href="https://developer.chrome.com/blog/third-party-origin-trials/">origin trial</a> (which will end in May 2022) enabled on 7 origins that are likely embedded in a number of sites as third-party providers.
+<a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/trust-tokens">_Trust Tokens_</a> enable a website to convey a limited amount of information from one browsing context to another to help combat fraud, without passive tracking. We saw the first <a hreflang="en" href="https://developer.chrome.com/blog/third-party-origin-trials">origin trial</a> (which will end in May 2022) enabled on 7 origins that are likely embedded in a number of sites as third-party providers.
 
 <a hreflang="en" href="https://github.com/WICG/CHIPS">_CHIPS_</a> (Cookies Having Independent Partitioned State) allows websites to mark cross-site cookies as "Partitioned", putting them in a separate cookie jar per top-level site. (Firefox has already introduced the similar <a hreflang="en" href="https://blog.mozilla.org/security/2021/02/23/total-cookie-protection/">_Total Cookie Protection_</a> feature for cookie partitioning.) As of October 2021, there is no origin trial for CHIPS.
 
@@ -560,7 +560,7 @@ The <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/att
   )
 }}
 
-Finally, <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/first-party-sets/">_First-Party Sets_</a> allow website owners to define a set of distinct domains that actually belong to the same entity. Owners can then set a `SameParty` attribute on cookies that should be sent across cross-site contexts, as long as the sites are in the same first-party set. A first origin trial ended in September 2021. We saw the `SameParty` attribute on a few thousand cookies.
+Finally, <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/first-party-sets">_First-Party Sets_</a> allow website owners to define a set of distinct domains that actually belong to the same entity. Owners can then set a `SameParty` attribute on cookies that should be sent across cross-site contexts, as long as the sites are in the same first-party set. A first origin trial ended in September 2021. We saw the `SameParty` attribute on a few thousand cookies.
 
 ## Conclusion
 
diff --git a/src/content/en/2021/pwa.md b/src/content/en/2021/pwa.md
index 765974c1da4..b0bce13934f 100644
--- a/src/content/en/2021/pwa.md
+++ b/src/content/en/2021/pwa.md
@@ -528,7 +528,7 @@ An important aspect of a PWA is that it allows users to access the web experienc
 Ways to distribute this installable experience include:
 
 - Prompting the user to install the PWA via the [add to home screen](https://developer.mozilla.org/docs/Web/Progressive_web_apps/Add_to_home_screen) functionality.
-- Uploading the PWA to App Stores by packaging it with <a hreflang="en" href="https://developer.chrome.com/docs/android/trusted-web-activity/">Trusted Web Activity (TWA)</a> (currently available in any Android app store, including Google Play and Microsoft Store).
+- Uploading the PWA to App Stores by packaging it with <a hreflang="en" href="https://developer.chrome.com/docs/android/trusted-web-activity">Trusted Web Activity (TWA)</a> (currently available in any Android app store, including Google Play and Microsoft Store).
 
 Next, we'll share some stats related to these techniques, to have an idea of the usage and growth of these trends.
 
@@ -573,7 +573,7 @@ WebView-based apps may look similar to native apps, but certainly there are some
 
 TWAs allow you to package your PWA into a native application shell and upload it to some App Stores. Unlike WebView-based solutions, a TWA is not just a rendering engine; it's the full browser running in fullscreen mode. For that reason, it's feature-complete and evergreen, meaning that it's always up to date and will give you access to the latest web APIs.
 
-Developers can package their PWAs into native apps with TWA directly, <a hreflang="en" href="https://developer.chrome.com/docs/android/trusted-web-activity/integration-guide/">by using Android Studio</a>, but there are several tools that make this task much easier. Next, we'll analyze two of them: PWA Builder and Bubblewrap.
+Developers can package their PWAs into native apps with TWA directly, <a hreflang="en" href="https://developer.chrome.com/docs/android/trusted-web-activity/integration-guide">by using Android Studio</a>, but there are several tools that make this task much easier. Next, we'll analyze two of them: PWA Builder and Bubblewrap.
 
 #### PWA Builder
 
diff --git a/src/content/en/2021/resource-hints.md b/src/content/en/2021/resource-hints.md
index 70ec16fc303..3c0b05cc251 100644
--- a/src/content/en/2021/resource-hints.md
+++ b/src/content/en/2021/resource-hints.md
@@ -635,7 +635,7 @@ Chrome 95 added experimental support for <a hreflang="en" href="https://datatrac
 
 ### Priority Hints
 
-Priority hints inform the browser of the relative importance of resources within the page, intending to prioritize critical resources and improve Core Web Vitals. Priority Hints are enabled through the document markup by adding the `importance` attribute to resources, such as `<img>` or `<script>`. The `importance` attribute accepts an enumeration of `high`, `low` or `auto` and by combining this with the type of resource, the browser would be able to assign the optimal fetch priority based on its heuristics. Priority Hints are available on Chrome 96 as an <a hreflang="en" href="https://developer.chrome.com/blog/origin-trials/">origin trial</a>.
+Priority hints inform the browser of the relative importance of resources within the page, intending to prioritize critical resources and improve Core Web Vitals. Priority Hints are enabled through the document markup by adding the `importance` attribute to resources, such as `<img>` or `<script>`. The `importance` attribute accepts an enumeration of `high`, `low` or `auto` and by combining this with the type of resource, the browser would be able to assign the optimal fetch priority based on its heuristics. Priority Hints are available on Chrome 96 as an <a hreflang="en" href="https://developer.chrome.com/blog/origin-trials">origin trial</a>.
 
 ## Conclusion
 
diff --git a/src/content/en/2022/accessibility.md b/src/content/en/2022/accessibility.md
index 3768c659f48..096c1cd8ca3 100644
--- a/src/content/en/2022/accessibility.md
+++ b/src/content/en/2022/accessibility.md
@@ -155,7 +155,7 @@ Forced colors mode is an accessibility feature intended to increase the readabil
 ) }}
 
 Like other user preference media queries, we see a lot of websites making adjustments based on forced colors mode. 8% of mobile sites and 9% of desktop sites use the `forced-colors` media query to alter their styles, while usage of the legacy IE11-only `-ms-high-contrast` media query is above 20% for both mobile and desktop.
-This doesn't tell us to what extent sites do support forced colors mode, but the data is encouraging nonetheless considering the `forced-colors` media query has only been supported in major browsers <a hreflang="en" href="https://caniuse.com/mdn-css_at-rules_media_forced-colors">since 2020</a>, and support for <a hreflang="en" href="https://developer.chrome.com/docs/devtools/rendering/emulate-css/">emulating `forced-colors` mode</a> on devices other than Windows is only available since February 2022.
+This doesn't tell us to what extent sites do support forced colors mode, but the data is encouraging nonetheless considering the `forced-colors` media query has only been supported in major browsers <a hreflang="en" href="https://caniuse.com/mdn-css_at-rules_media_forced-colors">since 2020</a>, and support for <a hreflang="en" href="https://developer.chrome.com/docs/devtools/rendering/emulate-css">emulating `forced-colors` mode</a> on devices other than Windows is only available since February 2022.
 
 ## Navigation
 
diff --git a/src/content/en/2022/capabilities.md b/src/content/en/2022/capabilities.md
index 964b40a0692..22ab8699b1d 100644
--- a/src/content/en/2022/capabilities.md
+++ b/src/content/en/2022/capabilities.md
@@ -379,7 +379,7 @@ Many features users expect to belong to platform-specific applications also exis
 
 Project Fugu comprises Microsoft, Intel, Samsung, Google, and many other groups and individuals.
 
-Check out <a hreflang="en" href="https://developer.chrome.com/blog/fugu-status/">this post</a> on the Chrome Developers blog to learn more about the Capabilities Project.
+Check out <a hreflang="en" href="https://developer.chrome.com/blog/fugu-status">this post</a> on the Chrome Developers blog to learn more about the Capabilities Project.
 
 ## Conclusion
 
diff --git a/src/content/en/2022/http.md b/src/content/en/2022/http.md
index e5d8fe86fdb..e1b256cd264 100644
--- a/src/content/en/2022/http.md
+++ b/src/content/en/2022/http.md
@@ -110,7 +110,7 @@ With HTTP/2, clients can <a hreflang="en" href="https://stackoverflow.com/questi
 
 With the challenges to HTTP/2 priorities, a new prioritization scheme was needed. The <a hreflang="en" href="https://httpwg.org/specs/rfc9218.html">Extensible Prioritization Scheme for HTTP</a> was developed separately from HTTP/3 and was standardized in June 2022. In this scheme, clients can explicitly assign a priority composed of two parameters via the `priority` HTTP header or the `PRIORITY_UPDATE` frame. The first parameter, `urgency`,  tells the server the priority of the requested resource. The second parameter, `incremental`, tells the server whether a resource can be partially used at the client (for example, partially displaying an image as parts of it arrive). Defining the scheme as a HTTP header and as the `PRIORITY_UPDATE` frame makes it extensible as both formats were designed to provide future extensibility. At the time of writing, the scheme has been deployed for HTTP/3 in Safari, Firefox, and Chrome.
 
-While most of the resource priorities are decided by the browser itself, developers can now also use the new <a hreflang="en" href="https://web.dev/priority-hints/">priority hints</a> to tweak the priority of a particular resource. Priority hints can be specified via the `fetchpriority` attribute in the HTML. For example, suppose that a website would like to prioritize a hero image, it can add `fetchpriority` to the image tag:
+While most of the resource priorities are decided by the browser itself, developers can now also use the new <a hreflang="en" href="https://web.dev/articles/fetch-priority">priority hints</a> to tweak the priority of a particular resource. Priority hints can be specified via the `fetchpriority` attribute in the HTML. For example, suppose that a website would like to prioritize a hero image, it can add `fetchpriority` to the image tag:
 
 ```html
 <img src="hero.png" fetchpriority="high">
@@ -147,7 +147,7 @@ In 2021, as shown in the figure above, the percentage of websites using push was
 
 The decrease in websites using push is likely because <a hreflang="en" href="https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/">it is difficult to use effectively</a>. For example, websites cannot accurately know whether a resource being pushed already exists in the client's cache. If it is in the client's cache, the bandwidth used for pushing the resource is wasteful.
 
-With the difficulties, <a hreflang="en" href="https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/ho4qP49oAwAJ">Chrome decided to deprecate HTTP/2 Push</a> starting from <a hreflang="en" href="https://developer.chrome.com/blog/removing-push/">Chrome version 106</a>. Despite push officially still being a part of the HTTP/3 standard, Chrome—which the HTTP Archive crawler uses—never implemented push for HTTP/3 connections, which might further explain the reduction in usage as sites moved to that version and lost the ability to push.
+With the difficulties, <a hreflang="en" href="https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/ho4qP49oAwAJ">Chrome decided to deprecate HTTP/2 Push</a> starting from <a hreflang="en" href="https://developer.chrome.com/blog/removing-push">Chrome version 106</a>. Despite push officially still being a part of the HTTP/3 standard, Chrome—which the HTTP Archive crawler uses—never implemented push for HTTP/3 connections, which might further explain the reduction in usage as sites moved to that version and lost the ability to push.
 
 ### Alternatives to HTTP/2 Push
 
@@ -184,13 +184,13 @@ We observed a large number of pages in our dataset include a `<link rel="preload
 
 #### 103 Early Hints
 
-In 2017, the <a hreflang="en" href="https://www.rfc-editor.org/rfc/rfc8297">103 Early Hints status code was proposed</a> and <a hreflang="en" href="https://developer.chrome.com/blog/early-hints/">Chrome added support for it this year</a>.
+In 2017, the <a hreflang="en" href="https://www.rfc-editor.org/rfc/rfc8297">103 Early Hints status code was proposed</a> and <a hreflang="en" href="https://developer.chrome.com/blog/early-hints">Chrome added support for it this year</a>.
 
 Early Hints can be used to send interim HTTP responses before the final response of the requested object. They can boost performance by leveraging the fact that web servers often require some time to prepare a response, especially for the main HTML document if it is dynamically rendered.
 
 One use case of Early Hints is to deliver `Link: rel="preload"` for resources to preemptively fetch, or `Link: rel="preconnect"` to preemptively connect to other domains. Other headers can conceptually also be conveyed, though this is not supported by any browser.
 
-Early hints can be a better alternative than push because clients retain greater control over how the resources are fetched, but still allow an improvement on just adding preloads and preconnects to the main document HTML. Furthermore, Early Hints can potentially be used for 3rd party resources, which was not possible with push, though again <a hreflang="en" href="https://developer.chrome.com/blog/early-hints/#current-limitations">this is not yet supported on any browser</a>.
+Early hints can be a better alternative than push because clients retain greater control over how the resources are fetched, but still allow an improvement on just adding preloads and preconnects to the main document HTML. Furthermore, Early Hints can potentially be used for 3rd party resources, which was not possible with push, though again <a hreflang="en" href="https://developer.chrome.com/blog/early-hints#current-limitations">this is not yet supported on any browser</a>.
 
 {{ figure_markup(
   caption="Desktop pages using 103 Early Hints.",
diff --git a/src/content/en/2022/jamstack.md b/src/content/en/2022/jamstack.md
index d839e759997..ae6be864a9a 100644
--- a/src/content/en/2022/jamstack.md
+++ b/src/content/en/2022/jamstack.md
@@ -75,7 +75,7 @@ If you are not interested in the nuts and bolts of how we picked a precise defin
 
 We knew we wanted to measure: sites that load most of their content very quickly, and can be cached. After a lot of experimentation with different ways of measuring these things, we came up with some specific metrics.
 
-**Largest Contentful Paint (LCP)**: we got the distribution of all LCP times across all pages, picked the median of real-world user data from the <a hreflang="en" href="https://developer.chrome.com/docs/crux/">Chrome UX Report</a>, and decided that any site equal or less to the median counted as "loaded most content quickly". This was 2.4 seconds on mobile devices, and 2.0 seconds on desktop devices.
+**Largest Contentful Paint (LCP)**: we got the distribution of all LCP times across all pages, picked the median of real-world user data from the <a hreflang="en" href="https://developer.chrome.com/docs/crux">Chrome UX Report</a>, and decided that any site equal or less to the median counted as "loaded most content quickly". This was 2.4 seconds on mobile devices, and 2.0 seconds on desktop devices.
 
 **Cumulative Layout Shift (CLS)**: we wanted to avoid sites that very quickly load a skeleton but then take a long time to load real content. The closest we could get to that is the <a hreflang="en" href="https://web.dev/articles/cls">Cumulative Layout Shift</a>, a measure of how much the page layout jumps around while loading. While there are ways to "game" CLS, we still believe it's a reasonable proxy for what we’re trying to measure. We liked this measure because we felt that a "jumpy" site also felt less "Jamstack-y", a word we were going to end up using a lot. Again, we picked the median of Chrome UX Report data.
 
@@ -83,7 +83,7 @@ We knew we wanted to measure: sites that load most of their content very quickly
 
 **Caching**: this was particularly tricky to quantify, since most home pages, even on Jamstack sites, request revalidation even if they are in practice cached for a long time. We went with a combination of HTTP Headers including `Age`, `Cache-Control`, and `Expires` that we found were common in pages that could be cached for a long time.
 
-We initially thought we'd need another measure to exclude "tiny" sites – sites that load very quickly because they are just a "coming soon" or "Hello world" page that nobody would visit in real life – but the HTTP Archive data is defined by their <a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology/#popularity-eligibility">popularity according to Chrome</a> user visits, and very few of those sites are visited enough to make it into the sample (although example.com is in there!).
+We initially thought we'd need another measure to exclude "tiny" sites – sites that load very quickly because they are just a "coming soon" or "Hello world" page that nobody would visit in real life – but the HTTP Archive data is defined by their <a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology#popularity-eligibility">popularity according to Chrome</a> user visits, and very few of those sites are visited enough to make it into the sample (although example.com is in there!).
 
 A good question is: why not use <a hreflang="en" href="https://web.dev/articles/vitals">Core Web Vitals</a> (CWV) numbers for these metrics? For LCP, our numbers are nearly the same as CWV. For CLS, the CWV team explicitly <a hreflang="en" href="https://web.dev/defining-core-web-vitals-thresholds/#achievability-3">relaxed the requirements</a> (their threshold is more than double the median) which we thought was not representative of a Jamstack experience. So we decided it was fairer to pick the median for both. And CWV does not have a metric for"cacheability".
 
diff --git a/src/content/en/2022/mobile-web.md b/src/content/en/2022/mobile-web.md
index e6c6bb59d62..7d7876c2281 100644
--- a/src/content/en/2022/mobile-web.md
+++ b/src/content/en/2022/mobile-web.md
@@ -35,7 +35,7 @@ New generations are getting involved in social media and have earlier access to
 
 ### Traffic from mobile versus desktop
 
-In keeping with the [Methodology](./methodology), the primary data source for this report is the HTTP Archive and the Chrome UX Report (CrUX). In cases where tablet data was included as a separate measurement from any data source, it was omitted, since it does not neatly fit in the primary mobile or desktop classifications and can add confusion and complexity when interpreting or contrasting mobile and desktop information that is more neatly segmented out. Refer to the <a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology/#user-eligibility">CrUX documentation</a> for more information about eligible mobile platforms.
+In keeping with the [Methodology](./methodology), the primary data source for this report is the HTTP Archive and the Chrome UX Report (CrUX). In cases where tablet data was included as a separate measurement from any data source, it was omitted, since it does not neatly fit in the primary mobile or desktop classifications and can add confusion and complexity when interpreting or contrasting mobile and desktop information that is more neatly segmented out. Refer to the <a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology#user-eligibility">CrUX documentation</a> for more information about eligible mobile platforms.
 
 {{ figure_markup(
     image="pct-mobile-traffic-rank.png",
diff --git a/src/content/en/2022/page-weight.md b/src/content/en/2022/page-weight.md
index db6709c860c..2cd273fe827 100644
--- a/src/content/en/2022/page-weight.md
+++ b/src/content/en/2022/page-weight.md
@@ -6,7 +6,7 @@ description: Page Weight chapter of the 2022 Web Almanac covering why page weigh
 authors: [fellowhuman1101, dwsmart]
 reviewers: [CSteele-gh]
 analysts: [drohe]
-editors: []
+editors: [tunetheweb]
 translators: []
 results: https://docs.google.com/spreadsheets/d/1JvJMiRsL6T9m_NEBHFh-rrQmU5a-ufdOKriSJbrEN8M/
 fellowhuman1101_bio: Jamie Indigo isn't a robot, but speaks bot. As a technical SEO at <a hreflang="en" href="https://www.deepcrawl.com">DeepCrawl</a>, they study how search engines crawl, render, and index the web. They love to tame wild JavaScript and optimize rendering strategies. When not working, Jamie likes horror movies, graphic novels, and Dungeons & Dragons.
@@ -76,7 +76,7 @@ That can be across a superfast, high monthly usage broadband connection, but it
 
 The larger the page weight, the longer this will take. It can also be more expensive for those users with lower-capped data plans.
 
-There are optimizations with things like <a hreflang="en" href="https://web.dev/uses-rel-preconnect/">`preconnect`</a>, <a hreflang="en" href="https://web.dev/preload-critical-assets/">`preload`</a>, and <a hreflang="en" href="https://web.dev/priority-hints/">Priority Hints</a> that can manage the order things are loaded and help perceived load times, but ultimately the resources still need to be transmitted and received, and the best optimization of all is serving smaller resources.
+There are optimizations with things like <a hreflang="en" href="https://web.dev/uses-rel-preconnect/">`preconnect`</a>, <a hreflang="en" href="https://web.dev/preload-critical-assets/">`preload`</a>, and <a hreflang="en" href="https://web.dev/articles/fetch-priority">Priority Hints</a> that can manage the order things are loaded and help perceived load times, but ultimately the resources still need to be transmitted and received, and the best optimization of all is serving smaller resources.
 
 ### Rendering
 
diff --git a/src/content/en/2022/performance.md b/src/content/en/2022/performance.md
index eef208aa4fe..7dad873e7e8 100644
--- a/src/content/en/2022/performance.md
+++ b/src/content/en/2022/performance.md
@@ -28,7 +28,7 @@ Thankfully, there's a way to measure some aspects of performance automatically!
 
 It's important to note that these metrics are only our best guess at how to gauge user experience. For example, just because the browser fired an event that an element has been painted onto the screen, does that always mean it was visible to the user at that time? Additionally, as the industry grew, more and more metrics showed up while some became deprecated. It can be complicated to know where to start and understand what performance metrics are telling us about our users, especially for folks newer to the field.
 
-This chapter focuses on Google's solution to the problem: <a hreflang="en" href="https://web.dev/articles/vitals">Core Web Vitals</a> (CWV), web performance metrics introduced in 2020 and made <a hreflang="en" href="https://developers.google.com/search/blog/2020/11/timing-for-page-experience">a signal in search ranking</a> during 2021. Each of the three metrics covers an important area of user experience: loading, interactivity, and visual stability. The public <a hreflang="en" href="https://developer.chrome.com/docs/crux/">Chrome UX Report</a> (CrUX) dataset is Chrome's view of how websites are performing on CWV. There's zero setup on the developer's part; Chrome automatically collects and publishes data from <a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology/#eligibility">eligible websites</a>, for users who have opted in. Using this dataset, we're able to get insights into the web's performance over time.
+This chapter focuses on Google's solution to the problem: <a hreflang="en" href="https://web.dev/articles/vitals">Core Web Vitals</a> (CWV), web performance metrics introduced in 2020 and made <a hreflang="en" href="https://developers.google.com/search/blog/2020/11/timing-for-page-experience">a signal in search ranking</a> during 2021. Each of the three metrics covers an important area of user experience: loading, interactivity, and visual stability. The public <a hreflang="en" href="https://developer.chrome.com/docs/crux">Chrome UX Report</a> (CrUX) dataset is Chrome's view of how websites are performing on CWV. There's zero setup on the developer's part; Chrome automatically collects and publishes data from <a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology#eligibility">eligible websites</a>, for users who have opted in. Using this dataset, we're able to get insights into the web's performance over time.
 
 Although the spotlight of this chapter, it's important to note that CWV are relatively new to the field and not the only way to measure web performance. We chose to focus on these metrics because the search ranking influence was effective almost exactly one year ago, and this year's data gives us insights on how the web is adjusting to this major shift in the industry and where room for opportunity might still exist. CWV are a common baseline that allows performance to be loosely comparable across sites, but it's up to site owners to determine which metrics and strategies are best for their sites. As much as we wish otherwise, there's no way to fit the entire history of the industry or all the different ways to evaluate performance in one chapter.
 
@@ -106,11 +106,11 @@ Why did LCP improve so much this year? To help answer that, let's explore a coup
   )
 }}
 
-As an aside, note that earlier this year Chrome <a hreflang="en" href="https://developer.chrome.com/docs/crux/release-notes/#202204">changed</a> the threshold for "good" TTFB from 500 ms to 800 ms. In the chart above, all historical data is using this new threshold for comparison purposes.
+As an aside, note that earlier this year Chrome <a hreflang="en" href="https://developer.chrome.com/docs/crux/release-notes#202204">changed</a> the threshold for "good" TTFB from 500 ms to 800 ms. In the chart above, all historical data is using this new threshold for comparison purposes.
 
 With that in mind, the percentage of websites having good TTFB has not actually improved very much. In the past year, websites' desktop and mobile experiences have gotten one percentage point better, which is nice but doesn't account for the gains observed to LCP. While this doesn't rule out improvements to the "needs improvement" and "poor" ends of the TTFB distribution, the "good" end is what matters most.
 
-Another complication is that TTFB is still considered to be an <a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology/#experimental-metrics">experimental</a> metric in CrUX. According to the CrUX documentation, TTFB _does not_ factor in more advanced navigation types like pre-rendered and back/forward navigations. This is somewhat of a blind spot, so if there were improvements in these areas, they wouldn't necessarily affect the TTFB results.
+Another complication is that TTFB is still considered to be an <a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology#experimental-metrics">experimental</a> metric in CrUX. According to the CrUX documentation, TTFB _does not_ factor in more advanced navigation types like pre-rendered and back/forward navigations. This is somewhat of a blind spot, so if there were improvements in these areas, they wouldn't necessarily affect the TTFB results.
 
 ### First Contentful Paint (FCP)
 
@@ -190,7 +190,7 @@ We see that 72% of mobile pages and 82% of desktop pages have images as their LC
 
 After the HTML document is loaded, there are two major factors that affect how quickly the LCP resource itself can be loaded: discoverability and prioritization. We'll explore [LCP discoverability](#lcp-static-discoverability) later, but first let's look at how LCP images are prioritized.
 
-Images are not loaded at high priority by default, but thanks to the new <a hreflang="en" href="https://web.dev/priority-hints/">Priority Hints</a> API, developers can explicitly set their LCP images to load at high priority to take precedence over non-essential resources.
+Images are not loaded at high priority by default, but thanks to the new <a hreflang="en" href="https://web.dev/articles/fetch-priority">Priority Hints</a> API, developers can explicitly set their LCP images to load at high priority to take precedence over non-essential resources.
 
 {{ figure_markup(
   content="0.03%",
@@ -683,7 +683,7 @@ Let's dig deeper into the ways that responsiveness can be improved across the we
 
 #### Disabling double-tap to zoom
 
-Some mobile browsers, including Chrome, wait at least 250 ms before handling tap inputs to make sure users aren't attempting to <a hreflang="en" href="https://developer.chrome.com/blog/300ms-tap-delay-gone-away/">double-tap to zoom</a>. Given that the threshold for "good" FID is 100 ms, this behavior makes it impossible to pass the assessment.
+Some mobile browsers, including Chrome, wait at least 250 ms before handling tap inputs to make sure users aren't attempting to <a hreflang="en" href="https://developer.chrome.com/blog/300ms-tap-delay-gone-away">double-tap to zoom</a>. Given that the threshold for "good" FID is 100 ms, this behavior makes it impossible to pass the assessment.
 
 ```html
 <meta name="viewport" content="width=device-width, initial-scale=1">
@@ -873,7 +873,7 @@ This chart shows the relationship between pages' FID and TBT responsiveness. The
 
 The most notable attribute of this chart is the dense area in the bottom left corner, which appears to be smeared out across the TBT axis. The length of this smear represents pages having high TBT and low FID, which illustrates the low degree of correlation between FID and TBT.
 
-There's also a patch of pages that have low TBT and a FID of about 250 ms. This area represents pages that have <a hreflang="en" href="https://developer.chrome.com/blog/300ms-tap-delay-gone-away/">tap delay</a> issues due to missing a `<meta name=viewport>` tag. These are outliers that can be safely ignored for this analysis's purposes.
+There's also a patch of pages that have low TBT and a FID of about 250 ms. This area represents pages that have <a hreflang="en" href="https://developer.chrome.com/blog/300ms-tap-delay-gone-away">tap delay</a> issues due to missing a `<meta name=viewport>` tag. These are outliers that can be safely ignored for this analysis's purposes.
 
 The <a hreflang="en" href="https://en.wikipedia.org/wiki/Kendall_rank_correlation_coefficient">Kendall</a> and <a hreflang="en" href="https://en.wikipedia.org/wiki/Spearman%27s_rank_correlation_coefficient">Spearman</a> coefficients of correlation for this distribution are 0.29 and 0.40, respectively.
 
diff --git a/src/content/en/2022/privacy.md b/src/content/en/2022/privacy.md
index efc448ca59e..249b47bd215 100644
--- a/src/content/en/2022/privacy.md
+++ b/src/content/en/2022/privacy.md
@@ -306,7 +306,7 @@ Over the last few years, the average web user has become increasingly conscious
 
 ### Privacy Sandbox Origin Trial
 
-At the time of publishing this year's Web Almanac, Privacy Sandbox features are not yet available for general use. Websites and web services—such as ads, which are typically shown in iframes—can however participate in early testing of the Privacy Sandbox features, by making use of the <a hreflang="en" href="https://developer.chrome.com/en/blog/privacy-sandbox-unified-origin-trial/">Origin Trial</a>. Note that this is only for users whose browser supports the feature—Privacy Sandbox features are only implemented in Chrome, and are still disabled by default at the time of this writing. This gives the web services access to three Privacy Sandbox-related APIs: <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/topics/">Topics</a>, <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/fledge/">FLEDGE</a>, and <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting/">Attribution Reporting</a>.
+At the time of publishing this year's Web Almanac, Privacy Sandbox features are not yet available for general use. Websites and web services—such as ads, which are typically shown in iframes—can however participate in early testing of the Privacy Sandbox features, by making use of the <a hreflang="en" href="https://developer.chrome.com/en/blog/privacy-sandbox-unified-origin-trial/">Origin Trial</a>. Note that this is only for users whose browser supports the feature—Privacy Sandbox features are only implemented in Chrome, and are still disabled by default at the time of this writing. This gives the web services access to three Privacy Sandbox-related APIs: <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/topics">Topics</a>, <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/fledge">FLEDGE</a>, and <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting">Attribution Reporting</a>.
 
 <figure>
   <table>
@@ -391,7 +391,7 @@ For example, we find that on 34,128 sites a web service opts-in to the `Conversi
 
 For the <a hreflang="en" href="https://developer.chrome.com/en/docs/privacy-sandbox/trust-tokens/">TrustTokens</a> Origin Trial, which has also expired, we are still seeing 6,005 sites where a web service opts-in to it. This mechanism aims to allow websites to combat fraud by enabling one browsing context (for example, site) to convey a limited amount of information to another.
 
-Interestingly, on more than 30,000 websites a web service is still opting-in to the `InterestCohort` origin trial, which would give them access to the interest group of the user of FLoC. However, due to privacy concerns with the API, it was no longer pursued and development was discontinued. It is superseded by the <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/fledge/">FLEDGE API</a>, which aims to provide "on-device ad auctions to serve remarketing and custom audiences" and <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/topics/">Topics API</a>, which aims to allow advertisers to serve ads based on the interests of the user without the need of cross-site tracking.
+Interestingly, on more than 30,000 websites a web service is still opting-in to the `InterestCohort` origin trial, which would give them access to the interest group of the user of FLoC. However, due to privacy concerns with the API, it was no longer pursued and development was discontinued. It is superseded by the <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/fledge">FLEDGE API</a>, which aims to provide "on-device ad auctions to serve remarketing and custom audiences" and <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/topics">Topics API</a>, which aims to allow advertisers to serve ads based on the interests of the user without the need of cross-site tracking.
 
 ## Compliance with privacy regulations
 
diff --git a/src/content/en/2022/pwa.md b/src/content/en/2022/pwa.md
index 9f711ddd8e6..8cf887d5d9b 100644
--- a/src/content/en/2022/pwa.md
+++ b/src/content/en/2022/pwa.md
@@ -262,7 +262,7 @@ PWAs need to generate different icon sizes to accommodate the range of surfaces
 
 #### Installation and discoverability properties
 
-A web app manifest file can contain data that is useful in describing of the application. These properties can be used by stores or other distribution mechanisms to promote the application. An increased growth of <a hreflang="en" href="https://developer.chrome.com/blog/richer-pwa-installation/">rich browser-based installation dialogs</a> is also utilizing these fields more prominently. Relevant fields, which can be found as part of the Application Information supplement to the Manifest file are listed below:
+A web app manifest file can contain data that is useful in describing of the application. These properties can be used by stores or other distribution mechanisms to promote the application. An increased growth of <a hreflang="en" href="https://developer.chrome.com/blog/richer-pwa-installation">rich browser-based installation dialogs</a> is also utilizing these fields more prominently. Relevant fields, which can be found as part of the Application Information supplement to the Manifest file are listed below:
 
 * `description`: This property exists in 36% of desktop and 34% of mobile web app manifests. The description is important since it explains what the application does. It's commonly used to provide information about the app for a store. Currently around a third of installable PWAs would offer this information.
 * `screenshots`: This property provides the URLs of one or more screenshots for use in app stores and in-browser install prompts. PWAs with manifests that take advantage of this feature total 1.12% for desktop and 1.19% for mobiles devices.
@@ -383,7 +383,7 @@ We won't delve into these much more as we have a separate [Capabilities](./capab
 
 ## PWA insights from Lighthouse
 
-<a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/">Lighthouse</a> is an open-source, automated tool for improving the quality of web pages. It can be used to run a number of audits on a website and has a dedicated category for PWA audits. The available data sheds some light on interesting facts about the state of PWAs these past 12 months.
+<a hreflang="en" href="https://developer.chrome.com/docs/lighthouse">Lighthouse</a> is an open-source, automated tool for improving the quality of web pages. It can be used to run a number of audits on a website and has a dedicated category for PWA audits. The available data sheds some light on interesting facts about the state of PWAs these past 12 months.
 
 ### Lighthouse audits
 
@@ -409,7 +409,7 @@ It is not surprising to see PWA sites passing the PWA audits much more frequentl
   )
 }}
 
-Looking at the Lighthouse data on mobile sites we see similar stats, but the mobile-only <a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/pwa/content-width/">content-width meta tag</a> shows here and is pleasingly passed by both.
+Looking at the Lighthouse data on mobile sites we see similar stats, but the mobile-only <a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/pwa/content-width">content-width meta tag</a> shows here and is pleasingly passed by both.
 
 The presence of a viewport meta tag is relevant because it removes a 300-350ms delay that waits for a double-tap back when that was the way to zoom in. It has the additional benefit on mobile devices of optimizing the app for the device's screen size. It is not surprising that almost all websites, PWA or not, include this.
 
@@ -441,7 +441,7 @@ To conclude the Lighthouse insights section, we take a look at the overall Light
   )
 }}
 
-As expected, PWA sites tend to have considerably higher PWA audit scores. These audits look into speed, reliability, installability and other PWA requirements, as detailed in their <a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/pwa/">documentation</a>.
+As expected, PWA sites tend to have considerably higher PWA audit scores. These audits look into speed, reliability, installability and other PWA requirements, as detailed in their <a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/pwa">documentation</a>.
 
 What's also notable is the range of audit scores in PWA sites (50-100) representing the difference in PWAs out there. In contrast the rest of the web has a fairly consistent range of scores (20-40) reflecting the two main audits relevant for most sites discussed previously-viewport and icons.
 
@@ -451,7 +451,7 @@ Service workers are really powerful tools, their API allows developers to create
 
 ### Workbox usage
 
-<a hreflang="en" href="https://developer.chrome.com/workbox/">Workbox</a> is a set of libraries that was born to ease the usage of service workers for developers. It includes a set of libraries that go from the basics that are reused in other Workbox libraries with <a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-core/">workbox-core</a> to more specific tasks like <a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-strategies/">caching strategies</a>, <a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-background-sync/">background sync</a>, <a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-precaching/">precaching</a> and <a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/">many more</a>.
+<a hreflang="en" href="https://developer.chrome.com/workbox/">Workbox</a> is a set of libraries that was born to ease the usage of service workers for developers. It includes a set of libraries that go from the basics that are reused in other Workbox libraries with <a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-core">workbox-core</a> to more specific tasks like <a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-strategies">caching strategies</a>, <a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-background-sync">background sync</a>, <a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-precaching">precaching</a> and <a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules">many more</a>.
 
 {{ figure_markup(
   image="workbox-usage.png",
diff --git a/src/content/en/2022/sustainability.md b/src/content/en/2022/sustainability.md
index 9683930f066..73dd6f05cf5 100644
--- a/src/content/en/2022/sustainability.md
+++ b/src/content/en/2022/sustainability.md
@@ -241,7 +241,7 @@ For more on this topic, see the [Fonts](./fonts) chapter. You can also find some
 
 ##### Unused CSS
 
-Unused CSS is especially found when using CSS frameworks (Bootstrap and others). When doing so, you should keep in mind to remove unused CSS during your build phase. <a hreflang="en" href="https://developer.chrome.com/docs/devtools/coverage/">Chrome Dev Tools offer a Coverage tool to check on this</a>. Be careful: on many websites, all CSS and JavaScript are loaded on the first visit in order to cache them for further visits and exploration of the website. This is not necessarily a bad thing, but unused code is one of the drawbacks that you should keep in mind, especially because it might slow down further code processing.
+Unused CSS is especially found when using CSS frameworks (Bootstrap and others). When doing so, you should keep in mind to remove unused CSS during your build phase. <a hreflang="en" href="https://developer.chrome.com/docs/devtools/coverage">Chrome Dev Tools offer a Coverage tool to check on this</a>. Be careful: on many websites, all CSS and JavaScript are loaded on the first visit in order to cache them for further visits and exploration of the website. This is not necessarily a bad thing, but unused code is one of the drawbacks that you should keep in mind, especially because it might slow down further code processing.
 
 {{ figure_markup(
   image="unused-css-bytes.png",
@@ -256,7 +256,7 @@ The good news is the 10 percentile websites load no unnecessary CSS. Unfortunate
 
 ##### Unused JavaScript
 
-The amount of unused JavaScript can grow quickly when adding dependencies or using libraries such as jQuery. <a hreflang="en" href="https://developer.chrome.com/docs/devtools/coverage/">The Coverage tool from Chrome Dev Tools</a> is a good way to check on this. As for CSS, this is sometimes part of a strategy to cache everything needed for further browsing.  This should be balanced by the fact that unused JavaScript tends to result in longer processing. When possible, look for <a hreflang="en" href="http://microjs.com">smaller alternatives</a> with only the functionality that you need instead of loading the whole toolbox, hoping it will one day prove useful. Once upon a time, jQuery was the all-in-one solution that you found on almost every website. <a hreflang="en" href="https://youmightnotneedjquery.com/">As of today, a lot of things can be handled with modern JavaScript</a>. Check your <a hreflang="en" href="https://bundlephobia.com/">NPM dependencies and how they make your bundle bigger</a>.
+The amount of unused JavaScript can grow quickly when adding dependencies or using libraries such as jQuery. <a hreflang="en" href="https://developer.chrome.com/docs/devtools/coverage">The Coverage tool from Chrome Dev Tools</a> is a good way to check on this. As for CSS, this is sometimes part of a strategy to cache everything needed for further browsing.  This should be balanced by the fact that unused JavaScript tends to result in longer processing. When possible, look for <a hreflang="en" href="http://microjs.com">smaller alternatives</a> with only the functionality that you need instead of loading the whole toolbox, hoping it will one day prove useful. Once upon a time, jQuery was the all-in-one solution that you found on almost every website. <a hreflang="en" href="https://youmightnotneedjquery.com/">As of today, a lot of things can be handled with modern JavaScript</a>. Check your <a hreflang="en" href="https://bundlephobia.com/">NPM dependencies and how they make your bundle bigger</a>.
 
 {{ figure_markup(
   image="unused-javascript-bytes.png",
diff --git a/src/content/en/2022/third-parties.md b/src/content/en/2022/third-parties.md
index fcc9683074a..89d43957379 100644
--- a/src/content/en/2022/third-parties.md
+++ b/src/content/en/2022/third-parties.md
@@ -369,7 +369,7 @@ One of the third-party resource management problems is that sometimes it can ski
 
 Some modern third-party loading and execution solutions have appeared in recent years. For example, <a hreflang="en" href="https://partytown.builder.io/">Partytown</a> is a library that relocates third-party scripts into the web worker to free up the main thread for first-party code. Currently, the library is in the early adoption stage and its usage is very low. Only 70 websites from the whole dataset are using it in 2022. However, the <a hreflang="en" href="https://nextjs.org/docs/basic-features/script#off-loading-scripts-to-a-web-worker-experimental">Next.js framework has started to introduce this solution</a> that could increase Partytown's popularity.
 
-The previous sections showed that the responsibility for third-party negative impact is split between first and third-party developers. However, <a hreflang="en" href="https://developer.chrome.com/blog/third-party-scripts/#proposed-approach">browsers are also showing interest in optimizing the loading of third-party resources</a>. The proposals include better real user monitoring and developer tooling providing more data about the impact of third parties on their websites.
+The previous sections showed that the responsibility for third-party negative impact is split between first and third-party developers. However, <a hreflang="en" href="https://developer.chrome.com/blog/third-party-scripts#proposed-approach">browsers are also showing interest in optimizing the loading of third-party resources</a>. The proposals include better real user monitoring and developer tooling providing more data about the impact of third parties on their websites.
 
 {{ figure_markup(
   caption="Percent of third-party requests with Timing-Allow-Origin header header",
diff --git a/src/content/fr/2022/jamstack.md b/src/content/fr/2022/jamstack.md
index 01b47404459..faeca8b3fd4 100644
--- a/src/content/fr/2022/jamstack.md
+++ b/src/content/fr/2022/jamstack.md
@@ -75,7 +75,7 @@ Si vous n'êtes pas intéressé par les tenants et les aboutissants de comment n
 
 Nous savions que nous voulions mesurer: les sites qui chargent la plupart de leur contenu très rapidement, et qui peuvent être mis en cache. Après beaucoup d'expérimentation avec différentes méthodes de mesures, nous sommes parvenus à trouver quelques métriques spécifiques.
 
-**Largest Contentful Paint (LCP)**: nous avons la distribution de nous les temps LCP sur toutes les pages, récupérer la médiane de vrais données utilisateurs provenant du <a hreflang="en" href="https://developer.chrome.com/docs/crux/">Rapport Chrome UX</a>, et nous avons décidé que tous les site se trouvant égale ou sous la médiane, comptent comme "changeant la plupart de son contenu assez rapidement". Cela donnait 2.4 secondes sur les appareils portables, et 2.0 secondes sur les appareils de bureau.
+**Largest Contentful Paint (LCP)**: nous avons la distribution de nous les temps LCP sur toutes les pages, récupérer la médiane de vrais données utilisateurs provenant du <a hreflang="en" href="https://developer.chrome.com/docs/crux">Rapport Chrome UX</a>, et nous avons décidé que tous les site se trouvant égale ou sous la médiane, comptent comme "changeant la plupart de son contenu assez rapidement". Cela donnait 2.4 secondes sur les appareils portables, et 2.0 secondes sur les appareils de bureau.
 
 **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.
 
@@ -83,7 +83,7 @@ Nous savions que nous voulions mesurer: les sites qui chargent la plupart de leu
 
 **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.
 
-Nous avons d'abord pensé que nous avions besoin d'une autre mesure afin d'exclure les "petits" sites – sites qui chargent très rapidement car ce sont juste des pages "A venir bientôt" ou des pages "Hello world" que personne ne visiterait dans la vrai vie – mais les données de l'Archive HTTP est défini par leur <a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology/#popularity-eligibility">popularité selon les visites des utilisateurs de Chrome</a>, et très peu de ces sites sont assez souvent visités pour apparaître dans l'échantillon (même si example.com est dedans!).
+Nous avons d'abord pensé que nous avions besoin d'une autre mesure afin d'exclure les "petits" sites – sites qui chargent très rapidement car ce sont juste des pages "A venir bientôt" ou des pages "Hello world" que personne ne visiterait dans la vrai vie – mais les données de l'Archive HTTP est défini par leur <a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology#popularity-eligibility">popularité selon les visites des utilisateurs de Chrome</a>, et très peu de ces sites sont assez souvent visités pour apparaître dans l'échantillon (même si example.com est dedans!).
 
 Une bonne question est: pourquoi ne pas utiliser les valeurs <a hreflang="en" href="https://web.dev/articles/vitals">Core Web Vitals</a> pour ces métriques? Pour LCP, nos valeurs étaient presque les mêmes que CWV. Pour CLS, l'équipe CWV a explicitement <a hreflang="en" href="https://web.dev/defining-core-web-vitals-thresholds/#achievability-3">assoupli les exigences</a> (leur seuil est plus du double de la médiane) ce qui, nous pensions, n'étaient pas représentatif d'une expérience Jamstack. Nous avons donc décidé qu'il était plus équitable de choisir la médiane pour les deux. Et CWV n'a pas de métrique pour la "cacheabilité".
 
diff --git a/src/content/ja/2021/capabilities.md b/src/content/ja/2021/capabilities.md
index 79387ab560e..b6986975e40 100644
--- a/src/content/ja/2021/capabilities.md
+++ b/src/content/ja/2021/capabilities.md
@@ -229,7 +229,7 @@ sheets_gid="1372715282"
 }
 ```
 
-ウェブアプリのオリジン以外のオリジンを登録したい場合は、<a hreflang="en" href="https://web.dev/pwa-url-handler/#the-web-app-origin-association-file">所有権を確認する</a>必要があります。この機能は比較的初期の段階にあり、デスクトップのChromeとEdgeにのみ対応しています。URLハンドリングは現在、<a hreflang="en" href="https://developer.chrome.com/blog/origin-trials/">オリジン・トライアル</a>として提供されています。つまり、この機能はまだ一般的に利用できるものではありません。その代わり、開発者はこの実験的なAPIを使うために、まずOrigin Trialトークンに登録し、このトークンをウェブサイトと一緒に配信して、この機能を使うことを選択する必要があります。詳細は、<a hreflang="en" href="https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md">Web開発者向けOriginトライアルガイド</a> に掲載されています。
+ウェブアプリのオリジン以外のオリジンを登録したい場合は、<a hreflang="en" href="https://web.dev/pwa-url-handler/#the-web-app-origin-association-file">所有権を確認する</a>必要があります。この機能は比較的初期の段階にあり、デスクトップのChromeとEdgeにのみ対応しています。URLハンドリングは現在、<a hreflang="en" href="https://developer.chrome.com/blog/origin-trials">オリジン・トライアル</a>として提供されています。つまり、この機能はまだ一般的に利用できるものではありません。その代わり、開発者はこの実験的なAPIを使うために、まずOrigin Trialトークンに登録し、このトークンをウェブサイトと一緒に配信して、この機能を使うことを選択する必要があります。詳細は、<a hreflang="en" href="https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md">Web開発者向けOriginトライアルガイド</a> に掲載されています。
 
 {{ figure_markup(
 caption="デスクトップのWebサイトでは、URLハンドリングを使用しています。",
diff --git a/src/content/ja/2021/privacy.md b/src/content/ja/2021/privacy.md
index 8dfae7636f6..3cce4c5c5da 100644
--- a/src/content/ja/2021/privacy.md
+++ b/src/content/ja/2021/privacy.md
@@ -544,7 +544,7 @@ GoogleのPrivacy Sandbox構想の中では、さまざまな実験が行われ
 
 <a hreflang="ja" href="https://developer.chrome.com/ja/docs/privacy-sandbox/fledge/">_FLEDGE_</a>（第1回「グループ上の局所実行型判定」実験）は、広告ターゲティングに対応することを目指したものです。このAPIは、現在のバージョンのChrome<a hreflang="ja" href="https://developer.chrome.com/ja/docs/privacy-sandbox/fledge/">ローカルで個々の開発者で</a>試すことができますが、2021年10月現在、オリジントライアルは行われていません。
 
-<a hreflang="ja" href="https://developer.chrome.com/ja/docs/privacy-sandbox/trust-tokens/">_トラストトークン_</a> は、ウェブサイトがある閲覧状況から別の閲覧状況へと限られた量の情報を伝達し、パッシブ追跡なしで詐欺へ対抗できるようにするものです。私たちは、サードパーティのプロバイダーとして多くのサイトへ組み込まれていると思われる7つのオリジンで、最初の <a hreflang="en" href="https://developer.chrome.com/blog/third-party-origin-trials/">オリジン トライアル</a>（2022年5月に終了予定）が有効になっていることを確認しました。
+<a hreflang="ja" href="https://developer.chrome.com/ja/docs/privacy-sandbox/trust-tokens/">_トラストトークン_</a> は、ウェブサイトがある閲覧状況から別の閲覧状況へと限られた量の情報を伝達し、パッシブ追跡なしで詐欺へ対抗できるようにするものです。私たちは、サードパーティのプロバイダーとして多くのサイトへ組み込まれていると思われる7つのオリジンで、最初の <a hreflang="en" href="https://developer.chrome.com/blog/third-party-origin-trials">オリジン トライアル</a>（2022年5月に終了予定）が有効になっていることを確認しました。
 
 <a hreflang="en" href="https://github.com/WICG/CHIPS">_CHIPS_</a> (Cookies Having Independent Partitioned State) では、ウェブサイトがクロスサイトのクッキーを「パーティションド」としてマークし、トップレベルのサイトごとに別のクッキー入れへ入れられるようにします。（Firefoxでは、Cookieのパーティショニングについて、同様の <a hreflang="en" href="https://blog.mozilla.org/security/2021/02/23/total-cookie-protection/">_トータル・クッキー・プロテクト_</a> 機能がすでに導入されています）。2021年10月現在、CHIPSのオリジントライアルはありません。
 
diff --git a/src/content/ja/2021/pwa.md b/src/content/ja/2021/pwa.md
index f2e483a6cf2..32e872fde39 100644
--- a/src/content/ja/2021/pwa.md
+++ b/src/content/ja/2021/pwa.md
@@ -528,7 +528,7 @@ PWAの重要な点は、ユーザーがブラウザのURLバーへURLを入力
 このインストール可能な体験を配布する方法は、以下の通りです。
 
 - [ホーム画面に追加](https://developer.mozilla.org/docs/Web/Progressive_web_apps/Add_to_home_screen)機能により、ユーザーにPWAのインストールを促す。
-- <a hreflang="en" href="https://developer.chrome.com/docs/android/trusted-web-activity/">Trusted Web Activity (TWA)</a>（現在、Google PlayやMicrosoft Storeなど、あらゆるAndroidアプリストアで利用可能）でパッケージ化し、PWAをApp Storeにアップロードする。
+- <a hreflang="en" href="https://developer.chrome.com/docs/android/trusted-web-activity">Trusted Web Activity (TWA)</a>（現在、Google PlayやMicrosoft Storeなど、あらゆるAndroidアプリストアで利用可能）でパッケージ化し、PWAをApp Storeにアップロードする。
 
 次に、これらの技術に関連する統計データを紹介し、これらのトレンドの使用率と成長率を把握します。
 
@@ -573,7 +573,7 @@ WebViewベースのアプリはネイティブアプリと似ているように
 
 TWAを使えば、PWAをネイティブアプリケーションのシェルにパッケージ化し、いくつかのApp Storeにアップロードできます。WebViewベースのソリューションとは異なり、TWAは単なるレンダリングエンジンではなく、フルスクリーンモードで動作する完全なブラウザーとなります。そのため、機能が完全であり、常に最新であり、最新のウェブAPIにアクセスできることを意味します。
 
-開発者はPWAをTWAで直接ネイティブ アプリにパッケージ化し、<a hreflang="en" href="https://developer.chrome.com/docs/android/trusted-web-activity/integration-guide/">Android Studioを使用</a> できますが、このタスクをはるかに容易にするツールがいくつかあります。次に、そのうちの2つを分析します。PWA BuilderとBubblewrapです。
+開発者はPWAをTWAで直接ネイティブ アプリにパッケージ化し、<a hreflang="en" href="https://developer.chrome.com/docs/android/trusted-web-activity/integration-guide">Android Studioを使用</a> できますが、このタスクをはるかに容易にするツールがいくつかあります。次に、そのうちの2つを分析します。PWA BuilderとBubblewrapです。
 
 #### PWAビルダー
 
diff --git a/src/content/ja/2021/resource-hints.md b/src/content/ja/2021/resource-hints.md
index ae970a5ca47..27d4f9af31e 100644
--- a/src/content/ja/2021/resource-hints.md
+++ b/src/content/ja/2021/resource-hints.md
@@ -635,7 +635,7 @@ Chrome 95では、`preload`と`preconnect`に対して、<a hreflang="en" href="
 
 ### 優先順位付けのヒント
 
-優先度ヒントは、ページ内のリソースの相対的な重要度をブラウザに通知し、重要なリソースを優先してコアウェブバイタルを向上させることを目的としています。優先度ヒントは、`<img>` や `<script>` などのリソースに `importance` 属性を追加することで、ドキュメントのマークアップを通じて有効になります。`importance` 属性は `high`, `low`, `auto` の列挙を受け付け、これをリソースのタイプと組み合わせることで、ブラウザはヒューリスティックに基づいて最適なフェッチ優先度を割り当てることができるようになります。優先ヒントは、Chrome 96で<a hreflang="en" href="https://developer.chrome.com/blog/origin-trials/">オリジン・トライアル</a>として利用できます。
+優先度ヒントは、ページ内のリソースの相対的な重要度をブラウザに通知し、重要なリソースを優先してコアウェブバイタルを向上させることを目的としています。優先度ヒントは、`<img>` や `<script>` などのリソースに `importance` 属性を追加することで、ドキュメントのマークアップを通じて有効になります。`importance` 属性は `high`, `low`, `auto` の列挙を受け付け、これをリソースのタイプと組み合わせることで、ブラウザはヒューリスティックに基づいて最適なフェッチ優先度を割り当てることができるようになります。優先ヒントは、Chrome 96で<a hreflang="en" href="https://developer.chrome.com/blog/origin-trials">オリジン・トライアル</a>として利用できます。
 
 ## 結論
 
diff --git a/src/content/ja/2022/accessibility.md b/src/content/ja/2022/accessibility.md
index c39207ed006..4e249c74863 100644
--- a/src/content/ja/2022/accessibility.md
+++ b/src/content/ja/2022/accessibility.md
@@ -155,7 +155,7 @@ WCAGは、ウェブサイト内のテキストを最低でも200％までリサ
 ) }}
 
 他のユーザー好みのメディアクエリと同様に、多くのウェブサイトが強制色モードに基づいて調整を行っています。モバイルサイトの8%とデスクトップサイトの9%が `forced-colors` メディアクエリを使用してスタイルを変更していますが、古いIE11専用の `-ms-high-contrast` メディアクエリの使用率はモバイルとデスクトップの両方で20%以上です。
-これによってサイトがどの程度強制色モードをサポートしているかは分かりませんが、`forced-colors` メディアクエリが主要なブラウザでサポートされているのは[2020年から](https://caniuse.com/mdn-css_at-rules_media_forced-colors)であり、Windows以外のデバイスで[強制色モードのエミュレート](https://developer.chrome.com/docs/devtools/rendering/emulate-css?hl=ja)をサポートするのは2022年2月からであることを考えると、データはそれでもなお励みになります。
+これによってサイトがどの程度強制色モードをサポートしているかは分かりませんが、`forced-colors` メディアクエリが主要なブラウザでサポートされているのは[2020年から](https://caniuse.com/mdn-css_at-rules_media_forced-colors)であり、Windows以外のデバイスで[強制色モードのエミュレート](https://developer.chrome.com/docs/devtools/renderingemulate-css?hl=ja)をサポートするのは2022年2月からであることを考えると、データはそれでもなお励みになります。
 
 ## ナビゲーション
 
diff --git a/src/content/ja/2022/capabilities.md b/src/content/ja/2022/capabilities.md
index 98d9a7b2cc2..fff01f06639 100644
--- a/src/content/ja/2022/capabilities.md
+++ b/src/content/ja/2022/capabilities.md
@@ -379,7 +379,7 @@ GoogleのStadia、NVIDIAのGeForce Now、MicrosoftのXbox Cloud GamingなどのW
 
 プロジェクトフグには、Microsoft、Intel、Samsung、Googleなど多くのグループや個人が参加しています。
 
-Capabilities Projectについてもっと学ぶために、Chrome Developersブログの[この投稿](https://developer.chrome.com/blog/fugu-status/)をチェックしてください。
+Capabilities Projectについてもっと学ぶために、Chrome Developersブログの[この投稿](https://developer.chrome.com/blog/fugu-status)をチェックしてください。
 
 ## 結論
 
diff --git a/src/content/ja/2022/cdn.md b/src/content/ja/2022/cdn.md
new file mode 100644
index 00000000000..a1dc2a75d3e
--- /dev/null
+++ b/src/content/ja/2022/cdn.md
@@ -0,0 +1,375 @@
+---
+#See https://github.com/HTTPArchive/almanac.httparchive.org/wiki/Authors'-Guide#metadata-to-add-at-the-top-of-your-chapters
+title: CDN
+description: 2022年のWeb AlmanacのCDN章では、CDNの採用、主要なCDNプレイヤー、CDNがTLS、HTTP/2+、Brotli、およびクライアントヒントの採用に与える影響について説明しています。
+authors: [harendra, joeviggiano]
+reviewers: [ytkoka]
+analysts: [harendra, joeviggiano]
+editors: [tunetheweb]
+translators: [ksakae1216]
+results: https://docs.google.com/spreadsheets/d/1ySETT2IZ9ae5_VUphxUol2ZU3P1RJvcSVjDU5BgnK5A/
+harendra_bio: Haren BhandariはAmazon Web Servicesのソリューションアーキテクトです。Amazon Web Servicesに参加する前、HarenはAkamai Technologiesで働いており、CDNに関する深い経験を持っています。
+joeviggiano_bio: Joe ViggianoはAmazon Web Servicesのメディア＆エンターテイメントソリューションアーキテクトで、顧客が大規模にメディアコンテンツを配信するのを支援しています。
+featured_quote: CDNは多くのウェブサイトでスムーズなユーザーエクスペリエンスを提供するための重要な部分でした。COVID-19以降、実店舗のビジネスがオンラインに移行し、ウェブ会議、オンラインゲーム、ビデオストリーミングが増加したため、CDNの需要はさらに高まっています。
+featured_stat_1: 62%
+featured_stat_label_1: トップ1,000のサイトでCDNを使用しているサイト
+featured_stat_2: 3x
+featured_stat_label_2: 90パーセンタイルでCDNを使用したTLSネゴシエーションの高速化
+featured_stat_3: 47%
+featured_stat_label_3: CDNを通じてBrotliを使用しているドメイン
+---
+
+## 序章
+
+この章では、CDNの現状に関する洞察を提供します。CDNは、JavaScriptライブラリ、フォント、その他のコンテンツなどの静的およびサードパーティのコンテンツの配信を容易にすることで、小規模なサイトを含め、世界中のユーザーにコンテンツを提供する上でますます重要な役割を果たしています。この章で議論するCDNの重要な側面のもう1つは、CDNがTLSやHTTPバージョンなどの新しい標準の採用において果たす役割です。
+
+私たちは、CDNが将来においてもコンテンツの配信だけでなく、コンテンツのセキュリティにおいても重要な役割を果たし続けると考えています。ユーザーには、パフォーマンスとセキュリティの観点からCDNを見ることをオススメします。
+
+## CDNとは何か？
+
+_Content Delivery Network_（CDN）は、地理的に分散されたプロキシサーバーのネットワークです。CDNの目的は、ウェブコンテンツの高可用性とパフォーマンスを提供することです。これは、コンテンツをエンドユーザーに近い場所に配布することと、コンテンツを最適に配信するための先進技術をサポートすることによって達成されます。
+
+ビデオや画像などのウェブコンテンツの爆発的な増加により、CDNは多くのウェブサイトにおいてスムーズなユーザーエクスペリエンスを提供するための重要な部分となっています。COVID-19以降、実店舗のビジネスがオンラインに移行し、ウェブ会議、オンラインゲーム、ビデオストリーミングが増加したため、CDNの必要性はさらに高まっています。
+
+初期の頃、CDNは単なるプロキシサーバーのネットワークであり、以下の機能を果たしていました。
+
+1. コンテンツ（HTML、画像、スタイルシート、JavaScript、ビデオなど）をキャッシュする
+2. エンドユーザーがコンテンツにアクセスするためのネットワークホップを減らす
+3. TCP接続の終了をウェブプロパティをホスティングしているデータセンターからオフロードする
+
+これらは主に、ウェブ所有者がページのロード時間を改善し、これらのウェブプロパティをホスティングしているインフラからのトラフィックをオフロードするのに役立ちました。
+
+時が経つにつれて、CDNプロバイダーによって提供されるサービスはキャッシングや帯域幅/接続のオフロードを超えて進化しました。その分散性と広範な分散ネットワーク容量により、CDNは大規模な[Distributed Denial-of-Service (DDoS)](https://en.wikipedia.org/wiki/Denial-of-service_attack#Distributed_attack)攻撃を非常に効率的に処理することが証明されました。近年、エッジコンピューティングは別のサービスとして人気を博しています。多くのCDNベンダーは、ウェブ所有者がエッジで単純なコードを実行できるようにするエッジでのコンピュートサービスを提供しています。
+
+CDNベンダーによって提供されるその他のサービスには以下が含まれます。
+
+* クラウドホスト型[Web Application Firewalls (WAF)](https://ja.wikipedia.org/wiki/Web_Application_Firewall)
+* ボット管理ソリューション
+* クリーンパイプソリューション（データセンターのデータ洗浄）
+* 画像およびビデオ管理ソリューション
+
+エンドユーザーに近い場所でウェブアプリケーションのロジックとワークフローを進めることは、ウェブ所有者にとって利点があります。これにより、HTTP/HTTPSリクエストが取るラウンドトリップと帯域幅が削減されます。また、起点の瞬間的なスケーラビリティ要件も処理します。これによる副作用として、インターネットサービスプロバイダー（ISP）もスケーラビリティの管理から恩恵を受けるため、そのインフラ容量が向上します。
+
+### 注意事項と免責事項
+
+あらゆる観察研究と同様に、測定できる範囲と影響には限界があります。Web AlmanacのCDN使用に関する統計は、使用されている適用技術により焦点を当てており、特定のCDNベンダーのパフォーマンスや効果を測定することを目的としていません。これにより、私たちはどのCDNベンダーにも偏らないことを保証しますが、これはより一般化された結果であることも意味します。
+
+こちらが私たちのテスト[方法論](./methodology)の限界です。
+
+- **シミュレートされたネットワーク遅延：** トラフィックを合成的に形成する専用ネットワーク接続を使用します。
+
+- **単一地理的位置：** テストは単一のデータセンターから実行され、多くのCDNベンダーの地理的分散をテストすることはできません。
+
+- **キャッシュの効果：** 各CDNは独自の技術を使用し、多くの場合、セキュリティ上の理由からキャッシュのパフォーマンスを公開しません。
+
+- **ローカリゼーションと国際化：** 地理的分布と同様に、言語と地域固有のドメインの影響もこれらのテストでは不透明です。
+
+- **CDNの検出：** これは主にDNS解決とHTTPヘッダーを通じて行われます。ほとんどのCDNはDNS CNAMEを使用してユーザーを最適なデータセンターにマッピングします。ただし、一部のCDNはAnycast IPを使用するか、デリゲートされたドメインから直接のA+AAAA応答を使用し、DNSチェーンを隠します。その他の場合では、ウェブサイトが複数のCDNを使用してベンダー間でバランスを取ることが、私たちのクローラーの単一リクエストパスからは隠されています。
+
+これらすべてが私たちの測定に影響を与えます。
+
+もっとも重要なことは、これらの結果は特定の機能（たとえばTLSv1.3、HTTP/2）のサイトごとのサポートを反映していますが、実際のトラフィックの使用を反映していないことです。YouTubeは`www.example.com`よりも人気がありますが、どちらも私たちのデータセットでは同等に表示されます。
+
+これを念頭に置いて、CDNの文脈で意図的に測定されなかったいくつかの統計をここに示します。
+
+1. 最初のバイトまでの時間（TTFB）
+2. CDNラウンドトリップタイム
+3. Core Web Vitals
+4. 「キャッシュヒット」対「キャッシュミス」のパフォーマンス
+
+これらの一部はHTTPアーカイブのデータセットで測定可能であり、他はCrUXデータセットを使用して測定可能ですが、方法論の限界と一部のサイトが複数のCDNを使用しているため、測定が困難であり、誤って帰属される可能性があります。これらの理由から、この章ではこれらの統計を測定しないことにしました。
+
+モバイルとデスクトップの間に顕著な違いは見られなかったため、繰り返しを避けるため、この章で提供されるデータはとくに注記がない限り主にモバイルの使用に関するものです。
+
+## CDNの採用
+
+ウェブページは以下の主要なコンポーネントで構成されています。
+
+1. ベースHTMLページ（たとえば、`www.example.com/index.html`は、しばしば`www.example.com`のようなよりフレンドリーな名前で提供されます）。
+2. 主ドメイン（`www.example.com`）およびサブドメイン（たとえば、`images.example.com`、`assets.example.com`）にある画像、CSS、フォント、JavaScriptファイルなどの組み込みファーストパーティコンテンツ。
+3. サードパーティドメインから提供されるサードパーティコンテンツ（たとえば、Googleアナリティクス、広告）。
+
+{{ figure_markup(
+  image="cdn-usage-hosted.png",
+  caption="モバイルでのCDNの使用とホストされたリソース。",
+  description="オリジンとCDNによって分割されたCDN使用とホストされたリソースの棒グラフ。HTMLコンテンツの場合、リクエストの71%がオリジンからで29%がCDNからです。サブドメインコンテンツでは、53%がオリジンからで47%がCDNからです。そしてサードパーティコンテンツでは、33%がオリジンからで67%がCDNからです。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=41983383&format=interactive",
+  sheets_gid="2085205637",
+  sql_file="top_cdns.sql"
+  )
+}}
+
+上のグラフは、デスクトップでもほぼ同じ数字が見られたため、モバイルの各種リクエストのCDN対ホストリソースの分割を示しています。CDNはしばしば画像、スタイルシート、JavaScript、フォントなどの静的コンテンツの配信に利用されます。この種のコンテンツは頻繁に変更されないため、CDNのプロキシサーバーでキャッシュするのに適しています。とくにサードパーティコンテンツについては、この種のリソースでCDNがより頻繁に使用されています。
+
+CDNは静的でないコンテンツの配信にもパフォーマンスを向上させることができます。CDNはルートを最適化し、もっとも効率的な輸送手段を使用することが多いですが、HTMLの配信の使用は他の2つのタイプに比べてかなり遅れています。
+
+{{ figure_markup(
+  image="cdn-usage-hosted-comparison.png",
+  caption="モバイルでのCDNから提供されるコンテンツのトレンド",
+  description="CDNから提供されるコンテンツの過去数年のトレンドを示すグラフです。CDNの使用は増加傾向にあります。サブドメインから提供されるコンテンツで大きな増加が見られます。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=2141710369&format=interactive",
+  sheets_gid="2085205637",
+  sql_file="top_cdns.sql"
+  )
+}}
+
+[2021年](../2021/cdn)と比較して、CDNの使用が着実に増加していることがわかりました。サブドメインから提供されるコンテンツのCDN使用に大きな増加があり、HTMLの増加は小さく、サードパーティのCDN使用は比較的一定でした。
+
+この増加の背後にある潜在的な理由は次のとおりです。
+
+* パンデミック後、多くのビジネスがその大部分をオンラインに移行しました。これによりサーバーに多くの負担がかかり、静的コンテンツをCDNを通じて提供する方が、キャッシングと高速配信によってオフロードする方がはるかに効率的であることがわかりました。
+* この増加は2021年には見られませんでした。多くのビジネスが問題の最適な解決策を見つけ出そうとしていたからです。実際、サブドメインとサードパーティタイプのCDN使用に減少が見られました。
+* サイトは自社ドメインの代わりにサードパーティドメインを通じてサードパーティコンテンツを提供することに依存しました。この期間にサードパーティドメインから提供されるコンテンツの量が3%増加したという事実がこの仮説を支持しています。
+
+ベースHTMLページに関しては、伝統的なパターンはベースHTMLをオリジンから提供することで、このパターンはほとんどのベースページが引き続きオリジンから提供されるため続いています。しかし、CDNから提供されるベースページが4%増加しました。ベースHTMLページがCDNから提供される傾向は明らかに上昇しています。
+
+この背後にある可能性のある理由は次のとおりです。
+* CDNは、顧客体験を向上させ、ユーザーを引き付ける上で重要なベースHTMLページのロード時間を改善できます。
+* CDNプロバイダーによる分散DNSの使用は、よりシンプルで速いです。
+* ベースHTMLページを含むほとんどのコンテンツをCDNを通じてプッシュする場合、災害復旧の計画が容易になります。CDNは通常、プライマリサイトが不安定または利用不可能になった場合に自動的に代替サイトに切り替えるフェイルオーバー機能を提供します。
+
+サイトの人気に基づいて、さまざまなタイプのコンテンツでCDNの採用を観察しましたが、以下ではサイトの人気に基づいた異なる視点からこのデータを見ていきます。
+
+{{ figure_markup(
+  image="cdn-usage-ranking-desktop.png",
+  caption="モバイルでのサイトの人気によるCDNの使用。",
+  description="GoogleのChrome UX Reportに基づいて、トップ1,000、10,000、100,000、100万、1000万の人気サイトごとにモバイルサイトのCDN使用を分類した棒グラフです。トップ1000、10,000のサイトでCDNの採用率は60%以上です。人気が低いサイトでは採用率が低下しています。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=1175849008&format=interactive",
+  sheets_gid="1207165933",
+  sql_file="cdn_usage_by_site_rank.sql"
+  )
+}}
+
+GoogleのChrome UX Reportからのデータに基づいてウェブサイトの人気によるCDNの使用を見ると、トップ1,000-10,000がCDNのもっとも高い使用率を示しています。ランクの高いサイトでは、所有者の企業がパフォーマンスとその他の利点のためにCDNに投資していることが理解できますが、トップ1,000,000のサイトでも、CDNを通じて配信されるコンテンツの量が[2021年と比較して](../2021/cdn#fig-3)約7%増加しています。人気の低いサイトでのCDNの使用の増加は、CDNの無料または手頃なオプションの増加と、多くのホスティングソリューションがサービスにCDNを組み込んでいるためと考えられます。
+
+## 主要なCDNプロバイダー
+
+CDNプロバイダーは大きく2つのセグメントに分類できます。
+
+1. 汎用CDN（Akamai、Cloudflare、CloudFront、Fastlyなど）
+2. 特定目的用CDN（Netlify、WordPressなど）
+
+汎用CDNは大衆市場の要求に対応しています。その提供内容には以下が含まれます。
+
+- ウェブサイトの配信
+- モバイルアプリAPIの配信
+- ビデオストリーミング
+- エッジコンピューティングサービス
+- ウェブセキュリティの提供
+
+これはより多くの業界に訴求し、データに反映されています。
+
+{{ figure_markup(
+  image="top-cdns-html.png",
+  caption="モバイルでのHTMLリクエストに対する主要CDN。",
+  description="HTMLリクエストを提供する主要CDNプロバイダーを示すボックスプロット。Cloudflareがリストのトップで、HTMLリクエストの52％を提供し、次にGoogleが22％、Fastlyが9％、CloudFrontが6％、AkamaiとAutomatticが3％です。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=1688291462&format=interactive",
+  sheets_gid="2085205637",
+  sql_file="top_cdns.sql"
+  )
+}}
+
+上記の図は、ベースHTMLリクエストに対する主要なCDNプロバイダーを示しています。このカテゴリーでトップのベンダーはCloudflare、Google、Fastly、Amazon CloudFront、Akamai、そしてAtomatticです。
+
+{{ figure_markup(
+  image="top-cdns-subdomain.png",
+  caption="モバイルでのサブドメインリクエストに対する主要CDN。",
+  description="サブドメインリクエストを提供する主要CDNプロバイダーを示すボックスプロット。Cloudflareがリストのトップで、サブドメインリクエストの35％を提供し、次にCloudFrontが18％、Googleが17％、Automatticが9％、Akamaiが5％、Fastlyが3％です。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=1743984972&format=interactive",
+  sheets_gid="2085205637",
+  sql_file="top_cdns.sql"
+  )
+}}
+
+サブドメインリクエストについては、AmazonやGoogleなどのプロバイダーの使用が増えています。これは多くのユーザーが提供されるクラウドサービスでコンテンツをホストしており、クラウドサービスとともにCDNオファリングを利用しているためです。これにより、ユーザーはアプリケーションをスケールし、アプリケーションのパフォーマンスを向上させることができます。
+
+{{ figure_markup(
+  image="top-cdns-3p.png",
+  caption="モバイルでのサードパーティリクエストに対する主要CDN。",
+  description="サードパーティリクエストを提供する主要CDNプロバイダーを示すボックスプロット。Googleがリストのトップで、サードパーティリクエストの48％を提供し、次にCloudlareが15％、CloudFrontが12％、Akamaiが6％、Facebookが5％、Fastlyが4％です。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=1502237125&format=interactive",
+  sheets_gid="2085205637",
+  sql_file="top_cdns.sql"
+  )
+}}
+
+サードパーティドメインを見ると、トップのCDNプロバイダーで異なる傾向が見られます。Googleが汎用CDNプロバイダーの前にリストのトップに立っています。リストにはFacebookも目立っています。これは、多くのサードパーティドメインの所有者が他の業界よりもCDNを必要としているという事実に支えられています。GoogleやFacebookのような大手サードパーティプロバイダーにとっては、特定のコンテンツ配信ワークフローに最適化された特定目的用CDNを構築する必要があります。特定目的用CDNは、特定の市場セグメントの正確な要件に応えるために設計されています。
+
+たとえば、広告を配信するために特別に構築されたCDNは、以下に最適化されます。
+
+- 高い入出力（I/O）操作
+- [ロングテール](https://ja.wikipedia.org/wiki/%E3%83%AD%E3%83%B3%E3%82%B0%E3%83%86%E3%83%BC%E3%83%AB)コンテンツの効果的な管理
+- サービスを必要とするビジネスに地理的に近い
+
+これは、特定目的用CDNが汎用CDNソリューションとは対照的に、特定の市場セグメントの正確な要件を満たすことを意味します。汎用ソリューションはより広範な要件を満たすことができますが、特定の業界や市場に最適化されているわけではありません。
+
+## TLSの使用
+
+CDNがリクエストレスポンスワークフローに設定されると、エンドユーザーのTLS接続はCDNで終了します。その後、CDNは独立した2つ目のTLS接続を設定し、この接続はCDNからオリジンホストへと続きます。CDNワークフローのこの中断により、CDNはエンドユーザーのTLSパラメーターを定義できます。CDNはインターネットプロトコルの自動更新も提供する傾向があります。これにより、Webオーナーはオリジンを変更することなくこれらの利点を受け取ることができます。
+
+### TLS採用の影響
+
+下記のグラフは、CDNから提供されるコンテンツとオリジンから提供されるコンテンツとを比較した際、最新バージョンのTLSの採用率がCDNの方がはるかに高いことを示しています。
+
+{{ figure_markup(
+  image="tls-version-mobile.png",
+  caption="HTML（モバイル）のTLSバージョンの分布。",
+  description="CDNおよびオリジンによって提供されるモバイルリクエストのTLSバージョンの使用状況の棒グラフ。CDNはリクエストの87%をTLS 1.3で、13%をTLS 1.2で提供しています。一方、オリジンはリクエストの42%をTLS 1.3で、58%をTLS 1.2で提供しています。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=755535896&format=interactive",
+  sheets_gid="2008253446",
+  sql_file="distribution_of_tls_versions_cdn_vs_origin.sql"
+  )
+}}
+
+[2021年のデータ](../2021/cdn#TLS採用の影響)と比較すると、モバイルHTMLコンテンツにおけるTLS v1.3の採用は5%増加していますが、オリジンから提供されるコンテンツの場合はTLS v1.3の採用が10%増加しています。
+
+{{ figure_markup(
+  image="tls-version-mobile-3p.png",
+  caption="サードパーティリクエスト（モバイル）のTLSバージョンの分布。",
+  description="デスクトップのサードパーティリクエストのTLSバージョンの使用状況の棒グラフで、CDNおよびオリジンによって提供されます。CDNはサードパーティのリクエストの88%をTLS 1.3で、12%をTLS 1.2で提供しています。一方、オリジンはリクエストの26%をTLS 1.3で、74%をTLS 1.2で提供しています。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=1995157146&format=interactive",
+  sheets_gid="2008253446",
+  sql_file="distribution_of_tls_versions_cdn_vs_origin.sql"
+  )
+}}
+
+現在のセキュリティ環境では、コンテンツが最新のTLSバージョンを介して配信されることが重要です。上記のデータから、CDNを介してTLS v1.3への移行がオリジンに比べてはるかに迅速であったことがわかります。これはCDNを使用してコンテンツを配信する際の付加的なセキュリティ利点を示しています。
+
+### TLSのパフォーマンスへの影響
+
+一般的な論理では、HTTPSリクエストレスポンスが通過するホップの数が少ないほど、往復の時間は速くなるとされています。
+
+{{ figure_markup(
+  image="tls-negotiation-desktop.png",
+  caption="HTML TLSネゴシエーション - CDN対オリジン（デスクトップ）",
+  description="この棒グラフは、CDNとオリジンでの10番目、25番目、50番目、75番目、90番目のパーセンタイルにわたるTLS接続時間（ミリ秒）についての洞察を提供します。グラフからわかるように、TLSネゴシエーション時間は一般にCDNの方が速いです。",
+  chart_url="https://docs.google.com/spreadsheets/u/1/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=1669978107&format=interactive",
+  sheets_gid="1644442668",
+  sql_file="distribution_of_tls_time_cdn_vs_origin.sql"
+  )
+}}
+
+{{ figure_markup(
+  image="tls-negotiation-mobile.png",
+  caption="HTML TLSネゴシエーション - CDN対オリジン（モバイル）",
+  description="この棒グラフは、CDNとオリジンでの10番目、25番目、50番目、75番目、90番目のパーセンタイルにわたるTLS接続時間（ミリ秒）についての洞察を提供します。グラフからわかるように、TLSネゴシエーション時間は一般にCDNの方が速いです。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=1577806460&format=interactive",
+  sheets_gid="1644442668",
+  sql_file="distribution_of_tls_time_cdn_vs_origin.sql"
+  )
+}}
+
+上記の図からわかるように、TLSネゴシエーション時間はCDNを利用する場合に一般にはるかに優れています。これは、デスクトップとモバイルのデータを比較した場合、さらに顕著で、[_Round Trip Time_ (RTT)](./methodology#webpagetest)が使用されるモバイルクローラーの結果、TLSネゴシエーション時間がはるかに長くなります。
+
+CDNはTLS接続時間を大幅に短縮するのに役立っています。これは、エンドユーザーに近いことと、TLSネゴシエーションを最適化する新しいTLSプロトコルを採用しているためです。CDNはすべてのパーセンタイルでオリジンに対して優位性を持っています。P10およびP25では、CDNはオリジンよりもTLS設定時間で約1.5倍速いです。中央値を超えると、CDNはモバイルで約2倍、デスクトップで約3倍速くなります。90番目のパーセンタイルのユーザーは、直接オリジン接続の50番目のパーセンタイルのユーザーよりもパフォーマンスが良いでしょう。
+
+これは、すべてのサイトが現在TLSを使用していることを考慮するととくに重要です。この層での最適なパフォーマンスは、TLS接続に続く他のステップにとって不可欠です。この点で、CDNは直接オリジン接続に比べてより多くのユーザーを低いパーセンタイルブラケットに移動させることができます。
+
+## HTTP/2+ の採用
+
+HTTP/2の仕様は2015年にはじめて導入され、同年の終わりまでにほとんどの主要ブラウザが採用しました。HTTPアプリケーション層プロトコルは1997年のHTTP 1.1以来更新されておらず、それ以降、Webトラフィックの傾向、コンテンツタイプ、コンテンツサイズ、ウェブサイトデザイン、プラットフォーム、モバイルアプリなどが大きく進化しました。したがって、現代のWebトラフィックの要件を満たすことができるプロトコルが必要であり、そのプロトコルはHTTP/2として実現されました。
+
+HTTP/2のハイプと遅延の削減などの機能の約束にもかかわらず、採用は新しいアプリケーションプロトコルをサポートするためにサーバー側の更新に依存していました。CDNは、Webオーナーのために新しい実装の課題を橋渡しする手助けをすることができ、これはさらに新しいHTTP/3プロトコルにも当てはまります。HTTP接続はCDNレベルで終了し、これによりWebオーナーは自身のインフラストラクチャをアップグレードする必要なく、自分のウェブサイトやサブドメインをHTTP/2およびHTTP/3で配信する能力を持つようになります。新しいTLSバージョンの採用においても同様の利点が見られました。
+
+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>
+
+{{ figure_markup(
+  image="cdn-http-versions-mobile.png",
+  caption="HTML（モバイル）のHTTPバージョンの分布。",
+  description="この棒グラフは、モバイルHTMLリクエストにおけるCDNとオリジンのHTTPバージョンの採用を示しています。CDNから提供されたモバイルHTMLリクエストの84%がHTTP/2またはそれ以上のプロトコルで提供されましたが、オリジンから提供されたリクエストでは43%がHTTP/2またはそれ以上のプロトコルで提供されました。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=1385171364&format=interactive",
+  sheets_gid="542001559",
+  sql_file="distribution_of_http_versions_cdn_vs_origin.sql"
+  )
+}}
+
+上のグラフには、CDNを使用しているドメインと使用していないドメインとの間に明確な対照があり、CDNを使用しているドメインのHTTP/2+の採用率が高くなっています。
+
+2021年には、[オリジンから提供されるコンテンツの約40%がHTTP/2を採用していました](../2021/cdn#HTTP/2+（HTTP/2以上）の採用)が、同時期にCDNから提供されるコンテンツの81%がHTTP/2を通じて提供されました。オリジンのこの数値は3ポイント増加しましたが、CDNの場合は6ポイント増加し、すでに存在していたかなりの差がさらに広がりました。これは、CDNがウェブサイトオーナーが初期段階から新しいプロトコルを利用できるようにする方法を示しています。
+
+{{ figure_markup(
+  image="cdn-http-versions-mobile-3p.png",
+  caption="サードパーティリクエスト（モバイル）のHTTPバージョンの分布。",
+  description="この棒グラフは、モバイルのサードパーティリクエストにおけるCDNとオリジンのHTTPバージョンの採用を示しています。これらのサードパーティリクエストのCDNから提供されたものの88%がHTTP/2またはそれ以上のプロトコルで提供されましたが、オリジンから提供されたリクエストでは50%がHTTP/2またはそれ以上のプロトコルで提供されました。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=983285021&format=interactive",
+  sheets_gid="542001559",
+  sql_file="distribution_of_http_versions_cdn_vs_origin.sql"
+  )
+}}
+
+サードパーティドメインは新しいプロトコルのサポートにさらに迅速に対応していることが以前の研究で見られました。2022年には、サードパーティドメインのHTTP/1.1のシェアがさらに減少しましたが、今年使用されたプロトコルの大部分を特定できなかったため、さらなる調査が必要です。
+
+サードパーティドメインはすべてのネットワーク条件で一貫したパフォーマンスを必要としており、ここでHTTP/2+が価値を加えます。2022年6月には、インターネットエンジニアリングタスクフォース（IETF）が[HTTP/3 RFC](https://www.theregister.com/2022/06/07/http3_rfc_9114_published/)を公開し、WebをTCPからUDPに移行しました。多くのCDNプロバイダーはHTTP/3のサポートを公式のRFC公開前に迅速に採用しており、時間が経つにつれてウェブオーナーがHTTP/3を採用することが見られるでしょう。とくにモバイルネットワークトラフィックがインターネットトラフィックの大部分を占める場合には、2023年にさらなる洞察をお届けします。
+
+## Brotliの採用
+
+インターネット経由で配信されるコンテンツは、ペイロードサイズを削減するために圧縮を使用します。ペイロードが小さいほど、サーバーからエンドユーザーへのコンテンツの配信が速くなります。これにより、ウェブサイトの読み込みが速くなり、エンドユーザーの体験が向上します。画像については、JPEG、WEBP、AVIFなどの画像ファイルフォーマットによって圧縮が処理されます。これについての詳細は[メディア](./media)章を参照してください。HTML、JavaScript、スタイルシートなどのテキストWebアセットについては、従来[_Gzip_](https://ja.wikipedia.org/wiki/Gzip)ファイルフォーマットによって圧縮が行われていました。Gzipは1992年から存在しており、テキストアセットのペイロードを小さくするのに役立っていましたが、新しいテキストアセット圧縮は、より新しい[_Brotli_](https://ja.wikipedia.org/wiki/Brotli)圧縮フォーマットを使用することでGzipよりも優れた結果をもたらすことができます。
+
+TLSやHTTP/2の採用と同様に、BrotliはWebプラットフォーム全体で段階的に採用されてきました。この記事を書いている時点で、Brotliは<a hreflang="en" href="https://caniuse.com/brotli">世界中のWebブラウザの96%以上でサポートされています</a>。しかし、すべてのウェブサイトがテキストアセットをBrotliフォーマットで圧縮しているわけではありません。これは、サポートが不足していることと、Brotliフォーマットでテキストアセットを圧縮するのに必要な時間がGzip圧縮と比較して長くなることが理由です。また、古いプラットフォームでBrotliフォーマットをサポートしていない場合にGzip圧縮アセットを提供できるように、ホスティングインフラストラクチャには後方互換性が必要であり、これが複雑さを増す原因となります。
+
+この影響は、CDNを使用しているウェブサイトと使用していないウェブサイトを比較するときに観察されます。
+
+{{ figure_markup(
+  image="cdn-compression-mobile.png",
+  caption="圧縮タイプの分布（モバイル）。",
+  description="この棒グラフは、モバイルリクエストにおけるCDNとオリジンでのBrotliの採用を示しています。CDNはリクエストの47%をBrotli圧縮フォーマットで、57.3%をgzip圧縮フォーマットで提供しました。一方、オリジンはリクエストの25%をBrotli圧縮フォーマットで、77%をgzip圧縮フォーマットで提供しました。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=1836100530&format=interactive",
+  sheets_gid="2043216080",
+  sql_file="distribution_of_compression_types_cdn_vs_origin.sql"
+  )
+}}
+
+CDNとオリジンはともに、[前年と比較して](../2021/cdn#Brotli採用)Brotliの採用が増加しています。CDNでのBrotliの採用は5ポイント増加し、オリジンはほぼ4ポイント増加しました。この傾向が2023年に続くか、または飽和点に達したかどうかを確認することができるでしょう。
+
+## クライアントヒントの採用
+
+_Client Hints_ は、Webサーバーがクライアントから積極的にデータをリクエストできるようにし、HTTPヘッダーの一部として送信されます。クライアントは、デバイス、ユーザーエージェントの設定、ネットワーク情報などを提供することがあります。提供された情報に基づいて、サーバーは要求するクライアントに応答するための最適なリソースを決定できます。クライアントヒントは最初にGoogle Chromeブラウザで導入され、他のChromiumベースのブラウザもこれを採用していますが、他の人気ブラウザではクライアントヒントのサポートが限定的であったり、まったくなかったりします。
+
+CDN、オリジンサーバー、クライアントブラウザがすべてクライアントヒントを適切に利用するためには、サポートが必要です。このフローの一部として、CDNはクライアントに `Accept-CH` HTTPヘッダーを提示して、クライアントが後続のリクエストに含めるべきクライアントヒントをリクエストできます。我々は、CDNがこのヘッダーをリクエスト内に提供したクライアントのレスポンスを測定し、テストの一環として記録されたすべてのCDNリクエストでそれを測定しました。
+
+{{ figure_markup(
+  image="cdn-client-hints-mobile.png",
+  caption="クライアントヒントの比較（モバイル）。",
+  description="この棒グラフは、CDNでのクライアントヒントの使用状況を示しています。現在、リクエストの0.43%のみがクライアントヒントを持っています",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=1567266649&format=interactive",
+  sheets_gid="2048261739",
+  sql_file=""
+  )
+}}
+
+デスクトップとモバイルの両方のクライアントで、クライアントヒントの使用率は1%未満で、クライアントヒントの採用はまだ初期段階にあることを示しています。
+
+## 画像フォーマットの採用
+
+CDNは伝統的に、画像などの静的コンテンツをキャッシュ、圧縮、配信するために使用されてきました。それ以来、多くのCDNは、さまざまな使用例に最適化するために、画像をフォーマットとサイズの両方で動的に変更する能力を追加しています。
+
+これは、ユーザーエージェントやクライアントヒントに基づいて自動的に、クエリ文字列に追加パラメーターを送信することで実行される場合があります。これにより、エッジでの計算が画像を解釈し、応答に応じて画像を変更します。これによりサイト運営者は1つの高解像度画像をアップロードし、サムネイルなど、低品質または低解像度の画像が必要な場合に、画像を動的に変更できます。
+
+{{ figure_markup(
+  image="cdn-image-formats-mobile.png",
+  caption="画像フォーマットの分布（モバイル）。",
+  description="この棒グラフは、モバイルリクエストにおけるCDNとオリジンでのBrotliの採用を示しています。CDNはリクエストの42.6%をBrotli圧縮フォーマットで、57.3%をgzip圧縮フォーマットで提供しました。一方、オリジンはリクエストの21.2%をBrotli圧縮フォーマットで、78.7%をgzip圧縮フォーマットで提供しました。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vRZQqyyKiQWgICD_a0WaEAmfZyFN_Zi3wVuQnZxsXqwZ_1JQg2x7GpRw4CTkX4gKvurzoCQ6YokkdpM/pubchart?oid=293872923&format=interactive",
+  sheets_gid="571877353"
+  )
+}}
+
+デスクトップとモバイルの両方で、主要な画像フォーマットはJPG（JPEG）とPNGでした。JPGはサイズを最適化するためのロスリ圧縮ファイルフォーマットを提供します。PNGまたはポータブルグラフィックスフォーマットはロスレス圧縮をサポートし、画像が圧縮されてもデータが失われることはありませんが、画像全体のサイズはJPGよりも大きくなります。JPGとPNGの詳細については、[Adobeのウェブサイト](https://www.adobe.com/creativecloud/file-types/image/comparison/jpeg-vs-png.html)を訪れてください。
+
+## 結論
+
+過去数年にわたる我々の継続的な研究から、CDNは、ウェブサイトオーナーがオリジンから世界中のどのユーザーにもコンテンツを確実に配信するために重要な役割を果たしているだけでなく、新しい[セキュリティ](./security)およびWeb標準の採用にも大きな役割を果たしていることがわかります。
+
+一般的に、CDNの使用率は全体的に増加しています。TLS 1.3のような新しいウェブセキュリティ標準の採用においても、CDNはその採用を大いに促進しており、CDNからのトラフィックのほとんどがTLS 1.3を使用していることが確認されています。
+
+HTTP/2やBrotli圧縮など、新しいWeb標準やWeb技術の採用に関しても、CDNがリードしていることが見られました。CDNを利用して提供されるウェブサイトの大部分がこれらの新しい標準を採用していることが確認されました。エンドユーザーの観点から見ると、これらは非常にポジティブな進展であり、彼らは安全にサイトを利用しながら、最適なユーザー体験を得ることができるでしょう。
+
+今年からはクライアントヒントや画像フォーマットの採用など、新しい指標にも注目しています。来年のデータ収集が進むにつれ、より多くの洞察を得ることができるでしょう。
+
+CDNについて外部から得られる洞察には限界があり、その内部で動作する「秘密のソース」を知ることは困難です。しかし、我々はドメインをクロールし、CDNを使用しているサイトとそうでないサイトを比較しました。その結果、CDNがネットワーク層からアプリケーション層に至るまで、新しいWebプロトコルの採用を促進していることがわかりました。
+
+CDNのこの役割は非常に価値があり、今後も続くでしょう。CDNプロバイダーは<a hreflang="en" href="https://www.ietf.org/">インターネットエンジニアリングタスクフォース</a>の重要な一部であり、インターネットの未来を形作る手助けをしています。彼らは今後も、インターネット対応産業がスムーズかつ確実に、そして迅速に運営できるように、重要な役割を果たし続けるでしょう。
+
+来年のデータ収集が進むことを楽しみにしており、読者の皆様に有用な洞察を提供できることを期待しています。
diff --git a/src/content/ja/2022/http.md b/src/content/ja/2022/http.md
new file mode 100644
index 00000000000..80601505fba
--- /dev/null
+++ b/src/content/ja/2022/http.md
@@ -0,0 +1,255 @@
+---
+#See https://github.com/HTTPArchive/almanac.httparchive.org/wiki/Authors'-Guide#metadata-to-add-at-the-top-of-your-chapters
+title: HTTP
+description: 2022年のWeb AlmanacのHTTP章では、ウェブ全体で使用されているHTTPの歴史的バージョンに関するデータと、HTTP/2やHTTP/3を含む新しいバージョンの増加について取り上げています。また、HTTPライフサイクルの重要な指標の検証も行っています。
+authors: [paivaspol]
+reviewers: [tunetheweb, rmarx, LPardue]
+analysts: [paivaspol]
+editors: [tunetheweb]
+translators: [ksakae1216]
+paivaspol_bio: Vaspol RuamviboonsukはMicrosoftのソフトウェアエンジニアです。彼はミシガン大学でウェブページの読み込み速度を向上させるシステムに関する研究を行い、博士号を取得しました。彼と<a hreflang="en" href="https://www.linkedin.com/in/vaspol-ruamviboonsuk-7898b824/">LinkedIn</a>で繋がることができます。
+results: https://docs.google.com/spreadsheets/d/1NJrPOjBoJSDsHV0rAHpcZ9qBUgy6RVG3QtvbTqrj5_o/
+featured_quote: この1年はHTTPプロトコルにとって事件が多い年でした、とくにHTTP/3が標準化されたことによります。私たちは引き続き高いHTTP/2の利用を観察しており、ウェブサーバーからの強力な今後のHTTP/3サポートを見ています。
+featured_stat_1: 77%
+featured_stat_label_1: HTTP/2以上で提供されるリクエスト
+featured_stat_2: 1.5%
+featured_stat_label_2: 103 Early Hintsを採用しているウェブサイト
+featured_stat_3: 50%
+featured_stat_label_3: HTTP/3サポートを持つリクエストの増加
+---
+
+## 序章
+
+HTTPはウェブエコシステムの基盤であり、データ交換の基礎を提供し、さまざまなタイプのインターネットサービスを可能にします。とくに過去数年間で、HTTP/2や最近ではHTTP/3の導入により、いくつかの進化を遂げています。HTTP/2は、HTTP/1.1の同時に処理できるリクエストの数が限られているといった欠点を解決しようとしました。一見すると、HTTP/3はHTTP/2と似ておりセマンティクスは同じですが、内部的にはTCPの代わりにQUICをトランスポートプロトコルとして利用する点で、先行するバージョンと根本的に異なります。
+
+HTTP/2がHTTP/3の基礎を提供するため、HTTP/2 Push、優先順位付け、多重化などのHTTP/2の主要機能を分析し、それらがどれだけまだ使用されているかを理解します。また、これらの機能のさまざまな展開経験からの事例研究も提示します。たとえば、HTTP/2 Pushでは、ウェブサーバーがクライアントの要求前にリソースのレスポンスを先取りして送信できます。
+
+プッシュと優先順位付けは理論的にはエンドユーザーにとって有益ですが、使用するのが難しい場合があります。新しい技術について議論し、パフォーマンスが低いHTTP/2の機能の代替として使用できる可能性があります。たとえば、103 Early Hintsレスポンスは、先取りリソースフェッチの同じパフォーマンス目標を達成するHTTP/2サーバープッシュの代替手段を提供します。
+
+最後に、HTTP/3がHTTP/2をどのように改善しているか、また2021年からのいくつかの増加を観察するHTTP/3の現在のサポートについて分析しながら議論します。この章で提供されるデータポイントが、将来のトレンドや新しい技術に関する洞察を提供し、開発者がユーザー体験を向上させるために実験できる新しい技術への指針となることを願っています。
+
+## HTTPの進化
+
+HTTPはウェブの通信を支えるもっとも重要なインターネットプロトコルの1つです。最初の3バージョン（0.9、1.0、1.1）ではテキストベースのプロトコルとして始まりました。その拡張性により、HTTP/1.1は2015年まで15年間現行のHTTPバージョンでした。
+
+HTTP/2は、テキストベースのプロトコルからバイナリベースのものへと進化したHTTPの大きなマイルストーンでした。HTTP/1.1がシリアルなリクエストとレスポンスの交換のみをサポートするのに対し、HTTP/2は並行処理をサポートします。クライアントとサーバーは、リクエストとレスポンスをバイナリフレームのストリームとして表現します。ストリームには一意の識別子があり、フレームを多重化してインターリーブできます。
+
+HTTPの最新バージョンはHTTP/3で、最近<a hreflang="en" href="https://www.rfc-editor.org/rfc/rfc9114.html">2022年6月にIETFによって標準化されました</a>。HTTP/3はHTTP/2と同じ機能を実装していますが、インターネット上で輸送される方法が重要な違いです。HTTP/3はQUIC上に構築されており、QUICはUDPベースのプロトコルで、HTTP/2が損失の多いネットワークで直面するパフォーマンスの問題のいくつかを軽減します。
+
+## HTTP/2の採用
+
+年々導入されてきたさまざまなHTTPバージョンをふまえ、HTTPバージョンの採用状況の現状から説明します。2022年の __Web Almanac__ データセットのすべてのリソースを取り、それぞれのリソースがどのHTTPバージョンで提供されたかを特定することによって、HTTPバージョンの使用状況を測定します。
+
+しかし、設定上、クライアントがHTTP/3サポートを発見する必要があり、通常は[`alt-svc` HTTPレスポンスヘッダー](https://developer.mozilla.org/docs/Web/HTTP/Headers/Alt-Svc)を介して行われるため、HTTP/3で提供されたリソースを正確にカウントすることは容易ではありません。クライアントが`alt-svc`ヘッダーを受け取る時点で、すでにHTTP/1.1またはHTTP/2のプロトコル交渉を完了しています。この時点の後に、クライアントは後続のリクエストやページの読み込みでプロトコルをHTTP/3にアップグレードできます。そのため、私たちのデータは完全なHTTP/3ページの読み込みを決して捉えることができません。
+
+`alt-svc` HTTPヘッダー機構を介してHTTP/3の発見が遅れることにより、通常のブラウジングユーザーに対してHTTP/3で提供されたリソースが過少報告される可能性があります。したがって、HTTP/2とHTTP/3で提供されたリソースをHTTP/2+としてまとめています。
+
+{{ figure_markup(
+  image="http2-adoption-per-request.png",
+  caption="リクエストにおけるHTTP/2以上の採用率。",
+  description="HTTP/2以上の採用は非常に高く、2022年6月にはデスクトップとモバイルの設定でリクエストの77％がHTTP/2以上を使用して提供されました。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTsnJP1ulTTc-j9n7CIbGHxO1SaFvmZWMPQnJHrluku254CqKXz_D2fn2Ck54FC-m9135eCFg83NHOc/pubchart?oid=109625269&format=interactive",
+  sheets_gid="1707754058",
+  sql_file="h2_adoption_pages_reqs.sql"
+  )
+}}
+
+まず、現状を理解するために、HTTP/2+の普及率を測定します。2022年6月のデータでは、私たちのリクエストの約77％がHTTP/2+を使用していることが観察されました。これは、[2021年7月のHTTP/2+採用率から5％増加しています](../2021/http#リクエストによる採用)。当時、リクエストの73％がHTTP/2+でした。
+
+{{ figure_markup(
+  image="http2-adoption-per-site.png",
+  caption="ウェブサイトにおけるHTTP/2以上の採用率。",
+  description="2022年6月には、デスクトップとモバイルの設定で66％のウェブサイトがHTTP/2以上を使用して提供されました。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTsnJP1ulTTc-j9n7CIbGHxO1SaFvmZWMPQnJHrluku254CqKXz_D2fn2Ck54FC-m9135eCFg83NHOc/pubchart?oid=328815423&format=interactive",
+  sheets_gid="1707754058",
+  sql_file="h2_adoption_pages_reqs.sql"
+  )
+}}
+
+HTTP/2+の普及率の増加を理解するために、まず、ウェブサイトのランディングページがHTTP/2+で提供されているかどうかを確認することで、ウェブサイト単位でのHTTP/2+の採用を分析します。データセットの約66％のウェブサイトが、デスクトップとモバイルの設定でHTTP/2+で提供されていましたが、[2021年のデータセットでは約60％のウェブサイトがそうでした](../2021/http#HTTP/2の採用)。この増加は、ウェブサイトが最新のHTTPバージョンへ移行していることを示すポジティブな傾向です。
+
+{{ figure_markup(
+  image="http2-adoption-per-cdn.png",
+  caption="CDNから提供されるリクエストにおけるHTTP/2以上の採用率。",
+  description="デスクトップとモバイルの設定で、CDNから提供されたリクエストの95％がHTTP/2またはそれ以上を使用して提供されました。これは、CDNがHTTP/2採用の増加の主要な要因であることを示しています。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTsnJP1ulTTc-j9n7CIbGHxO1SaFvmZWMPQnJHrluku254CqKXz_D2fn2Ck54FC-m9135eCFg83NHOc/pubchart?oid=1268139215&format=interactive",
+  sheets_gid="427272739",
+  sql_file="h2_adoption_by_cdn_pct.sql"
+  )
+}}
+
+HTTP/2+の採用を促進する別の要因はCDNから提供されるリソースです。[2021年の分析](../2021/http#CDNによる採用)での観察と同様に、CDNから提供されたほとんどのリソースがHTTP/2+でした。上記の図は、CDNから提供されたリクエストの95％がHTTP/2+で提供されたことを示しています。
+
+## HTTP/2とHTTP/3の利点
+
+次に、HTTP/2が導入した機能がどのように採用されているかに焦点を当てます。主に、単一のネットワーク接続上での_多重化_リクエスト、リソースの_優先順位付け_、および_HTTP/2 Push_の3つの顕著な概念に焦点を当てます。
+
+### 複数のリクエストを単一の接続で多重化
+
+HTTP/2の重要な特徴の1つに、単一のTCP接続で複数のリクエストを多重化することがあります。これは、TCP接続上で同時に1つのリクエストしか許可されず、ほとんどの場合、ホスト名に対して6つの平行TCP接続のみが許可されるという、以前のHTTPバージョンの制限を大幅に改善します。HTTP/2では、リソース配信に使用される接続の論理表現であるストリームの概念が導入されました。それにより、複数のHTTP/2ストリームを単一のTCP接続に多重化でき、接続ごとの同時実行の制限を解除します。
+
+単一のTCP接続にリクエストを多重化することの含意として、ページロード中に必要な接続数の削減があります。[2021年の私たちの調査結果](../2021/http#接続台数)と同様に、HTTP/2が有効なページでは、HTTP/2が有効でないページよりも接続数が少ないことが確認できます。
+
+{{ figure_markup(
+  image="connections-comparison-per-page.png",
+  caption="HTTPバージョンごとのページ毎の使用される接続数。",
+  description="HTTPバージョンとパーセンタイルごとのページ毎の接続数を示す棒グラフ。すべてのパーセンタイルでHTTP/2+ページは接続数が少なく10パーセンタイルではHTTP/1.1で6つ、HTTP/2+で4つ、25パーセンタイルでそれぞれ9つと7つ、50パーセンタイルで15対12、75パーセンタイルで23対20、90パーセンタイルで38対32です。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTsnJP1ulTTc-j9n7CIbGHxO1SaFvmZWMPQnJHrluku254CqKXz_D2fn2Ck54FC-m9135eCFg83NHOc/pubchart?oid=461867891&format=interactive",
+  sheets_gid="901907129",
+  sql_file="connections_per_page_load_dist.sql"
+  )
+}}
+
+上の図は、HTTP/2が有効な場合、中央値のモバイルページがページロード中に12の接続を確立していることを示しています。これに対し、HTTP/2が有効でない中央値のページでは15の接続が確立され、追加で3つの接続が生じるというオーバーヘッドがあります。しかし、より高いパーセンタイルではオーバーヘッドはさらに悪化します。HTTP/2が有効な90パーセンタイルのページは32の接続があり、HTTP/2が有効でない90パーセンタイルのページは38の接続があり、6つの追加接続のオーバーヘッドがあります。これらの傾向は、デスクトップ版とモバイル版のウェブサイト間で同様です。
+
+年を追うごとにHTTP/2の採用が増加していることを考えると、全体的にTCP接続数が徐々に減少していることは驚くべきことではありません。<a hreflang="en" href="https://httparchive.org/reports/state-of-the-web#tcp">HTTP Archiveからの縦断的な視点</a>によれば、確立された接続の中央値は2017年の22接続から2022年の13接続に9接続減少しました。
+
+### リソース優先順位付け
+
+HTTP/2では、クライアントは同じ接続上で複数のリクエストを[多重化](https://stackoverflow.com/questions/36517829/what-does-multiplexing-mean-in-http-2/36519379#36519379)できます。これにより、多数のリソースが同時に処理中の場合、レンダリングをブロックするリソースの配信に悪影響を及ぼす可能性があり、これがユーザー体験を損なうことがあります。[元の標準](https://www.rfc-editor.org/rfc/rfc7540#page-25)では、HTTP/2はこの問題に対処しようと、クライアントがページロード中に構築する優先度ツリーを提案し、ウェブサーバーがより重要なレスポンスの送信を優先するために使用できます。しかし、このアプローチは使用が難しく、多くのウェブサーバーやCDNは[正しく実装されていないか無視されました](https://github.com/andydavies/http2-prioritization-issues)。このため、HTTP/2の後の[反復](https://www.rfc-editor.org/rfc/rfc9113.html#section-5.3)では、異なる方式が使用されることが提案されました。
+
+HTTP/2の優先順位付けの課題により、新しい優先順位付けスキームが必要とされました。[HTTPのための拡張可能な優先順位付けスキーム](https://httpwg.org/specs/rfc9218.html)はHTTP/3とは別に開発され、2022年6月に標準化されました。このスキームでは、クライアントは`priority` HTTPヘッダーや`PRIORITY_UPDATE`フレームを通じて、2つのパラメーターで明確に優先順位を割り当てることができます。最初のパラメーターである`urgency`は、要求されたリソースの優先度をサーバーに伝えます。2つ目のパラメーターである`incremental`は、リソースがクライアントで部分的に使用できるかどうかをサーバーに伝えます（たとえば、画像の一部が到着するにつれて部分的に表示される場合）。このスキームをHTTPヘッダーと`PRIORITY_UPDATE`フレームとして定義することで、両方の形式が将来の拡張性を提供するように設計されているため、拡張可能です。執筆時点で、このスキームはSafari、Firefox、ChromeでHTTP/3に対して展開されています。
+
+リソースの優先順位のほとんどはブラウザ自身によって決定されますが、開発者は今では新しい[優先度ヒント](https://web.dev/articles/fetch-priority)を使用して特定のリソースの優先度を調整することもできます。優先度ヒントはHTMLの`fetchpriority`属性を通じて指定できます。たとえば、ウェブサイトがヒーローイメージを優先したい場合、画像タグに`fetchpriority`を追加できます。
+
+```html
+<img src="hero.png" fetchpriority="high">
+```
+
+優先度ヒントはユーザー体験を向上させるのに非常に効果的です。たとえば、[Etsyは実験を行い](https://www.etsy.com/codeascraft/priority-hints-what-your-browser-doesnt-know-yet)、特定の画像に優先度ヒントを含めた製品リスティングページでLargest Contentful Paint (LCP)が4%向上することを観察しました。
+
+{{ figure_markup(
+  caption="優先度ヒントを使用しているモバイルページ。",
+  content="1.2%",
+  classes="big-number",
+  sheets_gid="1067615125",
+  sql_file="priority_hints_usage.sql"
+)
+}}
+
+優先度ヒントは2022年4月末にChrome 101の一部として最近リリースされましたが、2022年8月時点で約1%のデスクトップウェブページと1.2%のモバイルウェブページがすでに優先度ヒントを採用しているため、採用率が非常に有望です。比較的容易にユーザー体験を向上させる可能性があるため、実験には良い機能かもしれません。
+
+### HTTP/2 Push
+
+HTTP/2 Pushにより、ウェブサーバーはクライアントからリクエストが送信される前に、あらかじめレスポンスを送信できます。たとえば、ウェブサイト提供者はページロード中に使用されるリソースを主要なHTMLと共にエンドユーザーにプッシュできます。
+
+{{ figure_markup(
+  image="h2-push-usage.png",
+  caption="HTTP/2 Pushの使用状況。",
+  description="2021年7月と2022年6月のデスクトップとモバイルでのHTTP/2 Pushの使用状況を示す棒グラフ。デスクトップでは1.04%から0.71%に、モバイルでは1.26%のサイトから0.66%に減少しています。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTsnJP1ulTTc-j9n7CIbGHxO1SaFvmZWMPQnJHrluku254CqKXz_D2fn2Ck54FC-m9135eCFg83NHOc/pubchart?oid=1440772038&format=interactive",
+  sheets_gid="1278005075",
+  sql_file="h2_h3_pushed.sql"
+  )
+}}
+
+2021年の上記の図に示されているように、ウェブサイトでプッシュを使用している割合はモバイルで非常に低く、1.26%でした。しかし、今年の分析では、モバイルウェブサイトでプッシュを使用しているウェブサイトの数が0.66%に減少しています。これは2020年以降はじめてのプッシュ使用の減少を示しています。
+
+プッシュを使用するウェブサイトの減少は、[効果的に使用するのが難しい](https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/)ためである可能性が高いです。たとえば、ウェブサイトはプッシュされたリソースがクライアントのキャッシュにすでに存在するかどうかを正確に知ることができません。それがクライアントのキャッシュにある場合、そのリソースをプッシュするために使用される帯域幅はムダになります。
+
+この困難さにより、[ChromeはHTTP/2 Pushを非推奨](https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/ho4qP49oAwAJ)とすることを決定し、[Chromeバージョン106](https://developer.chrome.com/blog/removing-push/)から始まりました。プッシュは公式にはまだHTTP/3標準の一部ですが、HTTPアーカイブクローラーが使用するChromeはHTTP3接続に対してプッシュを実装しておらず、それが使用減少の一因となり、サイトがそのバージョンに移行しプッシュ機能を失ったと考えられます。
+
+### HTTP/2 Pushの代替手段
+
+HTTP/2 Pushの使用に伴う課題やChromeからの非推奨化を考慮すると、開発者は代替手段について考えるかもしれません。
+
+#### プリロード
+
+開発者は、ページロードの後半で使用されるリソースを事前にリクエストするための代替手段としてプリロードを使用できます。これは、HTMLの`<head>`セクションに[`<link rel="preload">`](https://developer.mozilla.org/docs/Web/HTML/Link_types/preload)を含めることで有効になります。たとえば。
+
+```html
+<link rel="preload" href="/css/style.css" as="style">
+```
+
+または、`Link` HTTPヘッダーとしても使用できます。
+
+```
+Link: </css/style.css>; rel="preload"; as="style"
+```
+
+どちらのオプションも、ウェブサーバーが追加のURLや重要なリソースを含めることを可能にします。クライアントは、ページロード中に通常発見される前に、提供されたURLに対してリクエストを発行できます。
+
+リソースを積極的にプッシュするほど速くはありませんが、ブラウザがそれらのリソースをフェッチするかどうかを選択できるため、たとえばキャッシュにコピーがすでにある場合はそれをフェッチしないこともあり、より安全です。
+
+{{ figure_markup(
+  caption='`<link rel="preload">`を使用しているページ。',
+  content="25%",
+  classes="big-number",
+  sheets_gid="2036031560",
+  sql_file="sites_using_link_preload_header.sql"
+)
+}}
+
+私たちのデータセットには、`<link rel="preload">`タグを含むページが大量にあり、デスクトップとモバイルの両方で約25%です。
+
+#### 103 Early Hints
+
+2017年に<a hreflang="en" href="https://www.rfc-editor.org/rfc/rfc8297">103 Early Hintsステータスコードが提案され</a>、<a hreflang="en" href="https://developer.chrome.com/blog/early-hints">Chromeは今年それをサポートしました</a>。
+
+Early Hintsは、要求されたオブジェクトの最終レスポンスの前に暫定的なHTTPレスポンスを送信するために使用できます。ウェブサーバーがレスポンスを準備するのに時間がかかること、とくに動的にレンダリングされるメインのHTMLドキュメントの場合、この事実を利用してパフォーマンスを向上させることができます。
+
+Early Hintsの1つの使用例は、事前にフェッチするための`Link: rel="preload"`を送信することや、他のドメインに事前に接続するための`Link: rel="preconnect"`を送信することです。他のヘッダーも概念的に伝達できますが、これはどのブラウザでもサポートされていません。
+
+Early Hintsはプッシュよりも優れた代替手段である可能性があります。クライアントはリソースの取得方法をより大きくコントロールできますが、メインドキュメントのHTMLにプリロードやプリコネクトを追加するだけの改善を許可します。さらに、Early Hintsはプッシュでは不可能だった第三者リソースにも使用できる可能性がありますが、<a hreflang="en" href="https://developer.chrome.com/blog/early-hints#current-limitations">これもまだどのブラウザでもサポートされていません</a>。
+
+{{ figure_markup(
+  caption="103 Early Hintsを使用しているデスクトップページ。",
+  content="1.6%",
+  classes="big-number",
+  sheets_gid="187640264",
+  sql_file="early_hints_usage.sql"
+)
+}}
+
+Early Hintsの採用がユーザー体験を向上させることを示す研究があります。たとえば、<a hreflang="en" href="https://blog.cloudflare.com/early-hints-performance/">Shopifyはラボ研究でLCPが20-30%改善されたことを観察しました</a>。私たちのデータセットでは、初期段階にもかかわらず、約1.6%のウェブサイトがEarly Hintsを採用しており、そのほとんど（1.5%）はShopifyのプラットフォーム上で実行されているウェブサイトからのものです。
+
+ページレスポンスに`<link rel="preload">`を含むウェブサイトが25%あるため、これらのリンクノードをEarly Hintsに変換する潜在的な可能性があります。
+
+## HTTP/3
+
+このセクションの残りでは、HTTPの未来であり、<a hreflang="en" href="https://www.rfc-editor.org/rfc/rfc9114.html">2022年6月に標準化された</a>HTTP/3に焦点を当てます。とくに、HTTP/3がその前身よりもどのように改善されたか、そして現在どれだけのサポートがあるかを探ります。HTTP/3についての詳細な説明については、この章のレビューにも協力してくれた[Robin Marx](https://twitter.com/programmingart)が書いた<a hreflang="en" href="https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/">素晴らしい一連の投稿</a>を参照してください。
+
+### HTTP/3の利点
+
+HTTP/2はその前身に比べてさまざまな改善を導入しましたが、プロトコルにはさらなる課題と機会が残されています。たとえば、単一のTCP接続上でのリクエストの多重化は各リクエストのヘッド・オブ・ライン・ブロッキング問題を軽減しましたが、この方法でのリクエストの配信は[まだ非効率的である可能性があります](https://calendar.perfplanet.com/2020/head-of-line-blocking-in-quic-and-http-3-the-details/)。これは、失われたTCPパケットが、その再送信が到着するまで正しく受信された後続のTCPパケットの処理を阻止するためです。これは、後続のTCPパケットが別のHTTPストリーム用であっても、TCPはHTTPプロトコルの上層で行われている多重化を認識できないため、すべてのストリームを止めます。
+
+HTTP/3はHTTP/2の短所を改善することを目指しており、それを実現するためにUDPベースのトランスポートプロトコルであるQUIC上に構築されています。QUICはUDP上でストリームごとの信頼性の高いパケット配信を実装することにより、TCPのヘッド・オブ・ライン・ブロッキングを解決します。
+
+### HTTP/3のサポート
+
+HTTP/3がサポートされていることを広告するために、ウェブサーバーはHTTPレスポンスヘッダーの`alt-svc`に依存しています。`alt-svc`ヘッダーの値には、サーバーがサポートするプロトコルのリストが含まれます。
+
+{{ figure_markup(
+  image="alt-svc-example.png",
+  caption="`alt-svc`レスポンスヘッダーの例。",
+  description="`alt-svc`レスポンスヘッダーがHTTP/3をサポートし、値`h3`、`h3-29`を持つスクリーンショット。",
+  width=417,
+  height=267
+  )
+}}
+
+たとえば、2022年9月に<a hreflang="en" href="https://www.cloudflare.com">https://www.cloudflare.com</a>のレスポンスでの`alt-svc`値は、以下のスクリーンショットに示されるように、`h3=":443"; ma=86400, h3-29=":443"; ma=86400`です。`h3`と`h3-29`は、CloudflareがUDPポート443上でHTTP/3とHTTP/3のIETFドラフト29をサポートしていることを示しています。HTTP/3の発見をDNSルックアップの一部として高速化する提案もあります。詳細については<a hreflang="en" href="https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/">このCloudflareの投稿</a>を参照してください。
+
+HTTP/3の採用を分析するために、リソースがHTTP/3で提供されたか、そのレスポンスヘッダーに`alt-svc`ヘッダーが含まれていて、`h3`または`h3-29`が広告されたプロトコルの1つとして含まれているかを識別します。これにより、HTTP/3が使用可能であるかを理解し、クローラーがまだ`alt-svc`ヘッダーを見ていないという上記の制限を無視します。
+
+{{ figure_markup(
+  image="h3-support-per-request.png",
+  caption="リクエストにおけるHTTP/3のサポート。",
+  description="2021年7月と2022年6月のデスクトップとモバイルでのHTTP/3のサポートを示す棒グラフ。両方で10%から15%に増加しています。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTsnJP1ulTTc-j9n7CIbGHxO1SaFvmZWMPQnJHrluku254CqKXz_D2fn2Ck54FC-m9135eCFg83NHOc/pubchart?oid=971486939&format=interactive",
+  sheets_gid="1456324569",
+  sql_file="h3_support.sql"
+  )
+}}
+
+上の図は、昨年のWeb Almanac以来、HTTP/3サポートがあるリクエストの割合が10%から15%に5ポイント増加したことを示しています。デスクトップとモバイルのリクエストで同様の増加が観察されました。
+
+HTTP/2+の採用と同様に、HTTP/3のサポートのほとんどはCDNから発生しています。将来的にさらに多くのCDNがHTTP/3をサポートし始めると、サポートが増えると予想されます。
+
+## 結論
+
+今年はHTTPプロトコルにとって画期的な年であり、とくにHTTP/3が標準化されたことで注目されました。私たちはHTTP/2の高い利用率を継続して観察しており、ウェブサーバーからの強力な今後のHTTP/3サポートを見ています。
+
+さらに、HTTP/2の重要な課題に対処する技術のエコシステムでの強い成長を見てきました。103 Early Hintsはサーバープッシュのより安全な代替手段を提供し、クライアントサポートはChromeが現在サポートしていることで大きく前進しました。新しいHTTP優先順位付けの標準が最終化され、主要なブラウザといくつかのウェブサーバーはすでにHTTP/3でそれをサポートしています。さらに、優先度ヒントがウェブプラットフォームに追加され、クライアントがHTTP/2およびHTTP/3の両方で優先順位をさらに洗練させることを可能にし、初期の実験は有望なユーザー体験の改善をもたらしました。
+
+これからのHTTPプロトコルとウェブエコシステムにとって興奮する時期です。これらの新しい技術がどのように採用され、ユーザー体験にどのような影響を与えるかを見るのが楽しみです。
diff --git a/src/content/ja/2022/jamstack.md b/src/content/ja/2022/jamstack.md
index 85991b777bc..de51a0b852c 100644
--- a/src/content/ja/2022/jamstack.md
+++ b/src/content/ja/2022/jamstack.md
@@ -75,7 +75,7 @@ HTTP Archiveでクエリとして表現できるJamstackの正確な定義を選
 
 私たちは測定したいことを知っていました。ほとんどのコンテンツを非常に迅速にロードし、キャッシュ可能なサイトです。これらのことを測定するさまざまな方法を多く実験した後、いくつかの具体的な指標を思いつきました。
 
-__Largest Contentful Paint (LCP)__：すべてのページのすべてのLCP時間の分布を取得し、<a hreflang="en" href="https://developer.chrome.com/docs/crux/">Chrome UX Report</a>から実際のユーザーデータの中央値を選び、「もっともコンテンツを迅速にロードした」とみなされる任意のサイトとしました。これはモバイルデバイスで2.4秒、デスクトップデバイスで2.0秒でした。
+__Largest Contentful Paint (LCP)__：すべてのページのすべてのLCP時間の分布を取得し、<a hreflang="en" href="https://developer.chrome.com/docs/crux">Chrome UX Report</a>から実際のユーザーデータの中央値を選び、「もっともコンテンツを迅速にロードした」とみなされる任意のサイトとしました。これはモバイルデバイスで2.4秒、デスクトップデバイスで2.0秒でした。
 
 __Cumulative Layout Shift (CLS)__：非常に迅速にスケルトンをロードするが、実際のコンテンツのロードに長い時間がかかるサイトを避けたいと思いました。それにもっとも近いものは<a hreflang="en" href="https://web.dev/cls/">Cumulative Layout Shift</a>で、ページのレイアウトがロード中にどれだけ跳ねるかを測定します。CLSを「操作」する方法がありますが、私たちはそれが測定しようとしているものの合理的な代理であるとまだ信じています。私たちはこの測定が好きでした、なぜなら「跳ねる」サイトもまた「Jamstack的」ではないと感じられるからです。「Jamstack的」という言葉を多く使うことになるでしょう。再び、Chrome UX Reportのデータの中央値を選びました。
 
@@ -83,7 +83,7 @@ __Cumulative Layout Shift (CLS)__：非常に迅速にスケルトンをロー
 
 __キャッシュ__：これはとくに定量化が難しいものでした。なぜなら、Jamstackサイトであっても、ほとんどのホームページが実際には長時間キャッシュされているにもかかわらず、再検証を要求するからです。私たちは`Age`、`Cache-Control`、`Expires`を含むHTTPヘッダーの組み合わせを使用しました。これらは長時間キャッシュされる可能性のあるページで一般的に見られました。
 
-当初、私たちは「小さな」サイトを除外するための別の測定が必要だと思っていました。つまり、実際のところ誰も訪れない「まもなく公開」や「Hello world」ページを非常に迅速にロードするサイトです。しかし、HTTP Archiveのデータは<a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology/#popularity-eligibility">Chromeのユーザー訪問による人気</a>に基づいて定義されており、それらのサイトがサンプルに入るほど十分に訪問されるものはほとんどありません（ただしexample.comは入っています！）。
+当初、私たちは「小さな」サイトを除外するための別の測定が必要だと思っていました。つまり、実際のところ誰も訪れない「まもなく公開」や「Hello world」ページを非常に迅速にロードするサイトです。しかし、HTTP Archiveのデータは<a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology#popularity-eligibility">Chromeのユーザー訪問による人気</a>に基づいて定義されており、それらのサイトがサンプルに入るほど十分に訪問されるものはほとんどありません（ただしexample.comは入っています！）。
 
 良い質問は、これらの指標に<a hreflang="en" href="https://web.dev/vitals/">Core Web Vitals</a>（CWV）の数値を使用しない理由は何かということです。LCPについては、私たちの数値はCWVの数値とほぼ同じです。CLSについては、CWVチームが<a hreflang="en" href="https://web.dev/defining-core-web-vitals-thresholds/#achievability-3">要件を緩和しました</a>（彼らの閾値は中央値の2倍以上です）が、私たちはそれがJamstack体験を代表していないと考えました。したがって、両方に中央値を選ぶのが公平だと決めました。そしてCWVには「キャッシュ可能性」の指標はありません。
 
diff --git a/src/content/ja/2022/mobile-web.md b/src/content/ja/2022/mobile-web.md
index 4fe73336627..34f9e1f2729 100644
--- a/src/content/ja/2022/mobile-web.md
+++ b/src/content/ja/2022/mobile-web.md
@@ -35,7 +35,7 @@ Webコンテンツへのモバイルアクセスは、インターネットア
 
 ### モバイルとデスクトップからのトラフィック
 
-[方法論](./methodology)に従い、このレポートの主要なデータソースはHTTP ArchiveとChrome UXレポート（CrUX）です。データソースからタブレットデータが別の測定値として含まれている場合、それは省略されました。これは、タブレットが主要なモバイルまたはデスクトップの分類に適切に収まらず、モバイルとデスクトップの情報を解釈または対比する際に混乱や複雑さを増加させる可能性があるためです。詳しくは、[CrUXドキュメント](https://developer.chrome.com/docs/crux/methodology?hl=ja#user-eligibility)を参照してください。
+[方法論](./methodology)に従い、このレポートの主要なデータソースはHTTP ArchiveとChrome UXレポート（CrUX）です。データソースからタブレットデータが別の測定値として含まれている場合、それは省略されました。これは、タブレットが主要なモバイルまたはデスクトップの分類に適切に収まらず、モバイルとデスクトップの情報を解釈または対比する際に混乱や複雑さを増加させる可能性があるためです。詳しくは、[CrUXドキュメント](https://developer.chrome.com/docs/cruxmethodology?hl=ja#user-eligibility)を参照してください。
 
 {{ figure_markup(
     image="pct-mobile-traffic-rank.png",
diff --git a/src/content/ja/2022/page-weight.md b/src/content/ja/2022/page-weight.md
new file mode 100644
index 00000000000..7de9c611992
--- /dev/null
+++ b/src/content/ja/2022/page-weight.md
@@ -0,0 +1,446 @@
+---
+#See https://github.com/HTTPArchive/almanac.httparchive.org/wiki/Authors'-Guide#metadata-to-add-at-the-top-of-your-chapters
+title: ページの重さ
+#TODO - Review and update chapter description
+description: 2022年のWeb Almanacのページの重さの章は、ページの重さが重要である理由、帯域幅、複雑なページ、時間と共に変化するページの重さ、ページリクエスト、ファイル形式について説明しています。
+authors: [fellowhuman1101, dwsmart]
+reviewers: [CSteele-gh]
+analysts: [drohe]
+editors: [tunetheweb]
+translators: [ksakae1216]
+results: https://docs.google.com/spreadsheets/d/1JvJMiRsL6T9m_NEBHFh-rrQmU5a-ufdOKriSJbrEN8M/
+fellowhuman1101_bio: Jamie Indigoはロボットではありませんが、ボットの言葉を話します。技術的なSEOとして<a hreflang="en" href="https://www.deepcrawl.com">DeepCrawl</a>で、彼らは検索エンジンがウェブをどのようにクロール、レンダリング、そしてインデックス化するかを研究しています。彼らは野生のJavaScriptを手懐けることと、レンダリング戦略の最適化が大好きです。仕事をしていないとき、Jamieはホラー映画やグラフィックノベル、ダンジョンズ＆ドラゴンズが好きです。
+dwsmart_bio: Dave Smartは、[Tame the Bots](https://tamethebots.com)で開発者および技術的な検索エンジンコンサルタントとして活動しています。彼は現代のウェブでツールを構築し、実験することが大好きで、しばしばライブギグの最前線で見かけることがあります。
+featured_quote: 2022年には、ページのサイズを減らす機会があるにもかかわらず、ページの重さはますます大きくなる傾向が続きました。
+featured_stat_1: 110 MB
+featured_stat_label_1: モバイルページでロードされたフォントの最大重量
+featured_stat_2: 678 MB
+featured_stat_label_2: 最大のデスクトップページの重量
+featured_stat_3: 594%
+featured_stat_label_3: 10年間でのモバイルページ重量の増加
+---
+
+## 序章
+
+過去10年間でモバイルページの重量が594％増加したことを示します。この期間に、影響を緩和するためのパフォーマンス向上技術が登場しました。最近のパフォーマンス測定方法であるCore Web Vitalsは、ページの重さを要因として除外しています。
+
+Googleが推進するCore Web Vitalsイニシアチブは、上の折り返しのコンテンツがどれだけ早く見え、使えるかにパフォーマンスの認識をシフトしている一方で、大きなネットワークペイロードは依然として長いロード時間と相関しています。
+
+多くのウェブサイトの構築者は、高速のデスクトップ接続の利点を享受しており、限られた、しばしば高価なモバイルネットワークアクセスを経験していません。
+
+<a hreflang="en" href="https://www.itu.int/itu-d/reports/statistics/2022/05/30/gcr-chapter-2/">国際電気通信連合のグローバル・コネクティビティ・レポート</a>によると、世界の世帯の66％がインターネットアクセスを持っています。低所得国では、高所得国の91％に比べて22％しかアクセスがありません。途上国の農村地域では、4Gが有意義な接続の最低限であるにもかかわらず、3Gしか利用できないことが多いです。
+
+世界の低所得国と中所得国の半数以上で、住民は<a hreflang="en" href="https://digital-world.itu.int/ministerial-roundtable-cutting-the-cost-can-affordable-access-accelerate-digital-transformation/">月平均収入の2％以上を1GBのモバイルブロードバンドデータ</a>に支払っています。
+
+ページの重さは依然として重要です。不運なタイミングで弱いネットワーク接続を経験している場合でも、インターネットアクセスがメガバイト単位で課金される市場に住んでいる場合でも、ページの重さが増加すると情報の利用可能性が低下します。
+
+## ページの重さとは何か？
+
+ページの重さとは、ウェブページのバイトサイズを指します。もはや1994年ではないため、ウェブページはブラウザのアドレスバーで表示されるURLのHTMLだけではまれです。むしろ、ブラウザで表示されレンダリングされたウェブページは、特定の要素とアセットを使用します。
+
+これが、ページの重さがページの作成に使用されるすべてのアセットを含む理由です。これには以下が含まれます。
+
+- ページ自体を構成する[HTML](./markup)
+- ページに埋め込まれた[画像やその他のメディア（ビデオ、オーディオなど）](./media)
+- ページのスタイリングに使用される[カスケーディングスタイルシート（CSS）](./css)
+- インタラクティビティを提供する[JavaScript](./javascript)
+- 上記の1つ以上を含む[サードパーティ](./third-parties)リソース
+
+各リソースはページのバイトと、ページの転送、処理、レンダリングに関わる計算リソースに追加されます。スクリプトのようなリソースは、ダウンロード、解析、コンパイル、および実行が必要なため、CPU使用量の形で追加のオーバーヘッドがあります。
+
+ページの重さが膨れ上がるにつれて、影響を軽減するための勇敢な努力や方法が提案されています。それでも、リソース割り当てとページの重さの複雑な関係のからくりは、ほとんどのユーザーには見えません。
+
+リソースのページの重さの影響をさらに詳しく調査しましょう：ストレージ、転送、およびレンダリング。
+
+### ストレージ
+
+最終的にウェブページを構成するすべてのリソースはどこかに保存する必要があります。ウェブサイトの場合、それはしばしば複数の場所を意味し、それぞれが自身のコストとオーバーヘッドを持っています。
+
+ウェブサーバー上のストレージは、ディスクストレージ上では比較的低コストで、比較的スケーラブルです。もしウェブサーバーがメモリから提供している場合は少し高価かもしれません。これらのリソースは、中間キャッシュやCDNで複製される場合もあります。
+
+それがソースですが、最終的にはリソースはクライアント側にも何らかの形で保存する必要があります。そこでは、とくにモバイルデバイスの場合、ストレージがより限定されている可能性があります。巨大で膨れ上がったファイルを提供することは、ユーザーのキャッシュを満たし、他の有用なリソースを押し出す可能性があります。
+
+解像度がプリントメディアに適している未最適化の画像や、複数のメガバイトに及ぶ巨大なビデオファイルが依然として定期的に見られます。
+
+これの多くは、メディアの適切なフォーマットとコーデックを選び、サイズと品質の両方に注意を払うことで軽減できます。<a hreflang="en" href="https://squoosh.app/">Squoosh</a>のようなサービスは、可能な限り小さなサイズで画像を最大限に活用するのに役立ち、<a hreflang="en" href="https://web.dev/image-cdns/">画像CDN</a>の専門家がこれの多くを自動化できます。
+
+メディアは定期的にもっとも重い要素ですが、節約できるのはメディアだけではありません。テキストリソースも圧縮して最小化できます。
+
+リソースをダイエットにすることは、これまでになく簡単になりました！
+
+### 転送
+
+はじめてウェブページを訪問するとき、そのページが要求するすべてのリソースは、サーバーからあなたのデバイスへインターネットを介して転送される必要があります。
+
+これは超高速で高月間使用量のブロードバンド接続を介して行われることがありますが、遅くて高価でキャップされたモバイル接続や、衛星を介して行われることもあります。
+
+ページの重さが大きいほど、これにかかる時間は長くなります。また、データプランが低いユーザーにとってはより高価になることもあります。
+
+<a hreflang="en" href="https://web.dev/uses-rel-preconnect/">`preconnect`</a>、<a hreflang="en" href="https://web.dev/preload-critical-assets/">`preload`</a>、<a hreflang="en" href="https://web.dev/articles/fetch-priority">Priority Hints</a>などロードされるものの順序を管理し、知覚されるロード時間を助ける最適化がありますが、最終的にはリソースはまだ転送され受信される必要があり、最良の最適化はより小さなリソースを提供することです。
+
+### レンダリング
+
+リソースの取得は、ウェブサイトを画面上に描画し、ユーザーに表示するための最初のステップに過ぎません。それを行うために、ウェブブラウザはページをレンダリングするためにすべての関連リソースを使用する必要があります。
+
+ここでページの重さは重要な役割を果たします。まず、転送が遅い場合（ファイルが大きいため）、ブラウザがこれらをレンダリングするために作業を開始するまでの時間が長くなります。
+
+大きなファイルは、ネットワーク上で受信された後も影響を及ぼします。大きなファイルは読み取り、処理、およびレンダリングのためにより多くの処理能力とメモリを必要とします。これにより、コンテンツの一部、またはすべてがユーザーに表示されるまでの遅延が長くなることにつながります。遅延が長ければ長いほど、ユーザーがページを放棄してより応答性の高いサイトから情報を求める可能性が高くなります。
+
+ここでのJavaScriptはとくに懸念されます。ダウンロードする必要があるだけでなく、解析して実行する必要もあります。
+
+巨大なファイルは、ユーザーが最初にダウンロードするのを待つ場合でも、継続的なパフォーマンスのペナルティを持つことがあります。これらはブラウザに利用可能なすべてのクライアントサイドリソースを消費し、パフォーマンスを遅くするか、ブラウザを完全にクラッシュさせる可能性があります。
+
+最新の高性能スマートフォン、ラップトップ、タブレットでは、これらの大きなファイルを処理するパワーがあり、顕著なパフォーマンスの問題なく処理できるかもしれませんが、古いまたは低パワーのデバイスはうまく処理できない可能性があります。これらは、遅くておそらく高価なモバイル接続を持つデバイスでもあり、もっとも単純で信頼性の高いアクセスを必要とする人々にとって「二重のペナルティ」になる可能性があります。
+
+## 私たちは何を配信しているのか？
+
+1995年にHTML 2.0が導入される前、ページの重さは予測可能で管理しやすかったです。唯一のアセットはHTMLでした。<a hreflang="en" href="https://www.rfc-editor.org/rfc/rfc1866">RFC1866</a>は`<img>`タグを導入しました。画像がウェブページに含まれるようになると、ページの重さは劇的に増加しました。
+
+HTML仕様のさらなるバージョンでは、ページの重さを増加させる可能性のあるさらに多くの機能が追加されました。たとえば外部CSSを使ってページ間で一貫したスタイリングを可能にしました。
+
+1996年にはJavaScriptがはじめて登場し、2005年にはXHRが登場し、2006年にはjQueryのようなライブラリが誕生し、Angular、React、Vueなどのフレームワークに続き待ち構えていたリバイアサンであるJavaScriptを完全に解き放ちました。
+
+ページの重さの増加は、機能を維持しながらパフォーマンスを向上させることを目的としたファイルタイプの増加をもたらしました。資産タイプ別にそれらを検討することで、トレードオフが強調されます。
+
+### 画像
+
+画像は、パフォーマンス向上技術とアセットのバイトサイズのバランスをとる代表例です。これらの静的ファイルは、ウェブページを構築し、レンダリングするためのリソースとして機能します。ウェブの視覚的な性質が高まるにつれて、このメディアタイプはもっとも普及しているアセットとしての地位を保持するでしょう。
+
+PNG、JPEG、GIFなどの古い形式は、より広い「歴史的な」ブラウザサポートの遺産を楽しんでいます。パフォーマンスに焦点を当てたファイルタイプ<a hreflang="en" href="https://developers.google.com/speed/webp">WebP</a>は顕著なブラウザサポートを獲得し、現在<a hreflang="en" href="https://caniuse.com/webp">全世界のユーザーの97％</a>が利用可能です。
+
+ウェブ上の画像の使用とその影響についての調査と考察については、[メディア](./media)章を参照してください。
+
+### JavaScript
+
+JavaScriptはウェブ上でもっとも人気のあるクライアントサイドスクリプト言語です。[98％のウェブサイト](./markup#fig-10)がインタラクティブなオンラインコンテンツを作成するために使用しており、<a hreflang="en" href="https://w3techs.com/technologies/details/cp-javascript">他のソースもそれが非常に高いと同意しています</a>。適度に使用された場合は素晴らしいですが、JavaScriptの魅力は、パフォーマンス、検索エンジン最適化、ユーザーエクスペリエンスの問題にもつながる可能性があります。
+
+インターネットでもっとも好まれる問題を引き起こす魔法のアイテムについての詳細な洞察については、[JavaScript](./javascript)章を参照してください。
+
+### サードパーティサービス
+
+ページの重さは、元のホストのアセットに限定されません。ページによって要求されるサードパーティリソースが、分析、チャットボット、フォーム、埋め込み、分析、A/Bテストツール、データ収集の形で重さに追加されます。
+
+[サードパーティ](./third-parties)章によると、モバイルデバイスのウェブサイトの94％が少なくとも1つのサードパーティリソースを使用しています！それぞれがページ重さのバイトサイズに貢献しています。
+
+### その他のアセット
+
+ウェブの基本的な構成要素は25年以上にわたって比較的変わらずに残っています。ウェブ体験の豊かさが増すにつれて、フォントとビデオの使用も増えています。
+
+これらの増加は他のファイル重量の増加と同様に、とくに100パーセンタイルに顕著です。
+
+{{ figure_markup(
+  caption="モバイルページでの最大フォント使用量。",
+  content="110 MB",
+  classes="big-number",
+  sheets_gid="1763112644",
+  sql_file="bytes_per_type.sql"
+)
+}}
+
+2021年には、モバイルサイトの100パーセンタイルがフォントファイルとして20,452キロバイトを使用しました。2022年には、これらの外れ値は110メガバイトに膨らみました。この540％の成長は、デスクトップの前年比で見られませんでした。デスクトップは2021年に66,257キロバイト、2022年に68,285キロバイトでした。
+
+しかし、100パーセンタイルはおもしろい調査対象ではありますが、常にウェブの最悪の部分を示します。90パーセンタイルでは、モバイルフォントの重さはそれほど極端ではありませんでしたが、それでも大きく401キロバイトでした。
+
+ウェブのタイポグラフィ的な性質に関するさらなる洞察は、[フォント](./fonts)章で見つけることができます。
+
+## 数字によるページの重さ
+
+これで、ページの重さを考慮する際に何に主に興味があるかがわかりました。詳細について詳しく見ていきましょう。
+
+### リクエストの量
+
+リクエストされたバイト数の合計だけでなく、ページを作成するために行われたリクエストの数もページのパフォーマンスに影響を与えることがあります。したがって、これもページの重さの一部として考慮します。
+
+{{ figure_markup(
+  image="distribution-of-requests.png",
+  caption="リクエストの分布。",
+  description="パーセンタイル別のリクエストの分布を示す棒グラフ。10パーセンタイルのモバイルページは23リクエスト、デスクトップも23、25パーセンタイルはモバイルで41リクエスト、デスクトップで45、50パーセンタイルはモバイルで70リクエスト、デスクトップで76、75パーセンタイルはモバイルで102リクエスト、デスクトップで121、90パーセンタイルはモバイルで168リクエスト、デスクトップで184。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=523847409&format=interactive",
+  sheets_gid="508674603",
+  sql_file="request_type_distribution.sql"
+  )
+}}
+
+中央値（50パーセンタイル）のページでは、デスクトップページのロードには76のリクエストがあり、モバイルでは70のリクエストがあります。すべてのパーセンタイルでデスクトップとモバイルの差はほとんどありません。
+
+昨年の中央値のデスクトップリクエストは74でしたので、昨年との大きな違いはありません。
+
+{{ figure_markup(
+  image="distribution-of-requests-by-content-type.png",
+  caption="コンテンツタイプ別の中央値のリクエスト数。",
+  description="コンテンツタイプ別の中央値のリクエスト数を示す棒グラフ。中央値のデスクトップページは画像25枚、JavaScriptファイル22個、CSS7個、HTMLファイル3個、合計76リクエストをロードします。中央値のモバイルページは画像22枚、JavaScriptファイル21個、CSSファイル7個、HTMLファイル2個、合計70リクエストをロードします。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=666775105&format=interactive",
+  sheets_gid="508674603",
+  sql_file="request_type_distribution.sql"
+  )
+}}
+
+タイプ別にリクエストを分析すると、画像がもっとも多いリソースリクエストで、中央値のページではデスクトップページのロード時に25枚の画像、モバイルでは22枚の画像をリクエストします。これは昨年のデスクトップ23枚、モバイル25枚とほぼ同じです。
+
+JavaScriptはリクエスト数が次に多く、デスクトップで22リクエスト、モバイルで21リクエストです。これも2021年のデスクトップ21、モバイル20と非常に近い数値です。
+
+一般的に、デスクトップとモバイルの違いはほとんどなく、モバイルで画像がわずかに少ないことがありますが、これは初期ビューポートが小さいために遅延ロードが発火しないことが原因かもしれません。
+
+{{ figure_markup(
+  image="distribution.png",
+  caption="パーセンタイル別のページ重さの分布。",
+  description="パーセンタイル別の総ページ重さの分布を示す棒グラフ。10パーセンタイルのモバイルページのロード重量は445 KB、25パーセンタイルは990 KB、50パーセンタイルは2,019 KB、75パーセンタイルは4,042 KB、90パーセンタイルは8,082 KBです。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=590874210&format=interactive",
+  sheets_gid="1763112644",
+  sql_file="page_weight_trend.sql"
+  )
+}}
+
+50パーセンタイルでは、デスクトップページは2MBを超え、モバイルページはそれ未満です。90パーセンタイルでは、デスクトップは約9.0MBに、モバイルは約8.0MBに成長しています。
+
+全体的なページ重さは、デスクトップとモバイルのユーザーエージェントで提供されるものを見ると非常に近いですが、より高いパーセンタイル（大きなページ）ではギャップがわずかに広がっています。モバイルデバイスはローカルリソースが少なく、ネットワーク機能が制限されている傾向があるため、これは懸念されます。
+
+{{ figure_markup(
+  caption="最大のデスクトップページの重さ",
+  content="678 MB",
+  classes="big-number",
+  sheets_gid="1763112644",
+  sql_file="page_weight_trend.sql"
+)
+}}
+
+100パーセンタイルでは、検出された最大のページで、デスクトップユーザーは678MBのページに直面し、モバイルユーザーは390MBでした。
+
+これらの大きなサイズを構成するものをもう少し詳しく掘り下げてみましょう。
+
+### リクエストバイト
+
+{{ figure_markup(
+  image="median-page-weight-over-time.png",
+  caption="時間経過による中央値のページ重量。",
+  description="時間経過による中央値のページ重量を示す折れ線グラフ。グラフは時間とともにページ重量が増加していることを示しており、2012年3月にはデスクトップで669 KB、モバイルで288 KBから、2022年7月にはデスクトップで2,312 KB、モバイルで2,037 KBになっています。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=1631675184&format=interactive",
+  sheets_gid="1472139207",
+  sql_file="page_weight_trend.sql"
+  )
+}}
+
+時間経過とともに中央値のページ重量を見ると、傾向は一貫してがっかりさせるものであり、中央値の重量は時間とともに増加しています。
+
+{{ figure_markup(
+  caption="10年間でのモバイルページ重量の増加",
+  content="594%",
+  classes="big-number",
+  sheets_gid="1472139207",
+  sql_file="page_weight_trend.sql"
+)
+}}
+
+2012年6月から2022年6月の10年間で、デスクトップページロードの中央値のページ重量は221%、または1.6 MB増加し、モバイルページロードでは594%、または1.7 MB増加しました。
+
+年間比較（2022年6月対2021年6月）では、デスクトップは2,121 KBから2,315 KBに、モバイルは1,912 KBから2,020 KBに増加しました。
+
+#### コンテンツタイプとファイル形式
+
+{{ figure_markup(
+  image="median-page-weight-by-content-type.png",
+  caption="コンテンツタイプ別の中央値ページ重量。",
+  description="コンテンツタイプ別のリソースの中央値ページ重量を示す棒グラフ。中央値のデスクトップページは画像が1,026 KB、JavaScriptが509 KB、CSSが72 KB、HTMLが31 KBをロードします。中央値のモバイルページは画像が881 KB、JavaScriptが461 KB、CSSが68 KB、HTMLが30 KBをロードします。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=1961492622&format=interactive",
+  sheets_gid="1763112644",
+  sql_file="page_weight_trend.sql"
+  )
+}}
+
+ページの重さを構成するもっとも一般的なリソースコンテンツタイプの中央値の重量を見ると、画像が最大の貢献者であり、デスクトップページでは1,026 KB、モバイルでは811 KBです。次に大きな貢献者は、デスクトップとモバイルの両方のページロードでJavaScriptです。
+
+{{ figure_markup(
+  image="distribution-of-response-size-by-content-type.png",
+  caption="コンテンツタイプ別の応答サイズの分布。",
+  description="タイプ別のリソースサイズの分布を示す箱ひげ図。ビデオは他のリソースタイプと比べて圧倒的に大きく、90パーセンタイルで2,158 KBに達します。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=131869564&format=interactive",
+  sheets_gid="1337138155",
+  sql_file="response_type_distribution.sql"
+  )
+}}
+
+インターネット全体でページ重量にもっとも大きく貢献しているのは画像ですが、リクエストごとの純粋なサイズでもっとも大きな貢献者はビデオ、オーディオ、フォントです。90パーセンタイルで、ビデオリクエストは2,158 KBで、他のすべての90パーセンタイルタイプを合わせたものの4倍の重さがあります。
+
+画像と同様に、より現代的なフォーマットや、より良いエンコーディング、サイズ設定、圧縮を活用することで、この重さを減らす機会があります。ただし、ビデオはその性質上重くなりがちであり、許容できる品質とサイズの間のバランスが必要です。詳細は[メディア章のビデオセクション](./media#ビデオ)を参照してください。
+
+{{ figure_markup(
+  image="median-response-size-by-content-type.png",
+  caption="コンテンツタイプ別の中央値応答サイズ。",
+  description="コンテンツタイプ別の中央値応答サイズを示す棒グラフ。中央値のモバイルページはビデオが268 KB、フォントが20 KB、オーディオが19 KB、画像が8 KB、JavaScriptが4 KB、CSSが2 KBをロードします。中央値のデスクトップページはビデオが208 KB、フォントが20 KB、オーディオが60 KB、画像が7 KB、JavaScriptが4 KB、CSSが2 KBをロードします。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=1388305020&format=interactive",
+  sheets_gid="1337138155",
+  sql_file="response_type_distribution.sql"
+  )
+}}
+
+各コンテンツタイプの中央値応答サイズを見ると、モバイルページロードでビデオコンテンツがデスクトップよりも大きい268 KBであることが意外です。デスクトップでは208 KBです。フォントの中央値重量が画像よりも高く、モバイルで20 KB対8 KBと2倍以上になっていることも驚きです。
+
+{{ figure_markup(
+  image="median-response-size-by-format.png",
+  caption="フォーマット別の中央値応答サイズ。",
+  description="フォーマット別の中央値応答サイズを示す棒グラフ。中央値のデスクトップページはmp4が192 KB、f4vが480 KB、フラッシュが139 KB、jpgが24 KB、flvが136 KB、webpが14 KB、pngが5KBをロードします。中央値のモバイルページはmp4が342 KB、f4vが240 KB、フラッシュが118 KB、jpgが28 KB、flvが19 KB、webpが15 KB、pngが5KBをロードします。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=405613087&format=interactive",
+  sheets_gid="159262492",
+  sql_file="response_format_distribution.sql"
+  )
+}}
+
+ファイル形式に焦点を当てると、f4v、フラッシュ、flvがページにかなりの重さを加えていることが残念です。フラッシュプレイヤープラグインは2021年に廃止され、<a hreflang="en" href="https://support.google.com/chrome/answer/6258784">Chromeのような主要なブラウザから削除されました</a>ので、これらのバイトはおそらく完全にムダです。
+
+#### 画像バイト
+
+Web Almanacの開始以来、画像はページ重量の最大の割合を占めていますので、どのフォーマットが使用されているかを見る価値があります。
+
+{{ figure_markup(
+  image="distribution-of-image-sizes-by-format.png",
+  caption="フォーマット別の画像サイズの分布。",
+  description="サイズ別の画像の分布を示す箱ひげ図。JPGは圧倒的に最大のフォーマットで、90パーセンタイルで213 KB、次にWebPが99 KB、PNGが129 KBです。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=1569662161&format=interactive",
+  sheets_gid="159262492",
+  sql_file="response_format_distribution.sql"
+  )
+}}
+
+フォーマット別の画像サイズの分布は、JPG、WebP、PNGファイル形式が2021年の状態を維持し、画像重量の主要なソースであることを示しています。
+
+{{ figure_markup(
+  image="distribution-of-image-sizes.png",
+  caption="画像サイズの分布。",
+  description="パーセンタイル別の画像サイズの分布を示す棒グラフ。デスクトップページは10パーセンタイルで82 KB、25パーセンタイルで331 KB、50パーセンタイルで1,026 KB、75パーセンタイルで2,694 KB、90パーセンタイルで6,066 KBをロードします。モバイルページは10パーセンタイルで64 KB、25パーセンタイルで260 KB、50パーセンタイルで881 KB、75パーセンタイルで2,402 KB、90パーセンタイルで5,474 KBをロードします",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=692759206&format=interactive",
+  sheets_gid="1763112644",
+  sql_file="page_weight_trend.sql"
+  )
+}}
+
+2022年のデスクトップの画像の中央値重量は1,026キロバイトで、2021年からわずか44キロバイトの増加でした。モバイルは881キロバイトでほとんど変わりませんでした。
+
+年次の一貫性は、100パーセンタイルの極端な部分によってのみ崩れます。最大のデスクトップページには672MBの画像が含まれており、2021年の186MBという重い最大値から大幅に増加しました。同様に、モバイルの100パーセンタイルは959％増の385MBを見ました。
+
+#### ビデオバイト
+
+モバイルウェブのメディア章によると、モバイルページの5％に`video`要素が含まれています。この情報は、ビデオファイルがセットにグループ化されている全体的なページ重量の他のファイルタイプの100パーセンタイルと一致しています。ビデオ体験を提供するページは、それに応じて重量が増加します。
+
+ウェブ上のビデオの[51.5％](./media#ビデオ)を占めるMP4は、最大の応答サイズの可能性も表しています。50パーセンタイルで、mp4の応答サイズは534キロバイトになります。
+
+{{ figure_markup(
+  image="distribution-of-video-sizes-by-format.png",
+  caption="フォーマット別のビデオサイズの分布。",
+  description="フォーマット別の画像サイズの分布を示す箱ひげ図。mp4は50パーセンタイルで最大で534 KB、次にf4vが155 KB、フラッシュが257 KB、flvが720 KBです。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=1651375033&format=interactive",
+  sheets_gid="159262492",
+  sql_file="response_format_distribution.sql"
+  )
+}}
+
+## バイト節約技術の採用率
+
+では、送信しているこれらのバイトについて何ができるでしょうか？明らかに、ただ送信を停止することもできますが、理由があって送信されているはずです！したがって、内容を保持しつつ、ただキロバイトをパイプに詰め込むよりも効率的な方法で送信する方法を見てみましょう。
+
+### ビデオとその他の埋め込みのためのファサード
+
+ビデオやその他のインタラクティブな埋め込みは、ページの全体的な重量を大幅に増加させる可能性があります。ビデオはその性質上バイト数が多いことがありますが、ソーシャルメディアの埋め込みなど他のコンテンツも、たとえばツイートを埋め込むために多くのJavaScriptやその他のデータを取り込むことがあります。
+
+良いデザインパターンは、ファサードの使用、つまり遅延ローディングの形態です。これは基本的に要素のグラフィカル表現を表示し、必要になるまで完全なものをロードしないというものです。たとえば、YouTubeビデオの場合、初期ロードはビデオのポスター画像だけであることがあります。これは<a hreflang="en" href="https://github.com/paulirish/lite-youtube-embed">人気のあるlite-youtube-embed</a>ライブラリによって採用されており、クリック時に実際の完全なYouTube埋め込みに変わります。また、従来の画像の遅延ロードのように振る舞い、ビューポート内または近くに変更することもできます。
+
+このアプローチには欠点がありますが、<a hreflang="en" href="https://web.dev/third-party-facades/">web.devのサードパーティファサードに関する記事</a>で詳述されているように、ワイヤー上で送信されるデータの観点からユーザーにとっての利点は明らかです。彼らはビデオを見たい、またはライブチャットアプリと対話したい場合にのみ、そのコストを支払う必要があります。
+
+実際には、ここでの採用は追跡が難しいです。Lighthouseは限られたサードパーティリソースの使用を見て、これらがリクエストされている場合、ファサードが利用可能かもしれないと指摘します。
+
+サイトがファサードをうまく使用している場合、これらのリソースはリクエストされず、したがってLighthouseではテストできません。
+
+ファサードパターンはサードパーティリソースに限定される必要はなく、これらは追加のルックアップや接続のデメリットがありますが、大きな自己ホストリソースにもうまく機能する可能性があります。
+
+分析によると、Lighthouseがファサードが有益である可能性があることを検出できたサイトがいくつかあります。
+
+{{ figure_markup(
+  image="third-party-facades.png",
+  caption="サードパーティのファサード。",
+  description="サードパーティのファサードが有益である可能性があるサイトの割合を示す棒グラフ。デスクトップサイトの9.6％、モバイルサイトの8.8％がサードパーティのファサードから恩恵を受ける可能性があります。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=1279294107&format=interactive",
+  sheets_gid="1886611950",
+  sql_file="facades-usage.sql"
+  )
+}}
+
+テストされたデスクトップページの9.6％がファサードの実装から恩恵を受ける可能性があり、モバイル訪問ではやや良好な8.8％です。
+
+### 圧縮
+
+クライアントにリソースを提供する前に圧縮することでネットワークを介して送信する必要があるバイトを節約でき、理論上、そして通常は実際にも、より速いロードが可能になります。
+
+[HTML](./markup)、[CSS](./css)、[JavaScript](./javascript)、JSON、SVGのようなテキスト非メディアファイルや、ttf、icoファイルに対して、HTTP圧縮は強力なツールで、gzipやBrotli圧縮を使用してファイルサイズを小さくできます。画像やビデオのようなメディアはすでに圧縮されているため、恩恵はほとんどありません。
+
+{{ figure_markup(
+  image="text-compression-proper-usage.png",
+  caption="テキスト圧縮の適切な使用。",
+  description="正しくテキスト圧縮を使用しているサイトの割合を示す棒グラフ。デスクトップサイトの74％、モバイルサイトの73％が、リソースのテキストベースを正しく圧縮しています。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=1121279016&format=interactive",
+  sheets_gid="1736634135",
+  sql_file="compression-usage.sql"
+  )
+}}
+
+デスクトップのページロードの74％、モバイルのページロードの73％で圧縮が検出されました。
+
+モバイルの使用率がやや低いのは、モバイルが遅くて高価なネットワーク接続を持つ可能性が高いため、失望する結果です。
+
+最終的に圧縮はページの重さの全体的な影響を減らすわけではありません。なぜなら、これらのリソースは使用前にクライアントで解凍されなければならないからです。
+
+また、圧縮は完全に無料のプロセスではありません。静的リソースに対してキャッシュ可能であるとしても、サーバーには圧縮のための処理オーバーヘッドがあり、クライアント側にはこれらのリソースを使用する前に解凍するコストがあります。
+
+これはトレードオフについてであり、しばしばネットワークが最悪のボトルネックとなります。圧縮技術は驚くほど効率的であり、通常、その正味の利益はそれだけの価値があります。
+
+### 縮小化
+
+<a hreflang="en" href="https://en.wikipedia.org/wiki/Minification_(programming)">縮小化</a>は、不要な文字（空白、コードコメントなど）を削除することで、テキストベースのリソースの全体的なサイズを減らすのに役立ちます。これらはブラウザがこれらのリソースをどのように解釈し使用するかには関係ありません。
+
+CSSとJavaScriptは縮小化のための素晴らしい候補です。私たちはLighthouseのテストを使用して両方を調べました。
+
+{{ figure_markup(
+  image="minified-css-proper-usage.png",
+  caption="CSSの適切な縮小化。",
+  description="CSSリソースを正しく縮小化しているサイトの割合を示す棒グラフ。デスクトップサイトの84％、モバイルサイトの68％がCSSを正しく縮小化しています。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=2147180836&format=interactive",
+  sheets_gid="922332593",
+  sql_file="minified_css_usage.sql"
+  )
+}}
+
+デスクトップページロードの84％が提供されたCSSを正しく縮小化し、モバイルページロードの68％がより少ない割合でした。
+
+{{ figure_markup(
+  image="minified-javascript-proper-usage.png",
+  caption="JavaScriptの適切な縮小化。",
+  description="JavaScriptリソースを正しく縮小化しているサイトの割合を示す棒グラフ。デスクトップサイトの77％、モバイルサイトの64％がJavaScriptを正しく縮小化しています。",
+  chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vS-yCXlRH7TMaQg1T2YsESIiUNe4BSga5NWwEElHgU3ZaNLXNauwAxsn3k_el5v1fxvtc_YA5k9i689/pubchart?oid=1333759402&format=interactive",
+  sheets_gid="320865285",
+  sql_file="minified_js_usage.sql"
+  )
+}}
+
+デスクトップページロードの77％が提供されたJavaScriptリソースを正しく縮小化し、モバイルページロードの64％がより少ない割合でした。
+
+CSSとJavaScriptの縮小化はありがたいことに人気があり、多くのサイトが正しく行っていますが、まだ改善の余地があります。
+
+圧縮と同様に、モバイルユーザーのための縮小化がデスクトップよりも遅れているのは残念です。圧縮と同様に、モバイルデバイスではバイトを節約することがとくに役立ちます。
+
+圧縮とは異なり、クライアント側に縮小化のオーバーヘッドはありません。リソースを使用するために「非縮小化」する必要はありません。サーバー側には提供時にリアルタイムで縮小化が行われる場合にオーバーヘッドが発生する可能性がありますが、CSSとJavaScriptは静的ファイルである可能性が高く、縮小化はビルド時またはリソースを公開する前に行うべきで、それ以上のオーバーヘッドはありません。
+
+### キャッシュとCDN
+
+キャッシュを使用すると、リソースを指定された有効期限まで再利用できます。キャッシュはブラウザやサーバーで使用されます。
+
+CDNは人気のある例です。これら相互接続されたサーバーは地理的に分散されており、ユーザーにもっとも近いネットワーク位置からキャッシュされたコンテンツを送信することで、遅延を減らします。CDNはページの重さを減らすわけではなく、リクエスターとリソース間の距離を短縮することで遅延を減らします。
+
+そのため、この章ではこの点については調査していませんが、[CDN](./cdn)章ではこれについて詳しく取り上げており、昨年の[キャッシング](../2021/cdn)章ではそれについてさらに詳しく説明しています。
+
+## 結論
+
+重たいページの重さは、ユーザーの待ち時間を長くします。ウェブページの増大するコストは、データアクセスのコスト、技術要件を満たすためのデバイスのコスト、および時間のコストで支払われます。
+
+画像とJavaScriptは依然としてバイトサイズの最大の貢献者である一方で、2022年はモバイル上でのバイト重視のビデオの増加や、画像のカウンターパートよりも中央値のフォントバイトサイズが高いといった驚くべき増加が明らかになりました。
+
+ほとんどのウェブと比べて幸いにも極端であるとはいえ、100パーセンタイルで見られる荒唐無稽な外れ値は、新しいファイルタイプや機能がデジタル体験に導入されると、制御されていない膨張の可能性を示しています。
+
+バイト節約技術はいくつかの圧力を軽減していますが、モバイルユーザーにとってより影響が大きいにもかかわらず、デスクトップでの採用率が高いままです。このまま放置されると、デジタルの不平等の格差はさらに拡大するでしょう。
diff --git a/src/content/ja/2022/performance.md b/src/content/ja/2022/performance.md
index b088135f61f..b00eaf7ff4f 100644
--- a/src/content/ja/2022/performance.md
+++ b/src/content/ja/2022/performance.md
@@ -28,7 +28,7 @@ featured_stat_label_3: INPで良いCWVが期待できる上位1kサイト
 
 これらの指標は、ユーザーエクスペリエンスを測定するための私たちの最善の推測に過ぎないことに注意することが重要です。たとえば、ブラウザが画面に要素が描画されたイベントを発火したとしても、それが常にその時点でユーザーに見えていたとは限りません。さらに、業界が成長するにつれて、より多くの指標が登場し、いくつかは非推奨になりました。どこから始めればよいか、パフォーマンス指標が私たちのユーザーについて何を伝えているのかを理解することは、とくにこの分野の新しい人々にとって複雑になる可能性があります。
 
-この章では、問題に対するGoogleの解決策である<a hreflang="ja" href="https://web.dev/articles/vitals?hl=ja">Core Web Vitals</a>（CWV）に焦点を当てています。これは、2020年に導入され、2021年に<a hreflang="en" href="https://developers.google.com/search/blog/2020/11/timing-for-page-experience">検索ランキングのシグナル</a>となったウェブパフォーマンス指標です。3つの指標はそれぞれ、ローディング、インタラクティビティ、視覚的安定性というユーザーエクスペリエンスの重要な領域をカバーしています。公開されている<a hreflang="en" href="https://developer.chrome.com/docs/crux/">Chrome UX Report</a>（CrUX）データセットは、CWVでウェブサイトがどのようにパフォーマンスを発揮しているかのChromeの視点を提供します。開発者側での設定は一切不要で、Chromeは<a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology/#eligibility">対象となるウェブサイト</a>から、オプトインしたユーザーのデータを自動的に収集して公開しています。このデータセットを使用することで、時間をかけてウェブのパフォーマンスがどのように変化しているかについての洞察を得ることができます。
+この章では、問題に対するGoogleの解決策である<a hreflang="ja" href="https://web.dev/articles/vitals?hl=ja">Core Web Vitals</a>（CWV）に焦点を当てています。これは、2020年に導入され、2021年に<a hreflang="en" href="https://developers.google.com/search/blog/2020/11/timing-for-page-experience">検索ランキングのシグナル</a>となったウェブパフォーマンス指標です。3つの指標はそれぞれ、ローディング、インタラクティビティ、視覚的安定性というユーザーエクスペリエンスの重要な領域をカバーしています。公開されている<a hreflang="en" href="https://developer.chrome.com/docs/crux">Chrome UX Report</a>（CrUX）データセットは、CWVでウェブサイトがどのようにパフォーマンスを発揮しているかのChromeの視点を提供します。開発者側での設定は一切不要で、Chromeは<a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology#eligibility">対象となるウェブサイト</a>から、オプトインしたユーザーのデータを自動的に収集して公開しています。このデータセットを使用することで、時間をかけてウェブのパフォーマンスがどのように変化しているかについての洞察を得ることができます。
 
 この章の焦点であるにもかかわらず、CWVがこの分野で比較的新しく、ウェブパフォーマンスを測定する唯一の方法ではないことに注意することが重要です。検索ランキングへの影響がほぼ1年前に有効であったため、これらの指標に焦点を当てることを選択しました。そして、今年のデータは、ウェブがこの業界の大きな変化にどのように適応しているか、そしてまだ機会が存在するかもしれない領域についての洞察を提供します。CWVは、サイト間のパフォーマンスを大まかに比較可能にする共通のベースラインを提供しますが、どの指標と戦略が自分のサイトに最適かを決定するのはサイト所有者次第です。私たちが望むとおりに、業界の全歴史やパフォーマンスを評価するためのすべての異なる方法を1章に収める方法はありません。
 
@@ -106,11 +106,11 @@ CWVがGoogle Searchのランキングシグナルとして追加されてから1
   )
 }}
 
-余談ですが、Chromeは今年初めに「良好」なTTFBの閾値を500ミリ秒から800ミリ秒に<a hreflang="en" href="https://developer.chrome.com/docs/crux/release-notes/#202204">変更</a>しました。上のグラフでは、比較目的でこの新しい閾値を使用して過去のデータすべてが示されています。
+余談ですが、Chromeは今年初めに「良好」なTTFBの閾値を500ミリ秒から800ミリ秒に<a hreflang="en" href="https://developer.chrome.com/docs/crux/release-notes#202204">変更</a>しました。上のグラフでは、比較目的でこの新しい閾値を使用して過去のデータすべてが示されています。
 
 これを念頭に置くと、良好なTTFBを持つウェブサイトの割合は実際にはあまり改善していません。過去1年間で、ウェブサイトのデスクトップとモバイル体験は1ポイント改善されたに過ぎず、これは良いことですが、LCPに観察された利得を説明するものではありません。「必要な改善」と「不十分」のTTFB分布の両端に改善がなかったわけではありませんが、「良好」な端がもっとも重要です。
 
-もう1つの複雑な点は、TTFBがCrUXで依然として<a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology/#experimental-metrics">実験的</a>な指標とみなされていることです。CrUXのドキュメントによると、TTFBは、プリレンダリングや戻る/進むナビゲーションなど、より高度なナビゲーションタイプを考慮に入れていません。これはある種の盲点であり、これらの領域で改善があった場合、それらは必ずしもTTFBの結果に影響を与えるとは限りません。
+もう1つの複雑な点は、TTFBがCrUXで依然として<a hreflang="en" href="https://developer.chrome.com/docs/crux/methodology#experimental-metrics">実験的</a>な指標とみなされていることです。CrUXのドキュメントによると、TTFBは、プリレンダリングや戻る/進むナビゲーションなど、より高度なナビゲーションタイプを考慮に入れていません。これはある種の盲点であり、これらの領域で改善があった場合、それらは必ずしもTTFBの結果に影響を与えるとは限りません。
 
 ### 視覚コンテンツの初期表示時間（FCP）
 
@@ -136,7 +136,7 @@ TTFBのデータが反対のことを示していない限り、これはフロ
 
 #### レンダリングをブロックするリソース
 
-ページにレンダリングをブロックするリソースがあるとは、リソースがページの初期描画（またはレンダリング）を遅らせる場合を指します。これは、ネットワーク経由でロードされる重要なスクリプトやスタイルにとくに当てはまります。Lighthouseには、これらのリソースをチェックする<a hreflang="ja" href="https://developer.chrome.com/docs/lighthouse/performance/render-blocking-resources?hl=ja">監査</a>が含まれており、CrUXの各ウェブサイトのホームページで実行しました。これらのページをどのようにテストしているかについては、[Methodology](./methodology)で詳しく学ぶことができます。
+ページにレンダリングをブロックするリソースがあるとは、リソースがページの初期描画（またはレンダリング）を遅らせる場合を指します。これは、ネットワーク経由でロードされる重要なスクリプトやスタイルにとくに当てはまります。Lighthouseには、これらのリソースをチェックする<a hreflang="ja" href="https://developer.chrome.com/docs/lighthouse/performancerender-blocking-resources?hl=ja">監査</a>が含まれており、CrUXの各ウェブサイトのホームページで実行しました。これらのページをどのようにテストしているかについては、[Methodology](./methodology)で詳しく学ぶことができます。
 
 {{ figure_markup(
   image="pages-passing-render-blocking-resources-audit.png",
@@ -409,7 +409,7 @@ LCP画像のフォーマット選択は、そのバイトサイズに[大きな
 
 前のセクションでは、LCPリソースに使用されるさまざまな画像フォーマットの人気を見てきました。開発者がLCPリソースを小さくし、より速くロードするための別の方法は、効率的な圧縮設定を利用することです。JPGフォーマットは、画質をあまり落とさずに不要なバイトを削減するために、損失圧縮できます。しかし、一部のJPG画像は十分に圧縮されていないかもしれません。
 
-Lighthouseには、JPGを圧縮レベル85に設定した際のバイト節約を測定する<a hreflang="ja" href="https://developer.chrome.com/docs/lighthouse/performance/uses-optimized-images?hl=ja">監査</a>が含まれています。画像が結果として4KB以上小さくなる場合、監査は失敗し、最適化の機会と見なされます。
+Lighthouseには、JPGを圧縮レベル85に設定した際のバイト節約を測定する<a hreflang="ja" href="https://developer.chrome.com/docs/lighthouse/performanceuses-optimized-images?hl=ja">監査</a>が含まれています。画像が結果として4KB以上小さくなる場合、監査は失敗し、最適化の機会と見なされます。
 
 {{ figure_markup(
   image="lcp-image-optimization.png",
@@ -547,7 +547,7 @@ CLSベストプラクティスにどれだけのウェブが準拠している
 
 #### アニメーション
 
-一部の<a hreflang="ja" href="https://developer.chrome.com/docs/lighthouse/performance/non-composited-animations?hl=ja">非合成</a> CSSアニメーションはページのレイアウトに影響を与え、CLSに貢献する可能性があります。<a hreflang="ja" href="https://web.dev/articles/optimize-cls?hl=ja#animations-%F0%9F%8F%83%E2%80%8D%E2%99%80%EF%B8%8F">ベストプラクティス</a>は、代わりに`transform`アニメーションを使用することです。
+一部の<a hreflang="ja" href="https://developer.chrome.com/docs/lighthouse/performancenon-composited-animations?hl=ja">非合成</a> CSSアニメーションはページのレイアウトに影響を与え、CLSに貢献する可能性があります。<a hreflang="ja" href="https://web.dev/articles/optimize-cls?hl=ja#animations-%F0%9F%8F%83%E2%80%8D%E2%99%80%EF%B8%8F">ベストプラクティス</a>は、代わりに`transform`アニメーションを使用することです。
 
 {{ figure_markup(
   content="38%",
@@ -873,7 +873,7 @@ INPがFIDよりも優れた反応性メトリックである理由は何か？
 
 このチャートのもっとも注目すべき属性は、左下の角に密集した領域であり、TBT軸に沿って広がっているように見えます。この広がりの長さは、高いTBTと低いFIDを持つページを表し、FIDとTBTの間の相関の低さを示しています。
 
-また、低いTBTと約250 msのFIDを持つページのパッチもあります。この領域は、`<meta name=viewport>`タグが欠けているために<a hreflang="en" href="https://developer.chrome.com/blog/300ms-tap-delay-gone-away/">タップ遅延</a>の問題を持つページを表しています。これらはこの分析の目的のために安全に無視できる外れ値です。
+また、低いTBTと約250 msのFIDを持つページのパッチもあります。この領域は、`<meta name=viewport>`タグが欠けているために<a hreflang="en" href="https://developer.chrome.com/blog/300ms-tap-delay-gone-away">タップ遅延</a>の問題を持つページを表しています。これらはこの分析の目的のために安全に無視できる外れ値です。
 
 この分布の<a hreflang="ja" href="https://ja.wikipedia.org/wiki/%E3%82%B1%E3%83%B3%E3%83%89%E3%83%BC%E3%83%AB%E3%81%AE%E9%A0%86%E4%BD%8D%E7%9B%B8%E9%96%A2%E4%BF%82%E6%95%B0">ケンドール</a>と<a hreflang="ja" href="https://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%94%E3%82%A2%E3%83%9E%E3%83%B3%E3%81%AE%E9%A0%86%E4%BD%8D%E7%9B%B8%E9%96%A2%E4%BF%82%E6%95%B0">スピアマン</a>の相関係数はそれぞれ0.29と0.40です。
 
@@ -904,7 +904,7 @@ Annieが指摘するように、両方のメトリクスはTBTと相関してい
 
 これらの結果は、FIDによって描かれる明るい絵とは裏腹に、サイトには確かに反応性の問題があることを示しています。INPがCWVメトリックになるかどうかにかかわらず、今からそれを最適化し始めると、ユーザーは感謝するでしょう。
 
-ほぼ10分の1のモバイルサイトが、ダブルタップズームを無効にすることを怠ることで、無料のパフォーマンスを放棄しています。これはすべてのサイトが行うべきことです。HTMLの一行だけで、FIDとINPの両方に利益をもたらします。ページでLighthouseを実行し、<a hreflang="ja" href="https://developer.chrome.com/docs/lighthouse/pwa/viewport?hl=ja">ビューポート</a>の監査が確実に行われていることを確認してください。
+ほぼ10分の1のモバイルサイトが、ダブルタップズームを無効にすることを怠ることで、無料のパフォーマンスを放棄しています。これはすべてのサイトが行うべきことです。HTMLの一行だけで、FIDとINPの両方に利益をもたらします。ページでLighthouseを実行し、<a hreflang="ja" href="https://developer.chrome.com/docs/lighthouse/pwaviewport?hl=ja">ビューポート</a>の監査が確実に行われていることを確認してください。
 
 CWVとしてのINPを仮定して見ると、FIDレベルに戻るだけでなく、どれだけ多くの作業が必要であるかがわかります。とくにJavaScriptの（過度な）使用の結果として、もっとも人気のあるモバイルウェブサイトはこのような変更の影響を受けやすいです。CMSやJavaScriptフレームワークの中には、他よりも大きな影響を受けるものがあり、クライアント側で行う作業の量を集団で抑制するためには、エコシステム全体の努力が必要になります。
 
diff --git a/src/content/ja/2022/privacy.md b/src/content/ja/2022/privacy.md
index 1c55a9212e8..9726e0c6c38 100644
--- a/src/content/ja/2022/privacy.md
+++ b/src/content/ja/2022/privacy.md
@@ -236,7 +236,7 @@ IPベースのジオロケーションサービスは、特にユーザーがVPN
   )
 }}
 
-デフォルトでは、サードパーティのスクリプトは、組み込まれているウェブサイトと同じブラウザ機能にアクセスできます。ウェブサイトが有効にする機能を制限するために、ウェブサイトは[パーミッションポリシー](https://developer.chrome.com/docs/privacy-security/permissions-policy?hl=ja)を利用できます。HTTPレスポンスヘッダーを通じて、ウェブサイトはどの機能を許可するかを示すことができます。例えば、`microphone`機能がこのリストに含まれていない場合、ウェブページに組み込まれているスクリプトはそれを使用することができません。このポリシーは比較的新しいものですが、デスクトップサイトの2.71％、モバイルサイトの2.31％で採用が見られます。
+デフォルトでは、サードパーティのスクリプトは、組み込まれているウェブサイトと同じブラウザ機能にアクセスできます。ウェブサイトが有効にする機能を制限するために、ウェブサイトは[パーミッションポリシー](https://developer.chrome.com/docs/privacy-securitypermissions-policy?hl=ja)を利用できます。HTTPレスポンスヘッダーを通じて、ウェブサイトはどの機能を許可するかを示すことができます。例えば、`microphone`機能がこのリストに含まれていない場合、ウェブページに組み込まれているスクリプトはそれを使用することができません。このポリシーは比較的新しいものですが、デスクトップサイトの2.71％、モバイルサイトの2.31％で採用が見られます。
 
 パーミッションポリシーは、[フィーチャーポリシー](https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Permissions-Policy)を置き換えるもので、デスクトップサイトの0.69％、モバイルサイトの0.52％で依然として見られます。
 デフォルトでは、パーミッションポリシーによって規制されるほとんどの機能は、クロスオリジンのiframeで無効になっていますが、`allow`属性を通じて明示的に有効にすることができます。デスクトップサイトの15.18％、モバイルサイトの14.32％がこの機能を利用しています。iframe上の`allow`属性の使用に関する詳細な分析については、[セキュリティ](./security#パーミッションポリシー　)章を参照してください。
diff --git a/src/content/ja/2022/pwa.md b/src/content/ja/2022/pwa.md
index e284282b7b7..66ea905d7c3 100644
--- a/src/content/ja/2022/pwa.md
+++ b/src/content/ja/2022/pwa.md
@@ -262,7 +262,7 @@ PWAは、アプリが広告されたり配置されるさまざまな場所に
 
 #### インストールと発見性のプロパティ
 
-Webアプリマニフェストファイルには、アプリケーションの説明に役立つデータが含まれている場合があります。これらのプロパティは、アプリケーションを促進するためにストアやその他の配布メカニズムによって使用されることがあります。<a hreflang="en" href="https://developer.chrome.com/blog/richer-pwa-installation/">より豊かなブラウザベースのインストールダイアログ</a>の成長もこれらのフィールドをより顕著に利用しています。マニフェストファイルのアプリケーション情報サプリメントの一部として見つかる関連フィールドは以下の通りです：
+Webアプリマニフェストファイルには、アプリケーションの説明に役立つデータが含まれている場合があります。これらのプロパティは、アプリケーションを促進するためにストアやその他の配布メカニズムによって使用されることがあります。<a hreflang="en" href="https://developer.chrome.com/blog/richer-pwa-installation">より豊かなブラウザベースのインストールダイアログ</a>の成長もこれらのフィールドをより顕著に利用しています。マニフェストファイルのアプリケーション情報サプリメントの一部として見つかる関連フィールドは以下の通りです：
 
 * `description`: このプロパティは、デスクトップの36%とモバイルの34%のWebアプリマニフェストに存在します。説明はアプリケーションの機能を説明するために重要であり、通常はストア向けにアプリに関する情報を提供するために使用されます。現在、インストール可能なPWAの約3分の1がこの情報を提供しています。
 * `screenshots`: このプロパティは、アプリストアやブラウザのインストールプロンプトで使用する1つ以上のスクリーンショットのURLを提供します。この機能を利用するマニフェストを持つPWAは、デスクトップで1.12%、モバイルデバイスで1.19%です。
@@ -383,7 +383,7 @@ PWAは高度なウェブ機能と密接に関連しています。これらの
 
 ## LighthouseによるPWAの洞察
 
-<a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/">Lighthouse</a>はオープンソースで自動化されたツールで、Webページの品質を向上させるために使用されます。ウェブサイトに対して多数の監査を実行でき、PWA監査の専用カテゴリがあります。利用可能なデータからは、過去12か月間のPWAの状況について興味深い事実が明らかにされています。
+<a hreflang="en" href="https://developer.chrome.com/docs/lighthouse">Lighthouse</a>はオープンソースで自動化されたツールで、Webページの品質を向上させるために使用されます。ウェブサイトに対して多数の監査を実行でき、PWA監査の専用カテゴリがあります。利用可能なデータからは、過去12か月間のPWAの状況について興味深い事実が明らかにされています。
 
 ### Lighthouse監査
 
@@ -409,7 +409,7 @@ PWAは高度なウェブ機能と密接に関連しています。これらの
   )
 }}
 
-モバイルサイトのLighthouseデータを見ると、似たような統計が見られますが、モバイルのみの<a hreflang="ja" href="https://developer.chrome.com/docs/lighthouse/pwa/content-width?hl=ja">content-widthメタタグ</a>もここに表示され、両方によってうれしいことに合格されています。
+モバイルサイトのLighthouseデータを見ると、似たような統計が見られますが、モバイルのみの<a hreflang="ja" href="https://developer.chrome.com/docs/lighthouse/pwacontent-width?hl=ja">content-widthメタタグ</a>もここに表示され、両方によってうれしいことに合格されています。
 
 viewportメタタグの存在は重要であり、ダブルタップでズームインするために300-350msの遅延を取り除くために役立ちます。さらに、モバイルデバイスでの利点として、アプリをデバイスの画面サイズに最適化します。ほぼすべてのウェブサイト（PWAかどうかにかかわらず）がこれを含んでいるのは驚くことではありません。
 
@@ -441,7 +441,7 @@ Lighthouseインサイトセクションを締めくくるために、監査に
   )
 }}
 
-予想通り、PWAサイトはPWA監査のスコアがかなり高くなっています。これらの監査は、<a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/pwa/">ドキュメント</a>で詳細に説明されているように、速度、信頼性、インストール可能性、その他のPWA要件を調べます。
+予想通り、PWAサイトはPWA監査のスコアがかなり高くなっています。これらの監査は、<a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/pwa">ドキュメント</a>で詳細に説明されているように、速度、信頼性、インストール可能性、その他のPWA要件を調べます。
 
 また注目すべきは、PWAサイトの監査スコアの範囲（50-100）で、これは存在するPWAの違いを表しています。対照的に、他のウェブの範囲は比較的一貫しており（20-40）、これは以前に議論されたほとんどのサイトに関連する主要な2つの監査（ビューポートとアイコン）を反映しています。
 
@@ -451,7 +451,7 @@ Lighthouseインサイトセクションを締めくくるために、監査に
 
 ### Workboxの使用
 
-<a hreflang="en" href="https://developer.chrome.com/workbox/">Workbox</a>は、開発者がサービスワーカーの使用を容易にするために作られたライブラリセットです。基本から他のWorkboxライブラリで再利用される<a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-core/">workbox-core</a>まで、キャッシング戦略、バックグラウンド同期、プリキャッシングなど、より具体的なタスクまで幅広いライブラリが含まれています。
+<a hreflang="en" href="https://developer.chrome.com/workbox/">Workbox</a>は、開発者がサービスワーカーの使用を容易にするために作られたライブラリセットです。基本から他のWorkboxライブラリで再利用される<a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-core">workbox-core</a>まで、キャッシング戦略、バックグラウンド同期、プリキャッシングなど、より具体的なタスクまで幅広いライブラリが含まれています。
 
 {{ figure_markup(
   image="workbox-usage.png",
diff --git a/src/content/ja/2022/sustainability.md b/src/content/ja/2022/sustainability.md
index 5dc04e8114f..275ee87ac66 100644
--- a/src/content/ja/2022/sustainability.md
+++ b/src/content/ja/2022/sustainability.md
@@ -241,7 +241,7 @@ Ecograder、Website Carbon、Ecoping、CO2.jsなど、いくつかの利用可
 
 ##### 使用されていないCSS
 
-使用されていないCSSは、とくにCSSフレームワーク（Bootstrapなど）を使用している場合に見られます。その際、ビルドフェーズで使用されていないCSSを削除することを念頭に置くべきです。<a hreflang="en" href="https://developer.chrome.com/docs/devtools/coverage/">Chrome Dev Toolsは、これを確認するためのCoverageツールを提供しています</a>。注意が必要です。多くのウェブサイトでは、初回訪問時にすべてのCSSとJavaScriptが読み込まれ、それらをキャッシュしてウェブサイトのさらなる訪問と探索のために使用します。これは必ずしも悪いことではありませんが、使用されていないコードはとくに考慮すべき欠点の1つです。なぜなら、それはさらなるコード処理を遅くする可能性があるからです。
+使用されていないCSSは、とくにCSSフレームワーク（Bootstrapなど）を使用している場合に見られます。その際、ビルドフェーズで使用されていないCSSを削除することを念頭に置くべきです。<a hreflang="en" href="https://developer.chrome.com/docs/devtools/coverage">Chrome Dev Toolsは、これを確認するためのCoverageツールを提供しています</a>。注意が必要です。多くのウェブサイトでは、初回訪問時にすべてのCSSとJavaScriptが読み込まれ、それらをキャッシュしてウェブサイトのさらなる訪問と探索のために使用します。これは必ずしも悪いことではありませんが、使用されていないコードはとくに考慮すべき欠点の1つです。なぜなら、それはさらなるコード処理を遅くする可能性があるからです。
 
 {{ figure_markup(
   image="unused-css-bytes.png",
@@ -256,7 +256,7 @@ Ecograder、Website Carbon、Ecoping、CO2.jsなど、いくつかの利用可
 
 ### 使用されていないJavaScript
 
-依存関係を追加したり、jQueryのようなライブラリを使用したりすると、使用されていないJavaScriptの量がすぐに増えることがあります。<a hreflang="en" href="https://developer.chrome.com/docs/devtools/coverage/">Chrome Dev ToolsのCoverageツール</a>は、これをチェックするのに良い方法です。CSSの場合と同様に、これは時にすべての必要なものをキャッシュする戦略の一部です。これは、使用されていないJavaScriptがより長い処理をもたらす傾向があるという事実によってバランスを取るべきです。可能であれば、必要な機能のみを持つ<a hreflang="en" href="http://microjs.com">より小さな代替品</a>を探し、すべてのツールボックスを読み込むことを望むのではなく、いつか役立つことを期待してください。かつて、jQueryはほとんどのウェブサイトで見られるオールインワンソリューションでした。<a hreflang="en" href="https://youmightnotneedjquery.com/">今日では、多くのことがモダンなJavaScriptで処理できます</a>。<a hreflang="en" href="https://bundlephobia.com/">NPMの依存関係とそれがあなたのバンドルをどのように大きくするかをチェックしてください</a>。
+依存関係を追加したり、jQueryのようなライブラリを使用したりすると、使用されていないJavaScriptの量がすぐに増えることがあります。<a hreflang="en" href="https://developer.chrome.com/docs/devtools/coverage">Chrome Dev ToolsのCoverageツール</a>は、これをチェックするのに良い方法です。CSSの場合と同様に、これは時にすべての必要なものをキャッシュする戦略の一部です。これは、使用されていないJavaScriptがより長い処理をもたらす傾向があるという事実によってバランスを取るべきです。可能であれば、必要な機能のみを持つ<a hreflang="en" href="http://microjs.com">より小さな代替品</a>を探し、すべてのツールボックスを読み込むことを望むのではなく、いつか役立つことを期待してください。かつて、jQueryはほとんどのウェブサイトで見られるオールインワンソリューションでした。<a hreflang="en" href="https://youmightnotneedjquery.com/">今日では、多くのことがモダンなJavaScriptで処理できます</a>。<a hreflang="en" href="https://bundlephobia.com/">NPMの依存関係とそれがあなたのバンドルをどのように大きくするかをチェックしてください</a>。
 
 {{ figure_markup(
   image="unused-javascript-bytes.png",
diff --git a/src/content/ja/2022/third-parties.md b/src/content/ja/2022/third-parties.md
index cfdd98d0612..30a21cf5447 100644
--- a/src/content/ja/2022/third-parties.md
+++ b/src/content/ja/2022/third-parties.md
@@ -369,7 +369,7 @@ Facebookは、もっとも多くのページに影響を与えるレガシーJav
 
 近年、いくつかのモダンなサードパーティのロードと実行のソリューションが登場しています。たとえば、<a hreflang="en" href="https://partytown.builder.io/">Partytown</a> は、ファーストパーティのコードのためにメインスレッドを解放するために、サードパーティのスクリプトをWebワーカーに再配置するライブラリです。現在、ライブラリの利用状況は初期導入段階であり、非常に低い状況です。2022年にデータセット全体から70のウェブサイトしか使用していません。しかし、<a hreflang="en" href="https://nextjs.org/docs/basic-features/script#off-loading-scripts-to-a-web-worker-experimental">Next.jsフレームワークがこのソリューション</a>の導入を開始したことで、Partytownの人気が高まるかもしれません。
 
-前のセクションでは、サードパーティの悪影響に対する責任がファーストパーティとサードパーティの開発者の間で分担されていることを示しました。しかし、<a hreflang="en" href="https://developer.chrome.com/blog/third-party-scripts/#proposed-approach">ブラウザもサードパーティ製リソースの読み込みを最適化することに関心を示しています</a>。提案には、より良いリアルユーザーのモニタリングと、サードパーティがウェブサイトに与える影響についてより多くのデータを提供する開発者向けツールが含まれています。
+前のセクションでは、サードパーティの悪影響に対する責任がファーストパーティとサードパーティの開発者の間で分担されていることを示しました。しかし、<a hreflang="en" href="https://developer.chrome.com/blog/third-party-scripts#proposed-approach">ブラウザもサードパーティ製リソースの読み込みを最適化することに関心を示しています</a>。提案には、より良いリアルユーザーのモニタリングと、サードパーティがウェブサイトに与える影響についてより多くのデータを提供する開発者向けツールが含まれています。
 
 {{ figure_markup(
   caption="Timing-Allow-Originヘッダーを持つサードパーティリクエストの割合",
diff --git a/src/content/nl/2021/privacy.md b/src/content/nl/2021/privacy.md
index 6ba75b16847..b2d9bd4569a 100644
--- a/src/content/nl/2021/privacy.md
+++ b/src/content/nl/2021/privacy.md
@@ -506,7 +506,7 @@ Naast het blokkeren van trackers, heeft Chrome de <a hreflang="en" href="https:/
 
 ### Privacy Sandbox
 
-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.
+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>
 
@@ -540,11 +540,11 @@ We zien dat 4,10% van de top 1.000 websites zich hebben afgemeld voor FLoC. Over
 
 Binnen Googles Privacy Sandbox-initiatieven zijn een aantal experimenten in verscheidene stadia van ontwikkeling.
 
-De <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting/">_Attribution Reporting API_</a> (voorheen _Conversion Measurement_ genoemd) maakt het mogelijk om te meten wanneer gebruikersinteractie met een advertentie leidt tot een conversie—bijvoorbeeld, wanneer een klik op een advertenties uiteindelijk leidt tot een aankoop. We zagen de eerste oorsprongsproef (die eindigde in oktober 2021) geactiveerd op 10 oorsprongen.
+De <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/attribution-reporting">_Attribution Reporting API_</a> (voorheen _Conversion Measurement_ genoemd) maakt het mogelijk om te meten wanneer gebruikersinteractie met een advertentie leidt tot een conversie—bijvoorbeeld, wanneer een klik op een advertenties uiteindelijk leidt tot een aankoop. We zagen de eerste oorsprongsproef (die eindigde in oktober 2021) geactiveerd op 10 oorsprongen.
 
-<a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/fledge/">_FLEDGE_</a> (First "Locally-Executed Decision over Groups" Experiment) tracht gerichte advertenties aan te pakken. De API kan in huidige versies van Chrome <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/fledge/">lokaal door individuele ontwikkelaars</a> getest worden maar er is geen oorsprongsproef in oktober 2021.
+<a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/fledge">_FLEDGE_</a> (First "Locally-Executed Decision over Groups" Experiment) tracht gerichte advertenties aan te pakken. De API kan in huidige versies van Chrome <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/fledge">lokaal door individuele ontwikkelaars</a> getest worden maar er is geen oorsprongsproef in oktober 2021.
 
-<a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/trust-tokens/">_Trust Tokens_</a> laat aan een website toe om een beperkte hoeveelheid informatie over te brengen van de ene browsingcontext naar een andere om fraude te helpen bestrijden, zonder passieve tracking. We zagen de eerste <a hreflang="en" href="https://developer.chrome.com/blog/third-party-origin-trials/">oorsprongsproef</a> (die zal eindigen in mei 2022) geactiveerd op 7 oorsprongen die waarschijnlijk ingesloten zijn op een aantal websites als dienstverleners.
+<a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/trust-tokens">_Trust Tokens_</a> laat aan een website toe om een beperkte hoeveelheid informatie over te brengen van de ene browsingcontext naar een andere om fraude te helpen bestrijden, zonder passieve tracking. We zagen de eerste <a hreflang="en" href="https://developer.chrome.com/blog/third-party-origin-trials">oorsprongsproef</a> (die zal eindigen in mei 2022) geactiveerd op 7 oorsprongen die waarschijnlijk ingesloten zijn op een aantal websites als dienstverleners.
 
 <a hreflang="en" href="https://github.com/WICG/CHIPS">_CHIPS_</a> (Cookies Having Independent Partitioned State) laat aan websites toe om cookies over sites heen als "gepartitioneerd" aan te duiden, wat ze in een aparte _cookie jar_ per topniveausite steekt. (Firefox heeft reeds de gelijkaardige <a hreflang="en" href="https://blog.mozilla.org/security/2021/02/23/total-cookie-protection/">_Total Cookie Protection_</a>-functie voor cookiepartitionering geïntroduceerd.) In oktober 2021 was er geen oorsprongsproef voor CHIPS.
 
@@ -560,7 +560,7 @@ De <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/attr
   )
 }}
 
-Ten slotte laten <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/first-party-sets/">_First-Party Sets_</a> aan website-eigenaars toe om een verzameling van afzonderlijke domeinen te definiëren die eigenlijk aan dezelfde entiteit behoren. Eigenaars kunnen dan een `SameParty`-attribuut zetten op cookies die over sitecontexten heen verzonden zouden moeten worden, zolang de sites tot dezelfde _first-party set_ behoren. Een eerste oorsprongsproef eindigde in september 2021. We zagen het `SameParty`-attribuut op een duizendtal cookies.
+Ten slotte laten <a hreflang="en" href="https://developer.chrome.com/docs/privacy-sandbox/first-party-sets">_First-Party Sets_</a> aan website-eigenaars toe om een verzameling van afzonderlijke domeinen te definiëren die eigenlijk aan dezelfde entiteit behoren. Eigenaars kunnen dan een `SameParty`-attribuut zetten op cookies die over sitecontexten heen verzonden zouden moeten worden, zolang de sites tot dezelfde _first-party set_ behoren. Een eerste oorsprongsproef eindigde in september 2021. We zagen het `SameParty`-attribuut op een duizendtal cookies.
 
 ## Besluit
 
diff --git a/src/content/pt/2022/capabilities.md b/src/content/pt/2022/capabilities.md
index 3ec1fc2a4bc..8c1efb9a60d 100644
--- a/src/content/pt/2022/capabilities.md
+++ b/src/content/pt/2022/capabilities.md
@@ -379,7 +379,7 @@ Muitos recursos que os usuários esperam encontrar em aplicativos específicos d
 
 O Projeto Fugu inclui a participação da Microsoft, Intel, Samsung, Google e muitos outros grupos e indivíduos.
 
-Confira <a hreflang="en" href="https://developer.chrome.com/docs/capabilities/status?hl=pt-br">este post</a> o blog dos desenvolvedores do Chrome para saber mais sobre o Projeto Fugu.
+Confira <a hreflang="en" href="https://developer.chrome.com/docs/capabilitiesstatus?hl=pt-br">este post</a> o blog dos desenvolvedores do Chrome para saber mais sobre o Projeto Fugu.
 
 ## Conclusão
 
diff --git a/src/content/pt/2022/http.md b/src/content/pt/2022/http.md
index 8439d4d51c4..76ed20e84e9 100644
--- a/src/content/pt/2022/http.md
+++ b/src/content/pt/2022/http.md
@@ -110,7 +110,7 @@ Com o HTTP/2, os clientes podem <a hreflang="en" href="https://stackoverflow.com
 
 Com os desafios das prioridades do HTTP/2, foi necessário um novo esquema de priorização. O <a hreflang="en" href="https://httpwg.org/specs/rfc9218.html">Esquema de Priorização Extensível para HTTP</a> foi desenvolvido separadamente do HTTP/3 e foi padronizado em junho de 2022. Nesse esquema, os clientes podem atribuir explicitamente uma prioridade composta por dois parâmetros através do cabeçalho HTTP `priority` ou do quadro `PRIORITY_UPDATE`.  O primeiro parâmetro, `urgency`,  indica ao servidor a prioridade do recurso solicitado. O segundo parâmetro, `incremental`, informa ao servidor se um recurso pode ser parcialmente utilizado no cliente (por exemplo, exibindo parcialmente uma imagem à medida que partes dela chegam). Definir o esquema como um cabeçalho HTTP e como o quadro `PRIORITY_UPDATE` torna-o extensível, pois ambos os formatos foram projetados para fornecer extensibilidade futura. No momento da escrita, o esquema foi implementado para HTTP/3 no Safari, Firefox e Chrome.
 
-Embora a maioria das prioridades de recursos seja decidida pelo próprio navegador, os desenvolvedores agora também podem usar as novas <a hreflang="en" href="https://web.dev/priority-hints/">dicas de prioridade</a> para ajustar a prioridade de um recurso específico. As dicas de prioridade podem ser especificadas através do atributo `fetchpriority` no HTML. Por exemplo, suponha que um site queira dar prioridade a uma imagem de destaque, ele pode adicionar o atributo `fetchpriority` à tag da imagem:
+Embora a maioria das prioridades de recursos seja decidida pelo próprio navegador, os desenvolvedores agora também podem usar as novas <a hreflang="en" href="https://web.dev/articles/fetch-priority">dicas de prioridade</a> para ajustar a prioridade de um recurso específico. As dicas de prioridade podem ser especificadas através do atributo `fetchpriority` no HTML. Por exemplo, suponha que um site queira dar prioridade a uma imagem de destaque, ele pode adicionar o atributo `fetchpriority` à tag da imagem:
 
 ```html
 <img src="hero.png" fetchpriority="high">
@@ -147,7 +147,7 @@ Em 2021, como mostrado no gráfico acima, o percentual de sites que utilizavam o
 
 A diminuição no uso do Push provavelmente ocorre porque <a hreflang="en" href="https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/">é difícil utilizá-lo de forma eficaz</a>. Por exemplo, os sites não podem saber com precisão se um recurso que está sendo empurrado já existe no cache do cliente. Se estiver no cache do cliente, a largura de banda utilizada para empurrar o recurso será desperdiçada.
 
-Com as dificuldades encontradas, O <a hreflang="en" href="https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/ho4qP49oAwAJ">Chrome decidiu depreciar o HTTP/2 Push</a> a partir da <a hreflang="en" href="https://developer.chrome.com/blog/removing-push/">Chrome versão 106</a>. Apesar de o push ainda ser oficialmente parte do padrão HTTP/3, o Chrome - que é utilizado pelo rastreador HTTP Archive - nunca implementou o push para conexões HTTP/3, o que pode explicar ainda mais a redução do uso, já que os sites migraram para essa versão e perderam a capacidade de empurrar recursos.
+Com as dificuldades encontradas, O <a hreflang="en" href="https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/ho4qP49oAwAJ">Chrome decidiu depreciar o HTTP/2 Push</a> a partir da <a hreflang="en" href="https://developer.chrome.com/blog/removing-push">Chrome versão 106</a>. Apesar de o push ainda ser oficialmente parte do padrão HTTP/3, o Chrome - que é utilizado pelo rastreador HTTP Archive - nunca implementou o push para conexões HTTP/3, o que pode explicar ainda mais a redução do uso, já que os sites migraram para essa versão e perderam a capacidade de empurrar recursos.
 
 ### Alternativas ao HTTP/2 Push
 
@@ -184,13 +184,13 @@ Observamos que um grande número de páginas em nosso conjunto de dados inclui a
 
 #### 103 Early Hints
 
-In 2017, theEm 2017, o  <a hreflang="en" href="https://www.rfc-editor.org/rfc/rfc8297">código de status 103 Early Hints foi proposto</a> e o <a hreflang="en" href="https://developer.chrome.com/blog/early-hints/">Chrome adicionou suporte para ele este ano.</a>.
+In 2017, theEm 2017, o  <a hreflang="en" href="https://www.rfc-editor.org/rfc/rfc8297">código de status 103 Early Hints foi proposto</a> e o <a hreflang="en" href="https://developer.chrome.com/blog/early-hints">Chrome adicionou suporte para ele este ano.</a>.
 
 As dicas antecipadas (Early Hints) podem ser usadas para enviar respostas HTTP intermediárias antes da resposta final do objeto solicitado. Elas podem melhorar o desempenho ao aproveitar o fato de que os servidores web frequentemente precisam de algum tempo para preparar uma resposta, especialmente para o documento HTML principal, se ele for renderizado dinamicamente.
 
 Um caso de uso das dicas antecipadas (Early Hints) é fornecer `Link: rel="preload"` para recursos a serem buscados antecipadamente ou `Link: rel="preconnect"` para conexões prévias a outros domínios. Outros cabeçalhos também podem ser conceitualmente transmitidos, embora isso ainda não seja suportado por nenhum navegador.
 
-As dicas antecipadas (Early Hints) podem ser uma alternativa melhor do que o push, pois os clientes têm maior controle sobre como os recursos são buscados, mas ainda permitem uma melhoria apenas adicionando pré-carregamentos (preloads) e pré-conexões (preconnects) ao HTML do documento principal. Além disso, as dicas antecipadas têm o potencial de serem usadas para recursos de terceiros, o que não era possível com o push, embora, novamente, <a hreflang="en" href="https://developer.chrome.com/blog/early-hints/#current-limitations">isso ainda não seja suportado em nenhum navegador atualmente</a>.
+As dicas antecipadas (Early Hints) podem ser uma alternativa melhor do que o push, pois os clientes têm maior controle sobre como os recursos são buscados, mas ainda permitem uma melhoria apenas adicionando pré-carregamentos (preloads) e pré-conexões (preconnects) ao HTML do documento principal. Além disso, as dicas antecipadas têm o potencial de serem usadas para recursos de terceiros, o que não era possível com o push, embora, novamente, <a hreflang="en" href="https://developer.chrome.com/blog/early-hints#current-limitations">isso ainda não seja suportado em nenhum navegador atualmente</a>.
 
 {{ figure_markup(
   caption="Páginas para desktop usando 103 Early Hints.",
diff --git a/src/content/ru/2021/pwa.md b/src/content/ru/2021/pwa.md
index 63ed42fd49d..ac6e21e0536 100644
--- a/src/content/ru/2021/pwa.md
+++ b/src/content/ru/2021/pwa.md
@@ -528,7 +528,7 @@ Workbox по-прежнему остаётся самой популярной 
 Способы дистрибуции этой устанавливаемой версии включают:
 
 - Предложение пользователю установить PWA через функциональность [«добавить на домашний экран»](https://developer.mozilla.org/docs/Web/Progressive_web_apps/Add_to_home_screen).
-- Загрузка PWA в магазины приложений путем упаковки его с помощью <a hreflang="en" href="https://developer.chrome.com/docs/android/trusted-web-activity/">Trusted Web Activity (TWA)</a> (в настоящее время доступно в любом магазине приложений Android, включая Google Play и Microsoft Store).
+- Загрузка PWA в магазины приложений путем упаковки его с помощью <a hreflang="en" href="https://developer.chrome.com/docs/android/trusted-web-activity">Trusted Web Activity (TWA)</a> (в настоящее время доступно в любом магазине приложений Android, включая Google Play и Microsoft Store).
 
 Далее мы поделимся некоторой статистикой, связанной с этими методами, чтобы иметь представление об использовании и росте этих тенденций.
 
@@ -573,7 +573,7 @@ Workbox по-прежнему остаётся самой популярной 
 
 TWA позволяют упаковать PWA в оболочку нативного приложения и загрузить его в некоторые магазины приложений. В отличие от решений на основе WebView, TWA — не просто движок рендеринга; это полноценный браузер, работающий в полноэкранном режиме. По этой причине он полнофункциональный и вечнозелёный, а это означает, что он всегда актуален и предоставит вам доступ к самым новым веб-API.
 
-Разработчики могут упаковать свои PWA в нативные приложения с TWA напрямую, <a hreflang="en" href="https://developer.chrome.com/docs/android/trusted-web-activity/integration-guide/">с помощью Android Studio</a>, но есть несколько инструментов, которые значительно облегчают эту задачу. Далее мы разберём два из них: PWA Builder и Bubblewrap.
+Разработчики могут упаковать свои PWA в нативные приложения с TWA напрямую, <a hreflang="en" href="https://developer.chrome.com/docs/android/trusted-web-activity/integration-guide">с помощью Android Studio</a>, но есть несколько инструментов, которые значительно облегчают эту задачу. Далее мы разберём два из них: PWA Builder и Bubblewrap.
 
 #### PWA Builder
 
diff --git a/src/content/zh-CN/2022/pwa.md b/src/content/zh-CN/2022/pwa.md
index 2e0ee24c4e5..3efb069e9a4 100644
--- a/src/content/zh-CN/2022/pwa.md
+++ b/src/content/zh-CN/2022/pwa.md
@@ -262,7 +262,7 @@ PWA 需要生成不同的图标大小，以适应推广和显示应用的需要
 
 #### 安装和可被发现成员
 
-Web 应用 manifest 文件包含描述应用有用的数据。应用商店或其他分发机制可以使用这些属性来推广应用。<a hreflang="en" href="https://developer.chrome.com/blog/richer-pwa-installation/">基于浏览器的富安装对话框</a>的增长也在更多地利用这些字段。下面列出了manifest 文件中作为补充应用信息的一部分的相关字段：
+Web 应用 manifest 文件包含描述应用有用的数据。应用商店或其他分发机制可以使用这些属性来推广应用。<a hreflang="en" href="https://developer.chrome.com/blog/richer-pwa-installation">基于浏览器的富安装对话框</a>的增长也在更多地利用这些字段。下面列出了manifest 文件中作为补充应用信息的一部分的相关字段：
 
 * `description`：此成员存在于 36% 的桌面应用和 34% 的移动 Web 应用的 manifest 中。`description` 很重要，因为它解释了应用的功能。它通常用于为商店提供有关应用的信息。目前大约有 1/3 的可安装 PWA 提供这些信息。
 * `screenshots`：此成员提供一个或多个屏幕截图的 URL，以在应用商店或浏览器的安装提示中使用。具有此功能的 manifest 的 PWA 在桌面端占 1.12%，在移动设备中占 1.19%。
@@ -383,7 +383,7 @@ Web 平台的新能力越来越多，这些是 Web 中可用于 PWA 的使用最
 
 ## 来自 Lighthouse 的 PWA 洞察
 
-<a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/">Lighthouse</a> 是一个开源的自动化工具，用于提升网页质量。 它可在网站中运行很多检测，特别是专用于 PWA 类别的审计。 已有数据阐明了过去 12 个月关于 PWA 的一些有趣的事实。
+<a hreflang="en" href="https://developer.chrome.com/docs/lighthouse">Lighthouse</a> 是一个开源的自动化工具，用于提升网页质量。 它可在网站中运行很多检测，特别是专用于 PWA 类别的审计。 已有数据阐明了过去 12 个月关于 PWA 的一些有趣的事实。
 
 ### Lighthouse 审计
 
@@ -409,7 +409,7 @@ Web 平台的新能力越来越多，这些是 Web 中可用于 PWA 的使用最
   )
 }}
 
-我们看到 Lighthouse 关于移动网站一些类似的统计数据，仅用于移动端的 <a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/pwa/content-width/">content-width</a> 元标签都通过了。
+我们看到 Lighthouse 关于移动网站一些类似的统计数据，仅用于移动端的 <a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/pwa/content-width">content-width</a> 元标签都通过了。
 
 Viewport 元标签的存在很重要，因为它在以重新缩放的方式等待双击时移除了 300-350ms 的延迟。在移动设备上，它还具有为屏幕尺寸优化应用的额外好处 。几乎所有 PWA 的网站都包含这个标签毫不奇怪。
 
@@ -441,7 +441,7 @@ Viewport 元标签的存在很重要，因为它在以重新缩放的方式等
   )
 }}
 
-正如预期的那样，PWA 网站的 PWA 审计分数往往要高得多。 这些审核会检测速度、可靠性、可安装性和其他的 PWA 需求，详见他们的<a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/pwa/">文档</a>。
+正如预期的那样，PWA 网站的 PWA 审计分数往往要高得多。 这些审核会检测速度、可靠性、可安装性和其他的 PWA 需求，详见他们的<a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/pwa">文档</a>。
 
 同样值得注意的是 PWA 站点中的审计分数范围（50-100）代表了 PWA 的差异。 相比之下，其余网站的分数范围相当一致（20-40），这反映了之前讨论的大多数网站相关的两个主要审计内容：viewport 和图标 icons。
 
@@ -451,7 +451,7 @@ Service Workers 非常强大，这些 API 允许开发人员创建以前不可
 
 ### Workbox 的使用
 
-<a hreflang="en" href="https://developer.chrome.com/workbox/">Workbox</a> 是一组库，旨在简化开发人员对 Service Worker 的使用。这些库包含在其他 Workbox 库中重用的带有 <a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-core/">workbox-core</a>的基础知识，到更具体的任务，如<a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-strategies/">缓存策略</a>、<a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-background-sync/">后台同步</a>、<a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-precaching/">预缓存</a> 以及<a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/">更多</a>。
+<a hreflang="en" href="https://developer.chrome.com/workbox/">Workbox</a> 是一组库，旨在简化开发人员对 Service Worker 的使用。这些库包含在其他 Workbox 库中重用的带有 <a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-core">workbox-core</a>的基础知识，到更具体的任务，如<a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-strategies">缓存策略</a>、<a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-background-sync">后台同步</a>、<a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules/workbox-precaching">预缓存</a> 以及<a hreflang="en" href="https://developer.chrome.com/docs/workbox/modules">更多</a>。
 
 {{ figure_markup(
   image="workbox-usage.png",
diff --git a/src/package-lock.json b/src/package-lock.json
index 7ddfd5a2f9d..441af16621d 100644
--- a/src/package-lock.json
+++ b/src/package-lock.json
@@ -11,11 +11,11 @@
       "devDependencies": {
         "ejs": "3.1.10",
         "fs-extra": "11.2.0",
-        "jsdom": "25.0.0",
+        "jsdom": "25.0.1",
         "node-fetch": "3.3.2",
         "node-watch": "0.7.4",
         "prettier": "3.3.3",
-        "puppeteer": "23.4.0",
+        "puppeteer": "23.4.1",
         "rainbow-code": "2.1.7",
         "recursive-readdir": "2.2.3",
         "run-script-os": "1.1.6",
@@ -214,9 +214,9 @@
       "dev": true
     },
     "node_modules/@types/node": {
-      "version": "22.5.5",
-      "resolved": "https://registry.npmjs.org/@types/node/-/node-22.5.5.tgz",
-      "integrity": "sha512-Xjs4y5UPO/CLdzpgR6GirZJx36yScjh73+2NlLlkFRSoQN8B0DpfXPdZGnvVmLRLOsqDpOfTNv7D9trgGhmOIA==",
+      "version": "22.7.0",
+      "resolved": "https://registry.npmjs.org/@types/node/-/node-22.7.0.tgz",
+      "integrity": "sha512-MOdOibwBs6KW1vfqz2uKMlxq5xAfAZ98SZjO8e3XnAbFnTJtAspqhWk7hrdSAs9/Y14ZWMiy7/MxMUzAOadYEw==",
       "dev": true,
       "optional": true,
       "dependencies": {
@@ -300,9 +300,9 @@
       "dev": true
     },
     "node_modules/b4a": {
-      "version": "1.6.6",
-      "resolved": "https://registry.npmjs.org/b4a/-/b4a-1.6.6.tgz",
-      "integrity": "sha512-5Tk1HLk6b6ctmjIkAcU/Ujv/1WqiDl0F0JdRCR80VsOcUlHcu7pWeWRlOqQLHfDEsVx9YH/aif5AG4ehoCtTmg==",
+      "version": "1.6.7",
+      "resolved": "https://registry.npmjs.org/b4a/-/b4a-1.6.7.tgz",
+      "integrity": "sha512-OnAYlL5b7LEkALw87fUVafQw5rVR9RjwGd4KUwNQ6DrrNmaVaUCgLipfVlzrPQ4tWOR9P0IXGNOx50jYCCdSJg==",
       "dev": true
     },
     "node_modules/balanced-match": {
@@ -312,9 +312,9 @@
       "dev": true
     },
     "node_modules/bare-events": {
-      "version": "2.4.2",
-      "resolved": "https://registry.npmjs.org/bare-events/-/bare-events-2.4.2.tgz",
-      "integrity": "sha512-qMKFd2qG/36aA4GwvKq8MxnPgCQAmBWmSyLWsJcbn8v03wvIPQ/hG1Ms8bPzndZxMDoHpxez5VOS+gC9Yi24/Q==",
+      "version": "2.5.0",
+      "resolved": "https://registry.npmjs.org/bare-events/-/bare-events-2.5.0.tgz",
+      "integrity": "sha512-/E8dDe9dsbLyh2qrZ64PEPadOQ0F4gbl1sUJOrmph7xOiIxfY8vwab/4bFLh4Y88/Hk/ujKcrQKc+ps0mv873A==",
       "dev": true,
       "optional": true
     },
@@ -555,12 +555,12 @@
       }
     },
     "node_modules/cssstyle": {
-      "version": "4.0.1",
-      "resolved": "https://registry.npmjs.org/cssstyle/-/cssstyle-4.0.1.tgz",
-      "integrity": "sha512-8ZYiJ3A/3OkDd093CBT/0UKDWry7ak4BdPTFP2+QEP7cmhouyq/Up709ASSj2cK02BbZiMgk7kYjZNS4QP5qrQ==",
+      "version": "4.1.0",
+      "resolved": "https://registry.npmjs.org/cssstyle/-/cssstyle-4.1.0.tgz",
+      "integrity": "sha512-h66W1URKpBS5YMI/V8PyXvTMFT8SupJ1IzoIV8IeBC/ji8WVmrO8dGlTi+2dh6whmdk6BiKJLD/ZBkhWbcg6nA==",
       "dev": true,
       "dependencies": {
-        "rrweb-cssom": "^0.6.0"
+        "rrweb-cssom": "^0.7.1"
       },
       "engines": {
         "node": ">=18"
@@ -1124,12 +1124,12 @@
       "dev": true
     },
     "node_modules/jsdom": {
-      "version": "25.0.0",
-      "resolved": "https://registry.npmjs.org/jsdom/-/jsdom-25.0.0.tgz",
-      "integrity": "sha512-OhoFVT59T7aEq75TVw9xxEfkXgacpqAhQaYgP9y/fDqWQCMB/b1H66RfmPm/MaeaAIU9nDwMOVTlPN51+ao6CQ==",
+      "version": "25.0.1",
+      "resolved": "https://registry.npmjs.org/jsdom/-/jsdom-25.0.1.tgz",
+      "integrity": "sha512-8i7LzZj7BF8uplX+ZyOlIz86V6TAsSs+np6m1kpW9u0JWi4z/1t+FzcK1aek+ybTnAC4KhBL4uXCNT0wcUIeCw==",
       "dev": true,
       "dependencies": {
-        "cssstyle": "^4.0.1",
+        "cssstyle": "^4.1.0",
         "data-urls": "^5.0.0",
         "decimal.js": "^10.4.3",
         "form-data": "^4.0.0",
@@ -1142,7 +1142,7 @@
         "rrweb-cssom": "^0.7.1",
         "saxes": "^6.0.0",
         "symbol-tree": "^3.2.4",
-        "tough-cookie": "^4.1.4",
+        "tough-cookie": "^5.0.0",
         "w3c-xmlserializer": "^5.0.0",
         "webidl-conversions": "^7.0.0",
         "whatwg-encoding": "^3.1.1",
@@ -1163,12 +1163,6 @@
         }
       }
     },
-    "node_modules/jsdom/node_modules/rrweb-cssom": {
-      "version": "0.7.1",
-      "resolved": "https://registry.npmjs.org/rrweb-cssom/-/rrweb-cssom-0.7.1.tgz",
-      "integrity": "sha512-TrEMa7JGdVm0UThDJSx7ddw5nVm3UJS9o9CCIZ72B1vSyEZoziDqBYP3XIoi/12lKrJR8rE3jeFHMok2F/Mnsg==",
-      "dev": true
-    },
     "node_modules/json-parse-even-better-errors": {
       "version": "2.3.1",
       "resolved": "https://registry.npmjs.org/json-parse-even-better-errors/-/json-parse-even-better-errors-2.3.1.tgz",
@@ -1446,12 +1440,6 @@
       "integrity": "sha512-D+zkORCbA9f1tdWRK0RaCR3GPv50cMxcrz4X8k5LTSUD1Dkw47mKJEZQNunItRTkWwgtaUSo1RVFRIG9ZXiFYg==",
       "dev": true
     },
-    "node_modules/psl": {
-      "version": "1.9.0",
-      "resolved": "https://registry.npmjs.org/psl/-/psl-1.9.0.tgz",
-      "integrity": "sha512-E/ZsdU4HLs/68gYzgGTkMicWTLPdAftJLfJFlLUAAKZGkStNU72sZjT66SnMDVOfOWY/YAoiD7Jxa9iHvngcag==",
-      "dev": true
-    },
     "node_modules/pump": {
       "version": "3.0.2",
       "resolved": "https://registry.npmjs.org/pump/-/pump-3.0.2.tgz",
@@ -1472,9 +1460,9 @@
       }
     },
     "node_modules/puppeteer": {
-      "version": "23.4.0",
-      "resolved": "https://registry.npmjs.org/puppeteer/-/puppeteer-23.4.0.tgz",
-      "integrity": "sha512-FxgFFJI7NAsX8uebiEDSjS86vufz9TaqERQHShQT0lCbSRI3jUPEcz/0HdwLiYvfYNsc1zGjqY3NsGZya4PvUA==",
+      "version": "23.4.1",
+      "resolved": "https://registry.npmjs.org/puppeteer/-/puppeteer-23.4.1.tgz",
+      "integrity": "sha512-+wWfWTkQ8L9IB/3OVGSUp37c0eQ5za/85KdX+LAq2wTZkMdocgYGMCs+/91e2f/RXIYzve4x/uGxN8zG2sj8+w==",
       "dev": true,
       "hasInstallScript": true,
       "dependencies": {
@@ -1482,7 +1470,7 @@
         "chromium-bidi": "0.6.5",
         "cosmiconfig": "^9.0.0",
         "devtools-protocol": "0.0.1342118",
-        "puppeteer-core": "23.4.0",
+        "puppeteer-core": "23.4.1",
         "typed-query-selector": "^2.12.0"
       },
       "bin": {
@@ -1493,9 +1481,9 @@
       }
     },
     "node_modules/puppeteer-core": {
-      "version": "23.4.0",
-      "resolved": "https://registry.npmjs.org/puppeteer-core/-/puppeteer-core-23.4.0.tgz",
-      "integrity": "sha512-fqkIP5FOcb38jfBj/OcBz1wFaI9nk40uQKSORvnXws6wCbep2dg8yxZ3ddJxBIfQsxoiEOvnrykFinUScrB/ew==",
+      "version": "23.4.1",
+      "resolved": "https://registry.npmjs.org/puppeteer-core/-/puppeteer-core-23.4.1.tgz",
+      "integrity": "sha512-uCxGtn8VE9PlKhdFJX/zZySi9K3Ufr3qUZe28jxJoZUqiMJOi+SFh2zhiFDSjWqZIDkc0FtnaCC+rewW3MYXmg==",
       "dev": true,
       "dependencies": {
         "@puppeteer/browsers": "2.4.0",
@@ -1509,12 +1497,6 @@
         "node": ">=18"
       }
     },
-    "node_modules/querystringify": {
-      "version": "2.2.0",
-      "resolved": "https://registry.npmjs.org/querystringify/-/querystringify-2.2.0.tgz",
-      "integrity": "sha512-FIqgj2EUvTa7R50u0rGsyTftzjYmv/a3hO345bZNrqabNqjtgiDMgmo4mkUjd+nzU5oF3dClKqFIPUKybUyqoQ==",
-      "dev": true
-    },
     "node_modules/queue-tick": {
       "version": "1.0.1",
       "resolved": "https://registry.npmjs.org/queue-tick/-/queue-tick-1.0.1.tgz",
@@ -1551,12 +1533,6 @@
         "node": ">=0.10.0"
       }
     },
-    "node_modules/requires-port": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/requires-port/-/requires-port-1.0.0.tgz",
-      "integrity": "sha512-KigOCHcocU3XODJxsu8i/j8T9tzT4adHiecwORRQ0ZZFcp7ahwXuRU1m+yuO90C5ZUyGeGfocHDI14M3L3yDAQ==",
-      "dev": true
-    },
     "node_modules/resolve-from": {
       "version": "4.0.0",
       "resolved": "https://registry.npmjs.org/resolve-from/-/resolve-from-4.0.0.tgz",
@@ -1567,9 +1543,9 @@
       }
     },
     "node_modules/rrweb-cssom": {
-      "version": "0.6.0",
-      "resolved": "https://registry.npmjs.org/rrweb-cssom/-/rrweb-cssom-0.6.0.tgz",
-      "integrity": "sha512-APM0Gt1KoXBz0iIkkdB/kfvGOwC4UuJFeG/c+yV7wSc7q96cG/kJ0HiYCnzivD9SB53cLV1MlHFNfOuPaadYSw==",
+      "version": "0.7.1",
+      "resolved": "https://registry.npmjs.org/rrweb-cssom/-/rrweb-cssom-0.7.1.tgz",
+      "integrity": "sha512-TrEMa7JGdVm0UThDJSx7ddw5nVm3UJS9o9CCIZ72B1vSyEZoziDqBYP3XIoi/12lKrJR8rE3jeFHMok2F/Mnsg==",
       "dev": true
     },
     "node_modules/run-script-os": {
@@ -1796,28 +1772,34 @@
       "integrity": "sha512-w89qg7PI8wAdvX60bMDP+bFoD5Dvhm9oLheFp5O4a2QF0cSBGsBX4qZmadPMvVqlLJBBci+WqGGOAPvcDeNSVg==",
       "dev": true
     },
-    "node_modules/tough-cookie": {
-      "version": "4.1.4",
-      "resolved": "https://registry.npmjs.org/tough-cookie/-/tough-cookie-4.1.4.tgz",
-      "integrity": "sha512-Loo5UUvLD9ScZ6jh8beX1T6sO1w2/MpCRpEP7V280GKMVUQ0Jzar2U3UJPsrdbziLEMMhu3Ujnq//rhiFuIeag==",
+    "node_modules/tldts": {
+      "version": "6.1.47",
+      "resolved": "https://registry.npmjs.org/tldts/-/tldts-6.1.47.tgz",
+      "integrity": "sha512-R/K2tZ5MiY+mVrnSkNJkwqYT2vUv1lcT6wJvd2emGaMJ7PHUGRY4e3tUsdFCXgqxi2QgbHjL3yJgXCo40v9Hxw==",
       "dev": true,
       "dependencies": {
-        "psl": "^1.1.33",
-        "punycode": "^2.1.1",
-        "universalify": "^0.2.0",
-        "url-parse": "^1.5.3"
+        "tldts-core": "^6.1.47"
       },
-      "engines": {
-        "node": ">=6"
+      "bin": {
+        "tldts": "bin/cli.js"
       }
     },
-    "node_modules/tough-cookie/node_modules/universalify": {
-      "version": "0.2.0",
-      "resolved": "https://registry.npmjs.org/universalify/-/universalify-0.2.0.tgz",
-      "integrity": "sha512-CJ1QgKmNg3CwvAv/kOFmtnEN05f0D/cn9QntgNOQlQF9dgvVTHj3t+8JPdjqawCHk7V/KA+fbUqzZ9XWhcqPUg==",
+    "node_modules/tldts-core": {
+      "version": "6.1.47",
+      "resolved": "https://registry.npmjs.org/tldts-core/-/tldts-core-6.1.47.tgz",
+      "integrity": "sha512-6SWyFMnlst1fEt7GQVAAu16EGgFK0cLouH/2Mk6Ftlwhv3Ol40L0dlpGMcnnNiiOMyD2EV/aF3S+U2nKvvLvrA==",
+      "dev": true
+    },
+    "node_modules/tough-cookie": {
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/tough-cookie/-/tough-cookie-5.0.0.tgz",
+      "integrity": "sha512-FRKsF7cz96xIIeMZ82ehjC3xW2E+O2+v11udrDYewUbszngYhsGa8z6YUMMzO9QJZzzyd0nGGXnML/TReX6W8Q==",
       "dev": true,
+      "dependencies": {
+        "tldts": "^6.1.32"
+      },
       "engines": {
-        "node": ">= 4.0.0"
+        "node": ">=16"
       }
     },
     "node_modules/tr46": {
@@ -1870,16 +1852,6 @@
         "node": ">= 10.0.0"
       }
     },
-    "node_modules/url-parse": {
-      "version": "1.5.10",
-      "resolved": "https://registry.npmjs.org/url-parse/-/url-parse-1.5.10.tgz",
-      "integrity": "sha512-WypcfiRhfeUP9vvF0j6rw0J3hrWrw6iZv3+22h6iRMJ/8z1Tj6XfLP4DsUix5MhMPnXpiHDoKyoZ/bdCkwBCiQ==",
-      "dev": true,
-      "dependencies": {
-        "querystringify": "^2.1.1",
-        "requires-port": "^1.0.0"
-      }
-    },
     "node_modules/urlpattern-polyfill": {
       "version": "10.0.0",
       "resolved": "https://registry.npmjs.org/urlpattern-polyfill/-/urlpattern-polyfill-10.0.0.tgz",
@@ -2244,9 +2216,9 @@
       "dev": true
     },
     "@types/node": {
-      "version": "22.5.5",
-      "resolved": "https://registry.npmjs.org/@types/node/-/node-22.5.5.tgz",
-      "integrity": "sha512-Xjs4y5UPO/CLdzpgR6GirZJx36yScjh73+2NlLlkFRSoQN8B0DpfXPdZGnvVmLRLOsqDpOfTNv7D9trgGhmOIA==",
+      "version": "22.7.0",
+      "resolved": "https://registry.npmjs.org/@types/node/-/node-22.7.0.tgz",
+      "integrity": "sha512-MOdOibwBs6KW1vfqz2uKMlxq5xAfAZ98SZjO8e3XnAbFnTJtAspqhWk7hrdSAs9/Y14ZWMiy7/MxMUzAOadYEw==",
       "dev": true,
       "optional": true,
       "requires": {
@@ -2315,9 +2287,9 @@
       "dev": true
     },
     "b4a": {
-      "version": "1.6.6",
-      "resolved": "https://registry.npmjs.org/b4a/-/b4a-1.6.6.tgz",
-      "integrity": "sha512-5Tk1HLk6b6ctmjIkAcU/Ujv/1WqiDl0F0JdRCR80VsOcUlHcu7pWeWRlOqQLHfDEsVx9YH/aif5AG4ehoCtTmg==",
+      "version": "1.6.7",
+      "resolved": "https://registry.npmjs.org/b4a/-/b4a-1.6.7.tgz",
+      "integrity": "sha512-OnAYlL5b7LEkALw87fUVafQw5rVR9RjwGd4KUwNQ6DrrNmaVaUCgLipfVlzrPQ4tWOR9P0IXGNOx50jYCCdSJg==",
       "dev": true
     },
     "balanced-match": {
@@ -2327,9 +2299,9 @@
       "dev": true
     },
     "bare-events": {
-      "version": "2.4.2",
-      "resolved": "https://registry.npmjs.org/bare-events/-/bare-events-2.4.2.tgz",
-      "integrity": "sha512-qMKFd2qG/36aA4GwvKq8MxnPgCQAmBWmSyLWsJcbn8v03wvIPQ/hG1Ms8bPzndZxMDoHpxez5VOS+gC9Yi24/Q==",
+      "version": "2.5.0",
+      "resolved": "https://registry.npmjs.org/bare-events/-/bare-events-2.5.0.tgz",
+      "integrity": "sha512-/E8dDe9dsbLyh2qrZ64PEPadOQ0F4gbl1sUJOrmph7xOiIxfY8vwab/4bFLh4Y88/Hk/ujKcrQKc+ps0mv873A==",
       "dev": true,
       "optional": true
     },
@@ -2498,12 +2470,12 @@
       }
     },
     "cssstyle": {
-      "version": "4.0.1",
-      "resolved": "https://registry.npmjs.org/cssstyle/-/cssstyle-4.0.1.tgz",
-      "integrity": "sha512-8ZYiJ3A/3OkDd093CBT/0UKDWry7ak4BdPTFP2+QEP7cmhouyq/Up709ASSj2cK02BbZiMgk7kYjZNS4QP5qrQ==",
+      "version": "4.1.0",
+      "resolved": "https://registry.npmjs.org/cssstyle/-/cssstyle-4.1.0.tgz",
+      "integrity": "sha512-h66W1URKpBS5YMI/V8PyXvTMFT8SupJ1IzoIV8IeBC/ji8WVmrO8dGlTi+2dh6whmdk6BiKJLD/ZBkhWbcg6nA==",
       "dev": true,
       "requires": {
-        "rrweb-cssom": "^0.6.0"
+        "rrweb-cssom": "^0.7.1"
       }
     },
     "data-uri-to-buffer": {
@@ -2907,12 +2879,12 @@
       "dev": true
     },
     "jsdom": {
-      "version": "25.0.0",
-      "resolved": "https://registry.npmjs.org/jsdom/-/jsdom-25.0.0.tgz",
-      "integrity": "sha512-OhoFVT59T7aEq75TVw9xxEfkXgacpqAhQaYgP9y/fDqWQCMB/b1H66RfmPm/MaeaAIU9nDwMOVTlPN51+ao6CQ==",
+      "version": "25.0.1",
+      "resolved": "https://registry.npmjs.org/jsdom/-/jsdom-25.0.1.tgz",
+      "integrity": "sha512-8i7LzZj7BF8uplX+ZyOlIz86V6TAsSs+np6m1kpW9u0JWi4z/1t+FzcK1aek+ybTnAC4KhBL4uXCNT0wcUIeCw==",
       "dev": true,
       "requires": {
-        "cssstyle": "^4.0.1",
+        "cssstyle": "^4.1.0",
         "data-urls": "^5.0.0",
         "decimal.js": "^10.4.3",
         "form-data": "^4.0.0",
@@ -2925,7 +2897,7 @@
         "rrweb-cssom": "^0.7.1",
         "saxes": "^6.0.0",
         "symbol-tree": "^3.2.4",
-        "tough-cookie": "^4.1.4",
+        "tough-cookie": "^5.0.0",
         "w3c-xmlserializer": "^5.0.0",
         "webidl-conversions": "^7.0.0",
         "whatwg-encoding": "^3.1.1",
@@ -2933,14 +2905,6 @@
         "whatwg-url": "^14.0.0",
         "ws": "^8.18.0",
         "xml-name-validator": "^5.0.0"
-      },
-      "dependencies": {
-        "rrweb-cssom": {
-          "version": "0.7.1",
-          "resolved": "https://registry.npmjs.org/rrweb-cssom/-/rrweb-cssom-0.7.1.tgz",
-          "integrity": "sha512-TrEMa7JGdVm0UThDJSx7ddw5nVm3UJS9o9CCIZ72B1vSyEZoziDqBYP3XIoi/12lKrJR8rE3jeFHMok2F/Mnsg==",
-          "dev": true
-        }
       }
     },
     "json-parse-even-better-errors": {
@@ -3147,12 +3111,6 @@
       "integrity": "sha512-D+zkORCbA9f1tdWRK0RaCR3GPv50cMxcrz4X8k5LTSUD1Dkw47mKJEZQNunItRTkWwgtaUSo1RVFRIG9ZXiFYg==",
       "dev": true
     },
-    "psl": {
-      "version": "1.9.0",
-      "resolved": "https://registry.npmjs.org/psl/-/psl-1.9.0.tgz",
-      "integrity": "sha512-E/ZsdU4HLs/68gYzgGTkMicWTLPdAftJLfJFlLUAAKZGkStNU72sZjT66SnMDVOfOWY/YAoiD7Jxa9iHvngcag==",
-      "dev": true
-    },
     "pump": {
       "version": "3.0.2",
       "resolved": "https://registry.npmjs.org/pump/-/pump-3.0.2.tgz",
@@ -3170,23 +3128,23 @@
       "dev": true
     },
     "puppeteer": {
-      "version": "23.4.0",
-      "resolved": "https://registry.npmjs.org/puppeteer/-/puppeteer-23.4.0.tgz",
-      "integrity": "sha512-FxgFFJI7NAsX8uebiEDSjS86vufz9TaqERQHShQT0lCbSRI3jUPEcz/0HdwLiYvfYNsc1zGjqY3NsGZya4PvUA==",
+      "version": "23.4.1",
+      "resolved": "https://registry.npmjs.org/puppeteer/-/puppeteer-23.4.1.tgz",
+      "integrity": "sha512-+wWfWTkQ8L9IB/3OVGSUp37c0eQ5za/85KdX+LAq2wTZkMdocgYGMCs+/91e2f/RXIYzve4x/uGxN8zG2sj8+w==",
       "dev": true,
       "requires": {
         "@puppeteer/browsers": "2.4.0",
         "chromium-bidi": "0.6.5",
         "cosmiconfig": "^9.0.0",
         "devtools-protocol": "0.0.1342118",
-        "puppeteer-core": "23.4.0",
+        "puppeteer-core": "23.4.1",
         "typed-query-selector": "^2.12.0"
       }
     },
     "puppeteer-core": {
-      "version": "23.4.0",
-      "resolved": "https://registry.npmjs.org/puppeteer-core/-/puppeteer-core-23.4.0.tgz",
-      "integrity": "sha512-fqkIP5FOcb38jfBj/OcBz1wFaI9nk40uQKSORvnXws6wCbep2dg8yxZ3ddJxBIfQsxoiEOvnrykFinUScrB/ew==",
+      "version": "23.4.1",
+      "resolved": "https://registry.npmjs.org/puppeteer-core/-/puppeteer-core-23.4.1.tgz",
+      "integrity": "sha512-uCxGtn8VE9PlKhdFJX/zZySi9K3Ufr3qUZe28jxJoZUqiMJOi+SFh2zhiFDSjWqZIDkc0FtnaCC+rewW3MYXmg==",
       "dev": true,
       "requires": {
         "@puppeteer/browsers": "2.4.0",
@@ -3197,12 +3155,6 @@
         "ws": "^8.18.0"
       }
     },
-    "querystringify": {
-      "version": "2.2.0",
-      "resolved": "https://registry.npmjs.org/querystringify/-/querystringify-2.2.0.tgz",
-      "integrity": "sha512-FIqgj2EUvTa7R50u0rGsyTftzjYmv/a3hO345bZNrqabNqjtgiDMgmo4mkUjd+nzU5oF3dClKqFIPUKybUyqoQ==",
-      "dev": true
-    },
     "queue-tick": {
       "version": "1.0.1",
       "resolved": "https://registry.npmjs.org/queue-tick/-/queue-tick-1.0.1.tgz",
@@ -3233,12 +3185,6 @@
       "integrity": "sha512-fGxEI7+wsG9xrvdjsrlmL22OMTTiHRwAMroiEeMgq8gzoLC/PQr7RsRDSTLUg/bZAZtF+TVIkHc6/4RIKrui+Q==",
       "dev": true
     },
-    "requires-port": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/requires-port/-/requires-port-1.0.0.tgz",
-      "integrity": "sha512-KigOCHcocU3XODJxsu8i/j8T9tzT4adHiecwORRQ0ZZFcp7ahwXuRU1m+yuO90C5ZUyGeGfocHDI14M3L3yDAQ==",
-      "dev": true
-    },
     "resolve-from": {
       "version": "4.0.0",
       "resolved": "https://registry.npmjs.org/resolve-from/-/resolve-from-4.0.0.tgz",
@@ -3246,9 +3192,9 @@
       "dev": true
     },
     "rrweb-cssom": {
-      "version": "0.6.0",
-      "resolved": "https://registry.npmjs.org/rrweb-cssom/-/rrweb-cssom-0.6.0.tgz",
-      "integrity": "sha512-APM0Gt1KoXBz0iIkkdB/kfvGOwC4UuJFeG/c+yV7wSc7q96cG/kJ0HiYCnzivD9SB53cLV1MlHFNfOuPaadYSw==",
+      "version": "0.7.1",
+      "resolved": "https://registry.npmjs.org/rrweb-cssom/-/rrweb-cssom-0.7.1.tgz",
+      "integrity": "sha512-TrEMa7JGdVm0UThDJSx7ddw5nVm3UJS9o9CCIZ72B1vSyEZoziDqBYP3XIoi/12lKrJR8rE3jeFHMok2F/Mnsg==",
       "dev": true
     },
     "run-script-os": {
@@ -3424,24 +3370,28 @@
       "integrity": "sha512-w89qg7PI8wAdvX60bMDP+bFoD5Dvhm9oLheFp5O4a2QF0cSBGsBX4qZmadPMvVqlLJBBci+WqGGOAPvcDeNSVg==",
       "dev": true
     },
+    "tldts": {
+      "version": "6.1.47",
+      "resolved": "https://registry.npmjs.org/tldts/-/tldts-6.1.47.tgz",
+      "integrity": "sha512-R/K2tZ5MiY+mVrnSkNJkwqYT2vUv1lcT6wJvd2emGaMJ7PHUGRY4e3tUsdFCXgqxi2QgbHjL3yJgXCo40v9Hxw==",
+      "dev": true,
+      "requires": {
+        "tldts-core": "^6.1.47"
+      }
+    },
+    "tldts-core": {
+      "version": "6.1.47",
+      "resolved": "https://registry.npmjs.org/tldts-core/-/tldts-core-6.1.47.tgz",
+      "integrity": "sha512-6SWyFMnlst1fEt7GQVAAu16EGgFK0cLouH/2Mk6Ftlwhv3Ol40L0dlpGMcnnNiiOMyD2EV/aF3S+U2nKvvLvrA==",
+      "dev": true
+    },
     "tough-cookie": {
-      "version": "4.1.4",
-      "resolved": "https://registry.npmjs.org/tough-cookie/-/tough-cookie-4.1.4.tgz",
-      "integrity": "sha512-Loo5UUvLD9ScZ6jh8beX1T6sO1w2/MpCRpEP7V280GKMVUQ0Jzar2U3UJPsrdbziLEMMhu3Ujnq//rhiFuIeag==",
+      "version": "5.0.0",
+      "resolved": "https://registry.npmjs.org/tough-cookie/-/tough-cookie-5.0.0.tgz",
+      "integrity": "sha512-FRKsF7cz96xIIeMZ82ehjC3xW2E+O2+v11udrDYewUbszngYhsGa8z6YUMMzO9QJZzzyd0nGGXnML/TReX6W8Q==",
       "dev": true,
       "requires": {
-        "psl": "^1.1.33",
-        "punycode": "^2.1.1",
-        "universalify": "^0.2.0",
-        "url-parse": "^1.5.3"
-      },
-      "dependencies": {
-        "universalify": {
-          "version": "0.2.0",
-          "resolved": "https://registry.npmjs.org/universalify/-/universalify-0.2.0.tgz",
-          "integrity": "sha512-CJ1QgKmNg3CwvAv/kOFmtnEN05f0D/cn9QntgNOQlQF9dgvVTHj3t+8JPdjqawCHk7V/KA+fbUqzZ9XWhcqPUg==",
-          "dev": true
-        }
+        "tldts": "^6.1.32"
       }
     },
     "tr46": {
@@ -3488,16 +3438,6 @@
       "integrity": "sha512-hAZsKq7Yy11Zu1DE0OzWjw7nnLZmJZYTDZZyEFHZdUhV8FkH5MCfoU1XMaxXovpyW5nq5scPqq0ZDP9Zyl04oQ==",
       "dev": true
     },
-    "url-parse": {
-      "version": "1.5.10",
-      "resolved": "https://registry.npmjs.org/url-parse/-/url-parse-1.5.10.tgz",
-      "integrity": "sha512-WypcfiRhfeUP9vvF0j6rw0J3hrWrw6iZv3+22h6iRMJ/8z1Tj6XfLP4DsUix5MhMPnXpiHDoKyoZ/bdCkwBCiQ==",
-      "dev": true,
-      "requires": {
-        "querystringify": "^2.1.1",
-        "requires-port": "^1.0.0"
-      }
-    },
     "urlpattern-polyfill": {
       "version": "10.0.0",
       "resolved": "https://registry.npmjs.org/urlpattern-polyfill/-/urlpattern-polyfill-10.0.0.tgz",
diff --git a/src/package.json b/src/package.json
index 3316457a19b..9075904268b 100644
--- a/src/package.json
+++ b/src/package.json
@@ -37,11 +37,11 @@
   "devDependencies": {
     "ejs": "3.1.10",
     "fs-extra": "11.2.0",
-    "jsdom": "25.0.0",
+    "jsdom": "25.0.1",
     "node-fetch": "3.3.2",
     "node-watch": "0.7.4",
     "prettier": "3.3.3",
-    "puppeteer": "23.4.0",
+    "puppeteer": "23.4.1",
     "rainbow-code": "2.1.7",
     "recursive-readdir": "2.2.3",
     "run-script-os": "1.1.6",
diff --git a/src/templates/en/2021/methodology.html b/src/templates/en/2021/methodology.html
index ff60987653a..6cacf2c2d36 100644
--- a/src/templates/en/2021/methodology.html
+++ b/src/templates/en/2021/methodology.html
@@ -323,7 +323,7 @@ <h3 id="chrome-ux-report"><a href="#chrome-ux-report" class="anchor-link">Chrome
       </p>
 
       <p>
-        As of this year, the Chrome UX Report dataset now includes relative <a href="https://developers.google.com/web/updates/2021/03/crux-rank-magnitude">website ranking data</a>. These are referred to as <em>rank magnitudes</em> because, as opposed to fine-grained ranks like the #1 or #116 most popular websites, websites are grouped into rank buckets from the top 1k, top 10k, up to the top 10M. Each website is ranked according to the number of <a href="https://developer.chrome.com/docs/crux/methodology/#eligibility">eligible</a> page views on all of its pages combined. This year's Web Almanac makes extensive use of this new data as a way to explore variations in the way the web is built by site popularity.
+        As of this year, the Chrome UX Report dataset now includes relative <a href="https://developers.google.com/web/updates/2021/03/crux-rank-magnitude">website ranking data</a>. These are referred to as <em>rank magnitudes</em> because, as opposed to fine-grained ranks like the #1 or #116 most popular websites, websites are grouped into rank buckets from the top 1k, top 10k, up to the top 10M. Each website is ranked according to the number of <a href="https://developer.chrome.com/docs/crux/methodology#eligibility">eligible</a> page views on all of its pages combined. This year's Web Almanac makes extensive use of this new data as a way to explore variations in the way the web is built by site popularity.
       </p>
 
       <p>
diff --git a/src/templates/en/2022/methodology.html b/src/templates/en/2022/methodology.html
index 021e1e3568b..d9257bb40ee 100644
--- a/src/templates/en/2022/methodology.html
+++ b/src/templates/en/2022/methodology.html
@@ -250,7 +250,7 @@ <h3 id="webpagetest"><a href="#webpagetest" class="anchor-link">WebPageTest</a><
       <h3 id="lighthouse"><a href="#lighthouse" class="anchor-link">Lighthouse</a></h3>
 
       <p>
-        <a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/overview/">Lighthouse</a> is an automated website quality assurance tool built by Google. It audits web pages to make sure they don&#8217;t include user experience antipatterns like unoptimized images and inaccessible content.
+        <a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/overview">Lighthouse</a> is an automated website quality assurance tool built by Google. It audits web pages to make sure they don&#8217;t include user experience antipatterns like unoptimized images and inaccessible content.
       </p>
 
       <p>
@@ -295,7 +295,7 @@ <h3 id="lighthouse"><a href="#lighthouse" class="anchor-link">Lighthouse</a></h3
       </div></div>
 
       <p>
-        For more information about Lighthouse and the audits available in HTTP Archive, refer to the <a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/overview/">Lighthouse developer documentation</a>.
+        For more information about Lighthouse and the audits available in HTTP Archive, refer to the <a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/overview">Lighthouse developer documentation</a>.
       </p>
     </section>
 
@@ -323,11 +323,11 @@ <h3 id="wappalyzer"><a href="#wappalyzer" class="anchor-link">Wappalyzer</a></h3
       <h3 id="chrome-ux-report"><a href="#chrome-ux-report" class="anchor-link">Chrome UX Report</a></h3>
 
       <p>
-        The <a hreflang="en" href="https://developer.chrome.com/docs/crux/">Chrome UX Report</a> is a public dataset of real-world Chrome user experiences. Experiences are grouped by websites&#8217; origin, for example <code>https://www.example.com</code>. The dataset includes distributions of UX metrics like paint, load, interaction, and layout stability. In addition to grouping by month, experiences may also be sliced by dimensions like country-level geography, form factor (desktop, phone, tablet), and effective connection type (4G, 3G, etc.).
+        The <a hreflang="en" href="https://developer.chrome.com/docs/crux">Chrome UX Report</a> is a public dataset of real-world Chrome user experiences. Experiences are grouped by websites&#8217; origin, for example <code>https://www.example.com</code>. The dataset includes distributions of UX metrics like paint, load, interaction, and layout stability. In addition to grouping by month, experiences may also be sliced by dimensions like country-level geography, form factor (desktop, phone, tablet), and effective connection type (4G, 3G, etc.).
       </p>
 
       <p>
-        The Chrome UX Report dataset includes relative <a href="https://developer.chrome.com/blog/crux-rank-magnitude/">website ranking data</a>. These are referred to as <em>rank magnitudes</em> because, as opposed to fine-grained ranks like the #1 or #116 most popular websites, websites are grouped into rank buckets from the top 1k, top 10k, up to the top 10M. Each website is ranked according to the number of <a href="https://developer.chrome.com/docs/crux/methodology/#eligibility">eligible</a> page views on all of its pages combined. This year's Web Almanac makes extensive use of this new data as a way to explore variations in the way the web is built by site popularity.
+        The Chrome UX Report dataset includes relative <a href="https://developer.chrome.com/blog/crux-rank-magnitude">website ranking data</a>. These are referred to as <em>rank magnitudes</em> because, as opposed to fine-grained ranks like the #1 or #116 most popular websites, websites are grouped into rank buckets from the top 1k, top 10k, up to the top 10M. Each website is ranked according to the number of <a href="https://developer.chrome.com/docs/crux/methodology#eligibility">eligible</a> page views on all of its pages combined. This year's Web Almanac makes extensive use of this new data as a way to explore variations in the way the web is built by site popularity.
       </p>
 
       <p>
diff --git a/src/templates/ja/2021/methodology.html b/src/templates/ja/2021/methodology.html
index 76de0e6bca2..4d12792eb77 100644
--- a/src/templates/ja/2021/methodology.html
+++ b/src/templates/ja/2021/methodology.html
@@ -323,7 +323,7 @@ <h3 id="chrome-ux-report"><a href="#chrome-ux-report" class="anchor-link">Chrome
       </p>
 
       <p>
-        今年から、Chrome UXレポートのデータセットに、相対的な  <a href="https://developers.google.com/web/updates/2021/03/crux-rank-magnitude">Web サイト ランキング データ</a> が含まれるようになりました。これらは、<em>ランク マグニチュード</em>と呼ばれます。なぜなら、もっとも普及しているウェブサイトの1位や116位といった細かいランクとは対照的に、ウェブサイトは上位1K、上位10K、上位10Mまでのランクバケットにグループ化されるからです。各ウェブサイトは、そのすべてのページを合わせた<a href="https://developer.chrome.com/docs/crux/methodology/#eligibility">対象</a>ページビューの数によってランク付けされています。今年のWeb Almanacは、サイトの人気度によるウェブの構築方法のバリエーションを探る方法として、この新しいデータを広範に利用しています。
+        今年から、Chrome UXレポートのデータセットに、相対的な  <a href="https://developers.google.com/web/updates/2021/03/crux-rank-magnitude">Web サイト ランキング データ</a> が含まれるようになりました。これらは、<em>ランク マグニチュード</em>と呼ばれます。なぜなら、もっとも普及しているウェブサイトの1位や116位といった細かいランクとは対照的に、ウェブサイトは上位1K、上位10K、上位10Mまでのランクバケットにグループ化されるからです。各ウェブサイトは、そのすべてのページを合わせた<a href="https://developer.chrome.com/docs/crux/methodology#eligibility">対象</a>ページビューの数によってランク付けされています。今年のWeb Almanacは、サイトの人気度によるウェブの構築方法のバリエーションを探る方法として、この新しいデータを広範に利用しています。
       </p>
 
       <p>
diff --git a/src/templates/ja/2022/methodology.html b/src/templates/ja/2022/methodology.html
new file mode 100644
index 00000000000..9a00e6020f2
--- /dev/null
+++ b/src/templates/ja/2022/methodology.html
@@ -0,0 +1,489 @@
+{% extends "base/methodology.html" %}
+
+{% block title %}方法論 | HTTP ArchiveによるWeb Almanac{% endblock %}
+
+{% block description %}{{ year }}年のWeb Almanacがどのように構築されたかを説明します。使用されたデータセットとツール、およびプロジェクトの運営方法。{% endblock %}
+
+{% block twitter_image_alt %}{{ year }} Web Almanacの方法論{% endblock %}
+
+{% block index %}
+      <ul>
+        <li><a href="#overview">概要</a></li>
+        <li><a href="#dataset">データセットについて</a>
+          <ul>
+            <li><a href="#websites">ウェブサイト</a></li>
+            <li><a href="#metrics">メトリクス</a></li>
+          </ul>
+        </li>
+        <li><a href="#tools">ツール</a>
+          <ul>
+            <li><a href="#webpagetest">ウェブページテスト</a></li>
+            <li><a href="#lighthouse">Lighthouse</a></li>
+            <li><a href="#wappalyzer">Wappalyzer</a></li>
+            <li><a href="#chrome-ux-report">Chrome UXレポート</a></li>
+            <li><a href="#blink-features">Blink機能</a></li>
+            <li><a href="#third-party-web">サードパーティWeb</a></li>
+            <li><a href="#rework-css">Rework CSS</a>
+              <ul>
+                <li><a href="#rework-utils">Rework Utils</a></li>
+              </ul>
+            </li>
+            <li><a href="#parsel">Parsel</a></li>
+          </ul>
+        </li>
+        <li><a href="#process">分析プロセス</a>
+          <ul>
+            <li><a href="#planning">計画</a></li>
+            <li><a href="#analysis">分析</a></li>
+            <li><a href="#interpretation">解釈</a></li>
+          </ul>
+        </li>
+        <li><a href="#looking-ahead">将来の展望</a></li>
+      </ul>
+{% endblock %}
+
+{% block main_content %}
+    <section>
+      <!-- Show large image for large screens and high density screens and use webp when supported -->
+      <picture>
+          <source media="(min-width: 327px)" type="image/webp" srcset="/static/images/methodology-banner.webp">
+          <source media="(min-width: 327px)" type="image/jpeg" srcset="/static/images/methodology-banner.png">
+          <source type="image/webp" srcset="/static/images/methodology-banner.webp 2x">
+          <source type="image/jpeg" srcset="/static/images/methodology-banner.png 2x">
+          <source type="image/webp" srcset="/static/images/methodology-banner-sm.webp">
+          <source type="image/jpeg" srcset="/static/images/methodology-banner-sm.png">
+          <img src="/static/images/methodology-banner.png" class="content-banner" alt="" width="1200" height="984" fetchpriority="high">
+        </picture>
+        <h2 id="overview"><a href="#overview" class="anchor-link">概要</a></h2>
+
+        <p>
+          Web Almanacは、<a hreflang="en" href="https://httparchive.org">HTTP Archive</a>によって組織されたプロジェクトです。HTTP Archiveは、2010年にSteve Soudersによってウェブがどのように構築されているかを追跡する使命で始まりました。月に数百万のウェブページの構成を評価し、そのテラバイトのメタデータを<a hreflang="en" href="https://httparchive.org/faq#how-do-i-use-bigquery-to-write-custom-queries-over-the-data">BigQuery</a>で分析用に提供しています。
+        </p>
+
+        <p>
+          The Web Almanacの使命は、Webの現状に関する公共知識の年間リポジトリになることです。我々の目標は、HTTP ArchiveのデータウェアハウスをWebコミュニティにとってさらにアクセスしやすくすることであり、専門家がコンテキストに沿った洞察を提供することでこれを実現します。
+        </p>
+
+        <p>
+          {{ year }}年版のWeb Almanacは、コンテンツ、エクスペリエンス、パブリッシング、ディストリビューションの4つの部分に分かれています。それぞれの部分では、複数の章がさまざまな角度からその全体的なテーマを探ります。たとえば、第2部では、パフォーマンス、セキュリティ、アクセシビリティの章などでユーザーエクスペリエンスを異なる視点から探求しています。
+        </p>
+    </section>
+
+    <section>
+        <h2 id="dataset"><a href="#dataset" class="anchor-link">データセットについて        </a></h2>
+
+        <p>
+          HTTP Archiveのデータセットは、毎月新しいデータで継続的に更新されています。{{ year }}年版のWeb Almanacでは、とくに章で記載がない限り、すべての指標は{{ year }}年6月のクロールから取得されました。これらの結果は、BigQuery上で<code>{{ year }}_06_01</code>というプレフィックスが付いたテーブルで<a hreflang="en" href="https://github.com/HTTPArchive/httparchive.org/blob/main/docs/gettingstarted_bigquery.md">公開クエリが可能</a>です。
+        </p>
+
+        <p>
+          Web Almanacで提示されているすべての指標は、BigQuery上のデータセットを使用して公開再現可能です。すべての章で使用されたクエリは、<a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/{{ year }}">GitHubリポジトリ</a>で閲覧できます。
+        </p>
+
+        <p 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>
+
+        <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>を参照してください。
+        </p>
+
+        <div class="code-block floating-card">
+          {# このマークアップを生成するには、一時的に```sqlコードブロックを章に追加し、その章を生成すると、次のような HTML が得られます。 #}
+          {# キーボードスクロールを可能にするため、preタグに余分な属性があることに注意し、それらを元に戻す。 #}
+          <pre role="region" aria-label="bytes_2022.sql" tabindex="0"><code class="sql language-sql"><span class="comment">#standardSQL</span>
+<span class="comment"># Sum of JS request bytes per page (2022)</span>
+<span class="keyword">SELECT</span>
+  percentile,
+  _TABLE_SUFFIX <span class="keyword">AS</span> client,
+  <span class="function call">APPROX_QUANTILES</span>(bytesJs / <span class="constant numeric">1024</span>, <span class="constant numeric">1000</span>)[<span class="function call">OFFSET</span>(percentile <span class="keyword operator">*</span> <span class="constant numeric">10</span>)] <span class="keyword">AS</span> js_kilobytes
+<span class="keyword">FROM</span>
+  <span class="string">`httparchive.summary_pages.2022_06_01_*`</span>,
+  <span class="function call">UNNEST</span>([<span class="constant numeric">10</span>, <span class="constant numeric">25</span>, <span class="constant numeric">50</span>, <span class="constant numeric">75</span>, <span class="constant numeric">90</span>, <span class="constant numeric">100</span>]) <span class="keyword">AS</span> percentile
+<span class="keyword">GROUP</span> <span class="keyword">BY</span>
+  percentile,
+  client
+<span class="keyword">ORDER</span> <span class="keyword">BY</span>
+  client,
+  percentile</code></pre></div>
+
+        <p>
+          Results for each metric are publicly viewable in chapter-specific spreadsheets, for example <a href="https://docs.google.com/spreadsheets/d/1vOeFUyfEtWRen3Xj57ZsWav40n5tlcJoV0HmAxmNE_I/edit?usp=sharing">JavaScript results</a>. Links to the raw results and queries are available at the bottom of each chapter. Metric-specific results and queries are also linked directly from each figure.
+        </p>
+    </section>
+
+    <section>
+        <h3 id="websites"><a href="#websites" class="anchor-link">Websites</a></h3>
+
+        <p>
+          データセットには8,360,179のウェブサイトが含まれています。そのうち、7,905,956はモバイルウェブサイトで、5,428,235はデスクトップウェブサイトです。ほとんどのウェブサイトは、モバイルおよびデスクトップの両方のサブセットに含まれています。
+        </p>
+
+        <p>
+          HTTP Archiveは、<a href="#chrome-ux-report">Chrome UX Report</a>からウェブサイトのURLを取得しています。Chrome UX Reportは、Googleによる公開データセットで、Chromeユーザーが積極的に訪問している何百万ものウェブサイトにおけるユーザーエクスペリエンスを集約しています。これにより、最新の実際のWeb使用状況を反映したウェブサイトのリストを入手できます。Chrome UX Reportのデータセットにはフォームファクターの次元が含まれており、これを使用してデスクトップまたはモバイルユーザーがアクセスしたすべてのウェブサイトを取得しています。
+        </p>
+
+        <p>
+          Web Almanacで使用された{{ year }}年6月のHTTP Archiveクロールは、もっとも最近利用可能なChrome UX Reportリリースをウェブサイトのリストとして使用しました。{{ year }}04のデータセットは{{ year }}年5月3日にリリースされ、4月にChromeユーザーが訪問したウェブサイトをキャプチャしています。
+        </p>
+
+        <p>
+          リソースの制約により、HTTP Archiveは以前、Chrome UX Reportの各ウェブサイトから1ページしかテストできず、ホームページのみが含まれていました。ホームページは必ずしもウェブサイト全体を代表しているわけではないため、結果にバイアスがかかる可能性があることに注意してください。今年、Web Almanacプロジェクトが開始された後に<a hreflang="en" href="https://discuss.httparchive.org/t/improving-the-http-archive-pipeline-and-dataset-by-10x/2372">セカンダリページ</a>を導入し、一部の章ではこの新しいデータを使用しています。しかし、ほとんどの章ではホームページのみを使用しました。今後の分析では、この新しいデータセットがさらに活用されることを期待しています。
+        </p>
+
+        <p>
+          HTTP Archiveは、ラボテストツールとも見なされており、データセンターからウェブサイトをテストし、実際のユーザーエクスペリエンスからのデータを収集していません。すべてのページは、キャッシュが空の状態で、ログアウトした状態でテストされており、実際のユーザーがアクセスする方法を反映していない場合があります。
+        </p>
+    </section>
+
+    <section>
+      <h3 id="metrics"><a href="#metrics" class="anchor-link">メトリクス</a></h3>
+
+      <p>
+        HTTP Archiveは、Webがどのように構築されているかについて何千ものメトリクスを収集しています。これには、ページごとのバイト数、ページがHTTPSで読み込まれたかどうか、個々のリクエストおよびレスポンスヘッダーなどの基本的なメトリクスが含まれます。これらのメトリクスの大部分は、各ウェブサイトのテストランナーとして機能する<a href="#webpagetest">WebPageTest</a>によって提供されます。
+      </p>
+
+      <p>
+        他のテストツールは、ページに関するより高度なメトリクスを提供するために使用されます。たとえば、<a href="#lighthouse">Lighthouse</a>は、アクセシビリティやSEOなどの分野でページの品質を分析するための監査を実行するために使用されます。これらのツールの詳細については、下の<a href="#tools">ツール</a>セクションで説明しています。
+      </p>
+
+      <p>
+        ラボデータセットの固有の制約を回避するために、Web Almanacは、とくにウェブパフォーマンスの分野でのユーザーエクスペリエンスに関するメトリクスのために<a href="#chrome-ux-report">Chrome UX Report</a>も使用しています。
+      </p>
+
+      <p>
+        一部のメトリクスは完全に把握できません。たとえば、ウェブサイトを構築するために使用されたツールを検出する能力は必ずしも持っていません。create-react-appを使用してウェブサイトが構築されている場合、そのサイトがReactフレームワークを使用していることはわかりますが、特定のビルドツールが使用されているかどうかは必ずしもわかりません。これらのツールがウェブサイトのコードに検出可能な指紋を残さない限り、それらの使用を測定することはできません。
+      </p>
+
+      <p>
+        他のメトリクスは測定が不可能ではないにしても、挑戦的であるか、信頼性が低いことがあります。たとえば、ウェブデザインの側面は本質的に視覚的であり、ページに煩わしいモーダルダイアログがあるかどうかなど、定量化が困難です。
+      </p>
+    </section>
+
+    <section>
+      <h2 id="tools"><a href="#tools" class="anchor-link">ツール</a></h2>
+
+      <p>
+        Web Almanacは、次のオープンソースツールの助けを借りて実現されています。
+      </p>
+    </section>
+
+    <section>
+      <h3 id="webpagetest"><a href="#webpagetest" class="anchor-link">WebPageTest</a></h3>
+
+      <p>
+        <a hreflang="en" href="https://www.webpagetest.org/">WebPageTest</a>は、著名なウェブパフォーマンステストツールであり、HTTP Archiveの基盤です。私たちは、<a hreflang="en" href="https://docs.webpagetest.org/private-instances/">プライベートインスタンス</a>のWebPageTestを使用しており、各ウェブページをテストするためのプライベートテストエージェント（実際のブラウザ）を使用しています。デスクトップおよびモバイルウェブサイトは、異なる構成でテストされています。
+      </p>
+      <div class="table-wrap"><div class="table-wrap-container">
+      <table>
+        <thead>
+          <tr>
+              <th>設定</th>
+              <th>デスクトップ</th>
+              <th>モバイル</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr>
+            <td>デバイス</td>
+            <td>Linux VM</td>
+            <td>エミュレートされたMoto G4</td>
+          </tr>
+
+          <tr>
+            <td>ユーザーエージェント</td>
+            <td>
+              Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.61 Safari/537.36 PTST/220609.133020
+            </td>
+            <td>
+              Mozilla/5.0 (Linux; Android 8.1.0; Moto G (4)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.115 Mobile Safari/537.36 PTST/220609.133020
+            </td>
+          </tr>
+
+          <tr>
+            <td>ロケーション</td>
+            <td>
+              Google Cloud Locations, USA
+            </td>
+            <td>
+              Google Cloud Locations, USA
+            </td>
+          </tr>
+
+          <tr>
+            <td>接続</td>
+            <td>Cable (5/1 Mbps 28ms RTT)</td>
+            <td>4G (9 Mbps 170ms RTT)</td>
+          </tr>
+
+          <tr>
+            <td>ビューポート</td>
+            <td>1376 x 768px</td>
+            <td>512 x 360px</td>
+          </tr>
+        </tbody>
+      </table>
+      </div></div>
+
+      <p>
+        デスクトップウェブサイトは、Linux VM上のデスクトップChrome環境内で実行されます。ネットワーク速度はケーブル接続に相当します。
+      </p>
+
+      <p>
+        モバイルウェブサイトは、エミュレートされたMoto G4デバイス上のモバイルChrome環境内で実行され、ネットワーク速度は4G接続に相当します。
+      </p>
+
+      <p>
+        テストエージェントは、米国に拠点を置くさまざまな<a hreflang="en" href="https://cloud.google.com/compute/docs/regions-zones/#locations">Google Cloud Platformロケーション</a>から実行されます。
+      </p>
+
+      <p>
+        HTTP ArchiveのWebPageTestのプライベートインスタンスは、最新のパブリックバージョンと同期されており、<a hreflang="en" href="https://github.com/HTTPArchive/custom-metrics">カスタムメトリクス</a>が追加されています。これらは、各ウェブサイトでテストの終了時に評価されるJavaScriptのスニペットです。
+      </p>
+
+      <p>
+        各テストの結果は、ウェブページに関するメタデータを含むJSON形式のアーカイブファイルである<a href="https://en.wikipedia.org/wiki/HAR_(file_format)">HARファイル</a>として利用可能です。
+      </p>
+    </section>
+
+    <section>
+      <h3 id="lighthouse"><a href="#lighthouse" class="anchor-link">Lighthouse</a></h3>
+
+      <p>
+        <a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/overview/">Lighthouse</a>は、Googleによって開発された自動ウェブサイト品質保証ツールです。ウェブページを監査し、最適化されていない画像やアクセシビリティのないコンテンツなど、ユーザーエクスペリエンスに反するパターンが含まれていないことを確認します。
+      </p>
+
+      <p>
+        HTTP Archiveは、すべてのページで最新バージョンのLighthouseを実行しています。今年ははじめて、Lighthouseテストがモバイルとデスクトップの両方のページで行われています。{{ year }}年6月のクロール時点で、HTTP Archiveは<a hreflang="en" href="https://github.com/GoogleChrome/lighthouse/releases/tag/v9.6.2">9.6.2</a>バージョンのLighthouseを使用しました。
+      </p>
+
+      <p>
+        Lighthouseは、<a href="#webpagetest">WebPageTest</a>内から独自のテストとして実行されますが、独自の設定プロファイルを持っています。
+      </p>
+      <div class="table-wrap"><div class="table-wrap-container">
+      <table>
+        <thead>
+          <tr>
+            <th>設定</th>
+            <th>デスクトップ</th>
+            <th>モバイル</th>
+          </tr>
+        </thead>
+        <tbody>
+          <tr>
+            <td>CPUの速度低下</td>
+            <td><em>N/A</em></td>
+            <td>1x/4x</td>
+          </tr>
+          <tr>
+            <td>ダウンロードのスループット</td>
+            <td>1.6 Mbps</td>
+            <td>1.6 Mbps</td>
+          </tr>
+          <tr>
+            <td>アップロードのスループット</td>
+            <td>0.768 Mbps</td>
+            <td>0.768 Mbps</td>
+          </tr>
+          <tr>
+            <td>RTT</td>
+            <td>150 ms</td>
+            <td>150 ms</td>
+          </tr>
+        </tbody>
+      </table>
+      </div></div>
+
+      <p>
+        LighthouseおよびHTTP Archiveで利用可能な監査に関する詳細は、<a hreflang="en" href="https://developer.chrome.com/docs/lighthouse/overview/">Lighthouse開発者ドキュメント</a>を参照してください。
+      </p>
+    </section>
+
+    <section>
+      <h3 id="wappalyzer"><a href="#wappalyzer" class="anchor-link">Wappalyzer</a></h3>
+
+      <p>
+        <a hreflang="en" href="https://www.wappalyzer.com/">Wappalyzer</a>は、ウェブページで使用されている技術を検出するツールです。JavaScriptフレームワーク、CMSプラットフォーム、さらには暗号通貨マイナーまで、<a hreflang="en" href="https://www.wappalyzer.com/technologies">98のカテゴリ</a>にわたる技術がテストされています。サポートされている技術は3,805を超えており（昨年の2,600から増加しています）。
+      </p>
+
+      <p>
+        HTTP Archiveは、すべてのウェブページで最新バージョンのWappalyzerを実行しています。{{ year }}年7月の時点で、Web Almanacは<a hreflang="en" href="https://github.com/AliasIO/Wappalyzer/releases/tag/v6.10.26">6.10.26バージョン</a>のWappalyzerを使用しました。
+      </p>
+
+      <p>
+        Wappalyzerは、WordPress、Bootstrap、jQueryなどの開発者ツールの人気を分析する多くの章で利用されています。たとえば、<a href="{{ url_for('chapter', year=year, lang=lang, chapter='cms') }}">CMS</a>章では、Wappalyzerが検出した<a hreflang="en" href="https://www.wappalyzer.com/categories/cms">CMS</a>カテゴリの技術に大きく依存しています。
+      </p>
+
+      <p>
+        Wappalyzerを含むすべての検出ツールには制限があります。その結果の正確性は、検出メカニズムの精度に依存します。Web Almanacは、Wappalyzerが使用されるすべての章において、特定の理由で分析が正確でない可能性がある場合、その旨を注記します。
+      </p>
+    </section>
+
+    <section>
+      <h3 id="chrome-ux-report"><a href="#chrome-ux-report" class="anchor-link">Chrome UX Report</a></h3>
+
+      <p>
+        <a hreflang="en" href="https://developer.chrome.com/docs/crux/">Chrome UX Report</a>は、実際のChromeユーザーのエクスペリエンスに関する公開データセットです。エクスペリエンスは、ウェブサイトのオリジンごとにグループ化されます。たとえば、<code>https://www.example.com</code>です。このデータセットには、ペイント、ロード、インタラクション、レイアウト安定性などのUX指標の分布が含まれています。月ごとにグループ化されるだけでなく、国レベルの地理、フォームファクター（デスクトップ、電話、タブレット）、有効な接続タイプ（4G、3Gなど）などの次元で分割することもできます。
+      </p>
+
+      <p>
+        Chrome UX Reportのデータセットには、相対的な<a href="https://developer.chrome.com/blog/crux-rank-magnitude/">ウェブサイトランキングデータ</a>も含まれています。これらは<em>ランクマグニチュード</em>と呼ばれ、1位や116位のような細かな順位ではなく、上位1k、上位10k、最大で上位10Mまでのランクバケットにウェブサイトがグループ化されます。各ウェブサイトは、すべてのページを合わせた<a href="https://developer.chrome.com/docs/crux/methodology/#eligibility">対象となる</a>ページビューの数に基づいてランク付けされます。今年のWeb Almanacでは、この新しいデータを広範に使用し、サイトの人気によってWebの構築方法にどのような違いがあるかを探る手段としています。
+      </p>
+
+      <p>
+        Web Almanacのメトリクスで、Chrome UX Reportからの実際のユーザーエクスペリエンスデータを参照しているものには、{{ year }}年6月のデータセット（{{ year }}06）が使用されています。
+      </p>
+
+      <p>
+        データセットの詳細については、<a hreflang="en" href="https://web.dev/chrome-ux-report-bigquery">Using the Chrome UX Report on BigQuery</a>ガイドを<a hreflang="en" href="https://web.dev/">web.dev</a>でご覧ください。
+      </p>
+    </section>
+
+    <section>
+      <h3 id="blink-features"><a href="#blink-features" class="anchor-link">Blink Features</a></h3>
+
+      <p>
+        <a href="https://chromium.googlesource.com/chromium/src/+/HEAD/docs/use_counter_wiki.md">Blink Features</a>は、特定のWebプラットフォーム機能が使用されていると検出された際にChromeがフラグを立てる指標です。
+      </p>
+
+      <p>
+        私たちは、Blink Featuresを使用して機能の採用状況を別の視点から捉えています。このデータは、ページに実装されている機能と実際に使用されている機能を区別するのにとくに有用です。たとえば、<a href="{{ url_for('chapter', year=year, lang=lang, chapter='css') }}">CSS</a>章のGridレイアウトに関するセクションでは、Blink Featuresデータを使用して、実際のページレイアウトの一部がGridで構築されているかどうかを測定しています。これに対して、多くのページが未使用のGridスタイルをスタイルシートに含んでいることもあります。どちらの統計もそれぞれに興味深く、Webがどのように構築されているかについて何かを教えてくれます。
+      </p>
+
+      <p>
+        Blink Featuresは、<a href="#webpagetest">WebPageTest</a>の通常のテストの一環として報告されています。
+      </p>
+    </section>
+
+    <section>
+      <h3 id="third-party-web"><a href="#third-party-web" class="anchor-link">Third Party Web</a></h3>
+
+      <p>
+        <a hreflang="en" href="https://www.thirdpartyweb.today/">Third Party Web</a>は、HTTP ArchiveおよびLighthouseデータを使用して、Web上のサードパーティリソースの影響を特定し分析する<a href="{{ url_for('contributors', year=year, lang=lang, _anchor='patrickhulce') }}">Patrick Hulce</a>（<a href="{{ url_for('chapter', year=2019, lang=lang, chapter='third-parties') }}">2019年のサードパーティ</a>章の著者）による研究プロジェクトです。
+      </p>
+
+      <p>
+        ドメインは、少なくとも50の異なるページに表示される場合、サードパーティプロバイダーと見なされます。このプロジェクトでは、プロバイダーを広告、分析、ソーシャルなどのカテゴリごとにグループ化しています。
+      </p>
+
+      <p>
+        Web Almanacのいくつかの章では、このデータセットのドメインとカテゴリを使用して、サードパーティの影響を理解しています。
+      </p>
+    </section>
+
+    <section>
+      <h3 id="rework-css"><a href="#rework-css" class="anchor-link">Rework CSS</a></h3>
+
+      <p>
+        <a hreflang="en" href="https://github.com/reworkcss/css">Rework CSS</a>は、JavaScriptベースのCSSパーサーです。スタイルシート全体を取り込み、各スタイルルール、セレクター、ディレクティブ、値を区別するJSON形式のオブジェクトを生成します。
+      </p>
+
+      <p>
+        この特別なツールは、<a href="{{ url_for('chapter', year=year, lang=lang, chapter='css') }}">CSS</a>章の多くの指標の精度を大幅に向上させました。各ページの全外部スタイルシートおよびインラインスタイルブロックのCSSが解析され、クエリされ、分析が可能になりました。BigQuery上のHTTP Archiveデータセットとの統合方法については、<a hreflang="en" href="https://discuss.httparchive.org/t/analyzing-stylesheets-with-a-js-based-parser/1683">このスレッド</a>を参照してください。
+      </p>
+    </section>
+
+    <section>
+      <h4 id="rework-utils"><a href="#rework-utils" class="anchor-link">Rework Utils</a></h4>
+
+      <p>
+        今年の<a href="{{ url_for('chapter', year=year, lang=lang, chapter='css') }}">CSS</a>章では、2020年のCSS章で導入された多くの指標を再訪します。その章は<a href="{{ url_for('contributors', year=2019, lang=lang, _anchor='LeaVerou') }}">Lea Verou</a>が主導しました。Leaは、Rework CSSの出力から洞察をより簡単に抽出するために<a hreflang="en" href="https://github.com/LeaVerou/rework-utils">Rework Utils</a>を書きました。CSS章で見るほとんどの統計は、これらのスクリプトによって引き続き提供されています。
+      </p>
+    </section>
+
+    <section>
+        <h4 id="parsel"><a href="#parsel" class="anchor-link">Parsel</a></h4>
+
+        <p>
+            <a hreflang="en" href="https://projects.verou.me/parsel/">Parsel</a>は、CSSセレクターパーサーおよび特異性計算機で、元々は<a href="{{ url_for('chapter', year=2019, lang=lang, chapter='css') }}">2020年のCSS</a>章のリーダーである<a href="{{ url_for('contributors', year=year, lang=lang, _anchor='LeaVerou') }}">Lea Verou</a>によって書かれ、別のライブラリとしてオープンソース化されました。これは、セレクターや特異性に関連するすべてのCSS指標で広く使用されています。
+        </p>
+    </section>
+
+    <section>
+      <h2 id="process"><a href="#process" class="anchor-link">分析プロセス</a></h2>
+
+      <p>
+        Web Almanacは、ウェブコミュニティの100人以上の<a href="{{ url_for('contributors', year=year, lang=lang) }}">寄稿者</a>との調整を伴い、計画および実行に約1年かかりました。このセクションでは、Web Almanacで選ばれた章がどのような理由で選ばれ、その指標がどのようにクエリされ、どのように解釈されたかを説明します。
+      </p>
+    </section>
+
+    <section>
+      <h3 id="planning"><a href="#planning" class="anchor-link">計画</a></h3>
+
+      <p>
+        {{ year }}年のWeb Almanacは、{{ year }}年3月に<a href="https://twitter.com/HTTPArchive/status/1508506002383069192">寄稿者募集の呼びかけ</a>でスタートしました。プロジェクトは前年の全26章から始まり、コミュニティから提案された追加のトピックが今年の新しい2章となりました：<a href="{{ url_for('chapter', year=year, lang=lang, chapter='interop') }}">相互運用性</a>と<a href="{{ url_for('chapter', year=year, lang=lang, chapter='sustainability') }}">持続可能性</a>。
+      </p>
+
+      <p>
+        私たちは<a href="../2019/methodology#brainstorming">創刊年の方法論</a>で述べた通り：
+      </p>
+
+      <blockquote>
+        Web Almanacの将来の版の1つの明確な目標は、著者やピアレビュアーとして代表されていない多様な声をさらに奨励することです。
+      </blockquote>
+
+      <p>
+        そのために、今年も<a href="https://github.com/HTTPArchive/almanac.httparchive.org/discussions/2165">著者選定プロセス</a>を続けています：
+      </p>
+
+      <ul>
+        <li>
+          以前の著者には、新しい視点を提供するため、再び執筆することをとくに奨励しませんでした。
+        </li>
+        <li>
+          {{ year }}年の著者を推薦する全員に対して、外見や考え方が同じ人々を推薦しないようにとくに意識するよう求めました。
+        </li>
+        <li>
+          プロジェクトリーダーはすべての著者の推薦をレビューし、新しい視点をもたらし、コミュニティ内の代表されていないグループの声を増幅する著者を選出する努力をしました。
+        </li>
+      </ul>
+
+      <p>
+        私たちは、Web Almanacがさらに多様で包括的なプロジェクトとなるよう、このプロセスを将来的に反復し、すべての背景を持つ寄稿者からの意見を取り入れることを望んでいます。
+      </p>
+    </section>
+
+    <section>
+      <h3 id="analysis"><a href="#analysis" class="anchor-link">分析</a></h3>
+
+      <p>
+        {{ year }}年の4月と5月に、データアナリストは著者およびピアレビュアーと協力して、各章でクエリを実行する必要がある指標のリストを作成しました。場合によっては、分析能力のギャップを埋めるために<a hreflang="en" href="https://github.com/HTTPArchive/custom-metrics">カスタムメトリクス</a>が作成されました。
+      </p>
+
+      <p>
+        {{ year }}年6月を通じて、HTTP Archiveのデータパイプラインは数百万のウェブサイトをクロールし、Web Almanacで使用されるメタデータを収集しました。これらの結果は後処理され、<a href="https://console.cloud.google.com/bigquery?p=httparchive&d=almanac&page=dataset">BigQuery</a>に保存されました。
+      </p>
+
+      <p>
+        4年目となる今年、以前のアナリストによって書かれたクエリを更新して再利用することができました。それでも、ゼロから書かれる必要がある多くの新しい指標がありました。GitHub上のオープンソース<a hreflang="en" href="https://github.com/HTTPArchive/almanac.httparchive.org/tree/main/sql/{{ year }}">クエリリポジトリ</a>で、年度および章ごとのすべてのクエリを閲覧できます。
+      </p>
+    </section>
+
+    <section>
+      <h3 id="interpretation"><a href="#interpretation" class="anchor-link">解釈</a></h3>
+
+      <p>
+        著者はアナリストと協力して結果を正しく解釈し、適切な結論を導き出しました。著者がそれぞれの章を書く際には、これらの統計を利用してウェブの状態を枠組みとして支えました。ピアレビュアーは著者と協力して分析の技術的正確さを保証しました。
+      </p>
+
+      <p>
+        結果を読者により容易に理解してもらうために、ウェブ開発者およびアナリストは章に埋め込むデータビジュアリゼーションを作成しました。いくつかのビジュアライゼーションは、ポイントをより明確にするために簡略化されています。たとえば、完全な分布を示すのではなく、いくつかのパーセンタイルのみが表示されます。とくに記載がない限り、すべての分布はパーセンタイルを使用して要約され、とくに中央値（50パーセンタイル）が使用され、平均は使用されません。
+      </p>
+
+      <p>
+        最後に、編集者が章を見直して単純な文法的な誤りを修正し、読書体験全体の一貫性を保証しました。
+      </p>
+    </section>
+
+    <section>
+      <h2 id="looking-ahead"><a href="#looking-ahead" class="anchor-link">将来に向けて</a></h2>
+
+      <p>
+        {{ year }}年版のWeb Almanacは、ウェブコミュニティの内省と前向きな変化への取り組みとして、継続することを希望する年次の伝統の第4回目です。この地点に到達するまで、多くの献身的な<a href="{{ url_for('contributors', year=year, lang=lang) }}">寄稿者</a>のおかげで壮大な努力がなされました。私たちは、将来の版をさらに効率的にするために、可能な限りこの作業を活用することを望んでいます。
+      </p>
+
+      <p>
+        2023年版のWeb Almanacへの寄与に興味がある方は、<a hreflang="en" href="https://forms.gle/zmk6wXfDrmkkKzXo8">関心フォーム</a>に記入してください。一緒にウェブの状態を追跡しましょう！
+      </p>
+    </section>
+{% endblock main_content %}