Skip to content
SEO · AEO · GEO — Zero to Expert

Technical SEO II — rendering, speed & mobile

IntermediateDuration ~22 min video + 75 min hands-onTools PageSpeed Insights / Lighthouse, Chrome DevTools, Search Console (Core Web Vitals report)

Why this lesson

Section titled “Why this lesson”

A page can be perfectly crawlable and still fail — because the engine can’t render its content, or it loads so slowly and shifts so much that users bounce, or it’s built desktop-first in a mobile-first world. And there’s a new stakeholder in 2026: AI answer engines that cite your content. They’re pickier than Googlebot in one specific way — most of them don’t run JavaScript at all. This lesson covers how rendering decides whether crawlers (and AI) can see your content, the three speed-and-stability metrics Google actually measures, mobile-first indexing, HTTPS as a baseline, and hreflang for international sites. It’s also where you’ll unlearn one outdated fact that’s still all over the internet.

Watch

Section titled “Watch”
Watch for: What each Core Web Vitals metric measures and how to improve it: LCP (largest contentful paint — loading, target under 2.5s; caused by slow servers, render-blocking JS/CSS, and client-side rendering) and CLS (cumulative layout shift — visual stability, target under 0.1; fixed by setting image/ad dimensions). Also field vs lab data and the 75th-percentile, mobile-first assessment. ⚠️ This video predates March 2024 — it teaches the interactivity metric as FID (First Input Delay). FID has been retired. The current metric is INP (Interaction to Next Paint) — read INP for it throughout.
Watch for: Why HTTPS is a baseline ranking signal (since 2014, now part of page experience): HTTP sends data as plain text anyone can intercept, HTTPS encrypts it via an SSL/TLS certificate. How to get a free DV certificate (Let's Encrypt) and how to find leftover unsecure pages with site:yourdomain.com -inurl:https.

The explainer

Section titled “The explainer”

Rendering: what the crawler actually sees. When a browser loads a page it renders it — turns HTML, CSS and JavaScript into the visible result. The question that decides your technical fate is where the content gets assembled. With server-side rendering (SSR), the server sends fully-formed HTML with the content already in it. With client-side rendering (CSR), the server sends a near-empty shell — often just <div id="root"></div> — and JavaScript builds the content in the browser afterward. Googlebot can execute JavaScript, so it can render CSR content, but it does so on a delay and it’s fragile. And here’s the 2026 stakes: AI crawlers generally do not run JavaScript at all. GPTBot, ClaudeBot, PerplexityBot and friends fetch the raw HTML and stop. If your content only exists after JavaScript runs, AI answer engines see an empty page and can never cite you. The fix is to make sure your real content and structured data are in the server-rendered HTML — view-source on your page; if you can’t see your main text there, neither can an AI. (Signs SSR is present: __NEXT_DATA__ or __NUXT__ in the source; an empty root div is the CRITICAL failure.)

Core Web Vitals — the current three. Google measures real-user experience with three metrics, assessed at the 75th percentile, mobile separately from desktop:

  • LCP (Largest Contentful Paint) — loading. Time until the largest visible element (usually the hero image or H1) is painted. Target: under 2.5 seconds. Common killers: slow servers, render-blocking CSS/JS, and client-side rendering. Fixes: good hosting, caching, a CDN, compressed and preloaded images, minified/deferred CSS and JS.
  • INP (Interaction to Next Paint) — interactivity. This replaced FID (First Input Delay) in March 2024 — if a resource still calls FID a Core Web Vital, it’s out of date. INP measures how quickly the page visually responds across all your interactions (clicks, taps, key presses), not just the first. Target: under 200 ms. The main cause of poor INP is heavy JavaScript blocking the main thread; fixes are breaking up long tasks and trimming JS execution.
  • CLS (Cumulative Layout Shift) — visual stability. How much visible content jumps around as the page loads (the annoyance of tapping a button that just moved because an ad loaded). Target: under 0.1. Fixes: set explicit width/height on images, videos, ads and embeds so the browser reserves their space.

Field data (real Chrome users, via CrUX and Search Console) is a rolling 28-day average, so changes take weeks to show; lab data (PageSpeed Insights, Lighthouse, DevTools) is instant for testing as you work.

Mobile-first indexing. Google predominantly crawls and indexes the mobile version of your pages. That means the mobile page is your page for ranking purposes — if you strip content, headings, or structured data out of the mobile view to “simplify” it, you’ve stripped it from what Google indexes. Build full parity: same content, same metadata, same schema on mobile as desktop.

HTTPS: the non-negotiable baseline. HTTPS encrypts data between browser and server with an SSL/TLS certificate; HTTP sends it as interceptable plain text. Google made HTTPS a ranking signal in 2014 and folded it into page experience. A free DV certificate from Let’s Encrypt covers most sites. Then hunt down leftover HTTP pages — site:yourdomain.com -inurl:https — and redirect them.

hreflang for international sites. If you serve the same content in multiple languages or regions, hreflang annotations tell search engines which URL to show which audience — en-us to American English searchers, es-mx to Mexican Spanish searchers. Done right it prevents your language variants from looking like duplicate content and gets each user the correct version. It’s finicky (every variant must reference every other, including itself) but essential once you go multi-region.

Do it

Section titled “Do it”
  1. View-source on your practice site’s main page. Can you see your primary content and headings in the raw HTML? If it’s an empty root div, note it as an SSR/CSR risk — especially for AI visibility.
  2. Run the page through PageSpeed Insights. Record LCP, INP, CLS for mobile. Which pass (LCP under 2.5s, INP under 200ms, CLS under 0.1)? For each failure, note the flagged cause.
  3. Pick the worst metric and list two concrete fixes from the lesson (e.g. preload the LCP image; set dimensions on the shifting element).
  4. Check mobile parity: open the page on a phone (or DevTools device mode). Is any content, heading, or schema missing vs desktop?
  5. Confirm HTTPS: run site:yourdomain.com -inurl:https and flag any unsecure indexed pages.
  6. If the site is (or could be) multilingual, sketch the hreflang map: which URLs serve which language/region.
  7. Record findings and the fix priority in the Level 2 workbook.
Level 2 workbook — rendering check, Core Web Vitals scorecard (LCP/INP/CLS) & mobile-parity auditlevel-2-workbook.pdf116 KBOriginal course material — free to use

Terms introduced

Section titled “Terms introduced”

Check

Section titled “Check”

Check yourself

  1. Which three metrics make up Core Web Vitals as of 2026?

  2. Your page renders its main content with client-side JavaScript, showing an empty <div id="root"> in the raw HTML. Why is this risky — especially for AI answer engines?

  3. What does mobile-first indexing mean for how you build a page?

You can move on when you can… tell from view-source whether a page is server- or client-rendered and why that matters for AI crawlers, name the three current Core Web Vitals and their targets (LCP under 2.5s, INP under 200ms, CLS under 0.1), explain mobile-first indexing, and know when a site needs hreflang.

Go deeper

Section titled “Go deeper”
  • Google Search Central — “Understanding Core Web Vitals” and “JavaScript SEO basics”: the current, authoritative reference — including the INP transition and how Google renders JavaScript.
  • Next: 2.5 · Structured data & schema — add JSON-LD so engines (and AI) understand what your content means, not just what it says.