DEV Community: Shidhin

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

Speculation Rules API: A New Era of Faster Web Browsing

Shidhin ・ Mar 9 '25

#speculationrulesapi #instantnavigation #prefetchprerender #webperf

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

Live core web vitals (local metrics) in browser devtools

Shidhin ・ Dec 22 '24

#webdev #devtools #corewebvitals #inp

Core Web Vitals

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

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

Shidhin ・ Dec 27 '24

#webdev #devtools #corewebvitals #performance

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:

Live core web vitals (local metrics) in browser devtools

Shidhin ・ Dec 22 '24

#webdev #devtools #corewebvitals #inp

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.

Live core web vitals (local metrics) in browser devtools

Shidhin — Sun, 22 Dec 2024 17:43:03 +0000

Local metrics are the new addition to the performance panel in Chrome DevTools. They provide real-time data on the performance of your website, enabling you to monitor and analyze the website's performance metrics as you interact with it. This feature is really useful for developers who want to understand how their website performs in real-world scenarios and identify performance bottlenecks quickly.

Local metrics also known as live metrics, include the following key performance indicators:

LCP (Largest Contentful Paint)
CLS (Cumulative Layout Shift)
INP (Interaction to next paint)

What's the advantage of using local metrics?

Local metrics provide real-time data on the website's performance, allowing you to monitor the performance metrics as you interact with the website. This avoids the need to deploy the website to a staging environment or use third-party tools to analyze the performance metrics. This also helps to catch performance issues early in the development process.

Let's understand each section in the local metrics panel

LCP (Largest Contentful Paint)

The Largest Contentful Paint (LCP) metric measures the time taken for the largest content element to render on the screen. It is an important metric as it indicates when the main content of the page is visible to the user. A good LCP score is usually less than 2.5 seconds.

The LCP panel shows the following data:

LCP value: The time taken for the largest content element to render on the screen.
Element: The largest content element on the page. Here in the example, it is an image.

CLS (Cumulative Layout Shift)

The Cumulative Layout Shift (CLS) metric measures the visual stability of the page. It quantifies how much the elements on the page shift around during the loading process. A good CLS score is usually less than 0.1.

The CLS panel shows the following data:

CLS value: The cumulative layout shift value.
Worst shifts: The elements that caused the maximum layout shift.

You can click on the "Shifts" link to see the detailed information about the layout shifts on the page.
These values are "Live" and will update as you interact with the page.

INP (Interaction to next paint)

The INP is a new metric introduced in Chrome DevTools that measures the time taken for the first interaction to the next paint. It helps you understand how quickly the page responds to user interactions. A good INP score is usually less than 100 milliseconds. This helps to identify slow interactions and optimize them for better performance.

You can see in the previous images that the INP value is blank. This is because the INP value is calcualted only when there is an interaction on the page. You can interact with the page and see the INP value update in real-time.

In the above screenshot, the INP value got updated as soon as I clicked on the search field. The INP metric shows the value in milliseconds and the element that was interacted with. Here the interaction was a click event, hence the event type is "pointer".

The green color indicates that the INP score so far is good. If the score is bad, it will be highlighted in red. There is also orange color which indicates that the score is moderate.

INP value is also live and will update as you interact with the page. Here you can see that the INP tag is pointing to the largest value.

Field data

Field data is another important section in the local metrics panel. It provides real-world data on the performance of your website. Field data is collected from real users who visit your website. This data helps you understand how your website performs in the real world and identify performance bottlenecks that need to be addressed.

When this is enabled, you can see the field data for the performance metrics like LCP, CLS, and INP. This helps you compare the lab data with the field data and identify any discrepancies.

Here you can see that the field data reports the 75th percentile value for the performance metrics. In this example, the values are collected for "Desktop" users. However, you can change the device type to "Mobile" to see the field data for mobile users.

Environment Settings

Environment settings allow you to simulate different network conditions and CPU throttling. This helps you understand how your website performs under different network conditions and device capabilities. You can choose between different network profiles like "Offline", "3G", "Slow 4G", and "Fast 4G". You can also throttle the CPU to simulate different device capabilities.

Why this is important?

Most of the time, we test the website in a controlled environment with a stable network connection and high-end devices. However, in the real world, users may have different network conditions and devices. By simulating different network conditions and CPU throttling, you can understand how your website performs in the real world and optimize it for better performance.

Finding slow interactions

First use the INP to flag the interactions that are slow. This will be highlighted in either red or orange. Once you identify the slow interactions, use the record feature in the performance panel to record the interactions and analyze the performance bottlenecks.

While recording, you repeat the same interactions that were slow and reported by INP. Now, you can pin-point the exact performance bottlenecks that are causing the slow interactions. You can analyze the performance bottlenecks using the flame chart, network panel, and other performance tools in Chrome DevTools.

Let's see what the recording unfolds:

You can also click on the "INP by phase" link to see the breakdown of the INP metric. This will help you understand which phase of the interaction is slow and needs optimization. With this, you can spot if the interaction is slow due to JavaScript execution, rendering, or any other performance bottlenecks.

A Final look at the Flame chart

Here when expanding the flame chart, you can see the detailed breakdown of the performance bottlenecks. You can see the time taken for each task and identify the bottlenecks that are causing the slow interactions. This will help you optimize the performance bottlenecks and improve the overall performance of the website.

Summary

Local metrics are a powerful tool that provides real-time data on the performance of your website. It helps you monitor the performance metrics as you interact with the website and identify performance bottlenecks quickly. By using local metrics, you can optimize the performance of your website and provide a better user experience to your visitors.

DEV Community: Shidhin

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

Speculation Rules API: A New Era of Faster Web Browsing

Shidhin ・ Mar 9 '25

Speculation Rules API: A New Era of Faster Web Browsing

What is Speculation rules API

How does it work?

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

Implementation

What about the Browser Support

Debugging in Chrome browser

Practical Applications of the Speculation Rules API

Advantages of Implementing Speculation Rules API

Key Considerations for Implementing Speculation Rules API

Summary

[Boost]

Live core web vitals (local metrics) in browser devtools

Shidhin ・ Dec 22 '24

Core Web Vitals

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

Shidhin ・ Dec 27 '24

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

Live core web vitals (local metrics) in browser devtools

Shidhin ・ Dec 22 '24

What the `<geolocation>` Element Does Differently

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