Add INP glossary entry and replace FID references (#36851)

* Add reference to INP and replace FID references * Add notice about INP becoming a CWV link * Fix typo * Links * Glossary links * Fix links * Apply suggestions from code review Co-authored-by: Brian Thomas Smith <[email protected]> Co-authored-by: Chris Mills <[email protected]> * Set other metrics as acronyms * Update files/en-us/glossary/interaction_to_next_paint/index.md * Update files/en-us/glossary/interaction_to_next_paint/index.md Co-authored-by: Brian Thomas Smith <[email protected]> * More review feedback * Update Performance Glossary --------- Co-authored-by: Brian Thomas Smith <[email protected]> Co-authored-by: Chris Mills <[email protected]>
mdn · Nov 20, 2024 · 0598721 · 0598721
1 parent 400c104
commit 0598721
Show file tree

Hide file tree

Showing 20 changed files with 74 additions and 103 deletions.
diff --git a/files/en-us/glossary/cls/index.md b/files/en-us/glossary/cls/index.md
@@ -6,7 +6,7 @@ page-type: glossary-definition
 
 {{GlossarySidebar}}
 
-**Cumulative Layout Shift (CLS)** is a usability metric for websites, designed by Google as one of the [Core Web Vital](https://web.dev/explore/learn-core-web-vitals) metrics.
+**Cumulative Layout Shift (CLS)** is a usability metric for websites, designed by Google as one of the [Core Web Vital](https://web.dev/articles/vitals) metrics.
 
 It measures the extent to which users encounter unexpected layout shifts, in which elements of the page are moved in an unexpected way: that is, that are not the result of a user action like pressing a button or part of an animation.
 

diff --git a/files/en-us/glossary/first_contentful_paint/index.md b/files/en-us/glossary/first_contentful_paint/index.md
@@ -1,5 +1,5 @@
 ---
-title: First contentful paint
+title: First Contentful Paint (FCP)
 slug: Glossary/First_contentful_paint
 page-type: glossary-definition
 ---
@@ -14,7 +14,7 @@ _The First Contentful Paint_ timestamp is when the browser first rendered any te
 
 - [`PerformancePaintTiming`](/en-US/docs/Web/API/PerformancePaintTiming)
 - Related glossary terms:
-  - {{Glossary("First paint")}}
-  - {{Glossary("Largest contentful paint")}}
-  - {{Glossary("First meaningful paint")}}
+  - {{Glossary("First Paint")}}
+  - {{Glossary("Largest Contentful Paint")}}
+  - {{Glossary("First Meaningful Paint")}}
 - [First Contentful Paint](https://web.dev/articles/fcp) at web.dev
diff --git a/files/en-us/glossary/first_input_delay/index.md b/files/en-us/glossary/first_input_delay/index.md
@@ -1,18 +1,22 @@
 ---
-title: First input delay
+title: First Input Delay (FID)
 slug: Glossary/First_input_delay
 page-type: glossary-definition
+status:
+  - deprecated
 ---
 
 {{GlossarySidebar}}
 
-**First input delay** (FID) measures the time from when a user first interacts with your site (i.e. when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to respond to that interaction.
+**First input delay** (FID) measures the time from when a user first interacts with your site (for example, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to respond to that interaction.
+
+> [!WARNING]
+> FID was designed by Google as one of the [Core Web Vital](https://web.dev/articles/vitals) metrics but was replaced by {{Glossary("Interaction to Next Paint")}} (INP) [in May 2024](https://web.dev/blog/inp-cwv-launch).
 
 It is the length of time, in milliseconds, between the first user interaction on a web page and the browser's response to that interaction. Scrolling and zooming are not included in this metric.
 
 The time between when content is painted to the page and when all the functionality becomes responsive to human interaction often varies based on the size and complexity of the JavaScript needing to be downloaded, parsed, and executed on the main thread, and on the device speed or lack thereof (think low end mobile devices). The longer the delay, the worse the user experience. Reducing site initialization time and eliminating [long tasks](/en-US/docs/Web/API/PerformanceLongTaskTiming) can help eliminate first input delays.
 
 ## See also
 
-- [requestIdleCallback](/en-US/docs/Web/API/Window/requestIdleCallback)
-- [lazy loading](/en-US/docs/Web/Performance/Lazy_loading)
+- [Interaction to Next Paint is officially a Core Web Vital](https://web.dev/blog/inp-cwv-launch) on web.dev (2024)
diff --git a/files/en-us/glossary/first_meaningful_paint/index.md b/files/en-us/glossary/first_meaningful_paint/index.md
@@ -1,5 +1,5 @@
 ---
-title: First Meaningful Paint
+title: First Meaningful Paint (FMP)
 slug: Glossary/First_meaningful_paint
 page-type: glossary-definition
 ---
@@ -16,5 +16,5 @@ FMP is very sensitive to small differences in the page load. This can lead to in
 ## See also
 
 - Related glossary terms:
-  - {{Glossary("First contentful paint")}}
-  - {{Glossary("Largest contentful paint")}}
+  - {{Glossary("First Contentful Paint")}}
+  - {{Glossary("Largest Contentful Paint")}}
diff --git a/files/en-us/glossary/first_paint/index.md b/files/en-us/glossary/first_paint/index.md
@@ -1,5 +1,5 @@
 ---
-title: First paint
+title: First Paint (FP)
 slug: Glossary/First_paint
 page-type: glossary-definition
 ---
@@ -12,6 +12,6 @@ page-type: glossary-definition
 
 - [`PerformancePaintTiming`](/en-US/docs/Web/API/PerformancePaintTiming)
 - Related glossary terms:
-  - {{Glossary("First contentful paint")}}
-  - {{Glossary("Largest contentful paint")}}
-  - {{Glossary("First meaningful paint")}}
+  - {{Glossary("First Contentful Paint")}}
+  - {{Glossary("Largest Contentful Paint")}}
+  - {{Glossary("First Meaningful Paint")}}
diff --git a/files/en-us/glossary/interaction_to_next_paint/index.md b/files/en-us/glossary/interaction_to_next_paint/index.md
@@ -0,0 +1,28 @@
+---
+title: Interaction to Next Paint (INP)
+slug: Glossary/Interaction_to_next_paint
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+**Interaction to Next Paint** (INP) measures the responsiveness of a website to user interactions (for example, when they click a link, tap on a button, or use a custom, JavaScript-powered control).
+
+INP was designed by Google as one of the [Core Web Vital](https://web.dev/articles/vitals) metrics, replacing {{Glossary("First Input Delay")}} (FID) in May 2024. There are two key differences between FID and INP that make INP a more reliable measure of a page's responsiveness:
+
+- FID measures only the first user interaction, whereas INP considers all user interactions.
+- FID only measures the input delay of the interaction, whereas INP measures for a longer period: beginning at the input delay, followed by the time it takes to process event handlers, and the browser's presentation time until the browser has painted the next frame.
+
+INP measures the worst length of time (minus some outliers), in milliseconds, between the user interaction on a web page and the next frame presentation after that interaction is processed. Scrolling and zooming are not included in this metric. INP is calculated using the [Event Timing API](/en-US/docs/Web/API/PerformanceEventTiming). Asynchronous operations such as network fetches or file reads usually do not delay INP as painting can occur while such operations are handled.
+
+All eligible interactions throughout the page lifetime are considered. For highly interactive pages of 50 or more interactions, the 98th percentile is used to exclude some extreme outliers that are not reflective of overall page responsiveness.
+
+The longer the delay, the worse the user experience. The [Long Animation Frames API](/en-US/docs/Web/API/Performance_API/Long_animation_frame_timing) can help identify causes of high INP.
+
+## See also
+
+- [Long animation frame timing](/en-US/docs/Web/API/Performance_API/Long_animation_frame_timing)
+- [PerformanceEventTiming](/en-US/docs/Web/API/PerformanceEventTiming)
+- [INP](https://web.dev/articles/inp) on web.dev (2023)
+- [Optimizing INP](https://web.dev/articles/optimizing-inp) on web.dev (2023)
+- [Interaction to Next Paint is officially a Core Web Vital](https://web.dev/blog/inp-cwv-launch) on web.dev (2024)
diff --git a/files/en-us/glossary/largest_contentful_paint/index.md b/files/en-us/glossary/largest_contentful_paint/index.md
@@ -1,5 +1,5 @@
 ---
-title: Largest contentful paint
+title: Largest Contentful Paint (LCP)
 slug: Glossary/Largest_contentful_paint
 page-type: glossary-definition
 ---
@@ -20,5 +20,5 @@ The following elements are considered when determining the LCP:
 
 - [`LargestContentfulPaint`](/en-US/docs/Web/API/LargestContentfulPaint)
 - Related glossary terms:
-  - {{Glossary("First contentful paint")}}
-  - {{Glossary("First paint")}}
+  - {{Glossary("First Contentful Paint")}}
+  - {{Glossary("First Paint")}}
diff --git a/files/en-us/learn/performance/perceived_performance/index.md b/files/en-us/learn/performance/perceived_performance/index.md
@@ -46,7 +46,7 @@ Similarly, it is better to display a "loading animation" as soon as a user click
 
 There is no single metric or test that can be run on a site to evaluate how a user "feels". However, there are a number of metrics that can be "helpful indicators":
 
-- [First paint](/en-US/docs/Glossary/First_paint)
+- [First Paint](/en-US/docs/Glossary/First_paint)
   - : The time to start of first paint operation. Note that this change may not be visible; it can be a simple background color update or something even less noticeable.
 - [First Contentful Paint](/en-US/docs/Glossary/First_contentful_paint) (FCP)
   - : The time until first significant rendering (e.g. of text, foreground or background image, canvas or SVG, etc.). Note that this content is not necessarily useful or meaningful.

diff --git a/files/en-us/web/api/htmlimageelement/fetchpriority/index.md b/files/en-us/web/api/htmlimageelement/fetchpriority/index.md
@@ -16,7 +16,7 @@ This in turn allows the browser to increase or decrease the priority, and potent
 The property should be used sparingly, as excessive or incorrect prioritization can degrade performance.
 
 The fetch priority can be used to complement [preloading](/en-US/docs/Web/HTML/Attributes/rel/preload), allowing a developer to boost the priority ahead of less-impactful resources that have a higher default priority.
-For example, if a developer knows that a particular image significantly contributes to the website's {{glossary("Largest contentful paint")}} (LCP) they could add [`<link rel="preload">`](/en-US/docs/Web/HTML/Attributes/rel/preload) for the image and then further boost the priority using the `fetchpriority` property.
+For example, if a developer knows that a particular image significantly contributes to the website's {{glossary("Largest Contentful Paint")}} (LCP) they could add [`<link rel="preload">`](/en-US/docs/Web/HTML/Attributes/rel/preload) for the image and then further boost the priority using the `fetchpriority` property.
 
 Note that both the internal priority of any fetch operation, and the impact of `fetchPriority` on the priority, are entirely browser dependent.
 

diff --git a/files/en-us/web/api/htmllinkelement/fetchpriority/index.md b/files/en-us/web/api/htmllinkelement/fetchpriority/index.md
@@ -16,7 +16,7 @@ This in turn allows the browser to increase or decrease the priority, and potent
 The property should be used sparingly, as excessive or incorrect prioritization can degrade performance.
 
 The fetch priority can be used to complement [preloading](/en-US/docs/Web/HTML/Attributes/rel/preload), allowing a developer to boost the priority of a resource ahead of less-impactful resources that are by default preloaded with a higher priority.
-For example, if a particular image significantly contributes to the website's {{glossary("Largest contentful paint")}} (LCP) it might be set to be preloaded and with a high fetch priority.
+For example, if a particular image significantly contributes to the website's {{glossary("Largest Contentful Paint")}} (LCP) it might be set to be preloaded and with a high fetch priority.
 
 Note that both the internal priority of any fetch operation, and the impact of `fetchPriority` on the priority, are entirely browser dependent.
 

diff --git a/files/en-us/web/api/largestcontentfulpaint/index.md b/files/en-us/web/api/largestcontentfulpaint/index.md
@@ -23,8 +23,8 @@ To measure render times of other elements, use the {{domxref("PerformanceElement
 
 Additional key paint moments are provided by the {{domxref("PerformancePaintTiming")}} API:
 
-- {{Glossary("First paint")}} (FP): Time when anything is rendered. Note that the marking of the first paint is optional, not all user agents report it.
-- {{Glossary("First contentful paint")}} (FCP): Time when the first bit of DOM text or image content is rendered.
+- {{Glossary("First Paint")}} (FP): Time when anything is rendered. Note that the marking of the first paint is optional, not all user agents report it.
+- {{Glossary("First Contentful Paint")}} (FCP): Time when the first bit of DOM text or image content is rendered.
 
 `LargestContentfulPaint` inherits from {{domxref("PerformanceEntry")}}.
 
@@ -112,5 +112,5 @@ const isAccurateLCP = entry.renderTime ? true : false;
 ## See also
 
 - {{Glossary("Largest Contentful Paint")}}
-- {{Glossary("First contentful paint")}}
-- {{Glossary("First paint")}}
+- {{Glossary("First Contentful Paint")}}
+- {{Glossary("First Paint")}}
diff --git a/files/en-us/web/api/page_visibility_api/index.md b/files/en-us/web/api/page_visibility_api/index.md
@@ -132,5 +132,4 @@ document.addEventListener("visibilitychange", () => {
 
 - {{domxref("Document.visibilityState")}}
 - {{domxref("Document.hidden")}}
-- [PerformanceEventTiming: Reporting the First Input Delay (FID)](/en-US/docs/Web/API/PerformanceEventTiming#reporting_the_first_input_delay_fid)
 - [Timing element visibility with the Intersection Observer API](/en-US/docs/Web/API/Intersection_Observer_API/Timing_element_visibility)
diff --git a/files/en-us/web/api/performance_api/index.md b/files/en-us/web/api/performance_api/index.md
@@ -64,7 +64,7 @@ The following interfaces are present in the Performance API:
 - {{domxref("PerformanceEntry")}}
   - : An entry on the performance timeline encapsulating a single performance metric. All performance metrics inherit from this interface.
 - {{domxref("PerformanceEventTiming")}}
-  - : Measures latency of events and first input delay (FID).
+  - : Measures latency of events and {{Glossary("Interaction to Next Paint")}} (INP).
 - {{domxref("PerformanceLongAnimationFrameTiming")}}
   - : Provides metrics on [long animation frames (LoAFs)](/en-US/docs/Web/API/Performance_API/Long_animation_frame_timing#what_is_a_long_animation_frame) that occupy rendering and block other tasks from being executed.
 - {{domxref("PerformanceLongTaskTiming")}}

diff --git a/files/en-us/web/api/performance_api/performance_data/index.md b/files/en-us/web/api/performance_api/performance_data/index.md
@@ -16,7 +16,7 @@ Most of the metrics exposed by the Performance API are automatically collected b
 
 For some metrics you do have to tell the browser what to measure:
 
-- the [Element Timing](/en-US/docs/Web/API/Performance_API/Element_timing) metric measures the time it takes to load and render certain DOM elements. This metric is opt-in: to ask the browser to include metrics for a particular element you must add the `elementtiming` attribute to it.
+- the [Element Timing](/en-US/docs/Web/API/PerformanceElementTiming) metric measures the time it takes to load and render certain DOM elements. This metric is opt-in: to ask the browser to include metrics for a particular element you must add the `elementtiming` attribute to it.
 - the [User Timing](/en-US/docs/Web/API/Performance_API/User_timing) metric enables you to measure the time between arbitrary points in your program, that might map to application-defined operations (such as logging in a user). To collect these metrics you need to add Performance API calls at the relevant points.
 - the [Server Timing](/en-US/docs/Web/API/Performance_API/Server_timing) metric enables you to measure the time taken for application-defined server-side operations. To collect these metrics your server must send the `Server-Timing` HTTP header.
 
@@ -33,8 +33,8 @@ A single recorded performance data point is called a _performance entry_ and is
 The Performance API records various different types of performance data, and the `PerformanceEntry` has an {{domxref("PerformanceEntry.entryType", "entryType")}} property which is a string describing the type of this performance entry:
 
 - `"element"` records how long it takes an element to load and render.
-- `"event"` records how long it took the browser to start running an event handler in response to its trigger, and how long the event handler took to run.
-- `"first-input"` records the {{Glossary("First input delay")}}.
+- `"event"` records how long it took the browser to start running an event handler in response to its trigger, and how long the event handler took to run. Used to measure {{Glossary("Interaction to Next Paint")}}.
+- `"first-input"` records the {{Glossary("First Input Delay")}}.
 - `"largest-contentful-paint"` records the largest paint during page load.
 - `"layout-shift"` records a metric representing how much the page layout has shifted in each animation frame.
 - `"longtask"` records tasks that took 50ms or more.

diff --git a/files/en-us/web/api/performanceentry/entrytype/index.md b/files/en-us/web/api/performanceentry/entrytype/index.md
@@ -30,7 +30,7 @@ A string. The return value depends on the subtype of the `PerformanceEntry` obje
 
 - `first-input`
 
-  - : Reports the {{Glossary("first input delay")}} (FID).
+  - : Reports the {{Glossary("First Input Delay")}} (FID).
 
     The entry instance will be a {{domxref("PerformanceEventTiming")}} object.
 

diff --git a/files/en-us/web/api/performanceentry/index.md b/files/en-us/web/api/performanceentry/index.md
@@ -9,7 +9,7 @@ browser-compat: api.PerformanceEntry
 
 The **`PerformanceEntry`** object encapsulates a single performance metric that is part of the browser's performance timeline.
 
-The Performance API offers built-in metrics which are specialized subclasses of `PerformanceEntry`. This includes entries for resource loading, event timing, {{Glossary("first input delay")}} (FID), and more.
+The Performance API offers built-in metrics which are specialized subclasses of `PerformanceEntry`. This includes entries for resource loading, event timing, and more.
 
 A performance entry can also be created by calling the {{domxref("Performance.mark()")}} or {{domxref("Performance.measure()")}} methods at an explicit point in an application. This allows you to add your own metrics to the performance timeline.
 

diff --git a/files/en-us/web/api/performanceeventtiming/index.md b/files/en-us/web/api/performanceeventtiming/index.md
@@ -13,7 +13,7 @@ The `PerformanceEventTiming` interface of the Event Timing API provides insights
 
 This API enables visibility into slow events by providing event timestamps and duration for certain event types ([see below](#events_exposed)). For example, you can monitor the time between a user action and the start of its event handler, or the time an event handler takes to run.
 
-This API is particularly useful for measuring the {{Glossary("first input delay")}} (FID): the time from the point when a user first interacts with your app to the point when the browser is actually able to respond to that interaction.
+This API is particularly useful for measuring the {{Glossary("Interaction to Next Paint")}} (INP): the longest time (minus some outliers) from the point when a user interacts with your app to the point until the browser was actually able to respond to that interaction.
 
 You typically work with `PerformanceEventTiming` objects by creating a {{domxref("PerformanceObserver")}} instance and then calling its [`observe()`](/en-US/docs/Web/API/PerformanceObserver/observe) method, passing in `"event"` or `"first-input"` as the value of the [`type`](/en-US/docs/Web/API/PerformanceEntry/entryType) option. The `PerformanceObserver` object's callback will then be called with a list of `PerformanceEventTiming` objects which you can analyze. See the [example below](#getting_event_timing_information) for more.
 
@@ -187,67 +187,6 @@ You can also set a different [`durationThreshold`](/en-US/docs/Web/API/Performan
 observer.observe({ type: "event", durationThreshold: 16, buffered: true });
 ```
 
-### Reporting the First Input Delay (FID)
-
-The {{Glossary("first input delay")}} or FID, measures the time from when a user first interacts with a page (i.e. when they click a link or tap on a button) to the time when the browser is actually able to begin processing event handlers in response to that interaction.
-
-```js
-// Keep track of whether (and when) the page was first hidden, see:
-// https://github.com/w3c/page-visibility/issues/29
-// NOTE: ideally this check would be performed in the document <head>
-// to avoid cases where the visibility state changes before this code runs.
-let firstHiddenTime = document.visibilityState === "hidden" ? 0 : Infinity;
-document.addEventListener(
-  "visibilitychange",
-  (event) => {
-    firstHiddenTime = Math.min(firstHiddenTime, event.timeStamp);
-  },
-  { once: true },
-);
-
-// Sends the passed data to an analytics endpoint. This code
-// uses `/analytics`; you can replace it with your own URL.
-function sendToAnalytics(data) {
-  const body = JSON.stringify(data);
-  // Use `navigator.sendBeacon()` if available,
-  // falling back to `fetch()`.
-  (navigator.sendBeacon && navigator.sendBeacon("/analytics", body)) ||
-    fetch("/analytics", { body, method: "POST", keepalive: true });
-}
-
-// Use a try/catch instead of feature detecting `first-input`
-// support, since some browsers throw when using the new `type` option.
-// https://webkit.org/b/209216
-try {
-  function onFirstInputEntry(entry) {
-    // Only report FID if the page wasn't hidden prior to
-    // the entry being dispatched. This typically happens when a
-    // page is loaded in a background tab.
-    if (entry.startTime < firstHiddenTime) {
-      const fid = entry.processingStart - entry.startTime;
-
-      // Report the FID value to an analytics endpoint.
-      sendToAnalytics({ fid });
-    }
-  }
-
-  // Create a PerformanceObserver that calls
-  // `onFirstInputEntry` for each entry.
-  const po = new PerformanceObserver((entryList) => {
-    entryList.getEntries().forEach(onFirstInputEntry);
-  });
-
-  // Observe entries of type `first-input`, including buffered entries,
-  // i.e. entries that occurred before calling `observe()` below.
-  po.observe({
-    type: "first-input",
-    buffered: true,
-  });
-} catch (e) {
-  // Do nothing if the browser doesn't support this API.
-}
-```
-
 ## Specifications
 
 {{Specifications}}