As a visitor of websites i have been annoyed by the Cookie Consent (or Privacy Consent) messages from the start. Especially the ones which show up after a few seconds or redirect me to another page to manage the settings globally (well they don’t manage my expectations for sure!). It distracts me from the content and like most visitors i’m accepting those cookies anyway. So the faster they show up the better. Google recently announced that the Core Web Vitals will become part of the Search Engine ranking algorithm and already started labeling fast sites in Chrome! This is why I want to know how the different type of cookie consent implementations are affecting these metrics.
If you don’t know what the fuzz is about with the Core Web Vitals then read about it after reading my article: Link for more information. For now the most important is that you know that the Largest Content Paint (LCP) is a visual loading metric and is being updated during the load of the page. This means that when something changes this metric can/will update until the page is considered loaded. My assumption was that the LCP will be impacted by slowly loading consent modals. Spoiler: this is the case, but in some unexpected ways! For this example i’ve picked 4 well known brands in the Netherlands all with a different implementation. In the image below you’re able to see the end result when the page is loaded.
Two of the four websites should optimize the moment that they show the cookie consent, but only one is actually being penalized in the LCP metric. Are you able to guess which one it is? I don’t!. At least not by comparing the screenshots from the fully loaded pages. Another hint would be that two of them are using an externally loaded consent manager, but for only one of them the metrics are impacted. Any idea yet on which one I will focus further?
Measured with a private hosted WebPageTest instance.
First I will have give a complement to Wehkamp and Bol.com since both have implemented the consent manager in the best possible way from performance and frustration perspective. For them it is the most important piece of content and therefore loaded first.
Externally loaded Cookie Consent Managers
In this comparison Zalando is the only one using an externally loaded 3rd party consent manager. A lot of sites are using such a consent manager, but in this case I wanted to show the different types of implementations.
Fact is that those consent managers are loaded after the external scripts are loaded which is most of the times implemented through Tag Management System. The same thing applies for any pure javascript implementation which is often the case with Single Page Applications.
Frustration
When the consent manager is suddenly taking over the page this is causing frustration due to miss clicks or abandonment. Depending on how strict you are you probably will not monitor the frustration with your screen recording analytical tools. The proper way would be to show it from the start like Bol.com and Wehkamp and even consider if it needs to be a full-page takeover at all.
You would expect that Zalando and VZG both would have a penalty for this behavior. However only VGZ is pays the penalty.
When looking at the Chrome Devtools with the help of a little snippet from https://web.dev/lcp/ I’m able to see what is being reported as possible LCP. The last value will become the final one. Here I’m able to see that for a while the H2 title is being considered but when the consent is shown this becomes the LCP.
The metrics are not always right!
Why is this not the case for Zalando? When loading the Zalando homepage the following is being reported by the same snippet.
Below list is a user friendly representation of the above list from the Chrome Developer Tools:
- The main content is being rendered after 229ms
- Header title is being rendered after 254ms
- The hero image is loaded from another domain, downloaded and rendered after 400ms
- And the category menu is being rendered after 525ms
The late shown full page consent is not being considered as the LCP.
What, how would that be possible?! The menu is only 1/4th of the page, no text and small images. The consent modal is clearly the largest element being rendered. Somehow Chrome thinks that there is full page menu and therefore reports it as the largest content full paint.
The reported menu is not really the visible menu but some links which are not being shown since the menu is being resized to 1 x 1 pixels. My best guess would be that this is done for either accessibility or SEO purpose.
On the right image I have removed the resize by CSS to show the actual content. When looking at the W3C specs you will notice that efforts have been made to ensure that the intrinsic image size is being used but I can’t find the same thing for text nodes which is probably why the CSS resize is not being used to recalculate the actual size. Perhaps I need to fill a bug report for it.
My best guess would be that the Google team will apply a fix for it since this is clearly being reported wrong. Since I’m pretty confident that this will be fixed I do advice against doing the same thing just to get a better ranking on LCP. After all the metrics are there in order to provide better experiences and remove frustration. If not for mankind then for me. I’m thankful already.
Conclusion and take aways
- In most cases the metrics are correct and aiming your to the right optimization direction.
- Sometimes the metrics are wrong so please be careful when comparing with your competition and always double check that the comparison is fair. You never know when specs change as long as they are drafts like this one.
- JavaScript injected and externally loaded consent managers almost always hurt the perceived performance and are being reflected mostly correct in the metrics. If getting consent is important for your business than make sure it is rendering as early as possible.
- Implement some type of measurements to keep track of when the consent is shown. This could be done with user timing marks which can be send to your analytics.
- All 4 brands have implemented the consent in such a way that 3rd parties are not loaded without consent. This causes less javascript being executed and lighter pages. This positively affects the First Input Delay in most cases.
Bonus
If you have the option to make use of a CND edge worker (Cloudflare or Akamai for example) you could include the consent HTML in the base page response to have it cached on your CDN and have the edge worker remove the HTML when the consent is already given (for example if a consent=true cookie is set). This does have the benefit of keeping your pages ‘long’ lived cached. Such a content replace job is just milliseconds work for the edge worker. Wehkamp and Bol.com are using something similar with their CMS.
This article is published before on LinkedIn.
