Why Is My Website Slow? What You Can Fix Today and What Needs a Rebuild
A slow website is usually slow for three or four specific reasons, and they are visible in a free test in under five minutes. Here is how to read the results, which fixes you can make from a dashboard this afternoon, and which ones are the architecture of the site itself.
Slow websites are rarely slow for mysterious reasons. When we audit one, the causes are almost always on a short list, and most of them are visible in a free test that takes five minutes. What’s less obvious is which of them you can fix this afternoon and which ones are built into the site’s foundation, because that distinction decides whether you need a developer for a day or a different site.
Here is what has to happen before a visitor sees your page, where each cause sits in that sequence, how to read the test, and an honest split between dashboard fixes and rebuild fixes.
What has to happen before a visitor sees your page
- Visitor taps the link Often on a phone, on cellular
- Server responds Distance and hosting speed decide this
- HTML arrives The browser starts building the page
- CSS and JavaScript load Heavy themes and scripts block here
- Images decode Oversized files stall the hero
- Largest element paints This is the LCP moment
Run the test first
Open PageSpeed Insights, enter your homepage, and select Mobile. Then do the same for your most important service page. Two things to read:
- The real-user section at the top (“Discover what your real users are experiencing”), if your site has enough traffic to show it. These are the numbers Google uses, and they come from actual visitors on actual phones. Core Web Vitals Explained covers what they mean.
- The diagnostics further down. This is where the causes are named: “Properly size images,” “Reduce unused JavaScript,” “Eliminate render-blocking resources,” “Reduce the impact of third-party code,” and so on, each with the specific files responsible.
Ignore the score for a moment. The diagnostics are the diagnosis.
The five causes, in the order we find them
1. Images shipped far larger than the screen needs
The most common cause, and the easiest to fix. Someone uploaded a 4,000-pixel photo straight from a camera, and the site serves it to every phone at full size. A hero image should be a few hundred kilobytes at most, in a modern format (WebP or AVIF), sized for the screen it appears on, with the below-the-fold images loading lazily.
Symptoms in the test: “Properly size images,” “Serve images in next-gen formats,” “Defer offscreen images,” and a large LCP number tied to an image file.
2. Heavy themes and page builders
Page builders (and many premium themes) load a large runtime on every page to render layouts that are, in the end, a headline and some columns. That code has to be downloaded, parsed, and executed on the visitor’s phone before the page becomes usable. It is the same cost on your simplest page as on your most complex one.
Symptoms: “Reduce unused CSS,” “Reduce unused JavaScript,” “Eliminate render-blocking resources,” with the theme’s or builder’s files named.
3. Third-party scripts
Chat widgets, analytics, ad pixels, review badges, map embeds, video embeds, font services, cookie banners, heat-mapping tools. Each one is a separate request to a separate server, and several of them run code before your content appears. They accumulate: the chat widget was added in 2022, the pixel in 2023, the review badge last spring, and nobody ever removed anything.
Symptoms: “Reduce the impact of third-party code,” with a list of domains and the time each one cost. This list is worth reading slowly. Every entry is a decision someone made and forgot.
4. JavaScript-heavy frameworks
Some modern sites are built so the browser assembles the page on arrival, downloading a large application bundle and running it before anything meaningful appears. This is the right architecture for a web application; it is the wrong one for a business website, where the page content is the same for every visitor and could have been built in advance.
Symptoms: a large “Total Blocking Time,” a poor INP in real-user data, and JavaScript bundles measured in hundreds of kilobytes or more.
5. Slow hosting, far away
Shared hosting under load, or a single server on another continent from your visitors, adds a wait before anything starts. This shows as a long time to first byte. It is real, and it is also the cause people most often blame when the actual problem is one of the four above.
Symptoms: “Reduce initial server response time,” with a TTFB over roughly half a second on repeated tests.
What you can fix from a dashboard, and what you can’t
This table is the honest part of the article. Some fixes take an afternoon; others are the site.
| Cause | Dashboard fix | Does it solve it? | Structural fix |
|---|---|---|---|
| Oversized images | Compress and resize; install an image-optimization plugin; convert to WebP | Usually yes, for images | Build-time image optimization that never ships a wrong-sized file |
| Third-party scripts | Remove the ones nobody uses; delay the rest until after the page settles | Partly — you keep the ones you need | Load interactivity only where it’s needed; consent-gated and lazy by design |
| Heavy theme or page builder | Caching plugin; disable unused modules | No — the runtime still ships | A static-first framework that ships almost no JavaScript |
| JavaScript-heavy framework | Code splitting, if a developer can do it | Partly | Pre-built HTML pages (static rendering) |
| Slow hosting | Better hosting; a CDN in front | Yes, for the server part | Edge delivery — pages served from a global network, no origin server to be slow |
| Web fonts | Reduce to one or two families; preload them | Mostly | Size-matched fallbacks and self-hosted fonts in the build |
| Layout shifts | Set image dimensions in the editor | Partly | Templates that reserve space for every element |
The pattern: images, scripts, and hosting can be tuned. Themes, builders, and application-style frameworks are the foundation, and you cannot optimize your way out of a foundation. This is why a business site can spend a year on caching plugins and still fail on mobile, and why the same site rebuilt on a static-first framework served from the edge tends to pass immediately. WordPress vs Astro for Business Websites goes through when that rebuild is worth it and when it isn’t.
An afternoon of dashboard fixes, in order
If you want to improve what you have before deciding anything bigger:
- Replace the hero image on your homepage and top service pages with a properly sized, compressed version. This alone often moves LCP more than anything else.
- Audit third-party scripts. List every widget, pixel, and embed. For each, ask who uses it and whether it produces anything. Remove the ones with no answer.
- Delay the survivors. Most analytics and chat tools can be set to load after the page is interactive.
- Cut fonts to two families, and check that text is visible while they load.
- Enable caching and, if you can, put a CDN in front of the site.
- Re-test on mobile and compare the diagnostics.
If the site is meaningfully faster and passes on mobile, stop; spend your energy on content and conversion instead. If it is still failing after all six, you have reached the foundation.
When the foundation is the problem
A site that fails mobile Core Web Vitals after the dashboard fixes is telling you something: the weight is the architecture. At that point the honest advice is a rebuild on a foundation that is fast by default — pages built in advance as plain HTML, minimal JavaScript, images optimized at build time, served from an edge network close to every visitor. That is the standard every CactusLaunch build ships with, not as a post-launch project but as a property of how the site is made. Why Fast Websites Convert Better explains what that speed is worth in enquiries, and Signs Your Website Needs a Redesign helps you decide whether it’s time.
If you’d like a second opinion before deciding, speed is one of the ten categories in a free website roast, and the review says plainly whether you’re looking at a tune-up or a foundation.
Questions people ask
How do I test my website speed properly?
Use PageSpeed Insights, select Mobile, and read the real-user Core Web Vitals section at the top before the score. Then look at the diagnostics below it, which name the specific images, scripts, and requests costing time. Test your homepage and your most important service page, not just the homepage.
Is my hosting the problem?
Sometimes. Slow shared hosting shows up as a long "time to first byte" — the wait before anything arrives. If that number is over about half a second on repeated tests, hosting is part of the problem. But most slow sites have a fast enough server and a heavy page; fixing hosting alone rarely fixes them.
Will a caching plugin fix it?
It will help a slow server respond faster, which is real. It will not shrink a four-megabyte hero image, remove a page-builder runtime, or stop six tracking scripts from loading. Caching treats one cause out of five.
Is my chat widget slowing the site down?
Very likely, along with every other third-party script. Chat widgets are often the single heaviest script on a business site. If yours is genuinely answered and produces leads, keep it but load it after the page settles; if nobody responds to it, remove it and gain both speed and honesty.
My site is simple. Why is it still slow?
Because weight is invisible. A page that looks like a headline and three paragraphs can be carrying a page-builder framework, a slider library, four font families, and a megabyte of tracking code. The visitor's phone has to download and process all of it before your three paragraphs appear. Simple-looking and lightweight are not the same thing.
This article is part of the website performance library. If it describes a problem you have, the service behind it is here: see the growth stack™.
Keep reading
Core Web Vitals Explained for Business Owners
Core Web Vitals are Google's three measurements of how a page feels to a real visitor — how fast the main content appears, how quickly the page responds to taps, and how much it jumps around while loading. Here is what each one means, the exact thresholds, why your PageSpeed score and Search Console disagree, and what actually moves the numbers.
How Website Speed Affects SEO, Leads, and Revenue
Speed isn't a technical vanity metric. It's a conversion lever, a trust signal, a ranking input, and a factor in what your ads cost, all at once. Here is the mechanism behind each, the published case studies worth trusting, the ones worth ignoring, and why the durable fix is architectural rather than a plugin.
WordPress vs Astro for Business Websites - An Honest Decision Guide
WordPress runs a huge share of the web and Astro is what we build on. Neither is "better" in general. Here is what each one is actually good at, the three questions that decide it for a service business, what happens to editing, forms, and blogs when you leave WordPress, and the cases where WordPress is still the right answer.