Page speed is the measurement of how quickly a webpage's content loads and becomes usable. It operates on a spectrum — from the server's first byte to full interactivity — with Google tracking three specific signals: LCP (how fast main content renders), INP (how fast the page responds to clicks), and CLS (whether content jumps around during load). A 1-second delay increases bounce probability by 32%. At 5 seconds, bounce probability hits 90%.
Page speed is where SEO and user experience meet. A slow page doesn't just frustrate visitors — it bleeds rankings, inflates bounce rates, and caps conversions. Get it right, and faster crawling, better rankings, and lower abandonment follow as a package.
What is page speed?
Page speed measures loading velocity and usability for a single URL — not an entire domain. It differs from site speed, which averages load performance across a domain. Load time is not a single number but a cascade of events:
- Time to First Byte (TTFB): How quickly the server responds. Good threshold: under 600ms.
- First Contentful Paint (FCP): When the first content element (text or image) appears. Good: under 1.8 seconds.
- Largest Contentful Paint (LCP): When the main content finishes rendering. Good: under 2.5 seconds.
- Interaction to Next Paint (INP): How fast the page responds to user clicks and taps. Good: under 200ms. Replaced First Input Delay in 2024.
- Cumulative Layout Shift (CLS): Visual stability — how much content jumps during load. Good: under 0.1.
Google added page speed as a ranking factor for mobile in 2018. In 2021, Core Web Vitals (LCP, INP, CLS) became explicit ranking signals via the Page Experience Update. Google evaluates field data from the Chrome User Experience Report (CrUX), not just lab scores, for ranking purposes.
Why page speed matters for SEO and conversions
Slow pages create two compounding problems: lost rankings and lost conversions. Here is how the numbers stack up:
- Bounce rate escalation. Bounce probability increases 32% when load time rises from 1 to 3 seconds. At 5 seconds it reaches 90%. At 10 seconds, 123% more visitors leave than at 1 second (Google/SOASTA research).
- Revenue destruction at scale. Amazon calculated a 1-second delay could cost $1.6 billion annually. Even a 100ms delay creates measurable revenue decline at significant traffic volumes.
- Mobile penalty amplified. 60%+ of searches occur on mobile where connections are slower. Mobile-first indexing means Google evaluates the mobile version of your page first.
- Crawl budget efficiency. Slow pages get crawled less frequently. Googlebot allocates crawl budget based on server response speed — faster sites get more pages indexed more often.
- Core Web Vitals as ranking signal. Failing LCP, INP, or CLS thresholds creates a direct ranking disadvantage against otherwise equal competitors.
How page speed works — the technical stack
Every request involves four stages that each contribute to total load time:
1. Server response (TTFB)
The browser sends an HTTP request and waits for the server's first byte of data. TTFB exceeding 600ms signals a server or infrastructure problem. CDNs (Content Delivery Networks) reduce geographic latency by serving pages from edge nodes close to the user.
2. Resource loading
Browsers must download CSS, JavaScript, images, fonts, and video. A single 5MB uncompressed image adds 3-4 seconds on mobile. Render-blocking scripts delay visual completion because the browser pauses HTML parsing to execute JavaScript.
3. Rendering
The browser constructs the DOM (HTML), applies CSSOM (styles), and runs JavaScript. Heavy client-side rendering frameworks push this stage later — everything the user sees must wait for JavaScript to execute before content appears.
4. Interactivity and stability
INP measures how quickly the page responds after a user click or tap. CLS tracks whether content moves during load — text jumping when ads load, buttons shifting when images appear, layouts reflowing when fonts swap. Each layout shift deducts from the CLS score.
Core page speed metrics — the complete reference
| Metric | What it measures | Good threshold | Ranking signal |
|---|---|---|---|
| LCP | Largest element load time | Under 2.5 seconds | Yes (Core Web Vital) |
| INP | Interaction responsiveness | Under 200ms | Yes (Core Web Vital) |
| CLS | Visual stability score | Under 0.1 | Yes (Core Web Vital) |
| FCP | First content appears | Under 1.8 seconds | Indirect |
| TTFB | Server response speed | Under 600ms | Indirect |
Real page speed examples
1. Local restaurant — from 14 seconds to 2.8 seconds
A restaurant site loaded a 52MB homepage with 12 uncompressed photos (4MB each), 3 Google Maps iframes, and a Facebook widget. Mobile load time: 14 seconds. PageSpeed score: 18/100. After image compression (WebP, resized to display dimensions), lazy-loading, and widget removal, load time dropped to 2.8 seconds and score climbed to 82. Bounce rate fell 40%.
2. E-commerce — halving load time doubled mobile conversions
A product page loaded in 6.2 seconds with 73% mobile abandonment. Root cause: a 1.2MB render-blocking JavaScript bundle loading synchronously in the <head>. After code-splitting, deferred loading, image optimisation, and CDN deployment, load time fell to 2.1 seconds. Mobile conversion rate doubled.
3. Content blog — static generation as the unfair advantage
Articles published through a static site generator load under 2 seconds by default. No database queries, no server-side rendering delays — pre-built HTML served directly from CDN edge nodes. Faster crawling means new content gets indexed within hours, not days.
Page speed vs. Core Web Vitals — which one matters for Google?
Page speed is the broad concept. Core Web Vitals are Google's specific three-metric subset of page speed signals that directly affect rankings.
Page speed (broad)
- Encompasses all load metrics (TTFB, FCP, LCP, INP, CLS, TTI)
- Measured by PageSpeed Insights, Lighthouse, GTmetrix
- Useful for diagnosing performance issues comprehensively
- Composite score (0-100) for benchmarking
- Influences conversions, bounce rate, and crawl efficiency
Core Web Vitals (ranking signals)
- Only three metrics: LCP, INP, CLS
- Evaluated from real Chrome user field data (CrUX)
- Direct Google ranking factor since 2021
- Pass/Fail against fixed thresholds
- Shown in Google Search Console as site-wide report
6 page speed optimisation best practices
- Compress and resize images to display dimensions. Convert to WebP or AVIF. A hero image displayed at 800px wide should be 800px — not 4000px scaled down by CSS. This single change often eliminates 50-70% of page weight.
- Implement native lazy loading. Add
loading="lazy"to all images below the fold. The browser skips downloading them until the user scrolls close, reducing initial page weight significantly. - Defer non-critical JavaScript. Add
deferorasyncattributes to non-critical scripts. Move analytics and chat widgets to load after the page is interactive. - Deploy a CDN. Serve static assets (images, CSS, JavaScript, fonts) from edge nodes geographically close to users. CDNs typically reduce TTFB by 60-80% for geographically dispersed audiences.
- Inline critical CSS. Extract the CSS needed to render above-the-fold content and inline it in the
<head>. Eliminates the render-blocking external CSS request for the first paint. - Monitor field data, not just lab data. PageSpeed Insights lab scores are synthetic. Google ranks based on real user data from CrUX. Track Core Web Vitals in Google Search Console for actual ranking-relevant performance.
A PageSpeed score of 95 does not guarantee passing Core Web Vitals. Google uses real Chrome user data (CrUX), not synthetic lab tests, for ranking. A page tested at 1.8s LCP in the lab may consistently deliver 3.2s LCP to real mobile users on 4G. Always validate against Search Console field data before declaring victory.
Common page speed mistakes to avoid
- Serving full-resolution images — 4000px images scaled to 400px via CSS waste bandwidth on every page load.
- Loading all JavaScript synchronously — render-blocking scripts in the
<head>delay first paint for every visitor. - Embedding third-party widgets uncritically — a single Facebook Like button adds 3-4 external HTTP requests and can add 500ms to load time.
- Ignoring font loading — unoptimised Google Fonts adds 2-3 render-blocking requests. Use
font-display: swapand preconnect hints. - Confusing mobile and desktop scores — Google ranks mobile versions. A desktop score of 90 with a mobile score of 45 means the ranking version is underperforming.
- Treating CLS as secondary — layout shifts below the fold still accumulate in the CLS score and affect rankings.
Frequently asked questions
A Google PageSpeed Insights score of 90-100 is excellent, 50-89 is average, and below 50 needs work. Focus on the actual metrics: LCP under 2.5 seconds and INP under 200 milliseconds matter more for rankings than the composite score.
Yes. Google designated page speed as a ranking factor in 2018. Core Web Vitals became explicit ranking signals in 2021. Mobile pages with slower speeds rank lower, with the most noticeable impact when comparing pages of similar content quality and domain authority.
Google PageSpeed Insights (free) provides lab and field data from real Chrome users. Chrome DevTools Lighthouse, WebPageTest.org, and GTmetrix offer deeper waterfall analysis. Google Search Console's Core Web Vitals report shows site-wide performance trends from actual visitors.
Large uncompressed images, render-blocking JavaScript, slow server response times, and excessive third-party scripts (analytics, chat, ads). Images are almost always the biggest offender and the easiest to fix — converting to WebP and resizing to display dimensions typically cuts page weight by 50-70%.
Page speed measures the load performance of a single URL. Site speed is an average across multiple sampled pages on a domain. Google evaluates page speed at the individual URL level for Core Web Vitals ranking purposes, not a domain-wide average.
Related glossary terms
Sources
