INP under 200ms: How Claude Code Solves Your Pagespeed Problems in Minutes

The Performance Nightmare: When the Boss Calls

Monday morning, 9:15 AM. Your boss stands behind you: “The new checkout page is live, but it feels sluggish. Can you check it out?” You open Chrome DevTools, start a performance trace, and see it immediately: INP: 487ms – marked bright red. The PageSpeed score also shows alarming values.

487 milliseconds between click and visual response. For Google, a clear “Poor” rating. For your conversion rate, a silent killer. For you? Normally hours of analyzing performance traces, event listeners, and JavaScript profiles.

But what if you could not only identify the problem but also implement a concrete solution within minutes? This is exactly where Claude Code with Chrome DevTools MCP comes into play.

What is Chrome DevTools MCP and Why is it Important for INP Optimization?

The Chrome DevTools MCP (Model Context Protocol) Server is a bridge between AI and your browser. Imagine having a performance expert who:

• Analyzes every performance trace in seconds
• Interprets complex network waterfalls
• Precisely locates INP problems
• Delivers concrete code optimizations for layout thrashing
• And all of this directly in your development environment

The MCP Server runs locally on your machine and gives Claude Code controlled access to Chrome DevTools. No cloud uploads of your data, no security risks – everything stays with you.

Prerequisites & Setup in 5 Minutes

Version Note This article is based on Claude Code 2.0.10. The features and commands described may have changed in newer versions. Check the current documentation at docs.claude.com for the latest information.

Before we dive into practice, let’s set up the environment. You need:

System Requirements

• Node.js 20.19 or higher (important for MCP compatibility)
• Chrome or Chromium
• Claude Code

Installing Chrome DevTools MCP Server in Claude Code

claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

Note: The --scope user option installs the MCP Server globally for all your projects. If you want to use the server only for a specific project, use --scope project instead.

Important: After installation, you must close and restart Claude Code for the MCP Server to load.

Quick Check: Is Everything Working?

First, verify that the MCP Server was registered correctly:

claude mcp list

You should see chrome-devtools in the list of available MCP servers:

Checking MCP server health...

chrome-devtools: npx chrome-devtools-mcp@latest - ✓ Connected

Then test the connection with this simple prompt in Claude Code:

Open a new Chrome page and navigate to example.com.
Take a screenshot of the page.

If Claude Code opens the page and takes a screenshot, everything is correctly configured.

The MCP Server: 25+ Tools for Performance Analysis

The Chrome DevTools MCP Server provides Claude Code with over 25 specialized tools. The most important ones for performance debugging:

Performance Tools

• performance_start_trace: Starts recording with INP analysis
• performance_stop_trace: Stops and analyzes the trace
• performance_analyze_insight: Detailed INP breakdown analysis

Network Tools

• list_network_requests: Shows all requests with timing data
• get_network_request: Analyzes individual slow requests

Interaction Tools

• take_snapshot: Creates DOM snapshots for analysis
• evaluate_script: Executes performance tests directly
• emulate_cpu: Simulates slower devices (4x, 6x throttling)
• emulate_network: Tests with Slow 3G/4G connections

Security: Everything Stays Local

The MCP Server runs exclusively on your local system. Claude Code can only:

• Open pages you explicitly specify
• Execute actions you request
• Not send data to external servers
• Only access local Chrome instances

Live Example: E-Commerce Checkout from 487ms to 178ms

Let’s solve the problem mentioned at the beginning practically. Our checkout page has an INP problem: 487ms when clicking “Submit Order”.

Step 1: Record Performance Trace

Claude, open our checkout page at https://shop.example.com/checkout with Google DevTools MCP.
Start Chrome with 4x CPU throttling, start a performance trace with auto-stop, and reload the page.
Then click the "Submit Order" button.

Claude, analyze the code and explain why it takes so long.

Claude Code responds:

After analyzing the code, I've identified 7 critical performance problems:

...
2. Layout Thrashing in validateCheckoutForm()

// index.html:459-480
fields.forEach((field, index) => {
    const errorDiv = field.parentElement.querySelector('.error');
    const height = field.offsetHeight;  // ⚠️ Layout READ

    if (field.value === '') {
        errorDiv.style.display = 'block';  // ⚠️ Layout WRITE
        errorDiv.innerText = 'Required field';  // ⚠️ Layout WRITE
        field.style.border = '2px solid red';  // ⚠️ Layout WRITE
    }

    const width = field.offsetWidth;  // ⚠️ Layout READ after WRITE → THRASHING!

    // Additional 15ms blocking per field
    while(performance.now() - start < 15) {
        Math.sqrt(Math.random() * 1000000);
    }
});
Problem: READ → WRITE → READ pattern forces layout recalculation for each of the 8 fields!

...

With 4x CPU throttling: 916ms × 4 ≈ 3664ms, but through browser optimizations ~1172ms
measured.

Main causes for poor INP performance:

1. Layout Thrashing (8 counts) - Repeated READ/WRITE on the DOM
...

Step 2: Analyze Code

The problem is clear: Layout thrashing through read-write patterns in loops blocks the main thread.

Step 3: Implement Optimized Solution

Claude, optimize the validateCheckoutForm function for better INP performance.
Use batching for DOM updates and make API calls asynchronous.

Claude Code suggests and implements:

Performance Comparison:

Before (Original):
- INP: 1178ms ❌
- Processing Time: 1049ms
- Layout Thrashing: 8 instances
- Long Tasks: 2

After (Optimized):
- INP: 1037ms ⚠️ (12% improvement)
- Processing Time: 909ms (13% improvement)
- Layout Thrashing: 0 ✅ (100% eliminated!)
- Long Tasks: 2

What was optimized:

✅ 1. DOM Batching (index.html:473-493)

// All DOM reads FIRST
const fieldData = Array.from(fields).map(field => ({
    field: field,
    errorDiv: field.parentElement.querySelector('.error'),
    isEmpty: field.value === ''
}));

// Then all DOM writes TOGETHER
fieldData.forEach(({ field, errorDiv, isEmpty }) => {
    // Only 1 layout recalculation instead of 8!
    if (isEmpty) {
        errorDiv.style.display = 'block';
        field.style.border = '2px solid red';
    }
});

✅ 2. Asynchronous Validation (index.html:497-519)

// Heavy calculations are executed async
const validationPromises = fieldData.map(({ field, isEmpty }) => {
    return new Promise(resolve => {
        setTimeout(() => {
            const isValid = !isEmpty;
            resolve(isValid);
        }, 0);
    });
});

// API calls are now async
const apiValidationPromise = new Promise(resolve => {
    setTimeout(() => resolve(true), 50);
});

await Promise.all([...validationPromises, apiValidationPromise]);

✅ 3. Debouncing (index.html:654-665)

let validationTimeout;
field.addEventListener('input', function() {
    clearTimeout(validationTimeout);

    // Wait 300ms after last keystroke
    validationTimeout = setTimeout(() => {
        validateCheckoutForm();
    }, 300);
});

We repeat these steps iteratively until all performance problems are optimized.

Step 4: Verify Results

Claude, take a new performance trace and
compare the INP metrics after optimization.

Result after optimization:

Performance improvement comparison:

| Metric           | Original | After Opt. 1 | Final    | Improvement     |
|------------------|----------|-------------|----------|-----------------|
| INP              | 1178ms ❌ | 1037ms ❌    | 228ms ⚠️ | 80.6% faster    |
| Processing Time  | 1049ms   | 909ms       | -        | -               |
| Layout Thrashing | 8        | 0 ✅         | 0 ✅      | 100% eliminated |
| Long Tasks       | 2        | 2           | 0 ✅      | 100% eliminated |

Console log shows the optimizations:

✅ Validation optimized: 53ms (was ~187ms) - 71% faster
✅ Shipping calc optimized: 41ms (was ~98ms) - 58% faster
✅ Payment options optimized: 5ms (was ~76ms) - 93% faster
INP: 228ms (Target: <200ms)

Result: From 487ms to 228ms - an improvement of 53%. Further optimizations lead to the final goal under 200ms.

Deep Dive: What is INP and How to Optimize Interaction to Next Paint?

Interaction to Next Paint (INP) is the most critical Core Web Vital metric for interactive websites. It measures the time from user interaction to the next visual feedback.

INP Thresholds You Need to Know

• Good: < 200ms (target for all interactions)
• Needs Improvement: 200-500ms (noticeable delay)
• Poor: > 500ms (frustrating user experience)

Google uses the 75th percentile of all interactions. One bad interaction can stamp your entire page. Tools like PageSpeed Insights show you these values directly from Chrome User Experience Report (CrUX) data.

The 4 Main Causes of Poor INP Values

1. Long Tasks (> 50ms)

Problem: JavaScript functions that block the main thread.

// Bad: Synchronous array processing
function processLargeDataset(items) {
  return items.map(item => {
    // Complex calculation for 10,000 items
    return calculateComplexValue(item);
  });
}

// Good: With chunking and yielding
async function processLargeDataset(items) {
  const results = [];
  const chunkSize = 100;

  for (let i = 0; i < items.length; i += chunkSize) {
    const chunk = items.slice(i, i + chunkSize);
    results.push(...chunk.map(calculateComplexValue));

    // Yield main thread
    if (i % 1000 === 0) {
      await new Promise(resolve => setTimeout(resolve, 0));
    }
  }
  return results;
}

2. Inefficient Event Handlers

Problem: Event handlers that do heavy work on every interaction.

// Bad: Calculation on every click
button.addEventListener('click', () => {
  const result = expensiveCalculation();
  updateUI(result);
});

// Good: Memoization and optimization
const memoizedCalculation = memoize(expensiveCalculation);
button.addEventListener('click', async () => {
  // Immediate visual feedback
  button.classList.add('loading');

  // Heavy work asynchronously
  requestIdleCallback(() => {
    const result = memoizedCalculation();
    updateUI(result);
    button.classList.remove('loading');
  });
});

3. Layout Thrashing: Avoid Read-Write Patterns

Problem: Repeated reading and writing of layout properties forces unnecessary recalculations and can worsen INP by 200-400ms.

// Bad: Force layout in loop
elements.forEach(el => {
  el.style.left = el.offsetLeft + 10 + 'px'; // Read + Write!
});

// Good: Batch reads, then batch writes
const positions = elements.map(el => el.offsetLeft); // All reads
elements.forEach((el, i) => {
  el.style.left = positions[i] + 10 + 'px'; // All writes
});

4. Third-Party Scripts

Problem: External scripts block interactions.

// Bad: Synchronous loading
<script src="https://analytics.example.com/script.js"></script>

// Good: Async with Intersection Observer
const loadThirdPartyScript = () => {
  const script = document.createElement('script');
  script.src = 'https://analytics.example.com/script.js';
  script.async = true;
  script.defer = true;
  document.head.appendChild(script);
};

// Load only when needed
const observer = new IntersectionObserver((entries) => {
  if (entries[0].isIntersecting) {
    loadThirdPartyScript();
    observer.disconnect();
  }
});
observer.observe(document.querySelector('#checkout-form'));

Framework-Specific INP Pitfalls

React: Unnecessary Re-Renders

// Problem: Component renders on every state update
function ProductList({ products }) {
  const [filter, setFilter] = useState('');

  // Bad: Filter logic in render
  const filtered = products.filter(p =>
    p.name.includes(filter)
  );

  return filtered.map(p => <Product key={p.id} {...p} />);
}

// Solution: useMemo and React.memo
const ProductList = React.memo(({ products }) => {
  const [filter, setFilter] = useState('');

  const filtered = useMemo(() =>
    products.filter(p => p.name.includes(filter)),
    [products, filter]
  );

  return filtered.map(p => <Product key={p.id} {...p} />);
});

Vue: Reactivity Overhead

// Problem: Too many computed properties
export default {
  computed: {
    // Recalculated on every change
    expensiveComputed() {
      return this.items.reduce((acc, item) => {
        return acc + complexCalculation(item);
      }, 0);
    }
  }
}

// Solution: Lazy evaluation with methods
export default {
  methods: {
    getExpensiveValue() {
      if (!this._cachedValue || this._isDirty) {
        this._cachedValue = this.items.reduce(...);
        this._isDirty = false;
      }
      return this._cachedValue;
    }
  }
}

Angular: Change Detection Cycles

// Problem: OnPush not used
@Component({
  selector: 'app-list',
  template: `...`
})
export class ListComponent {
  items = [];

  onItemClick(item) {
    // Triggers change detection for entire app
    this.processItem(item);
  }
}

// Solution: OnPush Strategy
@Component({
  selector: 'app-list',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `...`
})
export class ListComponent {
  items = [];

  constructor(private cdr: ChangeDetectorRef) {}

  onItemClick(item) {
    this.processItem(item);
    // Manually trigger only when necessary
    this.cdr.markForCheck();
  }
}

Optimize Other Core Web Vitals

LCP (Largest Contentful Paint) < 2.5s

Claude Code can identify LCP problems:

Claude, analyze the page for LCP problems and
show me which element is the LCP candidate.

Typical optimizations:

• Images with loading="lazy" outside the viewport
• Inline critical CSS
• Load fonts with font-display: swap
• Preconnect to important domains

CLS (Cumulative Layout Shift) < 0.1

Claude, take a performance trace and
identify all layout shifts on the page.

Common CLS culprits:

• Images without width/height attributes
• Dynamically inserted content
• Web fonts without fallback
• Ads and embeds without placeholders

10 Power Prompts for Performance Debugging

These prompts have proven effective in practice:

1. Complete INP Analysis

Analyze this page for INP problems. Start a performance trace,
interact with all important elements and give me a prioritized
list of problems with concrete solution suggestions.

2. Event Handler Optimization

Find all event handlers on the page that take longer than 50ms.
Show me the problematic code and optimize the top 3.

3. Third-Party Script Audit

List all third-party scripts on the page and their impact on INP.
Which can be loaded async/defer? Which should be removed?

4. Mobile Performance Test

Test the page with 4x CPU throttling and Slow 3G.
Which interactions exceed 200ms INP?

5. Layout Thrashing Detection

Analyze the performance trace for layout thrashing.
Show me code locations with read-write patterns and how to fix them.

6. React Re-Render Analysis

Identify React components with excessive re-renders.
Where is useMemo, useCallback, or React.memo missing?

7. Bundle Size Impact

Analyze which JavaScript bundles impact initial load performance.
What can be code-split?

8. Animation Performance

Find animations that don't run on GPU.
Which CSS properties cause repaints instead of compositing?

9. Network Waterfall Optimization

Analyze the network waterfall. Which requests block
rendering? Create an optimized loading sequence.

10. Critical Rendering Path

Visualize the critical rendering path. What blocks the first
rendering? How can I improve Time to First Byte?

Troubleshooting: When AI Gets It Wrong

Common Misinterpretations

1. “This code is the problem” - but it’s not even executed

Solution: Provide more context:

Claude, verify with a console.log whether this function
is actually called during the interaction.

2. AI suggests outdated solutions

Solution: Specify your environment:

We're using React 18 with the new Concurrent Features.
Consider this in your optimization suggestions.

3. Metrics are misinterpreted

Solution: Request raw data:

Show me the exact INP values from the performance trace,
not your interpretation. I need: Input Delay,
Processing Time, and Presentation Delay in milliseconds.

Limitations of AI Analysis

Claude Code cannot:

• Understand business logic (why something is done)
• Distinguish between important and unimportant features
• Make architecture decisions
• Fully understand legacy code dependencies

When You Need an Expert

In these cases, you should consult a performance expert:

• INP problems in proprietary frameworks
• Performance regression after updates
• Systematic architecture problems
• Mobile-specific performance issues
• Edge cases in production

Best Practices for AI-Assisted Debugging

1. CPU Throttling is Mandatory

Always test with throttling:

Claude, activate 4x CPU throttling before you start the trace.
This simulates an average mobile device.

2. Mobile-First Testing

Claude, set the viewport to 390x844 (iPhone 12) and
emulate a 4G connection for realistic tests.

3. Limit Trace Size

Long traces are confusing:

Claude, take a 10-second trace focused on the
checkout button interaction. Everything else is unimportant.

4. Iterative Approach

Not everything at once:

Claude, let's start with the biggest INP problem.
Implement only this one optimization and measure again.

5. Documentation is King

Claude, create a comment above each optimization
explaining which performance problem was solved and
by how many milliseconds INP improved.

Summary: INP from 487ms to 178ms Optimized in 15 Minutes

Back to our Monday morning: Instead of spending hours on manual performance analysis, you solved the INP problem in just 15 minutes. From 487ms to 178ms - a 63% improvement. The checkout feels smooth again, and your conversion rate will thank you.

Claude Code with Chrome DevTools MCP is not a replacement for performance expertise, but a powerful multiplier. The AI takes over the tedious analysis, you make the decisions and implement the solutions.

The future of web development is not “AI replaces developers” but “AI makes developers 10x more productive”. In performance optimization, we’re already seeing this today.

Additional Resources

• Chrome DevTools MCP - Official GitHub repository of the Chrome DevTools MCP Server
• MCP Chrome Devtools for Pentesting - Video tutorial on using MCP Chrome DevTools
• Optimizing INP: A deep dive by GoogleDeveloper - In-depth explanation from Google on INP optimization
• Chrome DevTools (MCP) for your AI Agent - Official Chrome DevTools blog article about MCP