@olives/devos 2.1.0

package/.agents/skills/modern-web-guidance/guides/performance/detect-initial-visibility-state.md

@@ -0,0 +1,99 @@
+Determining if a page was initially loaded in the background (e.g., opened in a new background tab) is critical for accurate performance monitoring. Pages loaded in the background often have delayed rendering and longer metric times (like First Contentful Paint). Identifying these pages allows you to filter them out of performance analytics to avoid skewed data.
+
+The most accurate way to measure this is by using the `VisibilityStateEntry` API, which reliably records visibility changes on the browser's performance timeline, regardless of when your script actually executes.
+
+### Detecting initial visibility and background time
+
+MANDATORY: Use `performance.getEntriesByType('visibility-state')` to access the exact visibility history. Do not rely solely on checking `document.visibilityState` at execution time, as it is susceptible to race conditions.
+
+```javascript
+/**
+ * Accurately determines visibility state history using the Performance API.
+ */
+function getVisibilityInfo() {
+  // Retrieve VisibilityStateEntry members:
+  const entries = performance.getEntriesByType('visibility-state');
+  
+  if (entries.length > 0) {
+    const firstEntry = entries[0];
+    
+    // If the first performance entry for visibility is 'hidden',
+    // the page was loaded in the background.
+    const initiallyBackgrounded = firstEntry.name === 'hidden';
+    
+    // Find the precise, high-resolution timestamp of when the page 
+    // was first backgrounded.
+    let timeBackgrounded = null;
+    for (const entry of entries) {
+      if (entry.name === 'hidden') {
+        // entry.startTime is used because it provides the exact browser 
+        // timestamp of the visibility change, which is required for precision
+        timeBackgrounded = entry.startTime;
+        break;
+      }
+    }
+
+    return {
+      initiallyBackgrounded,
+      timeBackgrounded
+    };
+  }
+}
+```
+
+### Fallback strategies
+
+Page visibility state has limited availability.
+Supported by: Chrome 115 (Jul 2023) and Edge 115 (Jul 2023).
+Unsupported in: Firefox and Safari.
+
+For unsupported environments, you may fall back to checking the `document.visibilityState` property or listening for the `visibilitychange` event.
+
+**MANDATORY:** You must understand that this fallback approach is often **highly inaccurate for determining initial background state**. Because scripts can load and execute asynchronously, a page could be opened in a background tab and then foregrounded by the user *before* your script has finished downloading and executing. When your script finally runs, `document.visibilityState` will synchronously read as `'visible'`, and you will incorrectly assume the page was loaded in the foreground, completely missing its initial hidden state. Furthermore, the fallback timestamp lacks the internal precision of the Performance API. If precision is a high priority, do not use the fallback.
+
+```javascript
+/**
+ * Fallback implementation using document.visibilityState.
+ * This approach is prone to race conditions if the script loads asynchronously.
+ */
+function getFallbackVisibilityInfo() {
+  // Check the state exactly when this script executes.
+  // This will fail to detect an initial background state if the user 
+  // foregrounded the page before this script executed.
+  let initiallyBackgrounded = document.visibilityState === 'hidden';
+  
+  // If it's hidden now, we approximate that it was hidden from load (time 0).
+  let timeBackgrounded = initiallyBackgrounded ? 0 : null;
+
+  // Listen for future visibility changes to capture if it is backgrounded later.
+  document.addEventListener('visibilitychange', () => {
+    if (document.visibilityState === 'hidden' && timeBackgrounded === null) {
+      // performance.now() is used here as a fallback, but it only gives 
+      // us the time the event listener fired, not the precise internal 
+      // browser time the visibility actually changed.
+      timeBackgrounded = performance.now();
+    }
+  });
+
+  return {
+    get initiallyBackgrounded() { return initiallyBackgrounded; },
+    get timeBackgrounded() { return timeBackgrounded; }
+  };
+}
+
+// Modern implementation using VisibilityStateEntry API.
+function getVisibilityInfo() {
+  // Code omitted here would be the same modern
+  // implementation shown earlier in this guide
+  // ...
+}
+
+// DO: Detect if the VisibilityStateEntry API is available
+if ('VisibilityStateEntry' in window) {
+  // DO: If VisibilityStateEntry is available, use it first:
+  getVisibilityInfo();
+} else {
+  // DO: If VisibilityStateEntry is unavailable, fall back to `document.visibilityState`:
+  getFallbackVisibilityInfo();
+}
+```

package/.agents/skills/modern-web-guidance/guides/performance/efficient-background-processing.md

@@ -0,0 +1,117 @@
+# Efficient Background Processing
+
+Pause heavy background tasks when a component is not being rendered by the browser to conserve system resources and battery life.
+
+## Overview
+
+The `content-visibility: auto` property allows the browser to skip rendering calculations for elements that are far outside the viewport. When the browser decides to skip or resume rendering for an element, it fires the `contentvisibilityautostatechange` event on that element.
+
+By listening to this event, you can pause expensive operations like `<canvas>` animations, WebGL rendering, or high-frequency WebSocket data polling when they are not needed, and resume them just-in-time when the browser prepares to display the content.
+
+### `contentvisibilityautostatechange` vs. `IntersectionObserver`
+
+It is important to understand when to use which API:
+
+*   **Use `IntersectionObserver` for application logic** tied to the exact visual visibility of an element in the viewport (e.g., lazy-loading data, infinite scroll triggers).
+*   **Use `contentvisibilityautostatechange` for rendering-heavy work** (like complex canvas updates or heavy DOM mutations). This event ties directly to the browser's internal rendering lifecycle. The browser often starts rendering an element before it actually appears on screen (the pre-render margin). This event tells you when that happens, ensuring your content is ready to be seen.
+
+## Implementation
+
+### 1. Apply CSS Content Visibility
+
+Set `content-visibility: auto` on the heavy container and provide a placeholder size to prevent scrollbar jumping.
+
+```css
+.heavy-component {
+  /* Defer rendering work when off-screen */
+  content-visibility: auto;
+  
+  /* Mandatory: Provide a placeholder size to prevent layouts shifts.
+    - 'auto' is optional and enables the browser to remember the actual size
+      once rendered. It must be paired with a <length> value to be used for
+      the first render.
+    - 'none' tells the browser not to apply any intrinsic width to this element.
+      It can be used for either the height or the width value.
+    - '500px' is the estimated height of this element. This can be any valid
+      CSS <length> value. Replace it with the expected height of your
+      component.
+   */
+  contain-intrinsic-size: auto none auto 500px;
+}
+```
+
+### 2. Listen for State Changes
+
+Add an event listener for `contentvisibilityautostatechange` to pause or resume background tasks.
+
+> **Important:** The `contentvisibilityautostatechange` event does not bubble in some browser implementations. To handle this event reliably, you must either:
+> - Attach the event listener directly to the element that has `content-visibility: auto` applied.
+> - Use a capturing event listener (`{ capture: true }`) if you are delegating events to a parent container.
+
+```javascript
+const component = document.querySelector('.heavy-component');
+
+// Option 1: Direct listener (recommended)
+component.addEventListener('contentvisibilityautostatechange', (event) => {
+  if (event.skipped) {
+    // The browser skipped rendering this content.
+    // DO NOT perform heavy mutations or animation loops here.
+    stopSimulation();
+    pauseWebSocketPolling();
+  } else {
+    // The browser is about to render the content.
+    // Resume your work so it is ready when visible.
+    startSimulation();
+    resumeWebSocketPolling();
+  }
+});
+
+// Option 2: Capturing listener for event delegation
+document.addEventListener('contentvisibilityautostatechange', (event) => {
+  if (event.target.matches('.heavy-component')) {
+    if (event.skipped) {
+      stopSimulation();
+    } else {
+      startSimulation();
+    }
+  }
+}, { capture: true });
+```
+
+### Fallback strategies
+
+Baseline status for content-visibility: Newly available. It's been Baseline since 2025-09-15.
+Supported by: Chrome 108 (Nov 2022), Edge 108 (Dec 2022), Firefox 130 (Sep 2024), and Safari 26 (Sep 2025).
+
+The `content-visibility` property and the associated `contentvisibilityautostatechange` event are progressive enhancements. In browsers that do not support them:
+*   The CSS property is ignored, and the content is rendered normally.
+*   The event never fires, so background tasks will continue to run as they normally would without optimization.
+
+If you must support pausing tasks on older browsers, you can fallback to using `IntersectionObserver` as a rough approximation. This helps save battery and CPU on older devices too.
+
+```javascript
+// Fallback using IntersectionObserver for older browsers
+const target = document.getElementById('target-container');
+
+// Check if content-visibility is supported
+const isSupported = 'contentVisibility' in document.documentElement.style;
+
+if (!isSupported) {
+  const observer = new IntersectionObserver((entries) => {
+    entries.forEach(entry => {
+      if (entry.isIntersecting) {
+        // The element is close to the screen. Start work!
+        startSimulation();
+      } else {
+        // The element is far away. Pause work!
+        stopSimulation();
+      }
+    });
+  }, {
+    // Use rootMargin to start rendering before it hits the screen
+    rootMargin: '200px'
+  });
+
+  observer.observe(target);
+}
+```

package/.agents/skills/modern-web-guidance/guides/performance/faster-spa-view-transitions.md

@@ -0,0 +1,79 @@
+# Faster SPA View Transitions via State Caching
+
+Enable instant navigation between views in a Single-Page Application (SPA) by caching the rendered state of inactive views instead of destroying them.
+
+## Overview
+
+Traditionally, when a user navigates between tabs or views in an SPA, developers either destroy the old view or hide it using `display: none`. Both approaches require the browser to recreate or recalculate the full layout and paint when the user returns to that view.
+
+By using `content-visibility: hidden` on inactive views, the browser removes the element’s contents from the layout flow and stops painting it, but *retains* its cached rendering state in memory. When the user switches back, the view restores nearly instantly.
+
+### The CPU vs. RAM Trade-off
+
+While this approach offers massive performance benefits, it introduces a specific trade-off that you must manage carefully:
+
+*   **CPU Savings:** Massive. The browser completely skips layout and paint passes for hidden views.
+*   **RAM Cost:** High. The browser keeps all DOM nodes, event listeners, and state for the hidden view in memory.
+
+#### When This Trade-off Becomes Dangerous
+
+*   **DO** use this strategy for simple applications with a small, predictable number of views (e.g., a 3-to-5 tabbed interface).
+*   **DO NOT** unconditionally cache every view in highly dynamic applications that generate dozens of unique reports or use infinite dynamic routes. Doing so will eventually cause severe memory bloat and may crash the browser on low-end devices.
+*   **MANDATORY:** If your application is highly dynamic, you MUST implement an **eviction strategy** (like a Least Recently Used cache) to destroy old views when a memory threshold is reached.
+
+## Implementation
+
+### 1. Configure View Containers
+
+Set `content-visibility: hidden` on views that are not currently active.
+
+> **Note:** The `content-visibility: hidden` property hides an element's *contents*, but the element itself remains styled and visible. Its background, borders, padding, and margins will still be painted by the browser.
+
+```css
+.spa-view.inactive {
+  /* MANDATORY: Use hidden to cache the rendering state of inactive views */
+  content-visibility: hidden;
+  
+  /* Optional: Prevent hidden views from taking up physical space in layout flow */
+  position: absolute;
+}
+```
+
+### 2. Manage Focus
+
+When swapping views, ensure you manage keyboard focus correctly to preserve accessibility.
+
+```javascript
+function switchToView(viewId) {
+  // Hide all views
+  document.querySelectorAll('.spa-view').forEach(view => {
+    view.classList.add('inactive');
+    view.setAttribute('aria-hidden', 'true');
+  });
+  
+  // Show the target view
+  const activeView = document.getElementById(viewId);
+  activeView.classList.remove('inactive');
+  activeView.setAttribute('aria-hidden', 'false');
+  
+  // MANDATORY: Move focus to the new view to ensure a logical tab-order
+  activeView.focus();
+}
+```
+
+### Fallback strategies
+
+Baseline status for content-visibility: Newly available. It's been Baseline since 2025-09-15.
+Supported by: Chrome 108 (Nov 2022), Edge 108 (Dec 2022), Firefox 130 (Sep 2024), and Safari 26 (Sep 2025).
+
+The `content-visibility` property degrades gracefully. In browsers that do not support it:
+*   The property is ignored.
+*   To prevent fallback browsers from rendering all views simultaneously, you should provide a fallback to `display: none` in your CSS:
+
+```css
+@supports not (content-visibility: hidden) {
+  .spa-view.inactive {
+    display: none;
+  }
+}
+```

package/.agents/skills/modern-web-guidance/guides/performance/full-session-analytics.md

@@ -0,0 +1,135 @@
+# Reliably measure full-session analytics and telemetry
+
+To reliably analytics and telemetry data that covers the entirety of a user's visit to a web page (not just until page load) use the `fetchLater()` API.
+
+The `fetchLater()` API is the most reliably way to send data to a server in cases where a response is not required and delivery timing is not urgent, which applies to data such as user analytics, telemetry, error tracking, and performance metrics like Core Web Vitals.
+
+Older technique like creating an `<img>` pixel in an `unload` event listener are notoriously unreliably (especially on mobile) and can negatively impact performance (by making pages ineligible for bfcache).
+
+## How to implement
+
+1. **Schedule the request:** As soon as relevant data is available, call `fetchLater()` with your data payload. This queues the data to be sent later.
+
+2. **Update the payload as needed:** If the user generates more data or the state changes, abort the previously scheduled request and call `fetchLater()` again with the fully updated snapshot.
+
+3. **Let the browser handle the rest:** When the user navigates away or closes the tab, the browser will reliably send the payload from your most recent `fetchLater()` call.
+
+## Example code
+
+This code measures the session duration of a user's visit to a page using `fetchLater()` to queue a new beacon every 10 seconds with the updated session duration.
+
+```javascript
+const ANALYTICS_ENDPOINT = '/path/to/analytics/endpoint';
+
+const sessionData = {
+  duration: 0,
+  id: crypto.randomUUID(),
+};
+
+let fetchLaterController = null;
+
+function queueBeacon() {
+  // Abort any pending beacons before creating a new one.
+  if (fetchLaterController) {
+    fetchLaterController.abort();
+  }
+  fetchLaterController = new AbortController();
+
+  // Update session duration to the current page time.
+  sessionData.duration = performance.now();
+
+  // Schedule a fetch for the data payload to be sent later.
+  // IMPORTANT: wrap the call in a try/catch to handle quota errors.
+  try {
+    fetchLater(ANALYTICS_ENDPOINT, {
+      method: 'POST',
+      headers: {'content-type': 'application/json'},
+      body: JSON.stringify(sessionData),
+      signal: fetchLaterController.signal,
+    });
+  } catch (error) {
+    // Handle errors as needed.
+  }
+}
+
+// Update the session data and queue a new beacon every 10 seconds.
+setInterval(queueBeacon, 10000);
+```
+
+## Best Practices
+
+- **DO** use `fetchLater()` to send data to a server in any situation where a response is not necessary, and it's not critical that the data is sent immediately.
+- **DO** use an `AbortController` to cancel the pending fetch in cases where the data may need to be updated before the user leaves the page
+- **DO** minimum the payload size to avoid exceeding the quota (currently roughly 64KB per origin).
+- **DO** wrap calls to `fetchLater()` in a `try/catch` to handle quota errors.
+- **DO** feature detect the presence of `fetchLater()` on `globalThis` and implement a fallback strategy for browsers that don't support the API.
+- **DO NOT** use a `ReadableStream` object for the request body, as that will error.
+
+## Browser support and fallback strategies
+
+fetchLater has limited availability.
+Supported by: Chrome 135 (Apr 2025) and Edge 135 (Apr 2025).
+Unsupported in: Firefox and Safari.
+
+A fallback strategy is required if `fetchLater()` doesn't meet your Baseline target. However, given the improved reliability and performance benefits of this API, `fetchLater()` should be used if the browser supports it.
+
+The recommended fallback strategy is to use the polyfill below, which internally handles unsupporting browsers using `fetch()` with `keepalive` or `navigator.sendBeacon()`. Your own code MUST call `fetchLater()` directly — never call `fetch()`, `sendBeacon()`, or other beacon APIs yourself.
+
+### `fetchLater()` polyfill
+
+Use the following minimal `fetchLater()` polyfill, which implements the API as closely as possible in unsupporting browsers.
+
+The only notable behavior difference with this polyfill is that it uses `visibilitychange` to detect when the user leaves, rather than relying on the browser's native unload handling. This is an internal implementation detail — your code does not need to listen for `visibilitychange` or any other page lifecycle events. Just call `fetchLater()` and the polyfill handles delivery.
+
+```js
+globalThis.fetchLater ??= function fetchLater(url, init = {}) {
+  let timeoutHandle;
+  let activated = false;
+
+  function sendNow() {
+    if (!(init.signal && init.signal.aborted)) {
+      // Use fetch keepalive if the browser supports it or if custom fetch
+      // parameters are specified (e.g. custom headers or methods).
+      // Otherwise fall back to `navigator.sendBeacon()`.
+      if (
+        'keepalive' in Request.prototype ||
+        init.method !== 'POST' ||
+        init.headers
+      ) {
+        fetch(url, Object.assign({}, init, {keepalive: true}));
+        activated = true;
+      } else {
+        activated = navigator.sendBeacon(url, init.body);
+      }
+    }
+    destroy();
+  }
+
+  function destroy() {
+    document.removeEventListener('visibilitychange', sendNow);
+    clearTimeout(timeoutHandle);
+  }
+
+  if (document.visibilityState === 'hidden') {
+    // If the beacon was created while the page is already hidden, send data
+    // ASAP but wait until the next microtask to allow all sync code to run.
+    queueMicrotask(sendNow);
+  } else {
+    document.addEventListener('visibilitychange', sendNow);
+
+    if (typeof init.activateAfter === 'number' && init.activateAfter >= 0) {
+      timeoutHandle = setTimeout(sendNow, init.activateAfter);
+    }
+  }
+
+  if (init.signal) {
+    init.signal.addEventListener('abort', destroy);
+  }
+
+  return {
+    get activated() {
+      return activated;
+    },
+  };
+};
+```

package/.agents/skills/modern-web-guidance/guides/performance/identify-heavy-scripts.md

@@ -0,0 +1,69 @@
+# Identify heavy-running JavaScript
+
+Heavy-running JavaScript can have a detrimental effect on both page load performance and interactivity. Modern web applications are more heavily reliant on JavaScript than ever before, from multiple sources. These include the application code itself (and the framework code it relies on), as well as third-party scripts that add functionality like chat widgets and video players. Behind-the-scenes analytics and marketing scripts are also common contributors that are all too easy to forget.
+
+Identifying root causes of an unresponsive web page can be tricky with certain expertise required to run web performance tracing or profiling and how to interpret the results. Additionally field data is often very different to lab data, which only replicates a small subset of real user scenarios. This can make it difficult to identify the root causes of poor performance, especially for interactions.
+
+The Long Animation Frames API is a lightweight API that can be used to identify heavy-running JavaScript in the field. A heavy-running script can be either a single long-running script, or a script that runs multiple times during the page lifecycle.
+
+## How to implement
+
+Long animation frames are monitored using the `PerformanceObserver` interface. It emits a `long-animation-frame` entry when an animation frame takes longer than 50ms to render. The entry contains information about the long animation frame, including the duration of the frame and the scripts that were executed during the frame.
+
+The `long-animation-frame` entry contains a `scripts` property which is an array of `PerformanceScript` objects. Each `PerformanceScript` object contains information about the script that was executed during the long animation frame, including the `sourceURL` and `duration` of the script.
+
+### Example of identifying the longest running scripts that contribute to long animation frames
+
+```javascript
+// Accumulate all script entries across the page lifecycle so no
+// data is lost between observer callbacks.
+const allScripts = [];
+
+const observer = new PerformanceObserver(list => {
+  // Collect all script entries across frames to find the biggest offenders.
+  allScripts.push(...list.getEntries().flatMap(entry => entry.scripts));
+
+  // Group by sourceURL so you can identify which scripts contribute
+  // the most total time, even if each individual invocation is short.
+  const scriptSource = [...new Set(allScripts.map(script => script.sourceURL))];
+  const scriptsBySource = scriptSource.map(sourceURL => ([sourceURL,
+      allScripts.filter(script => script.sourceURL === sourceURL)
+  ]));
+  const processedScripts = scriptsBySource.map(([sourceURL, scripts]) => ({
+    sourceURL,
+    count: scripts.length,
+    totalDuration: scripts.reduce((subtotal, script) => subtotal + script.duration, 0)
+  }));
+
+  // Only include scripts above a certain threshold to reduce noise.
+  const heavyScripts = processedScripts.filter(script => {
+    return script.totalDuration > 100;
+  });
+
+  // Sort by total duration so the worst offenders appear first,
+  // making it easier to prioritize optimization efforts.
+  heavyScripts.sort((a, b) => b.totalDuration - a.totalDuration);
+
+  // Log to the console for local debugging. In production, replace
+  // this with a call to send the data to your analytics service.
+  console.table(heavyScripts);
+});
+
+// Use buffered: true to capture any long frames that occurred before
+// this observer was registered.
+observer.observe({type: 'long-animation-frame', buffered: true});
+```
+
+## Best Practices
+
+- **DO** prefer the Long Animation Frames API over alternatives like the JS Self-Profiling API, which carries higher runtime overhead.
+- **DO** summarize the key information as the Long Animation Frames API contains a lot of detail.
+- **DO** send the required information to an analytics service in production.
+
+## Browser support and fallback strategies
+
+Long animation frames has limited availability.
+Supported by: Chrome 123 (Mar 2024) and Edge 123 (Mar 2024).
+Unsupported in: Firefox and Safari..
+
+The Long Animation Frames API is ignored by browsers that do not support it, so it can be safely used without fallbacks. In most cases the performance opportunities it identifies will apply to other browsers as well.

package/.agents/skills/modern-web-guidance/guides/performance/identify-inp-causes.md

@@ -0,0 +1,73 @@
+# Identify causes of poor INP
+
+Poor responsiveness to interactions leads to a poor impression of a page being slow or even completely broken. Interaction to Next Paint (INP) is a metric based on the Event Timing API. It measures the worst interaction (minus some outliers) as a measure of the page's responsiveness.
+
+Identifying root causes of an unresponsive web page can be tricky especially as it depends on user interactions and environmental conditions such as device capabilities and network conditions. This makes it even more difficult to diagnose compared to a more repeatable and predictable scenario like page load. Lab data only replicates a small subset of real user scenarios so measuring the causes of slow INP in the field is essential.
+
+The Event Timing API allows for splitting the INP duration into three subparts: Input Delay (processing that is already happing when the interaction happens), Processing Duration (delays due as a direct result of the interaction), and Presentation Delay (delays that are due to rendering the next frame after the interaction). This helps identify if the issue is in other code, the interaction JavaScript code, or browser processing rendering updates respectively rather than jumping straight to the interaction code.
+
+It is possible to gather further insights for JavaScript code delaying an interaction. A full performance trace using the JS Self-Profiling API is a heavyweight solution that is liable to cause performance problems. The Long Animation Frames API is a lightweight API that can be used to identify slow running JavaScript in the field for INP interactions.
+
+## How to implement
+
+Calculating INP from the raw Event Timing API is complicated and has several nuances. You are advised to use a RUM tool or library to gather this data.
+
+`web-vitals` is an open-source library from Google that calculates the Core Web Vitals including INP, and also includes subparts and long animation frame data for the INP interaction.
+
+## Get attributions for INP interactions using web-vitals library
+
+The `web-vitals` library is a tiny library used to measure Core Web Vitals and other performance metrics. The `onINP()` function can be used to identify the slowest interaction and includes information about the INP subparts and scripts that were executed during the interaction using the Long Animation Frames API.
+
+```javascript
+// Use the attribution build to get Long Animation Frame data
+// alongside the INP metric value.
+import { onINP } from 'web-vitals/attribution';
+
+onINP((metric) => {
+  // Beacon script attribution for the longest script during the INP
+  // interaction, so you can identify the root cause in production.
+  navigator.sendBeacon(
+    '/analytics',
+    JSON.stringify({
+      name: 'INP',
+      value: metric.value,
+      // These fields give the INP subparts:
+      inputDelay: metric.attribution.inputDelay,
+      presentationDelay: metric.attribution.presentationDelay,
+      processingDuration: metric.attribution.processingDuration,
+      interactionTarget: metric.attribution.interactionTarget,
+      // These fields identify which script function was responsible
+      // for the longest processing during the INP interaction.
+      invokerType: metric.attribution.longestScript.entry?.invokerType,
+      sourceURL: metric.attribution.longestScript.entry?.sourceURL,
+      sourceFunctionName: metric.attribution.longestScript.entry?.sourceFunctionName,
+      sourceCharPosition: metric.attribution.longestScript.entry?.sourceCharPosition,
+      // subpart indicates which phase (input delay, processing, or
+      // presentation delay) the longest script overlapped with most.
+      subpart: metric.attribution.longestScript.subpart,
+      intersectingDuration: metric.attribution.longestScript.intersectingDuration
+    })
+  );
+});
+```
+
+## Best Practices
+
+- **DO** use INP subparts initially to identify whether the delay is already running JavaScript (input delay), the event handlers JavaScript for the interaction (processing duration), or the subsequent rendering (presentation delay).
+- **DO** attempt to identify the biggest blocking JavaScript as additional detail, particularly for input delay, and processing duration.
+- **DO** prefer the Long Animation Frames API for providing this further detail over alternatives like the JS Self-Profiling API, which carries higher runtime overhead.
+- **DO** use the `web-vitals` library if no other RUM solution is in place. It can identify the INP interaction and includes information about the subparts and the scripts that were executed during the interaction (using the Long Animation Frames API).
+- **DO** beacon back the required information to an analytics service rather than just log it locally.
+
+## Browser support and fallback strategies
+
+Baseline status for Event timing: Newly available. It's been Baseline since 2025-12-12.
+Supported by: Chrome 76 (Jul 2019), Edge 79 (Jan 2020), Firefox 89 (Jun 2021), and Safari 26.2 (Dec 2025).
+
+The Event Timing API is available in most modern browsers and is necessary to calculate INP and the INP subparts. For browsers that do not support this API INP cannot be measured.
+
+Long animation frames has limited availability.
+Supported by: Chrome 123 (Mar 2024) and Edge 123 (Mar 2024).
+Unsupported in: Firefox and Safari.
+
+The Long Animation Frames API provides optional, additional details. It can be safely used without fallbacks. In most cases the performance opportunities it identifies will apply to other browsers as well.