The faster your organization collects end-user consent, the faster you can action upon their preferences and potentially deliver customized ads. In this article, we have aggregated some implementation best practices to improve the loading speed of your GDPR TCF v2 messaging experience for your property.
The recommendations made in this article is intended to raise the connection priority given to the Sourcepoint messaging connection and remove any potential blockers that might keep the connection from being made.
Connections made by a browser are given priority based on certain heuristics. With some simple optimizations, your organization can raise the priority of your messaging connection and improve how fast your message experience loads.
Additionally, browsers limit the number of overall connections it can make at any given time and implicitly throttles connections. Optimizations suggested in this article are intended to address potential blockers to the Sourcepoint script.
In this section, please find various Sourcepoint recommendations that your organization can leverage during implementation to increase the loading speed of your GDPR TCF v2 message experience:
Insert Sourcepoint Message Script in <head> Tags
Do Not Load Sourcepoint Message Script in Tag Manager
Leverage Single Server Endpoint
Preload Sourcepoint Message Script (
Load Sourcepoint Message Script with async
Inserting the Sourcepoint messaging script into the <head> tags on a page ensures that our network connection receives a high priority.
If possible, do not load the Sourcepoint messaging script through a tag manager (e.g. Tealium or Google Tag Manager) since doing so entails loading the tag manager before the network request for the Sourcepoint messaging script can start.
If the Sourcepoint messaging script has to load through a tag manager, ensure that the tag manager loads with a high priority and that the Sourcepoint messaging script is the first script to load.
Upgrade your property's implementation to utilize Sourcepoint's single server endpoint
https://cdn.privacy-mgmt.com or a CNAMED 1st party subdomain for the
baseEndpoint in the client configuration code and snippet in order to leverage the following advantages:
Reduced DNS lookups
Performing SSL handshaking with edge servers
Preload is an aggressive method (when combined with inserting the Sourcepoint in <head> tags) by which you can force a high prioritization for the Sourcepoint messaging script connection.
<link rel="preload" as="script" crossorigin="crossorigin" href="https://cdn.privacy-mgmt.com/wrapperMessagingWithoutDetection.js">
Alternative methods to optimize your implementation that are less aggressive as preload are as follows:
//preconnect - establishes connection to server but does not preload the script. Saves overhead of SSL handshaking later.<link rel="preconnect" href="https://cdn.privacy-mgmt.com/wrapperMessagingWithoutDetection.js">////dns-prefetch - performs a DNS lookup<link rel="dns-prefetch" href="https://cdn.privacy-mgmt.com/wrapperMessagingWithoutDetection.js">
<script src="https://cdn.privacy-mgmt.com/wrapperMessagingWithoutDetection.js" async></script>