The frontend is the part of a web application that runs on the user’s device, usually in the browser, and is responsible for everything a person sees and interacts with: page structure, layout, visual design, input handling and the logic that turns data into an interface. In web architecture, it is the presentation layer that sits opposite the backend, communicating with servers through HTTP requests and APIs.
Frontend code is built from three core technologies: HTML for structure, CSS for presentation and JavaScript for behavior. Around them sits a large toolchain of frameworks, bundlers and testing tools, but the defining feature stays the same: frontend code executes in an environment the developer does not control, on unknown hardware, screen sizes, network speeds and browser versions.
What the frontend layer is responsible for
The frontend translates data and business rules provided by the backend into a usable, accessible and fast interface. Its responsibilities go well beyond appearance, because the browser is also where user input is first collected, where state changes are reflected and where most perceived performance is decided.
The following table breaks the layer into its main areas of responsibility.
| Responsibility | Typical technology | What it covers |
|---|---|---|
| Structure and semantics | HTML | Document outline, landmarks, forms, meaning for assistive technology |
| Presentation and layout | CSS, design tokens | Typography, grid and flexbox layout, responsive breakpoints, themes |
| Interaction and state | JavaScript, TypeScript | Event handling, client state, routing, form validation |
| Data access | fetch, GraphQL clients | Calling APIs, caching responses, handling loading and errors |
| Performance | Bundlers, image formats | Code splitting, lazy loading, Core Web Vitals |
| Accessibility | ARIA, semantic HTML | Keyboard access, focus order, screen reader support |
A crucial boundary applies to all of these: validation and security checks in the frontend are a convenience, not a safeguard. Anything running in the browser can be inspected and modified by the user, so the backend must enforce every rule again.
How the frontend renders a page
Every frontend ultimately feeds the browser’s rendering pipeline: the browser parses HTML into the DOM, parses CSS into the CSSOM, combines them into a render tree, calculates layout, paints pixels and composites layers. JavaScript can change the DOM at any point, which is powerful but also the most common source of layout thrashing and slow interactions.
Where the HTML is produced is the key architectural decision. The table compares the main rendering strategies used by modern frontends.
| Strategy | Where HTML is built | Strengths | Weaknesses |
|---|---|---|---|
| Client-side rendering (CSR) | In the browser at runtime | Rich interactivity, simple hosting | Slow first paint, weaker for crawlers |
| Server-side rendering (SSR) | On the server per request | Fast first content, good for SEO | Server cost, hydration overhead |
| Static site generation (SSG) | At build time | Very fast, cheap CDN delivery | Rebuilds needed for content changes |
| Incremental regeneration | At build time, refreshed later | Static speed with fresher data | Cache invalidation complexity |
| Islands and partial hydration | Server, with isolated client parts | Ships little JavaScript | More complex component boundaries |
Most production sites combine strategies, for example static marketing pages with a client-rendered dashboard behind login. The choice depends on how dynamic the content is, how important search visibility is and how much JavaScript the target devices can execute quickly.
Frontend compared with backend and full stack
The frontend and backend divide a web application by where code runs and whom it trusts. Neighboring terms in web architecture, such as Backend, Full Stack and Headless Architecture, describe the other side of that line or ways of connecting the two.
| Aspect | Frontend | Backend | Full stack |
|---|---|---|---|
| Execution environment | Browser or client device | Servers and cloud services | Both |
| Trust level | Untrusted, user-controlled | Trusted, operator-controlled | Must respect both boundaries |
| Main concerns | Interface, interaction, perceived speed | Data, business rules, security | End-to-end features |
| Typical languages | HTML, CSS, JavaScript, TypeScript | Java, Go, Python, PHP, Node.js | A mix of both sides |
| Key metrics | LCP, INP, CLS, accessibility | Latency, throughput, error rate | Feature delivery speed |
In a headless architecture, the frontend is fully decoupled from a content or commerce backend and consumes it only through APIs. This gives frontend teams freedom over frameworks and release cycles, at the cost of more integration work and responsibility for rendering, caching and SEO.
The modern frontend toolchain
Source code written by developers is rarely what the browser receives. A build step transforms it: TypeScript is compiled, modules are bundled, unused code is removed by tree shaking, assets are minified and fingerprinted for long-term caching, and images are converted to efficient formats such as WebP or AVIF.
- Component frameworks such as React, Vue, Angular and Svelte organize the interface into reusable pieces with their own state.
- Bundlers and build tools such as Vite, webpack and esbuild resolve imports and produce optimized output files.
- Styling approaches range from plain CSS with custom properties to CSS modules and utility-first frameworks.
- Testing layers include unit tests, component tests, end-to-end browser tests and visual regression checks.
- Design systems keep components, tokens and accessibility patterns consistent across teams and products.
Common frontend pitfalls
Most frontend problems come from shipping too much code or from treating the developer’s fast laptop as representative. A median mobile device parses and executes JavaScript several times more slowly than a modern desktop, so a bundle that feels instant in the office can make a page unresponsive for seconds on a mid-range phone.
| Mistake | Consequence | Better practice |
|---|---|---|
| Oversized JavaScript bundles | Slow startup, poor INP | Code splitting and a performance budget |
| Div-only markup | Inaccessible to screen readers | Semantic HTML elements first |
| Unsized images and embeds | Layout shifts, poor CLS | Explicit width, height or aspect ratio |
| Trusting client validation | Security holes | Repeat every check on the server |
| Testing on one browser | Broken layouts for some users | Cross-browser and device testing |
The most reliable defense is measuring with real-user data and treating accessibility and performance as requirements from the first sprint rather than fixes before launch.
In plain words
Think of a restaurant. The dining room is the frontend: the menu, the tables, the lighting and the waiter who takes your order. The kitchen is the backend, where food is actually prepared and stored.
On a website, the frontend is everything you see and click in your browser: buttons, text, images and forms. It collects what you want, passes the request to the server and then presents the answer in a clear and pleasant way.
A real-world example
An online furniture retailer finds that most visitors arrive on phones, yet product pages take more than five seconds to become interactive on mid-range devices. An audit shows a single 1.2 MB JavaScript bundle that loads the checkout, reviews widget and 3D viewer on every page.
The frontend team switches product pages to server-side rendering, splits the bundle so the 3D viewer loads only when a shopper taps it, sets explicit dimensions on product photos and serves them as AVIF. They also replace clickable div elements with real buttons so keyboard and screen reader users can add items to the cart.
After the release, product pages show their main image in about two seconds on the same phones, layout shifts largely disappear and the mobile conversion rate rises noticeably. No backend code changed; the gains came entirely from the frontend.