Measure first, then fix
Guessing wastes time. Run your key pages through PageSpeed Insights and look at two sets of results: lab data from Lighthouse, which shows what is slow, and field data from real visitors, which shows how it feels. Check Core Web Vitals in Search Console, where good scores are a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less.
Note the biggest problem on each page. Is the server slow to respond? Is the main image huge? Is a script blocking the page? The answer tells you where to start, and it stops you installing a speed plugin that fixes nothing that matters.
1. Check your hosting and server response time
Everything starts with the server. If the time to first byte is long, the page cannot be fast however well it is built. Cheap shared hosting with crowded servers, old PHP versions and no object cache is a frequent cause. Move to hosting designed for WordPress, run a current supported PHP version and use a server-level cache.
Also check the location of the server compared with your visitors. A content delivery network reduces distance by serving cached pages and files from nearby locations.
2. Use full-page caching
By default WordPress builds each page on request, running PHP and database queries every time. A caching layer stores the finished HTML and serves it directly, which can cut response times dramatically. Use one good caching solution, either from your host or from a reputable plugin, and avoid stacking several that conflict.
Pages for logged-in users, carts and checkouts need special rules, so test those areas after enabling the cache.
3. Optimise images properly
Large images are the most common reason for a slow Largest Contentful Paint. Resize images to the size they are shown, compress them, serve modern formats such as WebP or AVIF, and give each image explicit width and height so the layout does not jump. Lazy-load images below the first screen, but never lazy-load the main image at the top, which should load first.
4. Remove plugins you do not need
Every plugin adds code and often database queries, scripts and styles on every page. Audit the list. Delete anything unused, replace several single-purpose plugins with one well-built one where sensible, and check which plugins load scripts on pages that do not need them. Fewer plugins also means fewer security updates to manage.
5. Fix the theme and page builder
Heavy multipurpose themes and visual page builders often ship hundreds of kilobytes of CSS and JavaScript and produce deep, bloated HTML. A lightweight theme with a block-based approach is usually much faster. If your design depends on a builder, use its performance settings, remove unused widgets and avoid stacking many animated sections on the first screen.
6. Control JavaScript, fonts and third-party scripts
Chat widgets, analytics, tag managers, maps, social feeds and ad scripts all cost time, and they are a leading cause of poor responsiveness. Load only what you use, delay non-essential scripts until after the page is interactive or after the first user action, and self-host fonts with only the weights you need.
- Defer or delay scripts that are not needed for the first view
- Preload the main font and the main image, not everything
- Replace embedded videos and maps with a static preview that loads on click
- Use a lightweight analytics setup and review tags in your tag manager
7. Clean and tune the database
Over the years a WordPress database collects post revisions, spam comments, expired transients and leftovers from deleted plugins. Limit stored revisions, clear expired data, and use an object cache such as Redis or Memcached if your host offers one, particularly for busy or WooCommerce sites. Take a backup before any clean-up.
When a rebuild is the better answer
If you have done the basics and the site is still slow, the cause is often the structure itself: a theme and plugin stack that cannot be made light. A rebuild on a framework such as Next.js or Astro, with content kept in a headless CMS or in files, removes most of that weight. Pages are built ahead of time, served from a CDN and ship far less code.
A rebuild takes planning, because URLs, redirects, metadata and structured data must be preserved. Done carefully it improves both speed and security, and it gives developers a cleaner base for future work. It is not always necessary, and a tuned WordPress site on good hosting can pass Core Web Vitals comfortably.
A 30-day speed plan
In the first week, measure and fix the server: record baseline scores for your main templates, check the PHP version and hosting plan, and turn on full-page caching. In the second week, tackle images and fonts: compress and resize images, convert them to modern formats, set dimensions and trim web fonts to the weights you use.
In the third week, deal with plugins and scripts: remove what you do not need, delay non-essential scripts and replace heavy embeds with lightweight previews. In the fourth week, clean the database, review the theme and page builder and re-measure. If scores are still poor, you now have evidence about whether the remaining problem is the platform.
Design for mobile first
Most visitors arrive on phones with slower processors and variable connections, so test on a mid-range mobile profile rather than a fast laptop. Keep the first screen simple: one clear heading, one main image and one call to action. Avoid autoplay video, sliders and large animated effects at the top of the page, since they delay the main content and make the layout jump.
Keep it fast after the fix
Speed decays as sites grow. New plugins, larger images and extra tracking scripts creep in. Add a performance check to your routine: test the main templates monthly, watch Core Web Vitals in Search Console and set a rule that new scripts and plugins need a reason and a test before they go live. Fast sites stay fast because someone owns their performance.
Related services