How to speed up a WordPress site: where to start, and in what order

Search for how to speed up WordPress and you get lists: thirty tips, fifty plugins, every option switched on. Follow one and the usual story begins. The score moves, then a menu stops opening, a form stops sending, and nobody knows which of the ten settings did it.

This guide takes the other road. It gives you an order: what to measure first, how to find the real problem, and which lever to pull for it, from the safest to the most delicate. Each step points to a dedicated guide when you need to go deeper.

What “fast” means for Google

Google judges the speed of a page with three indicators, the Core Web Vitals, measured on your real visitors:

• LCP (Largest Contentful Paint): when the main content, often the top image or the title, is displayed. Good under 2.5 s.
• INP (Interaction to Next Paint): how long the page takes to react to a tap or a click. Good under 200 ms.
• CLS (Cumulative Layout Shift): how much the content jumps while it loads. Good under 0.1.

The verdict is taken at the 75th percentile of visits over 28 days: three visits out of four must be good. A single test run on your own fast computer tells you little about that.

Step 1: measure the field first, then the lab

There are two kinds of data, and they answer different questions:

• Field data (Search Console, and the top section of PageSpeed Insights) come from your real visitors. They tell you whether there is a problem, and where.
• Lab data (the score of PageSpeed Insights, Lighthouse) come from one simulated load. They help you understand why, and check a change right away.

Start with the Core Web Vitals report in Search Console. It groups your URLs by similar pages, which usually means by template: home page, articles, product pages, categories, landing pages. That is the unit you will work on, because a fix in a template fixes every page built on it.

Before changing anything, write down the starting point for each template: the three metrics in the field, and a lab run on mobile. When the two disagree, and they often do, our guide on lab and field data explains how to read them.

Step 2: find which metric fails, on which template

Every metric points to a different family of causes. That is what saves you from switching everything on:

• Poor LCP: the server answers late, or the main image arrives late (too heavy, discovered late, lazy loaded by mistake, blocked behind stylesheets).
• Poor CLS: images without reserved space, a web font that swaps, a banner or a block injected after the first display.
• Poor INP: too much JavaScript running on the main thread, from the theme, the builder or third parties.

Also look at the server response time (TTFB, shown in PageSpeed Insights). If the HTML itself takes more than about 0.8 s to arrive, no front-end optimization will make up for it: the next step comes first.

Step 3: the server and the page cache

WordPress builds each page in PHP, with database queries, on every visit. A page cache keeps the finished HTML and serves it directly to the next visitors: it is the lever with the biggest effect on response time, and on a content site it is safe for anonymous visitors.

• One cache engine, not two. Many hosts already cache pages at the server. Stacking a plugin cache on top of it makes two layers that purge at different moments, and you end up serving stale pages. Choose one to own the page cache.
• Check the basics of the host: a supported PHP version, and an object cache (Redis or Memcached) if the site is dynamic.
• Sites with accounts or a cart need a line between what can be cached and what must never be. On WooCommerce, that line is the whole subject of our guide to speeding up a WooCommerce store.

Step 4: images and the main image

Images are usually the heaviest part of a page, and the main one is often the LCP. The first moves are all safe, because they send the same picture in fewer bytes: compression, a modern format (WebP or AVIF), and the right size for the screen. If PageSpeed keeps asking you to properly size images despite a srcset, the cause is almost always the sizes attribute: see our srcset and sizes guide.

Then take care of the main image itself:

• never lazy load it: lazy loading is for images below the fold;
• help the browser find it early with a preload and a high fetch priority, and if it differs between phone and desktop, preload one per device;
• if it is a CSS background set by a builder, the browser discovers it late: our guide on background heroes shows the fixes;
• and keep large illustrations out of inline SVG, which weighs on the HTML itself: inline SVG is for icons.

Step 5: CSS

The browser does not display anything until it has downloaded and read the stylesheets in the <head>. On a builder theme, that can be several hundred kilobytes, most of it unused on the current page. Two techniques address it:

• Critical CSS: the styles of what is visible at load are inlined in the page, and the full stylesheet loads without blocking.
• Used CSS (often called “Remove unused CSS”): the rules the page does not use are removed.

Both are very effective, and both can break something, because they judge from one snapshot of the page. A menu, a modal or a mini cart that is closed at that moment looks useless, and loses its styles. How to find the missing rule and put it back: our guide on missing styles, with two frequent cases in the menu that shows up open and the mini cart that disappears.

Step 6: JavaScript and responsiveness

JavaScript weighs on everything: it competes with the main image for the network, and it keeps the main thread busy when the visitor taps. The strongest lever is to delay the scripts that are not needed at load until the first interaction. It is also the lever that breaks the most sites:

• a menu that opens on the second tap only: our burger menu guide;
• a slider, a form or a consent banner that stops working: how to find the script at fault;
• a consent banner that arrives late and holds the rest: our guide on consent banners.

Never delay what the visitor needs right away: the consent tool, the menu, the add to cart and payment scripts. And know the limit of the exercise: some themes ship all their code in one large file, which caps what any optimization can do. How to spot them.

Step 7: layout stability

Content that jumps is rarely one big cause, it is several small ones: images without width and height, a web font that changes the size of the text when it arrives, a cookie banner or a promo bar that pushes the page down, a slider that starts in one state and ends in another. Reserve the space, and choose the font-display of your fonts on purpose: swap shows the text at once but can move it when the font arrives, optional never moves it but sometimes keeps the fallback font. Page builders add their own causes, covered in our CLS guide for Divi and Elementor.

Your builder, your store

The order above holds for every WordPress site. Some stacks have their own traps, with a dedicated guide:

• Divi: a lot of CSS and background images out of the box, and options that overlap with any optimization plugin. Speed up a Divi site, step by step.
• Elementor and Divi: layout shifts specific to builders. Fix CLS on builder themes.
• WooCommerce: cache, cart fragments, product images and payment scripts. Speed up a WooCommerce store.

The method that keeps the site working

The levers are not all equal. Some only reduce the weight of files or give the browser a hint, and cannot break anything. Others change what runs, in what order, or what is served, and need a test. Our guide on safe optimizations sorts them one by one.

With Mantys Core

In summary

• Read the field data first, template by template: they tell you whether there is a problem and where.
• Match the failing metric to its family of causes: LCP to server and images, CLS to reserved space, INP to JavaScript.
• Fix in order: server and page cache, images, CSS, JavaScript, stability.
• Switch on the safe levers first, then the delicate ones one at a time, testing on mobile and desktop, logged out.
• Confirm in the lab right away, and in the field four weeks later.