Need the #1 SEO strategist and optimiser in Brisbane?Click here →

Site Speed and SEO

12 min readLast reviewed: March 2025

Page speed is both a ranking factor and a user experience imperative. Since 2010, site speed has been confirmed as a ranking signal. Since 2021, Core Web Vitals (a specific set of speed metrics) became a major ranking factor. Speed matters.

Why Speed Is a Ranking Signal

Google cares about speed because users care about speed. A fast page provides better user experience. Slow pages frustrate users, leading to higher bounce rates and lower engagement. Google's ranking algorithm optimises for user satisfaction, so speed factors in.

However, speed is not the only ranking factor. Content relevance and backlinks matter more. A slow page with exceptional content and links can still rank. But all else being equal, the faster page ranks higher.

How to Measure Speed Properly

Many tools measure speed, but it's critical to understand the difference between lab data and field data.

Lab Data vs Field Data

Lab data is synthetic performance measured in a controlled environment (e.g., PageSpeed Insights running a test from a specific device and network). It's consistent and reproducible but doesn't reflect real user experience. Field data (also called "real user monitoring" or RUM) comes from actual users' real devices and networks. Field data is noisier but realistic.

Google uses field data for ranking — specifically, Core Web Vitals from the Chrome User Experience Report (CrUX). This is the data you should optimise for, not lab scores.

Tools to Measure Speed

  • Google Search Console. Shows your Core Web Vitals field data (if available) and any speed issues Google has detected.
  • PageSpeed Insights. Shows field data (if available) and lab data. Focus on the field data tab, not lab. Lab scores are diagnostic; field data determines rankings.
  • Google's CrUX Dashboard. Real user data aggregated from Chrome users. Shows your actual field performance.
  • Lighthouse. Lab-based auditing tool (available in Chrome DevTools, PageSpeed Insights, or standalone). Good for diagnosis, not for ranking evaluation.
  • WebPageTest. Detailed lab measurements from multiple devices and networks. Useful for deep diagnostics.
The Field Data Priority
Optimise for field data (Core Web Vitals) from real users. Lab scores are diagnostic aids. A page with a "slow" Lighthouse score but "good" field data scores will rank better than a page with the opposite.

What Causes Slow Pages

The most common culprit: unoptimised images. Images account for the majority of page weight on most sites. Compressing, resizing, and using modern formats (WebP) can dramatically improve speed with minimal effort.

After images, the usual suspects are render-blocking JavaScript, slow server response times (TTFB), and excessive third-party scripts.

Common Speed Problems and Fixes

IssueRoot CauseMetric AffectedFix
Unoptimised imagesLarge image file sizes not compressed or resized for webLCP, INPCompress with tools like TinyPNG; use modern formats (WebP); resize to needed dimensions
Render-blocking JavaScriptJS required to render the page, blocking HTML parsingLCPDefer or async non-critical JS; inline critical JS; use dynamic imports
Slow server response (TTFB)Server processing or database queries are slowLCPUpgrade hosting; optimise database queries; use caching; use CDN
Too many third-party scriptsAd networks, analytics, chat widgets loading heavy JavaScriptINP, LCPLoad third-party scripts asynchronously; lazy-load widgets; audit necessity
No cachingBrowser doesn't cache assets, every visit re-downloads everythingAll metrics (repeat visits)Set browser cache headers; use service workers; set cache-control headers
Layout shifts (CLS)Images/ads without dimensions, late-loading content pushing layoutCLSSet explicit width/height on images; reserve ad space; avoid late DOM insertions

Server-Side vs Front-End Performance

TTFB (Time to First Byte) measures how long until your server responds with the first byte of HTML. This is a server-side metric. If TTFB is slow, your server is the bottleneck. Upgrade hosting, optimise database queries, or use a CDN.

LCP (Largest Contentful Paint) measures how long until the main content is visible. If TTFB is fast but LCP is slow, the bottleneck is front-end — typically unoptimised images or render-blocking JavaScript.

Knowing which metric is slow tells you where to focus effort.

Which Speed Metrics Actually Matter for SEO

Google's official ranking signal is Core Web Vitals field data, not lab scores. Specifically:

  • LCP (Largest Contentful Paint): How fast the main content loads. Measured from actual user data in Google's CrUX.
  • INP (Interaction to Next Paint): How responsive the page is to user interactions. Based on real user events.
  • CLS (Cumulative Layout Shift): How stable the layout is as it loads. Based on real user sessions.

These three metrics, measured via field data (not lab), are the SEO-relevant speed metrics. A fast Lighthouse score means little if real users experience poor field metrics.

Action Plan
1. Log into Google Search Console and check your Core Web Vitals report. 2. Identify which metrics are failing. 3. Use PageSpeed Insights to see diagnostics (but remember this is lab data, not field). 4. Fix the top issues. 5. Monitor field data over time (it takes a few days to collect enough data).

Quick Wins for Speed

  • Compress images. Use TinyPNG, ImageOptim, or similar. Saves 40-70% file size with no quality loss.
  • Enable GZIP compression. Compresses HTML, CSS, JS on the fly. Often a server setting.
  • Use a CDN. Serves assets from geographically close servers. Massively speeds up static content.
  • Lazy-load images below the fold. Images not visible initially don't need to load immediately.
  • Minify CSS and JavaScript. Remove whitespace and unnecessary characters.
  • Remove unused CSS/JS. Don't load code you don't use.