`next start` built-in compression never applies to Route Handlers (including metadata routes) — sitemap.xml served uncompressed

Link to the code that reproduces this issue

https://github.com/albert4719/next-route-handler-compression-repro

To Reproduce

The repro app is 4 small files: a page (app/page.js, ~3KB of HTML), a metadata route
(app/sitemap.js, ~7KB of XML) and a force-dynamic route handler (app/d.xml/route.js,
~5KB of XML) — both bodies well above the 1KB compression threshold.

1. npm install && npm run build && npm run start
2. Request each route with Accept-Encoding: gzip:

curl -s -H 'Accept-Encoding: gzip, br' -D - -o /dev/null http://127.0.0.1:3000/
curl -s -H 'Accept-Encoding: gzip, br' -D - -o /dev/null http://127.0.0.1:3000/sitemap.xml
curl -s -H 'Accept-Encoding: gzip, br' -D - -o /dev/null http://127.0.0.1:3000/d.xml

Current vs. Expected behavior

Actual results:

== /            (page)                          → Content-Encoding: gzip   ✅
== /sitemap.xml (metadata route, prerendered ○) → no Content-Encoding      ❌
== /d.xml       (route handler, force-dynamic ƒ)→ no Content-Encoding      ❌

Only page renders are compressed. Every Route Handler response — static/prerendered or dynamic — is sent as identity, even though:

• compress is not disabled (default true), and the docs say Next.js compresses "rendered content and static files" by default;
• the response body is far above the 1KB threshold of the bundled compression middleware;
• application/xml is compressible: true in mime-db, so it is not the content-type filter (same result with text/plain bodies).

Expected: Route Handler responses go through the same compression middleware as page renders.

Real-world impact: the app/sitemap.js metadata convention is the recommended way to serve a sitemap, and real sitemaps are routinely hundreds of KB. Ours is 200KB of XML sent uncompressed to every crawler fetch (gzips to 9KB). Any JSON API built on Route Handlers has the same problem when self-hosting.

A detail that may help locate the bug: compressed page responses come back with normally-cased headers (Content-Type, Content-Encoding), while Route Handler responses come back with lowercase raw headers (content-type, vary, …) — which suggests Route Handler responses are written through a path that bypasses the compression() middleware's res.writeHead/res.write hooks installed in server/lib/router-server.js (requestHandlerImpl calls compress(req, res, () => {}) for every request, but the hooks evidently never fire for these responses).

Provide environment information

Operating System: Windows 10 Pro 10.0.19045
Node: v26.2.0
npm: 11.13.0
next: 16.2.10 (Turbopack build)
react: 19.2.7
react-dom: 19.2.7

Which area(s) are affected? (Select all that apply)

Connection, Dynamic Routes

Which stage(s) are affected? (Select all that apply)

next start (local)

Additional context

No response

Start with server/lib/router-server.js, especially requestHandlerImpl and the compress(req, res, ...) call, then reproduce the behavior with the linked four-file app using the three curl commands. Trace why page responses trigger the compression hooks while metadata and dynamic Route Handler responses do not. Done means qualifying Route Handler responses include compression headers and bodies under next start, without changing the existing page behavior.