I installed Consent Pro today (30th April 2026) but the generated script tag does not include the async attribute. I have followed the steps in this thread — opening the banner in the app, changing a setting, updating the component and republishing — but the script still loads synchronously, which is causing a TBT of 1,740ms on mobile PageSpeed.
The Consent Pro runtime script must NOT have the async attribute — and this is by design, not a bug. Consent Pro needs to load synchronously so it can intercept third-party scripts before they execute. If it loaded async, those scripts could fire before Consent Pro has a chance to block them, which means tracking without consent — a real GDPR issue for EU visitors.
There are actually two separate concepts here that are easy to mix up:
The async attribute on the Consent Pro runtime script itself → must stay off
The loadAsync config property → controls how your third-party scripts (GA, Leadfeeder, Vimeo) load after a user gives consent
Your "loadAsync": false setting is correct for auto-blocking mode. These are not the same thing, and whatever thread you followed was likely referring to a different async behavior.
About the 1,740ms TBT — your setup looks correctly configured. The TBT is most likely coming from the third-party scripts being managed by Consent Pro, not from the runtime itself. To dig into what’s actually causing it:
Open Chrome DevTools → Performance tab
Record a page load and look at Long Tasks — this shows which scripts are blocking the main thread
Review whether all three tracker categories (analytics, marketing, personalization) are all truly necessary
There is a “Load Script Async” toggle in Banners > Global Settings in the Consent Pro app, but enabling it means switching from auto-blocking to a manual setup — you’d need to tag every third-party script with type="fs-consent" and fs-consent-categories="[category]". It’s a valid path if performance is critical, but it’s not a quick toggle.