SEO, performance & accessibility

01Core Web Vitals: LCP, INP and CLS

Core Web Vitals are three metrics Google uses to describe real-user experience. Largest Contentful Paint (LCP) is when the main content, usually a hero image or heading, appears; good is 2.5 seconds or less. Interaction to Next Paint (INP) measures how quickly the page responds visually to clicks, taps and key presses across the whole visit; good is 200 milliseconds or less. INP replaced First Input Delay in March 2024. Cumulative Layout Shift (CLS) measures how much content jumps around unexpectedly; good is 0.1 or less. A page passes when 75% of real visits meet each threshold, measured separately for mobile and desktop. They are a ranking signal, but a modest one; their bigger value is conversions and user trust.

• LCP ≤ 2.5 s: loading.
• INP ≤ 200 ms: responsiveness.
• CLS ≤ 0.1: visual stability.
• Judged at the 75th percentile of real users.

02How to fix each metric

LCP has four parts: server response time (TTFB), the delay before the browser discovers the LCP resource, its download time, and render delay. Fix them in that order: cache HTML at the edge, make the hero image discoverable in the HTML (not set by JavaScript or CSS background), never lazy-load it, give it fetchpriority="high", and serve it in AVIF or WebP at the right size. INP is about main-thread work: ship less JavaScript, split long tasks so the browser can paint between them (scheduler.yield() or setTimeout), use startTransition for non-urgent React updates, and avoid heavy third-party scripts. CLS is about reserved space: always set width and height or aspect-ratio on images and embeds, reserve space for banners and ads, and use font fallbacks with matching metrics.

1<!-- LCP image: discoverable, eager, high priority, right size -->
2<img
3  src="/img/hero-1200.avif"
4  srcset="/img/hero-800.avif 800w, /img/hero-1200.avif 1200w, /img/hero-1800.avif 1800w"
5  sizes="(max-width: 768px) 100vw, 1200px"
6  width="1200" height="675"
7  fetchpriority="high"
8  alt="Fresh coffee being poured into a cup" />
9 
10<!-- below-the-fold images -->
11<img src="/img/team.avif" width="800" height="600" loading="lazy" decoding="async" alt="Our team" />

03Crawling, indexing and canonicals

Search engines work in three steps: crawl (fetch URLs), index (store and understand them) and rank. robots.txt controls crawling, not indexing: a blocked URL can still appear in results if other sites link to it. To keep a page out of the index, allow crawling and return a noindex meta tag or X-Robots-Tag header. A canonical link tells search engines which URL is the main version when the same content is reachable at several addresses, such as with tracking parameters or filters; it is a strong hint, not a command. Return real status codes: 301 for permanent moves, 404 or 410 for removed pages, and never a 200 'not found' page. Make sure important content is in the server-rendered HTML, not only loaded by client JavaScript.

1# robots.txt
2User-agent: *
3Disallow: /cart
4Disallow: /account
5Disallow: /*?sort=
6 
7Sitemap: https://example.com/sitemap.xml

04Sitemaps, structured data and hreflang

A sitemap lists the URLs you want indexed, with an accurate lastmod date; Google ignores priority and changefreq. One file holds up to 50,000 URLs or 50 MB uncompressed, so large sites use a sitemap index. Structured data, usually JSON-LD in a script tag, describes the page in a vocabulary from schema.org: Organization, Product with Offer, BreadcrumbList, Article, Event. It can unlock rich results such as prices and ratings. For multilingual sites, hreflang tells search engines which URL is for which language or region. Every version must list all versions including itself, the links must be reciprocal, and x-default points at the fallback. Use language codes like en, hy, ru, optionally with a region like en-GB.

1<link rel="canonical" href="https://example.com/en/products/espresso" />
2<link rel="alternate" hreflang="en" href="https://example.com/en/products/espresso" />
3<link rel="alternate" hreflang="hy" href="https://example.com/hy/products/espresso" />
4<link rel="alternate" hreflang="ru" href="https://example.com/ru/products/espresso" />
5<link rel="alternate" hreflang="x-default" href="https://example.com/en/products/espresso" />
6 
7<script type="application/ld+json">
8{ "@context": "https://schema.org", "@type": "Product", "name": "Espresso beans 1 kg",
9  "offers": { "@type": "Offer", "price": "24.90", "priceCurrency": "EUR",
10              "availability": "https://schema.org/InStock" } }
11</script>

05Image and font optimisation

Images are usually the heaviest part of a page. Serve modern formats (AVIF, then WebP), resize to the displayed size with srcset and sizes, compress, and lazy-load everything below the fold. Frameworks help: Next.js's Image component generates sizes and formats automatically; in Next.js 16 the old priority prop is replaced by preload, and the docs recommend loading="eager" or fetchPriority="high" for the LCP image. Fonts cause both slow text and layout shift. Self-host them, subset to the characters you need (separate files for Latin, Cyrillic or Armenian), preload only the one or two critical files, use font-display: swap, and use a fallback font with size-adjust so the swap does not move text. Variable fonts can replace several weight files with one.

1@font-face {
2  font-family: "Brand Sans";
3  src: url("/fonts/brand-sans-latin.woff2") format("woff2");
4  font-display: swap;
5  unicode-range: U+0000-00FF;
6}
7 
8/* metric-matched fallback reduces layout shift on swap */
9@font-face {
10  font-family: "Brand Sans Fallback";
11  src: local("Arial");
12  size-adjust: 104%;
13  ascent-override: 92%;
14}

06Accessibility essentials (WCAG)

WCAG (Web Content Accessibility Guidelines) is the standard; version 2.2 at level AA is the usual target and is what laws like the European Accessibility Act, enforced since June 2025, point to. The essentials cover most real problems. Use semantic HTML: one h1, headings in order, landmarks (header, nav, main, footer), button for actions and a for links. Every image needs meaningful alt text, or alt="" if decorative. Text contrast must be at least 4.5:1, or 3:1 for large text and UI components. Everything must work with a keyboard, with a visible focus indicator. Forms need real labels and clear error messages. Targets should be at least 24 by 24 CSS pixels. Set the lang attribute per page, which matters for screen readers on multilingual sites.

• Semantic elements first, ARIA only when HTML has no equivalent.
• Keyboard: Tab order, visible focus, no traps, Escape closes dialogs.
• Contrast 4.5:1 text, 3:1 large text and controls.
• Test with a screen reader (VoiceOver, NVDA) and 200% zoom.

07Measuring: Lighthouse, PageSpeed and CrUX

There are two kinds of data. Lab data comes from a simulated load on a fixed device and network: Lighthouse in Chrome DevTools or in CI. It is repeatable and great for debugging, but it cannot measure INP directly; Total Blocking Time is its proxy. Field data comes from real Chrome users: the Chrome UX Report (CrUX), which aggregates the previous 28 days. PageSpeed Insights shows both for a URL, and Search Console groups field data across your whole site. For your own detailed numbers, add the web-vitals library and send metrics to your analytics, including which element was the LCP and which interaction was slow. Optimise based on field data, verify fixes in the lab, then wait for field data to confirm.

1import { onLCP, onINP, onCLS } from "web-vitals/attribution";
2 
3function send(metric: { name: string; value: number; rating: string }) {
4  navigator.sendBeacon("/api/vitals", JSON.stringify(metric));
5}
6 
7onLCP(send);
8onINP(send);
9onCLS(send);

08Inside INP: input delay, processing and presentation

INP reports roughly the worst interaction of a visit; on pages with many interactions, one outlier per 50 is ignored. Every interaction has three parts, and each has a different fix. Input delay is the time before your handler even starts, usually because another long task is running, such as hydration, a tag manager or an analytics batch. Processing time is your event handlers themselves. Presentation delay is the work after the handlers until the next frame is painted: style, layout and paint of whatever changed, which grows with DOM size and with large React re-renders. The Long Animation Frames API (LoAF) reports which scripts made a frame slow, down to source URL and function, and the web-vitals attribution build attaches those entries to INP. So: break up competing long tasks to cut input delay, paint the visual feedback first and defer the rest to cut processing, and keep the DOM small and updates local to cut presentation delay.

1const yieldToMain = () =>
2  "scheduler" in globalThis && "yield" in scheduler
3    ? scheduler.yield()
4    : new Promise((resolve) => setTimeout(resolve, 0));
5 
6button.addEventListener("click", async () => {
7  showAddedState();      // 1. visual feedback in this frame
8  await yieldToMain();   // 2. let the browser paint
9  await saveCart();      // 3. heavy work afterwards
10  sendAnalytics();
11});

09Instant navigations: bfcache and speculation rules

The fastest page load is the one that never happens. The back/forward cache (bfcache) keeps a complete snapshot of a page in memory, so Back and Forward restore it instantly with no network and no JavaScript re-run. A page loses that benefit if it registers an unload handler, holds certain open connections when the user leaves, or is excluded by headers such as Cache-Control: no-store. DevTools, under Application and Back/forward cache, tests a page and lists exactly why it is blocked. For forward navigations, the Speculation Rules API lets Chromium-based browsers prefetch or fully prerender likely next pages, either from a list or by matching links, with an eagerness setting such as moderate (start on hover). A prerendered page shows near-zero LCP when opened. Other browsers ignore the rules, so it is a safe progressive enhancement. Prerender only side-effect-free GET pages, exclude logout or add-to-cart links, and delay analytics until the page is actually shown, using document.prerendering.

1<script type="speculationrules">
2{
3  "prerender": [{
4    "where": { "and": [
5      { "href_matches": "/*" },
6      { "not": { "href_matches": "/logout" } },
7      { "not": { "href_matches": "/cart/*" } },
8      { "not": { "selector_matches": "[data-no-prerender]" } }
9    ]},
10    "eagerness": "moderate"
11  }]
12}
13</script>

10Crawl budget and rendering on large sites

A site with a few hundred pages gets crawled completely. With hundreds of thousands of URLs, such as a faceted catalogue, crawl budget becomes real: Googlebot spends a limited number of fetches per site, shaped by how fast and healthy your server is and how much demand exists for your URLs. Waste comes from infinite URL spaces: filter combinations, sort orders, session or tracking parameters, endless calendars. Control it in layers. Link prominently only to the facet pages you want indexed. Keep other combinations canonicalised to the base page, or disallow parameters in robots.txt if they should not even be fetched; remember that a blocked URL cannot show its noindex. Keep sitemaps to canonical, indexable URLs with honest lastmod. Server logs filtered to verified Googlebot show where crawling really goes. Rendering matters too: Google executes JavaScript, but as a separate, more expensive step, so content and links that appear only after client-side fetching are found later and less reliably.

• Fast, stable responses (low TTFB, few 5xx errors) let Googlebot crawl more.
• Return 404 for empty filter combinations instead of a thin 200 page.
• Search Console's Crawl stats report shows response codes, file types and host status.

11Accessibility beyond the checklist: names, roles and live updates

Automated tools catch only part of WCAG failures; the rest needs an understanding of the accessibility tree. The browser turns the DOM into a tree of objects, each with a role (button, link, dialog), an accessible name (from text content, a label, aria-label or aria-labelledby), states such as expanded or checked, and an optional description. Screen readers read this tree, not your pixels; inspect it in the DevTools Accessibility pane. Deeper issues show up there: icon buttons with no name; custom dropdowns that are not keyboard operable; single-page navigations that swap content without moving focus, so screen-reader users do not know the page changed (move focus to the new h1 or announce the title); status messages like 'added to cart' that appear visually but are never announced. For announcements, use a live region such as role='status' that already exists in the DOM before you change its text. The native dialog element with showModal() traps focus and handles Escape for you. Test key flows with VoiceOver or NVDA.

1<button type="button" aria-label="Open cart" aria-expanded="false" aria-controls="cart">
2  <svg aria-hidden="true" focusable="false"><!-- icon --></svg>
3</button>
4 
5<!-- present on page load; changing its text is announced politely -->
6<p role="status" class="visually-hidden" id="cart-status"></p>
7 
8<dialog id="cart" aria-labelledby="cart-title">
9  <h2 id="cart-title">Your cart</h2>
10  <!-- opened with cart.showModal(): focus is trapped, Escape closes -->
11</dialog>