Why Is My Website So Slow? 9 Causes and How to Find Yours

What "slow" actually means

"My website is slow" can describe four different problems, and each one has a different fix. The server may take a long time to respond. The main content may take a long time to appear. The page may freeze when someone taps a button. Or the layout may jump around while it loads. Google measures these as Time to First Byte (TTFB), Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). TTFB is not one of the three Core Web Vitals, but it comes first and delays everything after it.

The Core Web Vitals checklist covers the three official metrics in depth. This guide is the step before it: working out which problem you actually have, so that you fix the right thing.

These thresholds are judged at the 75th percentile of real visits, so a page only passes when at least three out of four visitors get a good experience.

Find your cause in five minutes

Do these steps in order and do not change anything yet. The goal is to find out which of the nine causes below applies to you.

1. Run PageSpeed Insights on the slow page. Open pagespeed.web.dev, paste the address of the page that feels slow (not just your homepage) and open the Mobile tab. If the report shows real-user data at the top, read that first: it reflects real visitors over the last 28 days. The lab data below it comes from one simulated test.
2. Note which metric fails. A slow LCP, a slow INP, a poor CLS or a high TTFB each point to different causes. The lookup table later in this guide maps one to the other.
3. Open the Network tab. In Chrome, press F12, go to Network, tick Disable cache, set throttling to Slow 4G and reload. Sort by Size, then by Time. The top few rows are usually the answer.
4. Measure the server. Run the curl command below and look at the TTFB line.
5. Block the suspects. Right-click any third-party request in the Network tab, choose Block request URL and reload. If the page gets clearly faster, you have found a culprit.

curl -o /dev/null -s -w \
"DNS:     %{time_namelookup}s\n\
Connect: %{time_connect}s\n\
TLS:     %{time_appconnect}s\n\
TTFB:    %{time_starttransfer}s\n\
Total:   %{time_total}s\n" \
https://your-site.com/

Each value is measured from the start of the request, so TTFB already includes the DNS, connection and TLS time before it. Run the command three times and use the middle value, because a single run can be unlucky.

Causes 1–3: too much to download

1. Images that are far bigger than they need to be

Images are usually the heaviest thing on a page. The classic mistake is uploading a 4000-pixel photo straight from a camera or design tool and letting the browser shrink it to 400 pixels. The visitor still downloads every byte.

• Confirm it: in the Network tab, filter by Img and sort by size. Anything over a few hundred kilobytes deserves a look.
• Fix it: resize images to the largest size they are actually shown at, serve WebP or AVIF, use srcset so phones get smaller files, and lazy-load images below the fold. Never lazy-load the main image at the top of the page, because that is usually your LCP element.

The full process is in Image Optimization for the Modern Web.

2. Too much JavaScript

JavaScript costs more than an image of the same size. The browser has to download it, parse it, compile it and run it, and all of that happens on the main thread that also handles taps and scrolling. The typical symptom is a page that looks ready but reacts slowly (poor INP), or a site that feels fine on a laptop and sluggish on a phone.

• Confirm it: the Coverage tool shows how much of each script is never used on the page.
• Fix it: remove libraries you do not use, split code so each page loads only what it needs, load heavy widgets such as maps, editors and charts only when someone asks for them, and replace large dependencies with smaller ones or with features the browser already has.

The step-by-step version is in How to Cut JavaScript Bundle Size by 60%.

3. Text files that are not compressed

HTML, CSS, JavaScript, JSON and SVG are plain text, and they shrink a lot when compressed with Brotli or gzip. Most modern hosts and CDNs do this automatically, but a self-managed server often does not.

• Confirm it: run the command below. You should see br or gzip in the answer. If nothing comes back, the file is being sent uncompressed.
• Fix it: switch on Brotli (or at least gzip) in your server, host or CDN settings. Do not bother compressing images and video, because they are already compressed.

curl -s -o /dev/null -D - \
--compressed \
https://your-site.com/style.css \
| grep -i content-encoding

Causes 4–6: things that block or delay the page

4. Render-blocking CSS and scripts

When the browser finds a stylesheet in the <head>, it will not paint anything until that CSS has arrived. A plain <script> in the head is worse: it pauses the HTML parser while it downloads and runs. Stack several of these and visitors stare at a blank screen.

• Confirm it: PageSpeed Insights lists render-blocking requests in its diagnostics, and the Network waterfall shows a long gap before the first paint.
• Fix it: keep CSS small and avoid chains of @import, inline the little CSS needed for the top of the page, and add defer to scripts that do not need to run before the page is parsed. defer keeps scripts in order; async runs them the moment they arrive, in any order.

How the browser turns code into pixels is explained in Browser Rendering Explained.

5. Third-party scripts

Analytics, tag managers, chat widgets, ad networks, social embeds, A/B testing tools and cookie banners each add downloads from other servers and run more code on the same busy main thread. One tag manager entry can quietly pull in several more scripts. Third-party code is one of the most common reasons a fast site turns slow after "just adding one thing".

• Confirm it: in the Network tab, tick the 3rd-party requests filter, then use Block request URL from step 5 to see how much each one costs.
• Fix it: remove anything nobody looks at, load chat and video embeds only when the visitor clicks them, and load non-essential scripts after the page has become interactive.

6. Web fonts

A custom font is a file the browser must download before it can show text in that font. Loading six weights from two families is common and costly. If the text stays invisible while the font loads, visitors think the page is broken. If the font swaps in late, the layout can jump.

• Confirm it: filter the Network tab by Font and count the files.
• Fix it: use one or two families and only the weights you need, serve WOFF2 files, add font-display: swap so text appears immediately, and preload the font used above the fold. System fonts are the fastest option of all.

Causes 7–9: the server and your setup

7. A slow server response

Everything else waits for the first response. Google's web.dev guidance suggests a TTFB of 0.8 seconds or less for most sites, and treats anything above 1.8 seconds as poor. TTFB is not a Core Web Vital itself, but it adds straight onto LCP.

The usual causes are cheap or overloaded shared hosting, pages that are built from scratch on every visit because there is no page cache, slow database queries, a server far away from your visitors, a serverless function waking up from a cold start, and redirect chains such as http to https to www, where each hop costs a full round trip.

• Confirm it: use the curl timing command from earlier, then check for redirect hops with the command below. Ideally you see one 200 and no location lines.
• Fix it: turn on full-page caching, put a CDN in front, make every internal link point straight at the final address, or generate pages ahead of time as static HTML.

curl -sIL https://your-site.com/ \
| grep -iE "^(HTTP|location)"

8. No caching and no CDN

Without caching headers, returning visitors download the same logo, stylesheet and script on every page. Without a CDN, every visitor fetches everything from one location, however far away they are.

• Confirm it: reload a page in the Network tab with Disable cache turned off. Files that were already downloaded should show disk cache or memory cache in the Size column. If everything downloads again, caching is missing.
• Fix it: give versioned CSS, JavaScript and images a long cache lifetime, keep HTML on short or revalidated caching, and serve the site through a CDN.

Header values and CDN trade-offs are covered in Caching and CDN Strategies.

9. Too many plugins or a heavy theme

On WordPress and similar platforms, each plugin can add its own CSS and JavaScript to every page, whether that page needs it or not. Multipurpose themes and page builders also ship large amounts of code for features you may never use.

• Confirm it: look at the file paths of the biggest CSS and JavaScript files in the Network tab. On WordPress the path shows which plugin or theme a file comes from.
• Fix it: on a staging copy, disable plugins one at a time and re-test, remove duplicates and anything unused, switch to a lightweight theme, and load plugin assets only on the pages that use them.

Symptom to cause: a quick lookup

If you already know what the slowness looks like, this table narrows it down. The numbers refer to the causes above.

Fix them in this order

Once you know your causes, work through them from the biggest payoff to the smallest:

1. Images. The biggest saving for the least risk.
2. Third-party scripts. Remove what you do not need before you optimise what you do.
3. JavaScript and render-blocking files. Defer, split and delete.
4. Compression, caching and a CDN. Set once, benefits every visit.
5. Server and hosting. Only if TTFB is still high after the steps above.
6. Fonts and finishing touches. Small gains that add up.

Check that the fix actually worked

Run PageSpeed Insights on the same page, on mobile, after every change. Lab scores can move a few points between runs even when nothing changed, because the test is not perfectly repeatable. Compare the specific numbers that should have improved, such as LCP in seconds or the size of the page, and run the test a few times before trusting a result.

The real judge is field data. Search Console's Core Web Vitals report and the real-user section of PageSpeed Insights use a rolling 28-day window, so a fix appears gradually over a few weeks. The "Measure like a skeptic" section of the Core Web Vitals checklist explains the difference between lab and field data in more detail.

Most slow websites do not need a rewrite. They need someone to look at the waterfall chart.

Keep a simple log: the date, the change, and the before and after numbers for LCP, TTFB and total page weight. That log is worth more than any single score, and it shows you which fixes were worth the effort.

When the honest answer is your hosting

Sometimes every fix on the page helps a little and the site still feels slow. Test the server on its own: upload a plain HTML file with a few lines of text to the same host and time it with curl. If even that file has a high TTFB, the bottleneck is the host, the network path or the server configuration, not your page.

The options are page caching, a CDN in front of the host, a better plan, or moving to static or pre-rendered pages that a CDN can serve directly. The trade-offs between a cheap server and serverless hosting are broken down in Self-Hosting vs Serverless.

What to do this week

1. Run PageSpeed Insights on your three most important pages and write down LCP, INP, CLS and TTFB for each.
2. Sort the Network tab by size and fix the three biggest files.
3. Block your third-party scripts one at a time and remove the ones you do not need.
4. Re-test, write down the new numbers, and only then move on to caching and the server.

---

A slow website feels like a mystery until you measure it. Once you know whether the problem is the server, the weight of the page or the code running on it, the fix is almost always one of the nine above. When the basics are done, the Core Web Vitals checklist is the next step for fine-tuning LCP, INP and CLS.

Frequently asked questions