← All Posts

Modern Frontend Architecture — React, Svelte, and the Performance Patterns That Matter

Matthias Bruns · · 8 min read
frontend react svelte architecture performance

The Framework Choice Is Not the Architecture Decision

Every quarter, a new “React vs. Svelte vs. X” benchmark post goes viral. Teams spend weeks evaluating, build a proof-of-concept, and then ship the same over-fetching, client-rendered SPA they would have built with any framework. The choice of React or Svelte matters far less than the architectural patterns you apply on top of it.

The real decisions: Where does rendering happen? How much JavaScript reaches the browser? How do components communicate state? These questions determine whether your app loads in 800ms or 4 seconds — not whether you picked React 19 or Svelte 5.

Rendering Strategies: Pick Per Page, Not Per App

The era of “our app is an SPA” or “our app is server-rendered” is over. Modern meta-frameworks — Next.js, SvelteKit, Astro — let you choose rendering strategy per route.

Static Site Generation (SSG) for content that changes infrequently. Blog posts, documentation, marketing pages. Build once, serve from CDN, zero server cost per request.

Server-Side Rendering (SSR) for pages that need fresh data on every request. Dashboards, search results, personalized content. The server renders HTML, the client hydrates it.

Client-Side Rendering (CSR) for highly interactive sections behind authentication. Admin panels, real-time editors, drag-and-drop interfaces. No SEO requirement, full interactivity from the start.

The pattern that wins in 2026: hybrid rendering. Your marketing pages are SSG. Your product pages are SSR with streaming. Your app shell is CSR. One codebase, three strategies, each optimized for its use case.

Islands Architecture: Ship Less JavaScript

Islands architecture, popularized by Astro, is the most impactful frontend pattern to emerge in recent years. The concept: render most of your page as static HTML on the server, then hydrate only the interactive “islands” — a search widget, a shopping cart, a comment section — on the client.

The result is dramatic. A typical content-heavy page that shipped 200KB of JavaScript as a React SPA now ships 15KB. The rest is static HTML that the browser renders instantly. Core Web Vitals improve across the board: better Largest Contentful Paint (LCP), lower Interaction to Next Paint (INP), reduced Cumulative Layout Shift (CLS).

Astro takes this further by letting you mix frameworks within a single page. A React component for the interactive pricing calculator, a Svelte component for the animated hero, plain HTML for everything else. Each island hydrates independently, on its own schedule.

This is not theoretical. The Astro showcase includes production sites from companies handling millions of monthly visitors — with Lighthouse scores consistently above 95.

Signals: The Reactivity Model That Changes Everything

React’s re-rendering model — re-run the component function, diff the virtual DOM, patch the real DOM — has been the dominant paradigm for a decade. It works, but it has a cost. Every state change re-executes the entire component tree unless you manually optimize with useMemo, useCallback, and React.memo.

Signals take a fundamentally different approach. Instead of re-running components, signals track which specific DOM nodes depend on which specific pieces of state. When state changes, only the affected DOM nodes update. No diffing, no virtual DOM, no manual memoization.

Svelte 5 introduced runes ($state, $derived, $effect) as its signals implementation. The compiler analyzes your code at build time and generates surgical DOM updates. The developer writes straightforward reactive code; the compiler does the optimization work.

React is moving in this direction too. The React Compiler (formerly React Forget) automatically memoizes components and hooks, eliminating the need for manual useMemo/useCallback. It does not adopt signals directly, but it solves the same problem: reducing unnecessary re-renders without developer effort.

The practical implication: in 2026, both React and Svelte can deliver excellent runtime performance. The difference is in the developer experience. Svelte’s approach is more explicit — you see the reactivity in the syntax. React’s approach preserves the familiar function-component model while optimizing behind the scenes.

React Server Components: The Server-First Shift

React Server Components (RSC) represent React’s biggest architectural change since hooks. Server Components run only on the server. They can access databases, file systems, and internal APIs directly. They send rendered HTML to the client — no JavaScript bundle for the component itself.

The mental model shift:

// Server Component — runs on the server, ships zero JS to client
async function ProductPage({ id }) {
  const product = await db.products.find(id);
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <AddToCartButton productId={id} /> {/* Client Component */}
    </div>
  );
}

The ProductPage component never reaches the browser. Only AddToCartButton — marked with 'use client' — ships JavaScript. The data fetching happens on the server, close to the database, with no waterfall of API calls from the browser.

Next.js App Router builds entirely on this model. Every component is a Server Component by default. You opt into client-side interactivity explicitly. This inversion — server-first instead of client-first — reduces bundle sizes and eliminates entire categories of loading states.

When to Choose React, When to Choose Svelte

After years of consulting on frontend architecture, here is the decision framework we apply:

Choose React when:

  • Your team already knows React (retraining cost is real)
  • You need the ecosystem — component libraries, tooling, third-party integrations
  • You are building a large, long-lived application where hiring React developers matters
  • You want Server Components and the Next.js ecosystem

Choose Svelte when:

  • Performance is a primary concern and you want the smallest possible bundle
  • Your team is small and can move fast with less boilerplate
  • You are building content-heavy sites where compile-time optimization shines
  • You want an opinionated, batteries-included meta-framework (SvelteKit)

Choose Astro when:

  • Content is king — blogs, marketing sites, documentation
  • You want islands architecture with the flexibility to use React, Svelte, or both
  • You need perfect Lighthouse scores with minimal effort

The honest answer for most teams: the framework you know well, combined with the right rendering strategy, will outperform the “theoretically faster” framework applied naively.

Core Web Vitals: The Metrics That Pay the Bills

Google’s Core Web Vitals directly influence search ranking. In 2026, the metrics that matter:

Largest Contentful Paint (LCP) — how fast the main content appears. Target: under 2.5 seconds. Fix it with SSR/SSG, image optimization, and font preloading. If your hero image is a 2MB unoptimized PNG, no framework can save you.

Interaction to Next Paint (INP) — how fast the page responds to user input. Target: under 200ms. Fix it with smaller JavaScript bundles, code splitting, and avoiding long tasks on the main thread. Islands architecture helps enormously here.

Cumulative Layout Shift (CLS) — how much the layout jumps around during load. Target: under 0.1. Fix it with explicit image dimensions, font-display swap strategies, and reserving space for dynamically loaded content.

The pattern we see in production: teams that adopt SSR + islands architecture + aggressive code splitting consistently achieve “good” Core Web Vitals scores. Teams that ship client-rendered SPAs consistently struggle, regardless of which framework they use.

Practical Architecture for a Growing Team

Here is the frontend architecture we recommend for teams scaling from 3 to 15 engineers:

Monorepo with shared design system. Use Turborepo or Nx to manage packages. Your design system lives in a shared package. Each product vertical owns its own app package.

Feature-based folder structure. Not components/, hooks/, utils/. Instead: features/checkout/, features/search/, features/product/. Each feature folder contains its components, hooks, tests, and API calls. A developer working on checkout never needs to touch the search folder.

State management: keep it local. Global state stores (Redux, Zustand) are necessary for truly global concerns — authentication, feature flags, theme. For everything else, keep state in the component that owns it. Server Components eliminate most client-side state by moving data fetching to the server.

Testing pyramid, not testing ice cream cone. Unit tests for utility functions and hooks. Integration tests for feature flows. A thin layer of E2E tests for critical paths. If your E2E suite takes 45 minutes, you have an architecture problem, not a testing problem.

The Bottom Line

Frontend architecture in 2026 is not about picking the “best” framework. It is about applying the right rendering strategy per page, shipping the minimum JavaScript necessary, and structuring your codebase so that a team of 10 can work without stepping on each other.

Islands architecture, signals-based reactivity, and server components are not competing ideas — they are complementary patterns solving different parts of the same problem: delivering fast, interactive web experiences without drowning in complexity.

Pick a framework your team knows. Apply these patterns deliberately. Measure with Core Web Vitals. Iterate. That is the entire strategy.

Reader settings

Font size