Improve Personal WP loading resilience#3756
Draft
akirk wants to merge 14 commits into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
Downloading PHP runtime 88% (17.9 MB / 20.3 MB).no data for 12s; waiting to resume.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:
Rangerequest from the last received byte.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
EmscriptenDownloadMonitorevents (fileName,fileLoaded,fileTotal).Rangerequests pass through the service worker without trying to cache partial206responses.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