A photo, a logo, a screenshot — the pictures on your site, and what they weigh.

1. 1

   A picture in the design

   A logo, an icon, a background — checked into the repository and shipped with the build, the same as any other file in it.

2. 2

   A picture in the content

   A hero photo, a screenshot, a diagram — swapped in as a briefed change, alongside the words around it. See Content.

3. 3

   A picture a visitor uploads

   An avatar, an attachment, a photo added while the site runs. It needs a writable disk, which a static build does not have. See Files.

• Page-weight budget

  60.0 KB per route, enforced on every deploy.

• Heaviest route measured

  35.6 KB, across 87 routes on this site.

• An unoptimised image

  A single uncompressed photo can outweigh everything else on a page put together. Brief it — "compress the hero image" — and the pull request that resizes and re-encodes it is ready to review.

1. 1

   Source file in the repository

   Committed the same way any other file is, at whatever size and format it arrived in.

2. 2

   Build

   Bundled into the site by the same pipeline that ships every other change.

3. 3

   Content-hashed filename

   A changed picture gets a new address instead of overwriting the old one, so a cached copy anywhere is always safe.

4. 4

   Edge cache

   Held close to the visitor asking for it, the same as any other file whose name changes with its content.

5. 5

   Browser

   Decoded and painted onto the page, reserving the space its declared width and height ask for.

Files whose name changes with their content. Your stylesheets and scripts get the content written into their filename. A changed file gets a new address instead of overwriting the old one, so holding onto a copy of it anywhere is always safe.

• The right dimensions for the space

  A photo shown at 400 pixels wide should not ship at 4000. Brief the size the design actually uses.

• A modern format

  A format built for the web compresses further than an older one at the same visible quality. Brief the swap; the pull request re-encodes it.

• Real compression

  Most images leave a camera or a design tool uncompressed. Briefing "compress this" is most of the work on its own.

• Lazy loading, with width and height set

  A picture far down the page can wait to load. Declaring its width and height in advance stops the page jumping once it arrives.

Swapping a picture without swapping its alt text leaves a screen reader describing the old one. Briefing the two together is what keeps them matched.

1. 1

   You notice it

   You

   A hero image that takes a moment to appear, or a photo that dwarfs the page around it. A person looks at the page and sees it.

2. 2

   You brief the picture

   You

   Say which picture, and what it should do — "compress the hero image", or "this photo only ever shows at 400 pixels wide".

3. 3

   Briefed as a change

   CustomLabs

   Written up the same way any other change request is. The iteration add-on is what covers it.

4. 4

   An agent opens the pull request

   CodeHerder

   The resized picture lands as a real pull request against the repository, with the test suite run against it.

5. 5

   A human reviews and merges

   CustomLabs

   Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.

6. 6

   It ships through the same pipeline

   CustomHosted

   The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit.

7. 7

   You're told it's done

   CustomHosted

   A note confirming what changed and that it merged, in the same shape as every other note on this site.

• No separate line item

  A picture change is a briefed change like any other, covered by the same Agentic iteration — CodeHerder add-on ($25/mo).

• Its weight counts toward transfer

  The bytes a picture ships still draw from the same fair-use transfer allowance every other file does. Static Starter allows ~100 GB transfer/mo, and Static Pro allows ~500 GB transfer/mo. See Billing.

• Every image this site ships is a generated social card, rendered from one component at 1200×630 and re-rendered whenever a design token changes. This build ships 66 of them.
• Each one is checked against a per-image ceiling of 90 KB on every deploy. A picture over that ceiling fails the build before it ships.

• An unresized image

  Serving a large photo at a small width burns transfer and memory for no visible gain. Resizing it at build time often does more than moving up a tier would. See Scaling.

• A picture too heavy for the page budget

  A large image can push a page past its own published weight budget. Resizing it before it ships is part of the same briefed change. See Performance.

• A picture that jumps the layout as it loads

  A picture with no declared width and height gives the browser nothing to reserve space with, so the text around it jumps once it arrives.

• A picture swapped without its alt text

  The new picture ships, and a screen reader keeps describing the one it replaced. See Accessibility.

• No image resizing service

  A picture is not resized, converted, or compressed for you at the moment a visitor requests it. Every change to a picture ships as a briefed pull request.

• No format conversion at request time

  The format a picture ships in is the format it was briefed and built with, not one chosen per visitor.

• No media library or asset browser

  There is no screen to log into and pick a picture from. Every picture is a file in the repository.

• No stock photography

  We host and ship the pictures you brief us. Sourcing a picture to use is yours.