Next.js 15 was written mainly in the "revolution" genre. Further - without it. Let's analyze what exactly changed in the release, which changes break the working code silently, and how to check in half an hour whether your project receives anything from the new version at all, except for the number in package.json.
Turbopack: Faster, but not where you think
Turbopack has received a stable status for next dev — this is recorded in the official Next.js release notes. Instead of completely rebuilding the module graph after each edit, it rebuilds only what has changed and keeps the result in memory between builds.
How much faster it will be for you personally depends on the number of modules, depth of imports, set of CSS processors and disk speed. There won't be a comparative table of "was / became" here: numbers from someone else's laptop on someone else's project do not say anything about yours. Measure the time yourself before starting the dev server, then toggle the flag and repeat on the same code.
And the main thing, which is usually kept silent. The speed of the dev server has nothing to do with how fast the site will open for the visitor. Turbopack runs on your machine during development. A visitor sees a production build, delivered from a server in another country, over a mobile network, on a five-year-old phone. They're two different worlds, and speeding up the first doesn't improve the second one millisecond.
What really affects the speed of the visitor
Between the click and the appearance of the content, a person does not see anything. The longer this pause, the greater the proportion of people who close the tab - and these people will not see either the product, the price, or the form. Speed does not sell. It determines how many people your offer will be shown to.
Technically, there are two levers here: TTFB (time to first byte - caching, requests to the database, server settings) and the weight of HTML that the browser has to load before the first rendering. Next.js helps with both, but doesn't do the work for you.
Our measurements on live sites, made externally via curl on 07/31/2026:
- corporate one-page website of a consulting company on Next.js — TTFB 254 ms, full document in 342.6 ms, HTML 102.1 KB;
- SaaS platform for rewriting product descriptions — TTFB 220.6 ms at 141 KB HTML.
This is our measurement, and it's server health, not a client business metric. The fair boundary here is this: TTFB is only the server part. The full time to interactivity in a real visitor also depends on his device, network, weight of pictures and third-party scripts that were connected already after our measurement. And even more important: a site that opens in 200 ms will simply give a person a reason to leave faster if the price is higher than the market or the product is out of stock. Speed removes technical loss. It does not create demand.
Caching: fetch is no longer cached by default
Quietest release change. In Next.js 14, the result of fetch() was cached by default, in 15 it was not. The same with GET handlers in Route Handlers and with the router's client cache.
It breaks without errors. The code works, the tests pass, and the server starts going to the API for every request instead of once a minute. It is usually noticed on the bill from the hosting or on TTFB, which has tripled after the update.
What to do during migration: go through all fetch() in the server components and set the intention explicitly.
