Profile and fix a page

This final exercise turns the browser pipeline into one connected explanation. Choose a page with initial HTML, CSS, an important image, JavaScript, an interaction, and some browser storage.

Start with three explicit scenarios:

1. A fresh navigation until the main content appears.
2. One important interaction until its visual result appears.
3. Opening and closing a feature that allocates memory.

For the load, use Network and Performance recordings to answer:

• When did the document request start and finish?
• Which resources did the parser, CSS, or JavaScript discover?
• What became the DOM, CSSOM, and render tree?
• Where did style, layout, paint, raster, and compositing work occur?
• Which element became LCP, and what delayed it?

For the interaction, trace input delay, handler work, microtasks, and rendering before the next frame. Look for a long task, unnecessary DOM work, forced layout, or excessive paint. For memory, repeat the feature lifecycle and follow retaining paths for objects that should have disappeared.

Inspect the Application panel too. Identify why each cookie, localStorage entry, or IndexedDB database exists, who owns it, and when it expires or is cleared.

Choose fixes from evidence. Examples include exposing the hero resource in initial HTML, removing unused synchronous work, batching layout reads and writes, reserving image dimensions, or cleaning up a listener when its component closes. Do not apply all of them by default.

Keep a small before-and-after record for each chosen fix:

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

Record the scenarios again under the same cache, network, CPU, and viewport conditions. A successful result is not “the score increased.” It is a defensible explanation from request to pixels to interaction to cleanup, supported by traces that show the measured bottleneck changed.