Core Web Vitals

Google made Core Web Vitals a ranking factor in 2021. They measure three aspects of user experience that correlate with page quality:

  • Largest Contentful Paint (LCP) — how long until the main content is visible. Target: under 2.5 seconds. Common causes of slow LCP: unoptimised images, slow server response, render-blocking resources.
  • Interaction to Next Paint (INP) — how responsive the page is to user input. Replaced First Input Delay in 2024. Target: under 200ms. Common causes: heavy JavaScript, long tasks blocking the main thread.
  • Cumulative Layout Shift (CLS) — how much the page layout shifts unexpectedly while loading. Target: under 0.1. Common causes: images without dimensions, late-loading ads, web fonts with fallback shifts.

Measure these using Google Search Console (aggregated real-user data across your site), PageSpeed Insights (single-URL analysis), or Chrome's built-in DevTools. Field data — real user measurements — matters more than lab data for ranking purposes.

Our meta tag analyser checks the technical basics for any URL, and our HTTP header viewer helps diagnose server response and redirect issues.

Server response time

Time to First Byte (TTFB) — how quickly the server responds to a request — affects every subsequent performance metric. A slow server drags everything else down.

Targets: under 200ms for a CDN-served static asset, under 500ms for a server-rendered page. Anything over 800ms is a problem.

The main levers:

  • CDN — serve static assets and, where possible, edge-rendered pages from a CDN close to the user. Cloudflare Workers, for instance, run in ~300 locations globally and return sub-100ms responses for edge-rendered pages.
  • Caching — cache HTML responses where the content doesn't change per user. Even a 60-second cache can absorb most traffic spikes.
  • Database queries — slow database queries are the most common cause of slow TTFB on dynamic sites. Index properly, use connection pooling, and consider caching query results.
  • Server location — a server in one country serving users in another adds latency. CDN or edge rendering solves this.

Asset budgets

Every byte the browser downloads delays rendering. Set explicit budgets and stick to them:

  • Images — use modern formats (WebP, AVIF). Compress aggressively. Serve images at the size they'll be displayed, not at full resolution. Lazy-load below-the-fold images. Add explicit width and height attributes to avoid layout shift.
  • JavaScript — the most expensive asset type, byte-for-byte. Each kilobyte of JS has to be downloaded, parsed, and executed. Audit your dependencies. Remove what you don't use. Split bundles and lazy-load non-critical scripts.
  • CSS — inline critical CSS in the <head> and load the rest asynchronously. Remove unused rules (tools like PurgeCSS help).
  • Web fonts — use font-display: swap to prevent invisible text during loading. Subset fonts to only the characters you need. Consider system fonts — they're free and instant.

A rough target for a content page: under 100KB of HTML/CSS/JS (compressed), images sized appropriately for the viewport. Pages that load in under 2 seconds on a mid-range mobile device on a 4G connection cover most users.

Mobile-first

Google indexes and ranks based on the mobile version of your site — not the desktop version. This has been the case since 2019. If your mobile experience is worse than your desktop experience, your rankings reflect the worse one.

Mobile-first doesn't mean mobile-only. It means:

  • Content and structured data should be identical on mobile and desktop
  • Navigation should be usable on a small touchscreen
  • Tap targets should be large enough (48×48px minimum)
  • Text should be readable without zooming (16px minimum body font size)
  • No horizontal scrolling on small viewports

Test with real devices, not just browser emulation. Emulation doesn't replicate device processor speed or real network conditions.

Accessibility

Accessibility is not a ranking factor in any direct, documented way. But the things that make a site accessible also tend to make it better for search engines:

  • Semantic HTML (proper headings, lists, labels) is easier for crawlers to parse
  • Alt text on images provides text context that search engines can index
  • Sufficient colour contrast is good design, not just compliance
  • Keyboard-navigable pages tend to have clear, logical structure

More practically: accessibility problems often surface in Core Web Vitals (keyboard traps degrade INP) and technical audits. Fixing them improves both user experience and crawlability.

Use Google's Lighthouse or axe DevTools browser extension to audit. WCAG 2.1 AA is the practical target for most sites.

Crawlability and indexation

Search engines can only rank pages they've found and indexed. A few things commonly go wrong:

  • robots.txt blocks — check that you're not accidentally blocking important paths. A misconfigured robots.txt is a remarkably common cause of ranking loss.
  • noindex tags — staging environments frequently have noindex set globally. When a site launches, that tag sometimes persists. Our meta tag analyser will show the robots meta tag for any URL.
  • Canonicals — if multiple URLs serve the same content (with and without trailing slash, HTTP vs HTTPS, www vs non-www), use canonical tags to point Google to the preferred version. Without them, you're diluting link equity across duplicates.
  • Crawl depth — pages buried five or six clicks from the homepage may not get crawled regularly. Good internal linking and a clear site structure keep important pages shallow.
  • XML sitemap — submit one to Google Search Console. Keep it current. Don't include pages that are noindex or return errors.

HTTPS

HTTPS has been a ranking signal since 2014. If you're still serving pages over HTTP in 2026, that's the first thing to fix. Check redirect chains with our HTTP viewer — it's common to have HTTP → HTTPS redirects that work but add an extra hop, or mixed-content issues where a page loads over HTTPS but references HTTP resources.

Structured data

Schema.org markup helps search engines understand what your content is about and can unlock rich results (star ratings, FAQs, event dates, recipe info) in the SERP. Rich results improve click-through rates for the queries where they appear.

The most commonly useful types: Article, Product, FAQPage, BreadcrumbList, LocalBusiness, and HowTo. Implement in JSON-LD (Google's recommended format), validate with Google's Rich Results Test, and monitor in Search Console for errors.