Best practices for cookie notices

Why cookie notices demand performance scrutiny

Cookie notices occupy a unique position in the page load sequence: they typically load early, appear for every visitor, and can gate the loading of ads and other third-party content. That combination makes them a disproportionately large factor in Core Web Vitals, even though the notice itself is often small.

How they affect each metric:

• Largest Contentful Paint (LCP): Most consent notices are too small to contain the LCP element, but this is not guaranteed—especially on mobile, where a notice with a large text block can become the LCP element.
• Interaction to Next Paint (INP): The Accept interaction is a common INP culprit. Clicking it triggers heavy processing as third-party scripts are loaded all at once. The Chrome team has worked with several Consent Management Platforms (CMPs) to yield after acceptance so the browser can acknowledge the click quickly in the next paint. If your CMP hasn't adopted this pattern, the Optimize Long Tasks guidance offers yielding tactics you can suggest.
• Cumulative Layout Shift (CLS): Cookie notices are among the most frequent sources of layout shifts on the web.

A third-party cookie notice will generally have a larger performance impact than one you build and host yourself. This is not specific to cookie notices—it is the general cost of third-party scripts.

Loading practices that keep cookie notices fast

These practices focus on third-party notices, though several apply equally to first-party implementations.

Load asynchronously

The cookie notice script should never block the parser. Add the async attribute to the script tag:

<script src="https://example.com/script.js" async>

Without async, the script blocks parsing, which delays page load and LCP. See Efficiently load third-party JavaScript for background.

Load directly in the document

Place the cookie notice script tag directly in the HTML rather than injecting it via a tag manager or another script. Indirect loading delays the request: it hides the resource from the browser's lookahead parser and prevents the fetch from starting before JavaScript executes.

Connect early with the script origin

If the cookie notice script lives on a third-party origin, use dns-prefetch or preconnect to start the connection earlier:

<link rel="preconnect" href="https://cdn.example.com/">

See Establish network connections early for more detail.

Preload selectively

Some sites benefit from the preload resource hint for the cookie notice script, which tells the browser to begin the request immediately:

<link rel="preload" href="https://www.example.com/cookie-script.js">

preload is most effective when reserved for a couple of critical resources per page, so weigh whether the cookie notice script justifies the slot.

Preventing layout shift and other tradeoffs

Reserve space or use an overlay

Top-of-screen notices are the most common cause of consent-related layout shift. Inserting the notice into the DOM after the page has rendered pushes content down. The fix is to reserve space for it in the DOM. If you cannot do that—say, the notice dimensions vary by region—use a sticky footer or modal. Both render as overlays and will not displace the page content.

Watch animations and fonts

Notice animations, such as "slide-in" patterns, can trigger layout shifts depending on their implementation. Late-loading fonts used by the notice can also block render or cause shift, which is more noticeable on slow connections.

Understand styling costs

Customizing a third-party notice may add hidden performance costs. The notice often cannot reuse fonts or other resources already on your page, and it tends to apply styling at the end of a long request chain. Audit how the notice loads and applies its own styling.

Advanced delivery optimizations

Two further techniques improve delivery speed but require more implementation effort:

• Self-host the third-party script: Cache and serve the cookie notice script from your own origin.
• Use a service worker: This gives finer control over fetching and caching third-party scripts like the cookie notice resource.

INP: the accept button deserves attention

The Accept interaction is often the single largest INP contributor on pages with a consent notice, because it fires all third-party scripts in one processing burst. Work with your CMP on yielding after acceptance so the browser can paint the click acknowledgment promptly. A PubTech case study documents how this cooperation was implemented successfully.

Performance measurement

Cookie notices can alter the results of performance monitoring, because a visitor who declines cookies may not be measurable. This variation matters depending on the kind of tooling used and, for lab tests, how the consent state is configured.

Real User Monitoring (RUM)

RUM tools commonly rely on cookies to collect performance data. If a user opts out of cookies, that data cannot be captured. Before assuming this introduces a serious problem, it's worth understanding how your particular RUM tool collects data, because the direction and scale of the skew may be less significant than it appears at first. Cookie usage isn't strictly required to measure performance: the web-vitals JavaScript library is an example of a RUM approach that doesn't depend on cookies.

The legal picture is more nuanced. Depending on whether the cookies used for performance data contain personal information, the relevant legislation may not treat them the same way as, say, advertising cookies. For this reason, some sites present performance cookies as a separate consent category.

Synthetic monitoring

By default, Lighthouse and WebPageTest measure the experience of a first-time visitor who has not interacted with the consent notice. That represents just one possible state. Cache state is not the only variable to consider when comparing lab results; the cookie consent state (accepted, rejected, or unanswered) also changes what gets measured. Because lab environments have inherent limits in simulating all real-world conditions, RUM data should anchor your performance benchmarking.

Testing cookie notices with WebPageTest

WebPageTest can be configured to include the interaction with a consent notice in the trace, or to run a test with a specific cookie already set.

Use scripting

In the Script tab, a WebPageTest script can automate the click on a consent banner before the page is fully measured. The snippet below clicks the element with the id=cookieButton and combines the results into one measurement pass:

combineSteps
navigate    %URL%
clickAndWait    id=cookieButton

• combineSteps merges the scripted steps into a single set of traces. Running without it leaves separate traces, which can help show whether resources load before or after consent was given.
• %URL% is the WebPageTest placeholder for the URL under test.
• clickAndWait takes the form clickAndWait attribute=Value, clicking the indicated element and waiting for subsequent browser activity.

A correctly configured script yields a screenshot without the cookie notice. For further details, WebPageTest's scripting documentation covers more advanced scenarios.

Set cookies and choose a location

To run a test with a particular cookie in place, open the Advanced tab and enter the cookie header in the Custom headers field:

The Test Location drop-down on the Advanced Testing tab changes the server that runs the test.

Testing with Lighthouse

Lighthouse treats cookies differently depending on how it is launched — from DevTools, the CLI, or PageSpeed Insights.

DevTools and the CLI

Running Lighthouse from DevTools leaves cookies in place but clears other storage by default. The Clear Storage option in the Lighthouse settings panel toggles that behavior.

From the CLI, Lighthouse starts a fresh Chrome instance, so no cookies are present unless set explicitly. The command for a run with a specific cookie is:

lighthouse <url> --extra-headers "{\"Cookie\":\"cookie1=abc; cookie2=def; \_id=foo\"}"

Further detail on headers for authenticated pages is available in Lighthouse's own documentation.

PageSpeed Insights

PageSpeed Insights also launches a clean instance and does not carry cookies over. There is no configuration option to set cookies in that context.

User experience

Two primary choices shape the experience of a consent notice: its placement relative to the page and how much control it gives the user over cookie categories. Product decisions should weigh several factors:

• UX: How does the design hold up against existing flows and page elements?
• Business: What is the site's strategy toward cookies, and what should the notice accomplish?
• Legal: Does the chosen pattern satisfy current obligations?
• Engineering: What is the cost of building, maintaining, and later altering the notice?

Placement

Consent notices may be anchored in the header, footer, or as an inline block. They can alternatively appear above the content in a modal or as an interstitial.

Footer placement is the most defensible default. It avoids competing with banners and notifications near the top, rarely introduces layout shift, and sits beside links to privacy policies and terms. Header position is common but more obtrusive. Inline notices fit poorly into existing UI and are therefore less frequent.

Small modals can be a useful compromise when layout shift is a persistent concern. Large modals that cover the main content are riskier, especially for smaller or less-established sites, where users may bounce rather than interact. If a full-screen notice is under consideration, note that legal limits on cookie walls draw a line between consent and access that must not be crossed.

Configurability

No configurability

The simplest notice type presents only "Accept" and "Dismiss" options, leaving no direct interface for opting out. Instead, the notice links out to a cookie policy, where users are typically pointed toward browser settings for managing cookies.

Some configurability

A middle ground gives the user a single decision to accept or decline cookies, but offers no further granularity. This pattern appears less often than the others.

Full configurability

The most detailed approach lets users set their level of cookie acceptance. The controls for doing so are often placed in a second screen, launched from the initial notice. If space allows, some designs put those controls inline.

• Granularity: Categorization is the dominant method offered — typical buckets include functional, targeting, and social media cookies. A few sites refine this further by allowing per-cookie selections or by splitting wide categories such as advertising into distinct options for "basic ads" and "personalized ads".