Modern Frontends Don’t Have One “Ready” State

A lot of browser tests are still written around a simple mental model:

1. Open the page.


2. Wait for it to load.


3. Interact with the final UI.


4. Assert that the expected result appears.

That model worked reasonably well when pages arrived as complete documents and JavaScript added a few interactions afterward.

Modern frontends are different.

The page can be visible before it is interactive. A component can render three times before it settles. Text can arrive before the buttons around it. A skeleton can disappear while the real content is still being measured. A route transition can keep the previous screen in the DOM for a few hundred milliseconds. A theme preference can be applied after hydration and briefly produce the wrong colors.

There is no longer one obvious moment when the page is “ready.”

That is why some test suites look healthy in CI while users still report flickering controls, broken keyboard focus, stale content, or clicks that land on elements that are about to disappear.

The intermediate UI is part of the product

Teams often treat loading states as temporary implementation details. Users do not experience them that way.

A user on a slower device may spend several seconds looking at a skeleton screen. Someone opening a server-rendered page may try to click before hydration finishes. A user with reduced-motion preferences may receive a completely different transition path. A returning user may see the wrong theme for half a second before local storage is read.

These are real product states, even if they are short-lived.

A useful starting point is to stop asking only:

Did the final screen appear?

Instead, ask:

What states did the user pass through before the final screen appeared?

That shift immediately changes what you test.

For server-rendered applications, it is worth tracking whether your suite can actually detect client/server divergence rather than merely waiting until the browser repairs it. This guide on explores why this is especially difficult for AI-driven automation.

“Visible” is not the same as “stable”

A visible element can still be unsafe to interact with.

It may be:

• moving because a font has just loaded;


• covered by a fading transition layer;


• attached to a component that is about to re-render;


• a placeholder that will be replaced;


• part of the previous route;


• visually complete but not yet connected to event handlers.

This is one reason fixed sleeps are so seductive. A two-second pause seems to make the problem disappear.

Until CI gets slower. Or the application gets faster. Or an animation duration changes. Or a third-party request takes 2.3 seconds.

A stronger test waits for a meaningful application condition. That might be the disappearance of a loading marker, the presence of the final record count, the completion of a network request, or a stable element that remains attached across consecutive checks.

Skeleton screens deserve particular attention because they can create both false positives and false negatives. A test may mistake a skeleton row for a real record, or wait for all placeholders to disappear even though infinite scrolling intentionally keeps one visible. offers a good framework for doing that without filling the suite with arbitrary delays.

Persisted preferences create hidden branches

Theme switching looks simple until persistence enters the picture.

A complete test may need to cover:

• the default theme for a first-time visitor;


• the operating system preference;


• a manually selected theme;


• persistence after refresh;


• persistence in a new tab;


• behavior after logout;


• synchronization across sessions;


• contrast and icon changes;


• the brief state before stored preferences are applied.

This is not just a visual regression problem. It is also a browser-state problem.

The comparison in examines that exact pressure. Two related evaluations——are also useful when comparing maintenance approaches.

The broader lesson is tool-independent: design tests around stable product intent rather than incidental markup.

A test should care that the user can submit an invoice, not that the third nested <div> contains a button with exactly the same text forever.

That does not mean avoiding precise assertions. It means being precise about outcomes while being deliberate about which implementation details deserve to become dependencies.

A better model for frontend readiness

For each important workflow, define readiness at three levels:

1. Render readiness

Is the expected structure present?

This catches missing components, server failures, and major rendering problems.

2. Interaction readiness

Can the user actually operate the interface?

This includes event handlers, focus behavior, overlays, enabled controls, and elements that are no longer moving or being replaced.

3. Business readiness

Has the application reached the state that matters?

For example, the order appears in the account, the preference survives refresh, or the newly created record is available from another screen.

Many flaky tests stop at render readiness and immediately perform a business action. The unstable space between those levels is where failures hide.

Test the journey, not just the screenshot at the end

Modern frontend testing is increasingly about transitions between states.

A robust suite observes:

• what appears first;


• what changes next;


• what can be interacted with at each point;


• which state is persisted;


• which state is temporary;


• what happens when rendering is interrupted;


• whether accessibility preferences produce a different path.

The final screen still matters. It is just no longer the entire story.

When a team starts treating hydration, streaming, animation, skeletons, and preference restoration as first-class behavior, a surprising number of “random” failures become understandable. More importantly, the suite starts catching the same awkward moments that users notice before those moments become support tickets.