The cookieless floor: Vercel Analytics and Speed Insights
Ship Vercel Web Analytics and Speed Insights as the cookieless, no-consent-needed baseline that answers your traffic and real-user performance questions before you reach for a product-analytics platform.
The product is live. You followed the deployment chapter, pushed to Vercel, and both the marketing site and the app are serving real traffic right now. That is the moment this lesson is about. Nothing is broken, but three questions have just come due, and you can’t answer any of them yet.
How much traffic is the app getting, and where is it coming from? Which pages turn visitors into sign-ups, and which ones quietly lose them? And is the experience fast enough that Google’s search ranking and your own conversion rate aren’t being punished for it? You don’t need an event schema to answer these, and you don’t need to decide on a product-analytics platform. You need two installs, @vercel/analytics and @vercel/speed-insights, and two lines of JSX in a file you already have. By the end of this lesson all three questions are answered in a dashboard, with no event code written.
You already have everything this builds on: a Next.js App Router app deployed on Vercel, an app/layout.tsx at the root, and the consent gate you built in the security chapter, the one that holds non-essential tracking behind an explicit yes. That consent gate matters here, but not in the way your instinct expects. Hold onto that thought, because correcting that instinct is the most important thing this lesson does, and we’ll get to it deliberately.
Three questions, one floor
Section titled “Three questions, one floor”Let’s name those three questions properly. They aren’t one-time curiosities; they are the recurring questions every team running a SaaS asks from the first day of production onward.
- Traffic. How many people, and from where? Raw volume and referrers tell you whether your launch tweet did anything and whether that one blog post is actually sending humans.
- Behavior, lightly. Which pages do people land on, and which do they leave from? You don’t need a funnel yet to notice that the pricing page gets traffic but the sign-up that should follow it doesn’t.
- Performance. Is the page fast for real users on real devices? Not “fast on your laptop” but fast on a mid-range phone over hotel wifi, which is what Google scores you on.
Two installs answer all three. That’s the floor: the analytics layer that is correct to ship before you’ve decided anything else, because it costs you nothing to have and answers questions you have today.
Here’s the shape of the whole chapter in one picture. A SaaS analytics stack has two tiers, and this lesson ships the bottom one.
The bottom tier, the cookieless floor, is what you ship today on every Vercel project, no conditions. The top tier is PostHog , and unlike the floor it has a trigger. You add it only when a specific kind of question shows up, and there are exactly five of them. You cross the threshold the moment you need to know:
- Who. A specific identified user, not an anonymous visitor.
- What they did. An event with properties (
plan: 'pro',seats: 12), not just a page view. - Across sessions. A funnel that stitches a sign-up today to a paid invoice next week.
- Gated by a flag. Rolling a new feature out to 10% of orgs first.
- In replay. Watching the actual session where a user rage-clicked and left.
Until at least one of those is a real, present need, the floor is your entire analytics stack. We’ll come back to this list at the end of the lesson as the closing decision, and the next lesson treats it in full. For now, just notice that none of these five is “how much traffic do I get.” That’s the floor’s job, and the floor does it for free.
Why cookieless is the default, not the conditional path
Section titled “Why cookieless is the default, not the conditional path”Most tools in this course are conditional. You reach for them when a threshold is crossed, and a big part of each lesson is teaching you not to reach for them too early. This one is the inverse. Vercel Web Analytics is something you ship by reflex on every project, the way you’d add a favicon. It’s worth understanding exactly why, because the same reasons are what make it safe to stop here.
The biggest reason is one word: cookieless. Vercel Web Analytics sets no cookies and does no fingerprinting . The data is aggregated and anonymized the instant it’s collected. That property pays off directly on your marketing site: your consent banner doesn’t block it, so you keep the traffic data from every visitor, including the large majority who close the banner without ever clicking accept. We’ll unpack the legal shape of this in its own section, since it’s the lesson’s key correction. For now, hold the headline: cookieless is why this can run for everyone, and running for everyone is most of its value.
The second reason is cost. Vercel Web Analytics is free on every plan, including Hobby. There’s no separate contract and no per-event invoice landing at the end of the month. There is a monthly cap on captured events, and it’s worth being honest about it: on Hobby, collection pauses when you hit the cap rather than billing you for the overflow, and raising the cap means upgrading to Pro. For a pre-product-market-fit app that cap is generous, so in practice it’s free. Even the cost that exists is a volume cost, not an engineering one. There’s no event taxonomy to design and budget for. The price of the floor, in both money and effort, is close to zero.
That zero-effort point is what makes the floor durable, so it’s worth stating on its own. The whole install is two <script> injections through two official packages. The data model is fixed (page views, referrers, geography, device), so there is no schema to design, no schema to keep aligned across your codebase, and nothing to rot six months from now when someone renames a thing and forgets the analytics call.
Contrast that with the top tier. PostHog is genuinely powerful, but everything it gives you is weight: an SDK in your bundle, an event schema your team has to govern, a consent gate to route every call through, and a quota to watch so a stray capture() in a render loop doesn’t burn your month. None of that is wrong; it’s the right cost to pay when a real need shows up. But it is a cost, and the floor has none of it.
What Vercel Web Analytics gives you
Section titled “What Vercel Web Analytics gives you”So what exactly do those two scripts buy you? Web Analytics gives you a focused set of traffic metrics:
- Page views and unique visitors, your volume.
- Top pages and top referrers, what’s getting attention and what’s sending it.
- Country, OS, browser, and device class, the shape of your audience.
Every one of those is computed from data that’s aggregated and anonymized at the point of ingest. No personal data leaves the visitor’s device, which is the mechanism underneath the cookieless guarantee rather than a separate feature. The script is also built to be resilient: the current @vercel/analytics package discovers its ingest endpoints instead of hard-coding one, which is how it survives the URL patterns ad-blockers reach for. You don’t need to configure any of that. It’s just why your numbers hold up better than a naive analytics tag’s would.
Here’s the overview panel you’ll be watching once it’s live and verified:
There’s one boundary to draw clearly so you don’t push this tool past what it’s for. Web Analytics does support custom events, but treat them as out of scope, for two reasons. First, the data model around them is shallow: no funnels, no cohorts, no cross-session identity. Second, custom events are a Pro and Enterprise feature, not available on the free Hobby tier at all. So the moment you find yourself wanting to fire a custom event, that’s not a signal to upgrade your Vercel plan; it’s the threshold to the top tier. Don’t bend Web Analytics’ custom events into a product-analytics layer. The right reach is PostHog, and that’s the next lesson.
What Speed Insights gives you
Section titled “What Speed Insights gives you”The second install, @vercel/speed-insights, answers the third question: is the page actually fast for real people? It does that by sampling Core Web Vitals from your live production traffic.
You’ll see these metric names on the dashboard, so meet them now as vocabulary. We are not defining them here; the performance chapter coming later owns their precise definitions, thresholds, and how to fix each one. For now: LCP , INP , CLS , TTFB, and FCP.
The one idea worth holding from this lesson is the distinction between two kinds of performance data. Lab data comes from a synthetic test: one run, one machine, controlled conditions. Field data comes from your actual users on their actual devices and networks, and Speed Insights is field data. That distinction is not academic: field data, scored at the 75th percentile, is what Google uses to rank you in Search. A perfect lab score means little if real users on real phones are having a slow time. Speed Insights shows you the data that actually affects your ranking.
This lesson ships the wire. The performance chapter later takes this exact dashboard as its starting input, so when you get there you won’t be installing anything new; you’ll be reading the data you turned on today. Think of the two lessons as one continuous thread: turn on the sensor now, learn to act on it later.
Installing the floor
Section titled “Installing the floor”Now the hands-on part, and it’s short: two packages, two components, one dashboard toggle, one verification.
-
Install both packages with pnpm.
Terminal window pnpm add @vercel/analytics @vercel/speed-insights -
Add both components to your root layout, inside
<body>, after{children}. This is the only code in the lesson, and it’s walked through below. -
Enable Web Analytics and Speed Insights in the Vercel project dashboard, per environment. This is a separate step, and it’s the one people forget. The package ships the script either way, but until you flip this toggle in the dashboard, the script runs and the data goes nowhere: no error, no warning, just an empty dashboard. Turn it on at the same time you ship the code.
-
Verify in production. Load a page on your live site and watch the dashboard. Give it time, because there’s a first-load latency of roughly thirty seconds to a minute before the first data shows up, so an empty panel for the first minute is expected, not a bug. Once a view lands, you’re done.
The code in step two is the whole thing: two imports and two self-closing components in your root layout.
import { Analytics } from '@vercel/analytics/next';import { SpeedInsights } from '@vercel/speed-insights/next';
export default function RootLayout({ children }: { children: React.ReactNode }) { return ( <html lang="en"> <body> {children} <Analytics /> <SpeedInsights /> </body> </html> );}Both imports come from the Next.js-specific subpath of each package, the entry points built for the App Router. One import per capability, nothing more.
import { Analytics } from '@vercel/analytics/next';import { SpeedInsights } from '@vercel/speed-insights/next';
export default function RootLayout({ children }: { children: React.ReactNode }) { return ( <html lang="en"> <body> {children} <Analytics /> <SpeedInsights /> </body> </html> );}This is your existing root layout, and it stays a server component. You’re not adding 'use client' and you’re not wrapping it in a provider, because each component handles its own client behavior internally.
import { Analytics } from '@vercel/analytics/next';import { SpeedInsights } from '@vercel/speed-insights/next';
export default function RootLayout({ children }: { children: React.ReactNode }) { return ( <html lang="en"> <body> {children} <Analytics /> <SpeedInsights /> </body> </html> );}Drop both in once, at the root, after {children}. Because every route renders inside the root layout, this single placement covers your entire app automatically, every page. There is nothing to add per route.
Why these two skip the consent gate
Section titled “Why these two skip the consent gate”Here is the correction I promised at the start. You just spent a whole lesson in the security chapter learning that nothing non-essential fires before the user consents: every tracker routes through your useConsent() source of truth and stays dark until the user explicitly accepts. That lesson did its job a little too well. Having just installed two analytics tools, the natural next move is to wrap <Analytics /> and <SpeedInsights /> in that same gate. Do not do that.
The reason these two are different comes straight back to the property we opened with. The consent gate exists to protect the user’s personal data. Vercel Web Analytics and Speed Insights collect none of it: no cookies, no fingerprinting, everything aggregated and anonymized at ingest. Under most jurisdictions that puts them in the “essential” or “legitimate interest” category for traffic analytics, which is exactly the category that does not require consent. So they sit outside the gate, by design. The cookieless guarantee isn’t just a nice-to-have; it’s the entire reason these tools are allowed to run before anyone clicks accept.
Now picture what happens if you gate them anyway. On a marketing page, most visitors never click accept: they read what they came for and leave, or they dismiss the banner. If <Analytics /> is behind the gate, every one of those visitors is invisible to you. You’ve thrown away the bulk of your traffic data, the exact data you installed this for, and gained no extra compliance benefit, because the tool didn’t need consent in the first place. It’s a pure loss. Gate by what the tool collects, never by reflex.
To be clear, the rule isn’t “analytics never needs consent.” It’s “gate by what’s collected.” PostHog, the top tier, does handle personal data: distinct user IDs, IP addresses, event properties that carry user state. PostHog absolutely routes through the consent gate, and a later lesson in this chapter wires exactly that. Naming both halves is what makes the principle stick: the floor skips the gate because it’s cookieless, and PostHog goes through it because it isn’t.
One honest caveat, then we move on: “most jurisdictions” is doing real work in that sentence. A few stricter regimes draw the line differently, and the final call on what your specific product needs is your legal team’s, not your framework’s. The engineering default in 2026 is to leave these two cookieless tools ungated, but it’s a default, not a guarantee.
Let’s check that both boundaries landed. The capability boundary (what the floor can answer) and the consent boundary (what skips the gate) are the two load-bearing ideas of this lesson. Sort each concern into where it belongs.
Sort each analytics concern into where it belongs. Drag each item into the bucket it belongs to, then press Check.
Where to enable it: production, preview, dev
Section titled “Where to enable it: production, preview, dev”The dashboard toggle from the install is per-environment, which turns “is this on?” into a small but real decision across your three environments. The defaults are easy:
- Production: on. This is where real traffic lives and where the data matters. Always on.
- Preview deployments: opt in. Turn it on for a preview URL when you specifically want to QA against real traffic on that deploy. Otherwise leave it off, so your QA clicks don’t muddy production-shaped data.
- Development: off. Your local clicking around is noise, not signal. There’s nothing useful to capture from
localhost.
One dependency under all of this is worth stating plainly, because it’s a silent failure waiting to happen. @vercel/analytics needs Vercel’s edge network to ingest its data. The course’s stack is Vercel-hosted, so this is the happy default. But if you ever ship this package on a static export hosted somewhere else, the script will load, run, and catch nothing, because there’s no edge endpoint to send to. It looks installed and collects nothing.
When to reach past the floor
Section titled “When to reach past the floor”You’ve shipped the floor. The last thing to take away isn’t an install; it’s knowing when to add the next tier, so you reach for it on purpose rather than out of anxiety.
Here are those five threshold signals again, now as your closing checklist. Each one names a question the floor structurally cannot answer, which is what makes the line real rather than arbitrary:
- Who. The floor has no identity. It counts anonymous visitors; it can’t tell you what this signed-in user did.
- What they did. The floor has no event schema. It records page views, not “clicked upgrade” with
plan: 'pro'attached. - Across sessions. The floor doesn’t stitch sessions. It can’t follow one person from sign-up today to first paid invoice next week.
- Gated by a flag. The floor has no flags. It can’t roll a feature out to 10% of orgs or kill-switch a broken one.
- In replay. The floor has no replay. It can’t show you the actual session behind a bug that never threw an error.
If none of those are real for your product right now, you are done. Stay on the floor. The moment one of them becomes a genuine, present need, that’s your signal, and the next lesson lands exactly that decision.
A quick word on the tool you might expect to see here and won’t: Google Analytics 4. It was the historical default for a decade, and this course doesn’t reach for it. Its data model of sessions, hits, and audiences is an awkward fit for product analytics, its consent-banner UX is heavier than what we just built, and its export shape is rigid. The 2026 SaaS split is clean: Vercel for traffic, PostHog for product analytics. GA4 stays a marketing-team conversation, not an engineering one. We name it once, here, so you can recognize it and move past it.
That’s the handoff. The next lesson lands the PostHog decision in full: the moment it earns its weight, and the one-platform, four-primitives play that makes it the right reach when the threshold finally arrives.
A pre-PMF marketing site with one pricing page wants to know how many visitors it gets and which posts drive sign-ups. What’s the right analytics stack?
External resources
Section titled “External resources”The install is short, so the official quickstarts cover the wiring. Two deeper references back the two load-bearing ideas: why these tools skip the consent gate, and what the Speed Insights metrics actually mean.