Best practices for cookie notices

Optimize cookie notices for performance and usability.

Katie Hempenius
Katie Hempenius
X
Barry Pollard

This document discusses how cookie notices can affect performance, performance measurement, and user experience.

Performance

Cookie notices can have a significant impact on page performance due to the fact that they are typically loaded early in the page load process, are shown to all users, and can potentially influence the loading of ads and other page content.

Here's how cookie notices can impact Web Vitals metrics:

  • Largest Contentful Paint (LCP): Most cookie consent notices are fairly small and therefore typically don't contain a page's LCP element. However, this can happen—particularly on mobile devices. On mobile devices, a cookie notice typically takes up a larger portion of the screen. This usually occurs when a cookie notice contains a large block of text (text blocks can be LCP elements too).

  • Interaction to Next Paint (INP): Cookie notices can often be a cause for high INP as they typically add a lot of third-party scripts when accepted. The main issue is often to do the Accept interaction as that results in a lot of processing to add those third-party scripts all at once. Refer to the Best Practices section on how to mitigate this.

  • Cumulative Layout Shift (CLS): Cookie consent notices are a very common source of layout shifts.

Generally speaking, you can expect a cookie notice from third-party providers to have a greater impact on performance than a cookie notice that you build yourself. This is not a problem unique to cookie notices—but rather the nature of third-party scripts in general.

Best practices

The best practices in this section focus on third-party cookie notices. Some, but not all, of these best practices will also be applicable to first-party cookie notices.

Understand the INP impact of cookie notices

As mentioned previously, the Accept button is often a particular cause of INP issues due to the large amount of processing that happens when it's clicked.

The Chrome team has worked with a number of Consent Management Platforms (CMP) to yield after clicking accept to allow the browser to acknowledge that acceptance quickly in the next paint. See this PubTech case study as an example.

If your CMP is affected by this, try reaching out to them to see if they can similarly avoid INP issues for sites embedding it. See the Optimize Long Tasks article for guidance on yielding tactics.

Cookie notice scripts should be loaded asynchronously. To do this, add the async attribute to the script tag.

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

Scripts that are not asynchronous block the browser parser. This delays page load and LCP. For more information, see Efficiently load third-party JavaScript.

Cookie notice scripts should be loaded "directly" by placing the script tag in the HTML of the main document—rather than loaded by a tag manager or other script. Using a tag manager or secondary script to inject the cookie notice script delays the loading of the cookie notice script: it obscures the script from the browser's lookahead parser and it prevents the script from loading before JavaScript execution.

All sites that load their cookie notice scripts from a third-party location should use either the dns-prefetch or preconnect resource hints to help establish an early connection with the origin that hosts cookie notice resources. For more information, see Establish network connections early to improve perceived page speed.

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

Some sites would benefit from using the preload resource hint to load their cookie notice script. The preload resource hint informs the browser to initiate an early request for the specified resource.

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

preload is most powerful when its usage is limited to fetching a couple key resources per page. Thus, the usefulness of preloading the cookie notice script will vary depending on the situation.

Customizing the look and feel of a third-party cookie notice may incur additional performance costs. For example, third-party cookie notices aren't always able to reuse the same resources (for example, web fonts) that are used elsewhere on the page. In addition, third-party cookie notices tend to load styling at the end of long request chains. To avoid any surprises, be aware of how your cookie notice loads and applies styling and related resources.

Avoid layout shifts

These are some of the most common layout shift issues associated with cookie notices:

  • Top-of-screen cookie notices: Top-of-screen cookie notices are a very common source of layout shift. If a cookie notice is inserted into the DOM after the surrounding page has already rendered, it will push the page elements below it further down the page. This type of layout shift can be eliminated by reserving space in the DOM for the consent notice. If this is not a feasible solution—for example, if the dimensions of your cookie notice vary by geography, consider using a sticky footer or modal to display the cookie notice. Because both of these alternative approaches display the cookie notice as an "overlay" on top of the rest of the page, the cookie notice shouldn't cause content shifts when it loads.
  • Animations: Many cookie notices use animations—for example, "sliding in" a cookie notice is a common design pattern. Depending on how these effects are implemented, they can cause layout shifts. For more information, see Debugging layout shifts.
  • Fonts: Late-loading fonts can block render and or cause layout shifts. This phenomena is more apparent on slow connections.

Advanced loading optimizations

These techniques take more work to implement but can further optimize the loading of cookie notice scripts:

Performance measurement

Cookie notices can impact performance measurements. This section discusses some of these implications and techniques for mitigating them.

Real User Monitoring (RUM)

Some analytics and RUM tools use cookies to collect performance data. In the event that a user declines usage of cookies these tools cannot capture performance data.

Sites should be aware of this phenomenon; it is also worthwhile to understand the mechanisms that your RUM tooling uses to collect its data. However, for the typical site this discrepancy probably isn't a cause for alarm given the direction and magnitude of the data skew. Cookie usage is not a technical requirement for performance measurement. The web-vitals JavaScript library is an example of a library that does not use cookies.

Depending on how your site uses cookies to collect performance data (that is, whether the cookies contain personal information), as well as the legislation in question, the use of cookies for performance measurement might not be subject to the same legislative requirements as some of the cookies used on your site for other purposes—for example, advertising cookies. Some sites choose to break out performance cookies as a separate category of cookies when asking for user consent.

Synthetic monitoring

Without custom configuration, most synthetic tools (such as Lighthouse and WebPageTest) will only measure the experience of a first-time user who has not responded to a cookie consent notice. However, not only do variations in cache state (for example, an initial visit versus a repeat visit) need to be considered when collecting performance data, but also variations in cookie acceptance state—accepted, rejected, or unresponded.

The following sections discuss WebPageTest and Lighthouse settings that can be helpful for incorporating cookie notices into performance measurement workflows. However, cookies and cookie notices are just one of many factors that can be difficult to perfectly simulate in lab environments. For this reason, it is important to make RUM data the cornerstone of your performance benchmarking, rather than synthetic tooling.

Use scripting

You can use scripting to have a WebPageTest "click" the cookie consent banner while collecting a trace.

Add a script by going to the Script tab. The following script navigates to the URL to be tested and then clicks the DOM element with the id=cookieButton.

combineSteps
navigate    %URL%
clickAndWait    id=cookieButton

When using this script be aware that:

  • combineSteps tells WebPageTest to "combine" the results of the scripting steps that follow into a single set of traces and measurements. Running this script without combineSteps can also be useful—separate traces make it easier to see whether resources were loaded before or after cookie acceptance.
  • %URL% is a WebPageTest convention that refers to the URL that is being tested.
  • clickAndWait tells WebPageTest to click the element indicated by attribute=value and wait for the subsequent browser activity to complete. It follows the format clickAndWait attribute=Value.

If you've configured this script correctly, the screenshot taken by WebPageTest shouldn't show a cookie notice (the cookie notice has been accepted).

For more information on WebPageTest scripting, check out WebPageTest documentation.

Set cookies

To run WebPageTest with a cookie set, go to the Advanced tab and add the cookie header to the Custom headers field: