diff options
| author | Adam Soltys <[email protected]> | 2026-11-06 22:12:03 -0700 |
|---|---|---|
| committer | Adam Soltys <[email protected]> | 2026-11-06 22:12:03 -0700 |
| commit | efbc15065d78b1bbc0a841b628faf3f6b23ee0a0 (patch) | |
| tree | d8d2b6b6ee63013d5753be68374a9ba2b83f21f4 /android/app | |
| parent | 9886d4f1f51a6f0671d68ac3ba115e02b27ed474 (diff) | |
| download | coinosv3-efbc15065d78b1bbc0a841b628faf3f6b23ee0a0.tar.gz coinosv3-efbc15065d78b1bbc0a841b628faf3f6b23ee0a0.zip | |
Opening the app paints the installed build from the cache: no network wait, and no whole-build download on the first launch after a deploy. Navigations to / were network-first, so every launch waited on a round trip for the page, and after each deploy (several a day) the page it got named a new 1 MB entry bundle plus changed chunks (~650 KB compressed) that had to download before anything showed — seconds on a phone's data, which is where "so slow to load" (a user on the APK, 2026-11-05) comes from. Now / is cache-first from this build's own cache; the browser checks sw.js on the same navigation, a new build installs in the background (shell, entry and chunks together) and the next launch opens it. A refresh (request cache mode reload/no-cache) still goes to the network and gets the new build at once. Other paths (server-rendered note and profile pages) stay network-first, and only this build's own page is stored as its shell — before, any navigation's response (a profile page included) was put as './'. Navigation preload is on, so a network-bound navigation's request starts while the worker is still starting; cs nginx answers a launch's preload (no Cache-Control on it; a refresh sends max-age=0) with an empty 204, so a launch spends no bytes on a page it paints from the cache, and the worker then fetches normally if it does need it. Activation keeps the previous build's cache one deploy longer, so a page launched from the old shell still finds its lazily imported chunks. A page that installs a newer build while open no longer reloads under your hands: if nothing has been touched it reloads as it is put away, otherwise the new build waits for the next launch. tools/sw-reload-test.js covers launch (old build painted, page not fetched beyond an empty preload, new build installs, no reload, next launch opens it), refresh (new build at once, one load), an untouched open page (reloads only when hidden) and a used one (never reloads, older chunks still cached)
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Diffstat (limited to 'android/app')
0 files changed, 0 insertions, 0 deletions
