Website performance checklist: what to fix first

Define the outcome and audit scope before collecting issues

Name the business outcome in plain language: more qualified enquiries for a service, fewer abandoned bookings, more completed purchases, or fewer support calls caused by confusing information. Add the user outcome that enables it, such as finding eligibility details, comparing options, completing a form with a keyboard, or seeing confirmation that payment succeeded. This prevents visual preferences and low-impact warnings from displacing failures in the journey that funds the website.

Select a representative set of page templates and journeys rather than testing only the homepage. Include a high-traffic landing page, an important service or product page, a content page, a form or checkout, confirmation and error states, and any logged-in or location-specific route that matters. Segment mobile and desktop evidence where possible. Averages can hide a serious problem affecting one device class, browser, page group, traffic source, or step in the funnel.

Record a baseline before changing anything. Useful evidence can include qualified enquiries or completed orders, form errors, funnel exits, support themes, organic clicks and landing pages, real-user performance, and observed accessibility barriers. State the date range, page scope, device mix, and known campaigns or outages. If measurement is incomplete, label the gap instead of converting an assumption into a precise forecast.

• Choose one primary journey and two or three supporting journeys.
• Test the pages and states people actually use, including errors and confirmations.
• Separate observed evidence from hypotheses that still need testing.
• Give every accepted finding an owner and a retest method.

Remove critical blockers and misleading experiences first

A broken payment, enquiry form, navigation control, sign-in, telephone link, or consent choice outranks a cosmetic refinement. So do missing focus indicators, keyboard traps, unreadable error messages, content hidden from assistive technology, insecure pages, and an important landing page that returns an error or cannot be indexed. These defects can stop a customer completely, create legal or reputational exposure, and invalidate the measurement used to judge other improvements.

Test the whole route with realistic input. Submit the form, use invalid values, move backwards, refresh, and confirm what the recipient receives. Navigate using a keyboard without a mouse, zoom the page, check visible focus, and try the route on a narrow mobile screen. For an ecommerce journey, include basket changes, delivery choices, payment failure, and confirmation. For a lead-generation site, confirm that the message reaches the correct team with enough context to respond.

Treat a missing or misleading confirmation as a failure even when the server accepted the request. A visitor who sees a spinner indefinitely may submit repeatedly or leave; the business may record duplicate leads and mistake them for improved conversion. Fix the experience, data handling, and operational hand-off together. A front-end success state is not enough if notifications fail or no one owns the incoming request.

Measure performance with field and lab evidence

Use field data to understand how eligible real visits performed over time and lab tests to reproduce and diagnose a page under controlled conditions. PageSpeed Insights may show both, but they answer different questions. Field data can reveal patterns across devices and networks; a lab trace can identify an oversized image, render-blocking resource, long main-thread task, or layout shift. A single Lighthouse run is not a reliable before-and-after business result.

The current Core Web Vitals cover loading, responsiveness, and visual stability. Google's web.dev guidance defines good thresholds as Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, assessed at the 75th percentile and segmented by mobile and desktop. Use those thresholds as shared diagnostic targets, not as a promise of ranking or conversion gains.

Prioritise the slow templates and resources that affect valuable journeys or many pages. A shared header script delaying interaction across the site normally deserves attention before a small image on a rarely visited article. Common opportunities include correctly sized responsive images, reserved media dimensions, leaner third-party scripts, less client-side work, better caching, and faster server responses. The right fix depends on the trace and architecture; deleting features blindly can damage usability or measurement.

• Check real-user patterns before optimising for one test device.
• Repeat controlled tests to reduce noise and compare like with like.
• Diagnose the element, task, request, or template behind the metric.
• Retest the affected journey after release, not only the isolated page.

Combine automated accessibility checks with human testing

Automated tools are useful for repeatable checks such as missing labels, invalid relationships, certain contrast failures, and structural problems, but they cannot determine whether every control has an understandable name, content order makes sense, alternative text is useful, or a journey works for a person using assistive technology. W3C explicitly states that no tool alone can determine whether a site meets accessibility standards; knowledgeable human evaluation is required.

Start with the important journeys and test keyboard access, focus order, focus visibility, headings, landmarks, link and control names, form labels, instructions, errors, zoom, reflow, contrast, motion, media alternatives, and announcements of dynamic changes. Include disabled users in evaluation where the scope and risk justify it. WCAG 2.2 is a technical standard and useful reference, but ticking isolated criteria is not the same as delivering an understandable and usable service.

Prioritise by the severity of the barrier, the importance and frequency of the affected task, how widely the component is reused, and whether an interim accessible route exists. A keyboard trap in a shared menu is urgent because it blocks navigation across many pages. Weak alternative text on a decorative image is different in impact. UK service providers should understand their duties to anticipate reasonable adjustments, while obtaining qualified advice for their particular legal position rather than treating an audit tool as legal certification.

Review conversion as a complete customer journey

Conversion optimisation begins with clarity and trust, not pressure. A priority page should explain what is offered, who it is for, important conditions, what happens next, and how to act. The main action should be easy to identify without preventing access to supporting information. Check whether pricing, eligibility, delivery areas, response expectations, evidence, contact details, and privacy information appear where a reasonable customer needs them.

Inspect the journey for avoidable decisions and requests. Remove fields that have no operational purpose, use suitable input types and autocomplete, preserve entered information after a correctable error, and explain errors beside the relevant field in text. Do not make acceptance of optional marketing a condition of an enquiry, and do not use visual tricks to steer people away from a privacy choice. Review current ICO guidance before adding analytics, session recording, personalisation, or experimentation technology that stores or accesses information on a user's device.

Use analytics to locate a problem, then observe and test to understand it. A high exit rate may reflect a broken form, a mismatch between advert and landing page, successful use of a telephone number, or a page that answered the question without requiring another step. Search Console and analytics measure different systems, so their totals need not match. Look for stable patterns by page, query, channel, device, and journey rather than treating one dashboard number as proof of cause.

Score the backlog, release safely, and learn

Use a small scoring model that the team can explain. Rate each finding for severity, reach, business value, and confidence, then consider effort and delivery risk. Blockers and high-severity accessibility or security issues should not wait for an attractive score. For the rest, the model helps distinguish a repeated template defect affecting thousands of visits from a speculative rewrite on a low-value page.

For example, suppose mobile visitors can reach a quotation form, but the date picker cannot be operated with a keyboard and the page's main image delays the largest contentful paint. Fix the inaccessible input first if it prevents completion, then optimise the shared image delivery and confirm the form still works. A proposal to change the button colour can remain a hypothesis until evidence suggests that clarity or visibility is the actual problem.

Release related changes in small, reviewable groups. Run automated tests, repeat manual accessibility and journey checks, and watch performance and error reporting for regressions. Preserve URLs, metadata, tracking definitions, and consent behaviour unless the change requires them to move. If an experiment is appropriate, define the audience, primary outcome, guardrail measures, duration, and stopping rule before launch; do not keep testing until a favourable result appears.

After release, compare the same evidence used for the baseline and allow for traffic mix, seasonality, campaigns, and processing delays. Record what changed, what improved, what did not, and what the team learned. The goal is not a permanently empty backlog. It is a reliable improvement cycle in which urgent barriers are removed, valuable journeys become easier, and new releases are less likely to recreate old problems.

A practical 30-day website improvement plan

Related Clicknex resources