Every few years the web decides it has been doing things wrong. The last correction pushed almost everything into the browser and called the result an application. The one now under way is quieter: taking that work back off the user's device.
You can tell where things have landed by what teams have stopped arguing about. Server-first rendering is not a position any more. It is the default in every major framework.
The interesting question moved on. Now it is: how much of this page needs to be interactive at all? Most of a marketing site does not. Neither does a documentation page or a product listing. And the frameworks finally let you say so, sending plain markup for the static parts and script only where something actually responds.
A page's cost is no longer counted in requests. It is counted in JavaScript the browser must download, parse and execute before anything on screen will answer a tap.
That is the number that tracks how a site feels on a mid-range phone with a weak signal. Which is the device most of your users are holding. It is also the one Google now scores you on.
Worth knowing
INP replaced First Input Delay as a Core Web Vital. FID only measured the first interaction of a visit; INP measures all of them, which is why a site that scored well before can score badly now without changing a line.
web.dev — Interaction to Next Paint
200ms
Interaction to Next Paint above this is no longer rated "good"; above 500ms it is rated "poor". INP replaced First Input Delay as a Core Web Vital, and unlike its predecessor it measures every interaction across the visit — which is to say, it measures exactly the main-thread work that excess JavaScript creates.
Edge delivery, minus the hype
For a couple of years the edge was proposed as the answer to everything. It is settling into being the answer to some things. The correction was just arithmetic. Teams that moved everything out there found they had swapped a short trip to the server for a long trip to the database, and quietly moved most of it back.
Running your code in three hundred locations does not help if it has to wait on a database in one of them.
What survived is the work that belongs near the user and carries no state. Redirects. Auth checks. Feature flags, geo-aware routing, caching decisions. For those, the edge is excellent. As a default place to run everything, it mostly moves latency around instead of removing it.
The platform absorbed the tooling
The least discussed shift is the most useful one. A lot of what used to need a library now ships in the browser.
- Container queries — a component responds to the space it occupies rather than the size of the window.
- Modern CSS selectors express state that previously needed a class toggled by script.
- View transitions animate between states without a library.
- Dialogs and popovers are native elements, with focus handling and accessibility built in rather than reimplemented slightly wrong by each team.
- Build tooling rewritten in compiled languages does in seconds what used to take minutes.
Rule of thumb
The best dependency is the one you never added
It never breaks, never needs a security patch, and never has to be untangled by whoever inherits the project.
The through-line across all of this is not a technology, and that is what makes it easy to miss. It is a narrowing of what teams are willing to ship: less client-side JavaScript, fewer dependencies, less machinery between a request and a rendered page. The web spent a decade proving it could behave like a native application. The more valuable lesson of the last few years is how rarely it needs to. The most modern thing a team can do in 2026 is send less.