Speeding up WordPress: measure first, then make changes

Measure the same page under the same conditions

Installing a random caching plugin on a slow WordPress website does not always solve the problem. First establish whether the issue lies in server response, page size or JavaScript work in the browser. Measure different templates, such as an article, product detail and shopping cart if present, as well as the homepage.

PageSpeed Insights provides lab measurements and, where enough data is available, real-user data. Do not treat a single test result as conclusive: repeat tests at different times under similar device and network conditions. Record screenshots and measurements before making changes.

Match the right metric to the right problem

TTFB is the time until the first response byte arrives; it can include the combined effects of the network, server, application and cache. LCP measures when the main content appears; INP assesses responsiveness to interactions; CLS measures unexpected layout shifts. These metrics are not interchangeable.

The common thresholds for a good Core Web Vitals experience are an LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less. Assessment uses the 75th percentile of real users; these thresholds alone do not guarantee search rankings.

How do you measure in the browser?

1. Enter the exact HTTPS URL to test in PageSpeed Insights. Keep mobile and desktop results separate. If real-user data is unavailable, record it as 'no data'; do not interpret that as poor performance.
2. Run the same test type several times for the same URL. Record the date, URL, device or test type, LCP/CLS values and the main diagnostic finding. Do not draw conclusions by selecting a single good or bad run.
3. Open the page in a browser as a logged-out visitor. In Developer Tools → Network, enable Disable cache and reload the page; this option affects the browser cache while the tools are open, but does not clear server or CDN caches.
4. If you suspect images, use the Img filter and compare files in the Size column. Find images much larger than their displayed dimensions. If the Doc request shows a long delay in its Timing details, image compression alone may not improve the initial server response.
5. After a change, measure again using the same URL, login state and test type. Record both the result and whether the menu, forms and any cart still work.

Details on using the panel are explained in Chrome's official Network guide. If you change server or CDN caching, also record which layer you cleared and when.

Start with the largest images

Displaying a high-resolution image in a small area downloads unnecessary data. Prepare images for their displayed size, consider suitable formats such as WebP or AVIF, and check quality visually. Specifying width and height helps reduce layout shifts.

Images below the fold can be lazy-loaded. Delaying the main image in the initial viewport, however, can worsen LCP. Verify that an optimisation plugin does not apply the same rule to every image. Also check whether mobile devices download unnecessarily large desktop files.

Example diagnosis: a large hero image or a slow response?

This section is an educational example, not a measurement or success result from an Ajans Hosting customer. Imagine a brochure page loading slowly. First compare the late-appearing element in the LCP details with the Network log.

Changing one variable makes it easier to see which action affected the result. If you change a caching plugin in the test environment, also recheck session, cart, checkout and form workflows.

Configure caching around application behaviour

Page caching reduces the need to regenerate the same content for anonymous visitors. Cart, checkout, account and logged-in user pages should not be cached in the same way. Form security tokens and personalised content may also require exclusions.

If server caching, a WordPress plugin and a CDN run together, define the clearing order and who is responsible. Test that visitors see current data after a product price or content update. Evaluate additional layers such as object caching with appropriate application and server support.

Reduce plugin and code overhead

Remove unused plugins and themes, and keep the rest updated. Running several performance plugins that do the same job can cause conflicts. External fonts, chat widgets, embedded maps and advertising scripts also add load to the site.

Back up before disabling a component and try it in a test environment where possible. Make changes one at a time, then recheck contact forms, search, registration and payment workflows. Higher-resource hosting alone does not fix inefficient queries or excessive JavaScript.

Make improvement a regular routine

Keep measurements, changes and verification records in one place. Repeat baseline measurements whenever you publish a new theme, plugin or campaign page. If resource usage approaches limits at peak times, assess application improvements and capacity planning together.

See WordPress performance documentation for more detailed application guidance. If you are choosing hosting, compare resources and service coverage on the WordPress hosting page.

Track each change with a single measurement record

URL and date:
Mobile / desktop test type:
Logged in? Browser / server cache status:
Previous LCP / CLS and measurement source:
Single change made:
Subsequent measurements and number of runs:
Menu / form / cart check result:

INP from real-user interactions and lab diagnostic measures such as TBT are different metrics. TBT can help identify long main-thread tasks; it should not replace unmeasured INP in a report. If you run a store, also review the distinction between caching and intensive transactions in WooCommerce hosting selection.