This last lesson puts the whole course to work on one page. Pick a real one. It should have initial HTML, CSS, an important image, some JavaScript, at least one interaction, and some browser storage. A product page or a dashboard is perfect.

You’ll investigate three scenarios and write down what you find.

Scenario 1: the load

Record a fresh navigation, cache disabled, until the main content is on screen. Use Network and Performance together and answer:

When did the document request start and finish?
Which resources did the HTML parser discover, and which came later from CSS or JavaScript?
What did the DOM and CSSOM look like, and which nodes made it into the render tree?
Where on the timeline did style, layout, paint, raster, and compositing run?
Which element became LCP, and what delayed it?

That last question sends you back to the four LCP delays. Name the one that dominated.

Scenario 2: the interaction

Pick the interaction that matters most on this page and record it. Trace the path from input to the next frame: input delay, handler work, microtasks, rendering.

Look for a long task, DOM work that touches more than it needs, a forced synchronous layout, or a paint bigger than the visual change. Write down which phase took the most time.

Scenario 3: memory

Find a feature that allocates, like a dialog or a panel. Open and close it five times, snapshot before and after, and follow the retaining path of anything that should have disappeared.

The storage audit

While you’re there, open the Application panel. For every cookie, localStorage key, and IndexedDB database, answer why it exists, who owns it, and when it expires or gets cleared. Anything you can’t explain is a candidate for removal.

Choose fixes from evidence

Now you have a list of measured problems. Pick fixes that match them: put the hero image in the initial HTML, delete a synchronous script nobody needs, batch the layout reads and writes in that one loop, add width and height to the images that shifted, remove the window listener when the panel closes.

Don’t apply all of them on principle. Apply the ones your traces asked for.

Keep a small record for each fix:

Symptom:
Evidence:
Cause:
Change:
Result under the same test conditions:
Tradeoff or remaining risk:

Then record all three scenarios again under the same cache, network, CPU, and viewport conditions.

A good result is not “the Lighthouse score went up”. It’s an explanation you can defend, from the request to the pixels to the interaction to the cleanup, with traces that show the bottleneck you named got smaller. That’s what this course was about.

Profile and fix a page