perf: serve images at the size the page actually shows

[yorkerhodes3]

What

Images were committed at their original camera resolution and served unchanged. output: "export" requires images: { unoptimized: true } — GitHub Pages has no image optimization server — so next/image does no resizing, emits no srcset, and does no format negotiation. The committed file is exactly what every visitor downloads.

Nothing in the intake resized anything, so headshots went up straight from a phone. team/alex.jpg was 2644×2644 / 1,096 KB to fill a 48px circle, and /team weighed 8.5 MB.

95 images, 16.01 MB → 4.57 MB (−71%).

Route	Before	After	Change
/team	8.5 MB	2.1 MB	−76%
/demos	4.6 MB	2.4 MB	−48%
/media	3.5 MB	2.4 MB	−32%
/	2.3 MB	1.3 MB	−46%
/team/<person>	2.6 MB	1.1 MB	−60%

This matters more here than on most hosts: GitHub Pages serves everything with Cache-Control: max-age=600 and will not allow custom headers, so a returning visitor re-pays the full weight every ten minutes. Sending fewer bytes is the only available lever.

Analysis and method: docs/PERFORMANCE.md.

How

• scripts/optimize-images.mjs resizes in place against a per-directory budget (avatars 384px, logos 256px, posters 600px, summit 1200px, backgrounds/heroes 1600px), with per-file overrides.
• npm run check:images runs in CI, so the next oversized headshot fails the pull request instead of shipping.
• Budgets documented in CONTRIBUTING.md and public/team/README.md.
• sharp promoted from a transitive next dependency to an explicit devDependency.

Reviewer notes

Formats and filenames are unchanged on purpose. Converting to WebP would have saved another ~10%, but renaming an asset means editing every reference in src/content, and a missed one fails silently — TeamAvatar falls back to initials rather than showing a broken image. Nearly all of the win is the resize.

A silent corruption bug this nearly shipped. sharp's png({ effort }) and png({ palette }) put libvips into its palette-quantizing path, which drops the alpha channel on some images. It hit four logos. coinbase.png is mostly transparent, so it would have rendered as a solid dark rectangle on the white logo tile — while passing the build, the byte budget, and every automated check. The encoder now uses compressionLevel only and verifies transparency survived. Worth knowing before anyone tunes the encoder for a few more KB.

Lossy and irreversible. Every image was re-encoded in a single pass from the originals, so there is no generational loss. Full-resolution originals remain in git history at 32e1ab9f.

Two commits, split per CONTRIBUTING §4 — source first, then the generated static-site/ snapshot, so the real diff stays reviewable.

The __next.* prefetch payloads are deliberately untouched in the snapshot commit. Next writes those with a platform-dependent path shape, so regenerating on Windows would delete 140 Linux-shaped files and add 75 Windows-shaped ones with no content change. CI excludes them from its drift check for the same reason (UPD-004).

Verification

• CI already passed on this exact commit on Linux: run 32882271054 — lint, typecheck, content invariants, image budgets, build, and snapshot drift all green.
• All 95 images compared against their originals: 0 lost transparency, 0 changed aspect ratios, 0 decode failures.
• The CI gate was negative-tested — re-adding the 2644px headshot fails with the command that fixes it.
• The optimizer is idempotent; a second run is a confirmed no-op, so it never re-compresses a compliant file.
• Spot-checked /team, a profile page, /demos, and the partner logo band in both dark and light themes.

Also: EXIF is stripped after orientation is applied, which removes any GPS coordinates the cameras recorded on the published headshots.

Not included

Responsive srcset, lower book-render scale, lazy book pages, and removing /font-lab are tracked as UPD-015 and UPD-016. The font lab is recent in-flight work, so removing it is its author's call.