Merge branch 'main' of github.com:HTTPArchive/almanac.httparchive.org…

… into production

src/content/en/2019/mobile-web.md

@@ -110,11 +110,11 @@ One of the most beautiful parts of the web is how web pages load progressively b
 
 Imagine you're reading an article when all of a sudden, an image loads and pushes the text you're reading way down the screen. You now have to hunt for where you were or just give up on reading the article. Or, perhaps even worse, you begin to click a link right before an ad loads in the same spot, resulting in an accidental click on the ad instead.
 
-So, how do we measure how much our sites shift? In the past it was quite difficult (if not impossible), but thanks to the new <a hreflang="en" href="https://web.dev/layout-instability-api">Layout Instability API</a> we can do this in two steps:
+So, how do we measure how much our sites shift? In the past it was quite difficult (if not impossible), but thanks to the new <a hreflang="en" href="https://web.dev/articles/cls">Layout Instability API</a> we can do this in two steps:
 
 1. Via the Layout Instability API, track each shift's impact on the page. This is reported to you as a percentage of how much content in the viewport has shifted.
 
-2. Take all the shifts you've tracked and add them together. The result is what we call the <a hreflang="en" href="https://web.dev/layout-instability-api#a-cumulative-layout-shift-score">Cumulative Layout Shift</a> (CLS) score.
+2. Take all the shifts you've tracked and add them together. The result is what we call the <a hreflang="en" href="https://web.dev/articles/cls#a-cumulative-layout-shift-score">Cumulative Layout Shift</a> (CLS) score.
 
 Because every visitor can have a different CLS, in order to analyze this metric across the web with the [Chrome UX Report](./methodology#chrome-ux-report) (CrUX), we combine every experience into three different buckets:
 

src/content/en/2019/performance.md

@@ -139,7 +139,7 @@ Other APAC geos tell a different story. Thailand, Vietnam, Indonesia, and India
 
 ### Time to First Byte (TTFB)
 
-<a hreflang="en" href="https://web.dev/time-to-first-byte">Time to First Byte</a> (TTFB) is a measure of how long the web page took from the time of the user's navigation until they received the first byte of the response.
+<a hreflang="en" href="https://web.dev/articles/ttfb">Time to First Byte</a> (TTFB) is a measure of how long the web page took from the time of the user's navigation until they received the first byte of the response.
 
 {{ figure_markup(
   image="nav-timing.png",
@@ -289,6 +289,6 @@ Quantifying how fast a web page loads is an imperfect science that can't be repr
 
 The data presented in this chapter showed that there is still a lot of work to do to meet the goals set for fast websites. Certain form factors, effective connection types, and geos do correlate with better user experiences, but we can't forget about the combinations of demographics with poor performance. In many cases, the web platform is used for business; making more money from improving conversion rates can be a huge motivator for speeding up a website. Ultimately, for all websites, performance is about delivering positive experiences to users in a way that doesn't impede, frustrate, or enrage them.
 
-As the web gets another year older and our ability to measure how users experience it improves incrementally, I'm looking forward to developers having access to metrics that capture more of the holistic user experience. FCP is very early on the timeline of showing useful content to users, and newer metrics like <a hreflang="en" href="https://web.dev/largest-contentful-paint">Largest Contentful Paint</a> (LCP) are emerging to improve our visibility into how page loads are perceived. The <a hreflang="en" href="https://web.dev/layout-instability-api">Layout Instability API</a> has also given us a novel glimpse into the frustration users experience beyond page load.
+As the web gets another year older and our ability to measure how users experience it improves incrementally, I'm looking forward to developers having access to metrics that capture more of the holistic user experience. FCP is very early on the timeline of showing useful content to users, and newer metrics like <a hreflang="en" href="https://web.dev/articles/lcp">Largest Contentful Paint</a> (LCP) are emerging to improve our visibility into how page loads are perceived. The <a hreflang="en" href="https://web.dev/articles/cls">Layout Instability API</a> has also given us a novel glimpse into the frustration users experience beyond page load.
 
 Equipped with these new metrics, the web in 2020 will become even more transparent, better understood, and give developers an advantage to make more meaningful progress to improve performance and contribute to positive user experiences.

src/content/en/2020/ecommerce.md

@@ -278,7 +278,7 @@ We see a significant increase in the use of third-party requests and bytes [comp
 
 ## Ecommerce user experience
 
-Ecommerce is all about converting customers and in order to do that a fast performing website is paramount. In this section, we try to shed light on real-world user experience of ecommerce websites. To achieve this, we turn our analysis towards some user-perceived performance metrics, which are captured in the three <a hreflang="en" href="https://web.dev/vitals/">Core Web Vitals</a> metrics.
+Ecommerce is all about converting customers and in order to do that a fast performing website is paramount. In this section, we try to shed light on real-world user experience of ecommerce websites. To achieve this, we turn our analysis towards some user-perceived performance metrics, which are captured in the three <a hreflang="en" href="https://web.dev/articles/vitals">Core Web Vitals</a> metrics.
 
 ### Chrome User Experience Report
 

src/content/en/2020/mobile-web.md

@@ -159,7 +159,7 @@ Loading performance is a vast topic, so we picked a couple of aspects to cover h
 
 A key aspect of the loading experience is how quickly the main content of a web page loads and is visible to users. This has been difficult to measure, in the past Google recommended performance metrics like <a hreflang="en" href="https://web.dev/first-meaningful-paint/">First Meaningful Paint</a> (FMP) to capture this, but it was hard to explain, and often unable to identify when the main content of the page was visible.
 
-Sometimes simpler is better. More recently it's been found that a more accurate way to measure when the main content of a page is loaded is to simply look at when the largest element was rendered. <a hreflang="en" href="https://web.dev/largest-contentful-paint">Largest Contentful Paint</a> (LCP) is a timing-based metric that captures this—the time at which the largest above-the-fold element was rendered.
+Sometimes simpler is better. More recently it's been found that a more accurate way to measure when the main content of a page is loaded is to simply look at when the largest element was rendered. <a hreflang="en" href="https://web.dev/articles/lcp">Largest Contentful Paint</a> (LCP) is a timing-based metric that captures this—the time at which the largest above-the-fold element was rendered.
 
 A good LCP score is 2.5s at p75. We found that the median LCP at p75 is 2.6s on mobile and 2.3s on desktop. Mobile web is especially susceptible to missing the mark on LCP.
 
@@ -211,9 +211,9 @@ This is especially important for mobile web, as shifting content is more noticea
 
 ##### Cumulative Layout Shift
 
-<a hreflang="en" href="https://web.dev/cls/">Cumulative Layout Shift</a> (CLS) is a metric that quantifies how much content within the viewport shifts around, during the user visit.
+<a hreflang="en" href="https://web.dev/articles/cls">Cumulative Layout Shift</a> (CLS) is a metric that quantifies how much content within the viewport shifts around, during the user visit.
 
-The <a hreflang="en" href="https://web.dev/optimize-cls/">most common causes of a poor CLS</a> are:
+The <a hreflang="en" href="https://web.dev/articles/optimize-cls">most common causes of a poor CLS</a> are:
 
 * Images without dimensions.
 * Ads, embeds, and iframes without dimensions.

src/content/en/2020/performance.md

@@ -67,7 +67,7 @@ These overall changes are not unexpected considering a multitude of amendments t
 
 ## Core Web Vitals: Largest Contentful Paint
 
-Largest Contentful Paint (LCP) is a landmark timing-based metric that reports the time at which the largest <a hreflang="en" href="https://web.dev/lcp/#what-elements-are-considered">above-the-fold element</a> was rendered.
+Largest Contentful Paint (LCP) is a landmark timing-based metric that reports the time at which the largest <a hreflang="en" href="https://web.dev/articles/lcp#what-elements-are-considered">above-the-fold element</a> was rendered.
 
 ### LCP by device
 
@@ -115,7 +115,7 @@ India remains the last one in our set of data, with only 16% of good experiences
 
 Since LCP is a timing showcasing when the largest above-the-fold element has been rendered (including imagery, videos or block-level elements containing text), it is not surprising that the slower the network, the more significant portion of measurements are poor.
 
-There's a clear correlation of network speed and better LCP performance, but even on 4G, only 48% of results are categorized as good, leaving half of the readings in need of an improvement. Automating media optimization, serving the right dimensions and formats, as well as optimizing for Low Data Mode, could help move the needle. Learn more about <a hreflang="en" href="https://web.dev/optimize-lcp/">optimizing LCP in this guide</a>.
+There's a clear correlation of network speed and better LCP performance, but even on 4G, only 48% of results are categorized as good, leaving half of the readings in need of an improvement. Automating media optimization, serving the right dimensions and formats, as well as optimizing for Low Data Mode, could help move the needle. Learn more about <a hreflang="en" href="https://web.dev/articles/optimize-lcp">optimizing LCP in this guide</a>.
 
 ## Core Web Vitals: Cumulative Layout Shift
 
@@ -153,7 +153,7 @@ According to CrUX data, both in cases of desktop and mobile devices, more than h
 
 The CLS performance in different geographical regions is primarily good, with at least 56% of sites with a good rating. This is excellent news for perceived visual stability. We can observe similar countries leading as we've seen in the LCP geo-distribution—Republic of Korea, Japan, Czechia, Germany, Poland.
 
-Visual stability is less affected by geography and latency to other metrics, like LCP. The difference in the percentage of good scores between the top and the bottom country is 61% for LCP and only 13% for CLS. The percentage of moderate-rating websites is relatively low across the board, giving way to 19%-29% of poor experiences across the board. There are numerous factors that can contribute to poor CLS—learn how to address them in the <a hreflang="en" href="https://web.dev/optimize-cls/">Optimize Cumulative Layout Shift guide</a>.
+Visual stability is less affected by geography and latency to other metrics, like LCP. The difference in the percentage of good scores between the top and the bottom country is 61% for LCP and only 13% for CLS. The percentage of moderate-rating websites is relatively low across the board, giving way to 19%-29% of poor experiences across the board. There are numerous factors that can contribute to poor CLS—learn how to address them in the <a hreflang="en" href="https://web.dev/articles/optimize-cls">Optimize Cumulative Layout Shift guide</a>.
 
 ### CLS by connection type
 

src/content/en/2020/resource-hints.md

@@ -72,7 +72,7 @@ The <a hreflang="en" href="https://web.dev/uses-rel-preload/">`preload`</a> hint
 <link rel="preload" href="main.js" as="script">
 ```
 
-Be mindful of what you are going to `preload`, because it can delay the download of other resources, so use it only for what is most critical to help you improve the Largest Contentful Paint (<a hreflang="en" href="https://web.dev/lcp/">LCP</a>). Also, when used on Chrome, it tends to over-prioritize `preload` resources and potentially dispatches preloads before other critical resources.
+Be mindful of what you are going to `preload`, because it can delay the download of other resources, so use it only for what is most critical to help you improve the Largest Contentful Paint (<a hreflang="en" href="https://web.dev/articles/lcp">LCP</a>). Also, when used on Chrome, it tends to over-prioritize `preload` resources and potentially dispatches preloads before other critical resources.
 
 Lastly, if used in a HTTP response header, some CDN's will also automatically turn a `preload` into a [HTTP/2 push](#http2-push) which can over-push cached resources.
 
@@ -174,7 +174,7 @@ With `preload` many different content-types can be preloaded and the [full list]
   sql_file="as_attribute_by_year.sql"
 ) }}
 
-Compared to the trend in [2019](../2019/resource-hints#the-as-attribute), we've seen rapid growth in font and style usage with the `as` attribute. This is likely related to developers increasing the priority of critical CSS and also combining `preload` fonts with `display:optional` to <a hreflang="en" href="https://web.dev/optimize-cls/#web-fonts-causing-foutfoit">improve</a> Cumulative Layout Shift (<a hreflang="en" href="https://web.dev/cls/">CLS</a>).
+Compared to the trend in [2019](../2019/resource-hints#the-as-attribute), we've seen rapid growth in font and style usage with the `as` attribute. This is likely related to developers increasing the priority of critical CSS and also combining `preload` fonts with `display:optional` to <a hreflang="en" href="https://web.dev/articles/optimize-cls#web-fonts-causing-foutfoit">improve</a> Cumulative Layout Shift (<a hreflang="en" href="https://web.dev/articles/cls">CLS</a>).
 
 Be mindful that omitting the `as` attribute, or having an invalid value will make it harder for the browser to determine the correct priority and in some cases, such as scripts, can even cause the resource to be fetched twice.
 

src/content/en/2020/seo.md

@@ -764,17 +764,17 @@ Having a fast-loading website is fundamental to provide a great user search expe
 
 As announced in November 2020, three performance metrics known as <a hreflang="en" href="https://webmasters.googleblog.com/2020/05/evaluating-page-experience.html">Core Web Vitals</a> are on track to be a ranking factor as part of the "page experience" signals in May 2021. Core Web Vitals consist of:
 
-**<a hreflang="en" href="https://web.dev/lcp/">Largest Contentful Paint</a> (LCP)**
+**<a hreflang="en" href="https://web.dev/articles/lcp">Largest Contentful Paint</a> (LCP)**
 - Represents: user-perceived loading experience
 - Measurement: the point in the page load timeline when the page's largest image or text block is visible within the viewport
 - Goal: <2.5 seconds
 
-**<a hreflang="en" href="https://web.dev/fid/">First Input Delay</a> (FID)**
+**<a hreflang="en" href="https://web.dev/articles/fid">First Input Delay</a> (FID)**
 - Represents: responsiveness to user input
 - Measurement: the time from when a user first interacts with a page to the time when the browser is actually able to begin processing event handlers in response to that interaction
 - Goal: <300 milliseconds
 
-**<a hreflang="en" href="https://web.dev/cls/">Cumulative Layout Shift</a> (CLS)**
+**<a hreflang="en" href="https://web.dev/articles/cls">Cumulative Layout Shift</a> (CLS)**
 - Represents: visual stability
 - Measurement: the sum of the number of _layout shift scores_ approximating the percent of the viewport that shifted
 - Goal: <0.10

src/content/en/2021/cms.md

@@ -181,7 +181,7 @@ An important aspect of CMSs is the user experience they provide, for users visit
 
 ### Core Web Vitals
 
-2021 was a great year for web performance, with a growing focus on <a hreflang="en" href="https://web.dev/vitals/#core-web-vitals">Core Web Vitals</a>, which helped nudge many platforms in the right direction to focus on improving their user experience and loading times. More importantly, it provides users with the right tools and guidance to monitor and improve their website performance. As a result, we saw large performance improvements from many platforms, which continue to evolve, gradually making user experience better across the web, which is a big win for all of us.
+2021 was a great year for web performance, with a growing focus on <a hreflang="en" href="https://web.dev/articles/vitals#core-web-vitals">Core Web Vitals</a>, which helped nudge many platforms in the right direction to focus on improving their user experience and loading times. More importantly, it provides users with the right tools and guidance to monitor and improve their website performance. As a result, we saw large performance improvements from many platforms, which continue to evolve, gradually making user experience better across the web, which is a big win for all of us.
 
 The <a hreflang="en" href="https://httparchive.org/reports/cwv-tech">Core Web Vitals Technology Report</a> can be used to drill into this data and view the progress of each technology updated on a monthly basis.
 
@@ -324,7 +324,7 @@ A score of 0.1 or below is measured as "good", over 0.25 as "poor", and anything
   sql_file="core_web_vitals.sql"
 ) }}
 
-Wix had the best CLS score, with 81% of mobile origins having a "good" CLS. Adobe Experience Manager had the lowest CLS scores, with only 44% of mobile origins having a good CLS. Because layout shifts can usually be avoided, regardless of connection speeds–all platforms should strive to improve these numbers by <a hreflang="en" href="https://web.dev/optimize-cls/">reducing layout shifts</a> to the bare minimum.
+Wix had the best CLS score, with 81% of mobile origins having a "good" CLS. Adobe Experience Manager had the lowest CLS scores, with only 44% of mobile origins having a good CLS. Because layout shifts can usually be avoided, regardless of connection speeds–all platforms should strive to improve these numbers by <a hreflang="en" href="https://web.dev/articles/optimize-cls">reducing layout shifts</a> to the bare minimum.
 
 {{ figure_markup(
   image="core-web-vitals-cls-yoy.png",
@@ -613,6 +613,6 @@ CMSs are doing great work and have a huge opportunity to further improve user ex
 
 On the other hand, Core Web Vitals still have some progress and evolving to do.
 
-We mentioned the thoughts towards a <a hreflang="en" href="https://web.dev/responsiveness/">better responsiveness metric</a> above. In addition, navigations between pages in a site should be better tracked and take into account the difference between <a hreflang="en" href="https://web.dev/vitals-spa-faq">Single-Page Applications (SPAs) and Multi-Page Applications (MPAs)</a> architectures.
+We mentioned the thoughts towards a <a hreflang="en" href="https://web.dev/responsiveness/">better responsiveness metric</a> above. In addition, navigations between pages in a site should be better tracked and take into account the difference between <a hreflang="en" href="https://web.dev/articles/vitals-spa-faq">Single-Page Applications (SPAs) and Multi-Page Applications (MPAs)</a> architectures.
 
 Let's continue pushing forward.