Website Speed — How to Improve Loading Time and Why It Matters
Every second of delay in page loading costs you 7% of conversions. A site that loads in 5 seconds instead of 1 loses nearly 30% of potential clients — before they see any content. Speed is not a luxury. It's a foundation.
Website Speed Is Money — Literally
You don't have to take our word for it. Here are hard data:
- Amazon discovered that 100ms of delay costs 1% of sales. At their scale, that's hundreds of millions of dollars annually.
- Google confirmed that page speed is a ranking factor. Slower pages drop in search results.
- 53% of mobile users leave a site if it takes longer than 3 seconds to load (Google Research).
- Walmart recorded a 2% increase in conversions for every second of loading time improvement.
For the average business, this means one thing: website speed directly affects the number of clients and revenue. Not indirectly, not "maybe someday" — directly and measurably.
Yet the average business website loads in 4-6 seconds on mobile. That's 3-5 seconds too many.
Core Web Vitals — The Metrics That Truly Matter
Since 2021, Google has officially evaluated websites on three metrics called Core Web Vitals. This isn't just "another thing to optimize." It's a ranking factor that affects your position in search results.
LCP (Largest Contentful Paint) — Time to Display Main Content
What it measures: How long it takes from clicking a link until the largest element on the page (heading, hero image) is visible on screen.
Targets:
| Score | Rating |
|---|---|
| Up to 2.5s | Good (green) |
| 2.5-4.0s | Needs improvement (orange) |
| Above 4.0s | Poor (red) |
Most common causes of slow LCP:
- Large, unoptimized images (the most common cause)
- Slow server response (TTFB)
- Render-blocking CSS/JavaScript
- Lack of preloading critical resources
FID / INP (First Input Delay / Interaction to Next Paint) — Responsiveness
What it measures: How long it takes from the moment a user clicks a button or link until the browser begins to respond. Since March 2024, Google replaced FID with the more demanding INP (Interaction to Next Paint) metric.
INP targets:
| Score | Rating |
|---|---|
| Up to 200ms | Good |
| 200-500ms | Needs improvement |
| Above 500ms | Poor |
Most common causes of slow INP:
- Heavy JavaScript blocking the main thread
- Too many event listeners
- Large frameworks (Angular, unoptimized React)
- Third-party scripts (analytics, chat, remarketing)
CLS (Cumulative Layout Shift) — Visual Stability
What it measures: Whether page elements "jump" during loading. You click "Submit," but suddenly an ad loads above it and you click on the ad instead of the form.
Targets:
| Score | Rating |
|---|---|
| Up to 0.1 | Good |
| 0.1-0.25 | Needs improvement |
| Above 0.25 | Poor |
Most common causes of high CLS:
- Images without defined dimensions (width/height)
- Fonts that change text size after loading (FOUT)
- Dynamically injected content (ads, popups)
- Embeds without reserved space
How to Check Your Site's Speed
Before you start optimizing, you need to know where you stand. Three tools you must know:
1. PageSpeed Insights (pagespeed.web.dev) Google's official tool. Shows Core Web Vitals results, both lab data (simulation) and field data (real user data). Always look at mobile data — that's what Google bases rankings on.
2. Google Search Console The "Core Web Vitals" section shows how many of your pages meet the thresholds and how many don't. This is a site-wide view, not a single page.
3. Lighthouse (in Chrome DevTools) Press F12 → Lighthouse tab → Generate report. Detailed analysis with specific recommendations. Remember: test in incognito mode (browser extensions distort results).
Image Optimization — The Fastest Way to Speed Up Your Site
Images are the most common cause of slow loading. On the average business website, images account for 50-70% of the total page size. Image optimization is the fastest and easiest way to improve Core Web Vitals.
Format: WebP or AVIF
| Format | Size (vs PNG) | Quality | Browser support |
|---|---|---|---|
| PNG | 100% (baseline) | Lossless | 100% |
| JPEG | 30-50% | Lossy | 100% |
| WebP | 25-35% | Lossy/lossless | 97%+ |
| AVIF | 15-25% | Lossy/lossless | 93%+ |
WebP is the minimum in 2026. An image that weighs 2MB in PNG weighs 500-700KB in WebP and 300-500KB in AVIF — with comparable visual quality.
Responsive Images (srcset)
Don't serve a 2000px wide image on a phone with a 375px screen. Use the srcset attribute so the browser automatically selects the appropriate size:
<img
src="hero-800.webp"
srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
sizes="(max-width: 768px) 100vw, 50vw"
width="800" height="450"
alt="Image description"
loading="lazy"
/>
Lazy Loading
Images below the visible screen don't need to load immediately. Add loading="lazy" — the browser will load them only when the user scrolls close to them.
Exception: The hero image (LCP element) should have loading="eager" or fetchpriority="high" — it must load as quickly as possible.
Image Dimensions
Always define width and height in HTML. Without this, the browser doesn't know how much space to reserve, and content "jumps" after the image loads (CLS).
JavaScript — The Silent Speed Killer
Images are the visible problem. JavaScript is the invisible but often more serious one. The average business website loads 500KB-2MB of JavaScript, half of which is third-party scripts (analytics, remarketing, chat, social media).
JavaScript Audit
Open Chrome DevTools → Network → filter by JS. Sort by size. You'll be surprised how much you load and how little of it you actually need.
Specific Reduction Techniques
1. Lazy loading third-party scripts. Google Analytics, Facebook Pixel, Hotjar — they don't need to load immediately. Load them after user interaction (scroll, click) or with a 3-5 second delay.
2. Code splitting. Don't load the entire application on every page. Next.js and Astro do this automatically — each page loads only the code it needs.
3. Tree shaking. Are you importing an entire library to use one function? Modern bundlers (webpack, esbuild, Rollup) remove unused code — but only if you import selectively: import { debounce } from 'lodash-es', not import _ from 'lodash'.
4. Removing unused scripts. Installed a chat widget but turned it off? The script still loads. Had a remarketing campaign 2 years ago? The pixel is still tracking. Clean up.
5. Switching to a lighter framework. If your site is mainly static content (blog, landing page), you don't need React with its 140KB runtime. Astro ships 0KB JavaScript by default. Next.js with 'use client' only where needed — that's a reasonable compromise.
Server and Hosting — The Foundation You Can't Skip
You can optimize images and JavaScript to perfection, but if the server responds after 2 seconds — nothing will help.
TTFB (Time to First Byte)
This is the time from the browser's request to the first byte of the server's response. Target: under 200ms.
| Hosting type | Typical TTFB | Comment |
|---|---|---|
| Shared hosting (cheapest) | 500-2000ms | Shared resources, unpredictable performance |
| VPS | 100-500ms | Dedicated resources, self-managed |
| CDN + static hosting | 20-100ms | Files served from nearest edge location |
| Vercel / Netlify | 30-80ms | Automatic CDN, ideal for Next.js/Astro |
If your site is static (SSG), a CDN is a gamechanger. Instead of one server in one location, your site is served from dozens of locations worldwide. A user in Los Angeles gets files from Los Angeles, not from Amsterdam.
Compression: gzip vs Brotli
The server should compress responses. Brotli compresses 15-20% better than gzip and is supported by 97%+ of browsers.
HTTP/2 and HTTP/3
HTTP/2 allows downloading multiple files simultaneously (multiplexing). HTTP/3 adds QUIC — faster connection establishment. Most modern hosting supports both. If your hosting still uses HTTP/1.1 — switch hosting.
Fonts — A Detail That Makes a Difference
Fonts are a subtle but real cause of CLS and LCP problems.
The Problem: FOUT and FOIT
- FOUT (Flash of Unstyled Text): Text displays in a system font, then jumps to the custom font. Causes CLS.
- FOIT (Flash of Invisible Text): Text is invisible until the font loads. The user sees a blank page.
Solutions
1. font-display: swap — display text immediately in a system font, swap to custom font after loading. Eliminates FOIT.
2. Preload critical fonts:
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
3. Limit the number of fonts. Maximum 2 fonts (headings + body text). Each additional font is an extra 20-100KB to load.
4. Use WOFF2 format. WOFF2 compresses 30% better than WOFF. Don't load TTF or OTF in the browser.
5. Subset fonts. If you only need Latin characters — load only the Latin subset, not all 5,000 glyphs.
CSS — The Optimization That Gets Forgotten
CSS is rarely the main culprit, but it can lower your scores.
1. Critical CSS inline. The styles needed for rendering above-the-fold content should be in a <style> tag in <head>, not in an external file. Eliminates render-blocking CSS.
2. Remove unused CSS. A typical WordPress site loads 200-500KB of CSS, of which 70%+ is unused. Tools: PurgeCSS, Coverage tab in Chrome DevTools.
3. Minification. cssnano, clean-css — removes comments, whitespace, shortens color names. 15-30% size reduction.
4. Avoid @import. @import in CSS causes sequential loading (waterfall). Use <link> in HTML or bundle CSS in the build step.
Speed Optimization Checklist
Go through this list point by point:
Images:
- WebP or AVIF format
- Responsive sizes (srcset)
- Lazy loading on images below the fold
- Defined width/height
- Hero image with fetchpriority="high"
JavaScript:
- Third-party scripts loaded with delay
- Code splitting (each page loads only its own code)
- No unused scripts
- Bundle size under 200KB (gzipped)
Server:
- TTFB under 200ms
- Brotli compression
- HTTP/2 or HTTP/3
- CDN
Fonts:
- Max 2 fonts
- WOFF2 format
- font-display: swap
- Preload critical fonts
CSS:
- Critical CSS inline
- Unused CSS removed
- Minified
Targets:
- LCP under 2.5s on mobile
- INP under 200ms
- CLS under 0.1
- Lighthouse Performance 90+ on mobile
Speed and SEO — Why Google Cares How Fast Your Site Loads
Google officially confirms that page speed is a ranking factor. But the impact is more nuanced than you might think.
Direct impact: Core Web Vitals are one of many ranking signals. With comparable content quality, the faster site wins.
Indirect impact (more important): Slow site → higher bounce rate → shorter time on site → lower CTR in results → Google interprets this as "low quality" → positions drop. It's a domino effect.
Crawl budget: Google has limited time to crawl your site. If every page responds in 3 seconds, Google will index fewer pages than at 200ms response time. This is especially critical for large sites. More about this in our article on SEO basics and SEO audit.
Summary — Speed Is Not Optimization, It's the Standard
In 2026, a fast website is not a competitive advantage — a slow website is a flaw. Users expect a site to load in under 2 seconds. Google expects Core Web Vitals to be green. Every second of delay is a real loss of clients and rankings.
The good news: most speed issues can be resolved in 1-2 days. Image optimization, lazy loading, CDN — it's not rocket science. It's hygiene.
Want to know how much you're losing from a slow site? Request a free speed audit — we'll check your site's Core Web Vitals and show you specific areas for improvement.