Say something while the app is loading

[DanialBeg]

"when i initially go to the url i see this, i need to refresh to then see the main page"

The screenshot is the app working as written. That blank parchment rectangle is the loading screen: App.tsx rendered the background and the grain overlay and nothing else — a display: flex; align-items: center container with nothing to centre.

So a load that was merely slow was indistinguishable from one that had died, and reloading was the rational response. It works, because the second load has a warm token. The app was teaching people to refresh it.

What this fixes

A real loading screen, with two rules worth stating:

• The spinner waits 400ms. A load that resolves in 200ms should show nothing; a spinner flashed that briefly reads as jank, not speed.
• After 9s it admits it. "Still loading… your connection may have dropped", with a Reload button — the thing people were already doing. That is the error state PRODUCTION-TODO Add Aid Engine, educational content, and real college data #10 asked for.

Profile attempts also get 2.5s / 4s / 6s rather than a flat 6s, because a transient failure is likelier than a genuinely slow query and the old first attempt cost 6.6s before the retry began.

What this does not fix, and why there is nothing to fix

I first wrote the timeout change as a fix for the cold-start wait, claiming the initial fetch raced Supabase's token rotation. That was wrong, and reading the client says so plainly.

In auth-js 2.101.1, __loadSession refreshes an expired session itself before returning it:

const hasExpired = currentSession.expires_at
  ? currentSession.expires_at * 1000 - Date.now() < EXPIRY_MARGIN_MS : false
...
const { data: session, error } = await this._callRefreshToken(currentSession.refresh_token)

and onAuthStateChange waits for initialization and the lock before emitting:

await this.initializePromise
await this._acquireLock(this.lockAcquireTimeout, async () => { this._emitInitialSession(id) })

So INITIAL_SESSION only ever reaches our callback with a valid token. getProfile never races the rotation, and fetchProfile is not where a cold load spends its time.

The seconds go on the refresh round-trip itself — swapping a refresh token for a new access token — which happens before any of our code runs, on a first visit after the access token expired (1h by default) and not on an immediate reload. That matches the reported symptom exactly, and nothing in this repo can shorten it: an authenticated query cannot go out before the token it needs exists.

What we can do is stop showing a blank page during it. That is this PR.

Honest summary

~3s of "Loading your dashboard…" instead of ~7s of nothing. The blank page is gone. The cold-start delay is a required network call and is unchanged.

If you want certainty about the split between that refresh and everything else, the next step is measuring it on a real cold load with a real session, which I cannot do from here. Happy to add the instrumentation if the number matters.

Testing

533 passing, lint and typecheck clean, build succeeds. Four new cases on the timing, since that is what silently regresses: nothing before 400ms, text after, the stuck state with its reload at 9s, and role="status" / aria-live so it is not silence to a screen reader either.

(Force-pushed once to correct the commit message, which asserted the same wrong mechanism. No one else was on the branch.)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
webapp	Ready	Preview	Oct 1, 2026 11:47pm UTC

[cloudflare-workers-and-pages]

Deploying timeline-prototype with    Cloudflare Pages

Latest commit:	4ad7b70
Status:	✅  Deploy successful!
Preview URL:	https://09e5cbba.timeline-prototype.pages.dev
Branch Preview URL:	https://fix-blank-first-load.timeline-prototype.pages.dev

View logs