How to Speed Up Selenium Tests: Proven Best Practices

Why Speed Matters in Selenium Automation

Faster test execution provides quicker feedback and higher productivity. Reducing the time spent locating elements, waiting for page conditions, and launching browsers can significantly cut overall run time.

Choose the Fastest Web Locators

The speed of locating a WebElement depends on the locator type. The order from fastest to slowest is:

ID

Name

CSS Selector

XPath

Use By.id() when an element has a unique id. If no id exists, prefer By.name(). When neither is available, use a CSS selector ( By.cssSelector()) because browsers optimise CSS queries. Reserve XPath for cases where no other reliable locator is possible.

Minimize the Number of Locator Calls

Each call to driver.findElement(By) or driver.findElements(By) traverses the DOM. Reducing the total number of calls shortens execution time and improves script readability.

Avoid Thread.sleep() and Use Explicit Waits

Static sleeps pause execution for a fixed duration regardless of page state, causing unnecessary delays. Instead, monitor document.readyState or use Selenium’s explicit waits, which return as soon as a condition is met.

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement element = wait.until(
    ExpectedConditions.visibilityOfElementLocated(By.id("elementId")));

The above waits up to 10 seconds for the element to become visible, but proceeds immediately once the condition is satisfied.

Reuse Browser Instances with Test Framework Annotations

Creating a new WebDriver for every test adds considerable overhead. Initialise the driver once per test class or suite using framework lifecycle annotations.

JUnit: @BeforeClass, @AfterClass TestNG: @BeforeSuite, @AfterSuite NUnit: [OneTimeSetUp], [OneTimeTearDown] Example (JUnit):

public class SeleniumTests {
    private static WebDriver driver;

    @BeforeClass
    public static void setUp() {
        driver = new ChromeDriver();
    }

    @AfterClass
    public static void tearDown() {
        if (driver != null) driver.quit();
    }
}

Create Atomic and Independent Tests

Break complex scenarios into small, self‑contained test methods. Atomic tests are easier to debug, reduce inter‑test dependencies, and enable parallel execution.

Parallel Testing with Selenium Grid 4

Run multiple tests simultaneously on different browsers or nodes. With Selenium Grid 4, start a hub and register nodes, then configure the test framework to run in parallel.

# Start hub
java -jar selenium-server-4.10.0.jar hub

# Register a Chrome node
java -jar selenium-server-4.10.0.jar node --detect-drivers true --publish-events tcp://localhost:5555

In TestNG, enable parallel execution:

<suite name="ParallelSuite" parallel="tests" thread-count="4">
    ...
</suite>

Disable Image Loading to Reduce Page Load Time

Images often dominate network traffic. Disabling them speeds up page loads.

// Chrome
ChromeOptions options = new ChromeOptions();
Map<String, Object> prefs = new HashMap<>();
prefs.put("profile.managed_default_content_settings.images", 2);
options.setExperimentalOption("prefs", prefs);
WebDriver driver = new ChromeDriver(options);

// Firefox
FirefoxProfile profile = new FirefoxProfile();
profile.setPreference("permissions.default.image", 2);
FirefoxOptions fOptions = new FirefoxOptions();
fOptions.setProfile(profile);
WebDriver driver = new FirefoxDriver(fOptions);

Run Tests in Headless Mode

Headless browsers eliminate GUI rendering overhead, which is especially useful in CI pipelines.

// Chrome headless
ChromeOptions options = new ChromeOptions();
options.addArguments("--headless");
WebDriver driver = new ChromeDriver(options);

// DesiredCapabilities (legacy)
DesiredCapabilities caps = new DesiredCapabilities();
caps.setCapability("headless", true);
WebDriver driver = new ChromeDriver(caps);

Supported headless browsers include Chrome headless, Firefox headless, HtmlUnit, and others.