How to speed up a WordPress website, in plain order of impact: fix your images, add page caching, cut unused plugins, reduce what the page builder loads, serve modern image formats, control fonts, defer non-critical scripts, reserve space for anything that shifts, and only then consider moving hosts. Most small business sites get the bulk of their gain from the first three.
Work top to bottom and measure after each step. Changing six things at once tells you nothing about which one helped.
Measure First, With the Right Tool
Before you change anything, get a baseline you can compare against. Run your homepage and your most important service page through PageSpeed Insights, and record the mobile numbers, not desktop.
The three measurements Google uses for Core Web Vitals are the ones worth watching:
- Largest Contentful Paint — how long until the main content appears. Target 2.5 seconds or less.
- Interaction to Next Paint — how quickly the page responds when someone taps. Target 200 milliseconds or less.
- Cumulative Layout Shift — how much the page jumps around while loading. Target 0.1 or less.
Write your current numbers down. You will want them in step nine when you are deciding whether hosting is really the problem.
Step 1: Fix Your Images
On most WordPress sites, images are the single largest cause of slow pages, and the fix needs no technical skill.
Three things go wrong. Images are uploaded at camera resolution and displayed at a fraction of that size. They are saved at unnecessarily high quality. And they are served in old formats.
Resize before upload. A full-width hero rarely needs to be wider than 2000 pixels; an in-content photo rarely needs more than 1200. Then compress — most photographs survive meaningful compression with no visible difference on screen.
Check your largest offenders by loading a page with your browser’s developer tools open on the network tab, sorting by size. Anything over a few hundred kilobytes deserves attention.
Step 2: Turn On Page Caching
Without caching, WordPress rebuilds each page from the database on every single visit. With caching, it builds the page once and serves a stored copy.
Many hosts provide caching at the server level, which is generally better than a plugin doing the same job. Check what your host offers before installing anything, and never run two caching plugins at once — they conflict, and the symptoms are confusing.
If you edit a page and the change does not appear, clear the cache. That is almost always the explanation.
Step 3: Audit Your Plugins
Open your plugins list and sort it honestly into three groups: essential, replaceable, and forgotten.
Plugins slow a site in two ways. They add their own scripts and styles, often on every page whether needed or not. And they add database queries. A site with forty plugins is usually carrying several doing overlapping jobs — two contact form plugins, three SEO tools, a slider nobody uses anymore.
Deactivate one at a time, check the site still works, then remove what you no longer need. Do this on a staging copy if you have one.
Step 4: Control What the Page Builder Loads
Divi, Elementor and similar builders are productive to work in, and by default they tend to load their full library of modules and styles on every page.
Most builders have performance settings worth switching on: dynamic CSS so only the styles a page needs are sent, deferred loading of icon fonts, and disabling features you do not use. Find the performance panel in your builder’s settings and go through it once properly.
Also look at how your pages are built. Deeply nested rows and columns generate more markup than a simpler structure doing the same visual job.
Step 5: Serve Modern Image Formats
WebP files are typically significantly smaller than equivalent JPEGs or PNGs at comparable visual quality, and every current browser supports them.
Many hosts and optimisation plugins will convert and serve WebP automatically with a fallback for anything that cannot read it. If yours does, switch it on. If not, convert your largest images manually and replace them.
Pair this with lazy loading so images below the fold download only when someone scrolls toward them. WordPress does this natively for most images, but check that your theme or builder has not disabled it.
Step 6: Reduce and Localise Fonts
Custom fonts are a quiet cost. Each weight is a separate file, and fonts loaded from an external service add a connection to another server before text can render.
Pick two font families at most, and only the weights you actually use. Regular and bold usually covers it. Host the font files on your own domain rather than calling them from elsewhere, and set them to display fallback text immediately while the custom font loads — otherwise visitors stare at blank space where your headline should be.
Step 7: Defer Non-Critical Scripts
Anything that is not needed to render the visible page should not block it. Chat widgets, analytics, tracking pixels, embedded video players, map embeds and social feeds all fall into this category.
Load them after the main content, or on interaction. A map that loads only when someone clicks “show map” costs nothing on the pages where nobody clicks.
Third-party embeds are often the worst performers on an otherwise fast page, because you have no control over how fast the other server responds.
Step 8: Stop the Page Jumping Around
Layout shift is the measurement small business sites most often fail, and the cause is nearly always the same: elements that appear after the page has started rendering without space reserved for them.
The usual offenders:
- Images and videos without width and height attributes, so the browser cannot reserve space.
- Advertisements or embeds injected into the middle of content.
- Fonts that swap in at a different size to the fallback, pushing text around.
- Notification bars or banners added at the top after load.
- Content loaded by script above existing content.
Each of these is fixable by declaring dimensions or reserving space in advance.
Step 9: Reconsider Hosting — Last, Not First
Hosting matters, but it is the last step for a reason. Moving a badly optimised site to a faster server gives you a faster badly optimised site, and you will have spent the budget without learning anything.
Once steps one to eight are done, re-measure. If your pages are still slow with small images, caching on, few plugins and deferred scripts, then the server is genuinely the constraint and a move is justified. Look at where the server is located relative to your customers, how the host handles traffic spikes, whether caching happens at server level, and what their response time looks like under load rather than at rest.
Priority Table
| Step | Effort | Typical gain | Risk |
|---|---|---|---|
| Fix images | Low | High | Very low |
| Page caching | Low | High | Low — clear cache after edits |
| Plugin audit | Medium | Medium–high | Test on staging |
| Builder settings | Low | Medium | Low |
| WebP | Low | Medium | Low |
| Fonts | Low | Low–medium | Low |
| Defer scripts | Medium | Medium | Test functionality after |
| Layout shift | Medium | Improves usability directly | Low |
| Hosting move | High | Varies | Plan the migration |
Keep It Fast
Speed is not a one-off project. A site gets slower the way a garage gets full — one plugin, one unresized hero image, one embedded video at a time. Re-measure quarterly and after any significant change, and keep your baseline numbers so you can tell drift from noise.
Knowing how to speed up a WordPress website matters less than having someone actually doing it on a schedule. If you would rather performance monitoring, image optimisation and plugin updates ran in the background every month, look at the Website Care Plan page.