What is Page Speed? SEO Guide for Beginners

Learn what page speed means in SEO, why it matters, and how to use it to improve your search rankings.

Page speed is a measurement of how quickly the content on a web page loads, directly impacting both user experience and search rankings. It encompasses multiple metrics including how fast the server responds (TTFB), how quickly the main content appears (LCP), and how soon the page becomes interactive (INP). Google's official position is that Core Web Vitals, which capture loading speed, interactivity, and visual stability, are used by its ranking systems as part of the broader page experience signal. Google is also clear that this is not a single dominant factor. Search "always seeks to show the most relevant content, even if the page experience is sub-par," and a great page experience mainly helps win when several results are otherwise similarly relevant (Google Search Central, Understanding Page Experience).

Why Page Speed Matters for SEO

Speed is not just a technical metric. It is a user experience signal that affects every aspect of your site's performance. Amazon famously found that every 100ms increase in load time cost them 1% in sales. Google's own research shows that 53% of mobile users abandon a site that takes more than 3 seconds to load.

For SEO specifically, page speed feeds into the three Core Web Vitals (LCP, CLS, INP), crawl efficiency (slow sites get crawled less), and user engagement metrics (fast sites have lower bounce rates and higher time on page). When Google can crawl your site faster, it discovers and indexes new content quicker, which is especially important for sites that publish frequently. One detail many people miss is that Core Web Vitals are judged on real-user field data at the 75th percentile, segmented across mobile and desktop, not on a single lab score. That means a page is graded "good" only when at least 75 percent of real visits hit the threshold (web.dev, Web Vitals).

The competitive advantage of speed compounds over time. A site that loads in 1 second feels instant. A site that loads in 3 seconds feels normal. A site that loads in 5 seconds feels frustrating. In a world where users can get similar content from dozens of sources, they will always gravitate toward the faster experience. I consistently see my fastest pages outperform slower competitors even when the competitors have more backlinks, simply because the user experience is dramatically better.

How Page Speed Works

Page speed is not a single number. It is a combination of metrics that capture different aspects of the loading experience. The most important ones for SEO are:

Largest Contentful Paint (LCP) measures when the main content is visible. This is the metric users care about most because it represents when the page "feels" loaded. The "good" threshold is 2.5 seconds or less at the 75th percentile (web.dev, LCP).

Interaction to Next Paint (INP) measures responsiveness to user input. It tracks how quickly the page reacts to clicks, taps, and keystrokes across the whole visit. The "good" threshold is 200 milliseconds or less. INP became a stable Core Web Vital on March 12, 2024, replacing First Input Delay (FID), which has since been retired (web.dev, INP becomes a Core Web Vital).

Cumulative Layout Shift (CLS) measures visual stability. It tracks how much page elements jump around during loading. The "good" threshold is 0.1 or less (web.dev, CLS).

LCP, INP, and CLS are the three Core Web Vitals. A supporting diagnostic metric also matters for speed work:

Time to First Byte (TTFB) measures server responsiveness. It covers redirect time, DNS lookup, connection and TLS setup, and server processing before the first byte of the response arrives. TTFB is not a Core Web Vital, but web.dev recommends most sites aim for a TTFB of 0.8 seconds or less so the server does not eat into the LCP budget (web.dev, TTFB).

PageSpeed Insights also reports a lab Performance score from 0 to 100 that blends several lab metrics. A score of 90 or above is considered good, 50 to 89 needs improvement, and below 50 is poor. Treat that lab score as a diagnostic tool. The Core Web Vitals assessment Google actually uses for the page experience signal comes from real-user field data, not the lab score.

How to Improve Page Speed on Your Site

Optimize and compress images - Images are typically the largest assets on a page. Convert to WebP or AVIF format, resize to the display size (not larger), and use responsive srcset attributes. Tools like Squoosh, Sharp, or Cloudflare's automatic image optimization handle this well.

Minimize and defer JavaScript - Audit your JavaScript bundles for unused code. Use code splitting to load only what each page needs. Defer non-critical scripts with the defer attribute and consider removing third-party scripts that add minimal value but significant load time.

Use a CDN for static assets - Serve your CSS, JavaScript, images, and fonts from a CDN like Cloudflare, Fastly, or CloudFront. Edge caching puts your files closer to users worldwide and can cut load times by 50% or more for visitors far from your origin server.

Enable compression and caching - Enable Gzip or Brotli compression on your server to reduce file transfer sizes by 60-80%. Set proper cache headers (Cache-Control, ETag) so returning visitors load assets from their browser cache instead of re-downloading.

Choose a performance-first framework - Static site generators like Astro ship zero JavaScript by default, resulting in pages that load almost instantly. If you need interactivity, Astro's island architecture loads JavaScript only for components that need it, keeping the rest of the page fast.

Common Mistakes to Avoid

Testing only on fast connections: PageSpeed Insights simulates a throttled mobile connection. Test your site under realistic conditions using Chrome DevTools network throttling set to "Fast 3G" to understand what your actual users experience.
Overloading with third-party scripts: Each analytics tracker, marketing pixel, chat widget, and A/B testing tool adds weight to your page. Audit all third-party scripts quarterly and remove anything that is not actively providing value. The performance cost of running 10+ third-party scripts is enormous.
Ignoring web font loading: Custom fonts can add 200-500KB of downloads and cause layout shifts during loading. Use font-display: swap to prevent invisible text, limit font variants to what you actually use, and preload your primary font files.

In Practice

A common LCP problem is a hero image that the browser only discovers late, after it has parsed the CSS. The fix is to mark the image as high priority and skip lazy loading so the browser fetches it immediately. A before and after on the same hero looks like this:

Before, the LCP image is lazy loaded and competes with everything else:

<img src="/blog-images/hero.png" alt="Hero" loading="lazy" />

After, the image is eager, fetched at high priority, and decoded asynchronously so it does not block the main thread:

<link rel="preload" as="image" href="/blog-images/hero.png" fetchpriority="high" />

<img
  src="/blog-images/hero.png"
  alt="Hero"
  loading="eager"
  fetchpriority="high"
  decoding="async"
  width="1200"
  height="630"
/>

The explicit width and height also reserve the correct space in the layout, which prevents the image from shoving content down once it loads and protects your CLS score. On the server side, pairing this with Brotli compression and a long cache lifetime keeps TTFB low so the server response does not eat into the 2.5 second LCP budget:

Content-Encoding: br
Cache-Control: public, max-age=31536000, immutable

After shipping that change, confirm the win in real-user field data rather than a single lab run, since Core Web Vitals are graded at the 75th percentile of actual visits.

What Are Core Web Vitals? covers the three metrics Google uses for the page experience signal.
What is LCP? explains Largest Contentful Paint and the 2.5 second threshold in depth.
What is CLS? breaks down visual stability and the 0.1 threshold.
What is INP? details responsiveness and the 200 millisecond target that replaced FID.
What is TTFB? explains the server response time that feeds into your overall speed.
What is Technical SEO? puts page speed in the wider context of crawlability and indexing.

Key Takeaways

Google uses Core Web Vitals and page experience as ranking signals, but treats relevance first. A fast page helps most when results are otherwise similarly relevant.
Focus on the three Core Web Vitals as your primary speed metrics. LCP should be 2.5 seconds or less, INP 200 milliseconds or less, and CLS 0.1 or less, each measured at the 75th percentile of real visits.
INP replaced FID as a Core Web Vital on March 12, 2024, so target INP, not the retired FID metric.
TTFB is a diagnostic, not a Core Web Vital. Aim for 0.8 seconds or less so the server response does not consume your LCP budget.
Image optimization, JavaScript reduction, and CDN usage provide the biggest speed improvements for most sites.
Test regularly with PageSpeed Insights, but trust the field data in Google Search Console's Core Web Vitals report for ranking decisions.