Check WordPress performance by measuring a representative visitor journey, identifying the likely bottleneck and verifying a focused change under comparable conditions. Record page state, device and test method before interpreting a score. Check that the page still performs its intended task, then review field evidence as well as controlled measurements.
Begin with the problem the reader notices. A slow first view, delayed response to a control and movement during loading describe different experiences. Choose an affected page and a useful comparison page. Record the intended task so the performance investigation stays connected to what visitors need to accomplish.
Which measurements describe the experience?
Google’s Web Vitals guide defines complementary metrics. Largest Contentful Paint measures loading performance. Interaction to Next Paint measures interactivity. Cumulative Layout Shift measures visual stability. Use the metric that relates to the reported problem and retain the conditions in which it was observed.
A single aggregate score can be a prompt for investigation, but the reviewer still needs to understand which part of the experience needs attention. Record the tool, page address, device arrangement and relevant interaction. Keep the underlying observations so a later comparison can examine the same question.
Google’s Web Vitals guidance says lab measurement does not substitute for field measurement. Use a controlled measurement to investigate a proposed change and real-user evidence to understand the experience represented by actual visits. Identify which kind of evidence a report contains rather than treating the two as interchangeable.
Where the available evidence is limited, describe the observation precisely. An individual controlled run relates to that run’s page state and conditions. Ask what additional measurement would help assess the affected journey before making a wider claim about the whole website.
Where should the WordPress investigation start?
The WordPress optimisation guide describes several layers. WordPress says the available optimisation techniques depend on the hosting setup. Identify which settings the site team can manage and which require the hosting administrator, then keep proposed changes within the authorised scope.
Its optimisation guide recommends selectively disabling plugins to measure server performance. Use a controlled test environment and a recoverable configuration record when investigating an extension. Include the function the plugin provides in the review so a faster page is assessed alongside whether the required journey still works.
It recommends choosing an appropriate image format and compression for each image. Examine the images involved in the affected view and retain the approved visual content. Compare the delivered asset and its appearance after a proposed change, including whether its crop and text alternatives remain suitable for the page.
It describes caching plugins as serving cached posts and pages as static files. It says browser caching can reduce requests and server load. Establish what is already configured before adding another caching layer, and ask the maintainer how the chosen arrangement handles the actual page states being tested.
It describes persistent object caching as reducing database trips. Treat that as a different layer from delivering a cached page or reusing a browser asset. Ask the hosting maintainer which layer the evidence points towards and what observation would demonstrate that a proposed change addresses the identified problem.
How can observations guide a focused change?
The original worksheet below links symptoms to questions rather than prescribing the same optimisation for every site. Complete it with measurements from the selected page and keep the proposed investigation beside the original evidence.
| Observed experience | Question to investigate | Comparison to retain |
|---|---|---|
| Main content appears slowly | Which resource or response delays that content? | Same page state and loading observation |
| Control responds late | Which work occurs during the interaction? | Same action and relevant timing evidence |
| Layout moves during loading | Which element changes its position or space? | Comparable view and visible shift |
| Repeated visit behaves differently | Which cache state applies to each run? | Cold and repeat conditions labelled clearly |
| Logged-in task differs from public view | Which content and cache rules apply? | Correct account state and functional result |
| Proposed plugin change helps one page | Which other task depends on the extension? | Affected page and dependency checks |
Choose one hypothesis to test at a time where practical. Record the changed item, expected effect and recovery route. If several changes are bundled together, explain that limitation when interpreting the result and keep enough detail for the maintainer to investigate an unexpected outcome.
Compare relevant conditions, including whether the page was already cached and whether the reviewer was logged in. Keep deliberate differences visible. A comparison becomes more useful when another maintainer can explain which variables changed and which remained consistent during the exercise.
Original service-page bottleneck exercise
Prepare a hypothetical service page with a prominent photograph, an enquiry control and content that continues below the first view. Use an authorised test arrangement and approved sample material. Write the task as finding the service requirements and starting an enquiry, then record the baseline measurement method.
Inspect the loading and interaction evidence before choosing a change. Suppose the team wants to investigate the delivered photograph: identify the actual asset and its role in the page, then prepare a suitable alternative derivative while retaining the original. This is a proposed investigation, with the measured outcome left for the project team to establish.
Repeat the comparable page check after applying the scoped change. Inspect the visible photograph, its crop and the surrounding layout as well as the recorded loading observation. Follow the enquiry control and confirm the intended test journey still works. Preserve any unexpected behaviour alongside the timing evidence.
Next, ask another reviewer to distinguish the loading result from the interaction and stability observations. An image-related change needs evidence for its actual effect; the report should not silently claim it resolved an unrelated delay. Identify the next hypothesis only after reviewing what the comparison establishes.
Keep a brief acceptance note with the retained records: what changed, what was observed, which functional checks were performed and who decided whether to keep the change. If the result is inconclusive, record what would make the next comparison more informative rather than selecting the most favourable isolated number.
What belongs in the performance handover?
Give the owner the affected page list, measurement conditions, approved configuration and recovery location. Separate controlled test evidence from field reports and explain which visitor task each concerns. Assign the follow-up owner so an unresolved bottleneck has a clear next investigation.
When content or functionality changes later, review the relevant measurement and journey again. Preserve the earlier records so the team can examine the change in context. This makes the performance work a repeatable investigation anchored to a useful page, rather than a collection of scores without an explanation.
For related work, see hosting and website development. Get started with affected pages, performance observations and the visitor tasks that matter most.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.