Analytics for Next.js

Next.js creates two specific problems for analytics and solves neither of them for you. Client-side navigation means route changes do not fire a page load, so a script that only counts loads will record one pageview for an entire session. And the App Router's server components change where a tracking script can legally live.

Both are solvable in a few lines. The bigger decision is whether to use the analytics that ships with your host, and that one has consequences you will feel in two years rather than two weeks.

The client-side routing problem

A traditional analytics script fires on page load. In a Next.js app, the first navigation is a load and every subsequent one is not: the router swaps the view without the browser navigating, so the script never runs again.

Well-built modern analytics tools handle this themselves by listening for History API changes, and any tool advertising SPA support is doing exactly that. Verify it rather than assuming: open your site, navigate three times without reloading, and check the realtime view shows three pageviews rather than one. This takes ninety seconds and catches a mistake that otherwise silently halves every engagement metric you have.

If a tool needs manual help, the pattern is a small client component that calls the tracking function on pathname change, mounted once in the root layout.

Where the script goes in App Router

Put the tag in `app/layout.tsx` using `next/script` with `strategy="afterInteractive"`, which loads it after hydration without blocking the first paint. For a script small enough not to matter, `beforeInteractive` is also defensible, but with a one-kilobyte tag the difference is not measurable.

The root layout is a server component, and that is fine: you are rendering a script tag, not running client code. You only need a client component if the tool requires you to call a function on route change, in which case keep that component as small as possible and mount it once.

In the Pages Router, the equivalent is `_document.tsx` for the tag itself, or `_app.tsx` if you need `router.events` for route changes.

Script weight matters more here than elsewhere

Next.js sites are usually built by people who care about Core Web Vitals, and who have spent real effort on bundle size, image optimisation and font loading. Dropping a forty-kilobyte analytics tag into that is an odd way to spend the budget.

The spread across this market is wide. The lightest tools are around one to three kilobytes. Google Analytics through Tag Manager, PostHog, Mixpanel and the session replay tools are tens of kilobytes, sometimes more once their runtime fetches are counted. On a content site funded by search traffic, that is a measurable cost paid by every visitor on every page, in exchange for reports nobody opens.

If you have optimised anything else on the page, optimise this too.

The platform-native option and what it costs

If you deploy to Vercel, Vercel Web Analytics is the path of least resistance: install the package, add the component, deploy. Nothing on this list is faster to set up, and deployment attribution, seeing what a release did to your numbers, is genuinely useful for a team shipping several times a day. Speed Insights alongside it gives you real Core Web Vitals from your users.

The cost is portability, and it is a real one for a measurement system. The analytics are tied to the hosting, retention is tied to the plan, export is limited, and if you leave Vercel you leave your history behind. Analytics is supposed to give you a long baseline, and a baseline that resets when you change host is not one.

It is also shallow: custom events exist on paid plans, but there are no funnels, no meaningful segmentation and no behaviour tooling. Treat it as a convenience layer for shipping teams rather than the analytics the business runs on.

The rest of the field

Common questions

Related guides