How to speed up a slow WordPress site (without a single plugin)
WordPress out of the box is slow for boring, fixable reasons. Here is the order to fix them in — highest impact first — by moving work to the edge rather than stacking more plugins on top.
The usual advice for a slow WordPress site is a list of twenty things, presented as though they all matter equally. They do not. Two of them account for most of the improvement on most sites, and the rest is rounding error you can get to later.
So this is a ranked list. Do them in order, measure after each, and stop when the site is fast enough — which will probably be sooner than you expect.
Step 0: find out what is actually slow
Skipping this is how people spend a weekend minifying CSS on a site whose real problem is a 4 MB header image.
Open your site in an incognito window with DevTools on the Network tab. Look at three numbers: how long until the first byte of HTML arrives, what the largest file on the page is, and how many requests the page makes. That is enough to tell you which of the sections below applies to you.
- First byte over 600ms → your problem is server-side. Section 1.
- First byte fine, page still slow → your problem is assets. Section 2.
- Fast for you, slow for customers elsewhere → your problem is distance. Section 3.
1. Stop rebuilding pages that have not changed
This is the big one. For every visit, WordPress wakes up PHP, loads your theme and every active plugin, runs a pile of database queries, assembles the HTML, and only then sends it. It does this identically for the thousandth visitor to a post published in March.
Full-page caching stores the finished HTML and serves that copy directly. PHP and the database get the day off. Done at the edge rather than on the server, it also means the cached copy sits near your visitors rather than in one data centre.
The objection is always "but my site has dynamic parts". It does, and that is handled by bypassing the cache precisely where it is needed rather than abandoning caching entirely.
Cache these — identical for everyone
- Posts and pages
- Homepage and archives
- Category and tag listings
- Static assets, obviously
Bypass these — personal
- wp-admin and logged-in sessions
- Cart and checkout
- Anything behind a login
- The WordPress preview and customiser
The mechanism is cookies. WordPress sets recognisable cookies when someone logs in or puts something in a cart, and the cache bypasses on their presence. A logged-out visitor has none of them and gets the cached copy; you, logged in as an editor, get a live page and never notice caching exists.
More caching plugins is not the answer when caching plugins are the problem. Running two or three simultaneously produces conflicts, stale pages and an afternoon of confusion rather than speed. Moving the cache off the server entirely sidesteps the whole category.
2. Fix the images, because they are the page weight
On a typical WordPress site, images are 60 to 80 percent of the bytes on the page. The media library is full of photos uploaded straight from a phone at full resolution, displayed in a 600-pixel column.
Two changes, in this order: resize to the dimensions actually displayed, then convert to WebP or AVIF. Done at the edge, both happen automatically on the way out and are cached afterwards — no re-uploading, no regenerating thumbnails, no plugin rewriting your media library and breaking something.
While you are there: make sure the image in your header is not lazy-loaded. WordPress adds loading="lazy" generously, and applying it to the largest above-the-fold image actively harms your Largest Contentful Paint. That single attribute has cost more sites their LCP score than almost anything else.
3. Serve it from near your visitors
If your host is in Frankfurt and a quarter of your customers are in the US, they are paying 100 to 150 milliseconds of latency on every round trip before your server has done anything at all. Cached pages served from a nearby edge remove that entirely, and it is the fix that your own testing will never reveal — the site is fast from your desk, because your desk is near the server.
4. Only now, the small stuff
Once the first three are done, these are worth an hour:
Audit your plugins honestly
Deactivate everything and reactivate one at a time, checking load time as you go. Most sites are carrying two or three plugins nobody has used since 2022, each loading scripts on every page.
Compress and minify text assets
Brotli for CSS, JS and HTML. Real, if modest, and it costs nothing to turn on.
Cut what loads on every page
A slider library loaded site-wide for one slider on the homepage is very common and easy to fix.
Clean the database
Post revisions, expired transients and orphaned metadata accumulate for years. Only worth doing after the above; it rarely moves the needle on its own.
Frequently asked questions
Why is my WordPress site so slow?
Most commonly because WordPress rebuilds every page from PHP and the database on every visit, even for pages that have not changed in months, and because the images are far larger than the space they are displayed in. Between them these two account for the majority of the problem on typical sites. Plugin bloat and unoptimised assets matter, but usually less than people assume.
Can I speed up WordPress without plugins?
Yes, and it is often better. Full-page caching, image resizing and format conversion, and compression can all be handled at the CDN edge instead of by plugins running inside WordPress. That removes the PHP work entirely rather than optimising it, and avoids the conflicts that appear when several caching plugins run at once.
Will caching break my WooCommerce cart or logged-in pages?
Not if the cache bypass is configured correctly. WordPress and WooCommerce set identifiable cookies when a visitor logs in or adds something to a cart, and the cache is bypassed whenever those cookies are present. Logged-out visitors browsing the catalogue get cached pages; anyone with a session gets a live page generated normally.
How much faster does full-page caching make WordPress?
The saving is the entire server-side render, which on a typical shared-hosting WordPress install is several hundred milliseconds to a few seconds per page. A cached page served from a nearby edge commonly arrives in under 50 milliseconds versus 800 milliseconds or more uncached. The gap widens under load, because cached responses do not consume origin capacity.
Does lazy loading images help or hurt performance?
Both, depending on the image. Lazy loading images below the fold saves bandwidth and speeds up initial load. Lazy loading the largest above-the-fold image — often the header or hero — delays it and directly worsens Largest Contentful Paint. WordPress applies loading="lazy" broadly, so it is worth checking that your hero image is excluded.
Work down that list and stop when you are happy. Most sites get the majority of the available improvement from steps 1 and 2, which between them take an afternoon and require installing nothing.
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
