Web Architecture Overview

Map the full journey of a web request — from URL bar to painted pixels — and understand where front end engineering lives inside that pipeline.

The Distance Between Click and Content

When Stripe's infrastructure team redesigned their checkout architecture in 2022, page load time dropped by 340 milliseconds. No visible design change. No new features. Pure architecture. That 340ms translated directly into measurable conversion improvement — because users weren't waiting as long between clicking "Pay" and seeing the confirmation screen.

Most developers treat the browser as the starting line. It isn't. By the time the browser gets involved, several distributed systems have already negotiated behind the scenes. Understanding that negotiation is what separates engineers who fix symptoms from those who fix causes.

The PixelForge Performance team discovered this directly. Their dashboard felt slow even after optimising React component renders. The real culprit was a 180ms DNS lookup on a third-party font provider — a step happening before the browser had even received a byte of HTML. Fixing it required understanding the full stack, not just the JavaScript layer.

Three Layers, One System

Web architecture is usually described as "client–server." That framing is accurate but dangerously simple. In any production web application today, there are at least three distinct layers that every request passes through — and each layer has a different job, different failure modes, and different performance levers.

Front end engineers interact with all three layers — even if they never write a line of backend code. You decide which API endpoints to call and when. You configure how assets are cached. You write service workers that intercept network requests. Treating the front end as isolated from the network layer is a mindset that produces slow, brittle applications.

Rendering Models — The Most Important Decision in Your Architecture

GitHub's engineering blog published a postmortem in 2021 about a failed migration from server-rendered ERB templates to a fully client-side React SPA. The result was a regression in Time to Interactive from 1.8s to 4.1s on median hardware. They rebuilt using a hybrid model that kept HTML delivery server-side and handed JS execution only to the interactive parts. Performance recovered to 1.4s — better than the original. The choice of rendering model had a larger impact than any individual component optimisation.

There are four primary rendering models in production use today. Every new project forces a choice between them — and that choice cascades into bundle strategy, caching strategy, SEO posture, and developer experience.

The PixelForge Platform team ships two separate rendering models simultaneously. The marketing site (pixelforge.io) uses SSG through Next.js — it rebuilds on every deploy and individual pages revalidate hourly via ISR. The web application (app.pixelforge.io) is CSR-only, since it's fully authenticated and SEO is irrelevant behind a login wall.

CDNs — The Layer Most Developers Underestimate

A Content Delivery Network is a geographically distributed cache. Instead of every request crossing an ocean to reach a server in Virginia, a user in Mumbai hits a CDN edge node 8 milliseconds away. That single architectural decision — moving assets closer to users — is responsible for more web performance improvement than any front end optimisation technique combined.

Cloudflare operates over 285 edge locations. Fastly reaches 93% of internet users within 50ms. When Shopify serves 1.7 million merchants globally, every static asset — every JS chunk, every CSS file, every product image — routes through their CDN layer. The origin server barely touches those requests.

Front end engineers control CDN behaviour through Cache-Control headers. A JS bundle with a content-hash in its filename (e.g. chunk.a8f3d2.js) can be cached for one year: Cache-Control: public, max-age=31536000, immutable. The hash changes with every build, so browsers and CDNs fetch the new file automatically. An HTML file, by contrast, should never be cached long-term — it's the pointer to all those hashed assets.

APIs — How the Front End Talks to Everything Else

The front end never stores the real data. User profiles, project files, collaboration state — all of it lives in databases the browser can't directly touch. Every interaction that needs real data goes through an API: a defined contract between the client and the server. How that contract is designed has enormous consequences for how fast, how reliable, and how complex your front end becomes.

Over-fetching is a problem REST developers often accept as normal. A GET /users/42 endpoint might return 47 fields when the UI only needs 3. On mobile over a 4G connection, those extra fields cost real bytes and real milliseconds. Linear solved this by building a tight GraphQL API where every client query is specific — their mobile app downloads precisely what it renders, nothing more.

Monolith vs Micro-Frontend — When to Split the Front End Itself

Atlassian hit a wall around 2018. Their Jira and Confluence front ends had become enormous single applications — millions of lines of JavaScript shared across teams that had entirely different release cycles and different product priorities. A bug fix in one team's component required coordinating deploys with four other teams. Their solution was to split the front end the same way backend teams split services: micro-frontends.

A micro-frontend is an architectural approach where the front end is divided into independently deployable slices — each owned by a separate team, each shippable without touching the others. The shell application composes them at runtime using module federation, iframes, or web components.

The right choice depends on team size, not application size. A 5-person team building a complex product does not need micro-frontends. A 50-person team with four independent product squads absolutely does. Introducing micro-frontend complexity at the wrong time creates overhead without benefit.

Where Architecture Decisions Actually Live

Architecture isn't a document you write once. Every pull request is an architecture decision — whether you treat it that way or not. A developer who adds a new useEffect to fetch data in a component has made an architecture decision about where data lives. One who imports a 120KB library to format a date has made a performance architecture decision that will affect every user on a slow network.

Senior front end engineers develop an architectural instinct — the ability to see the second and third-order consequences of a code change. Adding a new HTTP request inside a component render cycle can create N+1 network patterns. Storing server state in a global Redux store when you could use React Query doubles your data management complexity for zero benefit.

None of those consequences are wrong — they're just real. The engineers who made those decisions weren't incompetent. They just didn't trace the cascade before committing. Architecture thinking is consequence thinking. And the best time to think about consequences is during the pull request discussion, not six months after the technical debt has accrued.

Quiz