Frontend Roadmap, Tier 2: Intermediate Deep Notes

The mental models and edge cases that live at the intermediate tier — where most mid-level interviews actually live. Same approach as Part 1: not surface definitions, but the understanding that separates someone who has used these features from someone who actually gets them.

---

Accessibility

Accessibility is not a checklist you bolt on at the end. It is mostly a byproduct of using the right elements and managing focus, with ARIA as a patch for the gaps native HTML cannot cover.

Keyboard-First Navigation

Every interactive element must be reachable and operable by keyboard. Native elements (<button>, <a>, <input>) get this for free. A <div onclick> does not — which is the single biggest reason to use real elements.

• Tab order follows DOM order. CSS reordering (flex order, grid placement) can desync the visual order from the tab order, which is disorienting. Keep the DOM in logical order.
• tabindex semantics: 0 puts an element in the natural tab order, -1 makes it focusable only programmatically (not by tab). Any positive value hijacks the order and is an anti-pattern. Use 0 and -1 only.
• No keyboard traps. Focus must be able to leave any component. The exception is a modal, where you trap focus intentionally and release it on close.
• Skip links. A "skip to main content" link as the first focusable element lets keyboard users bypass repeated nav.

ARIA

ARIA is a set of role, state, and property attributes that describe semantics to assistive tech when native HTML cannot. The governing principle: do not use ARIA if a native element does the job. A <button> beats <div role="button" tabindex="0"> plus keyboard handlers every time.

The other rules: do not change native semantics (<button role="heading"> is wrong), all interactive ARIA controls must be keyboard usable, and do not put aria-hidden="true" on a focusable element.

The attributes that come up most:

• aria-label and aria-labelledby give an accessible name when there is no visible label (an icon-only button).
• aria-describedby adds supplementary description (error text, hints).
• aria-expanded, aria-selected, aria-checked communicate state for custom widgets.
• aria-live regions announce dynamic changes (polite waits for a pause, assertive interrupts). This is how you announce "3 results loaded" to a screen reader.

Bad ARIA is worse than no ARIA — it actively lies to assistive tech. Native first, ARIA only to fill genuine gaps.

Screen Readers

A screen reader narrates the page and lets the user navigate non-visually. It does not read your DOM directly — it reads the accessibility tree, a parallel structure the browser derives from the DOM, combining semantics, ARIA, and computed properties.

Users navigate by structure: jump between headings, landmarks (<nav>, <main>), links, and form controls. This is why heading hierarchy and landmarks are navigation infrastructure, not decoration.

The accessible name of each element is computed from a priority order (aria-labelledby, then aria-label, then label or content). If a button announces as "button" with no name, that computation found nothing.

You are authoring two interfaces at once: the visual one and the one in the accessibility tree. Semantic HTML keeps them in sync automatically.

Contrast

Contrast is the measurable ratio between text and background luminance. WCAG sets thresholds:

• AA: 4.5:1 for normal text, 3:1 for large text and UI components.
• AAA: 7:1 for normal text, 4.5:1 for large.

Two rules beyond the numbers: never rely on color alone to convey information (pair a red-only error state with an icon or text), and remember placeholder text and disabled states still need to be perceivable.

Focus Management

Focus management is what separates a technically accessible component from a usable one.

The situations that require manual management:

• Route changes in an SPA. A client-side navigation does not move focus. Move focus to the new page's heading or main region after navigation.
• Modals and dialogs. On open, move focus into the dialog and trap it there. On close, return focus to the element that opened it. Forgetting the return is the most common bug.
• Dynamically revealed content. When you expand a menu or reveal a panel, focus often needs to move to it.

Use :focus-visible rather than :focus for focus rings — it shows for keyboard users but not on mouse click. Never remove the outline without replacing it.

---

State Management

App Patterns

The most important modern distinction is server state versus client state.

• Client state is owned by the UI: is this dropdown open, what is in this input, which tab is active. It is synchronous and you are the source of truth.
• Server state is owned by a backend: fetched, possibly stale, shared across clients, needs caching and revalidation. Dedicated tools (React Query / TanStack Query, SWR) exist for this. Stuffing server data into Redux and managing loading flags by hand reinvents, badly, what those libraries do for you.

For client state, the patterns scale with scope:

• Local component state for anything one component owns. Default here.
• Lifted / shared state when siblings need it: lift to the nearest common parent.
• Context for low-frequency global values (theme, locale, current user). Context is a distribution mechanism, not a performance tool — it re-renders all consumers on change, so it is wrong for high-frequency updates.
• A store (Redux, Zustand, Jotai) for genuinely global, frequently updated, or complex state, ideally with selectors so components subscribe only to the slices they use.

Derive, do not duplicate. If a value can be computed from existing state, compute it rather than storing a second copy that can drift out of sync.

Predictable Component Architecture

Predictability comes from a few constraints that the Flux/Redux lineage formalized:

• Unidirectional data flow. Data flows down through props, events flow up through callbacks. Given a state, the UI is determined. Given an action, the next state is determined.
• Single source of truth. Each piece of state lives in exactly one place.
• Immutability. You produce new state rather than mutating the old, which makes change detection cheap (reference comparison) and time-travel debugging possible.
• Pure update logic. A reducer is (state, action) => newState with no side effects — same inputs, same output, testable and predictable.

State machines (XState and the general concept) take this further by making invalid states unrepresentable. Instead of three booleans (isLoading, isError, isSuccess) that can contradict each other, you model explicit states with explicit transitions. This is the answer to "how do you prevent impossible UI states."

---

Component Design

Composition

Composition means building complex UI by combining small, focused components. The principle: composition over configuration — instead of a single component with thirty props, expose smaller pieces that callers assemble.

The mechanisms (React vocabulary, general ideas):

• children is the simplest composition: a component wraps whatever you put inside it without knowing what it is.
• Compound components share implicit state through context (<Tabs>, <Tab>, <TabPanel>), giving a clean declarative API while the coordination is hidden.
• Render props and hooks share behavior rather than markup, letting the caller decide what to render.

The payoff is flexibility without prop explosion. The trap is over-decomposition: splitting things so finely that following the logic requires opening ten files.

Props and Inputs

Props are a component's inputs. The contract is data down, events up — a parent passes data through props, the child communicates back by calling callbacks the parent passed in. The child never reaches up to mutate the parent.

• Props are read-only from the child's perspective. Mutating a prop is a bug.
• Prop drilling — passing a prop through many intermediate layers that do not use it — is solved by context (for genuinely global values) or composition (pass the rendered element down instead of the data), not a global store reflexively.
• A clear prop interface (required vs optional, sensible defaults, TypeScript types) makes a component self-documenting.

Pure Components

A pure component renders the same output for the same props and state, with no side effects during render. Purity is what makes rendering safe to optimize.

• Memoization is only safe on pure components. React.memo, useMemo, and useCallback skip work by assuming same inputs produce same output.
• Side effects belong outside render. Data fetching, subscriptions, timers, and DOM manipulation go in effects (useEffect) or event handlers, never in the render body.
• Purity makes testing trivial. Same props in, assert the output, no setup.

Do not memoize everything — memoization has its own cost (comparison, memory), and most components are cheap to re-render. Reach for it when you have measured a real problem.

Separation of Concerns

Each unit should have one reason to change. The modern version of the container/presentational split is custom hooks for logic, components for markup. A useUserData hook owns the fetching and state, and the component consumes it and renders. Presentational components stay pure and reusable; logic is testable in isolation.

The honest caveat: do not dogmatically separate everything. Co-locating closely related logic and markup is often more readable than spreading it across files for the sake of a pattern.

---

Media Optimization

Images and media are usually the heaviest thing on a page. This is where real-world performance is won or lost.

Formats

• AVIF offers the best compression for photographic content, then WebP, then legacy JPEG.
• PNG for transparency or sharp edges (logos, screenshots), though WebP and AVIF also support transparency and compress better.
• SVG for anything vector — scales infinitely, tiny, styleable with CSS.
• Serve modern formats with fallback via <picture> and multiple <source> elements.

Responsive Images

Two distinct problems, two tools:

• Resolution switching (same image, different sizes) uses srcset and sizes on <img>. srcset lists candidate files with widths, sizes tells the browser how wide the image renders at various breakpoints, and the browser picks the smallest sharp file. Getting sizes right matters — a wrong value makes the browser pick a poorly sized image.
• Art direction (a different crop at different viewports) uses <picture> with <source media="...">.

Always set explicit width and height (or aspect-ratio) on images to reserve space and prevent layout shift.

Lazy Loading

• Native lazy loading with loading="lazy" on <img> and <iframe> — zero JS, browser-managed.
• IntersectionObserver for finer control or non-image content.

Do not lazy-load above-the-fold images, especially the LCP image. Lazy-loading your hero image delays the very metric you are trying to optimize. Eager-load (and use fetchpriority="high") for the hero image, lazy-load below the fold.

---

Browser Basics

Rendering Engines

The major engines: Blink (Chrome, Edge, most Chromium browsers), WebKit (Safari, and all iOS browsers), Gecko (Firefox).

The pipeline every performance topic refers back to:

1. Parse HTML into the DOM
2. Parse CSS into the CSSOM
3. Combine into the render tree (only visible elements, with computed styles)
4. Layout (reflow): compute geometry
5. Paint: fill in pixels, colors, text, borders
6. Composite: assemble layers, often on the GPU

Repaint vs Reflow

• Reflow (layout) is triggered by anything that changes geometry: width, height, position, font size, adding or removing elements. Most expensive — can cascade. A reflow is usually followed by a repaint and composite.
• Repaint is triggered by visual changes that do not affect layout: color, background, visibility, box-shadow. Cheaper than reflow.
• Composite-only changes are the cheapest. transform and opacity can be handled entirely by the GPU on an already-painted layer, skipping layout and paint.

Animate only transform and opacity for smooth 60fps animations.

Layout Thrashing

Layout thrashing forces the browser to compute layout repeatedly within a single frame by interleaving reads and writes to the DOM.

Certain reads (offsetHeight, getBoundingClientRect, scrollTop, getComputedStyle) need an up-to-date layout, so if you read after a write, the browser does a forced synchronous layout right then:

JSfile.js
1// Thrashing — each read forces layout
2for (const el of elements) {
3  const height = el.offsetHeight; // read forces layout
4  el.style.height = height * 2 + "px"; // write invalidates layout
5}

The fix is to batch all reads, then all writes:

JSfile.js
1// Read phase
2const heights = elements.map((el) => el.offsetHeight);
3// Write phase
4elements.forEach((el, i) => {
5  el.style.height = heights[i] * 2 + "px";
6});

Now layout happens once, not once per element.

---

Rendering Strategies

These describe where and when your HTML is generated:

• CSR (Client-Side Rendering). The server sends a near-empty HTML shell plus a JS bundle. The browser renders everything. Downsides: blank screen until the bundle loads (bad first paint, bad on slow devices), weak SEO. Upside: cheap servers, snappy subsequent navigation.
• SSR (Server-Side Rendering). The server renders full HTML per request. Users see content immediately and crawlers get real HTML. JS then hydrates the static HTML, attaching event listeners. Costs: server compute on every request, a gap where the page looks ready but is not yet interactive.
• SSG (Static Site Generation). HTML is rendered once at build time and served as static files. Fastest possible delivery, cheapest hosting, but content is frozen until the next build. Suits content that does not change per request (docs, marketing, blogs).
• The bridges. ISR (Incremental Static Regeneration) regenerates static pages in the background on a schedule. Streaming SSR sends HTML in chunks so the browser starts rendering before the full page is ready. React Server Components and the islands/partial hydration model (Astro, Qwik) send less JS by hydrating only the interactive parts.

There is no single best strategy. Pick per route based on whether content is static or dynamic, how important first paint and SEO are, and how much interactivity the page needs.

---

Fonts

Web fonts are a common, avoidable source of slow rendering and layout shift.

Loading Strategies

font-display controls what the browser shows while a web font downloads:

• swap: show fallback text immediately, swap to the web font when it loads. Causes FOUT (Flash Of Unstyled Text). Common default.
• block: hide text briefly waiting for the font. Causes FOIT (Flash Of Invisible Text). Usually worse for users.
• optional: use the web font only if it loads almost instantly (from cache), otherwise stick with the fallback. Best for performance and avoiding layout shift, at the cost of the web font sometimes not appearing on first visit.

Beyond font-display: preload critical fonts (<link rel="preload" as="font" crossorigin>) to fetch them early. Self-host rather than third-party CDN for control. Use WOFF2 (best compression). Subset fonts to only the characters you use. Variable fonts pack many weights into one file.

Layout Shift from Fonts

When text renders in a fallback font and swaps to a web font with different metrics (character widths, line height), the text reflows and everything below jumps, hurting CLS (Cumulative Layout Shift).

The modern fix is metric overrides on @font-face: size-adjust, ascent-override, descent-override, and line-gap-override tune the fallback font to occupy the same space as the web font, so the swap causes no reflow. Some frameworks (Next.js font optimization) do this automatically.

---

Testing Strategies

The point of a test suite is confidence per unit of cost. Different test types buy different confidence at different costs.

The Testing Spectrum

• Unit testing: tests a single function or component in isolation. Fast, numerous, pinpoints failures precisely. Best for pure logic: utilities, reducers, formatting. Tools: Jest, Vitest.
• Integration testing: tests several units working together — a component with its hooks, child components, and state, without mocking everything. This is where the highest-value front-end tests usually sit, because most real bugs live in the seams between units. Tools: React Testing Library, Vitest/Jest.
• Visual testing: captures rendered screenshots and diffs against baselines to catch unintended visual changes. Catches regressions that functional tests miss entirely. Tools: Chromatic, Percy, Playwright screenshots.
• End-to-end testing: drives the full application in a real browser as a user would. Highest confidence, highest cost — slow, brittle, hard to debug. Reserve for critical user journeys (signup, checkout). Tools: Playwright, Cypress.

Testability Practices

• Pure functions and clear inputs/outputs are trivially testable.
• Query by accessibility (roles, labels, text) rather than test IDs or class names — tests survive refactors and double as accessibility checks.
• Test behavior, not implementation. Assert what the user observes, not which internal method was called. This keeps suites from becoming a refactoring tax.

The testing trophy (Kent Dodds) argues integration tests give the best confidence-to-cost ratio for front-end work: a small base of static checks and unit tests, a large middle of integration tests, a thin top of E2E. The more current view for front-end.

---

Deployment Basics

Static Hosting

Static hosting serves pre-built files (HTML, CSS, JS, assets) directly, with no application server per request. Cheap, scales effortlessly (just files behind a CDN), the natural home for SPAs and statically generated sites. Platforms: Vercel, Netlify, Cloudflare Pages, S3 plus CloudFront. Anything dynamic comes from APIs, serverless functions, or edge functions layered on top.

Edge vs Origin

• Origin is your central server: full compute, full Node runtime, database access, but higher latency for distant users.
• Edge is code running close to users (CDN points of presence): very low latency, but a constrained runtime (limited APIs, short execution time, no persistent local state, often no direct DB connection). Used for redirects, auth checks, A/B routing, personalization, and request rewriting.

Push latency-sensitive, lightweight logic to the edge. Keep heavy or stateful work (database transactions, large computations) at the origin.

Cache Lifetimes and Invalidation

• Hashed, immutable assets (app.4f8a2c.js) get max-age=31536000, immutable — a year — because content never changes without the filename changing.
• HTML entry points get a short lifetime or no-cache so users pick up new asset references promptly.
• Atomic deploys deploy a complete new set of files and flip a pointer, so users never get a mix of old HTML and new assets during a rollout.
• CDN purge for resources you cannot rename (the HTML entry point) that must update immediately.
• Instant rollback — because each deploy is an immutable snapshot, rolling back is repointing to the previous snapshot.

Design so that invalidation is rare and cheap. Rename what you can, cache it forever, and keep only a thin always-fresh layer (the HTML) on top.