STATIC APPLICATIONS / RELEASE CONTENTS

Every file.
Accounted for.

/ releases / example-02
index.htmltext/html
Choose a file to inspect its contents.
01 / PUBLICATION ORDER

ASSETS FIRST.
ENTRY POINT LAST.

Publish the files that a page depends on before pointing browsers at that page. A release is the complete set, not just its index.

[ READ THE PATTERN ↗ ]
02 / CACHE BOUNDARIES

Different files.
Different promises.

index.htmlCache-Control: no-cache

Revalidate the entry point so the browser can discover a new release.

assets/app.[hash].jspublic, max-age=31536000, immutable

Use a new filename when content changes. Keep an existing version unchanged.

manifest.jsonrelease identity + file checksums

Keep enough information to verify the exact files that were reviewed.

03 / REFERENCE NOTES[01]

Cache HTML and assets deliberately

READ ↗
[02]

Publish a coherent static release

READ ↗
[03]

Verify the release in a browser

READ ↗
04 / DETAILS THAT MATTER
Should every file use the same cache policy?+

No. Versioned immutable assets and the HTML entry point have different update requirements. Their policies should be designed together.

Can old assets be deleted after deployment?+

Only after the agreed retention period and compatibility checks. Existing tabs or cached documents may still refer to previous files.

What about service workers?+

They add their own update and cache lifecycle. Test that lifecycle explicitly, including open tabs and the transition between releases.

What do the bundled releases contain?+

They are representative release components used to explain the publishing workflow. They do not expose private builds or active deployment data.