# WebPerf Snippets

> A curated collection of JavaScript snippets for web performance measurement in browser consoles and Chrome DevTools.
> Source: https://webperf-snippets.nucliweb.net

---

## Core Web Vitals

- [Cumulative Layout Shift (CLS)](https://webperf-snippets.nucliweb.net/CoreWebVitals/CLS)
  Quick check for Cumulative Layout Shift, a Core Web Vital that measures visual stability. CLS tracks how much the page layout shifts unexpectedly during its lifetime, providing a single score that represents the cumulative impact of all unexpected layout shifts. Why this matters: Unexpected layout shifts are frustrating and can cause users to click the wrong element or lose their reading position. CLS directly impacts user experience and is a ranking factor for Google Search. Common causes include images without dimensions, web fonts, and dynamically injected content. CLS Rating Thresholds:

- [Interaction to Next Paint (INP)](https://webperf-snippets.nucliweb.net/CoreWebVitals/INP)
  Tracks Interaction to Next Paint, a Core Web Vital that measures responsiveness. INP evaluates how quickly a page responds to user interactions throughout the entire page visit, replacing First Input Delay (FID) as a Core Web Vital in March 2024. Why this matters: INP directly measures user frustration. When users click a button and nothing happens for seconds, they abandon tasks. Unlike FID which only measured first interaction, INP tracks ALL interactions, making it a more comprehensive responsiveness metric and a key ranking factor for Google Search. INP Rating Thresholds:

- [LCP Image Entropy](https://webperf-snippets.nucliweb.net/CoreWebVitals/LCP-Image-Entropy)
  Checks if images qualify as LCP candidates based on their entropy (bits per pixel). Since Chrome 112, low-entropy images are ignored for LCP measurement. Based on Stoyan Stefanov's BPP check. What is BPP (Bits Per Pixel)? BPP measures image complexity/entropy: ``` BPP = (file size in bits) / (width × height)     = (encodedBodySize × 8) / (width × height) ``` LCP eligibility threshold:

- [LCP Subparts](https://webperf-snippets.nucliweb.net/CoreWebVitals/LCP-Subparts)
  Breaks down Largest Contentful Paint into its four phases to identify optimization opportunities. Understanding which phase is slowest helps you focus your optimization efforts where they'll have the most impact. Based on the Web Vitals Chrome Extension. Why this matters: LCP is a critical Core Web Vital that measures when the largest content element becomes visible. By breaking it into sub-parts, you can pinpoint exactly where delays occur and apply targeted optimizations instead of guessing. The four phases of LCP: ```mermaid flowchart LR     A([Navigation<br/>Start]) --> B["⏱️ TTFB<br/><small>Server Response</small>"]     B --> C["⏳ Load Delay<br/><small>Resource Discovery</small>"]     C --> D["📥 Load Time<br/><small>Download Resource</small>"]     D --> E["🎨 Render Delay<br/><small>Paint Element</small>"]     E --> F([✅ LCP<br/>Complete])     style B fill:#FFE5E5,stroke:#FF4444,stroke-width:2px     style C fill:#FFF3E5,stroke:#FF8800,stroke-width:2px     style D fill:#FFFBE5,stroke:#FFBB00,stroke-width:2px     style E fill:#E5FFE5,stroke:#44AA44,stroke-width:2px     style F fill:#E5F2FF,stroke:#4488FF,stroke-width:3px ```

- [LCP Trail](https://webperf-snippets.nucliweb.net/CoreWebVitals/LCP-Trail)
  Tracks every LCP candidate element during page load and highlights each one with a distinct pastel-colored dashed outline — so you can see the full trail from first candidate to final LCP. Each time the browser promotes a larger element as the new LCP, the snippet assigns the next color in the palette and highlights it. All previous candidates remain visible on the page for easy comparison.

- [LCP Video Candidate](https://webperf-snippets.nucliweb.net/CoreWebVitals/LCP-Video-Candidate)
  Detects whether the LCP element is a `<video>` and audits the poster image configuration — the most common source of avoidable LCP delay when video is the hero element. When a `<video>` element has a `poster` attribute, the browser treats the poster image as the LCP candidate. The browser cannot discover the poster URL until the parser reaches the `<video>` tag, so without a `<link rel="preload">` the poster is fetched late, increasing LCP. What this snippet checks:

- [Largest Contentful Paint (LCP)](https://webperf-snippets.nucliweb.net/CoreWebVitals/LCP)
  Quick check for Largest Contentful Paint, a Core Web Vital that measures loading performance. LCP marks when the largest content element becomes visible in the viewport. LCP Rating Thresholds:

## Loading

- [Back/Forward Cache (bfcache)](https://webperf-snippets.nucliweb.net/Loading/Back-Forward-Cache)
  Analyzes Back/Forward Cache (bfcache) to determine if your page is eligible for instant back/forward navigations. When bfcache works, users get instant (0ms) page loads when using browser back/forward buttons, dramatically improving perceived performance. Why this matters: bfcache is one of the most impactful performance optimizations available - it can make navigation instantaneous. However, many pages are unknowingly ineligible due to common patterns like `unload` handlers, `Cache-Control: no-store`, or ongoing network requests. This snippet helps identify why your page isn't being cached and how to fix it. bfcache Impact:

- [CSS Media Queries Analysis](https://webperf-snippets.nucliweb.net/Loading/CSS-Media-Queries-Analysis)
  Analyze all `@media` rules in CSS stylesheets to identify classes and properties targeting viewports bigger than a specified breakpoint (default: 768px). Results are grouped by inline CSS and external files, with byte size estimates for potential mobile savings. This page provides two complementary analysis functions: 1. `analyzeCSSMediaQueries(minWidth)` - Identifies desktop-specific CSS and calculates byte savings 2. `analyzeCSSPerformanceImpact(minWidth)` - Estimates real-world performance impact across device profiles, including Core Web Vitals effects, render-blocking time, and business impact projections

- [Cache Strategy Analysis](https://webperf-snippets.nucliweb.net/Loading/Cache-Strategy-Analysis)
  Audits HTTP caching strategies across all page resources, identifying resources without cache, short-lived cache configurations, cache anti-patterns, and CDN cache hit rates. Provides a cache efficiency score and actionable recommendations. What this snippet analyzes: - Cache strategy classification for every resource (immutable, long, medium, short, no-cache, no-store, etc.) - Resources missing cache headers entirely - Static assets with insufficient cache duration - Cache anti-patterns (versioned files without `immutable`, large uncached resources, outdated `Expires` usage) - CDN cache hit/miss detection (Cloudflare, Vercel, CloudFront, and generic proxies) - Cache efficiency score and estimated bandwidth savings - Protocol distribution (HTTP/1.1 vs H2/H3) - Uncompressed text resources and duplicate resource loads How the browser decides to serve a resource: ```mermaid flowchart TD     A[Resource Request] --> B{In browser cache?}     B -- No --> C[Fetch from network]     B -- Yes --> D{Cache-Control directive?}     D -- no-store --> C     D -- no-cache / max-age=0 --> E[Revalidate with server]     D -- max-age not expired --> F[Serve from cache ✅]     D -- max-age expired --> E     E -- 304 Not Modified --> F     E -- 200 OK --> G[New response + update cache]     C --> G ``` Why caching matters for performance:

- [Client-Side Redirect Detection](https://webperf-snippets.nucliweb.net/Loading/Client-Side-Redirect-Detection)
  Detects client-side redirects that add unnecessary latency to page load and impact Core Web Vitals, particularly LCP. Client-side redirects implemented via JavaScript or SPA routers can add seconds to the critical rendering path, yet they're often invisible to standard monitoring tools. Why this matters: Client-side redirects are one of the most impactful but hardest-to-detect performance issues: - Add complete navigation overhead (HTML download, JS parsing, execution) just to redirect - Can increase LCP by 3 to 6 seconds on first visit - Waste bandwidth downloading resources that won't be displayed - Not visible in basic performance metrics - Often introduced accidentally during localization or A/B testing Common patterns that trigger client-side redirects:

- [Content Visibility](https://webperf-snippets.nucliweb.net/Loading/Content-Visibility)
  Detect and analyze all elements using `content-visibility: auto` on a page. This CSS property is a powerful rendering optimization that allows browsers to skip layout and painting work for offscreen content, significantly improving initial page load performance. This page provides two complementary analysis functions: 1. `detectContentVisibility()` - Finds all elements with `content-visibility: auto` and provides inspection tools 2. `analyzeContentVisibilityOpportunities(options)` - Walks the DOM to find offscreen elements that could benefit from `content-visibility: auto`, with configurable thresholds for distance, height, and child count This snippet code is based on the script by Arjen Karel

- [Critical CSS Detection](https://webperf-snippets.nucliweb.net/Loading/Critical-CSS-Detection)
  Analyzes the CSS loading strategy of a page — identifying render-blocking stylesheets, measuring their size against the critical 14 KB budget, and detecting whether critical CSS is properly inlined for above-the-fold content. What makes CSS "critical":

- [Event Processing Time](https://webperf-snippets.nucliweb.net/Loading/Event-Processing-Time)
  Analyzes the time spent in each phase of page navigation, from initial redirect to the load event. This helps identify bottlenecks in the page loading process and understand where time is being spent. Key phases in page load: ```mermaid gantt     title Page Load Timeline     dateFormat X     axisFormat %s     section Network     Redirect           :0, 50     DNS Lookup         :50, 80     TCP Connection     :80, 120     SSL/TLS            :120, 180     Request/Response   :180, 350     section Processing     DOM Processing     :350, 500     DOMContentLoaded   :500, 520     Resources Loading  :520, 800     Load Event         :800, 820 ``` What each phase means:

- [First Contentful Paint (FCP)](https://webperf-snippets.nucliweb.net/Loading/FCP)
  Quick check for First Contentful Paint, the metric that marks when the browser renders the first piece of DOM content — text, image, canvas, or SVG. FCP measures the user's perception of whether the page is loading. Unlike LCP, FCP fires as soon as _any_ content appears, making it the earliest signal of loading progress. A slow FCP almost always points to TTFB or render-blocking resources. FCP Rating Thresholds:

- [Find Above The Fold Lazy Loaded Images](https://webperf-snippets.nucliweb.net/Loading/Find-Above-The-Fold-Lazy-Loaded-Images)
  Detect images with lazy loading that are incorrectly placed above the fold (in the viewport). Lazy loading above-the-fold images is a common performance anti-pattern that can significantly harm your Largest Contentful Paint (LCP) score. The snippet identifies images with `loading="lazy"` or `[data-src]` in the viewport, detects the LCP candidate, and provides detailed performance metrics.

- [Find Images With Loading Lazy and Fetchpriority](https://webperf-snippets.nucliweb.net/Loading/Find-Images-With-Lazy-and-Fetchpriority)
  Detects images that have both `loading="lazy"` and `fetchpriority="high"` - a contradictory combination that indicates a misconfiguration. Why this is a problem:

- [Find non Lazy Loaded Images outside of the viewport](https://webperf-snippets.nucliweb.net/Loading/Find-non-Lazy-Loaded-Images-outside-of-the-viewport)
  Identifies images that are loaded eagerly but not visible in the initial viewport, representing wasted bandwidth and parsing time that delays page interactivity. The snippet analyzes all `<img>` elements to find optimization opportunities for lazy loading. Images outside the viewport that load immediately: - Waste bandwidth by downloading resources users may never see - Block the main thread during decoding and rendering - Delay LCP by competing for network and CPU resources - Increase memory usage unnecessarily This script detects images without `loading="lazy"` or `[data-src]` attributes that are positioned outside the initial viewport, including images in hidden containers (tabs, modals, carousels). It also identifies the LCP candidate to ensure you don't accidentally lazy-load it.

- [Find render-blocking resources](https://webperf-snippets.nucliweb.net/Loading/Find-render-blocking-resources)
  Identifies resources that block the browser from rendering the page. These resources must be fully downloaded and processed before the browser can display any content, directly impacting First Contentful Paint (FCP) and Largest Contentful Paint (LCP). Render-blocking resources are the primary cause of slow initial page renders. Users see a blank white screen while CSS and JavaScript files download and parse. On slow connections or mobile networks, this can add several seconds to your load time. Eliminating or deferring render-blocking resources is one of the highest-impact optimizations you can make.

- [First And Third Party Script Info](https://webperf-snippets.nucliweb.net/Loading/First-And-Third-Party-Script-Info)
  Analyzes all scripts loaded on the page, separating them into first-party (your domain) and third-party (external) scripts. This helps identify the performance impact of external dependencies. Why this matters:

- [First And Third Party Script Timings](https://webperf-snippets.nucliweb.net/Loading/First-And-Third-Party-Script-Timings)
  Analyzes detailed timing phases for all scripts, comparing first-party vs third-party performance. This helps identify slow connection phases, DNS issues, or server response problems. Timing phases explained: ```mermaid sequenceDiagram     participant B as Browser     participant D as DNS     participant S as Server     B->>B: Redirect (if any)     B->>D: DNS Lookup     D-->>B: IP Address     B->>S: TCP Connection     B->>S: TLS/SSL Handshake     B->>S: Request     S-->>B: Response Start     S-->>B: Response End ```

- [Fonts Preloaded, Loaded, and Used Above The Fold](https://webperf-snippets.nucliweb.net/Loading/Fonts-Preloaded-Loaded-and-used-above-the-fold)
  Analyzes font loading strategy by comparing preloaded fonts, loaded fonts, and fonts actually used above the fold. This helps identify optimization opportunities and wasted resources. Why font loading matters:

- [Get your `<head>` in order](https://webperf-snippets.nucliweb.net/Loading/Get-Your-Head-in-Order)

- [Inline CSS Info and Size](https://webperf-snippets.nucliweb.net/Loading/Inline-CSS-Info-and-Size)
  Analyzes all inline `<style>` tags on the page, measuring their size and identifying optimization opportunities. This helps understand how much CSS is inlined and whether it's being used effectively. When inline CSS is good:

- [Inline Script Info and Size](https://webperf-snippets.nucliweb.net/Loading/Inline-Script-Info-and-Size)
  Analyzes all inline `<script>` tags on the page, measuring their size and identifying potential performance issues. This helps understand the impact of inline JavaScript on page load. When inline scripts are good:

- [JavaScript Execution Time Breakdown](https://webperf-snippets.nucliweb.net/Loading/JS-Execution-Time-Breakdown)
  Identifies where JavaScript time goes during page load: network download vs browser parsing. Shows which scripts delay `domInteractive` (TTI proxy) and flags code splitting opportunities. Why this matters: Knowing a script is "slow" isn't enough — the bottleneck can be the network download or the browser parsing and compiling the code after downloading. These require different fixes:

- [Prefetch Resource Validation](https://webperf-snippets.nucliweb.net/Loading/Prefetch-Resource-Validation)
  Detects potential performance issues with `rel="prefetch"` resource hints by analyzing quantity, size, type, and appropriateness of prefetched resources. Excessive or incorrect prefetch usage can waste bandwidth, delay critical resources, and negatively impact mobile users. What is prefetch? `rel="prefetch"` is a resource hint that tells the browser to fetch and cache resources that may be needed for future navigations, during idle time. Unlike `preload`, which is for the current page, prefetch is for anticipated next-page resources. Difference between preload and prefetch:

- [Priority Hints Audit](https://webperf-snippets.nucliweb.net/Loading/Priority-Hints-Audit)
  Audits all `fetchpriority` attribute usage across the page — covering non-image resources (scripts, preload links, iframes), `fetchpriority="low"` analysis, and conflicts between `preload` and low priority. Identifies the LCP candidate when it lacks `fetchpriority="high"`.

- [Resource Hints Validation](https://webperf-snippets.nucliweb.net/Loading/Resource-Hints-Validation)
  Validates resource hints (preload, preconnect, dns-prefetch) by analyzing which hints are declared and whether the resources or connections are actually used. Detects unused hints that waste browser resources and opportunities to optimize loading. What are resource hints? Resource hints tell the browser to perform actions that can improve loading performance:

- [Resource Hints](https://webperf-snippets.nucliweb.net/Loading/Resource-Hints)
  Analyzes resource hints on the page, checking for proper usage and identifying optimization opportunities. Resource hints help the browser prioritize resource loading for better performance. Resource hint types:

- [SSR Framework Hydration Data Analysis](https://webperf-snippets.nucliweb.net/Loading/SSR-Hydration-Data-Analysis)
  Analyzes hydration data scripts used by SSR frameworks like Next.js, Nuxt, Remix, Gatsby, and others. These scripts contain serialized state that the client needs to "hydrate" the server-rendered HTML into an interactive application. Supported frameworks:

- [Scripts Loading](https://webperf-snippets.nucliweb.net/Loading/Script-Loading)
  Analyzes all scripts on the page, showing their loading strategy and identifying potential performance issues. Scripts are often the biggest cause of main thread blocking and delayed rendering. This snippet helps you audit which scripts are blocking the critical rendering path. Why this matters: Render-blocking scripts in `<head>` without `async` or `defer` pause HTML parsing while they download and execute. This delays First Contentful Paint (FCP) and Largest Contentful Paint (LCP). Even a single blocking script can add hundreds of milliseconds to your load time, especially on slower connections. How scripts affect HTML parsing:

- [Service Worker Analysis](https://webperf-snippets.nucliweb.net/Loading/Service-Worker-Analysis)
  Analyzes the Service Worker lifecycle, cache behavior, and its performance impact on resource loading. Service Workers can dramatically improve performance through caching strategies, but misconfigured workers can introduce startup delays and degrade TTFB. What this snippet measures: - Service Worker registration state and active/waiting/installing workers - Navigation Preload status (reduces SW startup cost on navigation) - SW startup overhead on page load (impact on TTFB) - Resources intercepted by the SW vs. bypassed - Cache hit rate for SW-intercepted resources - Cache Storage inventory (caches and entry counts) SW impact on navigation timing: ```mermaid sequenceDiagram     participant B as Browser     participant SW as Service Worker     participant C as Cache Storage     participant N as Network     B->>SW: Navigation request     Note over SW: workerStart → fetchStart<br/>(SW startup overhead)     alt Cache hit         SW->>C: respondWith(caches.match())         C-->>SW: Cached response         SW-->>B: Response (transferSize = 0)         Note over B: Fast ✓ No network     else Cache miss         SW->>N: fetch(request)         N-->>SW: Network response         SW-->>B: Response (transferSize > 0)         Note over B: Network fallback     end ``` Navigation Preload reduces SW startup cost: ```mermaid sequenceDiagram     participant B as Browser     participant SW as Service Worker     participant N as Network     rect rgb(255, 235, 235)         Note over B,N: Without Navigation Preload         B->>SW: Start SW         Note over SW: Startup delay...         SW->>N: fetch(event.request)         N-->>B: Response     end     rect rgb(235, 255, 235)         Note over B,N: With Navigation Preload         B->>SW: Start SW         B->>N: Preload request (parallel!)         Note over SW: Startup runs in parallel         N-->>SW: Preloaded response         SW-->>B: Response (no extra delay)     end ```

- [Time To First Byte](https://webperf-snippets.nucliweb.net/Loading/TTFB)
  Time to First Byte (TTFB) measures the time from when the user starts navigating to a page until the first byte of the HTML response is received. It's a critical metric that reflects server responsiveness and network latency. TTFB includes: - Redirect time - Service worker startup time (if applicable) - DNS lookup - TCP connection and TLS negotiation - Request time until the first byte of the response arrives Thresholds (according to web.dev):

- [Validate Preload on Async/Defer Scripts](https://webperf-snippets.nucliweb.net/Loading/Validate-Preload-Async-Defer-Scripts)
  Detects preload resource hints for scripts that use `async` or `defer` attributes. This is an anti-pattern that wastes bandwidth and can hurt performance by artificially elevating the priority of resources that should load at lower priority. Why this matters:

## Interaction

- [Forced Synchronous Layout Detector](https://webperf-snippets.nucliweb.net/Interaction/Forced-Synchronous-Layout)
  Detects the Forced Synchronous Layout (FSL) pattern at runtime — when JavaScript reads geometric properties from the DOM immediately after mutating styles, forcing the browser to perform layout synchronously on the main thread. Why this matters: Normally the browser batches style recalculations and layout at the end of each frame. FSL breaks this contract: reading a geometric property after a style mutation forces the browser to flush pending style changes and recalculate layout _right now_, before the current task finishes. This blocks the main thread and contributes directly to long tasks, poor INP, and jank. A typical FSL pattern: ```js container.classList.toggle('state-a'); // invalidates styles container.scrollTop = 0;              // forces layout synchronously → FSL ``` The fix — double rAF: ```js container.classList.toggle('state-a'); requestAnimationFrame(() => {         // 1st rAF: browser processes styles   requestAnimationFrame(() => {       // 2nd rAF: layout tree is clean     container.scrollTop = 0;          // no FSL   }); }); ``` Step through the render pipeline to see _why_ the double `requestAnimationFrame` avoids the forced layout:

- [Input Latency Breakdown](https://webperf-snippets.nucliweb.net/Interaction/Input-Latency-Breakdown)
  Aggregates interaction latency by event type to reveal which phase causes slowness across all interactions with the page. While Interactions shows a per-interaction breakdown in real time, this snippet collects data over time and answers a different question: is click systematically slower than keypress? Is the bottleneck always input delay, or does it vary by event? Why this matters: INP measures the worst interaction, but understanding the pattern across many interactions is more actionable. A click with high input delay has a different fix than a keypress with slow processing time. Grouping by event type surfaces systematic problems instead of outliers. The three phases of every interaction:

- [Interactions](https://webperf-snippets.nucliweb.net/Interaction/Interactions)
  Tracks all user interactions in real-time to help debug and improve Interaction to Next Paint (INP). INP measures responsiveness by tracking the latency of all interactions during a page visit. This snippet breaks down each interaction into three phases to identify bottlenecks. Based on the Web Vitals Chrome Extension. Why this matters: INP is a Core Web Vital that directly affects user experience. Slow interactions make your site feel sluggish and frustrating. By identifying which phase causes delays (input delay, processing, or presentation), you can apply targeted optimizations to make your site feel more responsive. INP Rating Thresholds:

- [Layout Shift Tracking](https://webperf-snippets.nucliweb.net/Interaction/Layout-Shift-Loading-and-Interaction)
  Tracks all layout shifts during page load and user interaction, identifying the elements causing Cumulative Layout Shift (CLS). This debugging-focused snippet logs every shift with detailed information about which elements moved and when. Why this matters: While the CLS quick check gives you a score, this snippet helps you debug which specific elements are causing layout shifts. It shows you the exact selectors, movement distances, and whether shifts were excluded due to user input. This is essential for fixing CLS issues. CLS Rating Thresholds:

- [LoAF Helpers](https://webperf-snippets.nucliweb.net/Interaction/Long-Animation-Frames-Helpers)
  Advanced debugging utilities for Long Animation Frames. While the basic LoAF snippet shows real-time frame data, this helper library provides powerful analysis, filtering, and export capabilities. When to use each:

- [Long Animation Frames Script Attribution](https://webperf-snippets.nucliweb.net/Interaction/Long-Animation-Frames-Script-Attribution)
  Analyzes and visualizes which scripts are responsible for blocking the main thread. This snippet categorizes blocking time by script origin (your code, framework, third-party, extensions) and provides actionable insights for optimization. Why Script Attribution Matters: - Identify if blocking comes from your code vs third-parties - Prioritize optimization efforts on the biggest offenders - Separate framework overhead from application code - Track third-party impact on performance - Segment RUM data by script category What you'll see: - Blocking time breakdown by script category (first-party, framework, third-party, unknown) - Top blocking scripts ranked by total duration - Visual ASCII chart showing contribution percentages - Specific file names and function names responsible - Actionable recommendations based on data ```mermaid graph LR     A[Capture LoAF] --> B[Extract Scripts]     B --> C{Categorize}     C --> D[Your Code]     C --> E[Framework]     C --> F[Third-Party]     C --> G[Unknown]     D --> H[Calculate %]     E --> H     F --> H     G --> H     H --> I[Visual Report]     I --> J[Optimization Priority]     style D fill:#3b82f6,color:#fff     style E fill:#8b5cf6,color:#fff     style F fill:#f59e0b,color:#fff     style G fill:#6b7280,color:#fff ``` Purpose: Provide detailed attribution of main thread blocking to specific scripts, categorized by origin and ranked by impact. Key Features: 1. Automatic Categorization: Classifies scripts as first-party, framework, third-party, or unknown 2. Visual Breakdown: ASCII charts showing percentage contribution 3. Top Offenders: Ranked list of scripts by total blocking time 4. Actionable Insights: Specific recommendations based on findings 5. RUM Integration: Export data in format ready for analytics Use Cases: - Performance audits: "Where should we optimize first?" - Third-party analysis: "Is our analytics/ads slowing us down?" - Framework cost: "How much overhead does React/Vue add?" - Before/after comparisons: "Did our optimization work?"

- [Long Animation Frames (LoAF)](https://webperf-snippets.nucliweb.net/Interaction/Long-Animation-Frames)
  Tracks Long Animation Frames to identify JavaScript and rendering work that blocks the main thread. LoAF is the underlying API that powers INP debugging and provides detailed attribution for slow interactions. Why this matters: LoAF is the successor to the Long Tasks API and provides much more detailed information about what's blocking your page. It tells you exactly which scripts ran, how long they took, and whether they caused forced layouts. This is essential for debugging slow interactions and improving INP scores. What is a Long Animation Frame? A frame is considered "long" when it takes more than 50ms. The API provides detailed breakdown of where time is spent:

- [Long Tasks](https://webperf-snippets.nucliweb.net/Interaction/LongTask)
  Tracks tasks that block the main thread for more than 50ms. Long tasks prevent the browser from responding to user input, causing poor Interaction to Next Paint (INP) and sluggish user experience. Why this matters: When the main thread is blocked by a long task, the browser cannot respond to clicks, taps, or keyboard input. This creates a frustrating experience where the page feels "frozen". Long tasks are the primary cause of poor INP scores and should be broken up into smaller chunks.

- [Scroll Performance Analysis](https://webperf-snippets.nucliweb.net/Interaction/Scroll-Performance)
  Measures scroll jank, frame drops, and event listener configuration to identify what makes scrolling feel laggy or unresponsive. Scroll jank — visible stuttering during scroll — is one of the most common UX problems on the web, especially on mobile. Why this matters: Scroll jank is caused by work blocking the compositor thread: non-passive event listeners, heavy JavaScript during scroll, or large layout-triggering DOM reads. Even a few dropped frames per second are noticeable to users and contribute to poor experience scores. What this snippet detects:

## Media

- [Image Element Audit](https://webperf-snippets.nucliweb.net/Media/Image-Element-Audit)
  Audits all `<img>` elements on the page against image performance best practices — covering loading strategy, fetch priority, format modernisation, responsive markup, and CLS prevention. What this snippet checks:

- [SVG Embedded Bitmap Analysis](https://webperf-snippets.nucliweb.net/Media/SVG-Embedded-Bitmap-Analysis)
  Scans all SVG resources on the page — both external files and inline `<svg>` elements — and flags any that contain embedded bitmap images, reporting name, transfer size, compression encoding, and embedded bitmap details. What this snippet detects:

- [Video Element Audit](https://webperf-snippets.nucliweb.net/Media/Video-Element-Audit)
  Audits all `<video>` elements on the page against video performance best practices — covering preload strategy, autoplay configuration, format modernisation, CLS prevention, and playback accessibility. What this snippet checks:

## Resources

- [Network Bandwidth & Connection Quality](https://webperf-snippets.nucliweb.net/Resources/Network-Bandwidth-Connection-Quality)
  Network quality directly affects web performance. Segmenting metrics by connection type helps identify whether performance issues are infrastructure-related or affect only users on slower connections. Measured properties: - Connection type (WiFi, cellular, etc.) - Effective connection type (slow-2g, 2g, 3g, 4g) - Estimated downlink speed (Mbps) - Round Trip Time (RTT) estimate - Save-Data preference status Use cases: - Segment RUM data by connection quality - Serve adaptive experiences based on network conditions - Debug performance regressions for specific network profiles

## DevTools Overrides

- [Fetch & XHR Timeline](https://webperf-snippets.nucliweb.net/DevTools-Overrides/Fetch-XHR-Timeline)
  Intercepts every `fetch()` and `XMLHttpRequest` call made during the page lifecycle and correlates them with the Largest Contentful Paint (LCP) timing. Console snippets can only see requests that have already completed and are visible in the Resource Timing API. That excludes cross-origin requests without `Timing-Allow-Origin`, requests made by service workers, and calls that fail before a response is received. This snippet patches `window.fetch` and `XMLHttpRequest.prototype` at page initialization, so every call is captured regardless of origin or outcome. What it helps diagnose: - API calls that complete *before* LCP and may be blocking the critical rendering path - Failed or errored requests during framework bootstrap (Angular, React, Vue resolvers and guards) - Unnecessary authentication checks on pages where the user is known to be unauthenticated - The full request inventory of a page, including calls invisible to the Network panel timing data