Why is my website slow? How to find the cause and fix it

Your website is slow because of one of five things, and usually two of them together: the server takes too long to answer, the images are too large, CSS and JavaScript block the page from drawing, scripts (often from third parties) keep the phone's processor busy, or content jumps as it loads. A speed test tells you which, because each cause leaves a different pattern in the numbers. Fix the one that costs the most seconds first.

This guide is for site owners who have heard "the website is slow" from customers, a colleague or their own phone. It starts with a quick check for the case where it is your connection, not the site, then shows how to read the symptoms, and what fixes each cause. For the full picture of page speed and every fix in order, see the page speed guide.

Quick answer

• Only slow for you, and every site is slow? It is your connection, device or browser, not your website.
• High time to first byte (over 0.8 s): the server. Page caching, fewer redirects, better hosting.
• Fast first byte, late main content: the hero image or render-blocking CSS and JavaScript.
• Page appears but reacts late to taps: too much JavaScript, usually third-party scripts.
• Content jumps while loading: images, ads, banners or fonts without reserved space.
• Slow only sometimes: a cache that expires, background jobs or an overloaded shared server.
• Find out which with the free website speed test, on mobile, for more than one page.

First: is it the website or your connection?

If every site feels slow, including big ones, the problem is on your side. Websites loading slowly while a speed test of your internet shows plenty of bandwidth is common, because loading a page depends more on latency and on your device than on download speed. Things to try:

1. Another network. Switch from Wi-Fi to mobile data. A weak Wi-Fi signal or a busy router slows every page, even on a fast line.
2. A private window. Extensions such as ad blockers, password managers and shopping helpers run on every page. If a private window is faster, disable extensions one at a time.
3. VPN, proxy or antivirus web protection off. They route or inspect every request and can add seconds.
4. DNS. A slow DNS resolver delays the first request to every site. Your router or operating system lets you use a public resolver instead.
5. Restart the router and the device, and update the browser.

If only your own website is slow, and other sites are fine on the same connection, read on: the cause is on the site. It may still look faster to you than to your visitors, because your browser has cached its files and your laptop is faster than a mid-range phone.

Measure before you guess

Test the pages visitors use, not only the home page: one product or service page, one article, and one category or listing page. Test on the mobile profile, which is where most sites are slowest.

The speed test runs Lighthouse through Google's PageSpeed Insights on a throttled phone and on desktop, and shows the Core Web Vitals of real Chrome visitors beside it where Google has them. Every finding names the file responsible and what it costs. Run each page two or three times, because single runs vary, and keep the report links to compare later.

Then match what you see to one of the causes below. The guide on how to read a website speed test explains every number if you want the detail.

The symptoms, and what they point to

Cause 1: the server is slow

Everything waits for the first byte from the server. If that alone takes a second or more, no front-end fix can make the page fast. Typical reasons: a CMS such as WordPress building every page from the database with no page cache, an overloaded shared hosting plan, a slow plugin or database query, and redirect chains (http → https → www → trailing slash), each costing a full round trip.

The TTFB test measures the first byte from our test location in Frankfurt with a fresh connection, lists each redirect hop, and shows Lighthouse's server response time and real-visitor TTFB beside it. Test a page that should be cached, three times: consistently slow means no cache or a slow server; slow once, then fast means a cold cache.

To tell whether the host or your site is the problem:

It names the host behind the site and, once a host has enough sites in our data, compares your first byte with the median of other sites on the same host. Much slower than the host's other sites means something on your site; typical and still slow means the host.

Fix: turn on full-page caching, point links at the final URL so there are no redirect hops, and use a CDN for visitors far away. Only then consider better hosting. TTFB: what a slow server looks like covers each step.

Cause 2: images are too heavy

Images are the heaviest part of most pages, and the largest one at the top is usually the Largest Contentful Paint (LCP) element: the moment visitors consider the page loaded. A photo uploaded straight from a camera or stock site can be several megabytes. Often it is also lazy-loaded by a theme or plugin, which tells the browser to fetch it late.

The image size checker lists every image on the page with its file size, format, real and displayed dimensions, and flags files over 300 KB, images more than twice their displayed size and images without dimensions.

Fix: resize images to about twice the size they are shown at, save photos as WebP or AVIF, never lazy-load the image at the top, and add fetchpriority="high" to it. The image optimization guide covers the rest.

Cause 3: CSS and JavaScript block the page

Before drawing anything, the browser must download and process every stylesheet and every ordinary <script> in the page's <head>. Themes, page builders and plugins often put many there, including code for features the page does not use. The result is a blank screen with a fast server: a good TTFB and a late First Contentful Paint.

Fix: add defer to scripts not needed for the first screen, load plugin CSS only on pages that use it, and self-host fonts with font-display: swap. Render-blocking resources shows how on plain HTML, WordPress and Shopify.

Cause 4: too much JavaScript

JavaScript is expensive twice: it must be downloaded, and then the phone's processor must run it. While it runs, the page cannot respond to taps, which is what a poor Interaction to Next Paint (INP) and a high Total Blocking Time mean. Much of it is often third-party: tag managers, chat widgets, A/B testing, heatmaps, ad and social scripts, each added for a reason and rarely removed.

The unused code tool loads the page in Chromium with code coverage switched on and shows, file by file, how much of each script and stylesheet the page actually used, with third parties marked. A script that is 80 % unused on every page is a candidate for splitting or removing.

Fix: list every third-party script and what it gives you, remove what nobody uses, and load the rest later or on interaction (a chat button that loads the widget when tapped, a video thumbnail instead of an embedded player). See third-party scripts: tag managers, chat and ads.

Cause 5: the page jumps while loading

A page that shifts as images, ads, cookie banners or fonts arrive feels slow and broken even when it loads quickly: people tap the wrong thing or lose their place. It shows as a Cumulative Layout Shift (CLS) over 0.1.

Fix: give images and videos width and height, reserve space for ads and embeds, show cookie banners as an overlay instead of pushing the page down, and match your fallback font to the web font. Fix Cumulative Layout Shift has the CSS.

Slow only sometimes

When the same page is fast one minute and slow the next, look at what changes between visits:

• The page cache expired or was cleared, and the next visitor waits while the page is rebuilt. Longer cache lifetimes and cache preloading help.
• Background jobs run during a visitor's request, such as WordPress's wp-cron, backups or imports. Move them to a real scheduled task.
• Shared hosting neighbours use the same processor. Slow times at busy hours point to the plan.
• Traffic spikes from a campaign or newsletter overload an uncached server.

Test at different times of day and compare. If a site got slow after a specific change, such as a plugin, a theme update or a new tag, undo it on a staging copy and test again.

Slow only for some visitors

• Visitors far from the server pay for distance on every round trip. A CDN serves files, and with the right rules whole pages, from nearby.
• Visitors on phones have slower processors and networks than your office laptop; that is why the mobile test is the one to trust.
• Logged-in users often bypass the page cache, so the site feels slower to editors than to visitors. Test logged out.

Compression and caching matter here too: text files should be compressed with Brotli or gzip, and static files cached by the browser so repeat visits are fast.

How to fix a slow website, in order

1. Server first: page caching, no redirect chains, then hosting.
2. The LCP image: resized, modern format, not lazy-loaded.
3. Render-blocking CSS and JavaScript: defer, remove what is unused.
4. Third-party scripts: remove or delay.
5. Layout shifts: reserve space.
6. Measure again after each change, and check the real-visitor numbers after about four weeks.

On WordPress, the same order applies with platform-specific settings: see how to speed up a WordPress site. On Shopify, the main levers are apps and images: see Shopify speed optimization. To know when you are done, what a good page load time is lists the targets, and how important page speed is for SEO explains what a faster site means for search.

Common mistakes

• Judging from your own computer. A cached site on a fast laptop hides what a first-time visitor on a phone sees.
• Testing only the home page. The slow template is often a product or article page.
• Installing an optimisation plugin before measuring. You will not know what it fixed, or what it broke.
• Upgrading hosting first. An uncached site is slow on any plan.
• Changing many things at once. One change, one re-test.

Questions people ask

How do I fix a slow website?

Find the cause before fixing anything: run a speed test on your main pages on mobile and look at which number is worst. A slow first byte needs page caching or better hosting; a late main image needs resizing and must not be lazy-loaded; a late first paint needs render-blocking CSS and JavaScript deferred; poor responsiveness needs fewer scripts. Fix one thing at a time and re-test after each.

Why is my website slow for visitors but fast for me?

Because your browser has already cached the site's files, your computer is probably faster than your visitors' phones, and you may be close to the server or on a fast office connection. If you are logged in to your CMS, you may also be seeing an uncached version. Test in a private window on a phone profile, and check the real-visitor data in a speed test for the true picture.

Why are all websites slow when my internet speed test is fast?

Because loading a page depends on latency, Wi-Fi quality, DNS and your device, not only on bandwidth. A fast line with weak Wi-Fi, a slow DNS resolver, a VPN or antivirus inspecting traffic, or browser extensions can make every site slow. Try another network, a private window and switching off the VPN; if the problem stays with one site only, the cause is that website.

Can too many plugins or apps make a website slow?

Yes, when they load code on every page. Each plugin or app that adds scripts, stylesheets or requests to the front end costs download and processing time, and the heaviest ones can double a page's weight. The number matters less than what each one loads: measure per plugin, remove what nobody uses, and restrict the rest to the pages that need them.

Why did my website suddenly become slow?

Something changed: a plugin, theme or app update, a new tracking script, a larger image on the home page, a traffic spike, an expired cache, or a problem at the host. Compare a speed test with an earlier report if you have one, check what was changed and when, and look at the hosting provider's status page. Undo recent changes on a staging copy to confirm the cause.