Stop hammering Selenium Grid with an over-eager FluentWait

A test that waits two seconds locally takes nine seconds on Grid, yet the application becomes ready at roughly the same time. The wait condition is firing several remote commands on every poll. With enough parallel sessions, those checks create their own traffic jam.

Changing the timeout will not solve that problem; you need to understand what one evaluation costs, how often it runs, and how much detection delay the test can tolerate.

Why a local polling cadence behaves differently on Grid

FluentWait repeatedly applies a condition until the condition returns a value that is neither null nor false, an unignored exception escapes, the timeout expires, or the thread is interrupted. pollingEvery(Duration) controls the sleep between unsuccessful evaluations. It does not make an evaluation itself take that amount of time.

That distinction matters with RemoteWebDriver. A condition such as "find the button, check that it is displayed, then check that it is enabled" can produce several WebDriver commands. Each command travels through the client, Grid router, node, driver, and browser before the result comes back. A nominal 250 ms interval might become 250 ms of sleep plus 180 ms of remote work. Under load, the remote part can grow further.

The Java API documentation is explicit about this behavior: the actual interval may be longer because the cost of evaluating the condition is not factored into the configured interval. The timeout is therefore a policy boundary, not a precise stopwatch guarantee. If a command is still running when the boundary is reached, the wait cannot travel backward and stop it.

Fast polling has a nonlinear cost in a large suite. One wait is harmless. Two hundred sessions, each evaluating a two-command condition four times per second, can add around 1,600 remote commands per second while the application is merely busy. Those commands compete with the clicks, navigation, and assertions that move tests forward.

An implicit wait makes the calculation murkier. Every findElement inside the explicit condition may perform its own wait before returning. Selenium warns against mixing implicit and explicit waits because the resulting duration is unpredictable. Set the implicit wait to zero while measuring this issue.

Measure one real wait instead of guessing

The following JUnit 5 test runs against a Grid URL from the environment. It uses Selenium's public dynamic test page, records each condition evaluation, and prints the remote session ID so the client output can be matched with Grid logs.

import static org.junit.jupiter.api.Assertions.assertEquals;

import java.net.URI;
import java.time.Duration;
import java.util.concurrent.atomic.AtomicInteger;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.openqa.selenium.By;
import org.openqa.selenium.NoSuchElementException;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.openqa.selenium.support.ui.FluentWait;

class GridPollingTest {
  private RemoteWebDriver driver;

  @BeforeEach
  void startSession() throws Exception {
    String gridUrl = System.getenv().getOrDefault(
        "SELENIUM_GRID_URL", "http://localhost:4444");

    driver = new RemoteWebDriver(
        URI.create(gridUrl).toURL(), new ChromeOptions());
    driver.manage().timeouts().implicitlyWait(Duration.ZERO);
  }

  @AfterEach
  void stopSession() {
    if (driver != null) {
      driver.quit();
    }
  }

  @Test
  void logsTheCostOfEachRemotePoll() {
    driver.get("https://www.selenium.dev/selenium/web/dynamic.html");
    driver.findElement(By.id("reveal")).click();

    AtomicInteger evaluations = new AtomicInteger();
    long startedAt = System.nanoTime();

    FluentWait<WebDriver> wait = new FluentWait<WebDriver>(driver)
        .withTimeout(Duration.ofSeconds(8))
        .pollingEvery(Duration.ofMillis(750))
        .ignoring(NoSuchElementException.class)
        .withMessage("The revealed input never became visible");

    WebElement input = wait.until(currentDriver -> {
      int evaluation = evaluations.incrementAndGet();
      long elapsedMs = Duration.ofNanos(
          System.nanoTime() - startedAt).toMillis();

      WebElement candidate = currentDriver.findElement(By.id("revealed"));
      boolean visible = candidate.isDisplayed();
      System.out.printf(
          "session=%s poll=%d elapsedMs=%d visible=%s%n",
          driver.getSessionId(), evaluation, elapsedMs, visible);

      return visible ? candidate : null;
    });

    input.sendKeys("ready");
    assertEquals("ready", input.getAttribute("value"));
  }
}

Run that single class before running the suite:

SELENIUM_GRID_URL=http://localhost:4444 mvn -Dtest=GridPollingTest -DtrimStackTrace=false test

This example deliberately keeps the predicate readable. Its findElement and isDisplayed calls are visible in review, and the log exposes the evaluation count. A helper that hides those calls would make the wait shorter on the page but harder to diagnose.

Prove the wait is generating pressure

Start with the timestamps printed by the condition. Subtract adjacent elapsedMs values. If the gap is consistently close to the configured 750 ms plus a small amount of work, the Grid is keeping up. If the gaps widen only during parallel runs, remote command latency or node contention is involved.

Next, correlate the session ID with Grid events. Selenium Grid can emit trace events at FINE level. On a standalone server, the diagnostic form of the command is:

java -jar selenium-server-<version>.jar standalone --log-level FINE

Use the actual server jar name in place of <version>. Look for events carrying the same session.id and compare their timestamps with the client poll lines. You are trying to answer three concrete questions:

1. How many remote commands does one condition evaluation send?
2. How long does each command spend from request to response?
3. Does latency rise as concurrent waiting sessions increase?

A Grid trace full of quick, evenly spaced commands means the infrastructure is probably not the bottleneck. The application may simply need four seconds to reach the requested state. By contrast, growing gaps between client polls and longer Grid spans under load point to transport, node CPU, browser saturation, or queueing.

Keep the locator and condition constant during this comparison. Run the focused test once with one worker, then at representative concurrency. If you change the locator, timeout, poll interval, and Grid capacity at the same time, the result cannot tell you which change mattered.

Compare distributions, not only the average test duration. Record the median and a high percentile for both condition evaluation time and total wait time. A healthy median with a sharply rising tail suggests intermittent Grid contention, while uniformly slow evaluations point to a consistently expensive predicate or network path. Keep timeout failures in the dataset; removing them makes the busiest runs look faster than they were. If the application exposes a trustworthy timestamp for entering the ready state, compare it with the first successful poll to measure detection lag separately from application work.

Also inspect the exception at the end. A TimeoutException whose cause is the expected transient NoSuchElementException fits a readiness problem. An invalid selector, lost session, wrong window, or authentication redirect does not. Increasing the interval for those failures only delays useful feedback.

Choose an interval from the product requirement

Begin with the latest acceptable observation time. Suppose a status normally settles within six seconds and the test may detect it up to one second later. A 750 ms or one-second interval is a reasonable experiment. If a control must be detected within 200 ms because the next state is brief, a much shorter interval may be justified, but the condition must be cheap and the Grid must sustain it.

The trade-off is simple. Longer intervals reduce command volume but add detection lag. If readiness occurs randomly between polls, the average added delay is roughly half the interval, before remote execution cost. Shorter intervals improve responsiveness only until command latency and contention consume the saving.

Tune the predicate as carefully as the interval. Ask for the smallest state that proves the user can continue. Avoid checking five properties when one stable property represents readiness. Do not replace a user-visible condition with a convenient JavaScript variable unless that variable is itself the product contract; a faster test that observes the wrong thing is not an improvement.

Limit ignored exceptions as well. Ignoring NoSuchElementException is sensible when an element is expected to appear. Ignoring every WebDriverException can conceal an invalid session, browser crash, or malformed command until the wait times out with a weaker error.

Document tuned values near the wait. A short note such as "750 ms keeps checkout detection below one second and halves Grid commands at 80 sessions" is reviewable. "Grid fix" is not. Re-measure when node sizes, concurrency, browser versions, or the condition body changes.

Account for the cost you are accepting

A custom interval creates maintenance work. Teams now own another timing policy, and future readers may copy it into waits with very different conditions. Keep the customization local unless measurements show a common Grid-wide need.

Slower polling can also miss short-lived states. That is usually a signal to question the test contract. If the product shows a success state for only 150 ms, users may miss it too. Where the transient event is intentional, wait for the durable result it causes, such as a completed row, enabled action, or final URL, rather than racing the notification.

Capacity may still be the right fix. When normal clicks and navigation are slow outside any wait, reducing polls treats one contributor but not the underlying saturation. Grid traces, host metrics, and browser process usage should agree before you blame FluentWait.

Finally, a longer interval does not reduce the cost of one badly designed condition. If each evaluation scans a large DOM, switches frames repeatedly, or performs several remote calls, simplify that work first. Cadence and predicate cost multiply each other.

Do not tune polling for a different failure

Leave the interval alone when the selector is invalid, the test is in the wrong frame, the session has died, or the application navigated to an unexpected page. Those conditions are not temporarily false. They require a corrected locator, context, session, or flow.

Do not use UI polling to monitor a backend job when the user does not observe that job through the browser. An API-level readiness check can be cheaper and more precise for test setup. Keep a UI assertion afterward if the feature must present the completed state to the user.

Avoid a suite-wide custom FluentWait merely because one test is slow. Different conditions have different remote command costs and response requirements. A payment status that settles over seconds and an autocomplete list that appears in milliseconds should not inherit the same number without evidence.

Most importantly, do not tune away a service-level regression. If the application used to expose a ready control in one second and now needs seven, a relaxed wait may turn a performance defect into a green build. Compare product timing with its agreed threshold first. Only then decide how often Selenium should look.