Check If Your Website Is Slow: Fix Speed Issues (2026)

A slow website is one of those problems that everyone suspects they have and almost nobody measures. The homepage feels fine on your laptop, on your fast office WiFi, when you already have the site cached. What it feels like in the real world, a first-time visitor on a mid-range phone on 4G, three thousand miles away, is a completely different experience.

This guide covers how to actually measure website speed, which numbers matter, and the fixes that make the biggest difference for the effort involved.

Why website speed actually matters

Three concrete things, all measurable:

• SEO. Google uses page experience signals as a ranking factor, and Core Web Vitals are the most direct way to measure page experience. A slow site is downranked relative to faster competitors on the same content.
• Conversion. Every study that has measured the relationship between load time and conversions has found the same pattern: slower sites convert worse. Amazon reportedly found that every 100 ms of additional latency cost 1 percent of sales.
• Bounce rate. Users abandon slow pages. On mobile especially, a page that takes more than 3 seconds to become usable loses a large fraction of visitors before they see anything.

What to actually measure

There are dozens of metrics. Four matter most, and all four are measured by the free speed test tool.

1. Time to First Byte (TTFB)

The time between the request leaving the browser and the first byte of the response arriving. TTFB is the pure server-side metric. It includes DNS lookup, TCP handshake, TLS handshake, and whatever time the server takes to generate the response.

2. Largest Contentful Paint (LCP)

The time until the largest element in the viewport, usually the hero image or a big heading, has fully rendered. This is what users perceive as "when the page loaded." Google uses LCP as one of the three Core Web Vitals.

• Under 2.5 s: Good
• 2.5 to 4 s: Needs improvement
• Over 4 s: Poor

3. Interaction to Next Paint (INP)

Replaced First Input Delay as a Core Web Vital in March 2024. Measures the responsiveness of the page to user interactions: how long it takes for the page to visually respond after a click or tap. Over 200 ms feels laggy; under 100 ms feels instant.

4. Cumulative Layout Shift (CLS)

How much content moves around while the page loads. A page that jumps because a late-loading image pushed the text down has high CLS. Aim for under 0.1. A page with higher CLS feels broken even if it loads fast.

How to check your own site in 30 seconds

1. Open the Website Speed Test tool.
2. Enter your homepage URL. Do not include https://. The tool adds it automatically.
3. Read TTFB and total time. TTFB is the server-side signal, total time is the full HTML delivery.
4. Check the response headers. Is content-encoding gzip or br? Is there a cache-control header?
5. Run the test three times. Server response varies. The median is more meaningful than any single sample.

Interpreting the results

The five fixes that make the biggest difference

Once you have measurements, here is what to do about them, ordered by impact per unit of effort.

1. Enable gzip or Brotli compression

If your server sends HTML, CSS and JS uncompressed, every visitor is downloading 3 to 5 times more bytes than necessary. Enabling compression is a single-line config change in every major server (Apache, Nginx, Cloudflare, Vercel, Netlify).

# Nginx
# Add to your server block or http block
gzip on;
gzip_types text/html text/css text/javascript application/javascript application/json;
gzip_min_length 1000;

# Or enable Brotli (better compression, wider browser support now)
brotli on;
brotli_types text/html text/css text/javascript application/javascript application/json;

Expected impact: 50 to 75 percent reduction in text asset size. Takes five minutes. This is almost always the highest-impact single fix.

2. Serve images in modern formats

Images are usually 50 to 80 percent of page weight. If you are serving JPEGs, converting to WebP cuts them by 30 percent. Converting to AVIF cuts them by 50 percent. Both are supported by every browser in active use.

• Convert your ten largest images to WebP or AVIF.
• Use the picture element to serve AVIF with WebP fallback and JPEG as the last resort.
• Compress every remaining image to the smallest acceptable quality.

3. Use a CDN

A CDN places copies of your static assets (images, CSS, JS) on servers around the world. A visitor in Karachi gets the file from a Karachi edge node, not from a server in Virginia. This alone can cut TTFB by 200 to 500 ms for global audiences.

Cloudflare has a free tier that covers most sites. Vercel and Netlify include CDN by default. If you are on shared hosting without a CDN, moving to Cloudflare alone will usually improve TTFB by 30 to 60 percent.

4. Add cache headers

Static assets (images, CSS, JS files with hash names) should be cached aggressively by browsers. Without cache headers, every visit re-downloads them.

# Nginx: cache static assets for 1 year
location ~* \.(jpg|jpeg|png|gif|webp|avif|svg|css|js|woff2?)$ {
  expires 1y;
  add_header Cache-Control "public, immutable";
}

# HTML should be cached briefly (so updates are seen)
location ~* \.html?$ {
  expires 5m;
  add_header Cache-Control "public, must-revalidate";
}

The rule: static assets with hashed filenames get 1 year. HTML gets 5 minutes to 1 hour. Never cache HTML for a year. You would never see your own updates.

5. Eliminate redirect chains

If http://example.com redirects to https://www.example.com, that is one extra round-trip before the browser even starts loading the page. If there are two or three redirects chained, the cost multiplies.

• Pick one canonical URL (https://example.com or https://www.example.com).
• Redirect everything else to it in a single hop.
• Never chain http to https to www to apex.

Advanced fixes (worth it if the basics are done)

• Preconnect to external domains. A link rel preconnect tag saves 100 to 300 ms on font loading.
• Preload the LCP image. A link rel preload as image tag tells the browser to start downloading it before the CSS is parsed.
• Lazy-load below-the-fold images. The loading="lazy" attribute defers images the user has not scrolled to yet.
• Defer non-critical JavaScript. A script tag with defer or async avoids blocking rendering.
• Reduce web font weight. Every additional font weight (regular, medium, bold, etc.) is another file download. Use two weights maximum.
• Consider a static site. If your content does not change per-user, serving pre-rendered HTML from a CDN beats server-side rendering every time.

The bottom line

Website speed is measurable, and once measured it is usually fixable. The common problems (no compression, huge images, no CDN, no cache headers) account for the majority of slow sites, and all four are fixable in a single afternoon.

Start by measuring. TTFB and total time give you a quick diagnosis. Then work through the five fixes in order. The first two usually account for the majority of the improvement. The rest are polish.