Challenge 3: Apply the Methodology to a New Page — Possible Solution
====================================================================

SCENARIO: A documentation site with a large syntax-highlighted code
sample above the fold, and a heavy search-as-you-type widget.

STEP 1 — MEASURE FIRST (Lighthouse baseline)
-------------------------------------------------
Run Lighthouse to establish a baseline before touching anything. Given
what's described, expect the LCP timeline (Chapter 2) to likely flag
either the code sample's rendering (if it's syntax-highlighted via a
JS library that has to parse and re-render it) or a slow render delay,
and expect the INP/long-tasks panel (Chapter 4) to likely flag the
search widget, since "search-as-you-type" strongly implies a handler
firing on every keystroke.

STEP 2 — FIX LCP
--------------------
If the code sample is the LCP candidate and its syntax highlighting
requires JS to run before it's visually complete, that's exactly
Chapter 2's "client-side rendering" cause of poor LCP — the fix would
be to send the code block ALREADY highlighted in the initial HTML
(server-side or build-time syntax highlighting) rather than
highlighting it client-side after the JS bundle loads, removing an
entire step from the critical path. If a large hero-like image is
ALSO present above the fold, it would get the same preload + modern
format treatment from Chapters 2 and 5.

STEP 3 — FIX CLS
--------------------
Check whether the code sample's box has stable dimensions before and
after its syntax highlighting applies (a highlighted block sometimes
renders with slightly different sizing than plain unstyled text) — if
so, reserve space for it the same way Chapter 3 reserves space for
images, so the highlighting doesn't shift surrounding content once it
finishes.

STEP 4 — FIX INP
--------------------
This is very likely where most of the real work is: a search-as-you-type
widget is exactly the case Chapter 7 warned needs DEBOUNCING, not
throttling — firing an expensive search operation (filtering results,
possibly re-rendering a result list) on every keystroke is a strong
candidate for long tasks blocking the main thread (Chapter 4). Debounce
the search input so the actual search logic runs only once typing
pauses, and if the search itself does any DOM-heavy work (updating many
result elements), apply Chapter 7's batched-read-then-write pattern to
avoid layout thrashing while rendering results.

STEP 5 — ADD MONITORING
----------------------------
Wire up the web-vitals library (Chapter 8) to confirm the fixes hold
for real visitors, and set a performance budget specifically flagging
INP given how central it is to this page's main interactive feature (the
search widget) — this is the metric most likely to regress again if a
future change reintroduces expensive per-keystroke work.

WHY THIS WORKS AS AN ANSWER
------------------------------
The METHODOLOGY itself — measure, fix LCP, fix CLS, fix INP, monitor —
transfers directly to a completely different page with completely
different specific problems, exactly as the chapter's own concept card
describes it: "not specific to this one page... a repeatable process
for auditing any real page." The SPECIFIC techniques applied at each
step differ (server-side syntax highlighting instead of image preloading
for LCP; debouncing a search input instead of a scroll handler for INP),
but the ORDER and the underlying reasoning for that order stay
identical to this capstone's own worked example.