In Selenium 4, how do the pageLoadStrategy values normal, eager and none change when navigation returns?
answer
- Three keywords, one session-wide setting
- It picks a readyState target
- The default is the strictest one
- interactive sits between the other two
- Fixed at session creation, never changed later
basics
~10 sSelenium's pageLoadStrategy picks which document readiness state a navigation waits for: normal waits for complete, eager waits for interactive, and none returns straight away. Normal is the default in Selenium 4.
solid answer
~40 sA navigation command blocks until `document.readyState` reaches the readiness target that the session's `pageLoadStrategy` capability names. `normal`, the Selenium 4 default, targets `complete`, so the `load` event has fired and declared subresources are done. `eager` targets `interactive`, returning once the DOM is parsed while images and late scripts may still be arriving. `none` names no target and returns essentially at once, so the document may still be at `loading`. The page load timeout is the ceiling on whichever wait applies. Loosening the strategy does not remove waiting; it moves it into your own readiness checks, because the driver has stopped absorbing the page's settling time for you. It is a capability fixed when the session is created, applies to the whole session, and no command changes it afterwards.
go deeper
Learn the three keywords and the readiness state each targets, and that normal is the default. Being able to say that none returns without waiting is enough at this stage.
An interviewer expects the mechanics: the driver blocks until document.readyState reaches the target the keyword names, the keyword is a session capability rather than a command, and the page load timeout bounds whichever wait applies.
Demonstrate that loosening the strategy moves waiting out of the driver and into your code, and that the resulting failures show up as intermittent missing elements right after navigation rather than as slow tests.
Own the tradeoff at suite scale: the strategy is fixed per session, so choosing it is choosing how much settling time the platform absorbs for every test at once, and what readiness discipline the team must then guarantee everywhere.
## What the strategy is actually choosing between A navigation command does not return when the response bytes arrive. Under the W3C WebDriver model the driver runs a step called *wait for navigation to complete*, and that step blocks until the document's `document.readyState` reaches a **readiness target**. The `pageLoadStrategy` capability is the setting that picks which readiness target counts. It is the difference between a test that opens the community garden's plot map and sits through every tile image, and a test that gets control back as soon as the plot grid's markup is parsed. Three keywords are defined, and only three; anything else is rejected with an `invalid argument` error at session creation. | Keyword | Readiness target | Navigation returns when | Typical cost | |---|---|---|---| | `normal` | `complete` | the `load` event has fired | slowest; waits for every image, stylesheet and script | | `eager` | `interactive` | `DOMContentLoaded` has fired | the plot grid markup is parsed, tiles may still be arriving | | `none` | none | immediately | no waiting at all; the document may be at `loading` | `normal` is the **default**, and it is what a Selenium 4 session uses when nothing sets the capability. ## What each keyword buys and gives up - `normal` gives the strongest guarantee: the `load` event has fired, so subresources the document declared have finished. It also means one slow third-party asset on the plot map - a tile CDN, a weather widget - holds the whole navigation open. - `eager` returns at `interactive`. The DOM is parsed and searchable, so a locator for `.plot-tile` will find the elements the server rendered, but images and late scripts may still be in flight. - `none` returns essentially at once. The driver has guaranteed only that it stopped waiting; `document.readyState` may still be `loading`, and a locator run immediately afterwards can legitimately find nothing. ## Where it is set, and why it cannot change later `pageLoadStrategy` is a **capability**, not a command. It is negotiated when the session is created - in Java through the typed options object, for example `ChromeOptions.setPageLoadStrategy(PageLoadStrategy.EAGER)`, whose enum constants are `NORMAL`, `EAGER` and `NONE` and whose wire spellings are the lowercase strings. That has one consequence people trip over constantly: 1. The strategy applies to the **entire session** - every navigation, in every test that shares the driver. 2. There is **no WebDriver command to change it mid-session**. The timeouts endpoint changes timeouts; nothing changes the load strategy. 3. If one test needs a different strategy, it needs a different session. This is exactly the opposite of the **page load timeout**, which is ordinary session state you can POST to `/session/{sessionId}/timeouts` at any moment. Strategy is fixed at birth; the timeout is not. ## The gap that eager and none hand back to you Loosening the strategy does not remove waiting from the test - it moves the waiting from the driver into your code. Under `normal` the driver absorbed some of the page's settling time on your behalf. Under `eager`, and far more so under `none`, whatever the plot map renders after `interactive` is now your problem, and you notice it as an intermittent `NoSuchElementException` on the first locator after navigation rather than as a slow test. Two rules follow: - Every element the test touches after a loosened navigation needs its own readiness check. The strategy changed *when the driver stopped blocking*; it changed nothing about *when the plot tiles exist*. - The saving is real only when the thing you stopped waiting for is genuinely irrelevant to the assertions - decorative imagery, analytics beacons, an embedded weather panel the test never reads. - The failure mode is recognisable: the first locator after a navigation fails on some runs and passes on others, always on the element that renders latest. - The **page load timeout** still applies, but it now bounds a much shorter wait, so raising or lowering it has far less effect than it did under `normal`. ## The single-page-application trap `readyState` describes the **document**, not the application. On a plot map that fetches its plot list over XHR and renders client-side, `complete` fires when the shell document finished, which can be long before a single plot tile exists. That is true under `normal` as well, so the frequent claim that "the page load strategy is why my SPA test is flaky" has it backwards: `normal` was never a guarantee that the application was ready. `eager` and `none` widen an already-existing gap; they do not create it. The honest summary is that `pageLoadStrategy` is a **latency control on navigation**, not a correctness control. It decides how much of the document load the driver sits through before giving control back, and everything after that point is the responsibility of whatever readiness check the test performs next.
- Can a test switch from normal to eager partway through a session?No. `pageLoadStrategy` is a capability negotiated when the session is created, and WebDriver defines no command that changes it afterwards. The timeouts endpoint changes timeouts only. A test that needs a different strategy needs its own session, which is why the choice is usually made once for a whole suite.
- With none, what has the driver actually guaranteed by the time the navigation call returns?Only that it stopped waiting. The specification's wait-for-navigation step returns immediately for `none`, so `document.readyState` may still be `loading` and the document may have almost nothing in it. Every element the test touches next needs its own readiness check, or the first locator after navigation will fail intermittently.
- Does eager help a page that renders its content client-side?Barely. `readyState` describes the document, not the application, so `complete` can fire long before client-rendered content exists. Under `normal` that gap was already there; `eager` widens it. The saving from `eager` is real on asset-heavy documents, not on pages whose content arrives after the document has finished loading.
It is like deciding when to walk into the garden shed: normal waits until every tool is back on its hook, eager walks in as soon as the floor is clear, and none opens the door the moment the key turns.
saying these in an interview costs you the question
- Says eager waits for the load event, which is what normal targets
- Believes none cancels the page load rather than just not waiting
- Thinks pageLoadStrategy can be switched between tests in one session
- Claims normal guarantees a client-rendered application is ready
- Confuses the strategy with the page load timeout's ceiling on the wait