Next.js is the most popular React framework for production apps. These Next.js interview questions cover routing, pages and rendering basics for freshers, then the App Router, Server Components, data fetching and caching, Server Actions, middleware, SEO and deployment for experienced Next.js developers.
30 questions · Updated
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
Next.js is a React framework that adds file-based routing, server-side rendering, static generation, API routes, image and font optimisation, and production build tooling.
Plain React (for example with Vite) renders in the browser only.
Next.js gives faster first loads, better SEO and a full-stack structure without configuring these pieces yourself.
The Pages Router uses the pages folder, with getServerSideProps, getStaticProps and getStaticPaths for data.
The App Router, introduced in Next.js 13, uses the app folder with nested layouts, React Server Components by default, streaming with loading.js, and data fetched directly in async components.
The App Router is recommended for new projects.
Folders define routes and a page.js file makes the route public, so app/blog/page.js serves /blog. Dynamic segments use brackets, such as app/blog/[slug]/page.js. layout.js wraps child routes and keeps state across navigation, loading.js shows a loading state, error.js handles errors, and route groups in parentheses organise files without affecting the URL.
Run npx create-next-app@latest and choose TypeScript, ESLint, Tailwind and the App Router. The app folder holds routes, with layout.js and page.js files; public holds static files served from the root; next.config.js holds configuration; and components and lib folders are common conventions. npm run dev starts the development server.
next/link's Link component navigates between pages on the client without a full page reload, keeping layouts and state.
In production it automatically prefetches the code and data for links visible in the viewport, so navigation feels instant.
Use it for internal links and a normal <a> tag for external sites.
A layout.js wraps a route segment and its children, and stays mounted when navigating between child pages, so state and shared UI such as navigation persist.
The root layout must contain the html and body tags.
A template.js is similar but creates a new instance on every navigation, which suits enter animations or resetting state.
loading.js shows an instant loading UI for a route segment while its content loads, using React Suspense, so users see feedback immediately. error.js is a client component that catches errors in that segment and shows a fallback with a reset button, without breaking the rest of the page. not-found.js handles 404 states, and global-error.js handles errors in the root layout.
A folder in square brackets, such as app/blog/[slug]/page.js, matches any value, which the page receives through params. [...slug] catches all remaining segments. generateStaticParams returns the list of params to pre-render at build time, so those pages are static; setting dynamicParams = false returns 404 for any other value.
Variables in .env files are loaded automatically, with .env.local for secrets that are not committed.
By default they are only available on the server.
Only variables prefixed with NEXT_PUBLIC_ are included in the browser bundle, so secrets such as API keys must never use that prefix.
Variables are set per environment in the hosting dashboard.
Files in the public folder are served from the site root, so public/logo.png is available at /logo.png. Special files such as favicon.ico, icon.png and robots.txt can go in the app folder. next/font downloads Google or local fonts at build time and self-hosts them, with no layout shift and no requests to Google from the browser.
Route handlers are API endpoints in the App Router, defined in a route.js file that exports functions named after HTTP methods, such as GET and POST, using the standard Request and Response objects.
They are used for webhooks, APIs for mobile apps and third parties, and generated files such as RSS feeds.
For mutations from your own forms, Server Actions are often simpler.
Applied problems, trade-offs and questions about your own projects.
In the App Router, components are Server Components by default: they render on the server, can fetch data and access secrets directly, and send no JavaScript to the browser.
Adding "use client" at the top of a file makes it a Client Component, needed for state, effects, event handlers and browser APIs.
The best practice is to keep client components small and at the leaves of the tree.
Server-side rendering builds the HTML on each request, which suits personalised or frequently changing pages.
Static site generation builds pages at build time and serves them from a CDN, which is fastest.
Incremental static regeneration rebuilds static pages in the background after a set time or on demand with revalidatePath or revalidateTag, combining static speed with fresh data.
The Image component automatically resizes images to the right size for each device, serves modern formats such as WebP or AVIF, lazy-loads images below the fold, and requires dimensions or fill to prevent layout shift. The priority prop preloads the main hero image to improve Largest Contentful Paint.
In the App Router I export a metadata object or generateMetadata function from pages and layouts to set titles, descriptions, canonical URLs and Open Graph tags. sitemap.js and robots.js generate those files, opengraph-image can generate share images, and JSON-LD structured data is added with a script tag. Server rendering means crawlers get full HTML.
Server Components can be async and fetch data directly with fetch or a database client, without useEffect or an API layer.
Independent requests should start together with Promise.all to avoid waterfalls, while dependent requests run in order.
Wrapping slower parts in Suspense lets the rest of the page show first.
Sensitive code can be protected with the server-only package.
Streaming sends the page to the browser in chunks as they become ready instead of waiting for all data.
The layout and fast parts appear immediately, and slower sections wrapped in Suspense (or covered by loading.js) show a fallback and then stream in.
This improves time to first byte and how fast the page feels, especially with slow APIs.
Parallel routes, created with named slots such as @analytics, render several pages in the same layout at once, each with its own loading and error states, which suits dashboards. Intercepting routes, using conventions like (.)photo/[id], show a route inside the current layout, for example opening a photo in a modal from a feed, while a direct visit to the URL shows the full page.
Permanent redirects for moved pages can be listed in next.config.js under redirects, or done in code with redirect() and permanentRedirect() from next/navigation in Server Components and Server Actions.
Rewrites map a URL to a different path without changing what the user sees, for example proxying /api to another server.
Middleware (proxy) can redirect conditionally, such as by locale.
Use a library such as Auth.js (NextAuth), Clerk or Supabase Auth, or your own sessions in HttpOnly cookies.
Check the session on the server in layouts, pages, Server Actions and route handlers, because middleware alone is not enough for security.
Middleware can redirect unauthenticated users early for a better experience.
Keep authorisation checks next to the data access.
next/navigation provides hooks for client components: useRouter for navigating programmatically (push, replace, refresh, back), usePathname for the current path, useSearchParams for query string values, and useParams for dynamic route parameters. Server Component pages receive params and searchParams as props instead.
The Node.js runtime has full access to Node APIs and npm packages and is the default.
The Edge runtime runs on lightweight servers close to users with very fast start-up, but supports only a subset of APIs, so many Node libraries and database drivers do not work.
Edge suits simple, latency-sensitive logic; most pages and APIs should use Node.js.
System design, deep internals, leadership and tough follow-ups.
Next.js has several layers: request memoisation removes duplicate fetches during one render, the data cache stores fetch results across requests, the full route cache stores rendered static routes, and the router cache stores visited routes in the browser.
Next.js 15 changed fetch and GET route handlers to be uncached by default.
You opt in with cache options, revalidate settings or the "use cache" directive, and invalidate with revalidatePath and revalidateTag.
Server Actions are async functions marked with "use server" that run on the server but can be called directly from forms and client components, for example <form action={createPost}>.
They remove the need to write separate API routes for mutations, work with progressive enhancement, and can revalidate cached data after a change.
Inputs must still be validated and the user authorised, because they are public endpoints.
Middleware (middleware.js at the project root, renamed proxy.js in Next.js 16) runs before a request is completed.
It can rewrite, redirect or modify headers based on the request, which suits authentication checks, refreshing sessions, redirects by locale or geography, A/B testing and bot protection.
It should stay fast and light, using a matcher to run only on routes that need it.
Partial Prerendering combines static and dynamic rendering in one route.
The static shell of the page is served instantly from the edge like a static site, while dynamic parts wrapped in Suspense, such as a personalised cart, are streamed in the same response.
In Next.js 16 this is part of Cache Components, where you mark cacheable parts with "use cache".
Vercel supports every feature with no configuration. Next.js can also be self-hosted as a Node.js server with next start, packaged as a small Docker image using output: "standalone", deployed to other platforms such as Netlify, AWS Amplify or Cloudflare through adapters, or exported as a fully static site with output: "export" if it uses no server features.
Keep most components as Server Components so less JavaScript ships, push "use client" down to small interactive leaves, use next/image and next/font, lazy-load heavy client components with next/dynamic, avoid data waterfalls, cache data where it is safe, and stream slow sections. I check bundles with @next/bundle-analyzer and measure Core Web Vitals from real users.
Keep secrets in environment variables without the NEXT_PUBLIC_ prefix, import the server-only package in modules that must never reach the browser, and be careful what props you pass from Server to Client Components, since they are sent to the browser. Treat Server Actions as public endpoints: validate input, check authentication and authorisation in every action, and use a data access layer.
Both routers can run in the same app, so migration can be gradual, route by route.
Move _app and _document into the root layout, convert getServerSideProps and getStaticProps into data fetching inside async Server Components, replace getStaticPaths with generateStaticParams, swap next/router for next/navigation hooks, and add "use client" to components that use state or browser APIs.
Test each route as you move it.
See all Frontend Developer interview questions, covering HTML, CSS, JavaScript, TypeScript, React and more.