Choosing between bundler inlining and CORS headers for p5.js asset loading in production

Answer first

For a static-site deployment with same-origin assets, neither CORS nor inlining is required for loadImage() / loadSound(). If assets are served from a different origin than the page, CORS headers minimize ongoing maintenance versus bundler inlining. Inlining is lower maintenance only on restrictive hosts that cannot set headers.

Cache invalidation: CORS-based loading allows independent asset versioning. Inlining forces a JS bundle rebuild and redeploy for any asset change.

A hybrid strategy is preferable when you have many small UI assets and a few large media files: inline small icons under ~10KB as data URLs, serve large textures and audio via CORS-enabled same-origin or CDN URLs.

Likely explanation vs confirmed facts

Confirmed: p5.js loadImage and loadSound use XHR/fetch under the hood. Browsers block reading binary data from a different origin unless the response includes Access-Control-Allow-Origin. Data URLs imported by a bundler are same-origin by definition and require no runtime network request.

Likely: The CORS errors described for relative paths in production usually indicate assets are being requested from a different origin than the page, e.g., a CDN, S3 bucket, or a sub-domain, or the page is being served with a different scheme/host than the asset base. With true same-origin relative paths, CORS is not triggered.

Maintenance impact

• Approach A - CORS headers: One-time server/CDN configuration. After that, assets can be updated independently without touching the sketch code or build. Maintenance cost is tied to hosting provider config files such as netlify.toml, vercel.json, or S3 CORS rules.
• Approach B - Bundler inlining: Eliminates CORS configuration and works on hosts that cannot set headers. Maintenance cost is build complexity: every asset change requires a rebuild, and the JS payload grows. Base64 data URLs add ~33% size overhead.

Cache invalidation behavior

When hybrid is preferable

• Inline very small assets < ~8-10KB where request overhead dominates. Typical: UI sprites, small icons, short UI sounds.
• Serve large textures, audio files, video via CORS-enabled URLs to keep initial JS small and allow streaming and independent caching.
• Use hybrid when you already have a build step and want to reduce HTTP requests without inflating TTI.

Scoped verification steps

1. Open DevTools Network tab and load the sketch. Confirm the request URL origin matches the page origin.
2. If origins differ, inspect response headers for Access-Control-Allow-Origin.
3. Compare transferred size of main JS bundle with inlining enabled vs disabled.

One missing diagnostic detail that changes the recommendation: Are the assets served from the same origin as the HTML page in production, or from a different CDN/domain? If same origin, use relative paths with no CORS or inlining. If different origin, CORS headers are the lower-maintenance default.