Site Speed and Google Rankings: What Actually Matters

Speed isn't a technical luxury. A visitor waiting more than about three seconds usually leaves before seeing what you offer, and Google measures loading experience as part of how it ranks pages. This page covers what is actually measured and what is worth your time.

The three metrics Google measures

Known as Core Web Vitals, each maps to a real user complaint:

• LCP — Largest Contentful Paint. How long until the biggest visible element (hero image or headline) appears. Target: under 2.5 seconds.
• INP — Interaction to Next Paint. When you tap a button, how long before the page responds. Target: under 200 milliseconds.
• CLS — Cumulative Layout Shift. Do elements jump around while loading, so you tap the wrong thing? Target: under 0.1.

Critically, these are measured from real user visits, not a lab test. A site that's fast on your machine may be slow on a mid-range phone on a normal connection — and that's what counts.

The usual causes of slowness

In rough order of frequency:

• Uncompressed images. A 4MB photo uploaded straight from a camera is the single most common cause.
• Too many plugins on WordPress, especially ones that overlap in function.
• External fonts loaded in several weights, most of them unused.
• Third-party scripts: analytics, chat widgets, ad tags — each one delays interactivity.
• No caching or CDN.
• Total dependence on JavaScript to render content, so neither visitor nor crawler sees anything until execution completes.

High-impact quick fixes

With limited time, start here in this order:

1. Compress images and convert to WebP, and set explicit dimensions in the markup (this fixes CLS directly).
2. Lazy-load images below the fold.
3. Delete unused plugins rather than merely deactivating them.
4. Cut font weights to what you actually use, and self-host them.
5. Defer non-critical scripts until after load.
6. Enable caching and compression at the server.

These alone move many sites from red to green without a rebuild.

When the problem is architectural

Sometimes patching won't do it. Reconsider the architecture when:

• The site renders entirely through JavaScript with no content in the initial HTML — common in single-page applications, and solved by prerendering or server-side rendering.
• The theme loads enormous libraries for a simple page.
• Every page fires dozens of database queries with no caching.

SEO is more than speed

Speed is one signal among many. Don't neglect the fundamentals:

• A unique title and description per page, not one string repeated site-wide.
• Sound heading structure: one H1 describing the page, then H2s for sections.
• Alt text that actually describes the image.
• A sitemap.xml submitted in Google Search Console.
• Internal links with descriptive anchor text connecting your pages.
• Structured data (Schema) so Google understands what kind of page this is.
• Content that genuinely answers the searcher's question — still the most important factor.

How we build

This site is prerendered: every page is turned into complete static HTML at build time, so a crawler gets the text, headings and structured data without executing any JavaScript, and the interactive app then takes over for the visitor. We apply the same approach to client sites because the effect on indexing is clear and measurable.

Want a read on your current site's performance? Send us the URL and we'll tell you where the real bottleneck is.