Why is my WordPress site slow? On most sites the cause is one of five things: a heavy or lazy-loaded main image, many render-blocking CSS and JavaScript files, third-party scripts such as form protection and trackers, unoptimised images, or a slow server. We found all five on our own website. After fixing them, the homepage’s mobile PageSpeed Insights lab score went from 45–51 on 29 October 2026 to 90–98 on 30 October 2026.
Those are our own lab figures for one site. They vary from run to run, and they are not a promise for yours. This post shows what we measured, what we changed, what went wrong and what is still not perfect, so you can run the same diagnosis. If you would rather have someone do it, see our WordPress maintenance and support service.
Why is my WordPress site slow? Start with the right numbers
Do not start with a single score. PageSpeed Insights shows two kinds of data. Lab data is a simulated load in a controlled setup, useful for finding problems. Field data comes from real Chrome users over the previous 28 days, reported at the 75th percentile, and it is what Core Web Vitals judges. Google’s documentation says a good lab score does not guarantee a good experience for real users (PageSpeed Insights docs).
| Core Web Vital | Good threshold | What it measures |
|---|---|---|
| Largest Contentful Paint (LCP) | 2.5 seconds or less | How quickly the biggest visible element appears |
| Interaction to Next Paint (INP) | 200 milliseconds or less | How quickly the page responds when someone taps or clicks |
| Cumulative Layout Shift (CLS) | 0.1 or less | How much the layout jumps while loading |
Thresholds are from web.dev, measured at the 75th percentile and separately for mobile and desktop. A page passes only if it meets all three. Google also says it recommends good Core Web Vitals for success in Search (Search documentation). Total Blocking Time (TBT) is a lab-only metric that helps diagnose likely INP problems, but web.dev warns it cannot fully predict INP.
Scores also move for reasons that have nothing to do with your site. Google’s Lighthouse notes list local network, client hardware and other software on the testing machine as sources of variance, and recommend several runs rather than one (Lighthouse variability). Run each test a few times and note the date.
What we found on our own site on 29 October 2026
Our stack: WordPress with the Sydney theme and a child theme, Elementor, LiteSpeed Cache, free Cloudflare, Contact Form 7 with reCAPTCHA, a chat button, Google Tag Manager and GA4, a Meta pixel and Microsoft Clarity. Hosting is a Hostinger Business plan on LiteSpeed. Server response time (TTFB) was 270–320 ms, so the server was not the main problem.
The baseline, from PageSpeed Insights lab data on the homepage: mobile score 45–51, LCP 3.8–3.9 seconds and TBT 820–1,440 ms. Desktop scored 41 with LCP of 3.5 seconds. The causes:
| Cause found | Evidence from the report |
|---|---|
| Desktop hero image was lazy-loaded | 6,850 ms of load delay before the main image started |
| Render-blocking CSS and fonts | About 25 CSS files (133 KiB) plus Google Fonts blocked first paint |
| Icon fonts on the critical path | Font Awesome fonts loaded before the page could draw |
| Two optimisation tools clashing | Cloudflare Rocket Loader was on while LiteSpeed Cache did its own optimising |
| Form protection on every page | reCAPTCHA loaded twice on every page: 702 KiB of JavaScript, the main source of TBT |
| Heavy images | Images were not WebP; the hero PNG was about 2.9 MB |
| Trackers loading immediately | Tag Manager, Meta pixel and Clarity ran at page load |
The fixes, in order
- Switched Rocket Loader off, because it conflicted with LiteSpeed Cache.
- Loaded the hero image eagerly with fetchpriority high. web.dev’s advice is blunt: never lazy-load your LCP image, and set high fetch priority on it.
- Loaded reCAPTCHA and Contact Form 7 scripts only on pages with forms. This removed the biggest block of JavaScript from every other page.
- Added critical CSS and loaded the rest asynchronously, using LiteSpeed Cache with QUIC.cloud.
- Self-hosted fonts using Elementor’s option to load Google Fonts locally, set font-display to swap and preloaded the key files.
- Converted images to WebP through image optimisation.
- Delayed Tag Manager, the Meta pixel and Clarity. web.dev’s guide to improving Core Web Vitals lists avoiding unnecessary JavaScript among its top INP fixes, including removing old tags from your tag manager.
What went wrong
We tried the CSS Combine option in the caching plugin to cut the number of CSS files. It broke the Font Awesome icons, so we rolled it back. The lesson is not that combining CSS is bad. It is that every speed change needs a visual check of key pages on desktop and mobile, and a way back. Change one thing at a time.
Results, with dates and caveats
| Homepage, PageSpeed Insights lab | 29 Oct 2026 (before) | 30 Oct 2026 (after) |
|---|---|---|
| Mobile score | 45–51 | 90–98 |
| Mobile LCP | 3.8–3.9 s | 1.5–1.9 s |
| Mobile TBT | 820–1,440 ms | 0–110 ms |
| Desktop score | 41 | 90–96 |
These are lab results on our own site, not client results, and they changed between runs. For example, the first visit after a cache purge scored 84. We also fixed a layout shift, taking CLS from 0.128 to 0, which is inside Google’s 0.1 limit.
What is still not perfect
Service pages are slower than the homepage. A service page on our site scored about 78–81 on mobile, with LCP near 3.2 seconds, which misses the 2.5-second threshold. The reason is a plan limit, not a mistake: generating critical CSS for each URL is limited to two a day on the free QUIC.cloud plan, so not every inner page can get its own. Fixing it means a decision on a paid plan or another way of producing critical CSS.
This is why a high homepage score is not the same as a fast site. Test your key landing pages, not just the home page.
A diagnosis you can run on your own site
| Symptom in the report | Likely cause | What to try |
|---|---|---|
| High LCP | Large, late or lazy-loaded main image; slow first byte | Remove lazy-loading from that image, add fetchpriority high, serve a smaller modern format. web.dev puts the first byte at roughly 40% of LCP on a well-optimised page, so check it first |
| High TBT or poor INP | Too much JavaScript, heavy tags, form scripts on every page | Load scripts only where needed, delay trackers, remove unused tags and plugins |
| CLS above 0.1 | Images without set dimensions, late-loading embeds, banners | Set width and height, reserve space for embeds |
| Slow first byte | Slow hosting, no page cache, redirects | Turn on page caching, remove redirect chains, add a CDN, ask your host about PHP version |
| Many render-blocking files | Too many plugins loading CSS and JavaScript on every page | Audit plugins, remove what is unused, load assets only where used |
- Run PageSpeed Insights on mobile three times and note the date.
- Open the diagnostics and find the LCP element.
- Check server response time before touching the front end.
- Change one thing, then retest and check the page by eye.
- Keep a backup and a way back before each change.
For the ongoing routine that keeps speed from slipping, use our WordPress maintenance checklist. If your site runs on Elementor, our post on Elementor vs Gutenberg explains how the editor choice fits in. We also have an older post on website performance and speed.
Get a free site check
Not sure what is slowing your site? Get a free site check. We will run the tests above and tell you what we find. For regular care, see maintenance and support.
FAQ
Is a PageSpeed score of 90 the goal?
Not by itself. The score is a lab number. Core Web Vitals are judged on real-user data at the 75th percentile. Use the score to find problems, and use field data to see whether users feel the improvement.
Why does my score change every time I test?
Lab tests depend on network, device and other software at the time of the run. Google’s Lighthouse documentation lists these as sources of variance and recommends running several tests. Compare medians over time, not single runs.
Does Elementor make a WordPress site slow?
Any page builder adds code, so it needs care. Our own site runs Elementor and its homepage scored 90–98 on mobile in lab tests on 30 October 2026 after the changes above. That does not guarantee the same result on another site.
Will a faster site rank higher?
Google says it recommends good Core Web Vitals for success in Search, and that they align with what its ranking systems reward. It does not promise a ranking boost, so treat speed as one part of the job.
Can too many plugins slow my site?
They can, mostly when plugins load scripts and styles on pages that do not use them. On our site, form-protection scripts loaded on every page and were the main cause of long blocking time. Audit what loads where, not just how many plugins you have.
How long does speed work take?
Our homepage went from a baseline on 29 October 2026 to the results above on 30 October 2026. Service pages are still not perfect. Time depends on how many problems you have and how many page types need their own fixes.
