(by Minh Nguyen – Senior FE Software Engineer)
Look, we’ve all been there: your local build is flying, the Lighthouse score is green, and then the bug reports start rolling in from users on actual mobile devices.
Minh Nguyen, our Senior FE Software Engineer, recently called out the hard truth: most of us are living in a state of performance denial. Let’s be real: If you aren’t testing on congested 5G and throttled CPUs, your localhost metrics are a total lie.
In this V-Techhub December issue, we’re cutting through the noise to simulate real-world user environments and obtain accurate performance data. Prepare to deep-dive into the Core Web Vitals (LCP, CLS, and the now-critical INP) and put the cutting-edge AI Assistant to the test to see if it actually accelerates problem-solving.
Let’s get to work.
Table of Contents
Performance Debugging
The Performance panel (formerly the Timeline panel) is the core diagnostic engine within Chrome DevTools, designed to help developers identify and resolve execution bottlenecks. In 2024 and 2025, the panel received a major redesign, transitioning from a static recording tool to a real-time performance command center.
Key New Features
1. Live Performance Metrics
You can now monitor Core Web Vitals (LCP, CLS, and INP) in real-time without needing to record a full performance trace.
- Real-time Feedback: As you interact with the page, the panel updates to show how your actions affect responsiveness and visual stability.
- Field Data Integration: You can compare your local “lab” scores against real-world “field” data from the Chrome User Experience Report (CrUX) directly within the panel.
2. AI-Powered “Debug with AI” (Gemini)
The panel now integrates Gemini, allowing you to chat about a performance trace to identify bottlenecks more holistically.
- Trace Analysis: You can ask the AI to explain specific long tasks or suggest remediation steps like code splitting or lazy-loading.
- Contextual Insights: Right-click on elements or console messages to select “Debug with AI” for personalized optimization tips.
3. New “Insights” Sidebar
Replacing the deprecated experimental “Performance Insights” panel, this sidebar is now integrated directly into the main Performance tab.
- Actionable Recommendations: It automatically identifies issues like render-blocking resources, layout shifts, and heavy JavaScript tasks.
- Performance Annotations: You can now annotate traces to mark specific findings, making it easier to share learnings with team members.
4. Advanced Interaction & Visibility
- INP Breakdown: When a slow interaction is detected, the panel breaks the latency into three phases: Input Delay, Processing Duration, and Presentation Delay.
- Custom Tracks & Filtering: Developers can now reorder tracks, hide irrelevant scripts in the flame chart, and search for specific network requests within the performance timeline.
- Calibrated Throttling: The panel now offers recommended throttling settings based on real-user data to better simulate target user environments.
Overview of Performance Trace
The Performance panel provides a comprehensive trace of everything happening in your application during a recording session. When you start a recording and interact with your page, Chrome captures detailed information about JavaScript execution, rendering, painting, and more. The resulting trace is displayed in several sections:
The info sidebar on the left and the timeline at the top are usually the place to start your investigation. Below that, you’ll see the Main thread flame chart, which visualizes the call stack and shows exactly what JavaScript functions were executing and for how long. Network requests appear in their own row, and screenshots can be enabled to show what the page looked like at different points in time. Understanding how to read this trace is fundamental to performance optimization—you’re looking for long tasks (over 50ms), excessive layout recalculations, or JavaScript functions that take too long to execute.
Simulating Real User Environments
To accurately diagnose performance issues, you need to test under conditions that reflect your actual users’ experiences. Chrome DevTools provides several ways to simulate real-world scenarios.
First, use the Performance panel’s CPU throttling feature to slow down your CPU by 4x or 6x, simulating lower-end devices that many users might have. This is accessed through the settings gear icon in the Performance panel. Second, combine this with network throttling (as discussed in the Network section) to simulate mobile users on cellular connections. Third, use Device Mode (toggle device toolbar) to emulate specific mobile devices with their actual screen sizes and user agents. This combination of CPU throttling, network throttling, and device emulation gives you a realistic picture of how your site performs for users who don’t have high-end development machines. Additionally, consider testing with disabled cache and in Incognito mode to simulate first-time visitors without any cached resources or extensions that might affect performance measurements.
Investigating LCP Issues
Largest Contentful Paint (LCP) is a Core Web Vital that measures how long it takes for the largest content element to become visible in the viewport. To investigate LCP issues, start by running a Performance recording that captures your page load. In the Timings row of the trace, you’ll see an “LCP” marker indicating when this metric occurred. Click on it to see which element was identified as the LCP element. Common culprits for poor LCP include large, unoptimized images, web fonts that block rendering, slow server response times, or render-blocking JavaScript and CSS.
In the above example report, LCP score is 2.77 second. Which is not good and we will fix that. Expanding the LCP breakdown, we will see a detailed breakdown of what causes the LCP issue, and what is the LCP component
Clicking on the LCP tag, we will see exactly which element is LCP, in this example, the banner-ODu4uCCv.png is taking 1,197ms to load and 1,762ms to wait. 1,762ms is clearly problematic since the insights already mention: most of the LCP time should be spent on loading the resources not within delays. Next, we will find a way to fix it.
Fixing LCP Issues
Once you’ve identified the cause of poor LCP, several strategies can help fix it.
If your LCP element is an image, optimize it by compressing it, serving it in modern formats (WebP or AVIF), and using responsive images with srcset to serve appropriately sized versions. Add preload hints for critical LCP images using the <link rel=”preload” /> tag to ensure they’re discovered and loaded as early as possible. For this example, we will add the following code
<link rel="preload" as="image" href="/src/assets/banner.png" />
After implementing fixes, record another Performance trace
Notice how the banner-ODu4uCCv.png file loaded at the same time with js and css file. By doing this we have reduced the LCP time to just 2.16s which is a good LCP score. This was achieved by reducing the wait time of the critical resource
Some other issues that dev tool can list out including: If slow server response time is the issue, optimize your backend, implement caching, or use a CDN to serve content from locations closer to your users. For font-related LCP issues, use font-display: swap to prevent invisible text, and preload critical fonts. Remove render-blocking resources by deferring non-critical JavaScript, inlining critical CSS, or using async/defer attributes on script tags. After implementing fixes, record another Performance trace to verify that LCP has improved—you should see the LCP marker appearing earlier in the timeline and the Core Web Vitals passing the threshold (2.5 seconds or less for good LCP).
Investigating CLS Issues
Cumulative Layout Shift (CLS) measures visual stability by quantifying how much unexpected layout shift occurs during the page’s lifetime. Investigating CLS requires identifying which elements are shifting and why.
Click on these to see which elements moved and by how much, also the reason why it shifted (e.g. unsized image). The Layout Shift Details panel shows the elements that shifted and their impact scores. Common causes of CLS include images or videos without dimensions, dynamically injected content (ads, embeds), web fonts causing FOIT/FOUT, or animations that trigger layout. Use the Rendering panel (accessible via More Tools and then Rendering) and enable “Layout Shift Regions” to see real-time highlighting of areas that shift as you interact with your page—shifted regions will flash blue. This visual feedback is extremely helpful for identifying problematic elements. Also check the Console for any JavaScript errors that might be causing layout thrashing, and use the Layers panel to understand how different layers are composited, as improper layering can contribute to unexpected shifts.
Investigating INP Issues
Interaction to Next Paint (INP) measures a page’s overall responsiveness by tracking the latency of all click, tap, and keyboard interactions. Unlike First Input Delay, INP accounts for the entire duration from the initial input to the moment the browser actually paints the next frame.
To investigate INP, open the Performance panel and use the Live Metrics view to see real-time updates as you interact with the page. Once a slow interaction is identified (typically over 200ms), record a trace while repeating the action. In the recording, expand the Interactions track to see a breakdown of the three key phases:
- Input Delay: Time waiting for the main thread to become available.
- Processing Duration: Time spent executing JavaScript event handlers.
- Presentation Delay: Time required for the browser to calculate layout and paint the updated UI.
Optimize long task with scheduler.yield()
When investigating INP issues, you often find long tasks (tasks exceeding 50ms) that block the main thread and delay the browser’s ability to paint. One modern way to address this is using scheduler.yield().
async function respondToUserClick() {
giveImmediateFeedback();
await scheduler.yield(); // Yield to the main thread.
slowerComputation();
}
Benefit
- Prioritized Responsiveness: Unlike setTimeout, scheduler.yield() is specifically designed to yield to the main thread while ensuring the remaining work continues as a prioritized task.
- Reducing Interaction Latency: By breaking up a long JavaScript execution into smaller chunks, you allow the browser to process user inputs (like clicks or keypresses) in between those chunks, directly improving your INP score.
Limitations
- Browser Support: As a relatively new API, it may not be supported in all browsers, necessitating a fallback or polyfill (like setTimeout) for older environments.
AI-Powered Diagnostics
Chrome DevTools has introduced AI-powered assistance to help developers diagnose and fix all kinds of issues more efficiently. You can use the AI assistant anywhere that has the AI icon. The AI assistant can analyze your Performance recordings and provide contextual suggestions for improvements. To access this feature, look for the AI insights panel in the Performance tab (this feature may require enabling in Chrome’s experimental features).
When analyzing a performance trace, AI assistance can automatically identify issues like long tasks, render-blocking resources, or inefficient JavaScript execution patterns, and suggest specific remediation steps.
For example, it might recommend code splitting for large JavaScript bundles, suggest lazy-loading strategies for below-the-fold content, or identify specific functions that could benefit from optimization. You might see a recommendation like this:
Let’s check the current code of TargetDetailsPage.tsx
useEffect(() => {
async function fetchData() {
const start = Date.now();
while (Date.now() - start < 1000) {
// Bussiness logic
}
}
fetchData();
}, []);
And the performance trace report look like this:
This actually increase time for LCP, let’s fix it by adding setTimeout or scheduler.yield();
useEffect(() => {
async function fetchData() {
const start = Date.now();
await scheduler.yield();
while (Date.now() - start < 1000) {
// Bussiness logic
}
}
fetchData();
}, []);
Now run the trace report again and we can see that fetchData happened after the Element render delay time. Therefore delay time got reduce from ~6s to just ~3,3s
Beyond the Performance panel, you can use the AI assistant in the Elements tab to debug CSS and layout issues. Since it can inspect the DOM and computed styles, you can ask why a rule is (or isn’t) applied, which selector is winning, and what changes would fix the visual layout.
You can also ask about Network requests by selecting a request and requesting an explanation of the headers, timing breakdown, caching behavior, CORS issues, or why a request failed.
And if you’re unsure about what you’re seeing elsewhere, you can ask the assistant to explain the contents of a loaded file, or clarify what a specific trace item in the Performance flame chart means.
The AI assistant can also explain complex performance metrics in plain language, making it easier to understand what’s happening in your application.
Conclusion
The bottom line is that Chrome DevTools is the only environment that matters for building reliable web apps. If you aren’t leveraging the Performance panel to monitor Core Web Vitals in real-time, you’re just waiting for users to report your regressions—and that’s a colossally bad way to manage a product.
With AI-powered diagnostics and the Insights sidebar, resolving layout shifts and long-running tasks is finally becoming a predictable science instead of a guessing game. Consistently using these tools is how you transform complex trace data into a high-quality experience.
Don’t let your performance strategy drift. Follow V-Techhub to keep up with our monthly updates, or if your team needs a hand audit-proofing your stack, get in touch with the Vinova team. Let’s make sure your site isn’t the one lagging behind in 2026.