DEV Community: Francesca Milan

How We Cut Slow Responses by 80% Migrating to Next.js App Router

Francesca Milan — Tue, 16 Jun 2026 07:27:43 +0000

Subito is Italy's leading classifieds marketplace, serving millions of users every month. Our ad detail page is one of the most heavily trafficked pages on the platform, handling thousands of requests per minute and playing a critical role in both SEO and revenue.

In this article, we'll walk through how we migrated it from the Next.js Pages Router to the App Router, the challenges we encountered along the way, and how the migration helped reduce slow responses by roughly 80%.

The Goal
Migration Approach: Ship Without Blocking Anyone
Problem 1: HTTP 410 Gone in App Router
Problem 2: HTML Streaming Behind Nginx and Akamai
Rollout and SEO Monitoring
How Much Effort Did This Migration Require?
Results
Conclusions

The Goal

As we always do at Subito, we never migrate for migration's sake. We go in with specific, measurable targets:

Faster page loads: leverage React Server Components and HTML streaming
Better SEO: improve page speed scores, working alongside our SEO team, faster pages rank better

The migration touched every layer of the stack: Next.js, a custom Express server, Nginx, and Akamai as our CDN. Here's what each step looked like.

Migration Approach: Ship Without Blocking Anyone

The ad detail page is one of the highest-traffic pages on the platform. We couldn't freeze product work for weeks while we rewrote it. So we didn't.

Instead of doing a big-bang rewrite, we incrementally added the App Router tree, server components, data fetching, layouts, alongside the existing Pages Router page.

The key insight was that each new server component was simply a wrapper around the same client component already used by the Pages Router.
There was no duplication: one client component, two consumers.
This meant that any bug fix or product feature added to a client component automatically applied to both the old and new page. Developers working on the Pages Router side were already contributing to the App Router version without knowing it.

This approach gave us two things:

1. Clean component boundaries. We used server components to own data fetching and pass only what client components actually need. The classic prop-drilling waterfall disappeared.

2. A defined Data Access Layer. Following the Next.js recommendation, we centralized all data fetching behind a DAL and used React's cache() to deduplicate calls. When three server components all need the same ad data, the network call fires once.

For sections with heavy data dependencies or secondary content, we combined Suspense with the use() hook to unlock streaming:

// GeneralInfo.tsx
const GeneralInfo = ({ id, ...props }: Props) => {
  const { promise, resolve } = Promise.withResolvers<AsyncData>();

  fetchAdItem(id).then((ad) => {
    const { urn, advertiser } = ad;

    Promise.all([
      fetchShopData(advertiser.shopId, advertiser.type),
      // ...all the other fetches
    ]).then(([shop /* ...other results */]) => {
      resolve({ ad, shop /* ...other props */ });
    });
  });

  return (
    <Suspense fallback={<GeneralInfoSkeleton />}>
      <LazyGeneralInfo loadData={promise} {...props} />
    </Suspense>
  );
};

const LazyGeneralInfo = ({ loadData, ...props }: Props) => {
  const data = use(loadData);
  // ClientGeneralInfo is the same component used by the Pages Router version. No duplication!
  return <ClientGeneralInfo {...data} {...props} />;
};

The skeleton renders immediately while data resolves in the background. Once it arrives, React swaps in the real component, no layout shift, no full-page loading state.

Progressive Rollout via Custom Express Server

We run a custom Express server in front of Next.js. This gave us a clean toggle to route traffic between the old and new page:

// server.ts
server.get(
  adDetailListingPath,
  validateAdDetailListingParams,
  clientHints,
  securityMiddleware,
  (req, res) => {
    if (enableAppRouterForAdDetail(req.query, req.params.category)) {
      return app.render(req, res, '/ad/', req.params);
    }
    return app.render(req, res, '/addetail/', req.params);
  }
);

// utils/rollout.ts
const FORCE_MIGRATED_AD_QP = 'use-ar';
const MIGRATED_CATEGORIES: Array<string> = ['job'];

export const enableAppRouterForAdDetail = (
  query: ParsedQs,
  pathFriendlyCategory?: string
) => {
  return (
    query[FORCE_MIGRATED_AD_QP] === '1' ||
    (pathFriendlyCategory && MIGRATED_CATEGORIES.includes(pathFriendlyCategory))
  );
};

?use-ar=1 forced the new page for internal testing. The category list let us roll out one macro-category at a time in production, starting with Job category and expanding progressively.

Problem 1: HTTP 410 Gone in App Router

The ad detail page is indexed by search engines, so when an ad expires we must return a proper 410 Gone response. A redirect or even a standard 404 Not Found is not sufficient: a genuine 410 clearly signals to crawlers that the page has been permanently removed and should be dropped from the index as quickly as possible.

The App Router, at the time of our migration, had no built-in API for 410. notFound() returns 404. There's no gone().

We wrote a full discovery article on the available workarounds here: How to Return HTTP 410 Gone in Next.js App Router — Two Workarounds

Since we already owned the Express layer, we went with a status code interceptor: Express intercepts the outgoing response before it hits the client and rewrites the status code when the page signals a gone state. No framework hacks, no monkey-patching Next.js internals.

Problem 2: HTML Streaming Behind Nginx and Akamai

This was the trickiest part of the whole migration: during staging tests we noticed our <Suspense> skeletons were invisible. We even forced an artificial 5-second delay on data fetching; the skeleton still never appeared. The page just loaded slowly as a blank screen.

Nginx Buffering

The first fix was disabling response buffering in Nginx, as documented by Next.js:

proxy_buffering off;

With buffering off, the skeleton appeared... but only when hitting the origin server directly. Through the CDN, still nothing.

Akamai Buffering

We shifted our investigation to Akamai. Our initial hypothesis was a caching layer conflict or a compression issue. We disabled caching... no effect.

Before diving deep into Akamai's Property Manager, we opened a support ticket. The answer was clear:

By default, Akamai buffers HTML responses before delivering them to the client. Disabling this behavior requires advanced metadata and cannot be configured through standard Property Manager rules.

Chunked transfer encoding and early flush are not available as standard toggles, but Akamai provided us with a custom behavior that we could apply via Property Manager:

<network:http.buffer-response-v2>off</network:http.buffer-response-v2>
<edgeservices:wco.input-buffer-minimum>0B</edgeservices:wco.input-buffer-minimum>
<edgeservices:wco.request-flush>on</edgeservices:wco.request-flush>
<edgeservices:modify-outgoing-response.chunk-to-client>on</edgeservices:modify-outgoing-response.chunk-to-client>

Once applied, streaming worked end-to-end. Skeletons appeared immediately; content streamed in as data resolved :tada!

Streaming + Caching: What Actually Happens

After enabling the custom behavior, we re-enabled the Akamai cache layer (non-negotiable for a high-traffic site like ours) and observed the following behavior:

Cache MISS: The HTML is streamed. No Content-Length header in the response, the browser receives chunks progressively.
Cache HIT: The full HTML is returned at once with a Content-Length header (e.g., 28315). Streaming doesn't apply, but the page is already fully built so it doesn't need to be.

This is the correct behavior. Cached responses are fast regardless; streaming only matters for the cold path.

Rollout and SEO Monitoring

We rolled out in two distinct phase, deliberately separated, not just for technical safety, but for SEO safety.

Phase 1 was controlled at the Express layer: migrate to App Router, streaming off. We started with a single category (Job), monitored carefully, then expanded one macro-category per cycle until all traffic was on the App Router.

Only once the migration was stable did we consider enabling HTML streaming. We were genuinely concerned about the SEO implications: would Google's crawler handle a chunked, incrementally-delivered HTML response correctly? Would it see the full page content, or just whatever arrived in the first chunk? We didn't want to find out by watching rankings drop.

Phase 2 enabled HTML streaming: we started with the Videogiochi (Video Games) category, using a targeted rule in Akamai Property Manager:

If Path matches one of: /vi/*, *.htm
And Path matches one of: /videogiochi/*

Our SEO team played a key role throughout the rollout: before enabling streaming in a new category, we monitored its SEO metrics for roughly two weeks, ensuring there were no unexpected impacts on crawling, indexing, or search performance. Only after the category showed stable results did we move on to the next one.

How Much Effort Did This Migration Require?

Surprisingly little!
The migration was carried out primarily by a single developer, working on it incrementally between regular feature deliveries rather than as a dedicated full-time initiative.

A significant enabler was Claude Code, which we used extensively throughout the project. It helped with planning, architectural exploration, implementation details, and routine development tasks, allowing us to move faster while keeping the migration manageable for a very small team.

Results

Response Times

The Grafana graph below shows the percentage of responses taking more than 250ms. Before the migration (up to ~03/25), the figure sat consistently between 25% and 40%, with spikes reaching 55%.
After the rollout, it collapsed to near zero and stayed there.

SEO Performance

The data below shows Fast URLs (< 500ms) across categories:

The improvements are significant across the board, with Video Games showing the strongest gain at nearly 30%.

Conclusions

The migration itself wasn't the hardest part: Next.js made it possible to run Pages Router and App Router side-by-side, allowing us to migrate incrementally without stopping feature development.

The real challenge was making the entire delivery chain work together: React Server Components, streaming, Express, Nginx, Akamai, observability, and SEO requirements.

Only when all those pieces aligned did we unlock the performance improvements we were aiming for.

A few takeaways for teams considering a similar migration:

Parallel routing lets you migrate without a freeze. Pages Router and App Router coexist in the same Next.js project. Use that.
A custom server layer is an asset. Express gave us per-request routing control, progressive rollout toggles, and the ability to solve framework gaps (like 410 status codes) without waiting for upstream fixes.
HTML streaming requires work at every layer. Nginx buffering, CDN buffering, and chunked transfer encoding all need explicit configuration. Don't assume streaming works end-to-end just because your Next.js code is correct.
End-to-end and visual regression tests caught regressions early. Before touching production we had confidence from automated test coverage.

How We Reduced INP by 100ms+: GTM Isolation, React Compiler, and Better Telemetry

Francesca Milan — Tue, 17 Feb 2026 16:19:34 +0000

At Subito (Italy's leading classifieds platforms), we constantly monitor our Core Web Vitals. While we had a handle on LCP and CLS, we were constantly struggling with INP (Interaction to Next Paint) on our high-traffic public pages, specifically our Listing and Ad Details pages.

Unlike LCP or CLS, where we have automated alerts triggering when thresholds are breached, setting up alerts for INP seemed impossible.

What is INP?

For context, INP measures a page's responsiveness. It observes the latency of all user interactions (clicks, taps, and key presses) throughout the lifespan of a user's visit. The final value is the longest interaction observed (ignoring outliers).

According to Google's standards, a "Good" experience is defined by strictly defined thresholds:

🟢 Good: 200ms
🟡 Needs Improvement: Between 200ms and 500ms
🔴 Poor: 500ms

INP is about how "fast" the site feels when you try to use it. A poor INP means the user clicks a button and... waits.

The Problem: "It's Not Just Us"

We struggled with INP because fluctuations weren't always caused by our code.

On our highest-traffic pages, two major actors are almost entirely out of our direct control:

GTM (Google Tag Manager): Managed by our Marketing team.
ADV (Advertising): Managed by our Sales/Advertising team.

Both inject code and event listeners that heavily impact performance.

The Old "Empiric" Way (And Why It Failed)

Previously, our monitoring was purely observational via Grafana. When INP spiked, we would scramble to check recent releases. Most of the time, our code changes weren't the culprit, and rollbacks did nothing.

We resorted to an empiric, frustrating debugging process: open Chrome DevTools, throttle the CPU to 4x, simulate a 4G network, and click around hoping to reproduce the lag. It wasn't wrong, but it was inefficient and lacked engineering rigor.

The "Scientific" Approach: Isolating the Actors

This year, the Frontend Chapter decided to stop guessing. We needed to measure the specific weight of the three actors: Our Code, GTM, and ADV.

With approval from the respective teams, we ran an A/B test on 1% of our traffic:

Segment A: Loaded without GTM.
Segment B: Loaded without ADV.
Segment C: Standard traffic.

This finally gave us clear baselines.

Case Study 1: The Ad Details Page

Here is what we found for the Ad Details page:

Standard INP: 208ms (Needs Improvement)
INP without ADV: 180ms
INP without GTM: 112ms (Good!)

The data was undeniable: GTM was the primary bottleneck.

Case Study 2: The Listing Page

The Listing page was more complex. Even without external scripts, our baseline was high:

Standard INP: 345ms (Very Poor)
INP without ADV: 279ms
INP without GTM: 320ms

Here, removing GTM didn't help much, and removing ADV helped but didn't solve it. We had to dig deeper.

Solving the GTM Issue (Ad Details)

Once we knew GTM was the culprit on the Ad Details page, we collaborated closely with the Marketing team.

GTM works via triggers (events) that inject JavaScript (tags). To find the needle in the haystack, we cloned the GTM workspace for our 1% traffic slice and used a "Bisect" approach (binary search):

We disabled 50% of the triggers.
Monitored the INP.
If improved, the issue was in that 50%. If not, we checked the other half.
Repeat until the specific script is found.

The Verdict: The heavy hitters were tracking scripts for TikTok and Facebook.

Instead of complex engineering workarounds to move these scripts out of GTM, the Marketing team simply agreed to disable the TikTok tracking.

Result: INP dropped from 208ms to ~170ms. We were finally under the 200ms threshold! 🎉

Solving the Complex Issue (Listing Page)

The Listing page was harder because there was no single "culprit."

Step 1: Better Telemetry with Grafana Faro

We integrated Google's web-vitals library to capture attribution data (longestScriptURL, interactionTarget) and sent it to Grafana Faro:

getFaro().api.pushMeasurement(
    {
      type: 'INP',
      values,
    },
    {
      context: beacon,
    }
);

This allowed us to visualize exactly which scripts and which DOM elements were causing delays.

We discovered that clicks on a.index-module_link were problematic. These links had heavy event handlers attached by interstitial ads (full-page ads).

We are still negotiating a fix with the ADV team, but we couldn't just wait.

Step 2: Enter the React Compiler

To optimize the code we did control, we decided to upgrade to Next.js 16 and enable the React Compiler.

The upgrade process wasn't difficult (though switching from Webpack to Turbopack was an adventure for another article).

The Result:
Surprisingly, just enabling the React Compiler significantly dropped our INP:
From 345ms down to 271ms.

It's still not perfect, but it was a massive free performance win. If we calculate the "No ADV" scenario combined with React Compiler, we would actually be under the threshold:

Conclusion

We aren't done yet, but this journey taught us valuable lessons:

Don't Guess, Measure: Isolate your third parties (GTM, ADV) using traffic splitting (even 1-2%). It gives you leverage and data to drive decisions.
React Compiler is Legit: It's not hard to introduce, and it can provide a significant performance boost for free.
Collaborate, Don't Hack: We avoided clever technical workarounds (like the DataLayer yield pattern). Why? Because talking to the Marketing team and solving the root cause is sustainable. Hacks are not.

Next Steps

Enable automated alerting for INP now that we understand the baseline.
Continue optimizing the Listing page to reach the green threshold (sub 200ms).
The Big Goal: Treat Core Web Vitals as business metrics. We want to establish "Performance Budgets" (e.g., GTM gets max 50ms, ADV gets max 50ms) to ensure quality isn't sacrificed for tracking.