DEV Community: Shidhin

Declarative Partial Updates: Streaming HTML Where It Matters Most

Shidhin — Fri, 25 Sep 2026 12:31:48 +0000

Since I joined the Dashboard team at Xendit, I've been taking care of frontend platform work like this. And I keep coming back to one question: what does the user see first, and how long do they wait for it? A typical dashboard page has a header, a side navigation, a few summary cards and a big table of recent transactions. The header and the navigation are ready in a few milliseconds. The table depends on a slow query. And because HTML is delivered top to bottom, the fast parts of the page often end up waiting for the slow one.

We usually solve this with JavaScript. Render a skeleton, fetch the data on the client, and swap the content in when it arrives. It works, but it means more JavaScript, more round trips, and more code to maintain for something the server already knew how to render.

Chrome recently shipped a set of platform features under the name Declarative Partial Updates. They let the server stream HTML out of order, and let JavaScript stream HTML into an existing page. In this blog post, we'll explore how these features work, look at a streaming dashboard example, combine both APIs into an SPA-style navigation, and see how to use them today with polyfills.

The problem: HTML is delivered in order

The HTML parser reads a document from top to bottom. If the transactions table sits in the middle of the page, everything after it has to wait until the server finishes rendering that table. The server can flush the header early, but it can't send the footer before the table, because the footer comes later in the document.

To work around this, we usually pick one of these options:

Wait for the whole page to be ready, and send it in one go. Simple, but the slowest part decides the speed of the whole page.
Send a skeleton and fetch the slow parts with JavaScript. Fast first paint, but the data needs an extra round trip after the JavaScript loads.
Use a framework that streams HTML out of order. Frameworks like React do this with hidden containers and small inline scripts that move the content into place. It works well, but it's framework machinery for something HTML can't express on its own.

The interesting part is that, in all three cases, the server already knows the content. The only thing stopping it from sending the content early is the order of the document.

What are Declarative Partial Updates?

Declarative Partial Updates is a project from the Chrome team, incubated in the WICG. The first two pieces of it are now available:

Out-of-order streaming. A <template> element with a new for attribute can patch content into named placeholders, anywhere earlier in the document.
New HTML insertion and streaming methods. A consistent set of JavaScript methods like setHTML(), appendHTML() and streamHTML(), with streaming versions that accept a WritableStream.

The first one needs no JavaScript at all. The second one fills the gap for content that can't come from the initial HTML response. Let's look at each of them.

Out-of-order streaming with `<template for>`

Out-of-order streaming uses two building blocks:

Processing instructions as named placeholders. They look like <?marker name="x">. XML has had processing instructions for a long time, but HTML used to treat them as comments. They are now part of the HTML standard.
<template for="x"> as the patch. When the parser reaches the template, it looks up the placeholder with the same name and puts the template's content there.

There are three kinds of placeholders:

<?marker name="x"> is an insertion point.
<?start name="x"> and <?end> wrap a range of fallback content, which gets replaced.

Example 1: A simple marker

<div>
  <?marker name="greeting">
</div>

<!-- ...rest of the page... -->

<template for="greeting">
  Here is some <em>HTML content</em>!
</template>

After parsing, the <div> contains the content of the template. The template itself doesn't stay in the DOM.

Example 2: Fallback content with start and end

<section id="summary">
  <?start name="summary">
  Loading summary…
  <?end>
</section>

<!-- ...later in the same response... -->

<template for="summary">
  <p>Volume: 1,204 · Success rate: 98.2%</p>
</template>

The user sees Loading summary… until the template arrives. Then the range is replaced with the real content. This is the pattern I'd use for dashboard cards.

Example 3: Appending items one by one

A template can include a new marker with the same name. This lets the next template continue from where the last one stopped:

<ul>
  <?start name="results">
  Loading…
  <?end>
</ul>

<template for="results">
  <li>Result One</li>
  <?marker name="results">
</template>

<template for="results">
  <li>Result Two</li>
  <?marker name="results">
</template>

The final DOM has both list items, followed by one <?marker name="results">, ready for more.

Why processing instructions, and not elements?

This was my first question too. Why not use <slot> or another element as the placeholder? The answer is that processing instructions don't affect the DOM structure. So you can use them in places where an element isn't allowed. For example, inside <head> to update the <title>, or inside a <table> to add rows. An earlier version of the proposal used elements, and the design moved to processing instructions as it evolved.

Example 4: Streaming a dashboard from a Node server

Let's put this together with a small Node server. The page shell goes out right away. The summary card and the transaction rows are patched in as their data becomes ready, all in the same HTTP response.

import http from 'node:http';

const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

// Fake data sources with different speeds
async function getSummary() {
  await sleep(300);
  return { volume: '1,204', successRate: '98.2%' };
}

async function* getTransactions() {
  for (const id of ['TX-1001', 'TX-1002', 'TX-1003']) {
    await sleep(500);
    yield id;
  }
}

http.createServer(async (req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' });

  // 1. Send the shell immediately, with named placeholders
  res.write(`<!doctype html>
<html>
<head><title>Dashboard</title></head>
<body>
  <header>My Dashboard</header>
  <section><?start name="summary">Loading summary…<?end></section>
  <table>
    <tbody><?start name="rows"><tr><td>Loading…</td></tr><?end></tbody>
  </table>
  <footer>Footer is here already!</footer>
`);

  // 2. Patch the summary as soon as it is ready
  const summary = await getSummary();
  res.write(`<template for="summary">
    <p>Volume: ${summary.volume} · Success rate: ${summary.successRate}</p>
  </template>`);

  // 3. Each row leaves a fresh marker for the next one
  for await (const id of getTransactions()) {
    res.write(`<template for="rows"><tr><td>${id}</td></tr><?marker name="rows"></template>`);
  }

  // 4. Close the document only after the last template
  res.end('</body></html>');
}).listen(3000);

A few things to notice here:

The footer reaches the user before the slow data, even though it comes after the table in the layout.
The templates are written as direct children of <body>. This matters, as we'll see in the next section.
In a real app, escape any user data before writing it into the HTML.
Streaming only helps if the bytes actually reach the browser in chunks. Check that your compression middleware, proxy or CDN doesn't buffer the whole response.

The Chrome team also has a photo album demo that streams the status and the photos into the page after the initial layout.

Restrictions and gotchas

Out-of-order streaming has a few rules worth knowing before you use it:

Same parent only. For security reasons, a <template for> can only patch placeholders inside its own parent element. A template placed directly in <body> can reach the whole document, including the <head>.
<?end> is optional. Without it, everything from <?start> to the end of the containing element is replaced.
Don't move placeholders mid-stream. If you move a processing instruction after a template has started streaming into it, the new content keeps streaming into the old location.
innerHTML and setHTML() patch in place. When you insert <template for> with these methods, the parser works on an intermediate document fragment. So the template can't touch the existing DOM. The streaming methods in the next section don't have this limitation.
The response is the update window. Patching only works while the server is still writing the document. Once the response ends, further updates need JavaScript or a new navigation.

It's also worth being clear about what this is not. It doesn't replace client-side state. Filters, inline edits and anything else that reacts to user input after the page has loaded still needs JavaScript.

The new HTML insertion and streaming methods

Not every update can come from the initial HTML response. For those cases, we already have many ways to insert HTML with JavaScript: innerHTML, outerHTML, insertAdjacentHTML, createContextualFragment, setHTML and setHTMLUnsafe. Each of them behaves a little differently. Does it overwrite or append? Does it sanitize? Do scripts run? How does it work with Trusted Types? Honestly, I can't answer all of these without checking MDN.

There is also a bigger limitation. All these methods need the full HTML string up front. You can't stream into them, even though streaming is one of the best things about HTML.

The new set of methods fixes both problems, with consistent names and a streaming version of each:

Action	Static	Streaming
Set the contents of the element	`setHTML(html, options)`	`streamHTML(options)`
Replace the whole element	`replaceWithHTML(html, options)`	`streamReplaceWithHTML(options)`
Insert before the element	`beforeHTML(html, options)`	`streamBeforeHTML(options)`
Insert as the first child	`prependHTML(html, options)`	`streamPrependHTML(options)`
Insert as the last child	`appendHTML(html, options)`	`streamAppendHTML(options)`
Insert after the element	`afterHTML(html, options)`	`streamAfterHTML(options)`

Each method also has an Unsafe version, like streamHTMLUnsafe(). The safe versions run the HTML through the Sanitizer API by default. The Unsafe versions skip the sanitizer by default, and accept a runScripts option (default false) if you want scripts to execute. The word "unsafe" is a reminder to think about how much you trust the input, not a sign that you shouldn't use them.

Example 5: Static insertion with a custom sanitizer

const content = document.querySelector('#content');

// Only allow basic formatting
const sanitizer = new Sanitizer({ elements: ['em', 'i', 'b', 'strong'] });

content.setHTML('<p>Hello <strong>world</strong></p>', { sanitizer });

Example 6: Streaming a fetch response into an element

const content = document.querySelector('#content');
const response = await fetch('/partials/transactions.html');

response.body
  .pipeThrough(new TextDecoderStream())
  .pipeTo(content.streamHTMLUnsafe());

Chrome 151 also added a textStream() convenience method, which removes the TextDecoderStream step:

response.textStream().pipeTo(content.streamHTMLUnsafe());

The nice part is that streamHTMLUnsafe() works much like the main parser. It processes <template for> as the templates arrive, and it doesn't use an intermediate fragment. So streamed templates can patch content that already exists in the page.

If you use Trusted Types, streaming needs a new createParserOptions method to inject a sanitizer. The explainer has the details.

Using both together: an SPA-style navigation

This is where things get interesting. The two APIs are separate, but they work really well together. If you stream <template for> elements into the page, each template finds its own placeholder. You don't need a separate DOM reference for every part of the page you want to update.

Here is the idea: load a page shell with named placeholders once. On navigation, fetch the next page as a set of templates and stream them into the bottom of <body>.

Example 7: The page shell

<!doctype html>
<html>
<head>
  <title><?start name="title">Dashboard<?end></title>
</head>
<body>
  <nav>
    <a href="/overview" data-partial>Overview</a>
    <a href="/transactions" data-partial>Transactions</a>
  </nav>

  <main><?start name="main">Loading…<?end></main>

  <script type="module" src="/router.js"></script>
</body>
</html>

Example 8: A partial response from the server

Each template re-emits its own <?start> and <?end>, so the next navigation can replace the range again:

<template for="title"><?start name="title">Transactions<?end></template>

<template for="main">
  <?start name="main">
  <h1>Transactions</h1>
  <table>…</table>
  <?end>
</template>

Example 9: The router

// router.js
document.addEventListener('click', async (event) => {
  const link = event.target.closest('a[data-partial]');
  if (!link) return;

  event.preventDefault();
  history.pushState({}, '', link.href);

  const response = await fetch(`/partials${link.pathname}`);

  // Templates land as direct children of <body>,
  // so they can patch anything in the document, including <head>
  await response.textStream().pipeTo(document.body.streamAppendHTMLUnsafe());
});

Notice what's missing here. There is no client-side templating, no diffing, and no code that knows which element to update. The server decides what changes, and the HTML parser applies it as the bytes arrive. Because the templates are appended to <body>, the same-parent rule lets them update the <title> in the <head> too.

This is a sketch, not a production router. A real one would handle the back button, cancel an in-flight request when the user clicks again, and manage focus for accessibility. The Navigation API is a good fit for the first two.

Using it today with polyfills

The Chrome team has released two polyfills, so you don't have to wait for other browsers:

template-for-polyfill (npm) adds <template for> support. It can't change the browser's HTML parser, so it has some limitations, but it covers the common use cases.
html-setters-polyfill (npm) adds the new insertion and streaming methods. Note that it doesn't actually stream. It buffers the content and applies it when the stream completes. So treat it as a polyfill for the API shape, not for the performance benefit. The safe methods also depend on setHTML() and the Sanitizer API, which Safari doesn't support yet.

The good news is that out-of-order streaming degrades reasonably. Without support, the fallback content between <?start> and <?end> simply stays on the page. So test the experience in Firefox and Safari, and make sure the fallback is something the user can live with.

Browser support

Feature	Chrome / Edge	Firefox	Safari
`<template for>` out-of-order streaming	150 (on by default)	Not supported	Not supported
New insertion and streaming methods	Behind a flag from 148, planned for 155	Not supported	Not supported
`textStream()`	151	Not supported	Not supported

To try the streaming methods today, enable chrome://flags/#enable-experimental-web-platform-features. The for attribute on <template> is already part of the HTML standard, and the new methods are being added to the spec.

What's coming next

The Chrome team is exploring a few more additions:

Client-side includes, like <template for="footer" src="/partials/footer.html">. This one is already behind the experimental flag.
Versioning, so content that hasn't changed isn't overwritten and keeps its state between route changes.
Sanitizing while patching, like <template for="icon" safe>.

Additional Resources

Summary

For a long time, the order of the HTML document decided the order in which users saw things. Declarative Partial Updates change that. With <template for> and processing instructions, the server can send the fast parts of a page first and patch in the slow parts later, without any JavaScript. With the new streaming methods, JavaScript can stream HTML into an existing page too. Put them together and you get SPA-style updates where the server decides what changes and the browser's parser does the work.

For dashboards like the ones I work on, that means the user sees the page layout and the quick numbers right away, while the slow tables fill in as soon as their data is ready.

The Element Changed How I Think About Permissions

Shidhin — Mon, 26 Jan 2026 14:27:58 +0000

I've been building web apps that need location data for years. And honestly? I've always dreaded the geolocation code. Not because the API is complicated—it's actually pretty simple—but because of everything around it. The permission prompts that fire before users even know why they need to share their location. The dead-end when someone clicks "Block" by accident. The awkward dance of trying to explain "please go to your browser settings and reset permissions."

Chrome 144 shipped something that made me genuinely excited: the <geolocation> element. It's a declarative, HTML-first approach to location permissions, and after playing with it, I'm convinced this is how permissions should have worked all along.

Why the Old Way Was Painful

Let's be honest about the traditional navigator.geolocation.getCurrentPosition() API. It works, but it creates problems.

The permission prompt fires whenever your JavaScript decides to call the function. Users see a popup before they've even clicked anything. They don't know why your app wants their location, and the natural instinct is to click "Block." I've watched user testing sessions where people blocked location access reflexively, then complained the app didn't work.

Once blocked, there's no recovery. Your code can't re-trigger the prompt. You're stuck showing a sad "please go to Settings > Privacy > Site Settings > Location" message that 95% of users will never follow.

The browser also has no way to know if the request came from genuine user intent or from some sketchy script trying to harvest location data on page load.

What the `<geolocation>` Element Does Differently

The core idea is simple: instead of JavaScript triggering the permission flow, the user triggers it by clicking a browser-controlled button. The browser renders a styled button with localized text (something like "Use Location" in English, "Standort verwenden" in German). When the user clicks it, they're providing an explicit signal: "Yes, I want to share my location."

Let's see the most basic version:

<geolocation>
  <button onclick="requestLocationFallback()">Share Location</button>
</geolocation>

The content inside the <geolocation> element is fallback for browsers that don't support it yet. In Chrome 144+, the browser replaces this with its own trusted button.

Here's what happens when you wire it up with JavaScript:

const geoElement = document.getElementById("geoElement");

geoElement.addEventListener("location", () => {
  const pos = geoElement.position;
  if (pos) {
    console.log(`Lat: ${pos.coords.latitude}, Lng: ${pos.coords.longitude}`);
  } else if (geoElement.error) {
    console.log(`Error: ${geoElement.error.message}`);
  }
});

The above code is pretty simple to understand. We're listening for the location event on the element, then reading the position attribute directly from it. No callbacks, no separate success/error handlers—just straightforward property access.

The JavaScript Interface

The element exposes a clean interface that's worth understanding:

interface HTMLGeolocationElement extends HTMLElement {
  readonly attribute GeolocationPosition? position;
  readonly attribute GeolocationPositionError? error;
  readonly attribute PermissionState permissionStatus;

  attribute boolean autolocate;
  attribute boolean watch;

  attribute EventHandler onlocation;
  attribute EventHandler onpromptaction;
  attribute EventHandler onpromptdismiss;
}

The permissionStatus property is particularly useful. It tells you whether permission is granted, denied, or prompt—so you can build UI that responds appropriately without guessing.

Different Kinds of Location Tracking

The element supports two modes through attributes.

One-time location is the default. User clicks, location fires once:

<geolocation id="geo">
  <button>Get My Location</button>
</geolocation>

Continuous tracking uses the watch attribute. It's like watchPosition() but declarative:

<geolocation id="tracker" watch>
  <button>Track Me</button>
</geolocation>

Auto-locate is interesting. If you add the autolocate attribute and the user has already granted permission, the element will fetch location automatically on page load:

<geolocation id="geo" autolocate>
  <button>Share Location</button>
</geolocation>

This is great for apps where location is central—like a delivery tracker where returning users have already opted in.

A More Complete Example

Let me show something closer to real-world usage. Here's a location card that displays coordinates:

<div class="location-card">
  <h2>📍 Your Location</h2>
  <div class="coordinates" id="coords">
    Click the button to share your location
  </div>

  <geolocation id="geoElement">
    <button onclick="fallbackLocation()">Share Location (Fallback)</button>
  </geolocation>
</div>

<script>
  const geoElement = document.getElementById("geoElement");
  const coordsDisplay = document.getElementById("coords");

  geoElement.addEventListener("location", () => {
    const pos = geoElement.position;
    if (pos) {
      coordsDisplay.innerHTML = `
        Lat: ${pos.coords.latitude.toFixed(6)}<br>
        Lng: ${pos.coords.longitude.toFixed(6)}
      `;
    } else if (geoElement.error) {
      coordsDisplay.textContent = `Error: ${geoElement.error.message}`;
    }
  });

  // Fallback for unsupported browsers
  function fallbackLocation() {
    navigator.geolocation.getCurrentPosition(
      (pos) => {
        coordsDisplay.innerHTML = `
          Lat: ${pos.coords.latitude.toFixed(6)}<br>
          Lng: ${pos.coords.longitude.toFixed(6)}
        `;
      },
      (err) => {
        coordsDisplay.textContent = `Error: ${err.message}`;
      },
    );
  }
</script>

Notice how the fallback button inside <geolocation> uses the traditional API. Progressive enhancement at its finest—old browsers get the old behavior, new browsers get the better UX.

Security That's Actually Built-In

The element has some clever security measures that I didn't have to think about (which is the point).

Visibility validation: The element must be fully visible in the viewport. No hiding it behind other elements or positioning it off-screen.

Movement detection: If you programmatically move the element, it's temporarily disabled for 500ms. This prevents clickjacking attacks where the element slides under the cursor right before a click.

Style constraints: You can't make the element invisible or heavily disguise it. The browser maintains control over its appearance.

Trusted events only: Only actual user clicks work. Synthetic JavaScript events won't trigger the permission flow.

I used to write custom code to prevent some of these attacks. Now the browser handles it.

Detecting Support

Since this is Chrome-only for now, you need feature detection:

function isGeolocationElementSupported() {
  return "HTMLGeolocationElement" in window;
}

// Or the prototype check
function checkSupport() {
  const testElement = document.createElement("geolocation");
  return testElement instanceof HTMLGeolocationElement;
}

Then you can conditionally render different UI or rely on the fallback content.

Old vs. New: A Quick Comparison

Here's the traditional approach with all its ceremony:

async function requestLocation() {
  try {
    const permission = await navigator.permissions.query({
      name: "geolocation",
    });

    if (permission.state === "denied") {
      showPermissionDeniedUI();
      return;
    }

    navigator.geolocation.getCurrentPosition(handleSuccess, handleError, {
      enableHighAccuracy: true,
    });
  } catch (error) {
    console.error("Permission API not supported");
  }
}

And here's the new approach:

<geolocation id="geo" autolocate>
  <button>Share Location</button>
</geolocation>

<script>
  document.getElementById("geo").addEventListener("location", (e) => {
    const { position, error } = e.target;
    if (position) handleSuccess(position);
    if (error) handleError(error);
  });
</script>

Less code, better UX, built-in security. I'll take that trade every time.

Extra Points

The onpromptdismiss event fires when a user closes the permission prompt without making a choice. This lets you show contextual help instead of leaving them confused.
The lang attribute controls button text localization. The browser handles translation automatically, but you can override it if needed.
Don't use autolocate on first visit. It only works when permission is already granted, but the intent is for returning users—not to spam new visitors.
The element is disabled inside fenced frames for security reasons. If you're building embedded widgets, keep this in mind.

Summary

The <geolocation> element is what I wish we'd had from the start. It turns a JavaScript-triggered, easily-blocked, no-recovery permission flow into a user-initiated, browser-trusted, properly-recoverable experience. Once other browsers adopt this pattern, geolocation in web apps will feel a lot less hostile to users—and a lot less painful for developers. :)

Ship Faster, Debug Smarter: My Take on the New Chrome DevTools AI

Shidhin — Thu, 04 Dec 2025 13:24:56 +0000

I recently had the incredible opportunity to speak at GDG Coimbatore about a shift that is fundamentally changing how we build for the web: the integration of AI directly into Chrome DevTools. We all want to "Ship Faster," but the real challenge has always been how to "Debug Smarter."

If you missed the session, I wanted to write up a quick summary of the key updates. We are moving away from blindly staring at timelines and guessing, to having Gemini help us with styling, network issues, and performance without ever leaving the tab.

Here is the breakdown of what I covered and what you need to know.

The Reality Check: It’s Not About Your Laptop

I started the session with a quote that I think every frontend engineer needs to tape to their monitor:

"Performance isn't about your laptop; it's about theirs."

We often build on high-end machines with fiber internet, but the data tells a completely different story. When you look at Core Web Vitals like LCP (Largest Contentful Paint) and INP (Interaction to Next Paint), there is a massive gap between desktop and phone performance. For example, while desktop pass rates for INP might be decent, mobile users are often struggling with responsiveness.

If we want to fix this, we have to stop debugging in a vacuum. I always recommend using the Throttling settings in DevTools. Don't just test on "No throttling." Try mimicking a "Slow 4G" network and slowing down your CPU by 4x or 6x to really feel what your user feels.

The Performance Panel is Evolving

One of the biggest friction points for us developers has always been context switching—running a Lighthouse audit in one tab and then trying to map those findings to a Performance trace in another.

That’s changing. The standalone "Insights" panel is actually being deprecated. Instead, Lighthouse is moving to insight-based audits directly inside the Performance panel.

Now, when you record a trace, you get "Insights Annotations" baked right in. You can drill down into specific metrics like "LCP by phase" or investigate "Layout shift culprits" immediately. It’s designed so we spend "Less Searching, More Finding."

Enter the AI: A Helper, Not a Replacement

This is the part everyone is excited about. We now have "Ask AI" integrated directly into the Console and other panels. It’s powered by Gemini and designed to help us navigate the parts of web development that usually require opening ten new Google tabs.

Here are the three main ways I’ve been using it:

Fixing Styling Bugs: CSS can be a nightmare. You can now ask the AI to explain a specific element's styles or help you fix layout bugs—like finally figuring out why that one element won't center.
Analyzing Network Requests: Instead of manually parsing headers, you can ask the AI to look at a failed request or explain what a specific response header implies.
Understanding Source Files: Let’s be honest, it’s rare that we wrote 100% of the code on our websites. If you are looking at a minified or unfamiliar script, the AI can explain what that file is actually doing.

How to Enable It (And a Word of Caution)

To get these features, you generally need to head into your DevTools Settings, go to Experiments (or the AI innovations tab in newer versions), and toggle on "AI assistance".

However, I have to end with a "Be Careful" warning.

This is Generative AI. It can be wrong. The tool is experimental and might provide inaccurate info, so you should always validate the AI's suggestions with a new recording. My rule of thumb? Keep your fixes small and reversible. Also, keep in mind that your prompts and inspected page data are sent to Google, so be mindful if you are working with sensitive enterprise data.

It’s an exciting time to be building for the web. If you want to dive deeper, check out the official Chrome docs on AI assistance.

Beyond the Flame Chart: Chrome DevTools' New AI Instantly Pinpoints Your Site's Performance Issues

Shidhin — Wed, 05 Nov 2025 16:23:14 +0000

If you're a web developer, you know the ritual. Your site feels slow, so you open the Chrome DevTools "Performance" panel, hit "record," and brace yourself.

What you get is a powerful, but incredibly dense, "wall of data." A complex, multi-colored flame chart, a dense network waterfall, and a dozen metrics you have to cross-reference. For many, this is where the debugging process stalls. Is the problem a Long Task? A render-blocking resource? A late-discovered LCP element? Interpreting this data correctly is a specialized skill.

But what if you didn't have to? What if you could have an expert performance engineer look over your shoulder, analyze that entire trace in seconds, and just tell you what to fix?

That's exactly what Google is now building directly into Chrome.

Meet Your New "AI Assistance"

Buried within the latest DevTools is a new feature that fundamentally changes this workflow. Instead of manually scrubbing the timeline and deciphering the chart, you can now simply ask for help.

Here's the new workflow:

Run Your Trace: You start by recording a Performance trace just as you always have, capturing the page load or interaction you want to debug.
Open "Debug with AI": Once the trace is complete, you go to the main three-dot menu in the corner of DevTools. There's a new option: "Debug with AI."
Ask the Right Questions: This opens a new "AI assistance" panel directly beside your trace. This panel is context-aware; it "sees" your performance data and provides suggested prompts to get you started, such as:
- "What performance issues exist with my page?"
- "What can I do to reduce the LCP time for this page load?"
- "Why is LCP discovery time important?"
- "How can I prevent layout shifts on this page?"

From "Wall of Data" to Actionable Insights

This is where the magic happens. When you select a prompt like "What performance issues exist with my page?", the AI doesn't give you a generic checklist. It performs a specific analysis of your trace and delivers a prioritized, human-readable report.

Based on a recent trace, here is the kind of powerful, specific feedback this AI can provide:

LCP Render Delay (602 ms): It doesn't not just say "LCP is slow." It identifies the exact problem: "A significant portion of your Largest Contentful Paint (LCP) time is spent in the render delay phase. This indicates that the LCP element was ready to be painted but was blocked by other rendering work." This immediately narrows your focus.
Image Delivery (3.7 MB wasted): It provides a specific, quantifiable problem: "There are unoptimized images on your page, leading to 3.7 MB of wasted data transfer." This is a direct instruction to go and compress your images.
Long Tasks on Main thread: It connects the dots to user interaction metrics. It will identify "several long tasks" and explain that these "can block the browser from responding to user input, negatively affecting Interaction to Next Paint (INP)."
Render-Blocking Resources: It flags the classic bottleneck of "resources that are blocking the page's initial render," another clear-cut problem to solve.

Why This is a Game-Changer

This feature isn't just a gimmick; it represents a fundamental shift in developer tooling.

It Lowers the Barrier to Entry: Junior developers or those who don't specialize in performance can now get the same high-level analysis that would previously have required a seasoned expert.
It Saves Massive Amounts of Time: For senior developers, this AI acts as an incredibly fast assistant. It performs the initial 10-15 minutes of data triage in about two seconds, letting you jump straight to implementing the fix.
It Shifts Your Focus: You can spend less time trying to interpret data and more time solving problems. The tool even encourages this by providing follow-up prompts, like "Tell me more about the LCP render delay," allowing you to drill down interactively.

This is the future of developer tooling: not a replacement for your skills, but a powerful augment that handles the tedious work, letting you focus on what matters—building a faster, better web experience.

Using the fetchLater() API

Shidhin — Thu, 26 Jun 2025 14:22:08 +0000

Using the fetchLater() API: Reliable Beaconing for the Modern Web

Chrome 135, released in April 2025, introduces a powerful new addition to web developers' toolkit: the fetchLater() API. This feature solves a long-standing challenge of reliably sending data to servers when a user leaves a page. In this post, we'll explore what the API offers, why it matters, and how to start using it in your applications today.

The Problem with Page Unload Beaconing

Web developers often need to send critical data back to servers when users leave a page. Analytics services, performance metrics, and user interaction tracking all rely on this capability. Traditionally, developers have used a combination of approaches:

Listening for beforeunload, pagehide, or visibilitychange events
Using navigator.sendBeacon() or fetch() with the keepalive option

However, these methods face reliability issues, especially on mobile devices where events may not fire consistently. Even with the best practices, developers could only achieve around 82% reliability for unload beaconing.

Enter fetchLater()

The fetchLater() API provides a cleaner, more reliable solution. It allows you to queue up requests that will be sent either:

When the page is unloaded (tab closed, navigation away, etc.)
After a specified timeout
When the browser decides it's time to send it

Basic Usage

The API syntax is designed to feel familiar to developers who use fetch():

// Basic usage - will send when page unloads
const result = fetchLater('/analytics-endpoint', {
  method: 'POST',
  body: JSON.stringify({ sessionData: collectSessionData() })
});

// Check if the request has been sent
console.log(result.activated); // false initially, true after sending

Adding a Timeout

You can specify an activateAfter option (in milliseconds) to ensure the request is sent after a certain time, even if the page hasn't been unloaded:

// Send after 1 minute OR when page unloads (whichever comes first)
const oneMinute = 60 * 1000;
fetchLater('/analytics-endpoint', {
  method: 'POST',
  body: JSON.stringify({ sessionData: collectSessionData() }),
  activateAfter: oneMinute
});

Updating Data Before Sending

One of the most powerful features is the ability to update the queued request before it's sent. This is perfect for analytics that accumulate data over time:

const analyticsData = {
  pageViews: 1,
  interactions: []
};

let controller = new AbortController();
let fetchLaterResult;

function queueAnalyticsBeacon() {
  // Abort any existing request
  controller.abort();
  controller = new AbortController();

  // Queue a new request with the latest data
  fetchLaterResult = fetchLater('/analytics-endpoint', {
    method: 'POST',
    body: JSON.stringify(analyticsData),
    signal: controller.signal,
    activateAfter: 60 * 60 * 1000 // 1 hour
  });
}

// Initial queue
queueAnalyticsBeacon();

// Update when user interacts
function recordInteraction(interactionType) {
  analyticsData.interactions.push({
    type: interactionType,
    timestamp: Date.now()
  });

  // Update the queued beacon
  queueAnalyticsBeacon();
}

Real-World Example: Web Vitals Reporting

Here's how you might use fetchLater() to send Core Web Vitals data:

import {onCLS, onINP, onLCP} from 'web-vitals';

const metrics = new Set();
let controller;
let fetchLaterResult;

function updateMetrics(metric) {
  // Clear already-sent metrics if request was activated
  if (fetchLaterResult?.activated) {
    metrics.clear();
  }

  // Add the new/updated metric
  metrics.add(metric);

  // Prepare the data payload
  const body = JSON.stringify(Array.from(metrics));

  // Abort any existing fetchLater() and queue a new one
  controller?.abort();
  controller = new AbortController();
  fetchLaterResult = fetchLater('/vitals-analytics', {
    method: 'POST',
    body,
    signal: controller.signal,
    activateAfter: 60 * 60 * 1000 // 1 hour timeout for regular sending
  });
}

// Register the web vitals callbacks
onCLS(updateMetrics);
onINP(updateMetrics);
onLCP(updateMetrics);

Error Handling

It's good practice to handle potential errors, especially quota limitations:

try {
  fetchLater('/analytics-endpoint', {
    method: 'POST',
    body: JSON.stringify(analyticsData)
  });
} catch (e) {
  if (e instanceof QuotaExceededError) {
    // Handle quota exceeded
    console.warn('Analytics beacon quota exceeded');
  } else {
    // Handle other errors
    console.error('Error queueing analytics beacon:', e);
  }
}

Understanding Quotas and Limitations

To prevent abuse, browsers enforce limits on fetchLater() usage:

Total bandwidth for a top-level document is capped at 640KB
Each reporting origin is limited to 64KB
All pending requests are flushed when a document enters the browser's back/forward cache

Browser Support

As of May 2025:

Chrome: Supported since version 135 (April 2025)
Firefox: Under consideration
Safari: Not yet implemented

For browsers that don't support fetchLater(), you can implement a fallback using the traditional approach:

function sendAnalytics(data) {
  if (typeof window.fetchLater === 'function') {
    try {
      fetchLater('/analytics', {
        method: 'POST',
        body: JSON.stringify(data)
      });
      return true;
    } catch (e) {
      console.warn('fetchLater failed, falling back to sendBeacon', e);
    }
  }

  // Fallback to sendBeacon
  return navigator.sendBeacon('/analytics', JSON.stringify(data));
}

// Register traditional unload handlers as fallback
window.addEventListener('pagehide', () => {
  sendAnalytics(analyticsData);
});

window.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    sendAnalytics(analyticsData);
  }
});

Demo

I have built a simple Demo page for the fetchLater API here: https://www.undefinednull.com/fetch-later-demo/

Conclusion

The fetchLater() API represents a significant improvement for web developers who need reliable beaconing. It simplifies code, improves reliability, and provides a more declarative approach to handling page unload data transmission.

By adopting this API (with appropriate fallbacks), developers can ensure their analytics, metrics, and other critical data have the best chance of making it back to servers, regardless of how users exit their web applications.

For more details, check the official documentation and consider experimenting with the API in your applications today.

Harnessing AI to Debug and Optimize Web Performance: A Guide to Chrome DevTools AI Assistance

Shidhin — Mon, 28 Apr 2025 16:21:09 +0000

In the ever-evolving landscape of web development, staying on top of performance issues and debugging challenges can be time-consuming and complex. Google Chrome has introduced an exciting experimental feature in DevTools that can transform how developers approach these tasks: AI assistance. This powerful addition brings the capabilities of Google's Gemini AI directly into your development workflow, helping you understand, debug, and optimize your web applications more efficiently.

What is Chrome DevTools AI Assistance?

AI assistance in Chrome DevTools is an experimental feature available in Chrome Canary (version 131 and later) that integrates Gemini AI directly into your browser's development environment. Instead of spending hours deciphering cryptic error messages or manually analyzing performance bottlenecks, you can now chat with an AI assistant that has context about your webpage and can provide targeted insights and solutions.

The AI assistant can help with various aspects of web development:

Styling analysis: Understand why elements are displayed in specific ways and how they interact with each other
Network request debugging: Analyze the origin, timing, and potential issues with network requests
Source code examination: Get insights into the purpose and functionality of loaded files
Performance optimization: Identify and address performance bottlenecks in your application

Getting Started with AI Assistance

Requirements

Before diving in, ensure you meet these requirements:

You're at least 18 years old and in a supported location
You're using the latest version of Chrome (Canary for full feature access)
You're signed into Chrome with your Google account
You have English (US) selected in DevTools settings
You've enabled AI Innovations in DevTools settings

Opening the AI Assistance Panel

There are several ways to access the AI assistance panel:

From specific panels: Right-click on an element, network request, or performance activity and select "Ask AI"
Using the Command Menu: Press Ctrl+Shift+P (or Cmd+Shift+P on Mac), type "AI", and select "Show AI assistance"
From the More Tools menu: Click on More options (⋮) > More tools > AI assistance

How to Use AI Assistance for Debugging and Optimization

Let's explore how to leverage this powerful feature for different aspects of web development:

Debugging CSS and Styling Issues

When confronting styling challenges, AI assistance can be a game-changer:

Open your webpage in Chrome
Right-click on the problematic element in the Elements panel
Select "Ask AI" from the context menu
Ask questions like:
- "Why is this element overlapping with the header?"
- "How can I fix the responsive behavior of this component?"
- "Why isn't my flexbox layout working as expected?"

The AI will analyze the context, including CSS inheritance, conflicting styles, and layout interactions, providing explanations and potential solutions.

Optimizing Network Performance

For network-related issues:

Navigate to the Network panel in DevTools
Record network activity while loading your page
Right-click on a slow or problematic request
Select "Ask AI"
Ask specific questions like:
- "Why is this request taking so long?"
- "How can I optimize this API call?"
- "What's causing these multiple similar requests?"

The AI will analyze request headers, timing, and the request initiator chain to give you insights and optimization suggestions.

Analyzing Runtime Performance

Performance bottlenecks can be particularly challenging to identify. Here's how AI assistance can help:

Open the Performance panel
Record a performance profile while interacting with your site
Right-click on activities that appear to be problematic
Select "Ask AI"
Ask questions like:
- "What's causing this long task?"
- "How can I reduce the time spent on JavaScript execution?"
- "Why are there so many layout recalculations?"

The AI analyzes the call tree and timings to identify optimization opportunities and explain the root causes of performance issues.

Examining Source Code

Understanding unfamiliar code is much easier with AI assistance:

Navigate to the Sources panel
Open the file you want to understand
Right-click on specific sections of code
Ask the AI questions like:
- "What is this function doing?"
- "How does this code affect the page rendering?"
- "What could be improved in this code segment?"

Best Practices for Effective AI Assistance

To get the most out of Chrome DevTools AI assistance, consider these tips:

1. Ask Specific Questions

The more specific your questions, the more targeted and useful the AI's responses will be. Instead of asking "Why is my page slow?" try "What's causing the long task at the 2-second mark in my performance profile?"

2. Provide Context

Ensure you've selected the relevant element, request, or performance activity before asking questions. The AI uses this context to provide accurate answers.

3. Follow Up with Clarifications

If the initial answer doesn't fully address your question, ask follow-up questions to drill deeper. The AI maintains conversation history and builds on previous interactions.

4. Combine AI Insights with Your Expertise

AI assistance is a powerful tool, but it works best when combined with your development knowledge. Use AI suggestions as a starting point, then apply your understanding of your specific codebase and requirements.

5. Provide Feedback

Since this is an experimental feature, your feedback is valuable. Use the thumbs up/down buttons to rate answers and help improve the system.

Real-World Optimization Scenarios

Let's explore some practical scenarios where AI assistance can significantly streamline your workflow in the future:

Scenario 1: Fixing Layout Shifts

Cumulative Layout Shift (CLS) issues can be frustrating for users. AI assistance can help pinpoint the cause:

Record a performance profile capturing the layout shift
Right-click on the relevant layout recalculation activity
Ask: "What's causing this layout shift and how can I fix it?"

The AI might identify that images without defined dimensions are causing the shift and suggest adding width and height attributes to prevent the browser from recalculating layout during image loading.

Scenario 2: Reducing JavaScript Bundle Size

If your page load time is slow due to large JavaScript bundles:

Use the Coverage panel to identify unused JavaScript
Right-click on a specific JavaScript file with low usage
Ask: "How can I optimize this JavaScript to reduce bundle size?"

The AI might suggest techniques like code splitting, tree shaking, or lazy loading specific components.

Scenario 3: Optimizing Render Blocking Resources

For pages with render-blocking resources:

In the Network panel, right-click on a render-blocking CSS or JavaScript file
Ask: "How can I prevent this resource from blocking rendering?"

The AI could recommend using async or defer attributes for scripts, inlining critical CSS, or using resource hints like preload and preconnect.

Limitations and Considerations

While the AI assistance feature is powerful, it's important to be aware of its limitations:

Experimental Status: As an experimental feature, it may not always provide perfect answers and is subject to change.
Data Usage: The feature sends contextual data about your webpage to Google's servers for analysis. Sensitive information in headers is automatically redacted, but be cautious with proprietary code.
Potential Inaccuracies: Like all AI systems, it may occasionally generate incorrect or misleading information. Always verify critical suggestions before implementation.
Language Limitations: Currently, the feature is optimized for English (US) and may not work as effectively in other languages.

Conclusion

Chrome DevTools AI assistance represents a significant leap forward in how developers can approach debugging and performance optimization. By bringing AI capabilities directly into the browser development environment, it helps bridge the gap between identifying problems and implementing solutions.

As web applications grow increasingly complex, tools that can analyze and explain intricate interactions become invaluable. AI assistance in Chrome DevTools doesn't replace developer expertise, but it does augment it in powerful ways, helping you work more efficiently and make informed decisions about optimizing your web applications.

While still experimental, this feature offers a glimpse into the future of development tools where AI partners with developers to solve challenges and create better web experiences. As you incorporate AI assistance into your workflow, remember to provide feedback to help improve the system and shape the future of AI-powered development tools.

Start exploring this powerful feature in Chrome Canary today, and experience a new dimension of productivity in your web development process.

Inspecting Speculation rules with Chrome Devtools

Shidhin — Thu, 20 Mar 2025 16:29:40 +0000

[WIP]

Come back later ...

Faster navigations with Speculations rules api

Shidhin — Mon, 10 Mar 2025 17:49:40 +0000

Shidhin

Mar 9 '25

Speculation Rules API: A New Era of Faster Web Browsing

#speculationrulesapi #instantnavigation #prefetchprerender #webperf

10 min read

Speculation Rules API: A New Era of Faster Web Browsing

Shidhin — Sun, 09 Mar 2025 13:22:19 +0000

Imagine using the internet and seeing web pages load immediately, almost like magic. No more waiting or loading screens. This exciting idea is now possible thanks to a new feature called speculation rules. In this blog, we'll learn what speculation rules are, how they work, and see some practical examples you can use in your own projects.

What is Speculation rules API

The Speculation rules API is a new web api to improve the navigation speed in multi-page applications. It basically prefetch or prerender the desired pages upon user-interaction or after pageload. By doing prefetching or prerendering, the navigation speed between multiple pages will be significantly reduced.

Speculation rules give your browser hints about what pages to load next. Imagine hovering over a link, and the browser already starts loading that page in the background, even before you click. This dramatically speeds up browsing and removes frustrating waiting times.

How does it work?

With speculation rules, browsers can to predict (speculate) which page you're likely to visit next to enhance your experience. This prediction is based on factors like where your mouse is hovering or the links present on the current page. By anticipating your next move, the browser can load pages more efficiently, reducing wait times.

Prefetching vs. Prerendering

There are two primary methods browsers use to prepare the next page:

Prefetching: This approach involves the browser downloading the basic blueprint of the page—the HTML content—but not rendering it. It's a lighter method that uses fewer resources, ensuring that when you navigate to the page, it loads faster than if it hadn't been prefetched.
Prerendering: In this method, the browser goes a step further by downloading all resources, such as images and fonts, and fully rendering the page in a hidden tab. This means that when you click the link, the page appears instantly, providing a seamless experience. However, prerendering consumes more resources compared to prefetching.

Setting the Rules with JSON

Website developers can guide browsers on which pages to prefetch or prerender using the Speculation Rules API, defined in JSON format. This code can be embedded directly into the webpage or delivered via HTTP headers from the web server. The JSON structure specifies the URLs to target and the conditions under which the browser should act. For instance, developers can set the "eagerness" parameter to control how proactively the browser should prefetch or prerender pages:

immediate: The browser starts prefetching or prerendering as soon as it encounters the rule.
eager: Similar to immediate, but may be adjusted in future implementations.
moderate: The browser waits until there's a reasonable indication, such as a brief hover over a link, before acting.
conservative: The browser waits until you actually click or tap on a link before initiating the prefetch or prerender.

By fine-tuning these settings, developers can optimize resource usage and enhance user experience.

Example of Speculation Rules in JSON

Here's how developers can define speculation rules using JSON:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "urls": ["next.html", "next2.html"],
      "requires": ["anonymous-client-ip-when-cross-origin"],
      "referrer_policy": "no-referrer"
    }
  ]
}
</script>

In this example:

The prerender rule instructs the browser to prerender any same-origin link on the page upon hover, with a moderate eagerness setting.
The prefetch rule tells the browser to prefetch "next.html" and "next2.html", requires anonymization for cross-origin requests, and sets the referrer policy to "no-referrer".

By implementing these rules, developers can significantly improve page load times and provide a smoother browsing experience for users.

What about the existing `<link preload>` and `<link prefetch>` and

<link prerender>

The Speculation Rules API introduces a more advanced and flexible approach to resource loading, enhancing the capabilities of traditional methods like <link rel="preload">, <link rel="prefetch">, and <link rel="prerender">. Here's how it improves upon these older mechanisms:

<link rel="preload">

Purpose: <link rel="preload"> is utilized to load resources essential for the current page, such as fonts, images, and scripts, ensuring they're available when needed.
Limitation: It focuses solely on the current page's resources and doesn't anticipate the user's next navigation.
Speculation Rules Advantage: The Speculation Rules API extends this concept by allowing developers to specify resources for subsequent pages the user is likely to visit, enhancing the overall navigation experience.

<link rel="prefetch">

Functionality: The traditional <link rel="prefetch"> hint allows browsers to prefetch resources to the HTTP cache, potentially improving load times for future navigations.
Challenges:
- Cache-Control Limitations: Prefetched resources can be blocked by Cache-Control headers, limiting their effectiveness.
- Cross-Site Restrictions: Cross-site prefetching is often restricted due to security and privacy concerns.
Speculation Rules Enhancement:
- In-Memory Caching: Speculation Rules utilize a per-document in-memory cache, ensuring prefetched documents are processed similarly to regular navigations but aren't rendered until needed.
- Cross-Site Prefetching: This API supports cross-site prefetching, offering more flexibility compared to the older <link rel="prefetch"> method.
- Bypassing Cache-Control: Speculation Rules are not hindered by Cache-Control headers, making them more reliable for prefetching purposes.

<link rel="prerender">

Background: The legacy <link rel="prerender"> was deprecated in favor of NoState Prefetch, which fetched resources without fully rendering the page or executing JavaScript.
Speculation Rules Superiority:
- Full Prerendering: The Speculation Rules API enables developers to trigger complete prerendering of pages, including the execution of JavaScript and loading of subresources.
- Enhanced Performance: This comprehensive prerendering ensures that when a user navigates to the prerendered page, it loads instantly, providing a seamless experience.

Speculation Rules API Overview

Target Audience: The API is particularly beneficial for multi-page applications (MPAs), allowing developers to specify which documents should be prefetched or prerendered based on user behavior and site structure.
Expressive Syntax: It offers a more configurable and expressive syntax, enabling precise control over resource loading strategies to optimize performance.

By leveraging the Speculation Rules API, developers can implement more efficient and user-centric resource loading strategies, surpassing the capabilities of traditional methods like <link rel="preload">, <link rel="prefetch">, and <link rel="prerender">.

Implementation

The Speculation Rules API offers a structured approach to enhance web performance by enabling browsers to anticipate and load resources for pages users are likely to visit next. This proactive loading can significantly reduce perceived load times and improve user experience. Here's how to implement speculation rules in your HTML:

1. Embedding a <script type="speculationrules"> Element

To define speculation rules, you embed a <script> element with the attribute type="speculationrules" directly within your HTML document. This script contains JSON-formatted rules that instruct the browser on prefetching or prerendering behaviors.

Example:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Speculation Rules Example</title>
  <script type="speculationrules">
    {
      "prerender": [
        {
          "source": "list",
          "urls": ["/next-page.html"]
        }
      ]
    }
  </script>
</head>
<body>
  <h1>Welcome to My Website</h1>
  <a href="/next-page.html">Go to Next Page</a>
</body>
</html>

In this example, the browser is instructed to prerender /next-page.html, preparing it in the background so that navigation to it is instantaneous.

2. Defining Rules in JSON Format

Within the <script type="speculationrules"> element, rules are defined using JSON. Each rule specifies the action (prefetch or prerender), the source of the URLs, and the list of URLs to be processed.

Example:

{
  "prefetch": [
    {
      "source": "list",
      "urls": ["/about.html", "/contact.html"]
    }
  ],
  "prerender": [
    {
      "source": "list",
      "urls": ["/dashboard.html"]
    }
  ]
}

Here, the browser is instructed to prefetch /about.html and /contact.html, and to prerender /dashboard.html.

3. Specifying Pages to Prefetch or Prerender

The urls array within each rule specifies which pages the browser should prefetch or prerender. These URLs should be chosen based on user navigation patterns to optimize performance effectively.

4. Setting Conditions for Triggering Prefetching or Prerendering

Developers can control when prefetching or prerendering occurs by setting the eagerness property within each rule. This property determines how proactively the browser should load the specified resources.

Eagerness Levels:

immediate: The browser starts prefetching or prerendering as soon as it processes the rule.
eager: Similar to immediate, but allows the browser some discretion based on resource availability.
moderate: The browser waits until there's a reasonable indication of user interest, such as hovering over a link.
conservative: The browser waits until the user initiates navigation, such as clicking a link.

Example with Eagerness Setting:

<script type="speculationrules">
  {
    "prerender": [
      {
        "source": "list",
        "urls": ["/promo.html"],
        "eagerness": "moderate"
      }
    ]
  }
</script>

In this case, the browser will prerender /promo.html when it detects moderate user interest, such as a brief hover over a related link.

Additional Considerations:

Source Specification: The source property indicates how the URLs are determined. For instance, "source": "list" means the URLs are explicitly listed, while other methods can derive URLs based on patterns or user behavior.
Browser Support: As of now, the Speculation Rules API is supported in Chromium-based browsers like Chrome, Edge, and Opera. It's advisable to implement fallback mechanisms for browsers that do not support this API.

By thoughtfully implementing the Speculation Rules API, developers can significantly enhance the responsiveness of their websites, leading to a smoother and more engaging user experience.

What about the Browser Support

As of now, the Speculation Rules API is supported in Chromium-based browsers, including Chrome, Edge, and Opera. However, it is not yet available in Firefox or Safari. Despite this limited support, implementing the Speculation Rules API is safe because browsers that do not recognize it will simply ignore the <script type="speculationrules"> element without causing any issues.

Supported Browsers: Chrome, Edge, Opera (Chromium-based browsers). Unsupported Browsers: Firefox, Safari.
Market Coverage: Chromium-based browsers account for approximately 70% of the global browser market.
Backward Compatibility: Non-supporting browsers will ignore the Speculation Rules API without any adverse effects.

Debugging in Chrome browser

To debug Speculation Rules in Chrome, use Chrome DevTools.

Here’s how:

Open DevTools: Open Chrome DevTools before loading the page containing the speculation rules. This ensures speculations are captured correctly.
Navigate to the Speculative Loads Tab: Go to the Application panel, then Background Services, and select the Speculative loads tab. Then choose the Speculations pane. If nothing appears, ensure you're on the correct page and DevTools was loaded before navigation; reload the page if necessary.
Inspect Speculations: In the Speculations tab, you can view the URLs being prefetched or prerendered. Click on a line to see details if a page fails to prerender, including reasons for failure, such as incompatible JavaScript APIs.
Check Speculative Loading Status: To confirm whether a page was prerendered or prefetched, inspect the Application panel to see the Speculative loading status for the current page.
Monitor Network Activity: The Network track in the Performance Panel shows network activity related to prerendered resources without switching DevTools context.
Sort by Status: Sort the Speculations pane by the Status column to identify pages that are prerendering as you hover over them. Clicking on them will show a quicker Largest Contentful Paint (LCP) time compared to non-prerendered pages.
Examine Chrome's Address Bar Predictions: To view Chrome's predictions for URLs, go to the chrome://predictors page. Green lines indicate sufficient confidence to trigger prerendering.
Use the Console to Test Prerendering: After a page is activated, open DevTools and type performance.getEntriesByType('navigation').activationStart in the console. A non-zero value indicates the page was prerendered.
Simulate Different Network Conditions: Use the throttling options in the Network tab to simulate different network speeds and see how speculation rules perform under various conditions.
Feature Detection Use feature detection code to determine if the browser supports speculation rules. If the browser doesn't support speculation rules, implement older technologies such as <link rel="prefetch">.

Practical Applications of the Speculation Rules API

E-commerce platforms greatly benefit from the Speculation Rules API. On these platforms, users regularly browse through various product pages, category listings, and search results. By applying prefetching or prerendering to these pages, the shopping experience becomes smoother and quicker. This immediate responsiveness not only improves customer satisfaction but can also lead to higher conversion rates, as shoppers are less likely to abandon the site due to slow loading times.

Blogs featuring multiple articles or content spread across multiple pages can similarly enhance user experience using this API. By prefetching or prerendering subsequent articles or pagination pages, readers experience seamless navigation. This approach encourages users to explore more content effortlessly, significantly improving their engagement and satisfaction.

Advantages of Implementing Speculation Rules API

A key advantage of using the Speculation Rules API is significantly reducing the perceived load times by preloading resources in advance. Prefetching resources or fully prerendering pages enables nearly instantaneous page transitions when navigating through the website, creating a smoother, more responsive browsing experience. Such improvements are crucial for retaining user interest and increasing their satisfaction.

Enhanced performance resulting from prefetching and prerendering also has positive effects on user engagement metrics, such as reduced bounce rates and prolonged sessions. The smoother and more responsive user experience encourages visitors to explore additional content, increasing the likelihood of conversions and repeat visits. Additionally, these improvements in page performance can positively impact search engine optimization (SEO), helping websites rank better in search results.

The Speculation Rules API also ensures efficient use of resources by allowing browsers to initiate prefetching only when sufficient resources, such as memory and network bandwidth, are available. Developers can fine-tune when resources are preloaded using eagerness settings (immediate, eager, moderate, conservative), ensuring effective utilization without wasteful preloading.

Moreover, improvements in caching mechanisms mean that prefetched or prerendered resources are stored efficiently and reused when required. Even if speculated pages are not immediately accessed, these resources provide future benefits, further improving overall site performance and responsiveness.

Key Considerations for Implementing Speculation Rules API

When implementing the Speculation Rules API, it's important to understand both the API and your website's specific needs. Ensure you avoid applying rules to sensitive routes such as logout, language-switching, or shopping cart actions to prevent unintended consequences.

Regularly monitoring and adjusting your preloading rules is crucial. Analyze user behavior using tools like Google Analytics and Real User Monitoring (RUM) to identify optimal preloading strategies. Adjust rules based on insights to balance effective resource use with performance gains.

Lastly, be aware of the potential increased server load due to prefetching and prerendering. This can impact server resources, bandwidth, and costs. Use caching wisely and update client-side scripts carefully, particularly for personalized content, to ensure optimal and efficient performance.

Summary

In summary, the Speculation Rules API is a powerful tool for enhancing web performance, primarily in multi-page applications (MPAs), by proactively prefetching or prerendering potential next pages. It allows the browser to start loading a subsequent page before a user even clicks a link, making navigation feel nearly instantaneous. By strategically implementing this API, developers can significantly improve user experience and potentially boost Core Web Vitals

[Boost]

Shidhin — Sun, 09 Mar 2025 13:08:02 +0000

Shidhin

Dec 22 '24

Live core web vitals (local metrics) in browser devtools

#webdev #devtools #corewebvitals #inp

5 min read

Core Web Vitals

Shidhin — Sun, 09 Mar 2025 13:06:33 +0000

Shidhin

Dec 27 '24

Performance Audit: Analyzing Namshi’s Mobile Website with Live Core Web Vitals

#webdev #devtools #corewebvitals #performance

2 min read

Performance Audit: Analyzing Namshi’s Mobile Website with Live Core Web Vitals

Shidhin — Fri, 27 Dec 2024 13:13:40 +0000

If you’re new to Live Core Web Vitals, check out my previous post:

Shidhin

Dec 22 '24

Live core web vitals (local metrics) in browser devtools

#webdev #devtools #corewebvitals #inp

5 min read

What Are We Going to Do?

Namshi is one of the largest e-commerce websites in the UAE. Having worked at Namshi before, I was curious to test the Core Web Vitals scores of their mobile website and evaluate the user experience.

I started with their most visited webpage:

Namshi: Women's Fashion

Using a high-speed Wi-Fi network and an M3 Pro MacBook, I conducted the test without any network or CPU throttling. The LCP (Largest Contentful Paint) score was 2.84 seconds, indicating room for improvement. The LCP metric primarily points to the banner image in the carousel.

Suggestions for improvements:

Use smaller placeholder images for banners.
Preload banner images(using link preload directive).

As I interacted with the page, the other metrics appeared satisfactory.

Finding slowness

Namshi’s website heavily relies on modal components for features like Sort, Filter, and Search. While most modals opened and closed quickly, I noticed occasional slowness patterns. The INP (Interaction to Next Paint) score fluctuated between 60-100ms, which is generally acceptable.

However, I discovered main-thread blocking code when toggling the “New Arrivals” modal and attempting to close it. This directly impacted the INP score. You can see the behavior in the video below:

A Worse Version?

Yes, I found an even worse scenario where the INP score turned completely RED.

This occurred when I opened the “Filter” modal, applied some filters, and then clicked “Reset Filters”. The page froze momentarily, resulting in a poor user experience.

Suggestions for improvements:

Avoid blocking the main thread during user interactions, especially while applying filters.
Use Web Workers for computationally intensive tasks

Another Observation

By recording a Performance Profile, the issue was clearly visible in the flame chart. This method is invaluable for identifying and addressing performance bottlenecks.

DEV Community: Shidhin

Declarative Partial Updates: Streaming HTML Where It Matters Most

The problem: HTML is delivered in order

What are Declarative Partial Updates?

Out-of-order streaming with <template for>

Example 1: A simple marker

Example 2: Fallback content with start and end

Example 3: Appending items one by one

Why processing instructions, and not elements?

Example 4: Streaming a dashboard from a Node server

Restrictions and gotchas

The new HTML insertion and streaming methods

Example 5: Static insertion with a custom sanitizer

Example 6: Streaming a fetch response into an element

Using both together: an SPA-style navigation

Example 7: The page shell

Example 8: A partial response from the server

Example 9: The router

Using it today with polyfills

Browser support

What's coming next

Additional Resources

Summary

The Element Changed How I Think About Permissions

Why the Old Way Was Painful

What the <geolocation> Element Does Differently

The JavaScript Interface

Different Kinds of Location Tracking

A More Complete Example

Security That's Actually Built-In

Detecting Support

Old vs. New: A Quick Comparison

Extra Points

Summary

Ship Faster, Debug Smarter: My Take on the New Chrome DevTools AI

The Reality Check: It’s Not About Your Laptop

The Performance Panel is Evolving

Enter the AI: A Helper, Not a Replacement

How to Enable It (And a Word of Caution)

Beyond the Flame Chart: Chrome DevTools' New AI Instantly Pinpoints Your Site's Performance Issues

Meet Your New "AI Assistance"

From "Wall of Data" to Actionable Insights

Why This is a Game-Changer

Using the fetchLater() API

Using the fetchLater() API: Reliable Beaconing for the Modern Web

The Problem with Page Unload Beaconing

Enter fetchLater()

Basic Usage

Adding a Timeout

Updating Data Before Sending

Real-World Example: Web Vitals Reporting

Error Handling

Understanding Quotas and Limitations

Browser Support

Demo

Conclusion

Harnessing AI to Debug and Optimize Web Performance: A Guide to Chrome DevTools AI Assistance

What is Chrome DevTools AI Assistance?

Getting Started with AI Assistance

Requirements

Opening the AI Assistance Panel

How to Use AI Assistance for Debugging and Optimization

Debugging CSS and Styling Issues

Optimizing Network Performance

Analyzing Runtime Performance

Examining Source Code

Best Practices for Effective AI Assistance

1. Ask Specific Questions

2. Provide Context

3. Follow Up with Clarifications

4. Combine AI Insights with Your Expertise

5. Provide Feedback

Real-World Optimization Scenarios

Scenario 1: Fixing Layout Shifts

Scenario 2: Reducing JavaScript Bundle Size

Scenario 3: Optimizing Render Blocking Resources

Limitations and Considerations

Conclusion

Inspecting Speculation rules with Chrome Devtools

Faster navigations with Speculations rules api

Out-of-order streaming with `<template for>`

What the `<geolocation>` Element Does Differently

What about the existing `<link preload>` and `<link prefetch>` and