Why you can trust this benchmark

CookieYes publishes this benchmark and appears in it. We fixed the test conditions before running anything, we state our affiliation wherever the results are presented, and every measurement is public so you can verify the results.

A benchmark is worth reading in proportion to how little its publisher stands to gain from the result. This one cannot claim independence, so it does the next thing: it fixes the anchors before the run, states the affiliation, publishes every load, and makes the site itself pass the bar it holds others to.

CookieYes We publish this site and appear in the results three times: as @cookieyes/nextjs, as @cookieyes/react and as our CDN script. No other provider in the list is affiliated with us. The affiliation is stated here and in the footer of every page.

Questions worth asking

Who publishes Cookiebannerbench?
CookieYes publishes it and three of its own installations appear in the results — two npm packages and its CDN script. That is a conflict of interest, and it is stated here and in the footer of every page rather than left to be discovered. Anchors, weights, run conditions, every measurement and every individual load are published so the comparison can be checked rather than trusted.
Which installations are published?
Installable consent-banner products whose banner renders on the test domain and whose licensing permits it. A load in which the banner was not detected is counted and shown on the row. Internal experiments are not published. The no-SDK baseline is shown as an unscored control. A provider that is absent is a fact about the benchmark, not about the provider.
Why is the table sorted by score?
The score is the one composite the method defines, with its anchors and weights published. Every other column sorts on request and none is pre-sorted, because pre-sorting a metric would be an editorial claim about which cost matters most.
What does the score mean?
0–100 over four categories of cost, eight measurements in all: Banner Speed (30%) — time to banner; Page Impact (25%) — how much later the page first paints, and how much more the main thread is blocked, than the same page with no consent SDK; Network Cost (25%) — bytes and requests added; Visitor Experience (20%) — how much of the screen the banner covers, and how long after appearing it can be clicked. Each measurement is 100 at zero cost and 0 at a published anchor. Good is 80 and above, Fair 60–79, Poor below 60. It does not measure compliance, features or product quality.
Why are some scores provisional?
Because a measurement could not be taken on that condition — for example, no control on the banner became clickable in time. The score is computed over what was measured, the arc for the missing category is left empty, and the row says so. Nothing missing was counted as zero. Bytes are read off the wire, so a host that hides its sizes does not make a row provisional.
Why is LCP not in the score?
LCP is a property of the whole page, most of which the consent layer did not build. It is reported on every row and card — a fast banner cannot hide a slower page — but it is not weighted, because weighting it would score the test app's framework as much as the consent layer.
Does a dash mean zero?
No. A dash means the run produced no measurement for that cell, and the reason is on the detail page. A zero is a measurement and would claim something the benchmark did not observe.
How often are results updated?
Runs are recorded on demand and each result names its run and date. The history keeps older runs beside newer ones instead of replacing them. When the method changes, historical scores are not recomputed.
Where is the source?
The harness, every test app and every run manifest are in the public repository linked from the top bar. Each detail page also offers the raw trace for that installation as JSON.

We test ourselves too

This site is judged by the same standard it uses on everyone else. Every page is static HTML with 5.4 KB of JavaScript over the wire, self-hosted subset fonts, no analytics and no third-party requests. Continuous integration fails if any route scores below 100 in every Lighthouse category or trips a single accessibility rule. The harness, the test apps and the site all live in one repository.