Page speed: what it is, why it matters and how to make your site faster

Page speed is how quickly a page shows its main content and responds to a visitor, measured with a handful of timings such as Largest Contentful Paint (when the main content appears) and Interaction to Next Paint (how quickly the page reacts to a tap). A fast page shows its main content within 2.5 seconds on a phone and reacts to taps within 200 milliseconds. This guide is the map of the topic for site owners and marketers: what page speed and website speed mean, why they matter for visitors and for Google, how to test them, and the fixes that make a slow site faster, in the order that pays off. Each section links to the guide that covers its part in depth.

Quick answer

• Page speed is several numbers, not one. The three that matter most are Google's Core Web Vitals: LCP (main content visible, good at 2.5 s or less), INP (reaction to input, good at 200 ms or less) and CLS (layout stability, good at 0.1 or less).
• Judge real visitors first, the lab second. Real-user (field) data from Chrome is what Google ranks with; the lab test explains why the numbers are what they are.
• Test on mobile. Phones are slower than laptops, Google indexes the mobile version of your pages, and the mobile result is where most sites fail.
• Fix in this order: a slow server (caching and hosting), the hero image, render-blocking CSS and JavaScript, third-party scripts, then layout shifts. Those five cover most slow pages.
• Change one thing at a time and re-test, so you know what helped and what broke.
• Check any page for free with the website speed test: Lighthouse on mobile and desktop plus real-visitor Core Web Vitals, with a fix for each slow part.

What is page speed?

Page speed describes how long a visitor waits at each stage of loading one page: the first byte from the server, the first text on screen, the main content, the moment the page reacts to a tap, and whether things jump around on the way. Website speed and site speed mean the same thing across all your pages, usually summarised by your most visited templates. Page load speed is often used for the whole experience, but the old "load time" (the browser's load event) is a poor measure: it counts files the visitor never sees and ignores whether the page could be used earlier.

Modern tools report these timings instead:

The Core Web Vitals thresholds and the 75th-percentile rule are Google's, published on web.dev; the TBT and Speed Index targets are Lighthouse's green ranges for mobile. The Core Web Vitals guide for site owners explains LCP, INP and CLS in visitor terms and the usual cause of each failing one.

Web performance and page speed optimization

Web performance is the discipline behind these numbers: making pages send less, send it sooner and do less work in the browser. Page speed optimization (or website speed optimization) is the practical side of it: finding the few things that make your pages slow and fixing them. The rest of this guide follows that path, from measuring to fixing to keeping the gains.

Why does page speed matter?

For visitors, speed decides whether they see your page at all. A blank screen for several seconds on a phone is long enough for people to go back to the search results, and a page that jumps as ads load makes them tap the wrong thing. Heavy pages also cost visitors mobile data, which matters on prepaid plans.

For search, Google says in its page experience documentation that "Core Web Vitals are used by our ranking systems", and that there is no single page experience signal. The same page is explicit that Google "always seeks to show the most relevant content, even if the page experience is sub-par". Speed is a tie-breaker between pages that answer the query equally well, not a way to outrank a better answer.

For the business, a fast page makes everything else you pay for work harder: ads land on a page that shows up, email clicks do not bounce off a spinner, and shoppers reach the checkout. Measure your own conversion rate before and after a speed fix rather than trusting a generic percentage.

Does page speed affect SEO?

Yes, through Core Web Vitals measured on real Chrome visitors, and less than content and relevance. Google has used speed in ranking since 2010 (desktop), added the Speed Update for mobile in 2018 and has measured it as LCP, INP and CLS since the page experience update of 2021. Every announcement has said the same thing: a relevant page can still rank when it is slow.

Speed also reaches SEO in two indirect ways. Googlebot crawls less when a server slows down or returns errors, which matters on large sites; and visitors who wait leave before the ranking pays off. The guide on how important page speed is for SEO covers the history, which numbers Google reads, the crawling effect and a decision order for when speed is worth prioritising. The short version: pass all three Core Web Vitals in the field on your main templates, then stop chasing lab points for SEO reasons.

What is a good page load time?

There is no single "good load time", because a page loads in stages. Use the Core Web Vitals thresholds as the target: main content visible within 2.5 seconds, reactions within 200 ms and layout shifts below 0.1, for at least 75 % of visits. A page that meets those feels fast even if the browser keeps downloading below-the-fold images for another few seconds.

Averages hide the problem. Google's thresholds use the 75th percentile precisely so that the slow quarter of your visitors, usually on older phones and weaker connections, counts. When someone tells you their site "loads in 1.2 seconds", ask on what device, on which network and at which percentile.

The targets are demanding but realistic. The HTTP Archive's 2025 Web Almanac found that about half of sites (48 %) passed all three Core Web Vitals on mobile, and that LCP was the one most often missed. The guide to what a good page load time is gives the target for each stage of loading, explains why the browser's old "load" time is a poor measure, and lists what decides the load time on each type of page.

How to check your website speed

Test the pages that carry your traffic, not only the home page: one product or service page, one article, one category or listing page and one landing page. Pages built from the same template share the same weight and the same problems, so four or five tests cover most sites.

The speed test runs Google's Lighthouse through the PageSpeed Insights API on mobile and desktop and shows real-visitor Core Web Vitals from the Chrome UX Report beside it, where Google has them. Every finding names the file responsible and what it costs. The same run is part of the full getReport report, next to SEO, security, accessibility and four more modules.

Field data and lab data: which to trust

Every good speed test shows two kinds of numbers. Field data is what real Chrome visitors experienced over the last 28 days, reported at the 75th percentile. Lab data is one simulated visit on a throttled phone in a data centre. Google ranks with field data; lab data is the diagnosis, because it is repeatable and shows the cause. When the two disagree, the field wins. The guide to field data vs lab data walks through the four combinations (both good, both poor, and the two mixed cases) and what to do in each.

Reading a speed test result

A speed test returns a score, five or six metrics and a long list of opportunities. The list is a set of causes, not a to-do list: most items are symptoms of two or three problems. The guide on how to read a website speed test takes you through a result in the right order: field bars first, then the LCP element, then the opportunities grouped by cause, then blocking time and layout shifts. It also covers why the score moves a few points on every run.

The Lighthouse score is not the goal

The 0–100 performance score is a weighted blend of five lab metrics. According to Chrome's Lighthouse scoring documentation, Total Blocking Time carries 30 %, LCP and CLS 25 % each, and FCP and Speed Index 10 % each; 90 and above is green. A page can score 100 in the lab and still fail Core Web Vitals for real visitors, and the reverse happens too. The guide Lighthouse score vs Core Web Vitals: why 100 does not mean fast explains the weighting and how PageSpeed Insights and Lighthouse relate.

Why mobile is slower than desktop

The same page often scores 95 on desktop and 55 on mobile. That is not a bug: PageSpeed Insights tests mobile on a simulated mid-range phone with a slower connection and a CPU slowed down four times, so JavaScript that runs quickly on your laptop takes much longer. Since Google indexes the mobile version of your pages, the mobile numbers are the ones to work on. The guide to mobile vs desktop scores shows what is simulated and what to fix first.

First Contentful Paint and Speed Index

FCP marks the first text or image on screen; Speed Index measures how quickly the visible area fills up. Neither is a Core Web Vital, but a slow FCP delays everything after it, and both point at the same causes: a slow server and render-blocking files. The guide on Speed Index and First Contentful Paint explains what moves each and how they relate to LCP.

Waterfalls and filmstrips: where the seconds go

When the metrics say "slow" but not "why", two views answer it. The request waterfall lists every file the page loads, when it started and how long it took; long chains and late-starting hero images stand out. The filmstrip shows what the visitor saw at each moment, so you can match "blank for 2 seconds" to the file that caused it. Reading a waterfall chart and filmstrip shows how to read both, bar by bar and frame by frame.

Testing many pages or comparing with competitors

For a list of URLs, the bulk tool runs the same PageSpeed Insights test on up to 50 pages and puts score, LCP, TBT and CLS in one sortable table you can export as CSV.

To see whether you are faster or slower than the sites you compete with, the comparison tool puts your site next to up to four others on the same device, with the best site in each row marked.

Why is my website slow?

Slow sites are rarely slow everywhere. Usually two or three heavy things do most of the damage, and they are the same few on most sites:

1. A slow server. No page caching, an overloaded shared host or a database doing work on every visit. You see it as a high TTFB, and every other metric starts late.
2. A heavy hero image. A photo uploaded straight from a camera or stock site, several megabytes, sometimes lazy-loaded by mistake. It is the LCP element on many pages.
3. Render-blocking CSS and JavaScript. Stylesheets and scripts in the <head> that the browser must download before it draws anything.
4. Too much JavaScript, often from third parties. Chat widgets, tag managers, A/B testing, ad scripts and social embeds that keep the phone's processor busy, which hurts INP and TBT.
5. Web fonts and missing image dimensions, which cause text to appear late or the layout to jump.

Your own internet connection is rarely the reason other visitors see a slow site; a fast office line hides problems a phone on a mobile network shows. Each cause leaves its own pattern in a speed test: a high time to first byte points at the server, a fast first byte with a late main image at the image, a blank screen with a fast server at render-blocking files, and a high blocking time at JavaScript.

The diagnostic guide why is my website slow? turns those patterns into a symptom table with the tool that confirms each cause, and covers sites that are slow only sometimes or only for some visitors.

How to improve page speed, step by step

Work through these in order. Each step fixes a cause that also slows the steps after it, so the order matters more than the number of tweaks. Re-test after each change.

1. Make the server answer quickly

Everything waits for the first byte. For a CMS such as WordPress, the biggest win is full-page caching, so the server hands out a ready-made HTML file instead of building each page from the database. Lighthouse flags a server response over 600 ms; web.dev calls a TTFB of 0.8 s or less good. If caching is on and the server is still slow, the host is the limit.

A CDN puts copies of your files near your visitors and can cache whole pages at the edge, which helps most when your visitors are far from your server. It does not fix a slow uncached server behind it. Read TTFB: what a slow server looks like to tell DNS, connection and server time apart, and CDN basics before you switch one on.

2. Fix the images, starting with the hero

Images are usually the heaviest part of a page. Resize each image to the size it is shown at, save photos as WebP or AVIF, give every image width and height attributes, lazy-load images below the fold and never lazy-load the main image at the top. On the LCP image, fetchpriority="high" tells the browser to fetch it first.

The image optimization guide covers format, compression, responsive images and loading in full, with the tools to find and shrink heavy files.

3. Remove render-blocking CSS and JavaScript

The browser cannot draw the page until the stylesheets and synchronous scripts in <head> have arrived. Add defer to scripts that are not needed for the first screen, load plugin CSS only on pages that use it, and consider inlining the small amount of CSS the first screen needs. The guide to render-blocking resources shows how to find each file and fix it on plain HTML, WordPress and Shopify.

4. Cut JavaScript, especially from third parties

JavaScript is the most expensive thing a page can send, byte for byte, because the phone must download it and then run it. Unused code and third-party tags are what make INP and TBT poor. List every third party on the page and what it gives you, remove the ones nobody looks at, and load the rest later or behind a click (a static thumbnail instead of a YouTube player, a chat button that loads the widget when tapped). The guides on third-party scripts and long tasks and main-thread work go through it.

5. Stop the layout from jumping

Layout shifts come from images and embeds without reserved space, ads and banners injected above content, and web fonts that swap in at a different size. Reserve space with width/height or CSS aspect-ratio, keep injected content below what the visitor is reading, and match your fallback font's size. See fix Cumulative Layout Shift and web fonts without layout shift.

6. Compress, cache and avoid redirects

Three server settings that cost nothing once set:

• Text compression: HTML, CSS, JavaScript and SVG should be served with Brotli or gzip. Most hosts and every major CDN can do it; see text compression with gzip and Brotli.
• Browser caching: files with a version in their name (app.3f9a1c.js) can be cached for a year; HTML should be revalidated. Cache-Control for humans has the headers to copy.
• No redirect chains: every hop (http → https → www → trailing slash) is a round trip before anything loads. Point links and ads at the final URL.

7. Measure again, in the field

After the lab numbers improve, wait. Field data covers the last 28 days, so a fix takes up to four weeks to show fully in the Chrome UX Report and in Search Console's Core Web Vitals report. Keep the report link from before the change, so you can compare once the new data is in.

Page speed on WordPress, Shopify and other platforms

The fixes above apply everywhere, but where you make them depends on the platform.

WordPress. Most slow WordPress sites share the same causes: no page cache or two caching plugins fighting, a heavy page builder, too many plugins loading scripts on every page, and cheap shared hosting. The guide on how to speed up a WordPress site takes the fixes in order, from one page cache and current PHP to plugins, images, scripts and background jobs. For the individual parts, see WP Rocket settings for Core Web Vitals, LiteSpeed Cache settings, why two caching plugins break things, page builders vs Gutenberg and what each plugin costs in speed.

Shopify. Hosting, the CDN, image formats and HTTP/2 are handled by Shopify, so your levers are the apps (each can add scripts to every page), your images, the theme's Liquid and fonts. Shopify's own Web performance report, on the Online Store → Themes page, shows real-shopper LCP, INP and CLS; a lab test on a product and a collection page shows which app or image is responsible.

The guide to Shopify speed optimization takes those levers in order: app embeds and leftover app code first, then the hero and product images, tracking pixels, fonts and slow Liquid, with what not to do (speed-booster apps are usually one more script). Shopify: what you can fix and what you cannot sorts every report finding into yours, Shopify's and ones to ignore.

Wix, Squarespace and Webflow. You control less of the code, so focus on image sizes, the number of embeds and apps, and fonts. See the notes for Wix, Squarespace and Webflow.

Static and headless sites. They start fast, and lose it through large JavaScript bundles and client-side rendering. Keep the main content in the HTML and set long cache lifetimes on hashed files; static sites: headers and caching has the configuration.

How to keep a site fast

Sites rarely get slow in one go. They get slow one plugin, one tag and one uncompressed banner at a time. Three habits prevent that:

• Set a speed budget. Decide limits from your own numbers (for example LCP under 2.5 s and JavaScript under a given size on your product template) and check them before each release. The guide on speed budgets shows how to write one and make a build fail when it is broken.
• Measure before and after big changes. A redesign, a new theme or a new tag manager container can undo a year of work. Measuring before and after a redesign gives the baseline and the checkpoints.
• Re-test on a schedule. A monthly check of your main templates catches slow drift; the monthly site health routine includes it. Daily speed monitoring with email alerts is a funded unlock in getReport: it switches on for everyone once donations cover it.

Common mistakes

• Chasing the score instead of the visitor. A lab 100 built by deferring everything can still feel broken. Aim for passing Core Web Vitals in the field.
• Testing only the home page. Product, article and category templates carry most of the traffic and have different problems.
• Testing on your office laptop. Fast Wi-Fi and a new laptop hide what a phone on a mobile network shows. Use the mobile test.
• Installing a plugin to fix a plugin. Each optimisation plugin adds its own code and settings that can clash. Remove before you add.
• Lazy-loading the hero image. It makes LCP slower, not faster.
• Changing ten things at once. When something breaks, you will not know which change did it. One change, one re-test.

Questions people ask

What is the fastest way to improve website speed?

Turn on full-page caching and fix the main image at the top of your most visited page. Caching makes the server answer in a fraction of the time, and a resized WebP hero image is often the single biggest LCP gain on phones. Both are quick jobs on most sites. Run a speed test before and after, so you can see which change helped, then move on to render-blocking files.

How do I increase website speed on a small budget?

Most speed gains cost nothing but time. Use your host's or a free caching plugin, compress and resize images before uploading them, remove plugins, widgets and tags nobody uses, and switch on the free tier of a CDN if your visitors are far from your server. Pay for better hosting only once caching is on and the server response is still over 600 ms.

How can I check page speed on mobile and desktop?

Run a speed test that measures both profiles, such as getReport's free website speed test, which runs Lighthouse on a simulated phone and on desktop and shows real-visitor Core Web Vitals for each. Expect the mobile score to be much lower, because it simulates a slower connection and CPU. Work on the mobile numbers first, since Google indexes the mobile version of your pages.

How do I get reliable results when I test page speed?

Run each test two or three times and compare the metrics, not the score. Lab results move a few points between runs because servers, caches and third-party scripts vary. Test the same pages each time, at the same kind of hour, and keep the report links. For the verdict, trust the 28-day field data from real visitors over any single lab run.

How do I speed up a website without a developer?

Most of the work can be done from your CMS. Compress and resize images before you upload them, switch on your host's page cache or a caching plugin, remove unused plugins, apps and embeds, and replace embedded videos with a thumbnail that links to the player. Leave render-blocking code and JavaScript changes to a developer, and send them the report link with the findings.

What is page speed?

Page speed is how quickly a single page shows its content and responds to a visitor. It is measured with several timings rather than one number: the server's first byte, the first content on screen, the main content (LCP), reaction to taps (INP) and layout stability (CLS). Google uses those last three, the Core Web Vitals, from real Chrome visitors.

How do I make my website faster on phones?

Send less JavaScript and smaller images, because phones have slower processors and connections than laptops. Remove third-party scripts you do not need, defer the rest, serve images at the size a phone displays them with srcset, and make sure the server answers quickly. Test with the mobile profile, which simulates a mid-range phone, and confirm with real-visitor field data.

Is page speed the same as Core Web Vitals?

No, Core Web Vitals are part of page speed. They are the three measurements Google picked to describe loading, responsiveness and visual stability: LCP, INP and CLS, taken from real Chrome visitors. Page speed also includes server response time, First Contentful Paint and lab-only metrics like Total Blocking Time, which help explain why a Core Web Vital fails.