Challenge 3: Design a Performance Budget — Possible Solution
====================================================================

SCENARIO: A content-heavy blog site (not an interactive app).

PROPOSED BUDGET RULES
------------------------

1. LCP must stay under 2.5 seconds (Good threshold, per Chapter 1)

   Justification: A blog's primary content — usually a hero image or
   the article's opening text/headline — IS very likely the LCP
   candidate itself (Chapter 2). Since a blog's whole purpose is
   getting readers to that content quickly, keeping LCP within the
   "Good" range directly protects the core reading experience this
   site exists to deliver.

2. Total JavaScript must stay under 150KB (compressed)

   Justification: A CONTENT-heavy blog, as opposed to an interactive
   app, has fundamentally less legitimate NEED for large amounts of
   JavaScript — most of the page is static text and images, not complex
   client-side interactivity. A relatively low JS budget (compared to
   what an app might reasonably need) reflects that this site's actual
   requirements are modest, and helps catch scope creep — a comment
   widget here, an analytics script there — before it accumulates into
   a meaningfully bloated bundle competing for the main thread (Chapter
   4/7's INP concerns) that a static content site has little genuine
   need for.

3. No single image may exceed 200KB

   Justification: Blog posts are often image-heavy (illustrative
   photos, screenshots, diagrams), making per-image weight a real,
   recurring risk specific to this type of site — an author dropping in
   an unoptimized, full-resolution photo is a common, easy mistake.
   Capping individual image size (rather than only a page-total image
   budget) catches this exact mistake at the point it's introduced,
   reinforcing Chapter 5's optimization techniques (modern formats,
   compression) as an enforced requirement rather than just a
   recommendation.

WHY THIS WORKS AS A DESIGN
------------------------------
Each rule is a CONCRETE, checkable number (not a vague goal like "make
it fast") — exactly what the chapter describes budgets needing to be in
order to be enforceable in CI. The choices are also tailored to what
THIS SPECIFIC type of site (content-heavy, not an app) actually needs:
a strict LCP budget because that's the core promise of a content site,
a comparatively strict JS budget because a static blog has little
legitimate need for heavy client-side code, and a per-image cap because
images are this particular site's most likely source of accidental
bloat — rather than copying a generic budget that might fit a different
kind of site better.