A slow website is a symptom, not a diagnosis. Ask “why is my website slow?” and the answer could be a server that takes two seconds to respond, a 4 MB photo at the top of the page, or a pile of marketing scripts fighting over the phone’s processor. Each has a different fix, and often a different person who should make it.
That is why generic speed tips disappoint: a caching plugin won’t fix a chat widget. Diagnose in order, with free tools, and only then decide whether to optimise or rebuild.
Why is my website slow? The short answer
Most slow websites are slow for one of three reasons:
- The server responds slowly. Underpowered hosting, no page caching, heavy plugins or a server far from your visitors.
- The page is too heavy. Oversized images, page-builder and plugin bloat, too many web fonts, and CSS or JavaScript that must load before anything appears.
- Third-party scripts get in the way. Tags, ad pixels, chat widgets, cookie banners and video or map embeds competing for the browser.
To find which, check real-user data, test key templates on mobile and read a request waterfall.
Step 1: Check what real visitors experience
Start with field data: measurements from real Chrome users, not a single test run.
PageSpeed Insights. Enter a page address and read the top section, mobile first. It comes from the Chrome User Experience Report (CrUX), covers the previous 28 days and reports each metric at the 75th percentile. How to read a PageSpeed Insights report explains the rest.
Search Console. The Core Web Vitals report groups similar pages, for mobile and desktop separately, showing whether one type of page is affected or the whole site.
If a page has too little Chrome traffic, PageSpeed Insights shows data for your whole site instead; if the site has too little too, rely on lab tests and your own phone.
What the failing metric tells you
Google rates a page as good when, at the 75th percentile, Largest Contentful Paint (LCP) is 2.5 seconds or less, Interaction to Next Paint (INP) is 200 milliseconds or less and Cumulative Layout Shift (CLS) is 0.1 or less. Core Web Vitals explained covers each in plain English. Which one fails is your first clue:
| Failing metric | What visitors notice | Look first at |
|---|---|---|
| LCP (loading) | A blank or half-built screen | Server response, the hero image, blocking CSS and fonts |
| INP (responsiveness) | Taps that seem ignored | JavaScript from the page builder, plugins, tags and widgets |
| CLS (stability) | Content jumping as it loads | Images without dimensions, late banners, embeds, font swaps |
| TTFB (Time to First Byte) | A long pause before anything happens | Hosting, caching, redirects and server location |
TTFB isn’t a Core Web Vital, but PageSpeed Insights reports it, and a slow one delays everything else.
Step 2: Run a website speed test on each key template
Field data confirms the problem. Lab tests locate it, because you control the device, the connection and the page.
Test templates, not just the homepage
Pages that share a template (homepage, service or product pages, articles, landing pages, contact) share its problems. Test one real page of each type, plus any page your ads point to.
Pick the right tool
PageSpeed Insights runs Lighthouse, which simulates a mid-range phone on a slow connection, so mobile scores usually trail desktop. WebPageTest loads the page in a real browser from a location and device you choose, with a filmstrip and a detailed waterfall. Chrome DevTools (right-click the page, then Inspect) shows every request and what the browser was busy doing.
Make the test fair
- Run each test three times and use the middle result. Lab results vary between runs.
- Test logged out, in a private window. Most WordPress caching plugins don’t serve cached pages to logged-in users by default, so a site can feel slow to its owner and much faster to visitors.
Step 3: Read the waterfall
A waterfall is a timeline of every file the browser downloads to build the page, one row per request. Run WebPageTest, or open the DevTools Network panel, tick “Disable cache”, choose a mobile throttling preset and reload. Then read four things.
1. The first row: how long the server took
The first request is the HTML document, and nothing else starts until its first byte arrives. A long wait here points to a slow server, or a chain of redirects before it. As a rough guide, web.dev suggests most sites aim for a TTFB of 0.8 seconds or less.
2. What loads before anything appears
WebPageTest’s filmstrip shows when content first appears. A queue of CSS and JavaScript before that moment usually means render-blocking resources: the browser won’t paint until it has them. Render-blocking resources explained shows how to deal with them.
3. The biggest files
Sort by size. A multi-megabyte image, a background video or a dozen font files stand out at once. On WordPress, filter by wp-content/plugins to see which plugins load files on this page.
4. The domains you don’t control
Count the domains that aren’t yours: analytics, ads, chat, fonts, video, maps. Then look for stretches where little downloads but the page still isn’t ready: the browser is busy running JavaScript. In the DevTools Performance panel, any task over 50 milliseconds counts as a long task, and a page full of them feels unresponsive on a phone.
Step 4: Trace the cause to the server, the page or a third party
Most slow sites have one dominant cause and a couple of smaller ones. Place what you found:
| Bucket | What you see | Who usually fixes it |
|---|---|---|
| Server | Long first-row wait, slow on every page, sluggish admin area | Your host or developer |
| Front end (the page) | Fast first byte but late LCP, large files, queues of CSS and JavaScript | Your web developer |
| Third party | Many external domains, long tasks from scripts you didn’t write, poor INP | Whoever owns marketing tags and widgets |
Notice the last column: speed problems often linger because they fall between hosting, development and marketing, and nobody owns the whole page.
Confirm a third-party suspect. In the DevTools Network panel, right-click one of the suspect’s requests, use the block request option to block its whole domain, and reload. If the page is clearly faster without, say, the chat widget, you have your answer, and a trade-off to discuss. Third-party scripts and website speed covers auditing tags properly.
Slowed down suddenly? Start with what changed around that date: a plugin, theme or PHP update, a new tag or widget, a hosting move, or a surge of bot traffic.
Slow website causes, symptom by symptom
Slow hosting, no caching or a distant server
Symptom. A long first-row wait on every page, worse at busy times or far from the server, and a sluggish WordPress dashboard.
Check. Many hosts and CDNs add a response header saying whether the page came from cache (HIT) or was built fresh (MISS): click the document request in DevTools and look under Headers. Then compare the first-row wait from a WebPageTest location near your server with one near your customers.
Fix. Turn on full-page caching, run a PHP version that still gets updates, and upgrade hosting if it is still slow. Host near your main audience, and if you serve several regions, put a CDN in front that can cache whole pages. See how to choose web hosting for speed and website caching and CDNs explained.
Oversized images
Symptom. A late LCP, where the LCP element is the hero image.
Check. Compare each large image’s pixel width with the space it fills. Even allowing double for sharp screens, a 4,000-pixel photo in a 400-pixel card is five times too wide.
Fix. Resize before uploading, serve WebP or AVIF, set width and height, and lazy-load images below the fold, never the main image at the top. Image optimisation for websites has the full playbook.
Page-builder and plugin bloat
Symptom. Dozens of CSS and JavaScript files, a DOM size warning in PageSpeed Insights, poor INP on phones.
Check. Look for plugins that load files on every page but are used on one, such as a form, slider or gallery.
Fix. Remove what you don’t use and load assets only where needed; how to speed up a WordPress website covers doing it safely. If every page is built from deeply nested sections, the problem is structural.
Heavy web fonts
Symptom. Text that is invisible for a moment, or jumps when the web font replaces the fallback.
Check. Filter the waterfall by font. Several families in several weights, or a whole icon font for five icons, is a common find.
Fix. Cut families and weights, self-host WOFF2 files, preload only the fonts on the first screen, and use font-display: swap with a similar-sized fallback.
Stacked marketing scripts
Symptom. Many external domains and poor INP, worse than the design alone would explain.
Check. List every tag in your tag manager with its owner and purpose. Expect pixels from finished campaigns, duplicate analytics and a forgotten heatmap trial.
Fix. Remove what nobody uses, delay the rest until the page is usable, and swap video and map embeds for a lightweight preview that loads the real thing on click.
Optimise or rebuild?
Once you know the cause, ask one question: do the fixes change what your pages load, or how every page is built?
| Situation | Optimise | Rebuild |
|---|---|---|
| Main cause | Hosting, caching, images, a few scripts | The theme or page builder itself |
| Software | Current and easy to update | PHP or WordPress can’t be updated without breakage |
| History | First serious speed effort | Optimised before, and the slowness crept back |
| Other problems | Few | Poor on phones, hard to edit, few enquiries |
Mostly in the Optimise column? Then optimise; the website speed optimisation guide sets out the order to work in. Mostly in the Rebuild column? Faster hosting and another plugin will only buy time. A property developer’s website we rebuilt was in that position: slow, but also broken on phones and hard for its marketing team to update. The rebuild took load time from 9 seconds to 2. Signs your website needs a redesign helps you weigh speed against everything else.
Either way, test the same templates the same way before and after, and watch field data for four weeks, since CrUX is a rolling 28-day window.
Frequently asked questions
Why is my website slow on mobile but fine on desktop?
Phones take longer to run the same JavaScript, and mobile connections usually add delay to every request, so heavy scripts and large images hurt far more. Test on a mid-range phone using mobile data, not office Wi-Fi, to see what many customers see.
Will a caching plugin fix my slow website?
Only if the server is the bottleneck. Page caching saves the work of building each page, but it won’t shrink a 3 MB image or stop a chat widget tying up the phone’s processor.
Is a perfect PageSpeed score the goal when fixing a slow site?
No. The Lighthouse score is a lab summary, not the measure Google uses for page experience, and it moves between runs. Aim for good Core Web Vitals for real visitors, then put the effort into content and conversion.
What to do next
Work through the diagnosis in order:
Speed also erodes as new plugins, full-size photos and campaign tags arrive, so a fast site stays fast only if someone keeps watching. Our website care plans keep the software updated and monitored, and the Growth plan adds monthly improvements and speed work.
Would you rather not read waterfalls yourself? Ask for a free website audit and mention the pages that feel slow. A person will review them and tell you which fixes to make first, in a report you can hand to whoever looks after your site.