Loading-Strategy Sweep: Images, Fonts, Third-Party Scripts

Tier: Foundation · Workflow area: Performance & debugging

Where pb-34 closes the loop on a failing metric with traces, this playbook is the broad, cheaper sweep you run first (or routinely): systematic, low-risk wins across every asset on a route.

When to use

• •
  A route has never had a loading-strategy pass, or Lighthouse lists the classic opportunities: properly size images, preconnect, render-blocking resources, reduce third-party usage.
• •
  New marketing pages, CMS-driven pages, or AI-generated pages went live without asset review — generators emit <img src> with no dimensions, sizing, or priority thinking.
• •
  You want a repeatable pre-release checklist for pages your team ships weekly.
• •
  Preparation for the deeper loops: sweeping the obvious weight first makes pb-34's traces cleaner.

Skip it for app-like authenticated surfaces with almost no images/fonts/third-parties — your budget lives in JS there (pb-35, pb-36).

Prerequisites

• •
  Lighthouse runnable against the target route (DevTools, CLI, or PageSpeed Insights for public URLs), with a saved baseline report.
• •
  Access to the rendered HTML and the templates/components that produce it.
• •
  Knowledge of your framework's asset primitives (next/image, next/font, or your bundler's equivalents) — the sweep's fixes should land on the paved road where one exists.
• •
  A list you can get answered: what each third-party script is for and who owns it. Half the third-party wins are organizational, not technical.

The workflow

1. 1.

   Capture the baseline and the inventory. Run Lighthouse (mobile config) and save the report. Then collect the asset inventory for the route: every <img>/<picture> with its rendered vs intrinsic size, every @font-face/font link, every third-party <script>/iframe with its size and timing. An agent with DOM access (chrome-devtools-mcp, or paste the rendered HTML plus the network panel's export) builds this table in one pass.

2. 2.

   Audit images against the strategy checklist. Have the assistant mark each image row against:

   • •
     Modern format (AVIF/WebP with fallback) and compression appropriate to content.
   • •
     Responsive sizing: srcset/sizes (or framework image component) so a 400px card never downloads a 2000px original.
   • •
     Explicit width/height (or aspect-ratio) so nothing shifts — this is also a CLS fix.
   • •
     Priority correct: the LCP/hero image eager with fetchpriority="high" (and preloaded if discovered late); everything below the fold loading="lazy".
   • •
     Decorative backgrounds not blocking anything.

   The output is per-image: current state, target state, which template to edit.

3. 3.

   Audit fonts. For each family: is it self-hosted (third-party font CSS adds a connection chain), subset to the scripts you actually use, loaded as WOFF2, declared with font-display: swap (or optional for non-brand-critical faces), and is the primary text face preloaded? Cap the sweep at reducing weights/styles too — four families in nine weights is a design conversation the audit table makes concrete.

4. 4.

   Audit and interrogate third parties. For each third-party script: what does it do, who asked for it, what does it cost (KB, main-thread ms from the Lighthouse third-party summary), and does it need to be there at all? Then apply the strategy ladder — remove > facade (embed loads on interaction, e.g., video thumbnails) > delay to idle/consent > defer/async with preconnect — never leave a tag synchronous in <head> by default. Route every "can we remove it" to the named owner; the sweep's biggest wins are usually deletions someone just had to ask about.

5. 5.

   Apply, re-run Lighthouse, and diff. Land the changes in small PRs by asset class. Re-run Lighthouse under the same config and compare: the specific opportunities should shrink or vanish, and LCP/CLS should move. Paste the before/after opportunity rows into the PR. Where the framework has a paved road (next/image, next/font), prefer migrating to it over hand-tuning attributes — the road keeps future pages compliant automatically.

Tool variants

• Lighthouse (DevTools / CLI / PSI): the bookends — baseline and proof. The CLI (lighthouse --output json) makes the before/after diffable in CI.
• DevTools AI assistance + chrome-devtools-mcp: lets an agent read the live DOM and network waterfall to build the inventory itself instead of you exporting it.
• Any chat assistant: given rendered HTML and the network export, produces the same audit tables — this playbook needs no agentic tooling.
• Framework primitives:next/image/next/font, Angular's NgOptimizedImage, or your CDN's image transforms — the preferred landing place for image and font fixes.

Verification

• •
  Every inventory row has a disposition: fixed, deliberately kept as-is (with reason), or ticketed to an owner.
• •
  Lighthouse before/after under identical config shows the targeted opportunities reduced and no regression in other categories.
• •
  The hero/LCP image is verifiably prioritized (network panel shows it early, high priority) and below-fold images verifiably lazy.
• •
  No layout shift from media: CLS contribution from images/embeds/fonts is near zero in the report.
• •
  Each remaining third-party script has a named owner and a stated reason to exist.

Pitfalls

• Lazy-loading the LCP image. The classic self-inflicted wound — blanket loading="lazy" applied by a sweep (or a generator) to the hero image adds hundreds of ms to LCP. Priority is per-image; that is why the inventory has rows.
• Trusting the model's attribute knowledge over the network panel. Assistants sometimes emit stale or wrong loading attributes and preload syntax. The network waterfall shows what the browser actually did; verify against it.
• font-display: swap as a cure-all. Swap trades invisible text for layout-shifting reflow; pair it with metric-compatible fallback fonts (size-adjust) or optional where the brand allows, and check CLS after.
• Deleting third parties unilaterally. That forgotten pixel may be how marketing attributes half its budget. The ladder starts with asking — removal is an owner's decision the audit table informs.
• Auditing the empty state. CMS pages vary; audit representative content-heavy instances, not the sparsest page the route can render.
• One-time sweep, no guardrail. Next quarter's pages regress without a paved road and a Lighthouse CI assertion on the route. Lock the class of win in, not just the instances.

Restricted-environment variant

The sweep runs against your own pages with local tools; the only data leaving is HTML and network metadata if you use an external assistant.

• In-tenant assistant: full workflow unchanged — the audit tables are just structured reading of your own page.
• Local model: checklist-driven auditing of an HTML/network inventory is comfortably within local-model range; the checklist in steps 2–4 rides in the prompt.
• No model: this playbook is the checklist — a human with the network panel and steps 2–4 completes the same sweep in an afternoon.

Success criteria

• •
  The route's Lighthouse opportunities for images, fonts, and third parties are cleared or explicitly dispositioned, with LCP and CLS measurably improved.
• •
  New pages inherit the wins automatically via framework primitives and templates — the next audit finds an already-clean inventory.
• •
  The third-party list is smaller, owned, and reviewed on a cadence; nothing loads synchronously in the head without a written reason.
• •
  The sweep is a documented pre-release checklist item that a mid-level engineer runs unassisted in under two hours per route.