Frontend Architecture: [Web application name]

Frontend architecture document for a web application: rendering strategy, framework and state management, routing, data fetching and caching, component architecture and design system, micro-frontends, performance budgets with Core Web Vitals targets, accessibility, internationalisation, security, testing, build and deployment, observability and browser support. Based on common industry practice, Google's Core Web Vitals (LCP, INP and CLS, as published on web.dev, checked October 2026) and WCAG 2.2 level AA. Replace every [bracketed] value and every row marked Example; the examples follow a retail web shop with a logged-in account area.

Document control

Approvals

Revision history

Contents

1. Introduction
2. Architectural drivers
3. Rendering strategy
4. Framework and state management
5. Routing
6. Data fetching and caching
7. Component architecture and design system
8. Micro-frontends
9. Performance budgets and Core Web Vitals
10. Accessibility
11. Internationalisation
12. Security
13. Testing strategy
14. Build and deployment
15. Observability
16. Browser and device support
17. Decisions, risks and open questions

1. Introduction

1.1 Purpose and scope

This document defines the frontend architecture of [Application]: how pages are rendered and delivered, how code is organised, and the quality targets every team building on it must meet. It covers [scope]. Example: the public shop (home, category, product, search, cart, checkout) and the account area; the internal back office is out of scope.

1.2 Context

The diagram shows the frontend in its environment.

1.3 Users, devices and networks

2. Architectural drivers

3. Rendering strategy

3.1 Options

3.2 Decision per route

4. Framework and state management

Rule: do not copy server data into a global store; read it from the cache so there is one source of truth.

5. Routing

6. Data fetching and caching

API access: all client calls go to the backend for frontend (BFF), which shapes responses for screens and keeps tokens server-side. Errors follow a single problem-details format and map to user-facing messages.

7. Component architecture and design system

Design system: [package name and version policy]. Example: published as a versioned package; product teams upgrade within two minor versions; visual regression tests on every component; components documented with usage, accessibility notes and do and don't examples.

8. Micro-frontends

Decision: [Used / Not used]. Example: Not used for the shop. The four teams work in one repository with route-level ownership (CODEOWNERS) and independent feature flags, which meets FE-04 without the duplicated dependencies and integration cost of runtime composition. Revisit if the number of teams exceeds eight or if a separately released partner area is added.

9. Performance budgets and Core Web Vitals

9.1 Core Web Vitals targets

Thresholds for "good" as published on web.dev at the time of writing, measured at the 75th percentile of page loads:

Supporting metrics: TTFB (time to first byte) Example: <= 0.8 s and FCP (first contentful paint) Example: <= 1.5 s, used for diagnosis.

9.2 Resource budgets

Budget reasoning: download time for a resource of size $S$ kilobytes on bandwidth $B$ kilobits per second is

Example: 170 KB of JavaScript on a 1.6 Mbit/s connection takes $t = 8 \times 170 / 1{,}600 = 0.85$ s before parsing and execution, which is why the JavaScript budget is the tightest constraint on LCP and INP.

Enforcement: [tool and gate]. Example: bundle size check and lab performance run on every pull request; build fails above budget; field data reviewed weekly.

10. Accessibility

11. Internationalisation

12. Security

13. Testing strategy

14. Build and deployment

15. Observability

Privacy: [rules]. Example: no personal data in RUM payloads; IP addresses truncated; collection follows the consent settings; data retained 13 months.

16. Browser and device support

Review: browser list updated each quarter from analytics; build targets generated from the same list.

17. Decisions, risks and open questions

Standard and licence note

Based on common industry practice for frontend architecture. Core Web Vitals metrics and "good" thresholds are as published by Google on web.dev (LCP, INP and CLS; checked October 2026), and accessibility targets refer to W3C WCAG 2.2 level AA; verify both before each revision. Original text written for this collection; examples are illustrative. Template licence: MIT.