Performance is decided before you write any code
There is a common sequence in WordPress projects: build the site, notice it feels slow, install a caching plugin, notice it still feels slow, then start looking for something to blame. By that point the expensive decisions have already been made.
The things that actually determine how a WordPress site performs are chosen early: which theme you start from, how many plugins you commit to, how your images enter the media library, and whether your pages are assembled from reusable structures or built by hand each time.
Choose a theme for what it does not do
Multipurpose themes are attractive because they appear to include everything. That is exactly the problem: they load everything, on every page, whether the page uses it or not.
A lighter theme that does 70% of what you need and leaves you to build the rest will almost always outperform a heavy theme that claims to do 100%. You are choosing a baseline you cannot easily undo later.
- Prefer a lean theme you extend over a heavy theme you disable parts of
- Check what a theme enqueues on a blank page before committing
- Block themes with the native editor avoid a whole layer of page-builder overhead
Treat every plugin as a permanent cost
Each plugin is code that runs on requests, assets that may load site-wide, database queries, and an update you will have to keep applying for as long as the site exists. Some are unquestionably worth it. Many are solving a problem that ten lines of code would solve.
A useful discipline: before installing, ask what would break if you did not. If the answer is 'nothing critical', do not install it.
- Audit plugins quarterly and remove anything unused
- Watch for plugins that load assets on every page for a feature used on one
- Prefer one plugin doing a job well over three overlapping ones
Images are almost always the biggest win
On most sites images account for the majority of page weight. A single uncompressed photograph straight from a phone camera can outweigh every script and stylesheet on the page combined.
The fix is unglamorous and highly effective: resize images to the dimensions they are actually displayed at, compress them, serve modern formats like WebP or AVIF with fallbacks, and lazy-load anything below the fold.
- Resize before upload, rather than relying on CSS to shrink a 4000px image
- Serve WebP or AVIF with a fallback for older browsers
- Always set width and height so the browser can reserve space
- Lazy-load offscreen images, but never the main hero image
Caching helps, after the fundamentals
Caching is genuinely valuable. It is also frequently asked to compensate for problems it cannot fix. A cached page still has to send every byte of an oversized image, and still has to run whatever JavaScript you loaded.
Put page caching and a sensible browser-caching policy in place, but do it after you have addressed theme weight, plugin load and image handling, not instead of it.
Build structures, not pages
Reusable block patterns and consistent templates are usually discussed as a maintenance benefit, and they are. They also help performance indirectly: a site assembled from a small set of well-tested structures loads a predictable set of assets, while a site where every page was built by hand tends to accumulate one-off scripts and inconsistent markup.
It also means the person maintaining the site after you can make changes without introducing new problems.
Measure, then change one thing
Run a baseline measurement before optimising, using a tool that reports Core Web Vitals. Then change one thing at a time and measure again. Batched changes tell you the total effect but not which change caused it, and some 'optimisations' make things worse.
Test on a throttled mobile connection rather than your own broadband. That is closer to what most visitors actually experience.
Written by Ntege Israel Charles, a Web Developer and WordPress Developer based in Kampala, Uganda. If any of this applies to a site you are responsible for, get in touch.