Why is my website slow? 15 causes and how to check

The usual reasons a website is slow, how to tell which one is yours, and what fixes each. Start with where the delay is: before, during or after loading.

In this guide

First, find where the delay is
1. Hosting that cannot keep up
2. No caching
3. Visitors are far from the server
4. Redirects before the page
5. Images that are too big
6. The main image is found late or loaded lazily
7. Too much JavaScript
8. Third-party scripts
9. Files that block the page
10. Web fonts
11. Layout shifts
12. A heavy theme, page builder or too many plugins
13. Sliders, autoplay video and animations
14. A slow back end, or a page that is too large to update
15. The visitor's device and connection
A short, safe order of work
What it is usually not
Check your own page
Sources

First, find where the delay is

"Slow" means different things, and each has different causes. Open your page on a phone and watch it load, then ask which of these describes it.

What you see	Where the delay is	Most likely causes
A blank screen for a long time	Before anything is drawn	1, 2, 3, 4, 9
Text first, images arrive late	While the page fills in	5, 6, 10
The page looks ready but taps do nothing	After the page appears	7, 8, 12, 14
Things jump around as it loads	Visual stability	10, 11, 13
Fast on your computer, slow for customers	Their devices and networks	15, and all the above
Slow only when you are logged in	The server's work for each visit	1, 2, 12, 14

Then check the numbers. In PageSpeed Insights, look at the real-visitor result for mobile first, and note which of the three Core Web Vitals fails. How to read a speed report shows how. The numbers tell you whether the problem is loading, responsiveness or stability, and that cuts the list of suspects in half.

1. Hosting that cannot keep up

How it shows up. A long wait for the first byte on every page, worse at busy times, with the same delay however small the page is. How to check. The report's server response time or Time to First Byte. Lighthouse flags a server that takes over 600 milliseconds to respond. Test at different times of day. What fixes it. A better plan or host, with resources that are not shared and a current software stack. See choosing hosting for speed.

2. No caching

How it shows up. A slow first byte on a site that is otherwise simple, and a server that does the same work for every visitor. On WordPress, this is the most common cause of a slow start. How to check. Reload twice and compare the response time. Check the response headers for a cache hit. Look at the report's cache lifetime insight for files that are downloaded again on every visit. What fixes it. A page cache, an object cache for dynamic sites, and cache headers on static files. See caching explained.

3. Visitors are far from the server

How it shows up. Fast for you, slow for visitors in another country, with a long wait before the first byte. How to check. Test from a location near your visitors, if your tool allows it. What fixes it. A CDN that keeps copies of your pages and files near visitors, or hosting in the region where most of them are.

4. Redirects before the page

How it shows up. An extra wait before anything starts, often after clicking a link from an email, an ad or an old address. How to check. The Lighthouse insight for the page request lists redirects and what they cost. In DevTools, the Network panel shows each redirect as its own request. What fixes it. Link to the final address directly: the right protocol, the right version of the domain and the trailing slash. Clean up old chains.

5. Images that are too big

How it shows up. The page weighs several megabytes (see page weight and requests), and images are the biggest part. On slow connections, pictures pop in one by one. How to check. The report's image findings list files that could be smaller, with the size they are and the size they need to be. In DevTools, sort requests by size. What fixes it. Resize images to the size they are shown at, convert to WebP or AVIF, and compress. See image optimization.

6. The main image is found late or loaded lazily

How it shows up. Text appears, and then the big picture at the top arrives seconds later, though the file is not especially large. How to check. The LCP breakdown and the "LCP request discovery" insight in the report. What fixes it. A normal image tag for the main picture, no lazy loading on it, and high priority for that one image. See how to fix a slow LCP.

7. Too much JavaScript

How it shows up. A page that appears and then freezes for a moment, with buttons and menus that respond late. The test shows a high Total Blocking Time. How to check. The report's JavaScript findings and the main-thread work. In DevTools, record the load and look for long tasks. What fixes it. Remove code that is not used, split large bundles and load scripts only where they are needed. See Total Blocking Time.

8. Third-party scripts

How it shows up. The same symptoms as too much JavaScript, plus requests to many other domains. Chat widgets, ads, analytics, tag managers and social buttons are the usual cause. How to check. The "3rd parties" insight lists them by company with the time each one used. What fixes it. Remove what nobody uses, load the rest later and put a click-to-load placeholder in front of heavy tools. See third-party scripts.

9. Files that block the page

How it shows up. A blank screen even though the server answered quickly. Large stylesheets and scripts in the head hold the first paint back. How to check. The "render-blocking requests" insight in the report. What fixes it. Defer scripts, inline the CSS the first screen needs and load the rest later. See critical CSS and render-blocking resources.

10. Web fonts

How it shows up. Text that is invisible for a moment, or that changes size when the font arrives and moves the page. How to check. The "font display" insight, and the font files in the request list. What fixes it. Fewer fonts and weights, WOFF2 files, a display setting that shows text at once, and a fallback font with the same proportions. See web fonts and speed.

11. Layout shifts

How it shows up. The page jumps while you read it or go to tap something. It feels slow and clumsy even when it loads fast. How to check. The cumulative layout shift number and the layout shift culprits in the report. What fixes it. Set the size of images, videos and embeds, reserve room for banners and late content. See how to fix layout shift.

12. A heavy theme, page builder or too many plugins

How it shows up. A WordPress or similar site where every page is heavy, even simple ones. The same scripts and styles load everywhere. How to check. Switch temporarily to a default theme on a copy of the site, and test again. Switch plugins off one at a time. What fixes it. A lighter theme, simpler pages, and plugins that load their code only where they are used. See how to speed up a WordPress website.

13. Sliders, autoplay video and animations

How it shows up. A large moving element at the top of the page, which is also the largest thing on screen. It delays the main content, loads a lot of data and can make the page jump. How to check. The report names the largest element. If it is a slider image or a video poster, that is it. What fixes it. A single static image at the top, a small poster for a video and no autoplay on phones.

14. A slow back end, or a page that is too large to update

How it shows up. A dynamic site is slow to start even with a cache, or slow to respond after loading because the page contains thousands of elements and every change forces a lot of work. How to check. Server timing on the response, the number of database queries per page, and the size of the page structure that the report lists. What fixes it. Faster queries, an object cache, a smaller page, and rendering long lists only as far as the visitor has scrolled.

15. The visitor's device and connection

How it shows up. A page that is fine on a new laptop on office wifi and poor on an older phone in a car. You cannot control this, and the real-visitor data reflects it. How to check. Compare the real-visitor numbers with the lab test, and slow the test down in DevTools. See lab data versus field data. What fixes it. Design for the weakest common device: less JavaScript, smaller images and a lighter page. Everything above helps most for exactly these visitors.

A short, safe order of work

If you do not know where to start, this order is right for most sites. It is the same order as in which problems to fix first:

Make the server answer quickly: cache, CDN, hosting.
Fix the main image: found early, the right size, not lazy-loaded.
Remove scripts and tags you do not use.
Set sizes on images and reserve room for anything that appears late.
Defer scripts and unblock the first paint.
Tidy fonts.

After each change, test again, and keep the old numbers to compare.

What it is usually not

Your content. More pages do not make a site slow. Heavy pages do.
One plugin, in general. It is a specific plugin's code that costs, not the idea of having plugins.
Your internet connection, if the problem shows in real-visitor data.
A lab score of 62, by itself. The score is a summary. The cause is somewhere in the list above.

If the site feels fast on your computer and slow on phones, read why a site is slow on phones but fast on a computer.

Check your own page

Run the free audit on the page that feels slow, on mobile. Match what the report shows with the table at the top of this guide, find the one or two causes that fit, and fix those first. The audit's list will point to the same causes in more detail.

Sources

Web Vitals on web.dev: the three numbers that describe loading, responsiveness and stability.
Optimize Time to First Byte on web.dev: server, CDN and cache causes.
Optimize Largest Contentful Paint on web.dev: where loading time goes.
Performance chapter of the 2025 Web Almanac: how real sites perform today.