No history yet

Performance Edge Cases

Beyond the Basics: INP and Rendering Bottlenecks

Core Web Vitals have matured. While LCP and CLS remain, First Input Delay (FID) has been superseded by a more comprehensive metric: (INP). FID only measured the input delay—the time the browser waits before starting to process an event. INP measures the entire interaction latency, from the user's input (like a click or tap) through the processing time until the next frame is painted on the screen. A good INP is considered to be under 200 milliseconds, measured at the 75th percentile of all page interactions.

The key to optimising INP is identifying and breaking up Long Tasks on the main thread. Any single task that takes longer than 50 milliseconds can block the main thread, delaying the browser's ability to respond to user input. This makes the page feel janky and unresponsive. Using the Long Tasks API in combination with performance observers allows you to programmatically detect these bottlenecks in the field and pinpoint the scripts or processes responsible.

// Example: Using PerformanceObserver to find long tasks
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Log the long task and its attribution to the console
    console.log('Long Task Detected:', entry.toJSON());
  }
});

observer.observe({ type: 'longtask', buffered: true });

Proactive Resource Loading

Modern browsers are quite good at prioritising resources, but they aren't clairvoyant. The Fetch Priority API gives developers a direct way to signal the importance of a resource. By applying fetchpriority="high", you can tell the browser to download a critical resource, like your LCP image or a crucial CSS file, before other less important ones. Conversely, fetchpriority="low" can be used for non-critical assets like late-loading carousels or below-the-fold images.

<!-- Prioritising the LCP image -->
<img src="/path/to/hero-image.webp" fetchpriority="high" alt="...">

<!-- Deprioritising a less important script -->
<script src="/path/to/analytics.js" fetchpriority="low" async></script>

Taking this a step further, the Speculation Rules API offers a way to achieve near-instantaneous page loads for subsequent navigations. Instead of just prefetching resources, this API allows you to declaratively tell the browser which URLs a user is likely to navigate to next. The browser can then choose to not only prefetch the resources but fully prerender the entire page in a background process. When the user clicks the link, the page is swapped in almost instantly.

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/articles/*" },
          { "not": { "selector_matches": ".no-prerender" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Navigating Complex Scenarios

In Single-Page Applications (SPAs), route changes often happen client-side without a full page reload. These are known as and they present a challenge for CWV measurement. Standard tools often fail to capture LCP or CLS changes that occur after the initial load. This can lead to misleadingly good scores, as they only reflect the performance of the initial shell and not the user's actual journey through the application. Google is actively working on heuristics to better attribute vitals to soft navigations, but custom instrumentation is often required for accurate reporting.

Debugging Cumulative Layout Shift (CLS) also becomes more complex in pages with dynamic content. Asynchronous ad injections, cookie banners, or late-loading notifications are common culprits. The key is to use the Performance panel in Chrome DevTools to identify the specific elements causing the shifts. Look for the "Layout Shift" track and inspect the "Summary" tab to see the "Moved from" and "Moved to" coordinates. A common fix is to reserve space for these elements using min-height or aspect ratios so the layout doesn't reflow when they eventually load.

Lesson image

Finally, don't neglect the server. Time to First Byte (TTFB) remains a critical metric. A slow TTFB not only delays the start of the entire rendering process but also impacts your site's Crawl Capacity. Search engine bots have a finite budget for crawling your site; if your server is slow to respond, they can't crawl as many pages. Aggressive optimisation at the Edge—using a CDN, caching static HTML, and running logic with edge functions—can drastically reduce TTFB, improving both user experience and SEO performance.

Optimizing Core Web Vitals is not a one-time task—it demands consistent tracking, analysis, and refinement.

Time for a quick check on these advanced concepts.

Quiz Questions 1/6

Which statement best describes the primary difference between Interaction to Next Paint (INP) and the metric it replaced, First Input Delay (FID)?

Quiz Questions 2/6

A task on the main thread is considered a 'Long Task'—potentially blocking user input—if it takes longer than ___ milliseconds to execute.