PageSpeed Optimization: Improving Website Speed Systematically

Every second of load time costs users and revenue. Here you'll learn how to make your website measurably faster – from Core Web Vitals to CDN.

Intermediate8 min readLast updated: July 20, 2026

What you will learn

Why PageSpeed decides user experience, rankings and revenue
Which Core Web Vitals count in 2026 – LCP, INP and CLS – and their thresholds
How to measure speed correctly with field and lab data
The most important bottlenecks and how to eliminate them
Concrete core strategies from server to code and images to caching and CDN

PageSpeed in one sentence

PageSpeed is the time until a page's content is loaded and usable – and a direct lever for user experience, rankings and revenue. Google has confirmed it: page speed is a ranking factor, on desktop and mobile alike.

Users are impatient. According to Forrester, almost 50% leave a website if it doesn't load within 3 seconds; 74% of mobile users bounce if it takes longer than 5 seconds. Conversely, speed pays off: Walmart measured around 2% more conversions for every second of faster load time. Speed is therefore not a purely technical topic but a business fundamental.

Why PageSpeed matters so much

User experience: Under 100 milliseconds, a response feels instant. From about one second, the train of thought is preserved. From 3 to 5 seconds, frustration sets in – and slow pages leave a lasting negative impression.
Rankings: Slow pages cost visibility. They strain the crawl budget and score worse on the Core Web Vitals, which feed into Google's evaluation.
Conversions: Faster pages sell more and reduce server costs at the same time. Optimized pages need fewer resources.

With every additional second of load time, the bounce rate rises noticeably.

The Core Web Vitals in 2026

The Core Web Vitals are Google's central metrics for user experience. Three metrics currently count:

Metric	What it measures	Good value
Largest Contentful Paint (LCP)	Loading performance: when the largest visible element appears	under 2.5 s
Interaction to Next Paint (INP)	Interactivity: how quickly the page responds to input	under 200 ms
Cumulative Layout Shift (CLS)	Visual stability: unexpected layout shifts	under 0.1

Important for currency: INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Anyone still planning with FID is working with a discontinued metric. INP is stricter because it evaluates responsiveness across the entire session, not just the first interaction.

Google recommends looking at the 75th percentile of page views: the thresholds should be met for at least 75% of users.

Other relevant metrics

Time to First Byte (TTFB): The server's response time. A value under 200 ms is considered good; a high TTFB worsens all subsequent metrics.
First Contentful Paint (FCP): When the first visible content appears – an early signal that the page is loading.
Total Blocking Time (TBT): A lab metric for the time the page was blocked by long tasks (such as JavaScript). TBT is closely related to INP.

Measuring speed correctly

Distinguish two kinds of data:

Field data comes from real users under real conditions – sources are the Chrome User Experience Report (CrUX) or real-user monitoring. It shows the actual experience.
Lab data is generated under controlled, simulated conditions. Ideal for debugging, but it can deviate from reality.

For a complete picture you need both. Proven tools:

Google PageSpeed Insights: field and lab data plus concrete recommendations along the Core Web Vitals.
Google Search Console: the Core Web Vitals report shows field data from CrUX for your entire website.
Lighthouse & Chrome DevTools: lab data for performance directly in the browser.
WebPageTest, GTmetrix, Pingdom: detailed analyses and waterfall charts.
web-vitals JavaScript library: measures the Core Web Vitals in real users' browsers.

For an overview of the tool landscape, see PageSpeed tools.

Common bottlenecks

Before you optimize, you should know the typical causes:

Unoptimized images – files that are too large, the wrong format, unnecessary metadata. According to the HTTP Archive, images make up around two thirds of page weight on average.
Unoptimized code – whitespace, comments and unused CSS/JavaScript bloat files.
Render-blocking resources – CSS or JavaScript in the <head> that slows down page rendering.
Weak server performance – slow shared hosting or outdated software drives up the TTFB.
Too many HTTP requests and missing caching – every resource costs a request; without caching, everything loads anew on each visit.
No CDN, bloated databases and redirect chains (e.g. non-www → www → https).

The core optimization strategies

1. Optimize on the server side

Invest in good hosting – cheap shared hosting is often the bottleneck. Improve the TTFB through server-side caching and optimized database queries (target: under 200 ms). Current language versions (such as modern PHP versions) are considerably faster than old ones.

2. Keep code lean

Enable server-side compression with Brotli or Gzip – this often reduces file size by 70 to 90%. Minify CSS, JavaScript and HTML. Defer non-critical JavaScript with async or defer so it doesn't block rendering, and place critical CSS for the visible area inline in the <head>. Identify and remove unused code. Details on script-related problems can be found under JavaScript SEO.

3. Optimize images

Because images dominate page weight, optimizing them is essential:

Format: WebP (or AVIF) usually offers the best balance of quality and size. JPEG for color-rich photos, PNG for transparency, SVG for logos and icons. Avoid BMP and TIFF.
Dimensions: Scale images to the maximum display size before uploading and use srcset for responsive delivery.
Compression: Tools like Squoosh or TinyPNG reduce the size without visible quality loss.
Lazy loading: Load images only when they scroll into the visible area – natively via loading="lazy".

4. Use caching

With browser caching, users store static resources locally – controlled via Cache-Control or Expires headers, often for months. Server or page caching delivers pre-generated HTML pages instead of rebuilding them on every request.

5. Deploy a CDN

A Content Delivery Network stores your static content on servers close to the user. This noticeably reduces latency – especially for international visitors – and relieves the origin server. Providers like Cloudflare, KeyCDN or Amazon CloudFront can be put in front; how this layer can be used for SEO adjustments is shown in Edge SEO.

6. Reduce ballast

Scrutinize plugins, widgets and external scripts critically – every unused element burdens performance. Load tracking and social scripts asynchronously and minimize redirects so internal links lead directly to the final URL.

7. Optimize for mobile separately

The majority of traffic is mobile, and mobile networks are often slower. Optimize images and scripts for mobile devices especially aggressively and test mobile performance separately. More on this under Mobile SEO.

An ongoing process

PageSpeed is not a one-off project. Test regularly with PageSpeed Insights and the field data in Search Console, observe how new content or plugins change load time, and stay on top of technologies like HTTP/3 and modern image formats. Fast pages are an advantage for AI search systems too: what crawlers can render reliably and quickly is more likely to be captured and cited.

Conclusion

Optimizing page speed is one of the most effective measures there is – for happier users, better rankings and more revenue. With the right combination of server, code and image optimization, intelligent caching and a CDN, you deliver content fast. Measure against the current Core Web Vitals (LCP, INP, CLS), work deliberately on the biggest bottlenecks and keep at it.

FAQ

Frequently asked questions

LCP (under 2.5 s), INP (under 200 ms) and CLS (under 0.1). INP replaced FID as an official Core Web Vital in March 2024.

Yes. Google has officially confirmed page speed as a ranking factor for desktop and mobile search. The effect is real, but one factor among many – content quality remains decisive.

Field data comes from real users (e.g. CrUX) and shows the actual experience. Lab data is generated under controlled conditions and is suitable for debugging. For a complete picture you need both.

Often the most. Images make up around two thirds of page weight on average. Modern formats like WebP, correct dimensions and lazy loading reduce the weight drastically.

Quiz

Test your knowledge

Five questions on PageSpeed optimization and the Core Web Vitals.

Question 1 of 5

Which metric replaced First Input Delay (FID) as a Core Web Vital in 2024?