Diagnosing a slow WordPress website

Measure where WordPress is slow before changing the stack

Start with the URLs and devices that matter. Use Search Console or CrUX field data when available, then test comparable page types under similar conditions. Lab tools help diagnose causes, but one score does not describe every visitor’s experience.

Separate server response from rendering

If HTML arrives late, inspect hosting, cache, database and server-side plugins. If HTML is fast but the page appears late, inspect images, fonts, CSS and JavaScript that block rendering. Locating the bottleneck prevents an unnecessary rebuild.

Images and scripts are often practical first fixes

Serve images at their displayed size, choose appropriate formats, set dimensions and lazy-load only below-fold media. Review plugins and third-party scripts with the site owner before disabling anything that affects sales or measurement.

Cache by page type

Public content can usually be cached more aggressively than cart, checkout or private account pages. Verify cache headers and invalidation after content changes rather than applying one rule to the entire site.

Choose WordPress, Astro or Next.js for the work

WordPress may remain the right fit when editors need familiar content controls and the current system works. Astro is suited to content-heavy pages with minimal client JavaScript. Next.js can fit applications needing more server behaviour or interaction. A framework name does not guarantee speed; implementation and delivery matter.

If migration is justified, plan SEO and operations together

Inventory URLs with traffic and links, redirect to equivalent destinations, and verify canonicals, sitemaps, metadata, content and contact flows. Include hosting, maintenance, security and editorial ownership in the decision rather than relying on one Lighthouse score.

Diagnose slowness before replacing the platform

Test the templates and devices that matter, distinguishing cache from cold loads. Inspect the waterfall for server, image, font and script delays. Disable plugins in a test copy and verify contact/sales journeys. One Lighthouse run supports diagnosis; field Core Web Vitals requires real-user evidence over a suitable period.

Prepare for the estimate

Provide the current URLs, approved example data, owners and the most important workflow. Distinguish the first release from later additions so teams can estimate the same scope and agree acceptance before work.

Read the related decision guide →