Skip to content

Improve Personal WP loading resilience#3756

Draft
akirk wants to merge 14 commits into
WordPress:trunkfrom
akirk:personal-wp-loading-resilience
Draft

Improve Personal WP loading resilience#3756
akirk wants to merge 14 commits into
WordPress:trunkfrom
akirk:personal-wp-loading-resilience

Conversation

@akirk
Copy link
Copy Markdown
Member

@akirk akirk commented Jun 6, 2026

What?

This PR improves Personal WP's loading experience on slow or unreliable connections. It was split out from the desktop relay prototype so the loading/network resilience work can be reviewed independently.

What users see

Personal WP now gives earlier and more specific feedback during boot:

  • An immediate preloading screen appears before React finishes loading, avoiding the blank/black/white screen gap.
  • The boot checklist follows real Playground runtime progress instead of staying on a vague repeated message.
  • The progress line stays visually stable instead of jumping between one and two lines.
  • PHP runtime downloads show percentage and transferred bytes, for example Downloading PHP runtime 88% (17.9 MB / 20.3 MB).
  • If no bytes arrive for several seconds, the progress line says so, for example no data for 12s; waiting to resume.
  • Later boots can show when the PHP runtime is already available from the build-versioned cache.

How this helps repeated attempts

The large PHP WebAssembly runtime must be fully available before WordPress can finish booting. Previously, if that download stalled near the end, the user saw little actionable information and a reload often meant starting the same large download again.

With this PR:

  1. The page keeps already received bytes in memory while it remains open.
  2. If the PHP runtime response stalls, the loader retries with a Range request from the last received byte.
  3. When the resumed download completes, the assembled full response is stored in the normal Playground CacheStorage cache for the current build.
  4. A later reload can use the cached PHP runtime instead of downloading it again.

This does not persist partial downloads across a page reload. The benefit is that a stalled first attempt can recover while the page is still open, and once it completes successfully, future attempts for the same build can reuse the cached full runtime.

Implementation notes

  • Adds per-file download metadata to EmscriptenDownloadMonitor events (fileName, fileLoaded, fileTotal).
  • Uses those per-file details to label downloads more accurately instead of using a generic "runtime assets" caption.
  • Adds an in-memory resumable fetch path for the PHP runtime download.
  • Lets deliberate Range requests pass through the service worker without trying to cache partial 206 responses.
  • Writes the reassembled full runtime response into the existing build-versioned offline cache.

What is not included?

This intentionally excludes the desktop relay/viewer work. There is no relay.php, desktop viewer/connect UI, tunnel host, relay URL rewriter, or desktop traffic diagnostics in this PR.

Testing

npm exec nx typecheck php-wasm-progress
npm exec nx typecheck playground-client
npm exec nx typecheck playground-remote
npm exec nx typecheck playground-personal-wp

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant