-
Notifications
You must be signed in to change notification settings - Fork 18
Description
I’m writing this to highlight a potential architectural improvement in the Global Privacy Protocol (GPP) library that could significantly impact performance and developer flexibility across the industry. I might be wrong, and it’s possible I’ve misunderstood some details of the current implementation, but I believe this is worth discussing given its potential benefits.
The GPP library is designed to support multiple privacy regulations through a universal API.
Currently, when building a CMP for a single regulation, the bundling process still includes code for all regulations because tree-shaking cannot reliably remove unused methods.
For example, when building a CMP specifically for US privacy regulations without using any TCF-related methods, the final bundle still includes the GVL code.
This results in unnecessarily large bundles, slower download and execution times, delayed consent UI display, and slower execution of scripts that depend on consent status. The issue will grow as more regulations are added.
Proposed solution:
Refactor GPP into a modular architecture with a small shared core and separate regulation-specific modules. This would allow developers to import only what they need, enabling effective tree-shaking, keeping bundles lean, and preserving compatibility for those who require multiple frameworks.
If this solution can be implemented, it has the potential to help the entire industry deliver smaller bundles, faster load and parse times, earlier consent disclosure, quicker execution of dependent scripts, and an overall better user experience.