Script blocking and why your page refreshes after setting your cookie preferences

If you've never used a cookie banner before, it's easy to assume it's a fairly simple bit of software. A pretty box with a couple of buttons. Well, let us be the first to tell you there’s a little more going on under the hood.

Your cookie banner's job

The purpose of a cookie banner isn't just to tell people your website uses cookies; it's to prevent cookies from being stored on a user's browser without their consent.

How cookies get saved on a browser

If you're not a developer, imagining what cookies and cookie blocking look like might be a bit tough. All you need to know is:

Cookies don't look like this 🍪; they look like this: _ga
They don't just appear out of thin air; they get installed automatically with the help of scripts, which are essentially instructions that tell a browser how to load a feature or piece of content, usually by requesting information from an external website.

Here's an example of the script that installs a Google Analytics cookie (Google Tag).
<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-621WXSGQL0"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'G-1234567890');
</script>

Now you understand how cookies get installed, it should make sense when we say that we don’t prevent cookies from being stored; we block scripts from running when we know their purpose is to save a cookie on a user’s browser.

How script blocking works

Our script-blocking solution works by scanning your website for scripts, comparing them against our database of known cookie-setting scripts, and blocking any we know are responsible for setting cookies. For example, we would block a request to analytics.google.com because its purpose is to set your Google tag.

Where things can go wrong

If you didn't know scripts run from top to bottom, in the order they appear on the page, and once a script runs, there is no way to undo it!

For this reason, your cookie banner script must be installed above all other scripts in your <head>, so that it runs before any other scripts. This way, it can reliably prevent them from running and setting cookies.

Why we reload the page after a user provides their consent preferences.

As you now know, scripts cannot be blocked after they have finished running. The same is true in reverse. Scripts only run once, when a specific event takes place, and unless you've manually instructed it to do otherwise - this is usually when a user loads a page (or a 'Page View'). For this reason, if we block a script, it will not run until the next page load.

If you are in the EU, or another region that requires cookies to be blocked until consent is received (opt-in), your analytics, remarketing tags, and CRM forms will not load until the user accepts cookies and refreshes the page to trigger them.

This is why we reload the page, because it gives those scripts a clean start, so everything works as the visitor expects. This approach is designed to be plug-and-play, with no extra work needed on your side.

How to get around the page reload

If you feel the user experience is hindered to greatly due to the page refresh, you can absolutely disable it. You can disable both script blocking and the page reload from your banner's configuration page.

You'll just need to use a new method to tell scripts when to run - we recommend using Google consent mode signals through Google Tag Manager. Just set the tags up following our basic consent mode implementation instructions. Note: This requires that you have Google Consent Mode enabled.

Possible challenges:

This method works great if you only use a few third party cookies via Google Tag Manager. The issue arises if you're running loads of plugins that set cookies without a visible script. This is the problem that the page refresh was designed to avoid.

In practice, the refresh happens once, on a single interaction, and is usually quick. For most sites, it has little impact on the overall experience