CSS Selector vs XPath: Cheat Sheet + Real Benchmarks

Every scraping guide repeats the same line: CSS selectors are faster than XPath. We got tired of reading it without evidence, so we benchmarked both languages across five libraries. In lxml, the engine that powers Scrapy’s selectors, XPath won 3 of the 5 tests.

The CSS selector vs XPath question is really a choice between two query languages for pointing at elements in a parsed HTML tree: CSS describes what an element looks like, while XPath describes how to walk to it, in any direction. That is the real difference.

The problem with that debate is that most advice comes from 2013-era Selenium folklore. The most-cited benchmark on Stack Overflow predates a decade of browser engine optimization.

So we did the homework. We wrote equivalent CSS and XPath queries, verified they return identical elements, and timed them in lxml, parsel (Scrapy), BeautifulSoup, Selenium, and Playwright. This page is the result: a full translation cheat sheet plus numbers you can reproduce.

At FlyByAPIs we run scraping infrastructure that processes millions of requests per month across Amazon product pages with our scraping API , Google, and other hostile targets, so selector breakage is not theoretical for us. It is a Tuesday.

In short: use CSS selectors by default because they are shorter and every library supports them. Switch to XPath when you need to match text, climb up the DOM, or you are in Scrapy and lxml, where CSS is silently compiled to XPath anyway. Speed is the weakest reason to choose either: CSS won our browser tests by 4 to 40x while XPath won 3 of 5 tasks in lxml, and both gaps are microseconds next to network requests that cost milliseconds.

The short answer: which one should you use?

Both languages solve the same problem: pointing at elements in a parsed HTML tree. CSS selectors came from styling, XPath came from querying XML. That origin difference explains almost everything about how they behave today.

CSS is a pattern language. It describes what an element looks like: its tag, classes, attributes, position among siblings.

XPath is a path language. It describes how to walk to an element, in any direction, with conditions and functions along the way.

The honest heuristic after years of writing both: reach for CSS first, and switch to XPath the moment you catch yourself fighting the selector instead of writing it. The cheat sheet below shows exactly where that line sits.

CSS selectors vs XPath syntax: the translation cheat sheet

Same task, both languages, side by side. These 22 pairs cover pretty much everything you will write in a scraper. Bookmark this section; it is the reference we wish existed when we started.

Three rows in that table deserve a closer look, because they are where most scrapers quietly go wrong.

Text matching is XPath-only, and :contains() is a myth

You will see div:contains("price") in old Selenium tutorials and jQuery code. It is not real CSS. :contains() never made it past early drafts of the CSS selectors standard , and no browser implements it. jQuery and a few libraries ship non-standard lookalikes, which is exactly why the myth survives.

If you need “the button whose label says Add to cart”, XPath is your only clean option. That single capability keeps XPath alive in every serious scraping codebase we have seen.

Ours included: several of the parsers behind the FlyByAPIs Amazon product data scraping API lean on text predicates where Amazon offers no stable attributes.

The class-matching trap

Look at row 3. Matching a class in XPath is genuinely ugly, because @class is one string: an element with class="price old" will not match //*[@class="price"]. The naive fix, contains(@class, "price"), silently matches price_old and list-price too.

Parent traversal: XPath’s home turf

CSS can now express “the div that contains a logo image” with :has(), but support is patchy. Chrome shipped it in 2022 and BeautifulSoup’s soupsieve handles it, but cssselect, the CSS engine underneath lxml and Scrapy, rejects it outright.

XPath has had parent::, ancestor::, and preceding-sibling:: since 1999, and they work in every XPath engine, everywhere.

The benchmarks: CSS selector vs XPath performance, measured

Here is what nobody ranking for this topic has done: run the numbers on modern engines and publish the code. Our setup, so you can judge it:

• Machine: Apple Silicon Mac, Python 3.13, August 2026
• Page: the books.toscrape.com homepage (51 KB, 20 products), served locally so network noise is zero
• Method: 2,000 iterations per query, best of 5 runs, and every CSS/XPath pair is asserted to return identical element counts before timing

Round 1: parsing libraries (lxml, parsel, BeautifulSoup)

This is where scrapers actually live: Scrapy spiders, lxml pipelines, Python web scraping scripts. Times are microseconds per query.

Two things jump out. First, XPath won 3 of 5 tasks in lxml. So much for “CSS is always faster.”

Second, BeautifulSoup is 6 to 124x slower than the equivalent lxml or parsel query, typically around 10x. That matches what we found when we compared BeautifulSoup vs Scrapy head to head.

Why does XPath win here? Because in lxml and parsel, CSS does not exist at runtime: every CSS selector is compiled into XPath by the cssselect library before executing. Your tidy p.price_color becomes this:

1
2
3

>>> from cssselect import GenericTranslator
>>> GenericTranslator().css_to_xpath("p.price_color")
"descendant-or-self::p[@class and contains(concat(' ', normalize-space(@class), ' '), ' price_color ')]"

Do you see what this means? In Scrapy, the CSS vs XPath question is partly an illusion. You are always running XPath; the only question is whether you write it yourself or let a translator generate a defensive, slightly slower version.

Round 2: real browsers (Selenium and Playwright)

Browsers flip the story. Chrome’s CSS engine is one of the most heavily optimized code paths in the browser, because it runs on every page render.

XPath goes through document.evaluate, a comparatively dusty code path. We measured both inside the page with performance.now(), no driver overhead included:

CSS wins every browser test, by 4x to 40x. The folklore is true here. But before you rewrite all your XPath, look at what happens when you measure what your script actually experiences: the full driver round-trip.

The driver protocol costs roughly 1,000x more than the query itself. A 50-microsecond XPath inside an 8-millisecond round-trip is a rounding error. In our 30-call medians, XPath sometimes finished the full round-trip faster than CSS, purely on protocol noise.

Which libraries support what

This table settles more arguments than any benchmark. Half the time, your library already made the choice for you.

The dev tools row is the workflow tip most tutorials skip. Open the console on any page and test selectors instantly, no script required:

1
2

$$("article.product_pod h3 a")  // CSS, via querySelectorAll
$x("//article//h3/a")           // XPath, via document.evaluate

Ten seconds in the console saves ten minutes of scraper debugging.

One warning about dev tools: “Copy selector” and “Copy XPath” generate paths like #content > div:nth-child(2) > article > h3 > a. They work today and break tomorrow, because they encode the page’s entire current structure. Write your own selectors; use the copies only as hints.

Absolute vs relative XPath, in 30 seconds

Absolute XPath walks from the root: /html/body/div[2]/section/article[4]/h3/a. One layout tweak anywhere along that chain kills it.

1
2

/html/body/div[2]/section/article[4]/h3/a   # absolute: breaks on any layout change
//article[@data-sku]//h3/a                  # relative: anchors on meaningful markup

Relative XPath anchors on something meaningful: //article[@data-sku]//h3/a. It survives everything except a change to the article markup itself.

The rule: never ship an absolute XPath. The only reason they exist is that dev tools generate them.

The part nobody benchmarks: selectors break

Now, the part that actually costs money in production. We have never lost a night of sleep over selector speed. We have lost plenty over selectors that stopped matching at 3 AM.

The best selector language in the world cannot survive what modern sites do to their DOM:

Every scraping team eventually rediscovers the same equation: writing selectors takes a day, maintaining them takes forever. We wrote about the blocking half of this problem in why web scrapers get blocked ; the selector half is just as expensive.

That maintenance burden is exactly why structured scraping APIs exist. Instead of you tracking Amazon’s DOM churn, an Amazon scraper API returns structured JSON with the same field names every day, no selectors on your side at all.

When Amazon reshuffles its classes, fixing the extraction is our problem. Our fixes ship within hours, because every endpoint is monitored for drift.

The same trade applies to every hostile target. Those DOMs never stop moving either, so we maintain the selectors and parsers behind four more of them:

• A SERP API for real-time Google Search results
• A Google Maps scraper API with full reviews
• A Crunchbase scraper for company and funding data
• A jobs search API for hiring data

There is even a translation API for scraped content for when the data you extracted arrives in six languages.

To be clear about the trade-off: if your target is a stable site with sane markup, hand-written selectors plus this cheat sheet is the right call, and it costs nothing.

The API route earns its price on targets that fight back, where scraping Amazon product data by hand means re-fixing selectors monthly.

How to choose: the decision framework

After the cheat sheet, the benchmarks, and a few years of production scars, the whole decision compresses into four cards:

What we would tell a teammate

Learn both languages; the cheat sheet above covers 95% of what you will ever write. Default to CSS for readability.

Use XPath without guilt when the query calls for it, and always in its relative form. Ignore anyone who picks a selector language for speed without saying where it runs, because the answer flips between Scrapy and Selenium.

Speed is the weakest reason to choose either language. Pick the selector that will still work after the next site redesign.

And when a target starts eating your weekends with broken selectors, do the math on maintenance hours before rewriting them a fourth time. Sometimes the winning move is to stop writing selectors for that site entirely and let the FlyByAPIs Amazon scraping API carry the maintenance.

The benchmark code is waiting for you:

1
2
3
4
5
6
7

git clone https://github.com/flybyapis/blog-web-scraping-code.git
cd blog-web-scraping-code/css-selector-vs-xpath
pip install -r requirements.txt
playwright install chromium

python benchmark_parsers.py          # downloads and caches the test page
python benchmark_browsers.py --playwright

P.S. If you run the benchmarks and get different numbers on your machine, we genuinely want to see them. Different CPUs and library versions move the absolute values, though in our testing the conclusions held every time.

Oriol.