It was a Friday evening when the message came in: “Our sale starts tomorrow and the site is crawling.” A small WooCommerce store selling handmade leather goods. On my phone the homepage took a little over six seconds before anything useful appeared. The product pages were worse. And the sale emails were scheduled to go out at 9 am.
This is how I fixed the WordPress website speed that night, in the order I did it. Not a list of fifty tips. Just what I checked first, what actually helped, and what made almost no difference.
Step 1: measure before touching anything
The worst thing you can do with a slow WordPress site is install three speed plugins and hope. I ran the homepage and one product page through PageSpeed Insights and opened the network tab in Chrome DevTools. I wanted three numbers: server response time, page weight and what loaded first.
- Server response: almost 1.5 seconds before the first byte.
- Homepage weight: over 9 MB.
- Requests: more than 140, many from plugins that were not even used on that page.
Now I knew where the time went, instead of guessing.
Step 2: the images (the biggest single win)
The hero slider had five photos straight from a camera, each around 1.5 MB, all loading at once. Product thumbnails were full-size images shrunk with CSS. I converted everything to WebP at sensible sizes, let WordPress serve the right size for each screen and lazy-loaded everything below the first screen. The homepage dropped from 9 MB to under 1.5 MB. That alone cut more than two seconds.
Step 3: caching and the server
There was no page caching at all, so every visitor made WordPress build the page from scratch. I enabled full-page caching at the server level and object caching for WooCommerce. Server response went from 1.5 seconds to around 200 milliseconds for cached pages. Cart and checkout stay uncached, which is important on a store.
Most slow sites are not slow because of WordPress. They are slow because of what was added to it.
Rayhan Chowdhury
Step 4: plugins nobody remembered installing
The store had 38 active plugins. Some were duplicates: two SEO plugins, two slider plugins, a social sharing plugin nobody used. Several loaded their CSS and JavaScript on every page. I removed nine, and limited others to the pages where they were needed. Fewer requests, less code to run, and the admin got faster too.
Step 5: fonts and the first screen
The theme loaded six font weights from Google. We kept three, hosted them locally and preloaded the two used above the fold. I also removed a fade-in animation on the hero, which was delaying the main image by almost a second. This is the part of page speed optimization people often skip, but it decides how fast the page feels.
Where it ended up
By midnight the homepage loaded in under two seconds on mobile and the main Core Web Vitals were in the green. Google explains these metrics well on web.dev, and the one that mattered most here was Largest Contentful Paint, the moment the main content becomes visible. The sale went out the next morning and the site held up.
What made almost no difference
- Minifying HTML. A few kilobytes. Fine to do, but it was never the problem.
- A fourth speed plugin. Stacking optimisation plugins often causes conflicts and broken layouts.
- Chasing a score of 100. Real users care about how fast the page appears and responds, not the number.
Your own quick checklist
- Measure first: server response, page weight, number of requests.
- Fix images: right size, WebP, lazy-load below the fold.
- Turn on proper page caching, but never cache cart or checkout.
- Remove plugins you do not use, and stop the rest loading everywhere.
- Limit fonts and let the first screen appear without animations.
- Test on a real phone, on mobile data, not only on office Wi-Fi.
The part nobody tells you about speed
When the owner messaged me on Saturday morning, he did not say “thank you for the fast site”. He said “people are actually buying”. That is the part nobody tells you: speed is not a technical score, it is a sales feature. On a slow product page, people tap, wait, and go back to Instagram. On a fast one, they scroll, look at the photos and add to cart before they have time to doubt.
The store’s mobile visitors had always bounced more than desktop ones, and everyone assumed it was because “people do not buy on phones”. After the fix, mobile orders went up more than desktop orders. People do buy on phones. They just do not wait.
Why the store got slow in the first place
Nobody built this site to be slow. It got slow one small decision at a time. A slider for a seasonal campaign. A plugin for Instagram photos. A chat widget. A second SEO plugin because someone read a blog post. Each one added a little weight, and nobody ever removed anything. Two years later the homepage was carrying the history of every marketing idea the business ever had.
This is the most common story I see with a slow WordPress site. It is not one big mistake. It is many small additions that nobody reviews.
How we kept it fast after the sale
Fixing speed once is easy. Keeping it fast is the real work. After the sale weekend we set up three simple habits:
- A monthly check. Same pages, same tool, numbers written down. If something gets slower, we know which month it happened.
- A rule for new plugins. Before installing anything, ask what it does on the front end and whether there is a lighter way.
- Images through a size check. New product photos get resized and converted before upload, not after.
These habits take maybe an hour a month. They are also exactly what a good care plan should include, so that speed never quietly slips back to six seconds.
What I would do differently today
That night I fixed things in the order I found them. Today I would start with the first screen: the hero image, fonts and anything blocking the page from showing content. That is what visitors see first, and it is where the biggest perceived improvement comes from. Then the server and caching, then plugins, then everything else.
I would also test on a cheap Android phone on mobile data much earlier. Office Wi-Fi and a new laptop hide most speed problems. Your customers are not using your office Wi-Fi.
WordPress website speed is not only a plugin setting
Many people treat WordPress website speed as a box to tick: install a caching plugin, get a green score, move on. That night showed me again that real speed comes from decisions. Which images go on the homepage. How many fonts you load. Whether a slider is worth two seconds. Which plugins earn their place. A caching plugin cannot make those decisions for you.
It also changed how I build new sites. Every WordPress and Elementor project I deliver now starts with a speed budget: a maximum page weight and a maximum number of requests for the homepage. If a new section breaks the budget, we find a lighter way to build it. That is much cheaper than fixing a slow WordPress site on a Friday night before a sale.
How to explain WordPress website speed to your team
If you work with marketers or content editors, give them one simple rule: every new image, plugin or widget has a cost. Ask them to check the page on a phone after each change. When everyone sees speed as part of the customer experience, not a technical detail, the site stays fast without anyone having to fight for it.
Questions I usually get
Is hosting the problem?
Sometimes, but rarely the first one. Cheap hosting makes a heavy site worse. Fix the weight first, then decide if you need better hosting.
Which caching plugin should I use?
It depends on your server. On LiteSpeed servers server-level caching works best. The important part is one caching solution, set up properly, not several.
How often should I check speed?
Every month, and after every new plugin or big content change. Speed usually breaks slowly, one addition at a time.
Need a hand with yours?
If your WordPress site feels slow and you do not have a Friday night to spare, this is exactly what my website care and rescue service covers, and every WordPress and Elementor build I deliver ships with these settings from day one. Request a project review and I will tell you what is slowing your site down and what to fix first.
