perf(web): add cache headers for web UI static assets saving 90% data traffic in loading pages

[bowenliang123]

Related Issue

No linked issue — the problem is explained below.

Problem

The web UI's static assets (served by kap-server's web-assets routes) are sent with only Content-Type and Content-Length — no Cache-Control, no ETag, no Last-Modified. Browsers therefore receive no caching guidance at all and fall back to per-browser heuristic caching, so repeat visits to kimi web re-download JS/CSS bundles unnecessarily (or behave inconsistently across browsers).

What changed

One focused change in packages/kap-server/src/routes/webAssets.ts: serveWebAsset now stamps a Cache-Control header based on the file's location relative to the assets root:

• assets/ files (Vite's content-hashed build output, e.g. index-abc123.js) → Cache-Control: public, max-age=31536000, immutable. Content changes produce a new filename/URL, so caching them for a year is safe. This is the actual win: repeat visits load JS/CSS/fonts straight from disk cache with zero network requests, including on manual refresh (immutable).
• Everything else (index.html, SPA fallback responses, favicon, ...) → Cache-Control: no-cache. The entry document must be revalidated every load so a new release is picked up immediately and starts referencing the new hashed assets.

This is the standard "entry no-cache + hashed assets immutable" deployment pattern; the distinction is trivially reliable here because Vite always emits hashed files under dist/assets/.

Measured benefit

Built the real web UI (apps/kimi-web → dist) and served it through this route twice — once with the old code, once with the new — in a real Chrome instance, measuring transferred bytes via the Resource Timing API:

	cold load	refresh (warm)
before	2.03 MB	2.03 MB — every byte re-downloaded, nothing cached
after	2.03 MB	20.8 KB — main bundle (1.53 MB), CSS (360 KB), and fonts (114 KB) all served from disk cache with zero requests

So each repeat visit / refresh saves ~2 MB of transfer (~99% reduction; larger over the wire than these uncompressed localhost numbers since the same applies to gzipped bodies). Load time on localhost is dominated by other factors, but on any real network the difference is proportionally larger.

The remaining ~20 KB on warm loads is the index.html revalidation plus the root-level favicon.ico (17 KB, intentionally no-cache); adding ETag/304 support for root files could shrink that further but is out of scope here.

Checklist

• I have read the CONTRIBUTING document.
• I have linked a related issue, or explained the problem above.
• I have added tests that prove my feature works.
• Ran gen-changesets skill, or this PR needs no changeset.
• Ran gen-docs skill, or this PR needs no doc update.

[changeset-bot]

🦋 Changeset detected

Latest commit: 6c2e94a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@moonshot-ai/kimi-code	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

pnpm dlx https://pkg.pr.new/@moonshot-ai/kimi-code@6c2e94a

npx https://pkg.pr.new/@moonshot-ai/kimi-code@6c2e94a

commit: 6c2e94a

[bowenliang123]

Hi @wbxl2000 , could you consider reviewing this PR? It brings a performance improvement in page loading efficiency with minimal changes. It adds and sets the cache control to immutable, as the hashes in all generated files are always different.