What is a good page load time in 2026?

Under 2.5 seconds for the largest visible element (LCP) is Google's 'good' threshold. Under 1.5 seconds is excellent. Most well-optimized sites load in 1-2 seconds on a fast connection and 2-3 seconds on mobile 4G.

Does website speed affect SEO?

Yes. Google has used page speed as a ranking factor since 2010, and Core Web Vitals (LCP, INP, CLS) became an official ranking signal in 2021. Sites failing Core Web Vitals see measurably lower rankings compared to identical content on faster sites.

How do I check my website's speed?

Use Google PageSpeed Insights (pagespeed.web.dev) for Core Web Vitals from real users, WebPageTest.org for detailed waterfall analysis, or Chrome DevTools Lighthouse for local testing. Test on both mobile and desktop — most traffic is mobile.

Is it worth paying for a CDN?

Cloudflare's free tier is sufficient for most websites. It provides global CDN, basic caching, and DDoS protection at zero cost. Paid CDNs (Fastly, CloudFront) offer more control and analytics but are mainly needed for high-traffic sites (1M+ monthly visitors).

Website Speed Optimization: The Complete 2026 Guide

Speed Is Money

Amazon found that every 100ms of latency costs 1% in sales. Google uses page speed as a ranking factor. And 53% of mobile users abandon sites that take more than 3 seconds to load. Speed isn't a nice-to-have — it directly impacts revenue, rankings, and user experience.

The good news: most websites are slow for the same handful of reasons, and each one has a straightforward fix.

Core Web Vitals in 2026

Google's Core Web Vitals are the three metrics that matter most for both SEO and user experience:

LCP (Largest Contentful Paint)

How long until the biggest visible element (usually a hero image or headline) loads.

Good: Under 2.5 seconds
Needs work: 2.5 - 4 seconds
Poor: Over 4 seconds

Most common causes of bad LCP: Unoptimized hero images, slow server response, render-blocking CSS/JS, and lazy-loading above-the-fold content (don't do this — only lazy-load below the fold).

INP (Interaction to Next Paint)

How quickly the page responds when a user clicks, taps, or types. INP replaced FID (First Input Delay) in 2024 as a more comprehensive measure of interactivity.

Good: Under 200ms
Needs work: 200 - 500ms
Poor: Over 500ms

Most common causes of bad INP: Heavy JavaScript execution blocking the main thread, large DOM size (over 1,500 elements), and third-party scripts (chat widgets, analytics, ad networks).

CLS (Cumulative Layout Shift)

How much the page layout jumps around during loading. When text shifts down because an image loaded above it, or a banner pushes content — that's layout shift.

Good: Under 0.1
Needs work: 0.1 - 0.25
Poor: Over 0.25

Most common causes of bad CLS: Images without width/height attributes, web fonts loading and changing text size (FOUT), dynamically injected content (ads, cookie banners), and iframes without dimensions.

The 5 Biggest Speed Killers

1. Unoptimized Images

Images are typically 50-70% of a page's total weight. This is almost always the first thing to fix.

| Format | Best For | Savings vs JPEG | |--------|----------|-----------------| | WebP | Photos, general use | 25-35% smaller | | AVIF | Photos (modern browsers) | 40-50% smaller | | SVG | Icons, logos, illustrations | Resolution-independent | | PNG | Screenshots, text-heavy images | Lossless, but large |

Action items:

Convert all JPEG/PNG images to WebP or AVIF format (30-50% smaller)
Set explicit width and height attributes on every <img> (prevents CLS)
Use responsive srcset for different screen sizes — don't serve a 2000px image to a phone
Lazy-load below-the-fold images with loading="lazy"
Use fetchpriority="high" on your LCP image so the browser prioritizes it

2. Too Many HTTP Requests

Each resource (CSS file, JS file, font, image) requires a separate network request. A typical page makes 60-100 requests. Reducing this to 20-30 can cut load time dramatically.

Bundle CSS and JS files (your build tool should handle this)
Use CSS sprites or inline SVG icons instead of individual icon images
Inline critical CSS in the <head> (the minimum CSS for above-the-fold content)
Remove unused libraries — audit with Chrome DevTools Coverage tab
Self-host fonts instead of loading from Google Fonts (saves a DNS lookup + connection)

3. No CDN

A CDN (Content Delivery Network) serves your content from servers near your visitors. Without one, a user in Tokyo loads everything from your single server in Virginia — adding 200-300ms of latency on every request.

| CDN | Free Tier | Best For | |-----|-----------|----------| | Cloudflare | Yes (generous) | Most websites | | Vercel Edge Network | Included | Next.js / Vercel apps | | AWS CloudFront | Pay-per-use | AWS infrastructure | | Fastly | Limited | High-traffic, real-time | | Bunny CDN | $1/TB | Budget alternative |

Cloudflare's free tier provides global CDN, automatic HTTPS, basic caching, and DDoS protection. There's almost no reason not to use it.

4. Render-Blocking Resources

JavaScript and CSS files referenced in the <head> block the browser from rendering anything until they're downloaded and parsed.

Add defer or async attributes on non-critical scripts
Inline critical CSS (the styles needed for above-the-fold content) and lazy-load the rest
Move third-party scripts (analytics, chat widgets, ad tags) to load after the page with defer
Use <link rel="preload"> for critical resources the browser doesn't discover early (fonts, hero images)
Consider <link rel="preconnect"> for third-party domains your page will need

5. Slow Server Response (TTFB)

Time to First Byte (TTFB) over 600ms means your server is the bottleneck — the browser is waiting for the server to even start sending the page.

| TTFB | Status | Action | |------|--------|--------| | Under 200ms | Excellent | No action needed | | 200-500ms | Acceptable | Consider caching | | 500ms-1s | Slow | Add server caching, optimize DB queries | | Over 1s | Critical | Upgrade hosting or move to edge rendering |

Solutions:

Upgrade hosting (shared hosting → VPS → dedicated server)
Add server-side caching (Redis, Varnish, or application-level caching)
Use a static site generator or edge rendering (ISR, SSG) for pages that don't change per-request
Optimize database queries — add indexes, reduce N+1 queries, cache frequent queries
Enable HTTP/2 or HTTP/3 on your server (most modern servers support this)

The Quick Win Checklist

If you only have 30 minutes, do these five things in order:

Run PageSpeed Insights — identify the specific problems
Convert images to WebP — use Squoosh.app or your build tool
Add loading="lazy" to below-fold images — one attribute, immediate improvement
Add defer to non-critical scripts — stops JavaScript from blocking rendering
Enable Cloudflare — free CDN, automatic HTTPS, basic caching

These five changes alone can improve your Lighthouse score by 20-40 points.

Advanced Optimizations

Once the basics are handled, these techniques provide additional gains:

HTTP/3 and QUIC — Faster connection establishment, especially on mobile
Brotli compression — 15-20% better than gzip for text assets
Service workers — Cache assets locally for repeat visitors (instant loads)
Resource hints — preload, prefetch, preconnect, and dns-prefetch help the browser discover resources earlier
Font subsetting — Only load the characters you actually use (can reduce font files by 80%)
Critical rendering path optimization — Inline above-the-fold CSS, defer everything else

Free Tools to Measure Speed

Google PageSpeed Insights — Core Web Vitals from real users (CrUX data) plus lab data from Lighthouse
WebPageTest — Detailed waterfall charts, filmstrip view, and multi-location testing
Chrome DevTools Lighthouse — Built into Chrome, run locally for instant results
GTmetrix — Combines Lighthouse scores with waterfall analysis
Host Autopsy Scanner — Our free tool checks speed plus security, DNS, SSL, and more

Run your site through our scanner above to get a comprehensive health check that covers speed alongside security headers, SSL configuration, and DNS setup.