A slow WordPress website is best improved by measuring the page first, fixing the largest confirmed bottleneck, and testing again—not by installing several performance plugins at random. Start with a key page on mobile, compare field and lab measurements where available, then review image weight, scripts, caching and hosting one step at a time.
That sequence matters because a slow page can have more than one cause. A large hero image, delayed server response, a plugin, an external widget or a cache configuration can affect different pages in different ways. A single score does not tell you which change is safe or useful.
What should I measure first?
Use Google PageSpeed Insights on a representative page, such as the homepage and a page that generates enquiries. Check mobile and desktop separately. PageSpeed Insights can show both Chrome user-experience data from the Chrome User Experience Report (CrUX) and a Lighthouse lab test. The field panel may be unavailable when a page or site does not meet CrUX’s data-eligibility thresholds; a lab result is still useful for diagnosis, but it is not a substitute for real-user data.
The three current Core Web Vitals describe loading, responsiveness and visual stability:
- Largest Contentful Paint (LCP): how quickly the main visible content appears. The “good” target is 2.5 seconds or less.
- Interaction to Next Paint (INP): how quickly the page responds to user interactions. The “good” target is 200 milliseconds or less.
- Cumulative Layout Shift (CLS): how much visible content unexpectedly moves. The “good” target is 0.1 or less.
For field data, these targets are assessed at the 75th percentile of page loads, not by treating one lab run as the experience of every visitor. CrUX field data is a rolling 28-day view, so it will not immediately reflect a change made today. See Google’s Core Web Vitals guidance, web.dev’s metric definitions and its PageSpeed Insights measurement guide.
Record the tested URL, device, date, whether field data was available, and the main failing metric. Keep the original result so you can compare the same page again after a change.
1. Check the biggest image and other visible content
If LCP is poor, inspect what PageSpeed Insights identifies as the largest visible element. On many business pages this may be a hero image, but confirm it rather than assuming. Make sure the image is no larger than its displayed dimensions require, use an efficient format such as WebP where suitable, and remove decorative images that add no value. WordPress’s performance optimisation handbook recommends optimising image files and considering modern formats such as WebP.
Also check that images have reserved dimensions so they do not push text or buttons around while loading; web.dev recommends setting width/height or an aspect ratio so browsers can reserve the right space. Keep the image clear enough for the page; compressing it until it looks poor is not a useful speed improvement. Re-test the page after changing the specific image instead of replacing every visual at once.
2. Review plugins, themes and external scripts
A plugin or theme can add code, database work or extra requests. Look for a measured connection between a component and the slow page before removing it. WordPress recommends checking whether a plugin is significantly affecting performance and consulting its documentation or support when needed.
For a safe comparison, use a staging copy or a verified backup. Change one component at a time, then check the pages and functions that depend on it. Review external chat widgets, video embeds, analytics tags and other scripts too, but do not remove tracking or business features until you know what they do.
3. Use caching at the right layer
Caching can reduce repeated work, but “add a cache plugin” is not a universal fix. WordPress distinguishes page caching, browser caching, persistent object caching and server caching. Page caching can help mostly static pages; browser caching can reduce repeat requests for files that rarely change. A persistent object cache requires suitable hosting support. The WordPress caching guide describes these differences and notes that caching dynamic pages can be more complex.
Check whether the host already provides page or server caching before adding another layer. Avoid stacking multiple cache plugins without a plan. After a change, clear the relevant cache and verify that forms, logged-in views, quote requests and other dynamic functions still work.
4. Investigate the server when several pages are slow
If the first response is slow across multiple pages, review the hosting environment rather than focusing only on front-end files. WordPress’s performance handbook discusses server resources, the web server, PHP, the database and caching as possible areas to examine. Ask the host to check resource use and server response for the affected pages before paying to upgrade a plan or making a server change.
If the problem began after a PHP, plugin or theme change, note the timing and error details, then test on staging. Timing is a clue to investigate, not proof of cause. Keep WordPress, themes and plugins maintained, but avoid changing several major components at the same time when diagnosing a slowdown.
5. Retest the same page and the important customer journeys
After each focused change, run the same test again and note what changed. A better lab score can help identify progress, but also check field data when it is available. Test the mobile navigation, contact and quote forms, and any booking or enquiry path that matters to the business. A page that is fast but has a broken form has not been improved for the visitor.
Google recommends good Core Web Vitals as part of a positive page experience and explains how they measure real-world loading, responsiveness and visual stability. Treat them as user-experience targets, not a promise of higher rankings: search performance depends on more than a single performance test.
WordPress speed questions
Will a caching plugin fix every slow WordPress site?
No. Caching can reduce repeated server work, but it will not automatically fix an oversized image, a slow server response, an inefficient plugin or a third-party script. Measure first and choose the change that matches the evidence.
Is the PageSpeed Insights score the same as real-user performance?
No. PageSpeed Insights can show CrUX field data from eligible Chrome users as well as a Lighthouse lab test. Field and lab data answer different questions; use both when available and keep their results separate.
How long does it take for Core Web Vitals to reflect a fix?
Lab tests can be repeated after a change. CrUX field data uses a rolling 28-day window, so changes in that dataset can take time to appear. If field data is missing, use lab results carefully and avoid describing them as a measurement of all visitors.
Need help improving a WordPress website?
Engage24’s Website Design & Development service includes WordPress development and speed optimisation. If a slow page is affecting enquiries, discuss the measured issue and a practical next step with the team.