Advanced DevTools Debugging

Part 1: Memory Forensics

When your app gets sluggish over time, the problem is usually memory. Chrome's Memory panel lets you take X-rays of your heap.

Taking Heap Snapshots

Reading Heap Snapshots

The snapshot view has four columns that matter:

The trick: Sort by "Retained Size" descending. The biggest retained objects are your suspects.

Finding Memory Leaks

Objects that show up as +50, +100, +500 are your leak candidates.
Click to expand and see the retainer tree—what's keeping them alive?

Common Leak Patterns in the Heap

When you expand an object in the retainer tree, you'll see what's keeping it alive:

Exporting Memory Dumps for Analysis

For complex leaks, export the heap for offline analysis:

1. Right-click the snapshot in the left panel
2. Select "Save..."
3. Save as .heapsnapshot file

You can reimport these later, share with teammates, or feed to analysis tools.

Part 2: Network Chunk Investigation

Your bundle is split into chunks. The Network panel shows exactly what's in each one—and when it loads.

Finding Your Chunks

Inspecting Chunk Contents

Here's where it gets powerful. You can see exactly what's in each chunk:

The Source Maps Trick

If source maps are enabled (they should be in dev), you get superpowers:

1. Go to Sources panel
2. Navigate to webpack:// or _N_E/ (Next.js)
3. You can see the original, unminified source files
4. Right-click any file → "Reveal in Network panel" to see which chunk it landed in

Chunk Load Timing Analysis

In the Network panel, look at the Waterfall column:

If you see long gray/white bars: You're loading too many chunks in parallel. Browser limits connections.

If you see long blue bars: Chunk is too big. Split it further.

Part 3: Extracting Chunk Content for LLM Analysis

This is the advanced technique: extracting minified chunk content and using an LLM to decode what's actually in there.

Why This Works

Minified code is hard for humans but trivial for LLMs. They can:

• Identify which libraries are present
• Estimate the size contribution of each library
• Spot duplicated code across chunks
• Identify code that shouldn't be in the client bundle

Extraction Method

This is a minified JavaScript bundle from a Next.js application.
Please analyze it and tell me:

1. What major libraries/frameworks are included?
2. Approximately what percentage of the bundle is each library?
3. Is there anything that looks like it shouldn't be in a client bundle
   (server-only code, API keys, large data objects)?
4. Are there any obvious duplications or inefficiencies?

Here's the bundle:
[paste minified code]

// Run this in the Console after page load
const chunks = performance.getEntriesByType('resource')
  .filter(r => r.initiatorType === 'script' && r.name.includes('.js'))
  .map(r => ({
    name: r.name.split('/').pop(),
    size: r.transferSize,
    url: r.name,
  }));

// Log chunk info
console.table(chunks);

// Fetch and save a specific chunk
async function extractChunk(url) {
  const response = await fetch(url);
  const text = await response.text();
  console.log(`Chunk size: ${(text.length / 1024).toFixed(2)} KB`);
  return text;
}

// Example: extract the largest chunk
const largest = chunks.sort((a, b) => b.size - a.size)[0];
const content = await extractChunk(largest.url);
copy(content); // Copies to clipboard

// scripts/analyze-chunks.js
const fs = require('fs');
const path = require('path');

const buildDir = '.next/static/chunks';
const chunks = fs.readdirSync(buildDir)
  .filter(f => f.endsWith('.js'))
  .map(f => ({
    name: f,
    size: fs.statSync(path.join(buildDir, f)).size,
    content: fs.readFileSync(path.join(buildDir, f), 'utf8'),
  }))
  .sort((a, b) => b.size - a.size);

// Output largest chunks for analysis
chunks.slice(0, 5).forEach(chunk => {
  console.log(`\n=== ${chunk.name} (${(chunk.size / 1024).toFixed(2)} KB) ===`);

  // Sample: first 500 chars to identify what's in it
  console.log(chunk.content.substring(0, 500) + '...');
});

LLM Analysis Prompts

Different prompts for different investigations:

Finding Library Bloat:

Analyze this minified JS chunk and identify:
1. All third-party libraries (look for common patterns like __webpack_require__,
   known library function names, etc.)
2. Which library appears to take the most space
3. Any libraries that seem duplicated or have multiple versions

[paste chunk]

Finding Leaked Server Code:

This should be a client-side JavaScript bundle. Look for anything that
suggests server-side code leaked into it:
- Database queries or ORM code (prisma, drizzle, knex)
- Environment variable access beyond NEXT_PUBLIC_*
- File system operations
- Server-only imports

[paste chunk]

Bundle Archaeology:

I'm trying to understand why this chunk is so large. Please:
1. Identify the main purpose of this chunk (vendor libs? app code? specific feature?)
2. List everything you can identify in it
3. Estimate rough percentage breakdown by library/purpose
4. Suggest what could potentially be removed or lazy-loaded

[paste chunk]

What the LLM Can Find

Real examples of what LLM analysis reveals:

Part 4: Putting It All Together

Here's the full forensic workflow for a slow app:

Quick Reference

Memory Panel Shortcuts

Network Panel Shortcuts

Console Snippets

// List all loaded scripts with sizes
performance.getEntriesByType('resource')
  .filter(r => r.initiatorType === 'script')
  .map(r => ({ name: r.name.split('/').pop(), kb: (r.transferSize/1024).toFixed(1) }))
  .sort((a, b) => b.kb - a.kb);

// Total JS loaded
performance.getEntriesByType('resource')
  .filter(r => r.initiatorType === 'script')
  .reduce((sum, r) => sum + r.transferSize, 0) / 1024;

// Find what's keeping an object alive (run in Console)
// Select element in Elements panel first, then:
// queryObjects(Constructor) - finds all instances
// $0 - references selected element

This is advanced debugging. For the fundamentals, start with Bundle Analysis and Memory Management.