Why is my website slow? How to find the cause and fix it
"Slow" can mean a slow server, a slow main image, a sluggish response to taps, or a page that jumps around. Here's how to tell which, and what to fix first.
"My website is slow" can describe several different problems. The server might take a long time to send the first byte. The page might arrive quickly but take ages to show its main image. It might look ready but ignore taps for a second. Or it might load, then jump around as ads and images push the text down. Each has different causes, so the first job is working out which one you have.
Measure before you change anything
There are two kinds of speed data, and they answer different questions:
- Field data comes from real visitors on their own devices and connections. Google's Chrome UX Report collects it for sites with enough traffic, and you can see it in PageSpeed Insights and the Core Web Vitals report in Google Search Console. It tells you what people actually experience.
- Lab data comes from loading the page once under controlled conditions, as Lighthouse does. It's less representative, but it's repeatable and it explains why a page is slow.
Google's Core Web Vitals describe a good experience as Largest Contentful Paint (LCP) of 2.5 seconds or less, Interaction to Next Paint (INP) of 200 milliseconds or less and Cumulative Layout Shift (CLS) of 0.1 or less, measured at the 75th percentile of real visits.
For the diagnosis, run a lab test. Rudra's free website speed checker loads your page with Lighthouse and reports First Contentful Paint, LCP, Total Blocking Time, CLS, Speed Index and Time to Interactive, plus the Lighthouse audits that didn't pass, worst first. Keep its limits in mind: it's a single load from our server under Lighthouse's simulated conditions, so the numbers won't match your field data exactly, and it can't measure INP, which needs real interactions. Total Blocking Time is the lab signal most closely related to responsiveness.
Test a few representative page types (homepage, a product or service page, an article), run each more than once, and look at mobile results, not just desktop.
The most common causes, and how to fix them
1. A slow server response
Nothing else can start until the server sends the HTML. If Time to First Byte is high, the cause is usually cheap or overloaded hosting, pages built from scratch on every request, slow database queries, or visitors far from the server. Fixes: turn on page caching (most CMSs have a caching plugin or setting), put a CDN in front of the site, remove plugins you don't need, and upgrade hosting if the server is simply underpowered. Google's guidance treats a TTFB of 0.8 seconds or less as good. On full-site crawls, Rudra flags pages whose server took more than 1.5 seconds to respond, and more than 3 seconds as critical.
2. Oversized images
A photo exported straight from a camera or phone can be several megabytes and thousands of pixels wide, then displayed at 800 pixels. Resize, compress and use modern formats. Our guide on how to reduce image size walks through it step by step.
3. Too much JavaScript
Large bundles and third-party tags (analytics, chat widgets, A/B testing, ad scripts) compete for the browser's main thread. While a long script runs, the page can't respond to taps, which shows up as high Total Blocking Time in the lab and poor INP in the field. Audit every third-party tag and remove the ones nobody uses, load non-essential widgets after the page is interactive or when the visitor asks for them, and split large bundles so each page only loads what it needs.
4. Render-blocking CSS and scripts
Scripts in the <head> without async or defer, and every stylesheet, must load before the browser can paint anything. Add defer to scripts that don't need to run immediately, for example <script src="/app.js" defer></script>, combine or remove unnecessary stylesheets, and consider inlining the small amount of CSS needed for the top of the page.
5. No compression
Text files (HTML, CSS, JavaScript, JSON, SVG) shrink dramatically with gzip or Brotli. Check the response headers of your page in the browser's Network tab for content-encoding: br or gzip. If it's missing, enable it on the server (in nginx, gzip on; plus a gzip_types list) or at your CDN.
6. Static files that aren't cached
Returning visitors shouldn't download your logo and stylesheet again. For files whose names change when their content changes (most build tools add a hash, like app.3f9a2c.js), send Cache-Control: public, max-age=31536000, immutable. Keep HTML on a short cache or revalidation so updates appear promptly.
7. Heavy web fonts
Several font families, each in many weights, add up quickly, and text can stay invisible while fonts download. Use fewer weights, serve WOFF2, subset fonts to the characters you need, add font-display: swap so text appears in a fallback font immediately, and preload only the one font used above the fold. A system font stack avoids the download entirely.
8. Layout shift
Pages that jump are usually caused by images and embeds without reserved space, ads injected into the content, or banners that appear above the text after load. Give every image width and height attributes (or a CSS aspect-ratio), reserve space for ads and embeds with a min-height, and show cookie and promo banners as overlays rather than pushing content down.
9. Bloated pages and too many requests
Very large HTML documents (often from inlined data or endless product grids), dozens of scripts and the same script included twice all slow a page down. Paginate long lists, move large inline data to separate cached files, and remove duplicate tags. Rudra's crawl flags HTML documents over 1 MB, pages referencing more than 100 resources, and scripts loaded more than once.
10. Redirects before the page even starts
A visitor who types example.com and is redirected to https://example.com, then to https://www.example.com, then to /home, waits for each hop. Redirect straight to the final URL in one step, and link to final URLs everywhere.
What to fix first
- If the server response is slow, start there. Every other metric waits on it.
- If LCP is poor, find the LCP element. Lighthouse names it. It's usually a hero image (compress it, don't lazy-load it, and consider
fetchpriority="high") or a heading held back by fonts or render-blocking CSS. - If Total Blocking Time or INP is poor, look at JavaScript, especially third-party tags.
- If CLS is poor, reserve space for images, embeds, ads and banners.
- Re-test after each change, so you know what actually helped.
What a speed test can't tell you
A lab test loads one public URL, logged out, from one location. It won't show the slow checkout step behind a login, the page that's only slow for visitors on another continent, or the widget that only misbehaves after a minute of scrolling. Use it to find and explain problems, then confirm improvements in field data over the following weeks.
Common mistakes
- Chasing a perfect Lighthouse score instead of the metrics your visitors feel.
- Testing only on desktop over fast office Wi-Fi.
- Lazy-loading the hero image, which delays LCP.
- Installing several "speed" or caching plugins that conflict with each other.
- Judging a change on a single test run; results vary between runs.
Find what's slowing your site down
Run a free audit: Rudra crawls your pages and flags slow server responses, render-blocking resources, missing compression and images without dimensions.
Frequently asked questions
What is a good page load time?
There isn't one number, because "load time" can mean several things. Google's Core Web Vitals are the most useful targets: LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile of real visits.
Why does my speed score change every time I test?
Lab tests vary with server load, network conditions and third-party scripts that behave differently on each run. Run several tests and compare the typical result, and rely on field data for the real-world picture.
Does website speed affect SEO?
Core Web Vitals are part of how Google evaluates page experience, but relevance and content quality matter far more. Speed is best treated as a user-experience issue that can also help search performance at the margin.
Why is my site fast for me but slow for others?
You may have the site cached in your browser, live close to the server, use a fast device, or be seeing a logged-in or cached version. Visitors on mid-range phones and mobile networks, far from your server, experience something different, which is why field data matters.