Run the web as a business system.
Web Performance and Reliability
Build a journey-linked register connecting third-party services to owners, information flows, measured costs, failure effects, fallbacks and review triggers.
WebChorus Editorial Team9 min read
Build one maintained dependency register around representative user journeys. Populate it in two passes: observe browser-visible requests across meaningful states, then reconcile those observations with architecture, configuration, procurement, contracts, supplier records and stakeholder knowledge. The result should connect each reliance to its purpose, owners, information flow, measured cost, failure effect, fallback, monitoring and next review trigger. That shared record turns a scattered technical inventory into an operational decision tool.
Key takeaways
A third-party website dependency is any externally controlled code, content, service, infrastructure, credential, data source or supplier relationship whose behaviour can materially affect an in-scope journey. Change, delay, unavailability, compromise or data handling may all matter. This is a map of journey reliance and operational control, not an inventory of source-code packages, and it should include services that influence the experience without appearing as obvious page components.
A different origin is useful discovery evidence, but it is not the definition. An external service may be proxied through a first-party hostname, while a same-company origin may have a separate owner or failure boundary. Start with the browser network log and retain more than domain names: record resource type, initiator, status, size, duration, waterfall position, blocked behaviour and downstream request relationships. Third-party scripts can add network, execution and rendering work, but their actual effect must be measured.
A single initial load shows only what that session activated. Preserve enough context to explain each observation, including the journey step, test date and conditions. Treat HAR files and request records as potentially sensitive operational evidence: limit collection and sharing, use available sanitisation, and review every capture before adding it to the register or a ticket. Sanitisation can remove common sensitive headers without proving that every remaining field is safe to distribute.
Find hidden dependencies by running a second discovery pass across the platform and supplier estate. Reconcile browser observations with architecture materials, configuration, procurement systems, contracts, assurance records and discussions with providers and internal owners. These sources can reveal infrastructure, server-side integrations and subcontractors that never appear in a page capture. No scanner, contract list, diagram or browser session is complete on its own.
Trace provider chains proportionately. Prioritise services whose concentration or loss could affect a critical journey instead of attempting to map every commercial relationship. For each service, connect the supplier evidence back to the relevant journey and identify who can confirm its purpose, operation, contract, assurance status or removal authority. A useful supplier map can combine service importance, information flows, contacts, assessment status, subcontractors and shared downstream providers.
The register should give each dependency one compact but decision-ready record. Tie identity and scope to a named journey, then connect purpose, ownership, provider chain, information flow, measured performance, failure behaviour and lifecycle evidence. Use exact domains or endpoints where they help investigation, but retain the organisational relationship and activation conditions. A row should be understandable to business, technical, security, privacy and procurement partners without becoming a substitute for their specialist records.
Record data sent and received, relevant actors and destinations, the purpose and activation condition, and the contract or privacy record reviewed. Data minimisation, purpose limitation and transparency are useful questions, while jurisdiction-specific notice, consent, retention, transfer and user-right requirements belong with qualified privacy or legal reviewers. The register informs that review; it does not declare compliance or transfer the organisation’s accountability to a provider.
| Identity and scope | Purpose and accountability | Observed evidence | Decision and lifecycle |
|---|---|---|---|
| Dependency, provider, service class, endpoints, initiator, downstream services, environments, pages, journey steps, states, devices and activation conditions | Capability, business owner, technical operator, approval authority, provider chain, actors, data, destinations and relevant security, privacy or procurement contacts | Named test context, requests, transfer and decoded sizes where available, timing, execution or rendering effects, failure symptom, blast radius and last safe test | Journey criticality, disposition, fallback, monitoring signal, incident contact, contract status, decision owner, open actions and next review trigger |
Bind every performance observation to its journey, device, network condition, cache state and date. Resource Timing and browser tools can expose request counts, initiators, timing and available size information, but cross-origin policy and other platform conditions may limit detail. Record what was observed rather than filling gaps or assigning a universal score. Include connection, execution, rendering and interaction evidence when available, because transfer size alone does not describe the full cost.
Test failure in a safe environment or with explicitly approved browser tooling, changing one observed request or component at a time. Define the expected usable state before the exercise and do not create an unapproved production outage. Request blocking can reveal user-visible behaviour, but it cannot reproduce every latency pattern, malformed response, server-side failure or production condition. Broader resilience work needs its own authority, controls and qualified owners.
Consider a hypothetical scheduling widget. A browser capture finds its iframe and initiated requests at the booking step, while supplier records identify the owner and provider chain. The team documents the assumed information flow, then safely blocks the widget. Page content and an accessible alternate contact route remain usable, instant scheduling disappears, and existing monitoring misses the loss. The outcome is recorded as degraded, with a monitoring gap and a tested alternate route.
Classify the observed result for the named journey and condition as critical, degraded, optional or measurement-only. These labels are an editorial triage aid, not a universal continuity standard. Measurement-only failures can still matter when attribution, experimentation or operational evidence is required. An endpoint response or HTTP 200 does not prove that the business journey remains usable; assess the visible experience, fallback and monitoring together, then map the finding to your organisation’s impact criteria.
A dependency map earns its keep when it shows what users and operators experience when the reliance fails.
Choose a disposition by comparing documented purpose and ownership with observed cost, information flow, failure behaviour, fallback and journey importance. The six options are a practical decision framework, not a universal standard. Record the evidence, conditions, decision owner and review trigger so the choice can be challenged later. For the scheduling example, retaining the widget could be conditional on journey-level monitoring, preservation of the tested accessible alternative and a defined review event.
Apply technical controls with care. Directly included third-party JavaScript can change outside your release process and execute in the page context. Iframe isolation depends on origin, sandbox and permission configuration. Content Security Policy, compatible integrity checks, server mediation or separation from critical paths may reduce exposure, but suitability requires technical and security review. Subresource Integrity verifies expected bytes only for supported, compatibly delivered resources; it does not validate every API, iframe, external service or business behaviour.
A facade can defer an optional iframe and its subresources until activation, but the placeholder and activated experience still need consent, keyboard, labelling, accessibility and functional testing. Self-hosting likewise changes where bytes are delivered without removing update, integrity, licensing, privacy, maintenance or upstream software responsibilities. Isolation, deferral and self-hosting can shift or constrain exposure; none eliminates supplier risk or removes the need for an accountable owner.
Keep the map current by making review part of normal website operations. Use event-based triggers rather than imposing one arbitrary cadence on every dependency. Supplier guidance supports a maintained central record assembled from existing information stores, while third-party JavaScript guidance recommends identification, measurement and periodic audit. The appropriate depth and frequency should reflect the journey’s importance, the dependency’s observed behaviour and the effort required to obtain reliable evidence.
At each trigger, update last observed use, current contract or assurance status, last decision, decision owner, open actions and the next review event. Connect monitoring to user-visible journey symptoms and known measurement gaps rather than relying only on supplier or endpoint availability. Fallback expectations and recovery commitments should vary with impact; a critical identity service, an optional video embed and a measurement tag need not receive identical treatment.
During the first week, choose one priority journey, capture its major states, reconcile browser evidence with known supplier records, create the first register rows, assign provisional owners and plan one authorised failure exercise. Then set approval conditions for new dependencies so purpose, ownership, information flow, expected cost, failure behaviour, fallback, monitoring and review triggers are considered before adoption. Expand proportionately as the process becomes part of release, procurement and incident routines.
Bring security, privacy, legal, procurement, accessibility and continuity partners into decisions within their remit. Penetration testing, destructive resilience work, production fault injection, supplier assurance, jurisdiction-specific interpretations and binding recovery commitments require explicit authority and qualified owners. The register’s job is to make dependencies, evidence and decision rights visible enough for those judgements, not to replace specialist review or promise that every reliance can be mapped without uncertainty.
It is an externally controlled reliance whose behaviour can materially affect an in-scope website journey. It may be code, content, infrastructure, a credential, a data source or a supplier relationship. A different hostname is useful evidence, but organisational control, ownership and failure boundaries matter more than origin alone.
Capture representative browser journeys first, including meaningful states, interactions and consent choices. Reconcile those observations with architecture, configuration, procurement, contracts and supplier knowledge. Record the result in a maintained, journey-linked register with owners, information flows, observed costs, failure effects, fallbacks and review triggers.
Use the browser network log to capture request types, initiators, timing, sizes, status and downstream relationships across several journey states. Trace tag-manager descendants and embedded components. Then check platform and supplier records for infrastructure, server-side integrations and upstream providers that the browser cannot expose.
Use a safe test environment or explicitly approved browser tooling, define the expected usable state and change one condition at a time. Observe the complete journey, accessibility, fallback and monitoring rather than endpoint status alone. Do not create an unapproved production outage.
Self-host only when the organisation can lawfully and operationally own delivery, licensing, updates, integrity, privacy, maintenance and support. Moving the resource changes delivery control but does not remove upstream software or operational risk. Compare it with retaining, replacing, isolating, deferring or removing the dependency.
This article draws on the following sources:
Website Governance and Operations
Build a practical website governance model that names who decides, defines delegated limits, sets escalation triggers and keeps durable decision records.
Build a role-based accessibility testing matrix that scales evidence with change risk, assigns every handoff, and makes release decisions traceable.
Web Analytics and Experimentation
Build a decision-led website measurement plan that links user outcomes, focused indicators, data limits and review actions to choices that matter.
