Start with governance, not optimization
Third-party scripts are a common source of performance problems, but before you start deferring, lazy-loading, or preconnecting them, it is worth asking a more basic question: does the site actually need all of these tags?
Tags provide genuinely useful functionality, making pages more dynamic and interconnected. However, they are often added by different teams across an organization and then left in place indefinitely. People move on, contracts expire, or the original purpose is fulfilled, but no one comes back to remove the script. A common pattern with tag-heavy sites is that no single person or team owns this part of the stack, so it falls between the cracks. The result is an optimized staging environment that regresses in production as new tags are dropped onto the page.
Implementing a vetting process for third-party tags can prevent this by building a workflow that creates cross-functional accountability. The right approach depends on the organization: it might be as simple as a single team acting as gatekeeper, or more formal, such as a request form that asks teams to explain why a tag is needed, how long it should remain, and what business benefit it provides.
A five-stage tag lifecycle
Whatever the vetting mechanism, these stages should be part of a tag's lifecycle on the site.
1. Compliance
Before any tag is added to a page, it must be vetted by the legal team to confirm it passes all compliance requirements. This includes checking alignment with regulations such as the EU General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA). If there is any doubt at this stage, it needs to be resolved before assessing the tag from a performance perspective.
2. Is the tag actually required?
Ask whether the tag is needed on the page. Consider the following:
- Is the tag actively being used? If not, can it be removed?
- If the tag loads sitewide, is that necessary? For example, an A/B testing suite that is only being used on landing pages does not need to load everywhere.
- Can more logic be added? For instance, detect whether there is a live A/B test and only inject the tag when one exists.
3. Ownership
Every tag should have a clear owner, typically the person or team who added it. Having an assignee ensures future reviews and audits can be conducted to re-visit whether the tag is still needed.
4. Purpose
Document why the tag is on the page so that cross-functional teams understand what each script brings to the website. For example, if a tag records user session actions to enable personalization, does everyone know why that is present? Also consider whether a commercial versus performance trade-off has been discussed. If a tag is deemed required because it generates revenue, has anyone analyzed the potential revenue lost through the speed regression it causes?
5. Review regularly
The final and arguably most important step is to ensure tags are reviewed on a regular basis. The frequency should depend on the size of the site, the number of tags, and their turnaround time, but weekly, monthly, or quarterly reviews are reasonable. Treat tags the same way you treat any other asset such as JavaScript, CSS, or images, and check them proactively. Without review, the tag manager becomes bloated and slows pages down, and reverting to a performant state while keeping required functionality becomes a complex task.
Translate the final list into a budget
The vetting process should leave you with a final list of tags that are genuinely needed for a specific page. At that point, you can move on to technical optimization approaches. You can also define the number of tags in that list as part of a performance budget, monitored via Lighthouse CI and incorporated into performance-specific goal setting. For example:
If we stick to <5 tags on our Landing Pages along with our own optimized JS, we're confident the Total Blocking Time (TBT) can hit 'good' in the Core Web Vitals.
