Run the web as a business system.
Web Performance and Reliability
Build a journey-linked register connecting external website services to owners, information flows, measured costs, failure effects and review decisions.
WebChorus Editorial Team9 min read
Build one maintained dependency register around representative user journeys, using two discovery passes. First, observe the requests and components activated as people move through meaningful website states. Then reconcile that evidence with architecture, configuration, procurement, contracts, suppliers and the colleagues who operate the service. The result should connect each reliance to its purpose, owners, information flow, measured cost, failure effect, fallback and next decision. That shared view matters because an apparently simple scheduling page may depend on a widget, tag-manager descendants, identity, APIs, infrastructure and upstream providers that no single team sees in full.
The operating principles
A third-party website dependency is an externally controlled reliance whose change, delay, unavailability, compromise or data practice can materially affect an in-scope journey. It may be code, content, infrastructure, a credential, a data source, a service or a supplier relationship. 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 an internal-looking origin may have a separate owner and failure boundary. This is therefore a journey-reliance map, not a source-code package inventory.
Begin with representative browser journeys rather than one homepage load. Capture the important states, interactions, device conditions, consent choices and authenticated or transactional paths that can safely be observed. In the network log, 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 or initiate further resources, but their actual cost must be measured in the named context rather than inferred from the provider or file type.
Treat HAR files and detailed request records as sensitive operational evidence. They can contain headers, URLs, form-related data or other captured values that should not circulate casually. Use available sanitisation, minimise collection and access, and inspect every export before attaching it to a ticket or register entry. Sanitisation can remove common sensitive fields; it does not certify that everything left in the capture is safe for unrestricted distribution.
Uncover hidden dependencies by running a second pass through technical, commercial and operational records. Browser evidence cannot show every server-to-server call, renewal mechanism, hosting layer or provider subcontractor. Reconcile observations with architecture diagrams, live configuration, procurement systems, contracts, assurance records and discussions with service owners. No scanner, contract list or diagram is complete alone, so disagreements between sources are findings to resolve rather than reasons to select the tidiest version.
Map supplier chains proportionately. The goal is not to reconstruct every commercial relationship in the market, but to identify the reliance that matters to the journey and the people who can act on it. For each discovered service, find who can confirm its purpose, operation, contract position, assurance status and removal authority. Maintained supplier maps can combine importance, information flows, contacts, subcontractors and shared-provider concentration, giving the website team evidence that a browser session cannot supply.
The register should give each dependency one decision-ready row linking identity and scope to accountability, observed evidence and lifecycle action. Record the exact domains or endpoints where useful, but keep the journey step central: a service may be critical during authentication yet irrelevant on an information page. Name the accountable business owner, technical operator, relevant security or privacy partner, procurement contact and authority for change or removal. Without those roles, the row describes a reliance but does not establish control.
| 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, operator, approval authority, provider chain, actors, data sent and received, destinations and reviewed contract or privacy record | Named journey, device, network, cache state, date, requests, available sizes, timing, blocking, execution or rendering effects, failure symptom and last safe test | Journey criticality, disposition, fallback, monitoring signal, incident contact, contract status, decision owner, open actions and next review trigger |
Keep performance evidence contextual. Resource Timing and browser tools can expose request timing, initiators and available size information, although cross-origin policy and platform conditions can limit detail. Record the journey, device, network condition, cache state and observation date alongside request counts, transfer or decoded sizes, connection and request timing, blocking, main-thread work, rendering and interaction evidence where available. Do not collapse these observations into a universal supplier score: the same integration can behave differently across pages, conditions and releases.
Map information flows by naming the actors, data types, recipients, purpose and activation condition. Ask whether the transfer is minimised, limited to its stated purpose and explained appropriately, while recognising that the first party remains accountable for delegated processing. The register should point to the reviewed privacy or contract record; it should not declare legal compliance. South African and cross-border questions about notice, consent, retention, transfer or user rights belong with qualified privacy and legal partners.
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 starting, and do not create an unapproved production outage. Where relevant and safely reproducible, examine delayed, failed, denied-consent, empty-response or stale-data conditions. Request blocking can expose visible failure behaviour, but it cannot reproduce every latency pattern, malformed response, server-side fault or production condition.
Consider a hypothetical scheduling widget. A capture reveals its iframe and initiated requests at the appointment step; supplier records identify the owner and provider chain; the team documents the assumed information flow and safely blocks the component. Suppose the page content and an accessible alternate contact route remain usable, while instant scheduling disappears and existing monitoring stays silent. The team records a degraded outcome for that journey, carries the missing signal into its action list and retains evidence that the alternate path was actually tested.
Classify the observed condition as critical, degraded, optional or measurement-only for the named journey. These are editorial triage labels, not a universal continuity standard. A measurement-only failure can still matter when attribution, experimentation or operational evidence is required. Likewise, an HTTP 200 response or healthy supplier endpoint does not prove that the complete journey works. Contingency choices may include restoration, a degraded experience, an alternate channel or manual processing, selected according to impact.
A dependency map earns its keep when it shows not only what the website calls, but what users and operators experience when that reliance fails.
Choose retain, replace, isolate, defer, self-host or remove by comparing documented purpose and ownership with measured cost, information flow, failure behaviour, fallback and journey criticality. These six options are a practical decision framework, not an official standard. Record the selected disposition, the evidence behind it, its conditions, the decision owner and the event that will reopen it. A vague intention to optimise later is not a disposition because it assigns neither accountability nor a review point.
Apply technical controls with their boundaries visible. Directly included third-party JavaScript can change outside your release process and execute in the page context; precise capabilities depend on the implementation and browser controls. Iframe isolation depends on origin, sandbox and permission configuration. Content Security Policy, compatible integrity checks, server mediation and separation from critical paths may help some integrations, but require technical and security review. Subresource Integrity checks expected bytes for supported resources; it does not validate every API, iframe, service or business behaviour.
A facade can postpone an optional iframe and its subresources until activation, but the placeholder, consent state, keyboard behaviour, labelling and activated experience still require functional and accessibility testing. Self-hosting carries a similar qualification: moving delivery onto organisational infrastructure does not remove licensing, maintenance or upstream software risk. In the scheduling example, retaining the widget could be conditional on adding journey-level monitoring, preserving the tested accessible contact route and reopening the decision when a relevant change or incident occurs.
Keep the map current by embedding review triggers in normal website operations rather than relying on one universal calendar cadence. Supplier-mapping guidance supports a maintained central record assembled from existing information stores, while third-party JavaScript guidance recommends identification, measurement and periodic audit before mitigation. The appropriate frequency and depth depend on journey importance and change. Every trigger should update last observed use, current contract or assurance status, the latest decision, its owner, open actions and the next event requiring review.
Start with one priority journey during the first week. Capture its major states, reconcile browser observations with known platform and supplier records, create the initial rows, assign provisional owners and plan one authorised failure exercise. Connect monitoring to user-visible symptoms and measurement gaps rather than treating endpoint availability as proof of health. For new dependencies, require a documented purpose, owner, information flow, expected contextual cost, failure behaviour, fallback, monitoring approach and review trigger before adoption.
Expand the register proportionately once the first journey exposes where evidence and ownership are weak. 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 need explicit authorisation and appropriately qualified owners. The register supports those decisions by making reliance visible; it does not replace professional judgement, contracts, operational runbooks or accountable approval.
It is an externally controlled reliance whose change, delay, unavailability, compromise or data practice can materially affect an in-scope website journey. A different hostname is useful discovery evidence, but an external service may use a first-party hostname and an internal-looking origin may still have a separate owner or failure boundary.
Use two passes: capture representative browser journeys, then reconcile the observations with architecture, configuration, procurement, contracts, supplier records and stakeholders. Put the combined evidence into a maintained register linked to journey steps, owners, information flows, costs, failure effects, fallbacks and review triggers.
Record browser requests, resource types, initiators, tag-manager descendants, timing, sizes and activation conditions across meaningful journey states. Then inspect infrastructure and operational records to find DNS, certificates, hosting, identity, server-side integrations and upstream suppliers that the browser cannot reveal.
Use an authorised test environment or explicitly approved browser tooling and change one condition at a time after defining the expected usable state. Observe the complete journey, accessibility, fallback, errors and monitoring; do not create an unapproved production outage or assume browser blocking represents every possible failure.
Only when the organisation can lawfully and operationally own licensing, delivery, updates, integrity, privacy, maintenance and support. Self-hosting moves delivery control, but it does not remove upstream software, maintenance or supplier risk.
This article was researched using the following sources:
Website Governance and Operations
Build an adaptable eight-domain website governance matrix that assigns decision owners, defines delegated boundaries and gives every escalation a clear route.
Build a practical accessibility testing matrix that assigns every check, evidence record, release decision and retest to the right delivery role.
Web Analytics and Experimentation
Build a decision-led website measurement plan that links owner choices and user outcomes to focused evidence, data limits and scheduled review actions.
