Web Frameworks Compared: Next.js vs Astro vs SvelteKit

A marketing site with 4,000 pages, two forms and a search box does not need React. A payroll dashboard with permissioned tables, live totals and a websocket feed does not need a static site generator. Most framework arguments go wrong because nobody writes the workload down first.

This comparison is organised around that constraint. The four web frameworks below are good answers to four different problems, and the differences that decide your hosting bill are rarely the ones in the release notes. What reaches the browser. Where rendering happens. What the runtime does to memory. How much of the week disappears into operations.

The short version. Astro is the sensible default for content. Next.js is the default when the team already lives in React and the product has logged-in users. SvelteKit is the lean option for interactive interfaces where bundle size is a budget line. Laravel is the fastest route to a business application with auth, queues, invoices and an admin panel, and Octane removes most of the old PHP throughput objection.

What each stack actually sends to the browser

Arguments about web frameworks usually compare syntax. The useful comparison is a delivery table: how much JavaScript reaches a mid-range phone, and what the browser has to do with it before the page responds to a tap.

Two columns decide your hosting bill. The third decides your incident reviews.

Next.js: server components and the client boundary

Next.js renders React on the server by default. A component is a server component unless the file marks a boundary with the 'use client' directive, and only code inside those boundaries is bundled for the browser [2]. For an application where one page mixes database reads with interactive widgets, that model is hard to beat.

The cost is conceptual and operational. Someone has to know which side of the boundary each component sits on, because a stray hook in a server component fails at build time and one careless import drags a charting library into the client bundle. Caching adds a second thing to learn. Deployment, at least, is simple: output: 'standalone' emits a self-contained Node server with only the dependencies it needs [3], which is what you want in a container or on a VPS.

Memory is the part teams underestimate. A running process holds the React runtime, the router and your server components, and a production build wants more headroom than the runtime does. A 2 GB box will build a small site and struggle with a large one. Next.js survives contact with a big team because the talent pool is deep and most integrations already exist. It punishes teams that adopt it for a brochure site.

Astro: islands, and a static default worth defending

Astro was built on a bet that most pages do not need a client runtime. It renders the layout, text and styling to HTML at build time and ships no JavaScript for anything that is not interactive. Interactive parts are opt-in islands, hydrated independently, and an island can be written in React, Vue, Svelte or plain JavaScript [1].

A component marked client:visible costs nothing until it scrolls into view:

---
// index.astro
import Layout from '../layouts/Layout.astro';
import StaticHero from '../components/StaticHero.astro';
import InteractiveCart from '../components/Cart.jsx'; // React Component!
---
<Layout title="SysopHost Cloud">
  <!-- Ships 0 KB JavaScript -->
  <StaticHero />

  <!-- Ships JavaScript ONLY for this component, hydrated when visible -->
  <InteractiveCart client:visible />
</Layout>

The result is a page with almost nothing to execute on the main thread, which is why content sites built this way tend to pass Core Web Vitals without much tuning.

The failure mode is design drift. Once half the page needs client state, you are maintaining islands plus a client framework, and the simplicity argument is gone. Astro's on-demand rendering with a Node adapter covers the middle ground, but at that point you are running a server again, with all the operational work that implies.

SvelteKit: the compiler does the work

Svelte compiles components into DOM instructions at build time instead of shipping a virtual DOM diff to the browser [4]. The practical result is a small runtime and predictable interaction latency on mid-range Android hardware, which is where a lot of commerce traffic actually lands. SvelteKit adds file-based routing, server endpoints, form actions and adapters for Node, static and serverless targets.

The honest limitation is the ecosystem. React has a component for everything, including three abandoned ones. Svelte often does not, so you write the wrapper. That is the trade most web frameworks make: less surface area, less help. It is a real cost on a six-week project and a rounding error on a two-year product.

The syntax is the other dividing line. Svelte reads like HTML with JavaScript in it, which shortens the ramp for anyone who has written a template before, and the runes model removes most of the ceremony around shared state. None of that helps if your team has already memorized React's rules.

Laravel Octane: PHP without the per-request boot

Standard PHP boots the framework on every request. Octane starts the application once, keeps it in memory, and serves requests through Swoole or RoadRunner workers, so framework boot and container wiring happen at worker start rather than per visitor [5].

That one change is what makes the old throughput objection mostly obsolete:

# Running Laravel Octane with Swoole behind Nginx
php artisan octane:start --server=swoole --workers=4 --task-workers=2 --port=8000

What you get beyond throughput is a complete toolkit: Eloquent, migrations, queues, scheduled tasks, auth scaffolding, mail and a mature admin ecosystem. For billing, roles, reporting and a back office, that is months of work you do not write.

The cost is a new class of bug. Long-lived workers keep state between requests, so a static property holding request-specific data becomes a leak. Octane's documentation is explicit about this, and any package written for a fresh boot per request deserves a second look. You also need a supervisor, a reverse proxy and a deploy step that reloads workers rather than dropping requests.

The comparison, minus the scoreboard

Ignore any table that puts a millisecond figure on a web framework. Page latency depends on the query behind it, the cache in front of it and the network between them far more than on the renderer.

Hydration, INP, and what the metrics actually measure

Interaction to Next Paint replaced First Input Delay as the responsiveness metric, and it measures interactions across the whole visit rather than the first one. Google's guidance puts the boundary between good and needing improvement at 200 ms [6]. A static page with no interactive elements has almost nothing to measure, which is why an Astro marketing page looks excellent on paper.

Hydration hurts when a page looks ready before it is. The HTML paints, the user taps, and the main thread is still parsing the framework bundle, so the tap waits. Bigger bundles mean longer waits. That is an architectural problem, not a plugin problem.

The counter-argument is fair. A dashboard with forty interactive controls will ship JavaScript whichever framework you choose. The difference is how much runtime each one wraps around your code. If you want the search-visibility side of this argument, we covered it in why website speed matters for SEO.

Hosting all four on the same box

The deployment story for all four web frameworks has converged. Each one runs as a Linux process behind a reverse proxy, or as a container, and none of them needs a proprietary platform.

• Astro static output is files on disk. Point Nginx or LiteSpeed at the build directory.

• Next.js and SvelteKit run their Node server on localhost and get proxied.

• Laravel Octane runs workers under a supervisor and gets proxied.

• All of them need TLS, log rotation and a deploy path that finishes in-flight requests instead of killing them.

Two numbers decide whether an Octane run survives: workers multiplied by memory per worker, against available RAM. Four workers on a 4 GB box is comfortable for a small app. Twenty workers on the same box is how you meet the OOM killer.

The Node side is the same sequence every time: process manager, reverse proxy, certificates, deploy hook. We walk through it in the Node.js deployment guide, and the PHP specifics are in Octane hosting requirements. If assembling that stack is not the work you want, managed cloud hosting covers Node.js and Docker workloads without the plumbing.

Picking one

• Content site, documentation, marketing pages: Astro. The static default is the whole argument.

• Application with logged-in users and a React team: Next.js. Do not fight the ecosystem you already have.

• Interactive product UI where mid-range mobile performance is a differentiator: SvelteKit.

• Business software with billing, roles, queues and reporting: Laravel, with Octane if throughput matters and plain PHP-FPM if it does not.

• Mixed estate: Astro for the public site, Laravel or Next.js for the app, one reverse proxy in front of both.

Notice what is missing from that list: benchmark scores. They do not transfer between workloads, and a team that can operate its stack at 2am beats a team with the faster hello-world every time. Shortlists of web frameworks fail on operations far more often than on render speed.

None of this is permanent. The web frameworks you choose this year are probably the ones you migrate off in four, and that migration is cheaper when the runtime is a plain Linux process rather than a proprietary platform.

One caveat worth stating plainly. If nobody on your side can read a stack trace on a Sunday, hosting decisions matter more than framework decisions. The best framework on a box you cannot debug is a liability. Framework choice sets the ceiling; operations decide whether you get close to it.