Performance is where good content quietly dies. Google has confirmed Core Web Vitals as ranking signals, mobile-first indexing means your phone experience is your ranked experience, and AI fetchers (GPTBot, PerplexityBot) drop slow or flaky origins without ceremony. This category measures whether your page is fast, stable, mobile-ready, and — critically for AI — whether its content exists before JavaScript runs.
Each check below has a stable ID (B1–B9) so a finding maps straight to the explanation. The first four are core checks; the rest are extended diagnostics.
Core Web Vitals quantify how a page feels to a real visitor. LCP (Largest Contentful Paint) measures how long until the main content appears — aim for ≤ 2.5s. INP (Interaction to Next Paint), which replaced FID in 2024, measures real responsiveness to clicks and taps — aim for ≤ 200ms. CLS (Cumulative Layout Shift) measures unexpected movement as the page loads — aim for ≤ 0.1.
These come from field data — the Chrome User Experience Report (CrUX), aggregated from real Chrome users — not a lab simulation. That matters: a page can look fast on your fast laptop and still fail CWV for users on mid-range phones and slow networks, which is most of the world.
Typical culprits and fixes: a slow LCP usually means a heavy hero image or render-blocking resources (compress images, preload the LCP element, defer non-critical JS); poor INP means heavy main-thread JavaScript (break up long tasks, reduce third-party scripts); CLS comes from images/ads without reserved space (set explicit width/height and reserve ad slots).
TTFB is the time between the request and the first byte of the response arriving. It's the foundation every other speed metric builds on: if the server takes 1.5s just to start answering, your LCP can never be good. Aim for ≤ ~0.8s; 0.8–1.8s is a warning zone; beyond that you're losing both users and crawl efficiency.
TTFB is dominated by backend work — database queries, un-cached page generation, slow third-party calls, and the physical distance between the user and your server. The highest-leverage fixes are caching (full-page or edge caching so most requests never hit the origin) and a CDN that serves from a location near the visitor.
For GEO this is sharper than for classic SEO: AI fetchers operate on tight timeouts and won't patiently re-try a slow origin. A site that's "a bit slow" for Googlebot can be effectively invisible to an answer engine that gave up waiting.
The line <meta name="viewport" content="width=device-width, initial-scale=1"> tells the browser to render the page at the device's actual width instead of pretending to be a 980px desktop and zooming out. It's the prerequisite for any responsive layout to work.
This matters more than ever because Google indexes the mobile version of your site. If the mobile experience is a tiny, zoomed-out desktop page with unreadable text and un-tappable links, that's the version that gets ranked — and it ranks poorly.
Two anti-patterns to avoid even when the tag is present: user-scalable=no (which blocks pinch-zoom and fails accessibility) and a fixed-width layout that forces horizontal scrolling. The page should reflow to fit any screen.
There are two versions of every page: the raw HTML the server sends, and the rendered DOM after JavaScript runs. Googlebot can (eventually, with delay and cost) render JavaScript. But the major AI crawlers — GPTBot, ClaudeBot, PerplexityBot, CCBot — generally do not. They read the raw HTML and move on.
This is the single biggest GEO trap for modern sites. A typical client-side React/Vue/SPA setup ships an almost-empty HTML shell and builds the content in the browser. A human sees a full page; an AI crawler sees a blank div and cannot quote a word of it. The page can rank acceptably on Google yet be completely absent from AI answers — which is why GEO / LLM readiness depends on this even more than classic search does.
The fix is to get content into the initial HTML response: [server-side rendering](category-geo-llm.html) (SSR), static site generation (SSG), or pre-rendering for bots. You can verify the problem by comparing the raw HTML (view-source or curl) against the rendered page — if the body text is missing from the raw HTML, AI crawlers can't see it.
Extended checks
Diagnostic checks flagged for review — useful polish, but they don't carry the same score weight as the core checks above.
Some resources block rendering: CSS in the <head> and synchronous scripts must download and execute before the browser can paint. Each one pushes back your LCP. The fixes are well-trodden — inline critical CSS, defer or async non-essential scripts, and load fonts without blocking.
Total page weight (bytes and request count) is the other half. A page hauling multiple megabytes of unoptimized images, fonts and third-party scripts will be slow on real mobile networks no matter how fast your server is. Audit the heaviest resources and trim or lazy-load what isn't needed for the first view.
Lazy-loading below-the-fold images is good practice. But lazy-loading or interaction-gating critical content — the main copy, key links, primary navigation — is risky, because crawlers don't scroll, hover or click. If your important content only materializes after a user action, a crawler may never see it.
Keep first-view and primary content eagerly available in the markup. Reserve lazy-loading for genuinely secondary, below-the-fold media.
Unoptimized images are the number-one cause of slow LCP and bloated page weight. Three levers: compression (don't ship a 4000px hero at full quality), correct dimensions (serve appropriately sized images with explicit width/height to also prevent layout shift), and modern formats (WebP/AVIF are dramatically smaller than JPEG/PNG).
Add responsive srcset so phones download phone-sized images, and lazy-load below-the-fold media. These changes routinely cut page weight in half with no visible quality loss.
Without a CDN, every visitor — wherever they are — fetches from your single origin server, so users far away wait longer. A CDN caches static assets (and often full pages) at edge locations worldwide, so content is served from nearby, slashing latency and TTFB for a global audience.
A CDN also improves resilience under load and is where edge-level optimizations (compression, HTTP/2-3, caching rules) naturally live. For any site with non-local visitors, it's close to essential.
Mobile usability comes down to fingers and eyes. Tap targets (links, buttons) should be large enough (~48px) and spaced so users don't fat-finger the wrong one. Font size should be readable by default (~16px body) with adequate contrast, so visitors aren't forced to pinch-zoom.
These are direct mobile-friendliness signals and affect engagement metrics that feed back into rankings. They're easy to miss on a desktop preview — always test on an actual phone.
Why performance matters for SEO and GEO
Performance is one of the few categories that is simultaneously a confirmed ranking factor, a conversion factor, and a crawl-access factor. Slow pages rank lower, convert worse, and — increasingly — get skipped by impatient AI fetchers. Mobile-first indexing means the slow, cramped mobile experience is the one that actually gets judged.
The good news is that performance problems are concrete and measurable. Most of the wins come from a short list: optimize images, cache aggressively behind a CDN, defer non-critical JavaScript, reserve space to stop layout shift, and make sure the content exists in the HTML before JS runs.
AI fetchers are the harshest performance critics you have. They rarely execute JavaScript and they operate on tight timeouts — so a page that's merely "a bit slow" or that builds its content client-side can be completely invisible to ChatGPT, Perplexity and Google's AI Overviews even while it still limps along in classic search. Server-rendered, fast-loading HTML is the price of being quotable.
Audit your page across all 9 checks in Performance & Mobile UX
See exactly which checks pass, warn or fail — in seconds.
Run a free audit →