Start with an inventory and a business purpose
Open a representative landing page and list the external scripts and embeds observed during loading and normal use. Record their source, purpose, loading trigger and owner. Include items introduced through a tag manager or plugin, since the page template alone may not reveal every dependency. Separate confirmed purposes from guesses based on a domain name.
Ask the owner what would stop working if each item were unavailable. A booking widget, measurement tag and decorative embed have different roles. An unfamiliar request is a reason to investigate, not proof that the resource is unnecessary. Keep the inventory tied to the actual landing-page journey rather than deleting site-wide integrations from a single observation.
Collect evidence of cost and dependency
Use network and performance evidence to distinguish transfer work from script execution and visible delays. The official web.dev guide describes how third-party code can add requests and keep the main thread busy. A script’s file size alone therefore does not establish its full cost or its contribution to a particular delay.
Record the test conditions and retain a baseline trace. Note whether the visitor opened a widget, accepted a relevant preference or reached a section that loads an embed. Compare equivalent states. A measurement taken before a feature activates cannot establish the cost of using it later in the journey.
Test one candidate change in an isolated context
For a suspected dependency, use a controlled local or staging comparison to understand behavior with and without it. A temporary diagnostic change is not a production-removal decision. Keep the original configuration available and identify the essential actions to retest, including submitting a valid enquiry and receiving the intended confirmation.
Choose a proposed treatment with the feature owner: retain, remove a confirmed unused integration, or load a supported optional feature later. Review vendor requirements before changing execution order. Do not assume adding async or defer eliminates execution cost or preserves dependent code. Preserve required consent and security behavior rather than treating those controls as expendable performance overhead.
Illustrative example: an unused campaign widget
Imagine a fictional service landing page still loads a widget from an ended campaign. The campaign owner confirms that its offer is no longer used, and a staging comparison removes that integration alone. The reviewer checks the enquiry form, navigation and the remaining measurement setup before considering a production change.
If removing it breaks a shared dependency, the result is recorded as a failed candidate change rather than a successful optimization. If the tested journey remains correct, the team records the observed performance difference without claiming a conversion increase. This is a proposed review scenario, not evidence that a customer site or campaign was tested.
Document the release decision and monitor the journey
Keep a decision record with the owner, reason, evidence, changed scope and rollback path. After release, repeat the essential functions and confirm that the expected integrations still activate in their intended states. Check both the visible user outcome and the relevant technical observation; a faster page with a broken enquiry form is not a successful release.
Review the inventory when campaigns, plugins or vendors change. Keep performance observations separate from business results and do not promise a ranking improvement from removing a script. A website audit can organize the findings, but removal decisions need evidence about both cost and purpose.