Slow small business websites usually come down to three causes: oversized images, code from plugins, builders and tags that pages never use, and a slow server. Here is how to find yours with free tools, what to fix first, and when a rebuild beats more tuning.
Your website is most likely slow for one or more of three reasons: images heavier than they need to be; JavaScript and CSS from plugins, page builders and tags that the page never uses; and a server that is slow to answer. It costs you visitors who give up before anything appears, and some search visibility, because Google says Core Web Vitals are used by its ranking systems.
You are not alone. In the HTTP Archive's 2025 Web Almanac, only 62% of websites had a good Largest Contentful Paint (LCP) on mobile, the measure of how quickly the main content appears, and the median mobile home page grew to about 2.6 MB.
Each cause can be checked with free tools in an afternoon, and the first round of fixes rarely needs a new website.
- of mobile pages have an image as their largest element
- 76%
- of mobile pages have an image as their largest element
- of images on the median mobile home page, out of about 2.6 MB
- 911 KB
- of images on the median mobile home page, out of about 2.6 MB
- of mobile pages passed Lighthouse's render-blocking check in 2025
- 15%
- of mobile pages passed Lighthouse's render-blocking check in 2025
- of mobile sites had a good Time to First Byte (0.8 s or less)
- 44%
- of mobile sites had a good Time to First Byte (0.8 s or less)
01
Start with the honest test
Open your site on your own phone, on mobile data, away from the office wifi, and watch for the moment the main content appears. Then run the page through PageSpeed Insights, which reports two kinds of data. Field data shows what real Chrome visitors experienced over the previous 28 days; lab data is one simulated load on a mid-range phone over a mobile network. When they disagree, trust the field data, because it is your customers.
The number to watch is LCP, the moment the biggest element on screen, usually the hero image or headline, finishes drawing. Google counts 2.5 seconds or less as good. Then match what you see to a likely cause:
| What you see | Likely cause | Where to check |
|---|---|---|
| A blank screen for a second or more | Slow server, redirects or render-blocking files | Document request latency and Render-blocking requests insights |
| Text appears, the banner arrives last | Heavy or lazy-loaded hero image | LCP request discovery and Improve image delivery insights |
| Page appears, then taps feel sluggish | Too much JavaScript | Chrome's Coverage panel and the 3rd parties insight |
| Fast for you, slow for customers | You test on fast hardware and wifi | Field data in PageSpeed Insights |
02
Cause one: images that are too heavy
Images are the largest share of a typical home page: 911 KB of the median mobile home page, against 632 KB of JavaScript. Because the largest element is an image on 76% of mobile pages, a heavy banner or slider delays LCP directly.
The Improve image delivery insight flags the usual faults: images compressed less than they could be, older formats where WebP or AVIF would do, and files larger than the size they are shown at. WordPress helps more than it used to. Since version 6.3 it adds fetchpriority=high to the image it judges most likely to be the LCP element, which its developers say typically improves LCP by 5% to 10%, and since 6.5 it accepts AVIF uploads if your server supports them.
03
Cause two: code the page never uses
An estimated 60% of WordPress sites use a page builder, and the median WordPress page on mobile ships 638 KB of JavaScript and 119 KB of CSS. On the median mobile inner page, JavaScript (660 KB) outweighs images (354 KB). If a plugin's files load on every page, every page pays for them, including the ones that never use the feature.
To see it, open Chrome DevTools, open the Coverage panel and reload: it lists every script and stylesheet with how much went unused. The Render-blocking requests insight names the files that hold up the first paint, and in 2025 only 15% of mobile pages passed Lighthouse's render-blocking check. Marketing tags and chat widgets add more, and the 3rd parties insight shows which providers you load. web.dev's first suggestion for a slow third-party script is to remove it if it does not add clear value.
Keeping WordPress itself updated helps too. Version 6.9, released in December 2025, loads block styles in classic themes only when a page needs them, and its developers measured an average of 45% less CSS on the sample page across the bundled themes.
04
Cause three: a slow server
Before the browser can draw anything, your server has to answer. web.dev suggests a Time to First Byte of 0.8 seconds or less, and in 2025 only 44% of mobile sites managed it. The Document request latency insight flags three faults: redirects, a server that takes more than 600 ms to respond, and HTML sent uncompressed.
Look at hosting first. web.dev notes that shared hosting is generally slower, and that visitors far from your server can still see a slow first byte; a CDN fixes that by caching content on servers physically closer to them. Large Indian publishers show the pattern: NDTV extended caching of static files from a few minutes to 30 days as part of cutting its LCP from 3.0 to 1.6 seconds, and The Economic Times switched from Gzip to Brotli compression and served templates from a cache.
Before you even consider other optimization approaches, hosting should be the first thing you consider.
05
What it is costing you, and when to rebuild
Chrome's research in 2020 found that when sites met the Core Web Vitals thresholds, users were 24% less likely to abandon page loads before anything appeared. Controlled tests have since tied faster pages to more sales; we set out that evidence, and how to estimate your own cost, in what a slow website costs.
On search, relevance comes first: Google will still show the most relevant page even when its page experience is poor. Speed helps most when you compete with pages that are just as useful as yours.
Platform matters too. In the 2025 Almanac data, 85% of Duda sites and 74% of Wix sites passed Core Web Vitals on mobile, against 45% for WordPress, where results vary more because themes, plugins and integrations differ so much. If your site is still slow after the fixes below, the weight is probably built into the theme or builder, and an optimisation plugin is unlikely to remove it. That is when a rebuild is worth pricing: see what a website costs in India and whether WordPress is still the right choice.
06
Fix it in this order
Work from the cheapest, highest-return fix down, and measure after each step so you know what helped.
- Measure. Record mobile LCP from PageSpeed Insights for your home page and two key inner pages, so you can prove what changed.
- Fix the hero image. Resize it to its displayed size, compress it, serve WebP or AVIF, and make sure it is not lazy-loaded.
- Remove what you do not use. Delete inactive plugins, unused builder add-ons and tags nobody owns, then check the Coverage panel again.
- Keep the software current. Update WordPress or your platform, your theme and your plugins, so you get the performance work in recent releases.
- Turn on caching and compression, and put a CDN in front if your host offers one.
- Retest on a phone on mobile data, then watch the field data over the following 28 days, the window Google reports on.
If you would like help reading the results, Accendoz offers a free audit, and our web development page explains how we build for speed when a rebuild is the honest answer.
Sources
Figures current as of 30 June 2026.