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

> Page speed is how quickly a page shows its content and responds to visitors. What the numbers mean, what a good result is, how to test it and the fixes that help most.

Updated 2026-09-26 · Speed & Core Web Vitals · HTML version: https://getreport.app/guides/page-speed

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](https://getreport.app/tools/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:

| Metric | What it answers for the visitor | Good | Where it comes from |
| --- | --- | --- | --- |
| **TTFB** Time to First Byte | Is the server answering? | ≤ 0.8 s | Field and lab |
| **FCP** First Contentful Paint | Has anything appeared yet? | ≤ 1.8 s | Field and lab |
| **LCP** Largest Contentful Paint | Is the main content visible? | ≤ 2.5 s | Field and lab (Core Web Vital) |
| **INP** Interaction to Next Paint | Does the page react when I tap? | ≤ 200 ms | Field only (Core Web Vital) |
| **CLS** Cumulative Layout Shift | Does the page jump while I read? | ≤ 0.1 | Field and lab (Core Web Vital) |
| **TBT** Total Blocking Time | How long is the page too busy to respond? | ≤ 200 ms | Lab only, stands in for INP |
| **Speed Index** | How quickly does the screen fill up? | ≤ 3.4 s on mobile | Lab only |

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](https://getreport.app/guides/core-web-vitals-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](https://getreport.app/guides/page-speed-and-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](https://getreport.app/guides/what-is-a-good-page-load-time) 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.

> **Free tool:** [Free website speed test and page speed check](https://getreport.app/tools/speed-test): Free website speed test for any page: Lighthouse lab results and real-user Core Web Vitals on mobile and desktop, with a fix for each slow part. No sign-up.

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.

> **Check: Largest Contentful Paint.** LCP is when the biggest thing on screen — usually the hero image or headline — finishes loading. Visitors judge "is this site slow?" on it, and Google uses it for ranking.
>
> 1. Find the LCP element (named in your report) and make it lighter, earlier or both — a compressed WebP/AVIF, sized to the screen, without lazy loading.
> 2. Preload it with <link rel="preload" as="image"> or add fetchpriority="high" on the <img>.
> 3. Cut what comes before it — render-blocking CSS/JS and slow server responses push LCP back.

> **Check: Interaction to Next Paint.** INP measures how quickly the page reacts when someone taps or clicks. Lab tools cannot simulate it, so this comes from real Chrome users; slow responses feel like a frozen page.
>
> 1. Break up long JavaScript tasks and defer third-party scripts so the main thread is free when people interact.
> 2. Respond to input visually first (a pressed state, a spinner), then do the heavy work.
> 3. Reduce DOM size and avoid layout-heavy work inside click handlers.

> **Check: Cumulative Layout Shift.** CLS measures how much the page jumps around while loading — the button that moves just as someone taps it. It is one of Google's three Core Web Vitals.
>
> 1. Give every <img>, <video>, ad slot and embed explicit width and height (or aspect-ratio) so space is reserved before it loads.
> 2. Preload the main web font and use font-display optional, or swap with a size-adjusted fallback font, so text does not reflow.
> 3. Never insert banners or content above existing content after load.

### 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](https://getreport.app/guides/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](https://getreport.app/guides/reading-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](https://getreport.app/guides/lighthouse-score-vs-core-web-vitals-why-100-does-not-mean-fast) explains the weighting and how PageSpeed Insights and Lighthouse relate.

> **Check: Lighthouse performance score.** This is the number Google's own tools show for your page. It combines five of the lab metrics below (all except TTFB), weighted the way Lighthouse weights them. 90 and above is green.
>
> 1. Work through the failed metrics and opportunities below in order of points; the score follows.

### 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](https://getreport.app/guides/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](https://getreport.app/guides/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](https://getreport.app/guides/reading-a-waterfall-chart) 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.

> **Free tool:** [Bulk PageSpeed Insights: test 50 URLs at once](https://getreport.app/tools/bulk-pagespeed): Free bulk PageSpeed Insights: run Google's Lighthouse test on up to 50 URLs at once, with Core Web Vitals, LCP, TBT and CLS in a sortable table and 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.

> **Free tool:** [Website speed test comparison: up to 5 sites](https://getreport.app/tools/compare-speed): Free website speed test comparison: put your site next to up to four competitors on PageSpeed score, real-user Core Web Vitals, page weight and requests.

## 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?](https://getreport.app/guides/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.

> **Check: Server response time.** Lighthouse flags a first byte slower than 600 ms. Caching and hosting fix this for most CMS sites.
>
> 1. Enable full-page caching (WordPress: WP Rocket, LiteSpeed Cache, WP Super Cache; or your host's server cache).
> 2. Use a CDN and keep database queries out of the request path.

> **Check: Third-party code weight.** Tags, widgets and embeds from other companies run on your visitors' phones at your page's expense. Over 250 KB or 250 ms of blocking is a sign they dominate the load.
>
> 1. List what each third party gives you; remove the ones nobody looks at.
> 2. Load the rest after interaction or with a facade (a static thumbnail for YouTube, a click-to-load chat button).
> 3. Move tags into a tag manager that fires them late, not in <head>.

## 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](https://getreport.app/guides/ttfb-what-a-slow-server-looks-like) to tell DNS, connection and server time apart, and [CDN basics](https://getreport.app/guides/cdn-basics-what-it-fixes-and-what-it-does-not) before you switch one on.

> **Check: Time to First Byte.** TTFB is how long the server takes to start answering. Everything else waits for it, so a slow first byte makes every other metric worse. Google's 800 ms target is for real visitors, network included; Lighthouse flags the server's own share above 600 ms (see server response time).
>
> 1. Add page caching (WordPress: WP Rocket, LiteSpeed Cache, or your host's cache; Shopify does this for you).
> 2. Put a CDN in front (Cloudflare, Bunny) so the first byte comes from a nearby edge.
> 3. Check database-heavy plugins and slow hosting; a plan with more CPU often fixes this outright.

### 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](https://getreport.app/guides/image-optimization) covers format, compression, responsive images and loading in full, with the tools to find and shrink heavy files.

> **Check: Images are sized for how they are displayed.** Sending a 2000 px photo to a 400 px slot wastes most of the bytes. Responsive images let the browser pick the right size for each screen.
>
> 1. Add srcset and sizes to <img> so phones get small versions; most CMSs generate the sizes for you.
> 2. Resize the originals to the largest size you actually display.

> **Check: Images are served in modern formats (WebP or AVIF).** WebP and AVIF are 25–50 % smaller than JPEG and PNG at the same quality. Smaller images load faster and cost visitors less data.
>
> 1. Convert images to WebP or AVIF and serve them with <picture> or content negotiation.
> 2. WordPress: enable WebP/AVIF in your image plugin or CDN (Imagify, ShortPixel, Cloudflare Polish); Shopify does this automatically for its CDN.

### 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](https://getreport.app/guides/render-blocking-resources) shows how to find each file and fix it on plain HTML, WordPress and Shopify.

> **Check: No render-blocking resources delay the first paint.** Stylesheets and scripts in <head> stop the browser from drawing anything until they have downloaded. Each one adds a round trip before the visitor sees the page.
>
> 1. Add defer or async to scripts that are not needed before the first paint, or move them to the end of <body>.
> 2. Inline the CSS needed for the first screen and load the rest asynchronously (WordPress: "Optimize CSS delivery" in WP Rocket / LiteSpeed Cache).
> 3. Remove unused plugin CSS/JS from pages that do not need it.

### 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](https://getreport.app/guides/third-party-scripts-tag-managers-chat-and-ads) and [long tasks and main-thread work](https://getreport.app/guides/long-tasks-and-main-thread-work) go through it.

> **Check: Little unused JavaScript is downloaded.** JavaScript is the most expensive thing a page loads — it must be downloaded, parsed and run. Code that never executes still costs all of that on a phone.
>
> 1. Delay third-party scripts until interaction (WP Rocket "Delay JavaScript", Shopify: audit installed apps).
> 2. Code-split large bundles so each page loads only its own code.
> 3. Remove plugins, apps and tags you no longer use.

### 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](https://getreport.app/guides/fix-cumulative-layout-shift) and [web fonts without layout shift](https://getreport.app/guides/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](https://getreport.app/guides/text-compression-gzip-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](https://getreport.app/guides/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.

> **Check: Text files are compressed.** HTML, CSS and JavaScript shrink by 70–90 % with Brotli or gzip. Without it every visitor downloads several times more than needed.
>
> 1. Turn on Brotli or gzip on the server or CDN (Cloudflare does it automatically; Apache mod_deflate/brotli; nginx gzip on).
> 2. Check that your CDN or plugin is not serving already-compressed assets without the Content-Encoding header.

> **Check: Static files have long cache lifetimes.** Images, fonts, CSS and JS rarely change, yet without a long Cache-Control lifetime returning visitors download them again on every page.
>
> 1. Set Cache-Control max-age of a year on versioned static files (most CDNs and caching plugins have a "browser caching" switch).
> 2. Add a version or hash to file names so you can still change them.

### 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](https://getreport.app/guides/speed-up-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](https://getreport.app/guides/wp-rocket-settings-for-core-web-vitals), [LiteSpeed Cache settings](https://getreport.app/guides/litespeed-cache-settings-for-core-web-vitals), [why two caching plugins break things](https://getreport.app/guides/two-caching-plugins-why-it-breaks-and-which-to-keep), [page builders vs Gutenberg](https://getreport.app/guides/page-builders-vs-gutenberg-the-performance-reality) and [what each plugin costs in speed](https://getreport.app/guides/wordpress-plugin-cost).

**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](https://getreport.app/guides/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](https://getreport.app/guides/shopify-what-you-can-and-cannot-fix) 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](https://getreport.app/guides/wix-speed-and-seo-limits), [Squarespace](https://getreport.app/guides/squarespace-the-checklist) and [Webflow](https://getreport.app/guides/webflow-performance-and-seo-settings).

**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](https://getreport.app/guides/netlify-and-vercel-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](https://getreport.app/guides/speed-budgets-setting-one-and-holding-to-it-in-ci) 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](https://getreport.app/guides/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](https://getreport.app/guides/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.