One Google Analytics tag, pasted into the <head> the way the setup guide says, cost a plain article page 10 Lighthouse points and 424 ms of blocking time on mobile. I measured it, five runs each. The numbers are below.

I went looking because of an evening spent running Lighthouse on sites I like. Plenty of them scored badly on mobile, and the reports kept pointing at the same thing. Not their code. Their tracking. On most of them the tag scripts alone came to roughly 600 KB, give or take: the Meta Pixel, GA4, Microsoft Clarity and a handful of bot-detection scripts, all of it loaded and run before anything else got a turn.

I won't name them. I don't own them, and I don't know what their teams are up against. But I made the same mistake on my own site, so that one's fair game.

Nobody owns the cost

Here's how it usually goes. An agency or the SEO team sends over a Google Tag Manager snippet. The developer pastes it into the <head>, because that's what the instructions say. Then, over a year or so, tags pile up inside the container: GA4, an ads pixel, a heatmap, a chat widget. Each one made sense to someone when it went in.

Two things kept showing up.

Universal Analytics, still loading in 2026. Google stopped processing its data in July 2023. Nobody told the developer it could go, so it didn't.

And GA4, twice. Once as a tag inside GTM, once as a snippet someone handed the developer to paste into the code. Two downloads of the same script, two hits for every visit.

Neither of those is a coding mistake. Marketing owns the tags, the developer owns the page, and what the tags cost the page falls in the gap between them.

My own site did it too

When I measured my site on Lighthouse's mobile profile, gtag.js was about 176 KB and ran for over a second right after the page hydrated. Over a second where a tap on a button just sat there, on every visit, so I could count the visit.

I moved it to load later (code further down). That change shipped alongside a pile of other startup fixes, though, so I can't pull a clean GA-only before and after out of it. So I built a test page.

The test

A plain article page with no JavaScript of its own, in three versions: no analytics, GA4's standard snippet in the <head>, and GA4 deferred with the snippet I'll show you further down. Lighthouse 13.6, mobile profile, five runs of each, alternating between versions.

I used a placeholder measurement ID. A real one ships your property's configuration inside the file: for my real ID it's 545 KB unzipped, against 446 KB for the placeholder. So if anything, these numbers flatter GA.

With no analytics, the page scored 100 with 0 ms of blocking time, every run. The deferred version did exactly the same: 100 and 0 ms, every run.

The standard snippet scored between 88 and 91, median 90. Blocking time ran from 391 to 469 ms, median 424. gtag.js came over the wire at 157 KB (446 KB unzipped) and ran for about 540 ms on Lighthouse's simulated phone.

Ten points. From one tag, on a page that otherwise blocks for nothing at all.

That deferred 0 ms needs a footnote. The script didn't get faster. It still runs, four seconds after load or on the first scroll or tap, and by then Lighthouse has stopped measuring. Same work, moved out of the moment the page is loading and someone is trying to use it. I also checked nothing got lost: the page view arrived, and an event I fired before GA had even loaded went out with the next batch once it did.

"But the snippet is async"

It is. That fixes half the problem.

async means the browser keeps reading your HTML while the script downloads. It says nothing about what happens once the script runs, and it runs on the main thread, the same thread that handles taps, clicks and typing. Then GTM loads every tag in the container, and those run on the main thread too.

Lighthouse calls this Total Blocking Time: every task over 50 ms between first paint and the page being reliably interactive counts against you. It carries 30% of the performance score, more than any other metric.

A small correction to how this usually gets told: TBT isn't a Core Web Vital. It's a lab number. The Core Web Vitals Google measures on real visitors are LCP, CLS and INP, and INP (how fast the page responds to input) is the one tags hurt, for the same reason. A tap that lands while the main thread is busy with tags waits. Bad TBT in the lab tends to show up later as bad INP in Search Console.

Measure first

Before you change anything, get two numbers: how slow the page is, and how much of that is tags.

1. Run Lighthouse in Chrome DevTools on the mobile profile and open Reduce the impact of third-party code. It lists each third party with its transfer size and how long it held the main thread.
2. In the Network panel, right-click a googletagmanager.com request and choose Block request domain. Do the same for the other tag domains, then run Lighthouse again.
3. Run each version at least five times. Scores swing by several points between runs of the same page, so one run of each tells you nothing.

The gap is what your tags cost. "The developer wants to remove tracking" goes nowhere in a meeting. "Our tags cost us X points on mobile" gets an answer.

Clean out the container

This is the cheapest fix there is, and usually the biggest. Sit down with whoever owns marketing and go through the container one tag at a time.

Start with Universal Analytics. It sends data nowhere now, so delete it, along with tags for campaigns that ended and pixels for tools nobody pays for anymore. Then look for GA4 twice: search the codebase for gtag/js and check the container for a GA4 tag with the same measurement ID. Keep one. I'd keep the GTM one, but either works, as long as it's one.

Next, triggers. A chat widget or booking tool that matters on two pages has no business firing on "All Pages". And go easy on session recorders and heatmaps. They watch everything on the page, which makes them some of the heaviest scripts you can add. Sample them, or run them for a few weeks while you're actually researching something, then switch them off.

Every tag that survives gets an owner and a reason. A tag with no owner never gets removed.

Load what's left later

Analytics needs to know the visit happened. It doesn't need to know in the first 500 ms.

On my site, GA loads on the visitor's first interaction (a tap, a key press, a scroll) or a few seconds after the page finishes loading, whichever comes first. The timer is for people who read without touching anything. They still count.

Here's the plain HTML version. It works on any site:

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag() { dataLayer.push(arguments); }
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');

  let loaded = false;
  function loadAnalytics() {
    if (loaded) return;
    loaded = true;
    const s = document.createElement('script');
    s.async = true;
    s.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX';
    document.head.appendChild(s);
  }

  ['pointerdown', 'keydown', 'scroll', 'touchstart'].forEach((type) =>
    addEventListener(type, loadAnalytics, { once: true, passive: true })
  );
  addEventListener('load', () => setTimeout(loadAnalytics, 4000));
</script>

The inline part is safe to run early. gtag() only pushes onto the dataLayer array, and the real script works through that queue when it arrives, so events sent before it loads wait instead of disappearing. For GTM, swap the src for your gtm.js URL and keep the dataLayer setup.

It isn't free. Someone who lands and leaves within those few seconds without touching the page won't be counted. On most sites that's a thin slice of bounces, but agree on it with marketing before you ship, not after they spot the dip. And when a tap is what loads GA, the script runs right after that tap, so the next tap can feel slower. Still far better than running it during page load, and it's why the container clean-out matters even when you defer.

On Next.js, @next/third-parties ships GoogleAnalytics and GoogleTagManager components that load after hydration, which already beats a raw tag in the head, and next/script with strategy="lazyOnload" waits for the browser to go idle. I went a step further and only mount the GA component after the first interaction or the timer, because even after hydration it was one long task on a phone.

If it's still heavy

There are two bigger options, both with strings attached.

Partytown moves third-party scripts into a web worker, off the main thread. Some tags are happy there. Others break, especially ones that need to touch the page synchronously, so test every tag. On Next.js, the worker script strategy that uses it is still experimental and doesn't work in the App Router.

Server-side GTM has the browser send one stream of events to a server you run, which forwards them to GA4, the ad platforms and the rest. One script in the visitor's browser instead of one per vendor. You pay to host it and someone has to look after it, so it earns its keep once you have several vendors, not for a single GA4 tag.

Keeping it fixed

All of this rots the first time someone adds a tag without checking. Agree on a budget with marketing, something like "tags get at most 50 ms of blocking time on mobile", and check it whenever the container changes. Watch the Core Web Vitals report in Search Console too: Lighthouse is one simulated phone, Search Console is your actual visitors. If INP slips from green to orange after a release, open the container's version history before you start blaming your own code.

The official upgrade guide is good and the codemod does most of the typing. What the guide cannot tell you is which of its changes will hit your particular stack. Two problems broke this site's production build in ways a dev server never showed. This is what broke, why, and what I would check before you upgrade yours.

Turbopack builds your app differently

The headline change is that next build uses Turbopack by default. Development already did; now production does too. For most code that is invisible. For code that relies on two routes sharing the same instance of a module, it is not.

After the upgrade, the production build served every public page fine, and admin sign-in failed with this:

No metadata for "Admin" was found

The cause is how the database connection and the bundles meet. The TypeORM DataSource is created once and shared through globalThis, so whichever route connects first registers its entity classes. Turbopack gives each route its own copy of those classes. In production the first request is usually a public page, so the connection held the public page's Admin class, and the auth route asked for a repository with its own, different Admin class. TypeORM compares classes by identity, so as far as it was concerned that entity had never been registered.

webpack, the builder Next.js 15 used for production, shared one module instance across routes, which is why the same code had worked for months.

The fix is one line per lookup: ask for the repository by name instead of by class.

// Breaks when the route that connected first holds a different copy of the class
const admins = ds.getRepository(Admin);

// Works from any route: TypeORM matches the entity by its name
const admins = ds.getRepository<Admin>('Admin');

The public loaders had already been switched to name lookups months earlier, after the same error showed up in development. The auth route was the one place still passing a class, and nothing exercised it until the production build did.

The lesson is broader than TypeORM. If anything in your app keeps state in a module-level singleton and compares classes or object identity across routes, test it on the production build. next dev will not show you this.

The Docker image lost its database driver

This one was not strictly Next.js. It came from upgrading TypeORM to 1.x in the same round, and it only surfaced because of how Next.js packages a standalone build. The two together are worth knowing about.

The site ships as output: 'standalone'. Next.js traces which files the server actually imports and copies only those into .next/standalone, which keeps the Docker image small. TypeORM 1.x loads its database driver with a dynamic require(name). Output tracing cannot follow a require whose argument is a variable, so the trace quietly left pg out. Every page that touched the database threw DriverPackageNotInstalledError.

The fix is to import the driver yourself and hand it over, which puts it back in the trace:

import pg from 'pg';

new DataSource({
  type: 'postgres',
  driver: pg,
  // ...
});

It never reached visitors, because CI builds the Docker image and runs a smoke test against it before anything deploys. It had already earned its place once, after an earlier standalone surprise: images uploaded at runtime into public/ were not served, and the test grew a check for that too. If your deploy is a standalone build and your CI does not boot it, I would add that before upgrading anything.

Middleware is now called proxy

middleware.ts is deprecated in favour of proxy.ts, and the exported function is renamed to match. The codemod does the rename. One difference matters if you relied on the Edge runtime: proxy always runs on Node.js, and the guide says to keep middleware for now if you need Edge. The behaviour this site relies on, guarding /admin before a request reaches the page, works the same.

The name is more honest about what the file does: it sits in front of your routes and decides what to do with a request.

I still check the session again inside every admin page and server action. A guard in front of the routes is a convenience, not the only lock on the door.

next lint is gone

next lint was removed. You run the ESLint CLI directly, with a flat config. The codemod writes one for you; this site's is core web vitals, TypeScript and Prettier in eslint.config.mjs, and npm run lint calls ESLint itself.

The practical difference is that ESLint now lints whatever its config says, not what Next.js decided to point it at. The first run after the switch walked into tool folders that had never been linted before, and they needed adding to the ignores.

The small breaking changes

Most of the remaining changes are mechanical, and the codemod handles them:

• params, searchParams, cookies() and headers() are async. Await them.
• revalidateTag takes a second argument, a cache profile such as 'max'. The single-argument form is deprecated and fails type checking.
• The minimum Node.js is 20.9, and the supported browsers start at Safari 16.4 and Chrome 111.
• If you have a custom webpack config, next build fails on purpose rather than silently ignoring it. You either migrate it or build with --webpack.

None of these are hard. They are just noisy, which is a good reason to land the upgrade on its own and not inside a feature branch.

The React Compiler is stable, and still a choice

Next.js 16 made built-in support for the React Compiler stable, after the compiler's own 1.0 release. It memoizes components for you, so most hand-written useMemo and useCallback calls become unnecessary.

It is off on this site for now. If you turn it on, two things are worth knowing first. The upgrade guide warns that builds and dev compiles get slower, because the compiler runs through Babel. And eslint-plugin-react-hooks 7 ships rules that only make sense with the compiler on; this site has those three switched off, to be switched back on the day the compiler is.

What I would check before you upgrade

If you are still on Next.js 15, this is the short list I would work through:

1. Test the production build, not dev. Run next build and next start, then click through the parts of the app that only some users reach: sign-in, admin, webhooks, anything behind auth.
2. Look for shared singletons. Database connections, caches and clients stored on globalThis are fine. Comparing classes across routes is not.
3. Boot the standalone output in CI. If you deploy .next/standalone, start it and hit a few routes before you deploy. Dynamic requires are where tracing loses files.
4. Upgrade one thing at a time. The driver problem came from TypeORM, not Next.js, and it was easy to pin down only because the dependency bumps were separate commits.
5. Run the codemod, then read its diff. It renames and rewrites correctly. It cannot know which of your routes depend on what it changed.

A year on, Next.js 16 is a better default than 15: faster builds, clearer names, and a cache API that says what it does. The upgrade itself is mostly typing. The work is in the few places where your app depended on how the old builder happened to behave, and the production build is the only place that will show you where those are.

This post first appeared on my site, kunjdeveloper.com, where I write about building and running full-stack web apps.

The header loaded. The grid behind the hero loaded. Then nothing. A big empty screen where the rest of my site was supposed to be.

I got roasted. On a roadside bench, for a site I had announced moments earlier. It was funny. It was significantly funnier for them.

The phone was an iPhone 13 Pro Max on the latest iOS, and I'm putting that up front because it kills the excuse I would otherwise have reached for. This was not a five-year-old budget phone dying on 2G. It was a flagship, on mobile data, and my site did not render.

Blaming Safari, then running out of things to blame

First instinct: Safari. Blaming Safari is free and usually at least partly correct.

So he opened it in Chrome. Same shit.

That was the clue, and I completely missed it. Every browser on iOS is Safari wearing a different hat. Same WebKit engine underneath, whatever the icon says. "Try it in Chrome" isn't a second test on an iPhone, it's the first test again.

Then another friend opened it on his Samsung. Perfect. Smooth, exactly like my laptop.

Every iPhone broken. Every Android fine. My machine fine. Cool. Love that for me.

A week of not being able to reproduce it

This was the genuinely miserable part.

I threw it at BrowserStack. BrowserStack told me the site was fine. Every iOS version I tried, fine, fine, fine.

Then I borrowed my sister's phone. Broken. My cousins' phones. Broken. Every real iPhone I could physically get my hands on failed the same way, while the one service whose entire job is reproducing this stuff kept insisting I was imagining it.

I still don't have a clean explanation for that gap. My best guess is that a fresh remote device on a fast connection never sits in the broken state long enough for you to catch it. Whatever the reason, the lesson stuck: when every real phone you can find disagrees with your testing service, believe the phones.

So I did it the stupid way. Deploy, check on my sister's phone, change something, deploy again. For about a week.

The thing that actually cracked it

The next day I downloaded one of those apps that gives you a console on your phone. I genuinely don't remember which one, it was whatever came up first.

Then it took about ten seconds.

The content was there. All of it. Every paragraph sitting in the DOM at opacity: 0, waiting for JavaScript to turn up and give it permission to exist.

Nothing had failed to load. Nothing had crashed. My site had rendered perfectly and then hidden itself from everybody.

Two things I had done to myself

I wrote both of these on purpose, thinking I was being clever.

The first was the scroll reveal wrapped around every section:

<motion.div
  initial="hidden"
  whileInView="show"
  variants={{ hidden: { opacity: 0, y: 24 }, show: { opacity: 1, y: 0 } }}
>
  {children}
</motion.div>

initial="hidden" is the killer. It bakes opacity: 0 straight into the server-rendered markup. The element doesn't come back until the bundle has downloaded, parsed, hydrated and hooked up an IntersectionObserver, and every single link in that chain is something that can be slow.

The second one was dumber. My hero entrance was a GSAP timeline, and to stop everything flashing in its final position before GSAP grabbed it, I'd written the obvious guard:

.hero-reveal { opacity: 0; }

GSAP cleared that on load. So if GSAP didn't run, nothing cleared it, and the hero stayed invisible. Permanently. There's no route back from that state. I had written a line of CSS whose only job was to hide my own content, and then trusted a third-party library to undo it.

Which explains exactly what my friend saw on that bench. The header and the hero grid were plain HTML and plain CSS, so they painted. Everything else in the page was sitting behind a script that hadn't arrived yet.

I'd built a site where the decorative background was more reliable than the writing.

Why iOS specifically

Honestly, none of this is iOS-specific, and that's the part worth taking away. Any browser anywhere will show you a blank page if the content is gated behind a script that hasn't run. The only variable is how long the gap lasts.

On my laptop that gap was short enough that I never once saw it while building the entire site. On that iPhone it was long enough to look like a broken website, and occasionally long enough that people gave up and started roasting me instead.

The fix that wasn't

My first attempt was prefers-reduced-motion: reduce, wired up through JavaScript. Reasonable idea: if someone doesn't want motion, skip the animation and show everything.

It didn't help at all. The JavaScript still had to load before anything could decide anything, so you got the same blank wait, and then the entire page appeared at once in a single ugly slab.

I hadn't fixed the problem. I'd moved it. Same gate, different key.

Fixing the hero: no JavaScript at all

The hero entrance is a staggered fade and rise. There was never a reason for that to be JavaScript. CSS has done this natively for years, so I deleted the timeline, deleted the guard, and wrote it properly:

@keyframes hero-fade-up {
  from { opacity: 0; transform: translateY(18px); }
  to   { opacity: 1; transform: translateY(0); }
}

@media (prefers-reduced-motion: no-preference) {
  .hero-badge,
  .hero-sub,
  .hero-cta,
  .hero-terminal {
    animation: hero-fade-up 0.6s cubic-bezier(0.22, 1, 0.36, 1) both;
  }

  .hero-badge    { animation-delay: 50ms; }
  .hero-terminal { animation-delay: 400ms; }
  .hero-sub      { animation-delay: 500ms; }
}

Two things in there matter more than they look.

both as the fill mode. Without it you can't stagger with delays, because each element sits at its natural opacity until its delay runs out and then snaps into place. both tells the browser to apply the from state during the delay and hold the to state afterwards. The useful side effect is that the hidden state now lives inside the animation instead of in a rule of its own. Take the animation away and the element is just visible.

Then the no-preference wrapper, which is the direct fix for my failed attempt. Instead of animating by default and switching it off under reduce, the animation only exists inside no-preference. The plain stylesheet now describes a page that's already finished and static, and motion is the thing being added on top. Reduced motion stopped being something JavaScript had to decide and became the default I opt out of.

Visually it's the same entrance. Same easing, same delays. It just happens at first paint now, before the browser has even asked for the JavaScript.

Scroll reveals, which do need JavaScript

These actually depend on scroll position, so I couldn't just delete the JS. What I could change was which direction the logic ran. Instead of rendering hidden and letting JavaScript release it, render visible and let JavaScript arm it.

export function useInViewReveal(once = true) {
  const ref = useRef<HTMLDivElement>(null);
  const inView = useInView(ref, { once, margin: '-80px' });
  const [hydrated, setHydrated] = useState(false);

  useEffect(() => setHydrated(true), []);

  const animate: 'show' | 'hidden' = !hydrated || inView ? 'show' : 'hidden';
  return { ref, animate };
}

The hydrated flag is the whole trick. On the server it's false, so animate is 'show', so the markup that ships is visible. Pair it with initial={false} and Framer stops writing an initial state of its own:

<motion.div ref={ref} initial={false} animate={animate} variants={variants}>
  {children}
</motion.div>

There's now no moment where JavaScript hasn't run and the content is hidden, because "JavaScript hasn't run" and "visible" are the same state.

Once it hydrates, anything already on screen stays put, so nothing flashes and nothing re-animates a paragraph you're halfway through reading. Anything off screen drops to hidden and reveals on scroll like before. On a decent connection you cannot tell that any of this changed.

One thing I got wrong on the first pass: I'd made the staggering container a motion element too, with its own hidden variant. Doesn't matter how careful the children are if the parent can still hide them. RevealGroup is a plain div now that hands each child an incremental delay and has no opinion about visibility.

What else went, once I started looking

• Lenis is lazy-loaded and skipped completely on touch devices. Native iOS scrolling beats anything I'd bolt on top, and not running a permanent requestAnimationFrame loop during hydration helps exactly the phones that need help.
• The stacked project cards went back to position: sticky and became a server component. One less scroll library, and under reduced motion it collapses to a normal vertical stack for free.
• The timeline progress rail is a small throttled scroll handler instead of a plugin.
• The skills marquee waits for idle before mounting rather than shipping dozens of inline SVG paths in the initial HTML. Its height is reserved in CSS so nothing jumps when it arrives.
• overflow-x: clip on body went back to hidden. clip is the better property and I'd rather use it, but Safari didn't ship it until 16, and an overflow value an older iPhone doesn't understand is not a bug you find quickly.

"Modern CSS" and "CSS that works on the phone your friend is holding" are not the same list.

How to catch this without the bench

None of it is hard to find once you know to look. It's just completely invisible from where I was standing.

The check that would have saved me a week: turn JavaScript off and reload. DevTools, command palette, Disable JavaScript. If the page still reads top to bottom you're fine. If it's blank, congratulations, you have my bug. Four seconds.

Then throttle properly, and watch the first two seconds rather than the finished state. The finished state always looks great. That's exactly why nobody catches this.

Read the SSR HTML instead of the DOM, too. The inspector shows you the page after hydration, which is precisely the version that's lying to you. curl the URL and grep it for opacity:0. Anything sitting on real content is a problem waiting for a worse connection.

And test on a real phone. Not a simulator, not a remote device farm that will cheerfully tell you everything is fine. A real one, in your hand, on cellular.

Where it actually stands

I'm not going to pretend this ended with a perfect Lighthouse score and a lesson learned. It's still not as fast as I want. The entrance is all hand-written CSS now with no motion library involved at all, and I'm still going back and forth on whether to do reduced motion through a proper hook instead of by hand.

But it renders. Immediately, on every phone I can get hold of, whether or not the JavaScript ever turns up. That's a low bar, and I had somehow built a site that couldn't clear it.

The thing had been live and broken for about a week before that bench. I have no idea who else opened it in that window. Probably nobody. I've decided to believe it was nobody.

This post first appeared on my site, kunjdeveloper.com, where I write about building and running full-stack web apps.