Speed
How fast your pages load and respond — on the phone first, then the desktop.
0.25 of the composite score — the heaviest axisWhy does this matter — for rankings, traffic and trust?
Speed is the only axis Google has confirmed as a direct ranking signal through Core Web Vitals, and it is weighted heaviest in this score because it compounds everything else: a slow page wastes good titles, good schema and good content. Google indexes with the mobile agent and tests with the mobile strategy — your phone experience is your SEO experience.
For marketing the math is blunt: LCP under 2.5s versus over 4s is routinely the difference between a 2% and a 5% conversion rate; every extra second of load measurably raises bounce. Interactive feel (TBT/INP) decides whether a form feels instant or sticky on a mid-range Android — the device most of your traffic actually uses.
Most speed failures are configuration, not talent: uncompressed transfer, no cache headers, render-blocking assets and unoptimized hero images account for the majority of failed audits. They fix in hours, not quarters.
Every signal in this division — exactly what the engine checks
How to fix it
What commonly causes failures here
- Uncompressed HTML/CSS/JS — the origin never enabled gzip/brotli.
- No Cache-Control — every visitor re-downloads everything.
- A hero image without priority — the Largest Contentful Paint waits on the slowest asset.
- Render-blocking CSS/JS in <head>.
- Slow server response (TTFB): cheap shared hosting, no CDN, or a chatty backend.
- Missing mobile viewport meta — the page renders desktop-wide on phones.
- DOMs of thousands of elements — parse and style cost paid on every phone.
Best-practice setup
The two blocks below are the highest-leverage hour in web performance: turn on compression and sane caching at the edge, then mark the hero asset as the thing to fetch first.
server {
# compression: typically cuts HTML/CSS/JS transfer by 60–80%
gzip on;
gzip_vary on;
gzip_comp_level 6;
gzip_types text/css application/javascript application/json image/svg+xml text/plain application/xml;
# hashed, immutable assets → cache for a year
location /assets/ {
add_header Cache-Control "public, max-age=31536000, immutable";
}
# HTML must revalidate so deploys are picked up
location / {
add_header Cache-Control "no-cache";
}
}<head>
<link rel="preload" href="/hero.avif" as="image"
imagesrcset="/hero-640.avif 640w, /hero-1280.avif 1280w"
imagesizes="100vw" fetchpriority="high">
<script defer src="/app.js"></script> <!-- defer: never block rendering -->
</head>
<body>
<img src="/hero-640.avif"
srcset="/hero-640.avif 640w, /hero-1280.avif 1280w"
sizes="100vw" width="1280" height="720"
fetchpriority="high" decoding="async"
alt="Fulfillment center with Acme robots picking orders">
</body><meta name="viewport" content="width=device-width, initial-scale=1">How we measure it
We run Google PageSpeed Insights twice per scan — the mobile strategy (primary, matching how Google sees you) and the desktop strategy — plus CrUX field data (p75 of real users) when enough visitors have contributed. Server response comes from Lighthouse with our own probe measurement as fallback, so the axis stays honest even when PSI is rate-limited.