Implicit waits are the simplest synchronisation mechanism in Selenium. You set them once, and they apply globally to every find_element call for the lifetime of the driver. When an element is not immediately found, Selenium retries the lookup at short intervals until the element appears or the timeout expires. Implicit waits solve the most basic timing problem — elements not yet in the DOM — but they have significant limitations that make them insufficient as your only wait strategy.
Implicit Waits — Configuration, Behaviour and Limitations
An implicit wait tells the driver: “If you do not find an element immediately, keep trying for up to N seconds before throwing NoSuchElementException.”
from selenium import webdriver
from selenium.webdriver.common.by import By
# ── Setting up an implicit wait ──
driver = webdriver.Chrome()
driver.implicitly_wait(10) # Wait up to 10 seconds for ANY find_element call
# How it behaves:
# 1. driver.find_element(By.ID, "login-button")
# → Element found immediately? Return it. (0ms)
# → Not found? Retry every 500ms for up to 10 seconds.
# → Still not found after 10 seconds? Throw NoSuchElementException.
# ── What implicit waits CAN do ──
CAN_DO = [
"Wait for an element to appear in the DOM (presence)",
"Retry find_element automatically without explicit code",
"Apply globally — set once, affects every find_element call",
"Reduce NoSuchElementException for simple page loads",
]
# ── What implicit waits CANNOT do ──
CANNOT_DO = [
"Wait for an element to be VISIBLE (it may be in DOM but hidden)",
"Wait for an element to be CLICKABLE (it may be covered by an overlay)",
"Wait for text content to change or appear",
"Wait for a URL to change after navigation",
"Wait for an element to DISAPPEAR (e.g. loading spinner)",
"Wait for AJAX requests to complete",
"Wait for a specific attribute value (e.g. class changes)",
"Set different timeouts for different elements",
]
print("Implicit Waits")
print("=" * 55)
print("\nCAN do:")
for item in CAN_DO:
print(f" + {item}")
print(f"\nCANNOT do ({len(CANNOT_DO)} limitations):")
for item in CANNOT_DO:
print(f" - {item}")
# ── Implicit wait in Python and Java ──
SETUP_EXAMPLES = {
"Python": 'driver.implicitly_wait(10) # 10 seconds',
"Java": 'driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));',
}
print("\n\nSetup:")
for lang, code in SETUP_EXAMPLES.items():
print(f" {lang}: {code}")
driver.quit()
display: none), covered by an overlay, or disabled. The implicit wait will find the element and return it, but your next action (click, send_keys) will throw ElementNotInteractableException because the element is not ready for interaction. This is why implicit waits alone are insufficient for robust test synchronisation.NoSuchElementException errors — making failure feedback painfully slow. A 5-10 second implicit wait catches routine page load delays without making error detection unacceptably slow.Common Mistakes
Mistake 1 — Setting implicit wait too high and suffering slow failure reporting
❌ Wrong: driver.implicitly_wait(60) — every legitimate “element not found” error takes 60 seconds to report.
✅ Correct: driver.implicitly_wait(5) for a reasonable baseline, supplemented by explicit waits for specific conditions that need longer timeouts.
Mistake 2 — Relying solely on implicit waits for all synchronisation needs
❌ Wrong: “We set implicit wait to 10 seconds. All timing is handled.”
✅ Correct: “Implicit wait handles basic element presence. We use explicit waits for visibility, clickability, text changes, URL navigation, and overlay disappearance — conditions that implicit waits cannot detect.”