Why is my website slow to load? Usually one of three reasons
If you are asking "why is my website slow to load?", the answer is usually one of three things: the server takes too long to start sending the page, the page asks the browser to download and run too much, or third-party widgets such as chat, booking, and review embeds add work you do not control. Hosting is only one of the three, so upgrading it is not always the fix.
Before changing anything, confirm that real visitors have the problem, find which of the three costs the most time, and check what your platform lets you change.
First, check whether it is slow for everyone
A site can feel slow on your office computer for reasons a customer never sees, and vice versa. Start with quick comparisons:
- Open the site on your phone with Wi-Fi off, then on a laptop on another network, in a private window so extensions and saved data do not change the result.
- Log out of your website editor. Being signed in can load tools and skip settings that ordinary visitors get.
- Note which pages are slow; different pages can have different causes.
If it is slow on only one device or network, suspect that device or connection.
Run a website speed test that answers the right question
Speed tools report two kinds of data: field data from real Chrome users who visited your pages, and lab data from one simulated visit run on demand. Google's guidance on lab and field data (opens in a new tab) is plain: use field data to decide what to prioritize and lab data to debug.
Test the pages customers use. Run PageSpeed Insights (opens in a new tab) on your homepage, main service page, and contact page.
Read the field data first. PageSpeed Insights reports (opens in a new tab) real-user data from the previous 28 days, for mobile and desktop separately. A page with too little data of its own falls back to data for the whole site.
Then read the lab test. The same documentation says the mobile lab run simulates a mid-tier phone on a mobile network. Use it to find what is slow; one poor lab score is not proof that customers are waiting.
Repeat and record. Google's PageSpeed Insights FAQ (opens in a new tab) notes that results vary from run to run. Run each page three times, go by the typical result, and record the page, the date, and the three Core Web Vitals below so you can compare after each fix.
Core Web Vitals explained
Google's Core Web Vitals (opens in a new tab) are three measurements of real-visitor experience, judged at the 75th percentile of visits, with mobile and desktop counted separately. The Search Console Core Web Vitals report (opens in a new tab) uses these bands:
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | When the main content appears | 2.5 s or less | Up to 4 s | Over 4 s |
| Interaction to Next Paint (INP) | How quickly the page responds to taps and clicks | 200 ms or less | Up to 500 ms | Over 500 ms |
| Cumulative Layout Shift (CLS) | How much the layout jumps while loading | 0.1 or less | Up to 0.25 | Over 0.25 |
INP replaced First Input Delay (opens in a new tab) as a Core Web Vital in March 2024. A guide or report that still tells you to fix "FID" is out of date. The small business website audit uses the same thresholds for its yearly speed check.
Why a small site often shows "No data available"
Many small sites have no Core Web Vitals data in Search Console, and that is normal. The report draws on the Chrome UX Report, and the CrUX methodology (opens in a new tab) only includes pages and sites that are publicly discoverable and "sufficiently popular," a visit threshold Google does not publish. Only desktop and Android Chrome users with usage reporting and sync turned on contribute; Chrome on iPhone does not. Rely on repeated lab tests and a real phone instead.
Three common causes of a slow website
A slow server response
Time to First Byte (TTFB) is how long the browser waits before the first part of the page arrives. It includes redirects, the DNS lookup, the secure connection, and the server's own work. Google's TTFB guidance (opens in a new tab) treats 0.8 seconds or less as good. TTFB is not a Core Web Vital, but every other step waits for it.
Signs: every page sits blank for a moment, and the lab report shows a long server response. Common causes are an overloaded hosting plan, pages built from scratch on every visit instead of cached, and redirect chains, such as an old address that redirects twice. This is the one cause where better hosting or caching is the right first move.
A heavy page, and a late start
Large images, sliders, background video, several font families, and page-builder code all add weight. Compressing images helps, but it is often not the main delay. Google's LCP guide (opens in a new tab) splits the time to show the main content into four parts: server response, the delay before the main image starts downloading, the download itself, and the time to draw it.
A 2024 web.dev analysis of Chrome field data (opens in a new tab) for sites with poor LCP and an image as the main element found that image download time was "almost never the bottleneck." The median site in that group waited almost four times as long to start downloading the image as it spent downloading it. Common reasons are a hero image that a script inserts late, a top-of-page image set to load lazily, or a slider that waits for its code before showing anything.
Third-party widgets
Chat bubbles, booking tools, review carousels, embedded maps, video players, social feeds, and marketing tags all load code from someone else's servers. Google's third-party JavaScript guide (opens in a new tab) notes that these scripts are usually outside your control and can delay the rest of the page when they load the wrong way. They are also a common cause of sluggish taps and clicks, which show up in INP.
To test one, compare a page with and without it on a copy of the site or in a preview. If the difference is noticeable, decide whether the widget is worth that cost to every visitor, or load it only where it is needed.
A diagnosis path for a slow website
Work down the table and stop at the first step that clearly explains the problem. Fix that, then test again.
| Step | What to check | What you might see | What it points to | Who can usually change it |
|---|---|---|---|---|
| 1 | The site on another device and network, logged out | Slow only on one device or network | A local problem, not the website | You |
| 2 | Field data in PageSpeed Insights or Search Console | Poor LCP, INP, or CLS, or no field data | A real problem to prioritize; with no field data, use repeated lab tests | Depends on the cause |
| 3 | Server response in a lab test | Long wait before anything arrives | Hosting, caching, or redirect chains | Host or developer |
| 4 | When the main image or headline appears | Main image starts late or is very large | Late discovery, lazy loading, or image size | Designer or developer; on builders, you |
| 5 | Requests to other companies' domains | Chat, booking, reviews, video, or tags on every page | Third-party widgets | You decide; developer implements |
| 6 | Taps and clicks on a phone | Buttons or menus respond slowly | Heavy scripts, often third-party | Developer, or you by removing widgets |
| 7 | Page movement while loading | Text jumps as images, banners, or embeds appear | Missing image sizes or late-loading content | Designer or developer |
What your platform lets you change
What you can fix depends on who runs the server and the code. These are general patterns; check your platform's documentation.
| Platform type | What you usually control | What the platform or host controls | Sensible first move |
|---|---|---|---|
| Hosted website builder | Images, sections, embedded apps and widgets, fonts | Server, caching, core page code | Remove widgets you do not need; resize images |
| WordPress or another self-hosted system | Hosting plan, theme, plugins, caching, images | The hosting company's server | Measure server response, then cut plugins and scripts |
| Custom-built site | Nearly everything | The server, via the hosting provider | Ask your developer for the LCP breakdown and a plan |
Wix, for example, states that a Wix site must run on Wix's servers (opens in a new tab), so server tuning is out of your hands. Self-hosting gives you more control and more upkeep, including keeping plugins and themes from piling up. Before you change hosts, confirm who holds the hosting account and the domain; the website ownership audit shows how to check.
What a faster website will and will not do
Fix speed for the person on a phone trying to find your number or request a quote. Google recommends good Core Web Vitals (opens in a new tab) and says they align with what its ranking systems reward, but its page experience guidance (opens in a new tab) says good scores do not mean your pages will rank at the top, and that Google shows the most relevant content even when page experience is weaker. A faster site removes friction; it does not replace clear service pages, accurate business details, or the other work in AI SEO for small businesses.
When to tune and when to rebuild
Tuning makes sense when one or two causes explain the delay: a hosting plan that is too small, a slider at the top of the homepage, or three widgets loading on every page. A rebuild deserves a look when the slow parts are built into the theme or page builder, when every fix breaks something else, or when the site needs other work anyway.
If you lean toward a redesign, first write down what the current site does well; the redesign preparation checklist covers what to bring, and how to choose a web designer lists the questions to ask before you hire anyone. If the diagnosis points to the build itself, Cleland & Co. offers website design and care for small businesses; bring what you measured.
