Resources · 06

Secure, high-performance web: a journey-led audit guide

Audit speed, accessibility, security and conversion around the actions users genuinely need to complete.

Updated 23 October 2026 · 11 min

Illustration · fictional scene

What this guide helps achieve

Prioritise real user blockers
Reduce weight, dependencies and attack surface
Connect performance to conversion
Validate fixes under realistic conditions

Quick check

Are the three most valuable journeys named?
Is field data segmented for mobile?
Can the site be used by keyboard?
Does every third-party script have an owner?
Do form errors help users finish the action?

Step-by-step method

01
Choose critical journeys
Select search, reading, contact, signup, purchase or administration based on business value. Describe device, network, context and expected outcome.
Deliverable: prioritised test scenarios.
02
Measure field and lab
Combine aggregated real-user data with reproducible tests. Observe loading, responsiveness, stability, errors and abandonment without reducing analysis to one score.
Deliverable: segmented baseline.
03
Inspect the critical path
Review initial HTML, fonts, images, JavaScript, caching, server response and blocking resources. Give elements serving the journey an explicit budget.
Deliverable: performance budget.
04
Reduce exposed surface
Inventory third-party scripts, dependencies, headers, cookies, sessions, forms and admin interfaces. Remove the unnecessary and harden on the server.
Deliverable: dependency and protection register.
05
Test inclusive experience
Run every action by keyboard, screen reader, small screen, zoom and error state. Check labels, focus, contrast and recovery messages.
Deliverable: accessibility and friction report.
06
Release with guardrails
Automate stable controls, observe business outcomes after release and prepare rollback. A fix closes when the real journey improves without regression.
Deliverable: continuous validation plan.

Understand · try · decide

Core Web Vitals: interpret thresholds and measurement scope

LCP describes main-content loading, INP interaction responsiveness and CLS visual stability. Their “good” thresholds are 2.5 s, 200 ms and 0.1 respectively. Read field data at the 75th percentile, separating mobile and desktop. A single laboratory test does not represent that distribution.

Before changing anything, record the page or page group, period, device type and origin of each value. The tool below classifies three values you provide; it does not visit your website. A missing value still needs to be measured.

For a product page, inspect the resource responsible for LCP, reproduce the slow interaction and locate the visible shift. After a change, compare the same journeys and devices. Retain functional evidence too: a fast button that no longer submits an order is not an improvement.

Reference points and evidence to retain

Reference point	What you can conclude	Evidence to retain
LCP ≤ 2.5 s	Main content within the good range	p75 value, URL or group, device and period
INP ≤ 200 ms	Responsiveness within the good range	p75 value and reproduced interaction
CLS ≤ 0.1	Stability within the good range	p75 value and element causing the shift

From observation to decision

Define the scope
Observe field data
Reproduce the cause
Change and compare

Choose a correction from comparable measurements

These are Google’s published reference thresholds, not measurements of this website. Compare the same period, device and scope. Overall good performance requires all three metrics to be good; a missing metric cannot be inferred from the other two.

Good LCP at p75: 2.5 sMain-content loading
Good INP at p75: 200 msInteraction responsiveness
Good CLS at p75: 0.1Layout stability

Three interpretation ranges
Metric	Good	Needs improvement	Poor
LCP (s)	≤ 2.5	> 2.5 and ≤ 4	> 4
INP (ms)	≤ 200	> 200 and ≤ 500	> 500
CLS	≤ 0.1	> 0.1 and ≤ 0.25	> 0.25

At the boundaries, 4 s, 500 ms and 0.25 remain in the needs-improvement range under Google’s reference table. Keep seconds and milliseconds distinct.

Three fictional diagnoses with different actions
p75 measurements	Interpretation	Action to verify
LCP 3.2 s · INP 180 ms · CLS 0.08	Only main-content loading needs improvement.	Identify the LCP element and separate server wait, download and render delay.
LCP 2.2 s · INP 650 ms · CLS 0.05	Responsiveness is poor despite good loading.	Reproduce the slow interaction, inspect long tasks and verify visible feedback after the action.
LCP 2.4 s · INP 190 ms · CLS 0.28	Layout stability is poor.	Locate the shift and reserve dimensions for media or injected spaces.

None of these examples describes real visitors. Confirm the correction using field observations.

Checks before concluding

Retain the tool, dates, URL or origin, device and observation count when available. Origin-level data may not describe the page being investigated.
Review journeys without interactions separately: missing INP does not mean instantaneous interaction.
Use the lab to reproduce a cause; a Lighthouse score and TBT do not replace INP measured with actual interactions.

Decision: correct the observed cause, replay the journey and compare the same distributions. Good performance does not certify accessibility or security.

Calculation rule

Good: LCP ≤ 2.5; INP ≤ 200; CLS ≤ 0.1. Poor: LCP > 4; INP > 500; CLS > 0.25. Between those ranges: needs improvement.

Change an assumption

One site, two measurement conditions

A good isolated test and a field indicator answer different questions. This fictional case helps select the next check.

Laboratory
A controlled visit yields a 1.8 s LCP.
Field
Observed mobile p75 for a defined period is 3.4 s.
Diagnosis
Identify represented pages, devices and conditions before attributing the gap to a cause.

Reading exercise: the variations describe fictional situations.

Should the quick test replace field data?

New evidence: The figures concern different populations and conditions.
What changes: Retain both with their provenance. Use the lab to reproduce an issue; verify the fix within the chosen field scope.

What if field data is insufficient?

New evidence: The report supplies no usable value for the page.
What changes: Describe the value as unavailable, never zero. Broaden diagnosis using an explicitly identified scope without claiming to have measured that URL.

Worked example

Illustrative situation

A booking page seems fast in a lab but its confirmation button responds slowly on mobile. The team segments field measurements by device and journey, then tests less JavaScript and keyboard behaviour.

Decision and expected evidence

The change is accepted only if the task remains accessible, interaction improves and the journey’s security controls still work.

Management indicators

Indicator	What it measures	First action
Journey success	Users completing the action without a blocking error	Fix breaks shared by several segments first
Field performance	Loading, interaction and stability on real devices	Segment before targeting the dominant bottleneck
Third-party cost	Bytes, main-thread time and requests outside direct control	Remove, defer or replace each non-essential third party
Error rate	Technical and input failures by step	Improve prevention, message and recovery

Common pitfalls

Optimising the home page only
Confusing a lab score with real experience
Adding a security tool without removing unnecessary risk
Damaging accessibility or measurement to save milliseconds

Frequently asked questions

Do performance and security conflict?

No. Reducing dependencies, JavaScript and unnecessary requests often improves both. Trade-offs should be measured against actual journeys and risk.

What score should we target?

One threshold does not replace field data. Set budgets by journey, device and audience, then track them alongside business outcomes.

Why include accessibility in the audit?

Because a fast action that cannot be used by keyboard, understood or recovered from remains a user and commercial failure.

References: data, uses and limitations

Documentation reviewed on 2026-10-22.

References: data, uses and limitations
Source and purpose	Verified data or benchmark	How to use it	Limitation to retain
MDN · Cookie boundaries Understand session-cookie scope and SameSite boundaries.	Secure, HttpOnly, SameSite and the __Host- prefix address different risks. A site can include multiple origins.	Test external navigation, subdomains, provider returns and authenticated operations separately. Explore the method →	Cookie configuration does not replace CSRF checks or server-side authorisation.

Session cookies: separate site, origin and host boundaries

Two HTTPS subdomains can be same-site while having different origins. SameSite uses a site boundary; CORS uses an origin boundary. Neither decision replaces server-side checks of the user’s permissions.

Teaching examples use the reserved example.org domain. Scope also depends on the registrable domain, scheme and browser policies. These examples create no requests or cookies.

Session cookies: separate site, origin and host boundaries
Attribute	Protection provided	Boundary to test
`Secure`	Restricts cookie transmission to secure connections, with browser-documented local exceptions.	Does not prevent scripts reading a cookie when HttpOnly is absent.
`HttpOnly`	Prevents cookie access through JavaScript APIs such as document.cookie.	A script-triggered request can still include the cookie; XSS remains dangerous.
`SameSite=Lax`	Restricts cross-site sending, with an exception notably for some top-level navigations using a safe method.	Never perform a state-changing action using GET. Also test same-site subdomains.
`SameSite=None; Secure`	Allows cross-site sending subject to the browser’s other rules and policies.	Does not override third-party-cookie restrictions or remove the need for CSRF protection.
`__Host-`	In browsers enforcing this prefix: Secure, Path=/ and no Domain attribute.	Restricts scope to the host. Does not isolate ports or establish action authorisation.

Three situations to examine

A neighbouring subdomain is compromised

https://blog.example.org and https://app.example.org have different origins but can be same-site. SameSite alone is therefore not a boundary against an untrusted subdomain. Check allowed origins and CSRF protection for sensitive operations.

An HttpOnly cookie cannot be read, but an action succeeds

This is consistent with HttpOnly: it prevents reading, not sending with a request. Check XSS defences, CSRF tokens and server-side authorisation separately.

A provider’s return journey loses the session

Compare top-level navigation versus iframe, HTTP method, origins and received attributes. Do not switch everything to SameSite=None to hide the issue; define this journey’s requirements and retain its CSRF protection.

Reference reading · consulted 2026-10-25 · MDN · Set-Cookie · OWASP · CSRF

IANA references and DNSSEC interpretation

Distinguish resolution, caching and web responses

An outage can occur before any HTTP response. Examine DNS resolution, its validation and caches separately from the web server.

Record the failing stage and the resolver involved.
A received TTL and RRSIG expiration are different constraints.
An error disappearing on one device does not prove recovery for all visitors.

Read the registries and try the cache model →

IETF · RFC 4033 · §3–5 · 2026-10-23

Extensions: permissions and access

Include the browser in exposure scope

A hardened site can still be visited from a profile with highly authorised extensions. Keep the boundary between site security, browser capabilities and managed-endpoint choices visible.

Inventory the test profile’s extensions with version and accountable owner.
Explain each required host and check optional permissions actually granted.
Test restriction and removal; static manifest reading cannot replace code and traffic observation.

Read the permission directory and manifest examples →

Microsoft Learn · Manage Microsoft Edge extensions using group policies · Enterprise policy documentation consulted 2026-10-23

CSP: directives, fallback and journeys

CSP tells a browser which resources and certain behaviours a page permits. Reviewing it requires distinguishing the requested directive, its possible fallback, policy mode and delivery. A directive name in a header alone does not establish that a user journey is protected.

Twelve fallback chains extracted from CSP3 §6.8.3, three independent checks and eight fictional scenarios. Reference: W3C Working Draft of 16 September 2026, a work in progress rather than a final Recommendation. The consulted IANA registry contains sixteen names and was updated 3 February 2023.

W3C · Content Security Policy Level 3 · Mike West, Antonio Sartori · Working Draft · 2026-09-16 · work in progress · §2.2.1, §3, §6.8.3–6.8.4, §8.1

Twelve fallback orders and three checks without default-src

The selected list is not added to default-src. A present but empty directive also stops lookup. The final three rows are not fetch chains: base-uri, form-action and frame-ancestors require their own directive.

Twelve fallback orders and three checks without default-src
Requested check	Lookup order · first present directive wins	Reference
`script-src-elem`	`script-src-elem → script-src → default-src`	CSP3 §6.8.3
`script-src-attr`	`script-src-attr → script-src → default-src`	CSP3 §6.8.3
`style-src-elem`	`style-src-elem → style-src → default-src`	CSP3 §6.8.3
`style-src-attr`	`style-src-attr → style-src → default-src`	CSP3 §6.8.3
`worker-src`	`worker-src → child-src → script-src → default-src`	CSP3 §6.8.3
`connect-src`	`connect-src → default-src`	CSP3 §6.8.3
`manifest-src`	`manifest-src → default-src`	CSP3 §6.8.3
`object-src`	`object-src → default-src`	CSP3 §6.8.3
`frame-src`	`frame-src → child-src → default-src`	CSP3 §6.8.3
`media-src`	`media-src → default-src`	CSP3 §6.8.3
`font-src`	`font-src → default-src`	CSP3 §6.8.3
`img-src`	`img-src → default-src`	CSP3 §6.8.3
`base-uri`	`base-uri`	base-uri
`form-action`	`form-action`	form-action
`frame-ancestors`	`frame-ancestors`	frame-ancestors

CSP reading workshop

Choose a case and a check. This workshop uses pre-separated example directives, keeps the first occurrence of each name and stops at the first directive present in the stated order. It does not parse arbitrary CSP or check source expressions, URLs, nonces, hashes, redirects or actual browser behaviour.

Each policy is read separately with its mode and delivery. Values are displayed as text; the workshop loads no resource named by an example.

Delivery and mode: three different readings

Delivery and mode: three different readings
Mechanism	What to check	Limit
Content-Security-Policy	Response header and policies actually received.	Each enforced policy adds its constraint; a second cannot relax the first.
Content-Security-Policy-Report-Only	Violation observation and the configured reporting path.	Monitoring mode does not enforce this policy’s blocking.
meta http-equiv	Element position and content processed before it.	Report-Only, frame-ancestors, report-uri and sandbox are not supplied by this mechanism.

Eight reading scenarios and acceptance exercises

C01 · Fallback to default-src

script-src-elem

1 · enforce · header

Content-Security-Policy: default-src 'none'

Reading : script-src-elem and script-src are absent, so the chain reaches default-src. This list does not define base-uri, form-action or frame-ancestors.

Test to add : Select those three independent checks as well. Do not infer protection against embedding the page from default-src.

C02 · Fallback is not source-list merging

script-src-attr

1 · enforce · header

Content-Security-Policy: default-src 'none'; script-src 'self'

Reading : script-src-attr reaches script-src before default-src. Their lists are not concatenated. The presence of self alone does not authorise an inline event handler.

Test to add : Test script elements, event attributes and other relevant mechanisms separately. The workshop selects a directive; it does not decide whether a script executes.

C03 · A worker reaches child-src before script-src

worker-src

1 · enforce · header

Content-Security-Policy: default-src 'none'; script-src 'self'; child-src https://frames.example.net

Reading : worker-src is absent. The first directive present in its fallback order is child-src. The word child does not mean only iframes are affected.

Test to add : Check workers and frames separately; record the selected control and observe the browser in its real context.

C04 · A specific directive stops fallback

worker-src

1 · enforce · header

Content-Security-Policy: default-src 'none'; child-src https://frames.example.net; worker-src 'self' blob:

Reading : worker-src is present: neither child-src nor default-src supplies the list for this check. Its value is displayed without checking a URL, redirect or local scheme.

Test to add : Test creation and loading of expected workers together with their own policy and dependencies. Do not treat this illustrative list as universal configuration.

C05 · An empty directive is not absent

img-src

1 · enforce · header

Content-Security-Policy: img-src; img-src https://images.example.net; default-src 'self'

Reading : The first img-src occurrence is retained with an empty list. The second occurrence is discarded in this policy; the workshop does not replace the first with default-src.

Test to add : Check duplicates in configuration and the received response. A present field without source expressions must not be treated as missing.

C06 · Two enforced policies remain two constraints

connect-src

1 · enforce · header

Content-Security-Policy: default-src 'self'; connect-src 'none'

2 · enforce · header

Content-Security-Policy: connect-src https://api.example.net

Reading : The first policy retains connect-src none; the second names an origin. Adding the second does not lift the first policy’s restriction. Results are shown separately.

Test to add : Observe every received header after CDN and proxy handling. Do not unite both policies’ sources into a broader allowlist.

C07 · Monitoring is not enforcement

script-src-elem

1 · enforce · header

Content-Security-Policy: script-src 'self'

2 · report-only · header

Content-Security-Policy-Report-Only: script-src 'none'

Reading : script-src is selected in both policies. The second is Report-Only: it monitors violations without enforcing its blocking. The first retains its own effect.

Test to add : Plan report collection and check real journeys before a separately decided enforcement change. A monitored directive name alone does not establish blocking.

C08 · frame-ancestors in meta is ignored

frame-ancestors

1 · enforce · meta

<meta http-equiv="Content-Security-Policy" content="default-src 'none'; frame-ancestors 'none'">

Reading : This directive is not supported in a meta-delivered policy. default-src remains a resource control rather than a fallback for frame-ancestors.

Test to add : Inspect the policy actually received in headers and authorised embeddings. A meta element cannot supply Report-Only mode either.

Sixteen IANA names: registration differs from support

CSP2 registry references are preserved verbatim. This copy does not list every CSP3 addition: absence of worker-src or script-src-elem does not invalidate those names in CSP3. Conversely, a historical name such as plugin-types does not establish support in a current browser.

IANA · Content Security Policy Directives · Registry updated 2023-02-03 · consulted 2026-10-23

Sixteen IANA names: registration differs from support
Registered name	Registry reference	Registration date
`base-uri`	https://www.w3.org/TR/CSP2	2015-11-24
`child-src`	https://www.w3.org/TR/CSP2	2015-11-24
`connect-src`	https://www.w3.org/TR/CSP2	2015-11-24
`default-src`	https://www.w3.org/TR/CSP2	2015-11-24
`font-src`	https://www.w3.org/TR/CSP2	2015-11-24
`form-action`	https://www.w3.org/TR/CSP2	2015-11-24
`frame-ancestors`	https://www.w3.org/TR/CSP2	2015-11-24
`frame-src`	https://www.w3.org/TR/CSP2	2015-11-24
`img-src`	https://www.w3.org/TR/CSP2	2015-11-24
`media-src`	https://www.w3.org/TR/CSP2	2015-11-24
`object-src`	https://www.w3.org/TR/CSP2	2015-11-24
`plugin-types`	https://www.w3.org/TR/CSP2	2015-11-24
`report-uri`	https://www.w3.org/TR/CSP2	2015-11-24
`sandbox`	https://www.w3.org/TR/CSP2	2015-11-24
`script-src`	https://www.w3.org/TR/CSP2	2015-11-24
`style-src`	https://www.w3.org/TR/CSP2	2015-11-24

IANA · Protocol Registries · CC0 1.0 · Revised 2021-11-10

Test protection without breaking the journey

Test protection without breaking the journey
Proposed CIE journey	Control to review	Useful evidence
Sign-in and recovery	Required scripts, styles, frames and connections.	Success, useful refusal, recovery and errors observed with received policies.
Payment or external integration	frame-src for embedded content; frame-ancestors for who embeds your page.	Test the two directions separately rather than conflate them.
Form and confirmation	form-action, validation scripts and API requests.	Submission and confirmation received; a click alone does not establish processing.
Worker and deferred features	worker-src and its fallback order.	Creation, dependent resources and visible errors in the authorised context.
Third-party addition	Inventory of actually required scripts, connections, images and frames.	Documented need and sampled journeys; no wildcard added to hide a breakage.
Progressive release	Observed mode, configuration version and stop criteria.	Reviewed reports, attributed defects, tests and an enforcement decision.

Associate a policy with the page version and test critical journeys after CDN or proxy transformations. CSP is defence in depth: it does not replace output encoding, dependency control or access checks. This model explains directive selection rather than a security verdict.

Provenance, edition and licence

W3C CSP3 · Working Draft 2026-09-16 · reviewed 2026-10-23 · IANA registry 2023-02-03

IANA XML SHA-256: 42d2068b345f9b1df2bb124dd8b20e26d16dbd86960aafb62624aa285f2997c0

W3C HTML SHA-256: df90a9028632b39c70d9ed40dadfadbc2f3f690621ecf6212ef4f1376005738e

W3C · Software and Document license · 2023 · Effective 2023-01-01 · full notice below

This document and its lookup data include material derived from Content Security Policy Level 3, https://www.w3.org/TR/2026/WD-CSP3-20260916/. Copyright © 2026 World Wide Web Consortium. https://www.w3.org/copyright/software-license-2023/
Changes: selected fallback lists extracted as data; original CIE explanations, fictional scenarios and limited lookup implementation added.

This work is being provided by the copyright holders under the following license.
By obtaining and/or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions.
Permission to copy, modify, and distribute this work, with or without modification, for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the work or portions thereof, including modifications:
The full text of this NOTICE in a location viewable to users of the redistributed or derivative work.
Any pre-existing intellectual property disclaimers, notices, or terms and conditions. If none exist, the W3C software and document short notice should be included.
Notice of any changes or modifications, through a copyright statement on the new code or document such as "This software or document includes material copied from or derived from [title and URI of the W3C document]. Copyright © [$year-of-document] World Wide Web Consortium. https://www.w3.org/copyright/software-license-2023/"
THIS WORK IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE OR DOCUMENT WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE SOFTWARE OR DOCUMENT.
The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the work without specific, written prior permission. Title to copyright in this work will at all times remain with copyright holders.

Core Web Vitals: thresholds and field data

Web performance: state the measurement scope

Before announcing a gain, retain device, URL or origin and collection period.

Compare the same device, scope and documented periods.
Do not turn missing data into zero.
Verify functions and accessibility after the fix.

Read the thresholds and try the p75 reader →

Google · About PageSpeed Insights · Living documentation · consulted 2026-10-23

Official references

References consulted: 23/10/2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.

What this guide helps achieve

Quick check

Step-by-step method

Choose critical journeys

Measure field and lab

Inspect the critical path

Reduce exposed surface

Test inclusive experience

Release with guardrails

Reference points and evidence to retain

From observation to decision

Choose a correction from comparable measurements

Checks before concluding

Calculation rule

One site, two measurement conditions

Worked example

Illustrative situation

Decision and expected evidence

Management indicators

Common pitfalls

Frequently asked questions

References: data, uses and limitations

Session cookies: separate site, origin and host boundaries

Three situations to examine

IANA references and DNSSEC interpretation

Distinguish resolution, caching and web responses

Extensions: permissions and access

Include the browser in exposure scope

CSP: directives, fallback and journeys

Twelve fallback orders and three checks without default-src

CSP reading workshop

Result per policy

Delivery and mode: three different readings

Eight reading scenarios and acceptance exercises

Sixteen IANA names: registration differs from support

Test protection without breaking the journey

Core Web Vitals: thresholds and field data

Web performance: state the measurement scope

Official references

The Business Value of Redesigning Your Website for W3C Compliance and Accessibility

Mastering Payment API Integration: Strategies and Best Practices for Secure Digital Transactions