---
title: How to Improve Your Webpage Speed for Faster Website
description: 'Speed up your website in 2026: Core Web Vitals (LCP, INP, CLS), AVIF images, preloading, code splitting, and CDN tuning that cuts real-world load times.'
url: https://nerdleveltech.com/how-to-improve-your-webpage-speed-for-faster-website
language: en
date: '2023-01-15'
updated: '2026-03-27'
category: performance
tags:
- web-performance
- core-web-vitals
- page-speed
- recreated
markdown_url: https://nerdleveltech.com/how-to-improve-your-webpage-speed-for-faster-website.md
attribution: 'Source: NerdLevelTech — https://nerdleveltech.com/how-to-improve-your-webpage-speed-for-faster-website'
terms: https://nerdleveltech.com/llms.txt
---
# How to Improve Your Webpage Speed for Faster Website
## TL;DR
Focus on Core Web Vitals: LCP (Largest Contentful Paint under 2.5s), INP (Interaction to Next Paint under 200ms), and CLS (Cumulative Layout Shift under 0.1). Use AVIF images, Speculation Rules API for instant navigation, HTTP/3, and Lighthouse to measure. Speed directly impacts SEO rankings and conversion rates.
## Introduction
Page speed is not a nice-to-have. Google's ranking algorithm rewards fast sites. Users abandon slow sites — Google's mobile research found that bounce probability increases 32% as load time goes from 1 to 3 seconds, and 53% of mobile visitors abandon a page that takes longer than 3 seconds to load.[^google-mobile-speed] And for your business, every 100ms improvement in load time can move conversions — Akamai found a 100ms delay can cost online retailers up to 7% in conversions,[^akamai-100ms] while Mobify measured roughly a 1% conversion gain per 100ms improvement in production.[^mobify-100ms]
In 2026, optimizing speed is table stakes. But the toolkit has evolved. The focus has shifted from raw load time to **interaction responsiveness**—how quickly users can actually *do* something on your page. This guide covers the metrics that matter and the practical techniques to improve them.
## Understanding Core Web Vitals
Core Web Vitals are three metrics Google uses for ranking. They measure real user experience:
### Largest Contentful Paint (LCP)
LCP measures how quickly the main content appears. Specifically, the largest visible element on screen.
**Target: Under 2.5 seconds**
```
0s ─────────────────────── 4s
├─── Good (LCP <2.5s)
├─── Fair (2.5s-4s)
├─── Poor (>4s)
```
What counts as "contentful"?
- Images
- Heading and body text
- Video poster images
- Elements with background images
What doesn't count?
- SVG elements
- Canvas elements
- Iframe content
**How to improve LCP:**
1. **Lazy load below-the-fold images** (never the LCP element itself — `loading="lazy"` on a hero image will *hurt* your LCP score):
```html
```
2. **Optimize the critical path:** Minimize CSS and JavaScript that blocks rendering.
```jsx
// Before: render-blocking CSS
// After: critical CSS inline, defer the rest
```
3. **Preload the LCP element:**
```html
```
### Interaction to Next Paint (INP)
INP measures how responsive your site is to user interactions. When a user clicks, scrolls, or types, how long until the next paint? This replaced First Input Delay (FID) in March 2024.
**Target: Under 200 milliseconds**
Why does this matter? A sluggish response makes your site feel broken, even if it eventually loads.
```
0ms ──────────────────── 500ms
├─── Good (INP <200ms)
├─── Fair (200-500ms)
├─── Poor (>500ms)
```
**How to improve INP:**
1. **Break up long JavaScript tasks** (longer than 50ms becomes noticeable):
```javascript
// Bad: blocks for 100ms
function processLargeDataset(data) {
const result = data
.map(item => expensiveCalculation(item))
.filter(item => item.isValid);
updateUI(result);
}
// Good: break into chunks
async function processLargeDataset(data) {
const chunkSize = 100;
for (let i = 0; i < data.length; i += chunkSize) {
const chunk = data.slice(i, i + chunkSize);
const result = chunk
.map(item => expensiveCalculation(item))
.filter(item => item.isValid);
updateUI(result);
// Yield to browser to handle other tasks
await new Promise(resolve => setTimeout(resolve, 0));
}
}
```
2. **Use web workers for expensive computations:**
```javascript
// main.js
const worker = new Worker('worker.js');
worker.postMessage({ data: largeDataset });
worker.onmessage = (event) => updateUI(event.data);
// worker.js
self.onmessage = (event) => {
const result = complexCalculation(event.data);
self.postMessage(result);
};
```
3. **Defer non-critical JavaScript:**
```html
```
### Cumulative Layout Shift (CLS)
CLS measures unexpected layout changes. When content suddenly moves while users are trying to interact, it's a poor experience.
**Target: Under 0.1**
Example: You're about to click a button, but an ad loads and pushes the button down. You accidentally click the ad instead. That's layout shift.
**How to improve CLS:**
1. **Reserve space for dynamic content:**
```html
```
2. **Use `content-visibility` to prevent shifting:**
```css
/* Prevent cumulative layout shift on images */
img {
content-visibility: auto;
}
```
3. **Avoid inserting content above existing content:**
```jsx
// Bad: prepend new items (shifts everything down)
setItems([...newItems, ...items]);
// Good: append new items (no shift)
setItems([...items, ...newItems]);
```
## Image Optimization
Images still make up the largest share of page weight — around 40% of total bytes on the median page, per HTTP Archive's Web Almanac. That's down from nearly 75% in 2019, as JavaScript payloads have grown, but images remain the single biggest optimization opportunity for most sites.
### AVIF: Next-Gen Format
AVIF is smaller than WebP, which is smaller than JPEG. In 2026, AVIF support is widespread (all modern browsers).
```html
```
Typical file sizes for the same image:
- JPEG: 100KB
- WebP: 60KB
- AVIF: 40KB
Use ImageOptim, TinyPNG, or Squoosh to compress.
### Responsive Images
Serve different sizes based on device width:
```html
```
This tells the browser:
- On screens 600px or smaller, load an image 90% of viewport width
- On screens 600-1200px, load 70% of viewport width
- Larger screens, load a fixed 1200px image
## Network Optimization
### Speculation Rules API
Speculation Rules let the browser prefetch or prerender pages the user is *likely* to visit next.
```html
```
This way, if a user clicks "Proceed to Checkout," the page is already loaded in a hidden tab.
### HTTP/3 and Early Hints
HTTP/3 is faster than HTTP/2. If your hosting supports it, enable it.
HTTP 103 Early Hints tells the browser to start fetching critical resources before the main HTML is ready:
```
HTTP/1.1 103 Early Hints
Link: ; rel=preload; as=style
Link: ; rel=preload; as=script
HTTP/1.1 200 OK
```
Most CDNs (Cloudflare, Fastly) support this. Check your hosting.
## Measuring with Lighthouse
Lighthouse is the industry standard for measuring performance.
```bash
# Using Lighthouse CLI
npm install -g lighthouse
lighthouse https://example.com --view
```
Or use Chrome DevTools: F12 → Lighthouse tab → "Analyze page load".
**What to look for:**
1. **Opportunities:** Ranked by potential impact (e.g., "Eliminate render-blocking resources: 2.4s savings")
2. **Diagnostics:** Details on what's slow
3. **Passed audits:** What's working well
Set a target score for each category:
- Performance: 90+
- Accessibility: 95+
- Best Practices: 95+
- SEO: 100
## Real User Monitoring (RUM)
Lab tools like Lighthouse test your site in a controlled environment. Real User Monitoring (RUM) measures actual user experience.
### Web Vitals Library
The library's v3+ API uses `on*` functions (the older `get*` functions were renamed in v3; `onFID()` was deprecated in v4.0 and fully removed in v5.0, as Chrome ended FID support in its own tools — PageSpeed Insights, CrUX — in September 2024 in favor of INP):
```javascript
import {
onCLS,
onINP,
onFCP,
onLCP,
onTTFB,
} from 'web-vitals';
onCLS(console.log); // Cumulative Layout Shift
onINP(console.log); // Interaction to Next Paint
onFCP(console.log); // First Contentful Paint
onLCP(console.log); // Largest Contentful Paint
onTTFB(console.log); // Time to First Byte
// Send to analytics
onLCP((metric) => {
analytics.track('Core Web Vitals', {
metric: metric.name,
value: metric.value,
rating: metric.rating, // 'good', 'needs-improvement', 'poor'
});
});
```
Services like Vercel Analytics, Google Analytics 4, or Datadog show Core Web Vitals from real users.
## Performance Budget
Set targets for specific resources:
```javascript
// Budget in lighthouse config
{
"budgets": [
{
"type": "bundle",
"name": "main",
"baseline": 150000,
"maxSize": 170000
},
{
"type": "font",
"name": "Inter",
"maxSize": 50000
}
]
}
```
Run Lighthouse CI in your CI/CD to fail builds that exceed the budget.
## Common Pitfalls
**Too many third-party scripts:** Analytics, ads, chat widgets—each adds overhead. Load them asynchronously.
**Unoptimized web fonts:** System fonts load instantly. Web fonts cause a flash of invisible text (FOIT). Use font-display strategies:
```css
@font-face {
font-family: 'Inter';
src: url('inter.woff2') format('woff2');
font-display: swap; /* Show fallback until font loads */
}
```
**Large bundles:** Tree-shake unused code, code-split by route, lazy-load components:
```javascript
// Before: entire library bundled
import { datePicker, dropdown, modal } from 'ui-lib';
// After: lazy load what you need
const datePicker = lazy(() => import('ui-lib/DatePicker'));
```
**Uncompressed responses:** Ensure gzip/brotli compression is enabled on your server.
## Key Takeaways
Speed optimization is a continuous process:
1. **Measure first:** Use Lighthouse and Google Analytics to identify bottlenecks
2. **Focus on Core Web Vitals:** LCP, INP, CLS—these directly impact rankings
3. **Optimize images:** AVIF + responsive images yield the biggest gains
4. **Break up JavaScript:** Long tasks kill INP scores
5. **Measure real users:** Lab tools miss real-world conditions
6. **Monitor continuously:** Set performance budgets and enforce them in CI
A 1-second improvement in load time can mean thousands of dollars in additional revenue for e-commerce. Speed is not optional.
[^web-dev-perf]: web.dev — Core Web Vitals. https://web.dev/learn/performance/
[^google-mobile-speed]: Google/SOASTA Research, 2017, "The Need for Mobile Speed." https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/
[^akamai-100ms]: Akamai, State of Online Retail Performance report. https://www.akamai.com/newsroom/press-release/akamai-releases-spring-2017-state-of-online-retail-performance-report
[^mobify-100ms]: Mobify, "The 100 Millisecond Delay." https://web.archive.org/web/2018/https://www.mobify.com/insights/100-milliseconds-page-load-time/
```
2. **Optimize the critical path:** Minimize CSS and JavaScript that blocks rendering.
```jsx
// Before: render-blocking CSS
// After: critical CSS inline, defer the rest
```
3. **Preload the LCP element:**
```html
```
### Interaction to Next Paint (INP)
INP measures how responsive your site is to user interactions. When a user clicks, scrolls, or types, how long until the next paint? This replaced First Input Delay (FID) in March 2024.
**Target: Under 200 milliseconds**
Why does this matter? A sluggish response makes your site feel broken, even if it eventually loads.
```
0ms ──────────────────── 500ms
├─── Good (INP <200ms)
├─── Fair (200-500ms)
├─── Poor (>500ms)
```
**How to improve INP:**
1. **Break up long JavaScript tasks** (longer than 50ms becomes noticeable):
```javascript
// Bad: blocks for 100ms
function processLargeDataset(data) {
const result = data
.map(item => expensiveCalculation(item))
.filter(item => item.isValid);
updateUI(result);
}
// Good: break into chunks
async function processLargeDataset(data) {
const chunkSize = 100;
for (let i = 0; i < data.length; i += chunkSize) {
const chunk = data.slice(i, i + chunkSize);
const result = chunk
.map(item => expensiveCalculation(item))
.filter(item => item.isValid);
updateUI(result);
// Yield to browser to handle other tasks
await new Promise(resolve => setTimeout(resolve, 0));
}
}
```
2. **Use web workers for expensive computations:**
```javascript
// main.js
const worker = new Worker('worker.js');
worker.postMessage({ data: largeDataset });
worker.onmessage = (event) => updateUI(event.data);
// worker.js
self.onmessage = (event) => {
const result = complexCalculation(event.data);
self.postMessage(result);
};
```
3. **Defer non-critical JavaScript:**
```html
```
### Cumulative Layout Shift (CLS)
CLS measures unexpected layout changes. When content suddenly moves while users are trying to interact, it's a poor experience.
**Target: Under 0.1**
Example: You're about to click a button, but an ad loads and pushes the button down. You accidentally click the ad instead. That's layout shift.
**How to improve CLS:**
1. **Reserve space for dynamic content:**
```html
```
This tells the browser:
- On screens 600px or smaller, load an image 90% of viewport width
- On screens 600-1200px, load 70% of viewport width
- Larger screens, load a fixed 1200px image
## Network Optimization
### Speculation Rules API
Speculation Rules let the browser prefetch or prerender pages the user is *likely* to visit next.
```html
```
This way, if a user clicks "Proceed to Checkout," the page is already loaded in a hidden tab.
### HTTP/3 and Early Hints
HTTP/3 is faster than HTTP/2. If your hosting supports it, enable it.
HTTP 103 Early Hints tells the browser to start fetching critical resources before the main HTML is ready:
```
HTTP/1.1 103 Early Hints
Link: ; rel=preload; as=style
Link: ; rel=preload; as=script
HTTP/1.1 200 OK
```
Most CDNs (Cloudflare, Fastly) support this. Check your hosting.
## Measuring with Lighthouse
Lighthouse is the industry standard for measuring performance.
```bash
# Using Lighthouse CLI
npm install -g lighthouse
lighthouse https://example.com --view
```
Or use Chrome DevTools: F12 → Lighthouse tab → "Analyze page load".
**What to look for:**
1. **Opportunities:** Ranked by potential impact (e.g., "Eliminate render-blocking resources: 2.4s savings")
2. **Diagnostics:** Details on what's slow
3. **Passed audits:** What's working well
Set a target score for each category:
- Performance: 90+
- Accessibility: 95+
- Best Practices: 95+
- SEO: 100
## Real User Monitoring (RUM)
Lab tools like Lighthouse test your site in a controlled environment. Real User Monitoring (RUM) measures actual user experience.
### Web Vitals Library
The library's v3+ API uses `on*` functions (the older `get*` functions were renamed in v3; `onFID()` was deprecated in v4.0 and fully removed in v5.0, as Chrome ended FID support in its own tools — PageSpeed Insights, CrUX — in September 2024 in favor of INP):
```javascript
import {
onCLS,
onINP,
onFCP,
onLCP,
onTTFB,
} from 'web-vitals';
onCLS(console.log); // Cumulative Layout Shift
onINP(console.log); // Interaction to Next Paint
onFCP(console.log); // First Contentful Paint
onLCP(console.log); // Largest Contentful Paint
onTTFB(console.log); // Time to First Byte
// Send to analytics
onLCP((metric) => {
analytics.track('Core Web Vitals', {
metric: metric.name,
value: metric.value,
rating: metric.rating, // 'good', 'needs-improvement', 'poor'
});
});
```
Services like Vercel Analytics, Google Analytics 4, or Datadog show Core Web Vitals from real users.
## Performance Budget
Set targets for specific resources:
```javascript
// Budget in lighthouse config
{
"budgets": [
{
"type": "bundle",
"name": "main",
"baseline": 150000,
"maxSize": 170000
},
{
"type": "font",
"name": "Inter",
"maxSize": 50000
}
]
}
```
Run Lighthouse CI in your CI/CD to fail builds that exceed the budget.
## Common Pitfalls
**Too many third-party scripts:** Analytics, ads, chat widgets—each adds overhead. Load them asynchronously.
**Unoptimized web fonts:** System fonts load instantly. Web fonts cause a flash of invisible text (FOIT). Use font-display strategies:
```css
@font-face {
font-family: 'Inter';
src: url('inter.woff2') format('woff2');
font-display: swap; /* Show fallback until font loads */
}
```
**Large bundles:** Tree-shake unused code, code-split by route, lazy-load components:
```javascript
// Before: entire library bundled
import { datePicker, dropdown, modal } from 'ui-lib';
// After: lazy load what you need
const datePicker = lazy(() => import('ui-lib/DatePicker'));
```
**Uncompressed responses:** Ensure gzip/brotli compression is enabled on your server.
## Key Takeaways
Speed optimization is a continuous process:
1. **Measure first:** Use Lighthouse and Google Analytics to identify bottlenecks
2. **Focus on Core Web Vitals:** LCP, INP, CLS—these directly impact rankings
3. **Optimize images:** AVIF + responsive images yield the biggest gains
4. **Break up JavaScript:** Long tasks kill INP scores
5. **Measure real users:** Lab tools miss real-world conditions
6. **Monitor continuously:** Set performance budgets and enforce them in CI
A 1-second improvement in load time can mean thousands of dollars in additional revenue for e-commerce. Speed is not optional.
[^web-dev-perf]: web.dev — Core Web Vitals. https://web.dev/learn/performance/
[^google-mobile-speed]: Google/SOASTA Research, 2017, "The Need for Mobile Speed." https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-new-industry-benchmarks/
[^akamai-100ms]: Akamai, State of Online Retail Performance report. https://www.akamai.com/newsroom/press-release/akamai-releases-spring-2017-state-of-online-retail-performance-report
[^mobify-100ms]: Mobify, "The 100 Millisecond Delay." https://web.archive.org/web/2018/https://www.mobify.com/insights/100-milliseconds-page-load-time/