How to Debug a Website Like a Developer

Every developer hits the same wall at some point: the site works on their machine, the user says it's broken, and there's nothing in the console. Or the page loads but feels off. Or the layout jumps. Or the form doesn't submit half the time.

Most of these are debuggable in five minutes with the same handful of tools built into Chrome DevTools. Here's the exact sequence I run when something is "broken but the report is vague."

Step 1: Reproduce the issue first

Before changing anything, confirm you can see the same problem the user sees.

Reset the cache. DevTools → Network tab → check "Disable cache." Most "the site is broken" reports are old cache.
Match the viewport. Click the device-toolbar icon (or hit Cmd+Shift+M on Mac, Ctrl+Shift+M on Windows). Set the same screen size the user is on. Mobile Safari bugs almost never reproduce on a desktop browser.
Throttle the network. Network tab → throttling dropdown → "Slow 3G" or "Fast 3G." A surprising number of "the spinner spins forever" bugs are race conditions that only show up on slow connections.
Throttle the CPU. Performance tab → gear icon → "4x slowdown" or "6x slowdown." Frame drops and INP problems only show up here.

If you can't reproduce the user's problem in DevTools, ask them for a screenshot or screen recording. Don't change code blindly — the bug is probably real and probably not where you think.

Step 2: Check the console for the boring answer

Open the Console tab. Look at it with your eyes, not by scanning past.

Things I look for, in order:

Red error text. A page-level error is usually the bug.
Yellow warning text. [Violation] and [Deprecation] warnings often point at the actual issue even if they're not the literal error.
Network failures. The Console shows red entries for failed requests. A 404 on a JS chunk is the entire bug, and it's in the Console, and it's been there the whole time.
Failed to load resource lines. Often paired with a 404 or a CORS preflight failure. Click the link next to the line — DevTools jumps you to the Network tab.

Filter the console with the level buttons (Errors, Warnings, Info, Verbose). Most teams leave Verbose on and then complain there's too much noise. Click "Verbose" off, then "Warnings" on. Suddenly the relevant lines are visible.

Step 3: Read the Network tab like a timeline

The Network tab tells the story of the entire page load, in order. Most performance debugging lives here.

Sort by Time (started). That's the real order the requests happened, top to bottom.

Look for:

Long bars at the top. These are slow requests. Click them. The "Timing" tab breaks down DNS, TLS, TTFB, and download. A slow TTFB means the server is slow or far away. A slow "Content Download" means the file is too big.
Third-party requests in the critical path. Tag managers, chat widgets, fonts, analytics — they often block the rest of the page. Hover them, look at the initiator. If a 200KB script from a chat vendor is the reason your LCP is 4 seconds, that's the bug.
Requests that don't finish. Greyed-out rows in the Network tab are usually CORS, certificate, or DNS problems. Right-click → "Block request URL" is how you verify a third party isn't doing the same thing on its own.
404s on chunks. A page that loads forever on a fresh deploy usually means a JS chunk filename has a hash that changed between deploys and the user is hitting old HTML.

For the performance side of this, see Core Web Vitals and SEO — the field-data numbers in PageSpeed Insights almost always trace back to what's happening on the Network tab.

Step 4: Use the Performance tab for "the page feels off"

When the user says "the page is laggy" or "the menu doesn't open immediately," that's an INP problem. The Performance tab is where you find it.

Click Record, interact with the page the way the user describes, click Stop. You'll get a waterfall. Look for:

Long yellow/red "Scripting" blocks after an interaction. That's JavaScript running on the main thread. Hover the block — it tells you which function.
Long "Rendering" or "Layout" blocks. Styling or layout work. Often a sign of heavy CSS or large DOM trees.
Long tasks. Anything over 50ms is suspect. The red triangle icon means "this should not have been on the main thread."

The bottom-up tab groups the time by function. Click "Scripting" and find the function eating the most time. That's your lead.

If you don't want to record traces manually, ask the user to install the Web Vitals Chrome extension. It logs LCP, INP, and CLS to the console for every page load. Free diagnostic data with zero setup.

Step 5: Read the Sources tab for runtime bugs

Most developers under-use the Sources tab. It has three capabilities that pay back the install:

Breakpoints that matter. Click a line number, reload the page, the execution stops there. You can hover every variable in scope and step forward. This is how you find runtime bugs in JavaScript without sprinkling console.log everywhere.

Conditional breakpoints. Right-click a line number → "Add conditional breakpoint." Run only when user.id === 'abc-123'. Saves you from reproducing the bug from scratch.

DOM breakpoints. On the Elements tab, right-click a node → "Break on" → "Subtree modifications" or "Attribute modifications." Reload, and the debugger pauses the moment something changes. This is how you find the rogue script that's rewriting your form fields.

The "Blackbox" trick. Right-click a script in the Call Stack panel → "Blackbox this script." Now console.log and breakpoints skip that library. Useful when you don't want to step through angular.js / react-dom / jquery.js to get to your code.

Step 6: Check Lighthouse for the structural view

Open the Lighthouse panel. Run a report. Look at the SEO and Performance categories — they're graded out of 100 and the failures are listed by impact.

Don't obsess over the score. The scores are useful for two things:

Spotting what changed. Run Lighthouse before and after a change. If the score moves by 10+ points, that change mattered.
Surfacing audit-level issues. "Avoid an excessive DOM size," "Serve static assets with an efficient cache policy," "Eliminate render-blocking resources." Lighthouse lists every flagged item with a link to the explainer. Read the explainer. Apply only what's relevant.

The page-level SEO score catches the basics: missing meta descriptions, images without alt text, links that aren't crawlable, robots.txt problems. None of these are deep SEO fixes, but they're the ones your developers can knock out in an afternoon — see A Practical SEO Audit Checklist for the rest of it.

The five-minute triage script

When I get a "the site is broken" message, I run this in order:

Disable cache, hard reload, look at the Console. Red error? Read it. That's 80% of bugs.
Network tab, sort by Time, look for red rows and unusually long bars.
Mobile viewport, throttled network, repeat step 1.
If the page is slow, Performance tab recording, interact, look at the long task.
If a specific element is misbehaving, Elements → right-click → "Break on subtree modifications."

Every developer has their own version of this list. The point is to have one. The fastest debugging isn't clever — it's the same five checks, in the same order, every time.

For the broader "why is the site slow" question, see Angular Performance: The Few Things That Actually Matter or Why Your WordPress Site Is Slow, depending on the stack. If you're staring at the same red Lighthouse score across reports, send me a message and I'll tell you what's actually causing it.