Your site loads slower than you want, or slower than the theme's demo. This page explains where WordPress speed comes from, which layers you can fix yourself, and which ones belong to whoever runs your server.
#Speed comes from several layers
A fast WordPress site is several layers doing their job at once:
| Layer | What it decides |
|---|---|
| Hosting | How quickly the server answers at all, and how many visitors it handles at once |
| Page caching and asset optimization | Whether a visitor gets a ready page or waits for WordPress to build one |
| Images | Usually the heaviest part of every page |
| CDN | How far the files travel to reach the visitor |
| Content | How much each page asks for: images, embeds, scripts, third party widgets |
| Theme | The design, its CSS and JavaScript, and how lean its code is |
The theme is one row in that table, and one of the smaller ones. We built our themes with lean code and restrained assets. That foundation matters, but it cannot make up for a slow server or a page carrying ten megabytes of photographs.
#If your site is slower than our demo
The theme is rarely the reason. It is the same theme on both sites. What differs is everything around it: our demos run with page caching, optimized images and a CDN in front, and their content was prepared with speed in mind.
A cheap shared hosting plan can perform well, mostly for visitors near its data center. A visitor on another continent waits for every request to cross the distance, and a server shared with hundreds of other sites answers slowly when its neighbors are busy.
A support ticket or a low rating will not change the server a site runs on.
We will look at a real bug in the theme. Hosting, server configuration and caching setup are outside what support covers, see the Support Policy. If a site is slow on a slow server, the fix is on the server.
#Measure first
Test a real page with your content, your images and your plugins active, not the homepage of an empty install. PageSpeed Insights and WebPageTest both do this for free.
Write the numbers down before you change anything. Without a starting point you cannot tell whether a change helped. Look at the time to first byte in particular: if the server takes a second to start answering, the problem is the server, and nothing on the page can fix that.
#Two kinds of caching, and why they are not the same
"Caching" gets used for several different things. They sit at different levels, and they are set up by different people.
#Page caching and asset optimization: the last stage
A page caching plugin saves the finished HTML of a page and serves that copy to the next visitor, so WordPress does not rebuild the page on every visit. The same plugin usually handles asset optimization: combining and minifying CSS and JavaScript, delaying scripts until they are needed, lazy loading images, and preloading the cache so the first visitor does not pay for it. This is the stage you configure in the WordPress admin, and it gives the largest single improvement on most sites.
Our recommendation: WP Rocket.
WP Rocket is the caching plugin we use on our own demos and the one we recommend. It is a paid plugin, and in our years of building and running WordPress sites it has consistently earned its price: sensible defaults, page caching and asset optimization in one place, and settings a site owner can understand. Other caching plugins do the job too; in our experience they do it less well. That is our opinion, formed on our own sites.
#Server-side layers: leave these to someone who knows them
Below WordPress sit layers that live on the server itself:
- OPcache
A PHP feature that keeps compiled PHP code in memory, so the server does not re-read and re-compile every file on every request. Most hosts enable it.
- Object cache
A store such as Redis or Memcached that keeps the results of database queries in memory between requests. It helps most on sites with many logged-in users, shops and large archives.
- Database
The MySQL or MariaDB server, its memory settings and the size of its tables.
These layers make a real difference, and they break things easily when set up wrongly: a stale object cache shows old content or logs people out, and a misconfigured database server fails under load. Configure them only if you know them, or ask your host or a server administrator to do it. Do not switch them on from a tutorial and hope.
Never run two tools that do the same job.
Two page caches, or two plugins that both minify or lazy load, conflict with each other. The symptom is usually intermittent: a broken layout or a missing script that nobody can reproduce on demand.
#Images
Images are usually the heaviest thing on a page, and usually the easiest thing to fix.
- Upload images no larger than the largest size they are shown at
- Compress them before or on upload
- Use a modern format such as WebP or AVIF
- Let WordPress serve a smaller size to smaller screens, which it does automatically for images added through the media library
- Lazy load what sits below the first screen
The most common waste on a WordPress site is a full resolution photograph straight from a camera, displayed in a small card.
#A CDN
A content delivery network keeps copies of your files on servers around the world and serves each visitor from the nearest one. Cloudflare is a common choice and has a free plan. A CDN helps most when your visitors are spread across countries, and it also takes load off the server. It does not fix a slow server: pages the CDN does not cache still come from your host.
#Hosting
The server sets the ceiling for everything above it. Current PHP, adequate memory, fast storage and a data center near most of your visitors matter more than any plugin setting. Our themes list their minimum values in the server requirements, and a plan that only just meets them will not be fast.
#Plugins and third party scripts
Every plugin and every embedded script has a cost: chat widgets, analytics, ad scripts, social feeds, video embeds. Deactivate what you do not use. For what you keep, measure the effect of one at a time instead of enabling everything at once. One script that adds a hundred milliseconds is acceptable; six of them are not.
#Measure again
Test the same page with the same tool, and compare with the numbers you wrote down. If time to first byte is still high after caching, the server is the bottleneck, and the conversation to have is with your host.
#Common questions
Will a caching plugin break my site?
It can, when it caches something that should stay dynamic or optimizes a script that does not tolerate it. Clear the cache after changing settings, check the site in a private window, and turn optimization options on one at a time so you know which one caused a problem.
Do I need a CDN?
If most of your visitors are in one country and your server is in that country, the gain is small. For visitors spread across continents it is significant.
My score is high but the site feels slow
Lab scores measure a page under test conditions. Open the site on a real phone on a mobile connection and trust what you see over the number.
Should I turn on Redis?
Only if your host supports it and someone who knows it sets it up. An object cache set up wrongly causes problems that look like bugs in the site, such as old content showing or settings that seem not to save.
Nothing I try changes the number
Check time to first byte. When the server is slow to start answering, the fix is better hosting or server tuning, and nothing in WordPress will change it. If you think the theme itself has a performance bug, report it with the details: the page, the measurements, and the same page measured with caching on.
#Still stuck
Open a support ticket and say what you tried and where it stopped. Your product, your domain, a screenshot and the exact message you saw are usually enough to settle it in one reply.
Last updated
