Implicit Waits
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)) sets a single global polling timeout applied to every findElement/findElements call for the lifetime of that WebDriver instance: if an element isn't immediately found, WebDriver retries locating it repeatedly until the timeout elapses before finally throwing NoSuchElementException. Because it's global rather than element-specific, mixing implicit waits with explicit waits in the same test is discouraged — the combined wait times can compound unpredictably, sometimes making a test wait far longer than either timeout alone would suggest.
Cricket analogy: An implicit wait is like a ground announcer giving a blanket 10-minute delay rule for rain across the entire match — it applies globally to every stoppage, which can cause confusing double-delays if you also apply a specific delay to one particular over.
Explicit Waits
WebDriverWait paired with ExpectedConditions targets one specific element and one specific state, polling repeatedly until that condition becomes true or the timeout expires. new WebDriverWait(driver, Duration.ofSeconds(15)).until(ExpectedConditions.visibilityOfElementLocated(By.id("result"))) only waits for that particular element to become visible, rather than applying a blanket delay everywhere. Common conditions include elementToBeClickable, presenceOfElementLocated, visibilityOfElementLocated, and textToBePresentInElement — each targeting a different aspect of an element's readiness.
Cricket analogy: An explicit wait with ExpectedConditions.visibilityOfElementLocated is like a twelfth man being told to specifically watch for the moment the physio waves them onto the field, rather than just waiting a fixed generic amount of time before walking on.
Fluent Waits
FluentWait, built via new FluentWait<>(driver).withTimeout(...).pollingEvery(...).ignoring(NoSuchElementException.class), is the most configurable of the three: it lets you set a custom polling interval (rather than the default 500ms explicit-wait polling) and specify which exceptions to swallow silently while polling, such as ignoring transient StaleElementReferenceException during a page transition. Under the hood, WebDriverWait is actually implemented as a FluentWait with sensible defaults, so FluentWait is the general-purpose tool and WebDriverWait is a convenient specialization of it.
Cricket analogy: A FluentWait is like a scout re-checking the pitch condition every 2 minutes right up to the toss, deliberately ignoring minor false alarms like a stray gust of wind, until the actual pitch report is ready — fully configurable polling and exception tolerance.
// Implicit wait: global, applies to every findElement call
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
// Explicit wait: targets one element, one condition
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(15));
WebElement result = wait.until(
ExpectedConditions.visibilityOfElementLocated(By.id("result"))
);
// Fluent wait: custom polling interval + ignored exceptions
Wait<WebDriver> fluentWait = new FluentWait<>(driver)
.withTimeout(Duration.ofSeconds(20))
.pollingEvery(Duration.ofMillis(250))
.ignoring(NoSuchElementException.class)
.ignoring(StaleElementReferenceException.class);
WebElement dynamicRow = fluentWait.until(
d -> d.findElement(By.cssSelector("tr.loaded"))
);Never mix implicit waits with explicit waits (including FluentWait) in the same WebDriver session. When a WebDriverWait's condition internally calls findElement and an implicit wait is also set, the two timeouts can stack, producing unpredictable and much longer effective wait times than either was configured for. Pick one strategy per driver instance.
Selenium's official documentation explicitly recommends explicit or fluent waits over implicit waits for anything beyond the simplest scripts, because condition-specific waiting produces faster, more deterministic tests than a blanket global timeout applied to every lookup.
- Implicit waits are global, applying a fixed polling timeout to every findElement/findElements call.
- Explicit waits (WebDriverWait + ExpectedConditions) target one element and one specific readiness condition.
- Fluent waits allow a custom polling interval and a list of exceptions to ignore while polling.
- WebDriverWait is internally a specialization of FluentWait with default settings.
- Never mix implicit and explicit waits in the same driver session — the timeouts can compound unpredictably.
- Explicit/fluent waits are preferred over implicit waits for anything beyond trivial scripts.
Practice what you learned
1. What scope does an implicit wait apply to?
2. Why is mixing implicit and explicit waits in the same session discouraged?
3. What does FluentWait offer that a default WebDriverWait does not configure by default?
4. Which ExpectedConditions method is appropriate for waiting until an element can be safely clicked?
5. What is WebDriverWait, structurally, in relation to FluentWait?
Was this page helpful?
You May Also Like
Finding Elements: findElement vs findElements
How Selenium locates elements in the DOM, the difference between findElement and findElements, and how to choose the right locator strategy.
Clicks and Keyboard Actions
How to perform clicks, hovers, drag-style holds, and keyboard shortcuts with Selenium's click() and the Actions class.
Handling Dropdowns and Checkboxes
How to work with native <select> dropdowns via the Select class, and correctly toggle checkboxes and radio buttons.