What it does

Short-circuits PHP for WordPress static assets that are known to live outside the minified in-memory WordPress build.

When a request path appears in wordpress-remote-asset-paths, the service worker fetches it directly from the WordPress static assets directory instead of first converting the request into a PHP request.

Rationale

Minified WordPress builds intentionally omit many CSS, JS, image, and font files. Today, those requests still go through PHP, return a PHP-side 404, and only then fall back to the remote static assets directory.

The service worker already knows which paths were removed from the minified build, so the PHP round-trip is avoidable.

Local benchmark against origin/trunk at 309c44e9e, using npm run dev, Chromium headless, WordPress 6.8, ?storage=temp&wp=6.8, 5 fresh browser contexts per branch. Numbers are medians.

Implementation

PlaygroundWorkerEndpoint keeps the known remote asset paths collected during boot and exposes them through getWordPressModuleDetails().

The service worker checks GET and HEAD requests against that path list before calling into PHP:

1. Apply the WordPress rewrite rules to the scoped URL.
2. Check the normalized path against remoteAssetPaths.
3. If it matches, rewrite the URL to staticAssetsDirectory and fetch it directly.
4. Otherwise, use the existing PHP request path and PHP 404 fallback.

This preserves existing behavior for unlisted paths, dynamic routes, and user-modified files. Empty asset-list entries are ignored, and root requests are never treated as remote assets.

Testing instructions

npm exec nx test playground-remote -- --runInBand
npm exec nx typecheck playground-remote
npm exec nx lint playground-remote

Benchmark artifacts were saved locally under .context/benchmarks/first-two-prs/.