Finding what's slow
🎯You'll be able to
Use a performance trace to find the element, script or request behind a slow metric.
🏠The everyday picture
A doctor doesn't prescribe medicine because a patient "feels unwell". They check temperature, pulse and blood tests to find the cause. Performance tools are the tests for a slow page.
📘What it really is
- Lighthouse diagnostics list likely causes: render-blocking resources, large images, unused JavaScript, long main-thread tasks.
- Network panel (waterfall): shows each file, its size and when it started and finished. Look for:
- the LCP image starting late or being large;
- many requests in a chain, each waiting for the last;
-
big JavaScript files loaded early.
-
Performance panel: records what the browser did second by second.
- The main thread runs JavaScript, layout and painting; when it's busy, taps wait.
- Long tasks (over 50 ms) are marked; they delay responses and hurt INP.
-
The Layout Shift track shows what moved and when, for CLS.
-
Chrome's Performance panel can also show the LCP element and shifting elements directly.
- Work from the biggest cause first, and change one thing at a time so you know what helped.
📝A worked example
Recording Kirana's product page on a throttled profile showed:
| Finding | Effect |
|---|---|
| Product photo is a 1.8 MB JPEG, discovered only after JavaScript runs | LCP 3.9 s |
| A promotional banner loads after 1.5 s and pushes content down | CLS 0.24 |
| A 220 ms task on tapping "Add to cart" (recalculating offers for the whole cart) | Some slow taps |
| A chat widget loading 400 KB of JavaScript at start-up | Main thread busy early |
This list became the plan for Lessons 4 and 5, in order of effect.
🌍Where it's used
- Investigating complaints of slowness.
- Performance reviews before big launches, such as festive sales.
- Checking third-party scripts added by marketing tools.
📝Case scenario
Taps on a filter button feel sluggish. The Performance panel shows each tap triggers a 300 ms task that re-sorts 5,000 products and re-renders the list. Moving sorting to happen once per filter change, memoising the result and virtualising the list (FE1) brings the task under 50 ms, and INP drops into the "good" range.
🖱️Try it
Record your Kirana product page in the Performance panel with throttling. List the LCP element, any layout shifts with their causes, and the three longest tasks, with what each was doing.
⚠️Common mistakes
- Guessing the cause before measuring. Sign: compressing images when the delay is a long script. Fix: record a trace and find the biggest block first.
- Measuring once. Sign: numbers jump between runs and you chase noise. Fix: run three times and use the middle result.
🛠️For your project
In Project 3, record a trace of /deals in the starter kit and note the three biggest causes before changing any code.
✅Quick check
What is a long task, and why does it matter?
Show the answer
A main-thread task over 50 ms; while it runs, the page can't respond to taps, which hurts INP.
Why change one thing at a time when fixing performance?
Show the answer
So you know which change helped and by how much.