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

> A slow website almost always comes down to a slow server, heavy images, render-blocking files, too much JavaScript or layout shifts. How to tell which one you have from a speed test, and the fix for each.

Updated 2026-09-26 · Speed & Core Web Vitals · HTML version: https://getreport.app/guides/why-is-my-website-slow

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](https://getreport.app/guides/page-speed).

## 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](https://getreport.app/tools/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.

> **Free tool:** [Free website speed test and page speed check](https://getreport.app/tools/speed-test): Free website speed test for any page: Lighthouse lab results and real-user Core Web Vitals on mobile and desktop, with a fix for each slow part. No sign-up.

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](https://getreport.app/guides/reading-a-website-speed-test) explains every number if you want the detail.

## The symptoms, and what they point to

| What you see in the test | Most likely cause | Section |
| --- | --- | --- |
| Time to first byte over 0.8 s | Slow server, no page cache, redirects | Cause 1 |
| TTFB fine, LCP element is a large image | Hero image too big, lazy-loaded or found late | Cause 2 |
| TTFB fine, nothing on screen for a while (late FCP) | Render-blocking CSS, JavaScript or fonts | Cause 3 |
| High Total Blocking Time, poor INP | Too much JavaScript, often third-party | Cause 4 |
| CLS over 0.1 | Images, ads, banners or fonts without reserved space | Cause 5 |
| Different results every run | Cache expiring, background jobs, overloaded server | Slow only sometimes |
| Fast nearby, slow abroad | Distance to the server | Slow only for some visitors |

## 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.

> **Free tool:** [TTFB test: check your time to first byte](https://getreport.app/tools/ttfb-test): Free TTFB test: measure time to first byte from Frankfurt, in a Lighthouse run and from real Chrome users, plus the redirects before the page. No sign-up.

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.

> **Check: Server response time.** Lighthouse flags a first byte slower than 600 ms. Caching and hosting fix this for most CMS sites.
>
> 1. Enable full-page caching (WordPress: WP Rocket, LiteSpeed Cache, WP Super Cache; or your host's server cache).
> 2. Use a CDN and keep database queries out of the request path.

> **Check: No redirects before the page.** Every redirect is a full round trip before the browser can even ask for the page. http → https → www → trailing slash can easily add a second on mobile.
>
> 1. Link straight to the final URL everywhere (menus, ads, social profiles).
> 2. Collapse chains: redirect http and non-www directly to the final https URL in one hop.

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

> **Free tool:** [Web hosting speed test: is your host slow?](https://getreport.app/tools/hosting-speed-check): Free web hosting speed test: see who hosts a site, how fast its server sends the first byte, and how that compares with other sites on the same host.

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](https://getreport.app/guides/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.

> **Free tool:** [Image size checker: find heavy images on a page](https://getreport.app/tools/image-size-checker): Free image size checker: list every image on a page with file size, format, real and displayed dimensions, and find the heavy files that slow it down.

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.

> **Check: Heavy image files.** A single image over a few hundred kilobytes takes longer to download on mobile than the rest of the page. Uploading the original camera file is the usual cause.
>
> 1. Export each listed image at the size it is displayed and save it as WebP or AVIF at about 80 % quality.
> 2. Let your CMS or CDN resize on upload so this does not come back with the next photo.

> **Check: Images are sized for how they are displayed.** Sending a 2000 px photo to a 400 px slot wastes most of the bytes. Responsive images let the browser pick the right size for each screen.
>
> 1. Add srcset and sizes to <img> so phones get small versions; most CMSs generate the sizes for you.
> 2. Resize the originals to the largest size you actually display.

**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](https://getreport.app/guides/image-optimization) 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.

> **Check: No render-blocking resources delay the first paint.** Stylesheets and scripts in <head> stop the browser from drawing anything until they have downloaded. Each one adds a round trip before the visitor sees the page.
>
> 1. Add defer or async to scripts that are not needed before the first paint, or move them to the end of <body>.
> 2. Inline the CSS needed for the first screen and load the rest asynchronously (WordPress: "Optimize CSS delivery" in WP Rocket / LiteSpeed Cache).
> 3. Remove unused plugin CSS/JS from pages that do not need it.

> **Check: First Contentful Paint.** FCP is when the first text or image appears. Until then visitors see a blank page and cannot tell whether the site is working.
>
> 1. Speed up the server response and remove redirects before the page.
> 2. Inline critical CSS and defer the rest; drop render-blocking scripts from <head>.
> 3. Serve the HTML compressed (Brotli or gzip) from a CDN close to your visitors.

**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](https://getreport.app/guides/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.

> **Check: Third-party code weight.** Tags, widgets and embeds from other companies run on your visitors' phones at your page's expense. Over 250 KB or 250 ms of blocking is a sign they dominate the load.
>
> 1. List what each third party gives you; remove the ones nobody looks at.
> 2. Load the rest after interaction or with a facade (a static thumbnail for YouTube, a click-to-load chat button).
> 3. Move tags into a tag manager that fires them late, not in <head>.

> **Check: No long main-thread tasks block interaction.** A task longer than 50 ms freezes the page for that long. Several in a row are what makes a site feel unresponsive to taps and scrolls.
>
> 1. Find the scripts behind the longest tasks (listed below) and defer, split or remove them.
> 2. Yield to the browser between chunks of work (setTimeout, scheduler.yield, requestIdleCallback).

> **Free tool:** [Find and remove unused CSS and JavaScript](https://getreport.app/tools/unused-code): Find the unused CSS and JavaScript to remove, file by file, with real Chromium coverage, third parties marked and Google's estimate of the time saved. Free.

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](https://getreport.app/guides/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.

> **Check: Cumulative Layout Shift.** CLS measures how much the page jumps around while loading — the button that moves just as someone taps it. It is one of Google's three Core Web Vitals.
>
> 1. Give every <img>, <video>, ad slot and embed explicit width and height (or aspect-ratio) so space is reserved before it loads.
> 2. Preload the main web font and use font-display optional, or swap with a size-adjusted fallback font, so text does not reflow.
> 3. Never insert banners or content above existing content after load.

**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](https://getreport.app/guides/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.

> **Check: Text files are compressed.** HTML, CSS and JavaScript shrink by 70–90 % with Brotli or gzip. Without it every visitor downloads several times more than needed.
>
> 1. Turn on Brotli or gzip on the server or CDN (Cloudflare does it automatically; Apache mod_deflate/brotli; nginx gzip on).
> 2. Check that your CDN or plugin is not serving already-compressed assets without the Content-Encoding header.

> **Check: Static files have long cache lifetimes.** Images, fonts, CSS and JS rarely change, yet without a long Cache-Control lifetime returning visitors download them again on every page.
>
> 1. Set Cache-Control max-age of a year on versioned static files (most CDNs and caching plugins have a "browser caching" switch).
> 2. Add a version or hash to file names so you can still change them.

## 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](https://getreport.app/guides/speed-up-wordpress-site). On Shopify, the main levers are apps and images: see [Shopify speed optimization](https://getreport.app/guides/shopify-speed-optimization). To know when you are done, [what a good page load time is](https://getreport.app/guides/what-is-a-good-page-load-time) lists the targets, and [how important page speed is for SEO](https://getreport.app/guides/page-speed-and-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.