DEV Community: Garvit Sharda

JavaScript SEO in 2026: The "Two Waves of Indexing" Myth, and What Googlebot Actually Keeps

Garvit Sharda — Fri, 31 Jul 2026 09:31:18 +0000

If you build with React, Vue, or any JavaScript framework and you care about organic traffic, there's a good chance you're still optimizing for a Google that no longer exists.

For years the mental model was "two waves of indexing": Google reads your HTML in wave one, then comes back days or weeks later to run your JavaScript in wave two. That model — which Google itself presented back in 2018 — has quietly disappeared from the official documentation. In 2026, rendering is an asynchronous queue, and Google's own docs now say a page "may stay on this queue for a few seconds, but it can take longer than that." The famous "5-second JS execution limit"? Also not in the docs. It was never a hard rule.

So the interesting question in 2026 isn't when Google will run your JavaScript. It's what Google actually kept after it rendered your page — because that's a very different thing, and it's where most JS sites quietly bleed traffic.

How Google actually processes a JS page now

Three stages, in order: crawl → render → index.

Crawl. Googlebot makes an HTTP request, checks robots.txt, and parses whatever HTML comes back.
Render. Every 200 page gets queued for rendering in a headless, evergreen Chromium (it understands modern JS — ES2020+, dynamic import(), even WebAssembly). Syntax support is not your problem. Resource and queue constraints are.
Index. Google indexes the rendered DOM and re-extracts links from it.

One trap worth memorizing: if a noindex is present in the initial HTML, Google may skip rendering entirely. So the classic "we'll inject the right robots tag with JavaScript" plan can backfire — the script that was supposed to remove the noindex never runs.

The failure modes nobody warns you about

Here's the uncomfortable part. A client-side-rendered (CSR) page ships an almost-empty HTML shell; everything real arrives with the JS. When rendering succeeds and the content looks valuable, the page indexes fine. When it doesn't, you land in one of these buckets — all visible in Search Console:

Symptom	Typical status	Likely cause
HTML is a shell, content from JS	"Crawled – currently not indexed" (or indexed empty)	Render failed or judged thin
Client-side routing, empty states served as 200	"Soft 404"	No real error code
Large JS site, new pages pending	"Discovered – currently not indexed"	Render queue / crawl budget
title/canonical/robots injected via JS	Duplicate / canonical conflicts	Initial HTML disagrees with the render

The most insidious is the indexed-empty shell: the URL is in the index, but it ranks for nothing because Google kept the pre-JS shell. Nothing looks broken until you compare what got indexed with what should have.

And "Soft 404" is a pure SPA disease: your router shows a "no results" view but the server still returns 200. Sold-out products, empty search pages, and misconfigured fallback routes generate these at scale.

CSR vs SSR vs SSG vs ISR, minus the dogma

You don't need to server-render everything. You need SEO-critical content in the initial HTML response. Quick decision:

CSR — browser builds the DOM. Fine for dashboards behind a login; risky for anything you want ranked. Pure CSR can delay indexation enough to cost a large share of organic traffic.
SSR — HTML per request. Best for dynamic or personalized content (e-commerce, feeds).
SSG — HTML at build time, served from a CDN. Ideal for blogs, docs, landing pages. Fastest TTFB.
ISR — SSG that revalidates in the background. The pragmatic 2026 default: static speed, fresh-enough data.

The non-negotiable, regardless of framework: your title, meta description, H1, canonical, internal links, and structured data must exist in the server HTML — not be painted in afterward. That's what lands cleanly in the index with zero dependency on a successful render.

A few concrete gotchas:

Use the History API for SPA routing, not URL fragments — Googlebot can't reliably resolve #/ routes.
Fingerprint your assets (main.2bb85551.js). Googlebot's Web Rendering Service caches aggressively and may serve stale JS/CSS otherwise.
Web components get flattened (shadow + light DOM), but only what's in the rendered HTML is indexable.

Stop trusting your own crawler

This is the mistake I see most. Teams run Screaming Frog or Sitebulb in render mode, see their content, and conclude "we're fine." But that only proves your tool rendered it — with its engine, its timeouts, its settings. It says nothing about what Google rendered or chose to keep.

The source of truth is Search Console:

URL Inspection shows Google's own rendered HTML, the resources it loaded, and any JS exceptions it hit.
The Page Indexing report gives the verdict per URL, at scale.

On a big JS site the real question isn't "is this one URL rendered right?" — it's "what share of my JavaScript-dependent pages is actually indexed, and under which exclusion reasons?" You answer that by bulk-inspecting your sitemap URLs against the official inspection data, not by re-rendering locally.

A 2026 checklist

[ ] SEO-critical content (title, H1, canonical, links, schema) is in the initial HTML
[ ] No noindex in the served HTML that you intend to flip with JS
[ ] SPA routing uses the History API; missing pages return a real 404 server-side
[ ] Assets are content-fingerprinted
[ ] You verify indexation in Search Console, not your own crawler
[ ] Anything ranking-critical uses SSR/SSG/ISR, not pure CSR

None of this requires abandoning your framework. It requires being deliberate about where your HTML is generated for the pages that need to rank.

If you'd rather have someone pressure-test your stack, this is exactly the kind of thing a technical SEO team digs into — and running a free SEO audit is a fast way to see which of your JS pages Google is quietly dropping before you refactor anything.

Written by Garvit Sharda. I work with COM8 STUDIO, a digital marketing and web agency, on technical SEO and front-end performance.

The 2026 AI-Crawler Reality Check: What the Data Says for Developers

Garvit Sharda — Fri, 24 Jul 2026 09:18:57 +0000

Everyone's writing think-pieces about "optimizing for AI search." I wanted numbers. So I pulled together the 2025-2026 data from Cloudflare, Vercel/MERJ, Ahrefs and the AI providers' own docs. Some of it genuinely changed how I build sites. Here's the reality check, dev to dev.

1. The AI crawlers do not run your JavaScript

This is the big one. A Vercel/MERJ analysis of 500M+ crawler fetches found that none of the major dedicated AI crawlers execute JavaScript — not OpenAI's GPTBot/OAI-SearchBot/ChatGPT-User, not Anthropic's ClaudeBot, not PerplexityBot, not Meta or ByteDance's Bytespider. They fetch your raw HTML and leave. They do download JS files (~11.5% of ChatGPT's fetches, ~23.8% of Claude's) — they just never run them.

The exception is Google: its Web Rendering Service is shared across Search and Gemini, so Google-Extended renders JS the same way Googlebot does.

Translation: if your content only exists after client-side hydration, every AI engine except Google sees an empty shell.

# see what the bots see
curl -A "GPTBot" https://yoursite.com/page | grep "your headline"

If that's empty, you need SSR, SSG, or prerendering.

2. AI crawl traffic is exploding — and barely sends anything back

Cloudflare's data shows AI crawler activity up sharply year over year, with GPTBot's volume up ~305% and reaching ~11.7% of all crawler requests by mid-2025. But roughly 86% of that crawling is for model training, not live search retrieval.

And the referrals? Lopsided doesn't cover it. Measured crawl-to-referral ratios hit ~38,065:1 for Anthropic and ~1,091:1 for OpenAI. They read enormously, cite rarely. AI tools still send under 1% of outbound web traffic today.

3. The SERP is going zero-click

By early 2026, roughly 68% of Google searches ended without a click, and pages with an AI Overview above them saw click-through drop by around 60%. Being "on page one" is worth less every quarter; being the cited source is worth more.

4. Two overhyped tactics, with the data attached

llms.txt: adoption grew ~8.8x, but in one May 2026 measurement 97% of llms.txt files received zero requests. OpenAI, Anthropic and Google all point site owners to robots.txt instead. Add it if you like — it's a cheap static file — but don't expect it to do the work.
Schema/JSON-LD as a citation hack: controlled analysis found schema presence does not independently predict AI citation once you correct for content quality. Schema still earns rich results and disambiguates entities — just don't treat it as a magic AI-ranking lever.

What actually moves the needle

Boring, durable engineering:

Server-render your content — verify with curl, not DevTools.
Allow the retrieval bots you want cited by in robots.txt; block only what you must.
Answer-first, semantic HTML — clean headings, real lists, a direct answer per section.
Core Web Vitals, INP included — fast pages get crawled more thoroughly.

None of this is a hack. It's the same discipline as good, crawlable web engineering — which is why developers, not marketers, tend to be the ones who move AI visibility. It's the technical backbone of modern AI SEO and it overlaps almost entirely with classic technical SEO.

Build for the crawler that can't run your JavaScript, and you're ready for whatever the answer engines do next.

Sources: Cloudflare Radar, Vercel/MERJ crawler study, Ahrefs brand-mentions analysis, and OpenAI/Anthropic/Google bot docs (2025-2026).

How AI Crawlers Actually Read Your Site: A Developer's Guide to GEO & llms.txt (2026)

Garvit Sharda — Mon, 20 Jul 2026 06:19:12 +0000

Your users increasingly don't scroll ten blue links anymore. They ask ChatGPT, Perplexity, or Google's AI Overview a question and read one synthesized answer. For that answer to mention your site, a machine has to crawl it, parse it, and decide your content is worth quoting.

That whole pipeline is Generative Engine Optimization (GEO) — and a surprising amount of it lives in the part of the stack developers own, not the marketing team.

Here's the one-line version: treat AI crawlers like a browser that never runs your JavaScript, and hand them clean, server-rendered, well-structured HTML. Everything below unpacks what that means in practice.

Meet the bots already hitting your server

Open your access logs and you'll find a new class of user-agents. They fall into two jobs:

Training / indexing crawlers — GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, and Google-Extended (a token that controls whether your content is used for Gemini/AI, separate from Googlebot).
Live "user-triggered" fetchers — OAI-SearchBot and ChatGPT-User, Claude-User, Perplexity-User. These hit your page in real time when someone's prompt needs a fresh source.

You control access to all of them from robots.txt:

User-agent: GPTBot
Allow: /

User-agent: Google-Extended
Disallow: /private

Blocking them keeps you out of training data and out of the answers your customers now read. For most businesses, being cited is the goal — so allow the retrieval bots deliberately.

The big one: most AI crawlers don't run your JavaScript

Googlebot renders JavaScript with an evergreen Chromium engine. Most AI-specific crawlers do not. They largely fetch your raw HTML response and move on. If your content only appears after a client-side framework hydrates in the browser, there's a real chance the bot sees an empty <div id="root"> and nothing else.

Test it the way the bot does — no browser, no JS:

curl -A "GPTBot" https://yoursite.com/your-page | grep "the headline you expect"

If your key content isn't in that response, AI engines probably can't read it. The fixes are the ones you already know:

SSR or SSG (Next.js, Nuxt, Astro, SvelteKit) so HTML ships with content in it.
Prerender / dynamic rendering for legacy SPAs you can't fully migrate.
Keep the important text in the initial HTML, not lazy-loaded behind an interaction.

This single architectural choice separates sites that get quoted from sites that are invisible to the models.

Structure your HTML so a machine can extract answers

Once the bytes arrive, the model has to understand them. Semantic, answer-first HTML is the highest-leverage, least-hyped tactic here:

One <h1>, then a logical <h2>/<h3> outline that reads like the questions people actually ask.
Lead each section with a direct, self-contained answer, then expand. Models lift clean, standalone sentences far more readily than points buried in a wall of text.
Use real <ul>, <ol>, and <table> elements. Structured facts extract cleanly; <div> soup does not.

Add JSON-LD structured data (Organization, Article, FAQPage, BreadcrumbList, Product). Whether schema directly boosts AI citations is still genuinely debated, and I won't oversell it — but it's cheap, it powers traditional rich results, and it removes ambiguity about what your entities are. Clean signals never hurt.

llms.txt: add it, but don't believe the hype

llms.txt is a proposed standard (introduced by Jeremy Howard in late 2024): a Markdown file at /llms.txt that gives models a curated map of your most important content, minus the nav and cruft.

The honest status in 2026: adoption among docs and dev-tool sites is real, but no major AI provider has publicly confirmed they consume it, and skeptics (including voices at Google) have compared it to the old keywords meta tag. Server logs rarely show the big crawlers fetching it.

My take as a developer: it costs ten minutes and a static file, so add it — but treat it as a nice-to-have, not the thing that gets you cited. Your rendered HTML is still what matters.

Speed is still a ranking and crawling signal

Core Web Vitals didn't go away. INP (Interaction to Next Paint) replaced FID in 2024 as the responsiveness metric, joining LCP and CLS. Fast, server-rendered pages get crawled more thoroughly and are less likely to time out a bot mid-fetch. The performance work you do for users pays off again for machines.

The practical GEO checklist

If you do nothing else, ship these:

Server-render your content — verify with curl, not just DevTools.
Allow the AI retrieval bots you want to be cited by in robots.txt.
Answer-first sections under a clean heading hierarchy.
JSON-LD for your core entities.
Meet Core Web Vitals, INP included.
Drop an llms.txt — low effort, possible upside.

None of this is a growth hack. It's the same discipline as good, crawlable web engineering — which is exactly why developers, not marketers, are often the ones who move the needle on it. This groundwork is the technical core of modern AI SEO, and it overlaps almost entirely with classic technical SEO: fast, semantic, server-rendered pages that both humans and machines can actually read.

Build for the crawler that can't run your JavaScript, and you'll be ready for whatever the answer engines do next.

Getting Your Site Cited by AI Search in 2026: A Front-End Developer's Checklist

Garvit Sharda — Thu, 16 Jul 2026 05:32:53 +0000

AI answer engines — Google's AI Overviews, ChatGPT Search, Perplexity, Gemini — increasingly answer users without a click. For developers, that shifts the goal: it's no longer only "rank the page," it's "be the source the model quotes." The good news is that a lot of what makes a site citable is squarely front-end and infra work. Here's the checklist my team actually uses.

1. Server-render anything you want cited

LLM crawlers are far better at parsing HTML that exists before JavaScript runs. If your key content only appears after client-side hydration, assume it won't be reliably read.

Prefer SSR or static generation (Next.js, Astro, Nuxt, etc.) for content pages.
Verify what the bot actually sees:

curl -sL https://example.com/page | grep -i "your answer text"

If your content isn't in that output, a crawler probably can't see it either.

2. Ship structured data (JSON-LD)

Schema doesn't guarantee a citation, but it makes your page cheaper for a machine to parse and reuse. Add Article, FAQPage, HowTo, Organization, and BreadcrumbList where relevant:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "What is answer-engine optimization?",
    "acceptedAnswer": { "@type": "Answer", "text": "..." }
  }]
}
</script>

Validate with Google's Rich Results Test before shipping.

3. Write answer-first, chunk-friendly HTML

Models extract self-contained passages. Structure content so each section stands alone:

Put the direct answer in the first one or two sentences of a section, then expand.
Use real semantic headings (<h2>/<h3>) phrased as questions.
Short paragraphs, genuine lists, and tables beat walls of text.

4. Actually let the AI crawlers in

You can't be cited if you block the bots. Check your robots.txt — plenty of teams block these without realizing:

User-agent: GPTBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

(Google-Extended governs Gemini/Vertex grounding and training — decide deliberately rather than by accident.)

5. Consider an llms.txt

An emerging convention: a root-level /llms.txt that points models at your cleanest, most important content:

# Example Co
> One-line description of what we do.

## Docs
- [Getting started](https://example.com/docs): setup guide
- [API reference](https://example.com/docs/api): endpoints

It isn't universally consumed yet, but it's cheap to add and forward-looking.

6. Keep it fast and stable

Core Web Vitals still matter — for users, for classic SEO, and because slow, unstable pages get crawled less. Aim for LCP < 2.5s, INP < 200ms, CLS < 0.1.

7. Measure citations, not just clicks

This is the hard part: an AI citation often produces no referral in analytics. Track it directly — run your target prompts across ChatGPT, Perplexity, and Google's AI Mode on a schedule and log whether (and how) you appear. Then watch the small-but-high-intent referral traffic that AI does send.

Where this nets out

None of this replaces fundamentals — crawlability, real authority, and genuinely useful content still underpin everything. But the front end is where a surprising amount of "AI visibility" is won or lost. If you want a second pair of eyes on the technical and content side, this is the kind of answer-engine optimization work we do day to day, and a quick free SEO audit tends to surface the crawlability and schema gaps fastest.

What are you doing to make your sites citable? Curious what's working for others.

Conversion Rate Optimization for Developers: Front-End Changes That Actually Move the Needle

Garvit Sharda — Sat, 11 Jul 2026 19:10:01 +0000

Marketing teams obsess over conversion rate. Developers usually treat it as somebody else's metric. That is a mistake — a huge share of what decides whether a visitor converts is settled in the front-end: how fast the page paints, how the form behaves, and how little friction stands between intent and action.

Here are the front-end changes that, in my experience, actually move conversion — not vanity tweaks.

1. Speed is a conversion feature, not just an SEO one

Every study on this says the same thing: conversion rate drops as load time climbs, and the fall is steepest in the first few seconds. A checkout that takes 5s to become interactive loses buyers who would have completed at 2s. So the same Core Web Vitals work you do for rankings pays a second dividend at the cash register. Prioritise the Largest Contentful Paint element, defer third-party scripts until interaction, and keep the main thread free so taps respond instantly.

2. Fix your forms — this is where money leaks

Forms are the highest-leverage surface on any lead-gen or checkout page:

Use the correct type and autocomplete tokens (email, tel, one-time-code, cc-number). Mobile keyboards and autofill do half the work for the user.
Validate inline on blur, not only on submit. Telling someone their email is wrong after they hit submit is the fastest way to lose them.
Never disable the submit button waiting for "perfect" input — let them submit and show clear, specific errors.
Cut every field you do not truly need. Each optional field measurably lowers completion.

<input
  type="email"
  name="email"
  autocomplete="email"
  inputmode="email"
  required
  aria-describedby="email-err"
/>

3. Kill layout shift and interaction jank

Cumulative Layout Shift is not just a Core Web Vitals metric — a button that jumps as an ad loads causes mis-taps and rage clicks. Reserve space for media, ads, and embeds with explicit dimensions or aspect-ratio, and never inject content above content the user is already reading.

4. Make the primary CTA unmissable and honest

One primary action per screen, high contrast, describing what happens ("Get my free audit", not "Submit"). Secondary actions get secondary styling. If a user has to hunt for the button, you have already lost some of them.

5. Instrument everything — measure, do not guess

You cannot optimise what you do not track. Fire structured events for form starts, field abandonment, CTA clicks, and completions. The gap between "form started" and "form completed" is a treasure map of exactly where users drop. The teams we work with treat CRO and conversion-focused web development as a single discipline precisely because the fixes live in the code, but the priorities come from the data.

6. A/B test without tanking performance

Client-side testing tools are notorious for causing flicker (FOOC — flash of original content) and adding render-blocking JS, which reduces the very conversions you are trying to lift. Prefer server-side or edge experiments where you can, keep the variant logic tiny, and always measure the performance cost of the testing tool itself.

A realistic workflow

Instrument the funnel and find the biggest drop-off.
Form a hypothesis about why (usually friction, confusion, or speed).
Ship the smallest front-end change that tests it.
Measure against a real baseline, not a gut feeling.
Keep the winners, revert the losers, repeat.

This is unglamorous, iterative work, but it compounds. We have documented the impact of this exact loop in our case studies — small, disciplined front-end changes adding up to double-digit conversion gains.

TL;DR

Fast pages convert better — reuse your Core Web Vitals work.
Forms are where money leaks: correct input types, inline validation, fewer fields.
Reserve space to stop layout shift and mis-taps.
One clear, honest primary CTA per screen.
Instrument the funnel; optimise the biggest drop-off first.
A/B test without adding render-blocking flicker.

Conversion is not a marketing-only concern. It is a front-end responsibility — and one of the highest-ROI things you can ship.

Written by the team at COM8 STUDIO — a digital marketing and web development agency helping brands across the UAE and US turn traffic into customers.

Structured Data in 2026: How Developers Get Their Content Cited by AI Search

Garvit Sharda — Sat, 11 Jul 2026 12:45:20 +0000

Search is splitting in two. Classic blue links are still there, but a growing share of queries now get answered directly — by Google's AI Overviews, and by ChatGPT, Perplexity, and Claude. For developers, the practical question is: what do you put in your HTML so a machine can confidently extract and cite your content?

The answer is mostly structured data — Schema.org vocabulary expressed as JSON-LD. It is the same technology that has powered rich results for years, but it matters more than ever now that LLM-based answer engines lean on it to understand entities and relationships.

Here is a developer-focused rundown.

Why JSON-LD (not Microdata or RDFa)

You can express Schema.org three ways, but JSON-LD wins for one reason: it lives in a single <script> block, decoupled from your markup. You do not have to thread itemprop attributes through your components, and it is trivial to generate from the same data you already render.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Co",
  "url": "https://acme.example",
  "logo": "https://acme.example/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/acme",
    "https://twitter.com/acme"
  ]
}
</script>

Google, Bing, and the crawlers behind AI answer engines all parse this block first.

The schema types worth your time

You do not need all 800+ Schema.org types. In practice, 90% of the value comes from a handful:

Organization / LocalBusiness — who you are, your logo, address, and sameAs links to your social and authority profiles. This is what builds your entity in the knowledge graph.
WebSite with SearchAction — enables the sitelinks search box.
Article / BlogPosting — author, datePublished, headline, image. Critical for being cited as a source.
BreadcrumbList — helps crawlers understand site hierarchy.
FAQPage — pairs a question with an answer, which answer engines love to lift verbatim.
Product / Offer and Review / AggregateRating — commerce rich results.

The sameAs trick for entity SEO

If you do one thing, do this: add a complete sameAs array to your Organization schema, pointing at every authoritative profile you own — LinkedIn, Crunchbase, GitHub, Wikidata if you have it. This is how you tell machines "all of these identities are the same entity," which is the foundation of answer engine optimization. Without a strong entity, you do not get surfaced in generated answers.

Validate before you ship

Never hand-write JSON-LD and hope. Two free tools:

Schema.org Validator (validator.schema.org) — catches vocabulary errors.
Google Rich Results Test — tells you which rich results you actually qualify for.

Wire the validator into CI if structured data is business-critical. A single malformed date or missing required field silently disqualifies you from rich results.

Generating schema in a component framework

The clean pattern in React/Next.js, Vue/Nuxt, or Astro is to build the object server-side and serialize it once:

export function ArticleSchema({ post }) {
  const json = {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    headline: post.title,
    datePublished: post.publishedAt,
    author: { "@type": "Person", name: post.author },
    image: post.coverImage,
  };
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(json) }}
    />
  );
}

Serialize with JSON.stringify (not a template literal) so quotes and special characters escape correctly — a classic source of invalid markup.

Rendering matters: do not hide it behind client-side JS

Answer-engine crawlers are far less patient than Googlebot about executing JavaScript. If your JSON-LD is injected only after hydration, some crawlers will not see it. Server-render or statically generate your structured data. This is the same crawlability principle that underpins all technical SEO — if a bot cannot cheaply read it, it does not count. When we run a technical SEO audit, missing or client-only structured data is one of the most common issues we flag.

TL;DR

Use JSON-LD in a <script type="application/ld+json"> block.
Prioritise Organization, Article, FAQPage, BreadcrumbList.
Build a complete sameAs array — it is the backbone of entity and answer-engine SEO.
Validate (Schema.org Validator + Rich Results Test), ideally in CI.
Server-render it so every crawler sees it.

Structured data used to be about star ratings in the search results. In 2026 it is about whether an AI names you as the source. Ship it.

Written by the team at COM8 STUDIO — a digital marketing and web development agency specialising in SEO, AEO/GEO, and web engineering for brands across the UAE and US.

Core Web Vitals in 2026: A Front-End Checklist That Also Boosts SEO

Garvit Sharda — Sat, 11 Jul 2026 11:50:28 +0000

Performance work used to be the thing front-end teams did "if there was time left." In 2026 it is table stakes. Core Web Vitals are a confirmed Google ranking input, and real users bounce from anything that feels sluggish on a mid-range Android phone over a flaky mobile connection.

This is the checklist I keep coming back to when I audit a site. It is written for developers, but every item also moves the SEO needle — which is exactly why performance and search visibility have stopped being two separate conversations.

The three metrics that actually matter

Largest Contentful Paint (LCP) — aim for under 2.5s. This is almost always your hero image or main headline. Quick wins: serve correctly sized images in AVIF/WebP, add fetchpriority="high" to the LCP image, preload the hero font, and remove render-blocking CSS from the critical path.

Interaction to Next Paint (INP) — aim for under 200ms. INP replaced First Input Delay in 2024 and it is far less forgiving. It measures the latency of every interaction on the page, not just the first one. Wins: break up long tasks, yield back to the main thread, debounce expensive handlers, and push non-urgent work into requestIdleCallback or a web worker.

Cumulative Layout Shift (CLS) — aim for under 0.1. Wins: set explicit width/height or aspect-ratio on all media, reserve space for ads and embeds, and never insert content above content that has already rendered.

The checklist

Images

Convert to AVIF with a WebP fallback.
Use responsive srcset/sizes so phones never download desktop-sized artwork.
Lazy-load everything below the fold with loading="lazy" — but eager-load the LCP image.

Fonts

Self-host and subset your fonts. A third-party font CDN adds a DNS lookup and a connection you do not control.
Use font-display: swap so text paints immediately.
Preload only the one or two weights you actually use above the fold.

JavaScript

Audit the bundle. A brochure or marketing site rarely needs 400KB of JS.
Code-split by route and defer everything non-critical.
Swap heavy date/utility libraries for native APIs (Intl, structuredClone, URLSearchParams).
Delay third-party tags — chat widgets, analytics, heatmaps — until the first user interaction. These are the number-one INP killers I see in real audits.

Delivery

Serve over HTTP/2 or HTTP/3 from a CDN.
Set a long Cache-Control for hashed static assets.
Turn on Brotli compression.

Measure the way Google measures

Lab tools like Lighthouse are great for catching regressions in CI, but Google ranks on field data — the Chrome User Experience Report (CrUX) gathered from real Chrome users. A site can score a perfect 100 in Lighthouse and still fail Core Web Vitals in the field, because your actual visitors are on slower devices and worse networks than your dev laptop.

So run all three:

Lighthouse in CI to catch obvious regressions before they ship.
The web-vitals npm package in production, streaming real INP/LCP/CLS into your analytics.
The Core Web Vitals report in Search Console — that is the CrUX data Google actually ranks on.

Why front-end performance is an SEO strategy

Here is the part the product and marketing side cares about: faster pages rank higher and convert better. Google has said plainly that Core Web Vitals act as a tiebreaker between pages of comparable relevance, and the correlation between a slow LCP and a high bounce rate is brutal. Every 100ms you shave off is measurable revenue on a commerce or lead-gen site.

That overlap is why the teams I work with treat performance budgets and technical SEO as a single workstream instead of two competing backlogs. When engineering owns Core Web Vitals, the SEO team stops filing tickets for problems the front-end already fixed.

If you want an outside read on where a site currently stands, a structured free SEO audit will surface the CWV failures, crawl and indexation issues, and rendering problems in one pass — and, satisfyingly, most of the recommended fixes land right back in the front-end checklist above.

A note on frameworks

None of this is framework-specific, but a few defaults help. Next.js and Nuxt give you image optimization and route-level code splitting for free. Astro and other "islands" frameworks ship near-zero JS by default, which is fantastic for content sites. SvelteKit and SolidStart compile away a lot of runtime overhead. Whatever you use, the metrics do not care about your framework — they care about bytes, main-thread time, and layout stability.

TL;DR

LCP < 2.5s — optimize hero image + font
INP < 200ms — break up long tasks, defer third-party JS
CLS < 0.1 — reserve space for media and ads
AVIF/WebP + responsive images
Self-hosted, subset fonts
Route-based code splitting
CDN + Brotli + HTTP/3
Measure field data, not just Lighthouse

Performance is a feature. Budget for it, measure it in the field, and ship it like one.

Written by the team at COM8 STUDIO — a digital marketing and web development agency working with brands across the UAE and US.