Find performance bottlenecks with Chrome DevTools
Stop guessing why a page is slow. Use the Network and Performance panels in Chrome DevTools to find the heavy files, long tasks and layout shifts that cost you speed.
When a page feels slow, the tempting move is to apply every tip you have read: compress something, defer something, hope. That wastes time, because most slow pages have one or two real causes. The browser already ships the tools to find them.
Open DevTools with F12, or right click the page and choose Inspect. Then work through the two panels below in order.
Start with the Network panel
The Network panel answers one question: what did the page download, and how long did it take?
- Open the Network tab and tick Disable cache.
- Set throttling to Fast 4G so you see what a phone user sees.
- Reload the page.
- Sort by Size, then by Time.
Look for these patterns:
| What you see | What it usually means |
|---|---|
| An image of several hundred kilobytes | It needs compression, a modern format or smaller dimensions |
| One very large JavaScript file | The bundle needs splitting |
| Many small requests to other domains | Too many third party scripts |
| A long wait before the first byte of the HTML | A slow server or a missing cache |
The filter buttons (JS, CSS, Img, Font) make it quick to see which type of file dominates.
Record in the Performance panel
The Performance panel shows what the browser was busy doing.
- Open the Performance tab.
- Turn on CPU throttling at 4x slowdown.
- Click the reload button inside the panel to record a page load.
- Stop the recording once the page settles.
In the timeline, look for:
- Long tasks. Blocks marked with a red corner ran longer than 50 ms and kept the page from responding to input.
- Render blocking resources. Stylesheets and scripts in the
<head>that delay the first paint. - Layout shifts. Content that jumps while the page loads, often an image without
widthandheight. - The LCP marker. It shows which element was the largest paint and when it appeared.
Click any block to see the function and file behind it. That is the line of code to fix.
Turn the findings into fixes
A typical recording shows a large hero image loading early and one long script blocking the main thread. Each has a direct answer:
- Heavy images: see our guide to image optimization for the web.
- A large bundle: reduce the JavaScript bundle size.
- Long tasks: keep the main thread free or move the work to a Web Worker.
Measure again
Change one thing, record again and compare. Performance work without a second measurement is only a guess. For a quick overall score, run a Lighthouse report from the same DevTools window, and remember that it is a lab test: real users on real phones are the final judge.