Skip to content

Performance & Privacy

Privacy and performance are often treated as opposites. In practice, a clear consent setup can reduce unnecessary tracking and help pages load faster for visitors who have not agreed to optional cookies.

What usually slows a site down

Most performance issues on marketing sites come from third-party scripts — analytics, ads, social pixels, chat widgets, embeds, and similar tools. Each one adds JavaScript, cookies, and network requests.

Those are often the same tools that create privacy obligations. Consent Pro does not replace a full performance audit, but it gives you control over when those scripts run.

  • Blocks non-essential scripts until the visitor consents (based on your categories and setup in the app).
  • Loads one or two small Consent Pro files in <head> to manage the banner and enforcement — not dozens of extra files from Consent Pro itself. Async installs load a single combined file; the default (sync) setup splits this into a tiny per-site config file and a shared, cacheable runtime file.
  • Surfaces what runs on the site through scanning and categorization in the app, so teams can spot redundant or unused trackers.

When visitors decline optional cookies, fewer third-party scripts run — which can mean a lighter, faster page. When they accept, your tools load with consent on record.

For tuning how scripts load after consent, see Async Script Loading.

Consent Pro is a lightweight library — the runtime is about 15 KB transferred, which is small compared to most analytics or marketing tags.

By default (async off), installation uses two files:

  • A small config file, unique per site, carrying your consent configuration and geolocation data.
  • A shared runtime file, identical across every site, containing the actual Consent Pro logic.

Only the config file is not served as a long-term immutable asset for every visitor. Depending on license validation, geolocation (on Premium plans), and your published settings, its response may vary and may use short-lived caching and/or revalidation rather than long-term caching. The runtime file, being identical across sites, can be cached long-term. Audit tools that flag an inefficient cache policy may list the config file — that is expected, not a performance defect.

When async loading is enabled, both are combined into a single file that behaves like the config file above (not long-term cacheable).

SEO audits (Semrush, Lighthouse, etc.)

Audit tools sometimes report warnings such as “Serve static assets with an efficient cache policy” or “Uses an inefficient cache policy on static assets.” Consent Pro may be flagged when a site has many warnings.

  • Consent Pro is one or two small files, depending on your async setting. It does not explain a large list of uncached JS/CSS files — check the URLs; most come from Webflow, fonts, analytics, or other third parties.
  • If a Consent Pro file appears in the report, see The Consent Pro script(s) above.

Need help?

Get free support in our forum