What does TanStack Query solve?

Direct answer: TanStack Query (formerly React Query) solves server state management — the specific pain of fetching, caching, syncing, and updating data that lives on a server but needs to be displayed in your UI. It's not a replacement for client state tools like Redux/Zustand; it's a specialized layer for async data.

The problem it solves, concretely:

Before TanStack Query, a typical useEffect + fetch pattern forces you to manually handle:

function Todos() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    setLoading(true);
    fetch('/api/todos')
      .then(res => res.json())
      .then(setData)
      .catch(setError)
      .finally(() => setLoading(false));
  }, []);
  // ...
}

This looks fine until you need: caching (so navigating away and back doesn't refetch), deduping (two components requesting the same data shouldn't fire two network calls), background refetching, retry logic, pagination state, "is this data stale?" tracking, race-condition handling (slow request resolving after a faster newer one), and refetch-on-window-focus. You end up reinventing all of this by hand, badly, across every component.

TanStack Query gives you that out of the box:

function Todos() {
  const { data, isLoading, error } = useQuery({
    queryKey: ['todos'],
    queryFn: () => fetch('/api/todos').then(res => res.json()),
  });
  // done — caching, dedup, retries, refetch-on-focus all included
}

Core mechanism: It maintains a global, normalized cache keyed by queryKey (an array, e.g. ['todos', { status: 'done' }]). Every component calling useQuery with the same key subscribes to the same cache entry — so data is shared, requests are deduped, and updates in one place propagate to every consumer.

It also tracks each cache entry's status (fresh, stale, inactive) on a timer, which is the foundation for invalidation.

How cache invalidation works

Direct answer: Invalidation means marking cached data as "stale" so TanStack Query knows to refetch it — either immediately (if a component is actively observing it) or on the next trigger (refocus, remount, etc.).

The mechanism, step by step:

1. Every query result is stored under its queryKey with a timestamp and a staleTime.

2. While data is within staleTime, it's considered fresh — components get it instantly from cache, no network call.

3. Once staleTime elapses, the data is stale — still shown immediately (cache-first), but eligible for a background refetch on the next trigger (refocus, reconnect, remount).

4. queryClient.invalidateQueries() manually forces this stale transition right now, and if there's an active observer (a mounted component using that query), it triggers an immediate refetch.

Most common pattern — invalidating after a mutation:

const queryClient = useQueryClient();

const { mutate } = useMutation({
  mutationFn: (newTodo) => axios.post('/api/todos', newTodo),
  onSuccess: () => {
    // mark 'todos' as stale → triggers refetch for active observers
    queryClient.invalidateQueries({ queryKey: ['todos'] });
  },
});

Note invalidateQueries does fuzzy/partial matching by default — { queryKey: ['todos'] } invalidates ['todos'], ['todos', 1], ['todos', { status: 'done' }], etc. You can use exact: true to scope it down.

Other invalidation triggers besides manual calls:

• refetchOnWindowFocus (default: true)

• refetchOnReconnect

• refetchOnMount if the data is stale

• A refetchInterval for polling

Common follow-up questions

• "What's the difference between invalidateQueries and setQueryData?" — invalidateQueries marks data stale and triggers a refetch from the server. setQueryData directly writes into the cache without a network call — used for optimistic updates or when a mutation response already gives you the fresh data, so you don't need a round trip.

• "How do you do optimistic updates?" — In onMutate, snapshot the old cache value, call setQueryData with the optimistic value, then in onError roll back using the snapshot, and in onSettled call invalidateQueries to reconcile with the server's actual state.

• "What's staleTime vs cacheTime/gcTime?" — staleTime controls how long data is considered fresh (no auto-refetch). gcTime (renamed from cacheTime in v5) controls how long unused (no active observers) data stays in memory before being garbage collected entirely. People conflate these constantly — staleness is about refetch behavior, gc time is about memory cleanup.

• "How does it handle race conditions?" — Each query execution is tracked, and only the result matching the latest invocation gets written to cache, so a slow stale request resolving late won't overwrite newer data.

Gotchas

• Invalidating doesn't clear the cache — it keeps showing old data (no loading flicker) while refetching in the background. People expect a blank/loading state and are surprised it shows stale-then-fresh.

• invalidateQueries only triggers an immediate refetch if there's a mounted, active observer for that key. If no component is currently subscribed, it just marks it stale for next time.

How to phrase it out loud

"TanStack Query manages server state — caching, deduping, and syncing async data — instead of forcing you to hand-roll loading/error/cache logic with useEffect. Invalidation works by marking a cached query's queryKey as stale; if there's an active component subscribed to that key, it triggers an immediate background refetch, otherwise it just refetches the next time something mounts or refocuses the window. The most common use is calling invalidateQueries after a mutation succeeds, so related data stays in sync without manual cache surgery."

I'd rather verify the current specifics here than rely on memory — Next.js routing internals are exactly the kind of thing that shifts between versions, and I want to give you accurate detail instead of stale facts.Good — confirms the core architecture and surfaces one genuinely current detail worth knowing (the "use cache" directive shift in Next.js 16). Here's the structured answer:

App Router vs Pages Router — key architectural differences?

Direct answer: They're two different routing/rendering systems within Next.js. Pages Router (the original, pages/ directory) is page-centric — each file is a route, and data fetching happens via special exported functions at the page level. App Router (app/ directory, introduced in Next.js 13) is component-centric, built around React Server Components, where rendering location (server vs client) and data fetching happen per-component rather than per-page.

Routing convention

The App Router's special files are a meaningful shift: instead of one global _app.js wrapper, each route segment can have its own layout.tsx, loading.tsx (automatic Suspense boundary), and error.tsx (automatic error boundary) — colocated with the route itself.

Rendering model — the real architectural difference

Pages Router: Everything is a Client Component by default. The server renders HTML once, then ships the full component code as JS to hydrate. Data fetching is tied to the page via getServerSideProps, getStaticProps, or getInitialProps — these functions couple data fetching to the route level, meaning you can't easily fetch data inside a specific component without prop-drilling it from the top-level page.

App Router: Components are Server Components by default. They render on the server, never ship their JS to the browser, and can fetch data directly inside the component itself — no special exported function needed, just async/await in the component body. You opt into client-side interactivity explicitly with a 'use client' directive at the top of a file.

// Pages Router — data fetching forced to page level
export async function getServerSideProps() {
  const data = await fetch('...');
  return { props: { data } };
}
export default function Page({ data }) { /* ... */ }

// App Router — fetch directly inside any server component
export default async function Page() {
  const data = await fetch('...').then(r => r.json());
  return <div>{data.title}</div>;
}

This is the "biggest conceptual shift" cited consistently across sources — it isn't the syntax, it's thinking in terms of the server/client boundary rather than page-level data fetching functions.

Layouts

Pages Router has no native nested layout system — layouts are wrappers around the page Component in _app.js, which makes persistent nested layouts difficult to manage and preserve state like scroll position during navigation.

App Router makes layouts first-class and nested: a layout.tsx in any folder wraps everything beneath it and persists across navigations within that segment — it renders once and doesn't re-render when the user navigates between child routes, e.g. a dashboard sidebar stays mounted while only the inner content swaps.

Streaming & loading states

App Router supports React Suspense natively per-segment — you can show the page shell immediately and a loading skeleton for the main content while data fetches, and SaaS teams now commonly stream dashboard shells immediately while slower analytics widgets load progressively in parallel, which was significantly harder to implement cleanly in the Pages Router. Pages Router has no equivalent granular per-section streaming — it's closer to all-or-nothing per page.

Bundle size / performance

Because Server Components never ship to the client, App Router apps can ship meaningfully less JS — Server Components reduce the JavaScript sent to the browser, leading to faster load times and better Core Web Vitals.

Caching — worth knowing if asked about Next.js 16 specifically

This is a genuinely recent and important shift: Cache Components replaced the old implicit caching model entirely in Next.js 16 — caching is now opt-in via a "use cache" directive, the opposite of how it worked before. Before this, App Router's automatic/implicit fetch caching was widely cited as the most confusing part of the system — most engineering teams struggled with caching behavior first, since multiple caching layers interacted differently depending on fetch settings, rendering mode, and navigation state, sometimes causing real bugs like e-commerce teams discovering stale inventory data because route caching persisted longer than expected.

Common follow-up questions

• "Which would you pick for a new project today?" — App Router is now the recommended standard as of Next.js 13's introduction and 14's stabilization, and most sources converge on App Router for new projects, Pages Router acceptable for legacy maintenance. But mention the real exception: apps heavily dependent on client-side/browser-API-bound libraries — like Web3 wallet libraries (wagmi, ethers, web3.js) — are deeply client-side, and the 'use client' boundary dance gets exhausting when 80% of the app depends on browser APIs, making Pages Router a reasonable pick there.

• "Are there stability/security concerns with App Router?" — Worth mentioning if asked: there was a notable CVE history around React Server Components in late 2025/early 2026 — four rounds of security patches in three months targeting RSC deserialization — and Pages Router was immune to all of them, which matters for compliance-sensitive industries like fintech/healthcare.

• "Can you migrate incrementally?" — Yes — Next.js supports both routers in the same project; you can keep pages/ working while adding new routes in app/, and this is the generally recommended migration path rather than a big-bang rewrite.

• "What's a Server Component vs a Client Component, mechanically?" — Good follow-up to be ready for separately — Server Components run only on the server and their output is serialized into the response; Client Components hydrate and run in the browser like classic React. The 'use client' directive marks the boundary, not just one component — everything imported beneath it in the tree also becomes part of the client bundle.

Gotchas

• Don't say "App Router is just SSR by default" — Server Components are a distinct concept from SSR. SSR is about when HTML is generated; Server Components are about where code executes and whether it ships to the client at all. You can have Server Components that are statically generated, ISR'd, or dynamically rendered per-request.

• If discussing caching, don't describe the old "implicit fetch caching" as current behavior without caveat — it changed materially in Next.js 16's Cache Components model.

How to phrase it out loud

"Pages Router is page-centric — every file is a route, and data fetching happens through special functions like getServerSideProps at the page level, which forces prop-drilling into child components. App Router is component-centric, built on React Server Components — components render on the server by default, can fetch data directly inline with async/await, and never ship their JS to the client unless you opt in with 'use client'. App Router also gives you native nested layouts that persist across navigation, and per-segment streaming with Suspense, neither of which Pages Router has natively. The trade-off is that App Router's caching model is more powerful but historically more confusing — Next.js 16 actually overhauled this to make caching opt-in via a use cache directive instead of implicit."

What are React Server Components?

Direct answer: React Server Components (RSC) are components that render only on the server and never ship their JavaScript to the browser. The server runs them, produces a serialized output (not HTML, something richer — more on that below), and sends that down to the client, where it gets stitched together with any Client Components to form the final UI. The defining trait: their code, dependencies, and any server-only logic (DB calls, secrets, file system access) never reach the browser bundle at all.

This is a different axis from SSR. SSR is about when HTML gets generated (per-request vs build-time). RSC is about where a component's code lives and executes, permanently — it's not a one-time render-to-HTML-then-hydrate step, it's a category of component that has no client-side existence at all.

The core mechanism

In a framework like Next.js App Router, every component is a Server Component by default. You opt into client-side behavior explicitly:

// Server Component (default — no directive needed)
async function ProductList() {
  const products = await db.query('SELECT * FROM products'); // runs ONLY on server
  return (
    <ul>
      {products.map(p => <ProductCard key={p.id} product={p} />)}
    </ul>
  );
}

// Client Component — explicit opt-in
'use client';

function AddToCartButton({ productId }) {
  const [pending, setPending] = useState(false); // hooks need the client
  return <button onClick={() => addToCart(productId)}>Add to cart</button>;
}

You can mix them — a Server Component can render a Client Component as a child, and pass it serializable props. But a Server Component cannot be imported into a Client Component's render tree directly (because by the time you're on the client, the server component's code doesn't exist there) — instead it gets passed down as children from a parent Server Component.

Why this matters — what problem it solves

1. Zero bundle cost for server-only logic. A component that fetches from a database, reads a file, or uses a heavy parsing library never adds a single byte to the client JS bundle, because it's never sent there.

2. Direct backend access, no API layer needed. You can await db.query() or call an internal service directly inside the component — no need to build a REST/GraphQL endpoint just to shuttle data to the client.

3. Secrets stay secret. API keys, DB credentials — these can live in a Server Component's code path without any risk of leaking into client-visible JS, since that code never gets bundled for the browser.

4. Composability with streaming. Because the server can resolve different components independently, slow data-fetching components can stream in progressively (paired with Suspense) without blocking the rest of the page.

Server Components vs Client Components — decision table

What actually gets sent over the wire

This is a detail that signals real understanding if you bring it up: RSC doesn't serialize to HTML strings the way traditional SSR does. It serializes to a special RSC payload format — a tree-like representation that describes which Client Components to mount where, with their props, interleaved with the already-rendered output of Server Components. The client-side React runtime reconstructs the UI from this payload, hydrating only the Client Component "islands" while leaving the Server Component output as-is (no hydration needed for those — there's nothing to attach event listeners to since they have none).

Common follow-up questions

• "Why can't Server Components use useState?" — State and effects are inherently about a live, interactive instance running in a browser tab over time. A Server Component runs once, produces output, and is done — there's no persistent instance on the server to hold state across renders (the server isn't tracking "your" component instance the way a browser is).

• "How do Server and Client Components communicate?" — Server → Client: via props (must be serializable — no functions, no class instances, no Dates without conversion). Client → Server: via Server Actions (functions marked 'use server' that the client can invoke, which actually execute back on the server, like a built-in RPC mechanism).

• "What's the catch / downside?" — Mental model overhead is real. You now have to constantly think about which "side" a piece of code is allowed to run on, and a common beginner mistake is trying to use a hook or browser API inside a Server Component and getting a build error. Also, as noted in the App Router caching discussion, debugging the server/client boundary and caching interactions has been a genuine pain point for teams adopting this.

• "Are Server Components the same as SSR?" — No — explicitly call this out if asked, since it's the most common conflation. SSR renders a full page to HTML on each (or build-time) request and then hydrates the whole thing. RSC is about which individual components execute server-side permanently, with zero client-side footprint, and composes with SSR/SSG/ISR rather than replacing them — you can statically generate a page that's entirely built from Server Components, for example.

• "What's a Server Action and how is it different from RSC?" — RSC is about rendering on the server. Server Actions are about mutating — they let a Client Component trigger a server-side function (e.g., a form submit calling a DB write) without manually building an API route.

Gotchas

• A very common interview trap: someone says "Server Components are rendered to HTML and sent down" — not quite right. They're rendered to the RSC payload format, which is richer than HTML (it encodes the tree structure with placeholders for Client Components), and that payload is what enables things like re-fetching just a sub-tree on navigation without a full page reload.

• Forgetting that 'use client' marks a boundary, not a single file — every component imported underneath that file (unless it itself starts a server boundary again via specific patterns) becomes part of the client bundle too.

How to phrase it out loud

"Server Components are components that run exclusively on the server and never ship their code to the browser at all — not 'render once and hydrate,' but genuinely no client-side existence. That means they can directly access databases or secrets without an API layer, and they add zero bytes to the client bundle. You opt into client-side behavior — state, effects, event handlers — explicitly with a 'use client' directive, and that marks a boundary: everything imported below it becomes part of the client bundle too. It's a different axis from SSR — SSR is about when HTML gets generated, RSC is about where a component's code is allowed to live and execute, period."

How does Next.js handle code splitting?

Direct answer: Next.js automatically splits your JavaScript bundle into smaller chunks so that each page (or route) only loads the code it actually needs, instead of shipping one giant bundle for the whole app. This happens largely without you writing any special code — it's a build-time optimization layered on top of webpack/Turbopack, plus some explicit APIs for splitting beyond the automatic defaults.

The default behavior — automatic route-based splitting

Every route gets its own JS chunk. If you have app/dashboard/page.tsx and app/settings/page.tsx, visiting /dashboard does not download the code for /settings. This is true for both Pages Router and App Router — it's foundational to how Next.js has always worked.

.next/static/chunks/
  ├── pages/dashboard.js   ← only loaded when visiting /dashboard
  ├── pages/settings.js    ← only loaded when visiting /settings
  └── framework.js, main.js ← shared runtime, loaded everywhere

Shared code (React itself, common utilities used across multiple routes) gets extracted into shared chunks so it's downloaded once and cached, rather than duplicated into every page's bundle.

Explicit code splitting — next/dynamic

For splitting within a page — e.g., a heavy component that isn't needed immediately (a modal, a chart library, a rich text editor) — you use next/dynamic to lazy-load it:

import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('./HeavyChart'), {
  loading: () => <p>Loading chart...</p>,
  ssr: false, // skip server-rendering this component entirely
});

function Dashboard() {
  return (
    <div>
      <h1>Dashboard</h1>
      <HeavyChart /> {/* only fetched when this renders */}
    </div>
  );
}

This is the standard pattern for: chart libraries (Recharts, Chart.js), rich text editors, anything behind a modal/tab that isn't visible on initial load, or browser-only libraries that can't run during SSR (ssr: false is common here, e.g. for libraries touching window).

How this interacts with Server Components (App Router specific)

This is worth bringing up since it connects to the earlier RSC discussion — Server Components add a second, more powerful layer of "splitting" on top of bundler-level code splitting: a Server Component's code never enters the client bundle at all, not even as a lazily-loaded chunk. It's not "split and loaded on demand" — it's "never shipped, period." So in App Router apps, a lot of what used to require manual next/dynamic splitting (e.g., a component using a heavy server-side parsing library) is now solved structurally just by keeping that component a Server Component.

next/dynamic is still relevant in App Router, but mainly for Client Components you want to defer — e.g., a client-side chart library that's below the fold.

Other splitting mechanisms worth knowing

• Per-component dynamic imports without next/dynamic — plain React.lazy + Suspense also works and is supported, though next/dynamic is the Next.js-idiomatic wrapper with extra features (SSR toggle, custom loading state).

• Shared chunk deduplication — webpack's SplitChunksPlugin (used under the hood) automatically groups modules used by multiple pages into shared chunks so common dependencies aren't duplicated per-route.

• Third-party script loading — next/script lets you control when third-party scripts load (beforeInteractive, afterInteractive, lazyOnload), which isn't code splitting in the bundler sense but solves the same underlying goal: don't block initial load with code you don't need yet.

Common follow-up questions

• "When would you use next/dynamic vs just relying on automatic splitting?" — Automatic splitting handles the page-boundary case for free. You reach for next/dynamic when a single page contains something heavy that isn't needed for the initial render — e.g., a modal that's closed by default, or a library only needed after a user interaction.

• "What does ssr: false actually do and when do you need it?" — It tells Next.js to skip rendering that component on the server entirely, rendering it only in the browser. You need this for components that depend on browser-only APIs (window, document, localStorage) that would throw or behave incorrectly during server rendering.

• "How do you verify your code splitting is actually working?" — next build outputs a per-route bundle size table in the terminal, and the @next/bundle-analyzer plugin gives a visual treemap of what's in each chunk — useful for spotting an accidentally-bloated shared chunk (e.g., a huge library imported at the top level that ends up in every page).

• "Does code splitting affect SEO or initial load negatively?" — Generally it helps — smaller initial JS payload means faster Time-to-Interactive. The risk is over-fragmenting: too many tiny chunks means more round trips, so there's a balance (which Next.js's bundler defaults are already tuned for).

Gotchas

• A subtle one: next/dynamic with ssr: false means that component contributes nothing to the server-rendered HTML — if you need it for SEO-relevant content, that's the wrong tool.

• Importing a large library at the top of a shared layout or _app.js/root layout defeats route-based splitting — it gets pulled into the shared chunk and loaded on every single page, even ones that don't use it. This is one of the most common real-world bundle bloat bugs.

• Conflating "lazy loading a component" with "Server Component never shipping" — they solve overlapping problems but are mechanically different: one is deferred-but-eventually-downloaded, the other is never-downloaded-at-all.

How to phrase it out loud

"Next.js automatically splits JS per route, so visiting one page doesn't download the code for every other page — that's free, no setup needed. For splitting within a page, like a heavy modal or chart library you don't need on initial render, you use next/dynamic to lazy-load it, optionally skipping SSR for browser-only code. In the App Router, Server Components add a more aggressive layer on top of that — their code never enters the client bundle at all, not even as a deferred chunk — so a lot of what used to require manual splitting is now solved just by keeping a component server-only."

I want to make sure I'm giving you current Core Web Vitals metrics and Next.js-specific tooling rather than relying on memory, since both the metric set and the framework APIs shift over time.Good, this confirms the official thresholds (LCP ≤2.5s, INP ≤200ms, CLS ≤0.1 — note one source incorrectly claimed a 2.0s LCP bar, but Google's own docs confirm 2.5s is unchanged) and gives current Next.js-specific tooling. Here's the structured answer:

How would you optimize Core Web Vitals in a Next.js app?

Direct answer: Core Web Vitals are three metrics — Largest Contentful Paint (LCP) measuring loading performance, Interaction to Next Paint (INP) measuring responsiveness, and Cumulative Layout Shift (CLS) measuring visual stability — and Next.js gives you built-in primitives for each, but the framework defaults only get you partway; the rest is architectural discipline. Google's recommended thresholds are LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, evaluated at the 75th percentile of real visitor data — meaning 75% of your actual users need a good experience, not just your fastest test run.

1. LCP — Largest Contentful Paint

This is statistically the hardest one to pass — on mobile, only about 62% of pages achieve a good LCP, versus 77% for INP and 81% for CLS, so it's usually where you'll find the most leverage.

Next.js-specific fixes:

• next/image — automatically generates responsive sizes, serves WebP/AVIF, adds width/height for CLS prevention, and lazy-loads below-the-fold images. Critically: do not lazy-load the actual LCP element (usually a hero image) — give it priority instead, which maps to preloading the LCP image with fetchpriority="high".

• next/font — self-hosts Google Fonts, generates fallback metrics automatically, and applies font-display swap, avoiding the render-blocking external font request.

• Rendering strategy — static generation gives pages near-zero TTFB from CDN edge, giving LCP a massive head start. If a page's data doesn't need to be request-fresh, prefer SSG/ISR over SSR purely for this reason.

• Reduce TTFB generally — reduce server response time with caching, a CDN, and efficient rendering; for SSR pages this means watching what blocks the response (e.g., a slow DB query awaited before any HTML streams).

import Image from 'next/image';

<Image
  src="/hero.jpg"
  alt="Hero"
  width={1200}
  height={600}
  priority // tells the browser this is the LCP candidate — don't lazy load
/>

2. INP — Interaction to Next Paint

This is the metric most sites fail and the one requiring the deepest technical changes — 43% of sites still fail the 200ms threshold. Unlike its predecessor FID, INP captures responsiveness across every interaction in a session, not just the first one, so a page that feels snappy on first click but janky on the fifth still fails.

Root cause, almost always: JavaScript blocking the main thread when the user interacts.

Next.js-specific fixes:

• Server Components — reduce client-side JavaScript, lowering INP by reducing main thread work during interactions. This connects directly back to the RSC discussion: less hydrated/interactive JS on the page means less for the main thread to chew through when a user clicks something.

• Code splitting (next/dynamic) — defers non-critical interactive widgets so they don't compete for main-thread time during initial interaction windows.

• Break up long tasks — break up long tasks into smaller chunks to avoid blocking the thread, e.g., chunking expensive client-side computation with setTimeout/scheduler APIs so the browser can paint between chunks.

• Minimize work inside event handlers themselves — defer non-essential logic (analytics calls, secondary state updates) out of the critical interaction path.

3. CLS — Cumulative Layout Shift

The easiest of the three to fix mechanically — CLS has the highest pass rate because explicit dimensions are a straightforward fix.

Next.js-specific fixes:

• next/image again — it adds width/height for CLS prevention automatically, so as long as you pass width/height (or use fill with a sized parent), you avoid the classic "image pops in and shoves content down" shift.

• next/font again — zero CLS from font loading, since it computes fallback metrics that match the real font's size, avoiding the reflow when a web font swaps in.

• Generally: every image, video, iframe, and ad slot needs explicit width and height attributes, and reserve space for any dynamically-injected content (banners, ads, late-loading widgets) before it arrives.

How to measure and validate

• Field data over lab data: Lighthouse scores do not directly affect Core Web Vitals — Google uses real user data from CrUX to evaluate them, so a great Lighthouse score doesn't guarantee a passing CrUX assessment. Use Lighthouse for diagnosing, but validate against real user data (Search Console's Core Web Vitals report, or your own RUM/analytics) for truth.

• All three must pass simultaneously: a URL group only gets a "Good" status when at least 75% of visits meet the Good threshold for all three metrics simultaneously — fixing two out of three doesn't help if the third is still poor.

• Regression detection: set alerts at 80% of Google's thresholds — INP > 160ms, LCP > 2.0s, CLS > 0.08 — so you catch a regression before it actually crosses into "poor" territory in production.

Common follow-up questions

• "Why is INP harder to fix than LCP or CLS?" — Unlike LCP issues, which are often fixed by compressing an image or enabling a cache, fixing INP requires major changes to JavaScript architecture, since you need to rethink how your code handles user events rather than just optimizing file size. It's a structural problem (how much JS runs and when), not a swap-this-asset problem.

• "How does the App Router specifically help here versus Pages Router?" — Tie back to the RSC conversation: less client JS by default (helps INP), built-in streaming/Suspense for progressive rendering (helps perceived LCP even when actual data is slow), but the caching complexity discussed earlier can also hurt LCP if misconfigured (e.g., serving stale-but-fast content is fine for LCP itself, but a caching bug causing unexpectedly slow uncached paths would hurt TTFB).

• "What's the business case for caring about this?" — Worth having a number ready: for every second of delay beyond the 2.5-second LCP threshold, bounce rates increase by 32%, and a one-second delay in load time reduces conversions by 7%. Frames it as a product/revenue issue, not just a dev nicety — useful for an interview that wants to see business awareness, not just technical trivia.

• "What page types tend to fail which metric?" — Blog posts and homepages most commonly fail LCP due to image issues, product/category pages tend to struggle with CLS from dynamic content loading, and INP failures concentrate on pages with heavy JS interactions — checkouts, landing pages with forms, filter-heavy listing pages. Good to mention if asked to prioritize across a real site.

Gotchas

• Don't quote LCP's threshold as 2.0 seconds — that's a claim circulating in some lower-quality sources, but Google's own documentation is explicit that the LCP good threshold is 2,500ms, and a claim that it dropped to 2.0s in 2026 is wrong.

• Lighthouse ≠ Core Web Vitals pass/fail — conflating lab data with field data is a common interview-answer mistake.

• priority on more than one image defeats its own purpose — it should be reserved for the actual LCP candidate, not applied broadly "just in case."

How to phrase it out loud

"For LCP, I'd lean on next/image with priority on the hero element instead of lazy-loading it, use next/font to avoid render-blocking font requests, and prefer static generation or ISR over SSR where data freshness allows, since that gets TTFB near-zero from the CDN edge. For INP, the big lever is reducing client-side JS — Server Components help structurally here — plus code-splitting non-critical interactive widgets and breaking up long tasks so the main thread isn't blocked during a user interaction. For CLS, it's mostly discipline: explicit width/height on every image and embed, and next/image/next/font handle most of that automatically. I'd validate against real user field data — Search Console's CrUX report — rather than trusting Lighthouse alone, since Google's ranking signal is based on the 75th percentile of actual visits, not lab scores."

export const revalidate = 60 in a route tells Next.js to regenerate the page in the background if a request comes in after 60 seconds. On-demand revalidation: call revalidatePath('/blog/slug') or revalidateTag('posts') inside a Route Handler or Server Action — useful for CMS webhooks so pages update immediately when content changes without a full redeploy. In a real React or Next.js app, this matters because it affects rendering behavior, user experience, and performance. A strong answer should show where the code runs, when the UI updates, and what mistake could cause extra renders or broken hydration.

Bhai, think of Next.js Middleware as a proxy layer in front of your app.

Request flow:

Browser Request
      ↓
Middleware
      ↓
Route Matching
      ↓
Page / Layout / Route Handler
      ↓
Response

Middleware runs before Next.js decides which page or API route to execute. It can:

• Redirect

• Rewrite URLs

• Check authentication

• Set headers

• Set cookies

• Block requests

• Continue the request unchanged (Next.js)

Example:

// middleware.ts

import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function middleware(request: NextRequest) {
  const token = request.cookies.get("token");

  if (!token) {
    return NextResponse.redirect(
      new URL("/login", request.url)
    );
  }

  return NextResponse.next();
}

When someone visits:

/dashboard

Next.js does:

Request /dashboard
      ↓
middleware()
      ↓
Has token?
   ├─ Yes → render dashboard
   └─ No  → redirect /login

A very common use case:

export const config = {
  matcher: ["/dashboard/:path*"],
};

Now middleware runs only for dashboard routes. (Next.js)

Another example, URL rewriting:

export function middleware(request: NextRequest) {
  return NextResponse.rewrite(
    new URL("/maintenance", request.url)
  );
}

User visits:

/

but actually receives:

/maintenance

while the browser URL stays /. (Next.js)

One important detail:

Middleware ≠ Express middleware

It is not running inside your React tree. It runs before routing, often at the Edge runtime, acting more like a network proxy in front of your application. (Next.js)

For interviews, the concise answer is:

Next.js Middleware is code that executes before route matching and rendering. It intercepts incoming requests and can redirect, rewrite, modify headers/cookies, perform authentication checks, or return a response before the request reaches a page or route handler. (Next.js)

Server Actions are async functions marked with 'use server' that run on the server when called from a client component — typically from form submissions or event handlers. They replace API routes for simple mutations. They can directly access the database or ORM. Under the hood, they're a POST request to the same URL with a special action ID header. Support progressive enhancement — forms work without JS. In a real React or Next.js app, this matters because it affects rendering behavior, user experience, and performance. A strong answer should show where the code runs, when the UI updates, and what mistake could cause extra renders or broken hydration.
When user submits:

1. Browser submits form
2. POST request sent to Server Action
3. addTodo() runs on server
4. Database updated
5. revalidatePath("/") invalidates cache
6. Next.js re-renders affected Server Components
7. New RSC payload returned
8. React merges payload into existing UI
9. Browser updates DOM

Hydration errors happen when the HTML generated on the server does not match what React renders on the client during the first render. In Next.js, the server sends HTML first, and then React attaches event handlers and makes it interactive in the browser. If the server output and client output are different, React warns about a hydration mismatch. Common causes are using Date.now(), Math.random(), browser-only APIs like window or localStorage, or rendering different content based on client-only state during the initial render. The fix is to make the first render deterministic and move browser-only logic into useEffect or a Client Component where appropriate. This matters because hydration problems can cause broken UI, incorrect content, or components that behave differently in production than in development.

Colocate state when only one component or a small subtree needs it. Lift state up when multiple sibling components need to read or update the same source of truth. Rule of thumb: keep state as close as possible to where it is used, and only move it upward when coordination is necessary. Over-lifting state causes extra re-renders and more complex prop drilling; over-colocating creates duplicated state and synchronization bugs. In a real React or Next.js app, this matters because it affects rendering behavior, user experience, and performance. A strong answer should show where the code runs, when the UI updates, and what mistake could cause extra renders or broken hydration.

Accessible Forms

Labels — always bind to inputs

// Bad
<input type="email" placeholder="Email" />

// Good
<label htmlFor="email">Email</label>
<input id="email" type="email" aria-describedby="email-error" />

Error messages — announce to screen reader

<input
  id="email"
  aria-invalid={!!error}
  aria-describedby="email-error"
/>
{error && (
  <span id="email-error" role="alert">
    {error}
  </span>
)}

role="alert" makes screen reader announce error on inject. No need user focus it.

Fieldsets for grouped inputs

<fieldset>
  <legend>Notification preferences</legend>
  <label><input type="checkbox" name="email" /> Email</label>
  <label><input type="checkbox" name="sms" /> SMS</label>
</fieldset>

Required fields

<input required aria-required="true" />

Both. required triggers browser validation. aria-required tells screen readers.

Accessible Modals

Focus trap — critical

On open: move focus into modal. On close: return focus to trigger.

import { useEffect, useRef } from "react";

function Modal({ isOpen, onClose, children }) {
  const modalRef = useRef(null);
  const triggerRef = useRef(null); // pass from parent

  useEffect(() => {
    if (isOpen) {
      // store trigger, focus first focusable inside modal
      const focusable = modalRef.current?.querySelectorAll(
        'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
      );
      focusable?.[0]?.focus();
    }
  }, [isOpen]);

  // Return focus on close handled by caller restoring triggerRef.current.focus()
}

Use @radix-ui/react-dialog or react-aria — they solve focus trap already. Don't reinvent.

ARIA roles

<div
  role="dialog"
  aria-modal="true"
  aria-labelledby="modal-title"
  aria-describedby="modal-desc"
>
  <h2 id="modal-title">Confirm delete</h2>
  <p id="modal-desc">This action cannot be undone.</p>
</div>

aria-modal="true" hides background content from screen reader virtual cursor.

Escape key

useEffect(() => {
  const handler = (e) => e.key === "Escape" && onClose();
  document.addEventListener("keydown", handler);
  return () => document.removeEventListener("keydown", handler);
}, [onClose]);

Block scroll + background interaction

// Scroll lock
useEffect(() => {
  if (isOpen) document.body.style.overflow = "hidden";
  return () => { document.body.style.overflow = ""; };
}, [isOpen]);

// Backdrop click closes
<div role="presentation" onClick={onClose} /> // backdrop

Quick Checklist

Best path — use proven lib

• Radix UI — headless, full a11y, zero style lock-in

• React Aria — Adobe's lib, WCAG 2.1 AA out of box

• Headless UI — Tailwind team, solid

Build custom only if lib blocked. Focus trap + ARIA attributes hard to get right edge cases.

React Fiber is a re-implementation of the React core algorithm that allows for incremental rendering. It breaks down rendering work into smaller units and prioritizes them based on their importance. This way, it can pause and resume work as needed, which improves performance and responsiveness, especially for complex applications.

• useState is simpler and good for basic state management.
• useReducer is more powerful and better for complex state logic or when the next state depends on the previous one.