Three pillars of a robust frontend architecture.

1. Component structure

Principles:

• Composition over inheritance — <Card><Card.Header /><Card.Body /></Card> instead of class hierarchies.
• Props down, events up — parents pass data via props, children signal via callbacks. Avoid mutating parent state from children directly.
• Small focused components — one responsibility each. A 500-line component is a refactor signal.
• Layered architecture:

1. Primitives — design system: Button, Input, Modal. Generic, reusable, accessible.
2. Compositions — domain-specific: ProductCard, OrderForm. Built from primitives.
3. Pages / routes — page-level layouts, data wiring.
4. App shell — providers, error boundaries, global UI.

Common antipatterns:

• Prop drilling 5 layers deep → use context or move state.
• One giant component handling 6 concerns → split.
• Tight coupling between primitives and domain → primitives should be generic.

2. State management

State has several flavors, each with its own home:

Rules of thumb:

• Start local; lift only when proven shared.
• Server data is not application state — let the cache library own it.
• Avoid putting derived state in state — derive in render or use useMemo.
• Global stores should be small and split (theme separate from auth separate from preferences) — fewer re-renders.
• URL is state — searchable filters belong in query params, not Redux.

3. Performance

First paint:

• SSR/SSG for content pages → fast LCP + SEO.
• Code split per route → smaller initial JS.
• Preload critical resources (LCP image, fonts).
• Inline critical CSS, defer the rest.

In-app responsiveness (INP):

• Don't block the main thread with sync rendering of large lists — virtualize.
• Web workers for CPU-heavy tasks (parse, image manipulation).
• useTransition for non-urgent updates so input stays snappy.
• Debounce inputs that drive fetch / re-render.

Caching:

• Long max-age + immutable on hashed assets.
• React Query / RTKQ for API responses.
• Service worker for offline + custom strategies.
• Edge cache HTML where possible.

Bundle:

• Tree-shake; per-function imports.
• Audit dependencies quarterly; replace heavy with light (moment → dayjs).
• Set a budget in CI (size-limit, Lighthouse CI).

Render perf:

• Memoize on profiled-slow paths, not as a default.
• Stable references where children are memoized (useCallback, hoist).
• Lift state down to minimize re-render blast radius.

Measurement is non-negotiable

• RUM (web-vitals → analytics) for real users.
• Lighthouse CI for PR regressions.
• Custom marks for product-critical flows.
• Bundle analyzer quarterly.
• Segment by device, network, geo, route.

Anti-patterns to avoid

• Global state for local concerns → re-render cascades.
• Memoizing everything → overhead without payoff.
• Server data in Redux → reinventing caching badly.
• CSR for content pages → bad SEO + slow LCP.
• One mega-bundle → slow TTI.
• No CI perf guard → regressions accumulate.

Decision flow for a new feature

1. Render mode: who's the audience (public/auth)? SEO needed? → SSG / SSR / CSR.
2. State: where does data live (server / client / both)? Local or shared?
3. Components: pull from design system; compose domain UI on top.
4. Data: React Query for fetches; cache key, invalidation tags, mutations.
5. Perf budget: estimated JS added; preload/defer plan; LCP/INP target.
6. A11y: keyboard, screen reader, contrast.
7. Testing: unit for logic; integration for user flows; smoke E2E for critical paths.

Mental model

Architecture is constraints. Pick the rendering strategy, the state model, and the perf budget up front, and the rest of the system is much easier to keep coherent as it grows. Most pain in large frontends comes from not having made these decisions, not from making the wrong ones.