I’m going to walk you through how I use Chrome DevTools to find the single resource that’s dragging a page down — and how I usually fix it fast. This is the kind of drill I run when a client says “the site feels slow,” when Core Web Vitals are flirting with danger, or when I just want a quick win before diving into larger architecture changes.

Why look for a single resource?

Most performance wins come from a small number of heavy or blocking resources: a big hero image, a bloated third‑party script, an uncompressed font file, or a slow API response. Identifying the single most impactful resource helps you prioritize the fastest, highest‑leverage fix — usually within minutes.

Prepare DevTools

Open Chrome and load the page. I prefer a clean environment, so I usually:

  • Open DevTools (Cmd/Ctrl + Shift + I).
  • Go to the Network panel and check Disable cache (works only while DevTools is open).
  • Turn on a realistic network and CPU profile (Network throttling set to Slow 3G or Fast 3G, and CPU throttling to 4x) to simulate poorer devices. That surfaces issues you might not notice on a powerful desktop.

Step 1 — Use the Network waterfall to spot the offender

The Network panel is the first place I look. Reload the page (Cmd/Ctrl + R) with DevTools open and watch the waterfall. Things I look for instantly:

  • A resource with an enormous transfer size (e.g., >500KB for images, >200KB for JS/CSS depending on context).
  • A resource that blocks other requests for a long time (long white space before next request starts).
  • Long TTFB (Time To First Byte) if a request is waiting on a slow server or API.
  • Many sequential requests from the same origin that could have been combined or parallelized.

Tip: click the Size and Time columns to sort by weight or latency. That can reveal one big file dominating transfer size.

Step 2 — Check the initiator and call stack

Once I’ve found a suspicious resource in the waterfall, I click it and inspect the Initiator and Headers panes. The initiator tells me whether that file was requested by a script, an HTML <img>, a stylesheet, or a third‑party widget.

Knowing the initiator helps decide the fix. For example:

  • If a script tag from a third party initiated it, consider async/defer, loading it after main content, or replacing it with a lighter alternative.
  • If an image tag initiated it, consider resizing, compressing, or serving a modern format (AVIF/WebP) and lazy‑loading it.
  • If a CSS file initiated a large request, maybe it includes fonts or huge background images that can be split.

Step 3 — Use Performance and LCP to find blocking resources

Network size isn’t everything. A small JS file that blocks the main thread for a long time can be the real culprit for a slow perceived load. I run the Performance panel (Cmd/Ctrl + E to record) and reload while recording. The flame chart shows:

  • Main thread tasks and long tasks (>50ms).
  • Layout and paint events that correlate with resource loads.
  • Largest Contentful Paint (LCP) timing and which element contributed to it.

If LCP is delayed, DevTools will usually highlight which element is the LCP candidate. Then I trace back to see what resource (image, font, CSS, or script) is delaying it.

Step 4 — Use Coverage to find unused JS/CSS

Third‑party scripts and frameworks often ship code you don’t need. Open the Coverage tab (Cmd/Ctrl + Shift + P, type “Coverage” and run it) and reload to see which JS/CSS files are mostly unused. A 250KB library with 90% unused bytes is an easy candidate for removal or replacement.

Step 5 — Lighthouse and Third‑party Issues

Run Lighthouse right from DevTools (Lighthouse panel). It surfaces issues like render‑blocking resources, unused JS, and large images, and gives a prioritized list of suggestions. It’s not the law, but it’s a fast sanity check.

Also check the Third‑party section in the Performance insights (if available) — it helps spot ad networks, tag managers, and analytics scripts that are expensive.

How I decide the single fix

After gathering data, I ask myself two questions:

  • Which single resource is responsible for the largest delay to a key metric (e.g., LCP, First Input Delay, or TTFB)?
  • Which fix will deliver the biggest improvement with the least effort?

Common winners:

  • A hero image that’s full‑resolution and uncompressed. Fix: resize, compress, serve WebP/AVIF, add loading="lazy" where appropriate, or use a responsive srcset.
  • A blocking third‑party script (chat widget, A/B test, big analytics snippet). Fix: load async/defer, lazy‑load after interactive, or move to an opt‑in after page load.
  • A large JavaScript bundle. Fix: code‑split, remove dead code, lazy‑load non‑critical parts, or replace heavy libraries with lighter alternatives.
  • Unoptimized fonts. Fix: subset fonts, use font-display: swap, preload critical font files.
  • Slow backend API for content above the fold. Fix: cache responses, add a CDN, or use a lightweight placeholder until content arrives.

Quick, practical fixes I apply right away

  • Image optimization: Re-export hero images at the display size and compress with Squoosh, ImageOptim, or an automated build step. Serve WebP/AVIF with srcset. Use loading="lazy" for below‑the‑fold media.
  • Script loading: Add defer or async to non‑critical scripts. For heavy widgets, wrap loading in a setTimeout or trigger on user interaction.
  • Preload and preconnect: Preload critical assets (fonts, hero image) using <link rel="preload"> and add rel="preconnect" for third‑party origins to reduce handshake time.
  • Compression and caching: Enable gzip/Brotli on the server and set long cache headers for immutable assets. Use a CDN to reduce TTFB.
  • Font optimizations: Subset fonts and use font-display: swap. Preload only the critical font files.
  • Request blocking experimentation: In the Network panel you can right‑click a request and choose "Block request URL". I use this to simulate removing a third‑party script and see the performance gain before actually removing it.

Examples from recent projects

Once, a client’s homepage had a 2.4MB hero image served at full resolution and no srcset. The Network waterfall flagged that image as the largest transfer. I replaced it with a compressed WebP scaled to the display size and added a responsive srcset — LCP dropped by 1.2s.

Another time, an A/B testing script injected by a marketing team was blocking rendering on slower devices. Using the initiator information in DevTools showed the script’s call chain. I lazy‑loaded the A/B script after the page became interactive, and the perceived load improved immediately.

When the problem is a back‑end or network delay

If the Network panel shows a consistently high TTFB for an API or the main document, the fix might be server‑side: caching, database query optimization, or CDN. Still, you can often mitigate perceptual slowness by showing a skeleton UI or prioritizing critical CSS/HTML so the page feels faster while the server catches up.

Validate and measure the gain

After making the change, re-run the same DevTools checks (Network, Performance, Lighthouse). Compare LCP, FCP, and Total Blocking Time before and after. Small changes can have outsized visual impact — but verify with repeatable measurements (multiple runs, cache on/off, and realistic throttling).

If you want, tell me about a specific slow page you’re looking at (URL + what metric bothers you most) and I’ll point to the most likely offenders and a quick remediation plan.