Why is my website slow? A plain-English diagnosis

A website is slow for one of four reasons in nearly every case: images that are far larger than they need to be, too many third-party scripts, a bloated theme or page builder, or hosting that cannot keep up. Occasionally the problem is not the site at all but the device, network, or location you are testing from. This article walks through a five-minute website speed test that tells you which cause is yours, what each fix costs in time and effort, what speed is realistically worth in conversions, and when a slow loading website means the platform underneath it needs replacing rather than patching.

Rule out your own device and network before blaming the site

A surprising share of 'my website is slow' complaints turn out to be a slow laptop, a VPN, a corporate network, or a browser with thirty tabs and a dozen extensions. Before touching the site, open it in a private window on a phone using mobile data, and ask someone in a different city to do the same. If it is fast for them and slow for you, the site is fine.

Geography matters too. If your server sits in one country and your customers are in another, every request crosses an ocean before the page even starts. That is a hosting or CDN question, not a design one, and it is worth knowing before you spend money on image compression that will not help.

The five-minute website speed test and what the numbers mean

Run your homepage and your most important landing page through Google's free PageSpeed Insights. Ignore the overall score for a moment and look at three numbers. Google's own thresholds for a 'good' experience are Largest Contentful Paint (LCP) under 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds, and Cumulative Layout Shift (CLS) under 0.1.

• High LCP with a high 'server response time' warning points to hosting, missing caching, or a slow database. Nothing on the page can load until the server answers.
• High LCP with a fast server response points to the page itself: an oversized hero image, a background video, or fonts blocking render.
• High INP points to JavaScript. Something is hogging the main thread, usually a page builder, a chat widget, or a stack of tracking scripts.
• High CLS means content jumps as it loads, typically images without set dimensions, late-loading ads, or fonts swapping in. It feels slow even when it is not.

PageSpeed shows two data sets. 'Discover what your real users are experiencing' is field data from actual Chrome visitors over the past 28 days. The lab section below it is a single simulated test on a throttled connection. Trust the field data for whether you have a problem, and use the lab data to find what is causing it. A site can score 45 in the lab and still be fine in the field, and the reverse.

Oversized images are the most common cause and the cheapest fix

The single most frequent finding on a slow small-business site is a hero image uploaded straight from a camera or a stock library at 4000 pixels wide and several megabytes, then displayed at 1200 pixels. Multiply that by a gallery of twenty and the page is downloading more data than a short film.

Confirm it by opening the 'Properly size images' and 'Serve images in next-gen formats' warnings in PageSpeed. Fix it by resizing images to the largest size they will actually display, exporting as WebP or AVIF, and lazy-loading anything below the fold. On most platforms a business owner can do this without a developer. It is an afternoon of work and often takes seconds off LCP on its own.

One caveat: the hero image is the exception to lazy loading. It should load first and with priority, because it is usually the LCP element. Lazy-loading it makes the page slower, and it is a common mistake with plugins that lazy-load everything by default.

Third-party scripts and plugins are why your site got slower over time

Sites rarely launch slow. They get slow one script at a time: analytics, a heat-map tool, a chat widget, a pixel for each ad platform, a cookie banner, a review widget, an A/B testing snippet. Each one is small. Together they can block the main thread for a second or more on a mid-range phone, which is what a bad INP score is telling you.

Confirm it with the 'Reduce the impact of third-party code' panel in PageSpeed, which lists every external script by the time it cost. Then audit them against the tools you actually look at. It is common to find scripts for services that were cancelled a year ago. Removing dead ones is free. For the ones you keep, loading them after the page is interactive rather than before is a developer task, but a small one.

On WordPress, plugins are the same problem in a different coat. Each active plugin can add its own CSS and JavaScript to every page, whether that page uses it or not. Deactivating plugins one at a time and re-testing is tedious, but it is the most reliable way to find the one that is costing you.

Heavy themes and page builders trade your speed for their convenience

Multipurpose themes and drag-and-drop page builders ship code for every feature they support, not just the ones you use. A page that displays a heading and a paragraph can still load a slider library, an icon font with a thousand glyphs, and animation frameworks the theme bundled for someone else's demo. This is the cause when PageSpeed flags large amounts of unused CSS and JavaScript on a page that looks simple.

This one is the hardest to fix in place. You can strip some assets with optimisation plugins, but you are fighting the theme's architecture, and the next update can undo your work. If your theme is the bottleneck, the realistic options are a leaner theme with the same platform, or a custom build. I compared the two paths in custom website vs website builder, and speed is one of the places the difference shows up most clearly.

Cheap hosting shows up as a slow server response, not a slow page

If PageSpeed reports a server response time above roughly 600 milliseconds, the fastest page in the world will still feel sluggish, because nothing renders until that first byte arrives. Shared hosting puts many sites on one machine, so a neighbour's traffic spike becomes your slowdown. Slow database queries, missing page caching, and no CDN compound it.

The fixes, in order of effort: enable server-side page caching (often a toggle or a plugin), put a CDN in front of the site so static files are served from near the visitor, and if that is not enough, move to a better host. The first two can usually be done in a day. Changing hosts is a weekend project for a simple site and a real migration for a complex one, but it is a one-time cost and it fixes a whole category of problems at once.

Fonts, video, database bloat and bots slow sites that pass the big four

• Web fonts. Five weights of two typefaces loaded from an external service can block text from appearing at all. Self-host the two or three weights you use in WOFF2 and let the browser show fallback text while they load.
• Background video. A looping hero video is the most expensive thing you can put above the fold. Keep it short, compress it aggressively, serve a still image on mobile, and never autoplay it with sound.
• Database bloat. On WordPress and similar systems, years of post revisions, spam comments, and orphaned plugin tables slow every query. A cleanup plugin and a schedule fixes it.
• Bot traffic. Crawlers, including a growing number of AI crawlers, can account for a large share of requests to a small site. If your host's CPU is maxed with no matching rise in human visitors, rate-limiting bots at the CDN is the fix.
• Redirect chains and expired cache rules. A CDN configuration that quietly stopped caching after a platform update looks identical to bad hosting. Check the cache-hit headers before you blame the server.

What speed is worth in conversions, stated without the hype

The widely quoted figures about conversions dropping by a fixed percentage per second of delay come from studies that are old, from specific large retailers, and hard to generalise to a ten-page service business site. What holds up across the evidence is narrower but still useful: slow pages lose a portion of visitors before the page finishes loading, the loss is largest on mobile and on paid or cold traffic, and gains flatten once you are under about two seconds. Going from six seconds to two is worth real money. Going from 1.8 to 1.2 is mostly worth it for Core Web Vitals and for pride.

That gives you a priority order. Fix the things that move LCP by seconds first: images, server caching, and render-blocking scripts. Fix INP next, because it affects everyone who tries to tap something. Treat CLS and the last few hundred milliseconds as polish.

When slowness means the platform is the problem, not the settings

There is a point where optimising in place stops paying. You know you have reached it when you have compressed the images, removed the dead scripts, enabled caching and a CDN, and the site is still slow because the theme or builder generates the weight faster than you can strip it. At that point every fix is temporary and every update is a risk. The framework in when to rebuild and when to refresh applies here: if the cost of the next round of patching approaches the cost of a rebuild, rebuild.

A rebuild does not have to mean a plain site. Motion-heavy, scroll-driven design and good performance are not opposites when the motion is built as part of the page instead of bolted on afterwards. The techniques are covered in scroll-driven animation without killing performance, and the site you are reading this on is an example of the approach. Kaev builds cinematic marketing websites this way, but the principle holds whoever builds it: decide what the page is allowed to weigh before the first design is drawn, not after the launch.

Common questions

Why is my website so slow on mobile but fine on desktop?

Mobile devices have slower processors and worse connections, so JavaScript that a desktop shrugs off blocks the main thread on a phone. Large images also cost more on mobile data. Check INP and total JavaScript in PageSpeed's mobile tab, and confirm images are served at mobile sizes rather than desktop ones.

How do I fix a slow website without a developer?

Compress and resize images, remove tracking scripts and plugins you no longer use, enable caching and a CDN through your host, and reduce font weights. Those four steps are within reach of most business owners and cover the majority of slow sites. Deferring scripts, restructuring a theme, or migrating hosts usually needs a developer.

Is my hosting making my website slow?

Look at the server response time in PageSpeed Insights or the time to first byte in any speed test. If it is consistently above about 600 milliseconds, hosting or missing caching is a bottleneck regardless of anything else on the page. Turn on page caching first; if the number stays high, change hosts.

What is a good website loading speed?

Google's thresholds are the practical benchmark: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1, measured from real users. Under two seconds for LCP is where most sites see conversion gains flatten out.

Should I rebuild my website if it is slow?

Only if you have already done the cheap fixes and the theme or builder is still the source of the weight. If images, scripts, and hosting have been addressed and the site is still slow, the platform is generating the problem and patching will not hold. A rebuild is then usually cheaper over two years than repeated optimisation.