Most slow websites are slow for one of four reasons: the server takes too long to send the first byte, images are far bigger than they need to be, too much JavaScript has to download and run, or third-party scripts such as chat widgets and trackers compete for the connection. Measure first, then fix the biggest bottleneck before anything else.
This guide shows how to find which of those is hurting your site, what "slow" actually means in numbers, and the fixes that make the biggest difference for the least effort.
Key takeaways
- Most slow websites are caused by slow server response, oversized images, too much JavaScript or third-party scripts.
- A TTFB over 0.8 seconds points to the server, so fix caching, hosting or a CDN before any image work.
- Aim for LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less at the 75th percentile.
- Fix server response first, then the largest image on each key page, then unused plugins and third-party scripts.
How do I find out why my website is slow?
Guessing wastes time. A ten-minute diagnosis will tell you where the delay sits.
- Run PageSpeed Insights on your home page and one key page (a product, service or contact page). Look at the field data at the top first. It comes from real Chrome users over the previous 28 days. The lab report below it is a simulated test that helps you debug.
- Check Time to First Byte (TTFB). Google's guidance is that 0.8 seconds or less is good and anything over 1.8 seconds is poor. A high TTFB means the problem is the server, not the page.
- Read the Largest Contentful Paint (LCP) breakdown in the Lighthouse report. It splits LCP into server time, load delay, download time and render delay, so you can see which phase is eating the time.
- Open Chrome DevTools, go to the Network tab, tick "Disable cache" and reload. Sort by size. The biggest files are usually images or JavaScript bundles.
- Count the domains. In the Network tab, look at how many requests go to other companies' servers. Each one is a third-party script you are paying for in speed.
If you would rather see everything in one report, MakeItFlow can run a free website audit that includes PageSpeed and Core Web Vitals results alongside SEO and security checks.
What counts as "slow"?
Google's Core Web Vitals give you three targets, measured at the 75th percentile of real visits:
| Metric | What it measures | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | When the main content appears | 2.5 s or less |
| Interaction to Next Paint (INP) | How quickly the page responds to taps and clicks | 200 ms or less |
| Cumulative Layout Shift (CLS) | How much the page jumps around | 0.1 or less |
If your LCP is above 2.5 seconds for a quarter or more of visitors, visitors are finding the site slow, whatever it feels like on your office broadband. Our Core Web Vitals guide explains each metric in more detail.
Is my hosting the problem?
Often, yes. A cheap shared hosting plan, a server in another continent or a site with no page caching will all show up as high TTFB. Everything else waits for that first byte, so no amount of image work will hide it.
Signs it is the server:
- TTFB is above 0.8 seconds even on a simple page.
- The site is fast at night and slow during the day.
- Logged-in pages or the basket are much slower than static pages.
- Your host's data centre is far from your customers (for example, US servers for a UK audience, or the other way round).
Fixes, roughly in order of effort: turn on page caching (most CMSs have a plugin or setting), upgrade PHP or your runtime to a supported version, move to a host with servers near your customers, and put a CDN in front of the site. Our guide to reducing TTFB covers each step.
Are my images too big?
Images are the heaviest part of the median web page. The HTTP Archive's 2025 Web Almanac puts the median mobile home page at roughly 2.5 MB, of which around 0.9 MB is images. On small-business sites it is common to find a single 4 MB photo straight off a phone sitting in the hero banner.
Quick checks:
- Is any image over 200 KB? Most can be a fraction of that.
- Are images served at the size they display? A 4,000-pixel-wide photo shown at 800 pixels wastes most of its bytes.
- Are you using JPEG or PNG where WebP or AVIF would do?
Resize, compress and convert, then add width and height attributes so the page does not jump while images load.
Is JavaScript slowing my site down?
JavaScript costs twice: once to download and again to parse and run on the visitor's device. The median mobile home page loads around 630 KB of it, according to the same Web Almanac data. Page builders, sliders, animation libraries and plugins that load on every page whether they are used or not are common culprits.
Look at the "Reduce unused JavaScript" and "Minimise main-thread work" findings in Lighthouse. Then:
- Remove plugins and features you no longer use.
- Load scripts with
deferso they do not block the page from rendering. - Replace heavy sliders and carousels with a single static image.
- Ask your developer whether large bundles can be split so each page only loads what it needs.
Could third-party scripts be the cause?
Chat widgets, analytics, tag managers, heatmaps, cookie banners, embedded videos, review widgets and ad pixels each add requests to servers you do not control. Individually they may seem small. Together they often outweigh your own code and are a frequent cause of poor INP.
Audit them once a quarter: list every script, who asked for it and whether anyone still uses the data. Remove anything without a clear owner and purpose.
What else commonly slows a site down?
- No compression. Text files (HTML, CSS, JavaScript) should be sent with Gzip or Brotli. Most hosts and CDNs can switch this on in a few clicks.
- No browser caching. Returning visitors re-download the same files if your Cache-Control headers are missing or short.
- Render-blocking CSS and fonts. The browser cannot paint until it has the CSS in the
<head>. Large stylesheets and several web font files delay the first paint. - Redirect chains.
http://tohttps://towww.to a trailing slash adds a round trip each time. - Too many plugins. On WordPress especially, every plugin can add its own CSS and JavaScript to every page.
Which fixes should I do first?
Work in this order, because each step is a prerequisite for the next one to show its full benefit:
- Fix server response time (caching, hosting, CDN).
- Optimise the largest image on each key page, usually the hero.
- Remove unused plugins and third-party scripts.
- Enable compression and long cache lifetimes for static files.
- Tackle JavaScript and font loading.
Re-test after each change so you know what worked. Lab scores vary from run to run, so run each test two or three times and compare the median.
Frequently asked questions
Why is my website fast for me but slow for customers?
Your browser has probably cached the site, you may be on fast office fibre, and you are likely using a powerful laptop. Customers on mid-range phones over mobile data see the uncached, throttled version. Test in a private window with caching disabled, and trust field data over your own impression.
Does a slow website affect Google rankings?
Google says achieving good Core Web Vitals aligns with what its core ranking systems seek to reward, but it does not promise that good scores guarantee rankings. Relevance and content quality matter far more. The bigger cost of a slow site is usually lost enquiries and sales rather than lost positions.
Why did my website suddenly become slow?
Look at what changed recently: a new plugin, theme update, marketing tag, large image upload or a traffic spike. A sudden TTFB increase often points to the host, a database problem or a failed cache. Your host's status page and error logs are the first places to check.
Will a CDN fix a slow website?
A CDN helps most when visitors are far from your server and when static files are a big part of the load. It will not fix a slow database, bloated pages or heavy JavaScript. Our guide on whether you need a CDN explains when it is worth it.
Is PageSpeed score the same as load time?
No. The Lighthouse performance score is a weighted mix of lab metrics on a simulated mid-range phone, scored from 0 to 100. It is a useful diagnostic, but the field Core Web Vitals reflect what real visitors actually experience.
How often should I check my website speed?
Check after every significant change and at least monthly otherwise. Paid MakeItFlow plans can re-scan on a schedule and email you the results, so you notice regressions without remembering to test.
What to do next
Run a test now, note your TTFB and LCP, and pick the single biggest problem from the list above. Fix that, re-test and move to the next one. Use the MakeItFlow website speed test to keep a record of each result so you can show what improved.
Related reading
- What Is a Good Page Load Time in 2026? Targets That Matter: A good page load time in 2026 means main content visible within 2.5 seconds on mobile. See the exact targets for LCP, TTFB, FCP and INP and how to hit them.
- Chrome Adds Ad Metrics to CrUX: What Publishers Should Know: Chrome added four experimental ad metrics to CrUX on 15 September 2026. What ad count, density and weight mean for your site, and whether they affect rankings.
- Why Are My Web Fonts Slowing My Site Down? How to Fix It: Web fonts slowing your site? Cut font files, use WOFF2, set font-display, preload the main font and consider self-hosting and subsetting for faster text.
Sources
Written by the MakeItFlow team
We build the website audit these guides are based on. Every fact is checked against the primary sources listed above and this guide was last reviewed on 25 October 2026 . How we research and check
Check your own site in 30 seconds
Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.
