A cookie banner can change landing-page performance. Measure the page delay, download cost and click response before attributing any change in advertising results to the banner.
Banner visibility, page performance and advertising outcomes are different questions.
Measure the page before inferring an ad-cost effect
It starts innocently enough: you add a cookie banner to handle GDPR compliance. Standard stuff. Everyone does it.
A consent script can add work to the page. Check each effect separately:
- Measure banner visibility separately from the time your main content paints
- Check layout shift and main-thread blocking in the tested implementation
- Review landing-page experience alongside your campaign data
- Use an experiment before attributing CPC or conversion changes to the consent tool
Include consent tooling in your landing-page performance review, alongside images, application code and other scripts.
A customer who recently moved to Inth's consent infrastructure put it plainly: they were paying a mid-5-figure annual fee to a provider that was "driving the quality score down and increasing cost of your entire ad budget." That is the customer’s account of their experience; it does not establish a general or measured causal effect.
That is a reason to investigate performance alongside consent behavior.
Why This Keeps Happening
The standard consent management vendors built their products for legal teams, not engineers.
Hosted CMPs can add script and configuration requests. Their measured download size and page impact vary by vendor and setup.
When you load a third-party script that:
- Fetches configuration from a remote server
- Downloads banner code after initial page render
- Injects DOM elements that can shift the layout
- Can block the main thread while initializing
Those are possible performance costs to test, rather than consequences of every consent tool.
CLS measures layout movement, not milliseconds of load time. A later banner does not automatically cause a layout shift. Google describes Quality Score as a diagnostic tool, not an input in the ad auction. CookieBench does not measure ad costs, search rankings or conversion uplift.
What Good Looks Like
Bundling consent components lets your application control their loading and styling. It still adds code and can delay the page.
In CookieBench’s current Next.js desktop profile, c15t’s banner appeared in a median 27 ms, with 0 ms TBT and 0.00 CLS. It added 8 ms to main-content paint and 104 KB of initial transfer. On emulated mobile it appeared in 240 ms and added 400 ms to main-content paint. Updated 12 October 2026: CookieBench results, Next.js desktop profile, analysis matrix-2026-10-12, methodology cookiebench-v3.2.4. CookieBench is maintained by Inth. The run used a local c15t backend and live services for other CMPs. Mobile results use emulation. These are lab results, not a guarantee for your site. See run limits.
Improve the landing-page experience, then review your own campaign data. The benchmark provides no evidence of a guaranteed Quality Score increase or lower CPC.
The measured result here is page performance.
The Real Question
If you run Google Ads, a slow banner is worth investigating as part of the landing-page experience.
Google describes Quality Score as a diagnostic tool, not an input in the ad auction. CookieBench does not measure ad costs, search rankings or conversion uplift.
Most teams don't connect these dots because the cookie banner sits in a different part of the stack. Legal owns the vendor. Marketing runs the ads. Nobody's looking at the intersection.
Check your real traffic and campaign outcomes before claiming that switching CMPs changes advertising costs.
The Fix Takes Less Time Than You Think
Integrate c15t with Inth, then verify the banner, consent gates and page performance in your own production setup. The controlled benchmark does not replace that test.
If you're running Google Ads and your cookie banner is slow, you should probably talk to someone who can measure the actual impact on your quality scores.
Inth can help with that.
Want to hand this to your agent to deploy? Sign up to Inth, copy your hosted backend URL, paste the prompt below, and let the agent wire c15t into your repo against the matching docs. Then review the diff and ship.
# Add c15t Consent Management
Set up c15t consent management for this project using the installed package docs when available.
## Step 1: Inspect the project
Read:
`AGENTS.md` files that apply
`package.json`
the lockfile
framework entry files and routing/layout structure
existing env, middleware, provider, and global CSS patterns
Detect:
package manager: npm, pnpm, yarn, or bun
framework: Next.js, React, or custom JavaScript
whether `@c15t/*` or `c15t` is already installed
whether this is a new setup or an existing setup that needs repair
## Step 2: Detect the supported integration
c15t currently publishes these setup targets:
| Project shape | Package | Bundled docs |
| --- | --- | --- |
| Next.js app using `next` | `@c15t/nextjs` | `node_modules/@c15t/nextjs/docs/README.md` |
| React app using `react` without Next.js | `@c15t/react` | `node_modules/@c15t/react/docs/README.md` |
| Headless or custom JavaScript integration | `c15t` | `node_modules/c15t/docs/README.md` |
Do not look for framework-specific c15t packages for Remix, Astro, Nuxt, Vue, Svelte, Express, or similar unless the project already depends on one.
## Step 3: Choose the documentation source
Prefer docs in this order:
Framework-specific bundled docs for the installed package version:
Next.js: `node_modules/@c15t/nextjs/docs/README.md`
React: `node_modules/@c15t/react/docs/README.md`
Headless/core: `node_modules/c15t/docs/README.md`
Bundled core docs:
`node_modules/c15t/docs/README.md`
relevant pages under `node_modules/c15t/docs/`
Project-local markdown docs, if this repo contains c15t-specific setup docs.
Hosted docs only if bundled docs are unavailable or the package is not installed.
If bundled docs are missing, search for nested installs:
find node_modules -path "*/c15t/docs/README.md" -not -path "*/node_modules/*/node_modules/*/node_modules/*" | head -1
Do not guess component names, provider names, config shape, or file paths. Follow the docs that match the detected package and framework.
Step 4: Install or update packages
If c15t is not installed, install only the relevant c15t package for the detected project shape using the repo's package manager:
Next.js: @c15t/nextjs
React: @c15t/react
Headless/custom JavaScript: c15t
If c15t is already installed, keep the existing version unless the docs or code clearly require an update.
Only use c15t version >=2.0. If the project is on an older version, stop and report that a v2 migration decision is needed.
Step 5: Configure c15t
Follow the relevant bundled quickstart exactly.
Usually this means:
adding the c15t provider at the correct app root
adding the consent banner or consent manager component
adding required CSS imports
adding middleware, route handlers, or API endpoints only if required by the docs
configuring environment variables only where required
preserving existing providers, layouts, middleware, and app structure
If the project needs hosted mode, use the user's own hosted backend URL from their Inth account after they sign up.
If the repo already contains an Inth hosted backend URL, use that.
If it does not, stop and ask for it.
Do not hardcode or invent a hosted backend URL.
For manual setup, choose the documented mode only if it is clear from the project. Otherwise report the available modes:
hosted with Inth
hosted with self-hosted backend
offline
Do not silently choose offline for production-looking apps.
Step 6: Integrations
Before manually adding third-party script blocking or consent behavior:
Check file node_modules/@c15t/scripts/README.md if it exists.
Check node_modules/c15t/docs/integrations/.
Use a prebuilt c15t script helper if one exists.
Only create manual script config if no helper exists.
Step 7: Styling and copy
Use the lowest-power customization that solves the task:
provider/component props
i18n for text changes
documented layout/action options
theme tokens
slots
CSS overrides only when documented APIs are insufficient
headless mode only when fully custom markup is required
Step 8: Verify
Run the repo's relevant checks:
typecheck
lint
tests if available
build if reasonable
Start the dev server if needed and verify:
the app loads
the consent UI appears
accepting/rejecting preferences works
no server/client import errors
no secret keys are exposed to client code
Critical rules
Prefer bundled docs over web docs when packages are installed.
Preserve existing app conventions.
Do not invent c15t APIs.
Do not expose server secrets in client code.
Do not overwrite unrelated user changes.
Report files changed and checks run.