
Your consent banner is probably your worst interaction
Accept-click response times range from 6ms to 468ms across consent platforms, and it is usually the first interaction Chrome records on your page.
Measured accept-click response times across consent management platforms range from 6ms to 468ms. That is a 78-fold spread on the single most common interaction on the web, and on most pages it is the first thing a user clicks.
If your Interaction to Next Paint score is failing and you cannot work out why, start here rather than with your forms.
Why the first click matters more than the rest
INP does not report your average interaction. It reports close to your worst one. For pages with fewer than 50 interactions, which is almost every marketing page, INP is simply the slowest interaction in the visit.
So the calculation for a typical session is short. Someone lands on a service page, clicks accept on the consent banner, reads, and clicks a phone number. Two interactions. Whichever is slower becomes the INP for that page view, and it goes into the 75th percentile calculation for the URL.
The consent banner wins that contest far more often than teams expect, because of when it happens. The accept click lands during the busiest moment in the page lifecycle, while scripts are still parsing, fonts are still resolving and the main thread is congested. Your contact form button gets clicked twenty seconds later on a quiet main thread. The banner gets clicked at second two, into a queue.
What the slow platforms are doing
Three behaviours account for most of the 468ms end of the range.
Reloading the page on accept. Some implementations, particularly where consent is handled server side, simply reload once the user chooses. That is not an interaction delay, that is a full navigation, and the user experiences it as a page that flashes and starts again.
Injecting everything synchronously in the click handler. The accept handler fires, and inside it the code loads the tag manager, initialises analytics, adds the chat widget, starts the pixel and writes cookies. All of that runs before the browser is allowed to paint the banner closing. The user pressed a button and watched nothing happen for a third of a second.
Recalculating layout while the banner animates out. A banner that animates height rather than transform forces layout on every frame, and if the page beneath it reflows, that is compounded.
The fixes, in order
Paint first, work second. The only thing that has to happen inside the click handler is closing the banner and recording the choice. Everything else goes after the next paint. Wrap the tag loading in a scheduler yield call, or a requestIdleCallback, or at minimum a setTimeout of zero. The user sees the banner close immediately, and the tags load a frame later. Nothing is lost and the interaction latency collapses.
Do not reload. If your consent architecture requires a reload, that is an architecture decision to revisit, not a performance tweak.
Animate transform and opacity only. Height, top and margin animations force layout. Transform and opacity do not.
Load the banner script itself with priority, but keep it small. A consent banner that arrives late causes a layout shift as it pushes content down, so you get penalised on CLS as well as INP. Reserve the space, or overlay rather than push.
How to measure it, specifically
Do not trust a synthetic score, because a lab test does not click the banner.
Open Chrome DevTools, go to the Performance panel, tick the screenshots option, start recording, load the page cold with the cache disabled and network throttled to a slow 4G profile, and click accept. In the recording, find the click event and read the interaction duration. Everything between the pointer event and the next paint is your number.
Then check the field data. In your real user monitoring, INP attribution tells you which element was the slowest interaction. If the target is your consent banner's accept button, you have your answer without any further investigation. Most teams never look at INP attribution, so they optimise a form nobody clicked.
The commercial framing
This is not a compliance problem or a developer problem. It is the first impression of your site.
A visitor arriving from a Google Ads click on a phone, on a suburban connection, presses the only button on screen and waits nearly half a second for a response. They do not think about input latency. They think the site feels cheap, and every subsequent interaction is judged against that first one.
The change is usually under twenty lines in a consent template, and it moves a metric Google grades you on while making the site feel like it was built by people who cared.
Fix the button everybody presses before you optimise the ones almost nobody does.
Written by David Eid. Published .
Read next.
Contact the Ignis Team
Send through your details and we will audit your business before we reply.




