You’ve all seen it: a protected page loads, shows its content for a split second, then snaps to the login screen. That flash of private content before the redirect is a bad look — and on some apps, a real leak. It happens because the redirect decision is made too late, in the browser, after the page already rendered.
Why the flicker happens
The page renders, a useEffect runs, it sees no session, and only then redirects. By that point the protected UI has already painted. Moving the check earlier removes the flash entirely.
Decide on the server
In Next.js, check the session on the server — in middleware or a Server Component — and redirect there. The browser never receives the protected HTML for an unauthenticated user, so there’s nothing to flash. Middleware is ideal for whole sections of the app: it runs before the page, checks the session cookie, and redirects unauthorized requests before render.
For finer control, check the session inside a Server Component and redirect from there. Either way, the decision happens on the server, not after a client round trip.
If you must do anything client-side, render a neutral loading state — never the real content — until auth resolves. But the clean answer is to stop the protected page from rendering for the wrong user in the first place.