Forem: Ashish Kumar

Meta StyleX: Moving CSS-in-JS From Runtime to Build Time

Ashish Kumar — Thu, 09 Apr 2026 09:57:48 +0000

Meta ships StyleX as the styling layer behind very large surfaces, not because CSS is broken, but because classic runtime CSS-in-JS struggles to scale when huge component trees and variant matrices meet strict performance budgets.

The bet is simple to state and hard to execute: move styling work off the main thread’s long tail and into the bundler, so the browser mostly loads deterministic static CSS and applies atomic class names instead of synthesizing rules on every navigation and interaction.)

What goes wrong with runtime CSS-in-JS

Many CSS-in-JS libraries ask the runtime to:

Execute style functions or objects when components render.
Serialize declarations into strings or hashes.
Inject new rules into <style> tags or a stylesheet registry during hydration and updates.

That model is ergonomic for product teams: colocation, themes, dynamic props. It also carries costs:

JavaScript time on meaningful render paths for style resolution.
Larger bundles for runtime helpers.
Harder caching and deduplication when rules appear late or per app.
Inconsistent injection strategies across repos and micro-frontends.

At Meta-scale codebases, those margins compound.

How StyleX reframes the problem

StyleX keeps the authoring surface in JavaScript (objects analyzed by a compiler) but does not treat the browser as the first place styles materialize. A compiler plugin runs at build time and:

Statically reads style definitions tied to components.
Emits atomic classessmall, reusable rules so duplicates collapse globally.
Writes plain CSS files or chunks the document loads like any other static asset.

Atomic CSS is the mechanical trick that makes dedup cheap: many call sites reuse the same small declaration set instead of generating nearly identical rules at runtime.

The StyleX documentation is the source of truth for API details and constraints; this post stays at architecture level.

Runtime vs build time (one table)

Phase	Classic runtime CSS-in-JS	StyleX
Authoring	JS objects / tagged templates	JS objects (build-time analyzable)
When CSS exists	During render / effects	After compile, before deploy
Delivery	Injected rules + runtime	Static CSS files + class names
Dedup	Per session / heuristic	Global, at bundle time
Cost	JS + injection + recalculation	Mostly parse + apply in the CSS engine

Caveat: StyleX still ships a small runtime for conditional composition and debuggingthe win is vastly smaller than fully dynamic injection pipelines, not literally zero bytes of JS.

Why “compile time” is the headline

Frontend performance arguments often start with bundle size and end with main-thread contention. Moving styling to build time:

Shrinks what must execute after load for style synthesis.
Turns CSS into cacheable assets (CDN, HTTP cache, preload).
Aligns design systems with static analysis: lint rules, dead-code elimination, predictable class inventory.

The key idea is the one you sketched: push work left on the timelinefrom runtime discovery to build extractionso production pays less per paint.

Takeaway

StyleX is Meta’s bet that large teams still want CSS-in-JS ergonomics without paying continuous runtime tax. Compilers extract styles, atomic classes deduplicate output, and static CSS restores predictable behavior for enormous trees. Not every app needs that machinery; when injection cost shows up in profilers, compile-time styling is the lever they chose.

Originally published at renderlog.in · 4 min read

Follow Ashish on LinkedIn for more frontend performance deep dives.

DRM PiP Loophole: Why Picture-in-Picture Can Bypass DRM Black-Screen Protection

Ashish Kumar — Thu, 09 Apr 2026 08:57:48 +0000

In the last post on why JioHotstar goes black when you screen share, DRM keeps decrypted video off the capture surface most of the time. In practice, people sometimes notice a gap: after popping the same stream into Picture-in-Picture (PiP), a screen recorder may suddenly see pixels again.

This article explains why that can happen in the browser at a systems level, how Widevine L3 vs L1 fits in, and why no vendor promises this behavior forever. It is an implementation and policy balance, not a proof that protection is “unbreakable.”

Disclaimer: Streaming terms of service and copyright law still apply. The goal is to understand compositor and CDM behavior, not to advise circumventing rights management for redistribution.

What people observe (browser + PiP)

Reported steps: results vary by OS, GPU, browser build, codec path, and title tier:

Open a DRM-protected site such as JioHotstar in a desktop browser.
Start playback, then enter PiP via a built-in browser control or an extension that wraps <video> in a floating window.
Start screen capture.
Sometimes the PiP plane records normally while in-page video stayed black for the same session.

Treat this as empirical behavior, not a guaranteed recipe. Extensions can alter DOM and composition in non-standard ways; Chromium updates and studio policy changes invalidate write-ups constantly.

Why PiP can change what recorders see

Protected playback pairs decryption with a display path that is supposed to keep cleartext frames out of buffers that ordinary screen grabbers read. For in-tab or some fullscreen presentations, the compositor tags that layer as non-capturable on supported pipelineshardware-bounded video overlays on some GPUs, tighter hand-off to the OS capture stack, and related platform contracts.

Picture-in-Picture in Chromium-class browsers is not “the same widget moved.” The video is re-parented into a separate window or surface, and the browser runs a different code path for sizing, layers, and sometimes decode routing. When that path does not participate in the same protected-memory contract, or when playback is already on a Widevine L3-style software decode feeding ordinary GPU texturescapture tools may observe pixels again.

The hand-wavy version you hear in forums (“hardware fullscreen vs software PiP”) points at a real idea*different surfaces, different security tags*but oversimplifies how decode, scaling, and the OS compositor cooperate. The precise mechanics are proprietary and shift per release.

Mode	Typical goal	What capture often sees
In-page / some fullscreen paths	Keep cleartext off general capture	Black or masked video rectangle
PiP / alternate surface	Usable floating window, sane GPU work	Sometimes unprotected composition

That table is debugging intuition, not a spec.

Widevine L3 vs L1 (and why 4K stays stubborn)

Widevine levels roughly describe where keys and critical decrypt steps live:

L3: Software CDM; decode may run without the strongest TEE binding. Studios often cap resolution or bitrate for L3-only clients. That looser chain is where more capture quirks tend to appear.
L1: Hardware-backed; keys and decode touch secure silicon paths designed to resist exfiltration. 4K HDR titles frequently require L1, which is why PiP often stays black there even when 1080p briefly behaved differently on the same machine.

So the pattern “720p or 1080p slips through, 4K does not” matches industry expectations: stronger policy rides stronger hardware.

Security vs usability

PiP is a mainstream accessibility and multitasking feature. Shipping it without wrecking battery, latency, or OS integration forces tradeoffs. Whenever two composition paths exist (inline player vs out-of-tree PiP), security review has to show both respect studio rules. Gaps get patched when found; yesterday’s observation is not tomorrow’s interface contract.

That is why “DRM is not always unbreakable” is the accurate headline: not because protection is fake, but because systems are large, layered, and always moving.

Takeaway

Black video on capture depends on which decoder and compositor path feeds the pixels you see. PiP can switch that path enough that some L3 streams surface in capture-visible buffers again until vendors tighten the chain. Treat observations as time-stamped engineering facts, not stable exploits, and read your streamer’s terms before you press record.

Originally published at renderlog.in · 4 min read

Follow Ashish on LinkedIn for more frontend performance deep dives.

Core Web Vitals and Lighthouse: What the Scores Mean

Ashish Kumar — Thu, 09 Apr 2026 07:57:47 +0000

Related: Browser Rendering Pipeline: the underlying mechanics that most of these metrics are actually measuring.

LCP, CLS, INP, TTFB — the Core Web Vitals are precise technical measurements, not vague UX impressions. Each one captures a specific failure mode: slow resource loading, visual instability, interaction lag, server latency. Understanding what each metric measures at the spec level, and why Lighthouse lab scores diverge dramatically from real-user CrUX data, is what separates diagnosing actual regressions from chasing synthetic numbers.

What this covers: The technical definition and measurement mechanics of each Core Web Vital, why lab and field data diverge, why a perfect Lighthouse score coexists with terrible INP, and the exact debugging workflow for each metric.

LCP: Largest Contentful Paint

Largest Contentful Paint measures the time from when the page starts loading to when the largest content element in the viewport is rendered. "Largest" is determined by the element's rendered size in the viewport, not its intrinsic size, not its file size.

Which elements qualify

Not everything counts as an LCP candidate. The spec is specific:

Element type	Qualifies?
`<img>` elements	Yes
`<image>` inside SVG	Yes
`<video>` poster image	Yes
CSS `background-image`	Yes (as of recent spec updates)
Block-level elements with text	Yes
Inline elements	No
SVG shapes	No

The LCP candidate is updated as new elements render and become visible. If your page progressively reveals content (skeleton screen, then hero image, then content below the fold), the LCP timestamp updates each time a larger element renders. The final LCP value is the last update before the user first interacts with the page (scroll, click, or keypress stops LCP measurement).

Why images and text blocks differ

An image LCP depends on network fetch time the browser has to download the image before it can paint it. A text block LCP depends only on CSS and font availability, which is usually much faster. This is why a page with a large hero image almost always has worse LCP than a text-heavy landing page of equivalent visual weight.

The most common LCP problem I see: a hero image that loads fast on a Lighthouse test (simulated throttled connection, nearby CDN edge) but loads in 5+ seconds for users on mobile in Southeast Asia because the image isn't on a CDN node close to them, or worse, it's not being served with proper Cache-Control headers and gets fetched fresh every visit.

What invalidates LCP

LCP measurement stops at the first user interaction. This is intentional once a user starts scrolling or clicking, the "initial load" is considered complete. This means that if your largest element loads just after a user's first touch, it won't be counted as LCP, which can make synthetic measurements look better than real experience.

CLS: Cumulative Layout Shift

Cumulative Layout Shift measures visual instability: how much page content shifts around unexpectedly after it first renders. The score is a unitless number calculated from a formula that captures both how much of the viewport shifted and how far elements moved.

The formula

The score for each individual layout shift is:

layout shift score = impact fraction × distance fraction

Impact fraction is the fraction of the viewport that was affected by unstable elements during the shift. If an element occupies 50% of the viewport and moves, the impact fraction is at least 0.5.

Distance fraction is how far the element moved, as a fraction of the viewport's largest dimension. An element that moves 100px on a 800px viewport has a distance fraction of 0.125.

So an element that occupies half the screen and moves 20% of the viewport height gives a shift score of 0.5 × 0.2 = 0.1 right at the "needs improvement" boundary.

CLS is cumulative all individual layout shift scores are added together, with a windowing algorithm that groups shifts within 5 seconds of each other (session windows). The final CLS is the score of the worst session window.

What causes CLS

The most common offenders I've encountered:

Images without explicit dimensions. When the browser doesn't know the aspect ratio of an image before it loads, it allocates zero space for it. When the image arrives, everything below it jumps.

<!-- Bad: no dimensions, causes layout shift when image loads -->
<img src="/hero.jpg" alt="Hero">

<!-- Good: aspect ratio known upfront -->
<img src="/hero.jpg" alt="Hero" width="1200" height="630">

Dynamic content injection. A cookie banner, notification bar, or ad that gets inserted above existing content after the page loads will shift everything below it.

Web fonts causing FOUT. When a custom font loads and replaces the fallback font, if the two fonts have different metrics (line height, character width), text reflows. This is the "flash of unstyled text" causing layout shifts.

/* Mitigates font-swap shifts by matching fallback metrics */
@font-face {
  font-family: 'MyFont';
  src: url('/fonts/myfont.woff2') format('woff2');
  font-display: optional; /* Don't swap if font isn't ready, no shift */
}

Debugging CLS

The web-vitals library reports which elements shifted:


onCLS(metric => {
  metric.entries.forEach(entry => {
    console.log('Shifted elements:', entry.sources);
    // sources contains element references and rects
  });
});

Chrome DevTools also has a "Layout Shift Regions" overlay under Rendering → Layout Shift Regions. Blue flashes show exactly which elements are shifting. This makes diagnosis extremely fast once you know it exists.

INP: Interaction to Next Paint

Interaction to Next Paint replaced First Input Delay (FID) as a Core Web Vital in March 2024. Understanding why requires understanding what was wrong with FID.

Why FID was replaced

FID measured only the input delay component of the first interaction on a page: the time from when the user first clicks/taps/presses to when the browser starts processing the event. This had two problems:

It measured only the first interaction, which is often before heavy JavaScript has fully loaded. Many apps had good FID but terrible interactivity for subsequent clicks.
It measured only input delay, not the full interaction duration. Even if the browser started processing immediately, if the event handler took 400ms, FID would show 0ms and consider it a success.

How INP works

INP measures the full latency of all interactions throughout the page visit: click, tap, and keyboard events. For each interaction, it measures the time from user input to the browser's next paint after processing. The INP score is the worst interaction observed during the page visit (with some statistical smoothing: specifically, it's the 98th percentile if there are many interactions, to avoid outliers from accidental double-clicks).

An interaction's latency has three components:

interaction latency = input delay + processing time + presentation delay

Input delay: time from input event to when the browser starts running event handlers. Caused by long tasks blocking the main thread.
Processing time: how long the event handlers themselves take to run.
Presentation delay: time for the browser to render and paint after handlers complete.

INP targets: under 200ms is "good", 200–500ms "needs improvement", over 500ms is "poor."

What "next paint" means

The "next paint" in INP is the first frame the browser can render after the event has been fully processed. This means the browser has to complete layout and paint, not just run the JavaScript. A handler that does setState() in React and triggers a massive re-render contributes all of that re-render time to INP.

This is why INP is a much more honest signal than FID. A click that triggers a 600ms React reconciliation will show up as a 600ms INP, not a 0ms FID.

TTFB: Time to First Byte

Time to First Byte measures the time from when the browser starts the navigation request to when it receives the first byte of the response. It's a server + network metric.

What TTFB captures: server processing time (your Next.js SSR, your database query), DNS lookup, TCP connection, TLS handshake, and network transit.

What TTFB does not capture: anything that happens after the server starts streaming. A server that starts streaming HTML in 100ms but spends another 2 seconds building the response will look fast in TTFB but still deliver a slow page.

TTFB targets: under 800ms is "good." This sounds loose, but global users on mobile networks with high latency to your origin can easily exceed this even if your server responds in 10ms, purely from network round trips.

Lab vs field data: why they diverge

This is the thing that burned us. Lab data (Lighthouse, WebPageTest) runs in a controlled environment: a fixed device emulation, a fixed network speed, a server physically close to the testing infrastructure, and no real user behavior.

Field data comes from real users. Google's CrUX (Chrome User Experience Report) collects performance metrics from Chrome users who have opted in to usage statistics. PageSpeed Insights shows you CrUX data for your URL when it exists (it needs enough visits to have a statistically meaningful sample).

Dimension	Lab (Lighthouse)	Field (CrUX)
Device	Emulated mid-range Android	Real user devices
Network	Fixed throttled (4G simulation)	Real network conditions
Geography	One location	All user locations
User behavior	No interactions	Real clicks, scrolls, navigation
Latency to CDN	Often very low	Varies by user
Data freshness	Instant	28-day rolling window

The 28-day rolling window is particularly important. If you deployed a performance regression two weeks ago, it's baked into your CrUX data. If you fixed it yesterday, the improvement won't show up in Search Console for weeks.

The 75th percentile rule

Google doesn't use your average Core Web Vitals score to determine your Search Console assessment. They use the 75th percentile of field data: the value that 75% of your page loads achieve or better.

This matters enormously for INP. If 74% of your users have an INP under 200ms but 26% have an INP over 800ms (perhaps mobile users on slow devices running your heavy React app), your 75th percentile INP is over 200ms and you're not in the "good" zone even though most users are fine.

This is by design. Google wants the score to reflect the experience of the bottom quartile of your users, not the median or average.

Why a perfect Lighthouse score coexists with terrible INP

This was the most confusing part for our team to accept. Here's how it happens:

Lighthouse runs with no user interactions beyond the page load. INP requires interactions. Lighthouse doesn't measure INP from actual clicks because there are no clicks in a lab test it estimates it from Total Blocking Time (TBT) and long tasks during load. This estimate can be wildly off.

Our app had minimal load-time blocking: we code-split aggressively, deferred everything non-critical. Lighthouse loved it. But after hydration, when users actually clicked, our React event handlers triggered enormous re-renders. INP was 740ms in the field because we were doing 400ms of synchronous reconciliation on every button click. Lighthouse never saw this.

How to actually measure each metric

Don't rely only on Lighthouse. Use a layered approach:


// Report all Core Web Vitals to your analytics
function sendToAnalytics(metric) {
  const body = {
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good', 'needs-improvement', 'poor'
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
  };

  // Use sendBeacon so it fires even when page is unloading
  navigator.sendBeacon('/analytics', JSON.stringify(body));
}

onLCP(sendToAnalytics);
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onTTFB(sendToAnalytics);

You can also observe INP directly using PerformanceObserver if you want to capture interaction-level detail:

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 200) {
      // Capture slow interactions with the element that was clicked
      console.log('Slow interaction:', {
        duration: entry.duration,
        type: entry.name, // 'click', 'keydown', etc.
        target: entry.target,
        startTime: entry.startTime,
      });
    }
  }
});

observer.observe({ type: 'event', buffered: true, durationThreshold: 16 });

The tools and what they're good for:

Tool	Data type	Best for
Lighthouse (DevTools)	Lab	Quick feedback during development
PageSpeed Insights	Lab + Field	Checking real user CrUX data
Search Console Core Web Vitals	Field	28-day trend, page-group analysis
web-vitals JS library	Field (real users)	Sending to your own analytics
PerformanceObserver	Field (real users)	Detailed interaction diagnostics
WebPageTest	Lab (multi-location)	Geographic testing, filmstrip

Practical debugging workflow

For LCP problems: open the Network panel, filter by Img, find your hero image. Check: is it preloaded? Is it on a CDN? Is it in WebP/AVIF format? Then open the Performance panel and look for the LCP marker. It shows you exactly which element was measured and when it rendered relative to navigation start.

For CLS problems: enable Layout Shift Regions in DevTools → Rendering. Then use onCLS from web-vitals with the entries.sources to identify the specific elements. Add explicit width and height to all images. Use font-display: optional or size-adjusted fallback fonts.

For INP problems: record a Performance trace while clicking the button that feels slow. Look for long yellow JavaScript blocks in the main thread after your click. The call stack will show you exactly which function is taking 400ms. Then read the next post in this series on Long Tasks.

For TTFB problems: use WebPageTest's "Connection View" to see how much time is DNS, TCP, TLS, and server wait. If server wait is high, look at your SSR code, database queries, and edge caching configuration.

The scores in Search Console are the destination. The tools above are how you navigate there.

Originally published at renderlog.in · 13 min read

Follow Ashish on LinkedIn for more frontend performance deep dives.

Why React Error Boundaries Are Still Class Components

Ashish Kumar — Thu, 09 Apr 2026 06:57:46 +0000

If a child component throws during render, React can unmount the whole subtree beneath it. Related: React State Management Patterns—another area where the class-vs-hooks split shows up in practice.

Without containment, one bad leaf can leave users staring at a blank page—the informal “white screen of death.” React error boundaries exist to catch rendering errors and show a fallback UI instead of tearing down the entire app.

Most greenfield React code today is functional components and hooks. Error boundaries are the awkward exception: the supported API still lives on a class component. This post explains why, which lifecycle methods matter, what boundaries never catch, and a minimal pattern that keeps the rest of your tree function-based.

What an error boundary actually is

An error boundary is a React component that implements a specific error-handling contract with the reconciler. During a commit, if React hits an uncaught error in certain phases of the tree below the boundary, it can:

Capture the error instead of propagating it to the root.
Store enough state to know a failure happened.
Render a fallback (or delegate to a parent boundary).

The feature is deliberately narrow. It is not a general try/catch for all JavaScript failures in your component tree—more on that below.

Why error boundaries are class components today

React’s public API for this behavior is still expressed in terms of class lifecycle hooks that do not have first-class hook equivalents in React’s stable core:

Lifecycle	Role
`static getDerivedStateFromError(error)`	Runs during render when a descendant throws. Returns an object to update state from the error (for example, `{ hasError: true }`) so the next render can branch to fallback UI.
`componentDidCatch(error, info)`	Runs after a commit. Use it for side effects: logging to an APM, `console.error`, reporting `componentStack` from `info`, avoiding duplicate reports, etc.

Functional components cannot declare static methods or these class-only lifecycle entry points through useEffect/useState alone, because the reconciler invokes these hooks at specific times in the error recovery path—not as ordinary “effects after paint.” Until React exposes a blessed hook or component primitive with the same semantics, the documented, stable way to author a boundary is a class.

That is the entire answer to “why are React error boundaries only class components?” It is not ideology; it is API surface. You can still wrap function components—your app stays hooks-first; one small class (or a library wrapper) sits at the edge of a subtree.

Minimal class boundary (copy-paste pattern)


type Props = {
  fallback: ReactNode;
  children: ReactNode;
  onError?: (error: Error, info: ErrorInfo) => void;
};

type State = { error: Error | null };

  state: State = { error: null };

  static getDerivedStateFromError(error: Error): State {
    return { error };
  }

  componentDidCatch(error: Error, info: ErrorInfo) {
    this.props.onError?.(error, info);
  }

  render() {
    if (this.state.error) return this.props.fallback;
    return this.props.children;
  }
}

Usage around functional routes, widgets, or data-heavy subtrees:

Production tip: pair componentDidCatch with your logging pipeline (Sentry, Datadog, OpenTelemetry, etc.) and include info.componentStack—it shortens time-to-root-cause dramatically.

What error boundaries do not catch

Treat this as a hard mental split, not a vague “maybe.” Do not assume a boundary shields you from:

Event handler errors wrap synchronous handler code in try/catch, or handle promise rejections from async handlers yourself.
Asynchronous errors set after render (setTimeout, many Promise chains, fetch callbacks) unless they happen to throw during a phase React is already turning into a render error boundary path.
Errors in the boundary itself a broken fallback or a throw inside getDerivedStateFromError does not magically self-heal.

The React docs stress this split: error boundaries are for render-time failures in the tree below them, not a substitute for normal defensive coding in IO and events.

Strategy: where to place boundaries

Think in blast-radius units:

Route-level one boundary per major page or lazy-loaded chunk so a bad panel does not blank the shell.
Feature-level isolate experimental or data-heavy widgets (charts, rich text, third-party embeds).
Don’t over-nest too many stacked boundaries make UX and logging noisier; align with your design system’s fallback patterns.

Libraries such as react-error-boundary wrap the same lifecycle contract behind a declarative API; under the hood the mechanics are still “class boundary semantics,” not a different reconciler feature.

Mental model checklist

Need to stop a render-time exception from killing the app? Add a boundary above the risky subtree.
Need to catch a click-handler or failed fetch? Use try/catch, Result types, or await in an async event path—not a boundary alone.
Want hooks everywhere else? Keep using them; one class file (or library) at the edge is normal in modern React codebases.

If React adds a first-party hook or primitive with the same catch-and-recover semantics as class boundaries, you can adopt it incrementally behind the same placement ideas above. As of today, getDerivedStateFromError and componentDidCatch are still the supported surface for that behavior in app code.

Originally published at renderlog.in · 5 min read

Follow Ashish on LinkedIn for more frontend performance deep dives.

React State Management Compared: Redux vs Zustand vs Jotai vs Valtio

Ashish Kumar — Thu, 09 Apr 2026 05:57:46 +0000

Most teams pick React state libraries from npm trends or conference hype. Also in this series: Why React Error Boundaries Are Class Components: one of the few React APIs that still requires a class.

That works until re-renders spike, boilerplate spreads, or onboarding slows new hires. The useful split is not “which logo is popular” but which architecture you are buying: a centralized store, an atomic graph, or a proxy snapshot model.

This post compares Redux and Zustand (centralized), Jotai (atomic), and Valtio (proxy)what each optimizes for, where it hurts, and how to choose without regret.

Centralized stores: Redux and Zustand

Centralized state means a single logical store (or a small number of stores) holding domain data. Components select slices and dispatch updates through a defined path. The mental model matches the diagram above: global state sits above tabs, routes, and feature panels so switching UI does not orphan data.

Redux

Redux is the explicit, event-sourced style: actions → reducers → predictable state. Ecosystem depth (Redux Toolkit, RTK Query, DevTools, middleware) is the main reason enterprises still standardize on it.

Pros	Cons
Enforced data flow is easy to review in PRs and teach in onboarding docs.	Ceremony without RTK; even with RTK, new devs must learn slices, thunks, or listeners.
Time-travel debugging and structured logs map well to compliance-heavy environments.	Boilerplate pressure returns if you avoid conventions and RTK patterns.
Large-team scalability when you invest in patterns and codegen.	Selectors and memoization still require discipline to avoid broad re-renders.

Zustand

Zustand keeps a minimal store API: subscribe, getState, setStateoften without Providers. It is centralized like Redux but defaults to less structure, which speeds small and mid-size apps.

Pros	Cons
Tiny surface area; hook-based reads feel native in React.	Conventions are yourswithout guardrails, stores can become grab-bags.
Flexible middleware (persist, immer, devtools) without a framework lock-in story.	Very large teams may miss Redux’s uniform action/reducer story for cross-repo training.
Strong fit when you want one obvious place for cross-cutting client state.	Deep async flows still need clear patterns (no built-in “official” saga equivalent).

When centralized wins: domain rules span many screens, several engineers touch the same data, you need auditable updates, or hydration/persistence is first-class. Redux leans enterprise process and tooling; Zustand leans velocity and low ceremony.

Atomic state: Jotai

Jotai models state as a graph of atomssmall units of state with explicit dependencies. Derived data is atoms that read other atoms. React subscribes per atom, so components tend to re-render only when their atoms change.

Pros	Cons
Fine-grained subscriptions reduce unnecessary renders without hand-tuned selectors everywhere.	Mental model shift: thinking in graphs differs from “one big store object.”
Colocates derived state as composition of atomssimilar to graphs in Recoil’s family.	Large imperative workflows that touch many atoms at once need discipline.
Strong for UI-local and shared state mixed in one model.	Team documentation must explain atom layering to avoid spaghetti dependencies.

When atomic wins: performance-sensitive UIs where isolate rerenders matter, dashboards with many independent dimensions, or when you prefer declarative dependency wiring over manual memoized selectors.

Proxy reactivity: Valtio

Valtio exposes mutable-looking plain objects that are tracked with proxies. You mutate properties; the library resolves snapshots and subscriptions for React. It feels closest to “just update my JS object.”

Pros	Cons
Low cognitive overhead if your team already thinks in mutable domain models.	Proxy mental model: debugging requires understanding what is tracked vs plain objects.
Excellent for simple reactive objects and rapid prototyping.	Some patterns (nested structures, cross-cutting immutability expectations) need explicit docs on your team.
Small API; pairs well with TypeScript when patterns are stable.	May clash with codebases that treat deep immutability as a strict rule everywhere.

When proxy wins: product and UX iteration speed matter more than formal action logs, or you want colocated mutable models with minimal glue code.

Architecture comparison at a glance

Dimension	Centralized (Redux / Zustand)	Atomic (Jotai)	Proxy (Valtio)
Primary lever	One (or few) stores, explicit updates	Per-atom subscriptions	Mutable proxy + snapshots
Team scale	Strong for large teams with conventions	Strong when render cost is the bottleneck	Strong for small teams and fast iteration
Re-render story	Relies on selectors, `shallow`, structure	Built-in granularity via atoms	Property-level tracking
Learning curve	Redux steeper; Zustand gentle	New graph model	Familiar JS, proxy caveats
Debugging	Redux tooling gold standard	Atom dependency graphs	Snapshot / proxy awareness

Decision checklist

Do multiple features read and write the same domain entities? Prefer centralized (Redux or Zustand) and document update paths.
Is unnecessary re-rendering your main pain? Prototype Jotai or tighten selectors in your current store before swapping everything.
Do you want the least abstraction over plain objects? Try Valtio in strict boundaries (one feature slice) and measure.
Is auditability or time-travel non-negotiable? Redux DevTools and explicit actions still earn their keep.

Popularity is a lagging indicator; architecture fit is leading. Match the library to how your team reasons about state, not only to download countsand reserve the right to mix local useState, React Query for server state, and one of these patterns for client-owned complexity.

Originally published at renderlog.in · 5 min read

Follow Ashish on LinkedIn for more frontend performance deep dives.

How Google Maps Predicts Traffic in Real Time: Live Data and ETA Explained

Ashish Kumar — Thu, 09 Apr 2026 04:57:45 +0000

Open Google Maps during rush hour and a stretch of road turns red before you feel the brake lights stack up. That is not luck. It is telemetry, graph algorithms, historical baselines, and human reports fused into a near–real-time pipeline serving billions of clients.

Google's public documentation stays high level; the full recipe is proprietary. The systems shape is well understood in the industry though: phones behave like moving probes, the road network is a weighted graph, and anomaly detection against historical curves is what turns "slow" into "worse than usual": the signal that routing should penalize an edge and suggest an alternative.

Crowdsourced probes: speed and direction at scale

With location services active, devices can contribute aggregated, anonymized telemetry: speed and heading along map-matched road geometry. No engineering team publishes the exact threshold ("fifty phones at 5 km/h ⇒ red"). The principle is sufficient: on a given road segment, if many independent devices report low speeds relative to free flow, the live speed layer for that polyline drops, congestion color escalates, and ETA models consume the update.

Latency targets are tight because routing products compete on freshness: stale traffic is worse than noisy traffic for user trust.

Privacy is handled through aggregation, sampling, retention limits, and noise. The product promise is patterns, not surveillance records of individual drivers.

The road network as a graph

Map vendors treat the digitized road network as a graph: intersections and merge points are nodes; directed edges carry length, speed limit, road class, turn restrictions, and time-dependent costs derived from live telemetry.

When one edge jams, shortest-path queries care about more than that edge alone: downstream capacity, spillback, turn pockets, and alternative arterials create ripple effects. Production systems maintain live travel times per segment and periodically reoptimize routes for active users. The "AI" label in marketing usually refers to ML-weighted fusion of sensor inputs; hand-tuned rules still exist in the mix.

Historical curves: "slow" versus "wrong slow"

Monday 9:00 AM is supposed to be slow on commuter corridors. Maps keeps long-horizon baselines: historical speed distributions by time-of-day and day-of-week.

When the current median speed on a segment diverges from baseline more than noise explains, the system flags an exception: a crash, closure, weather event, or demand spike. That is the moment rerouting nudges users onto parallel paths before the jam propagates. Cold starts (new roads) and holidays are harder; less history means wider confidence intervals.

Waze and human-in-the-loop incidents

After Google acquired Waze, user-reported incidents (stalled vehicle, object on road, police presence) became an additional sensor layer. Reports are cheap to create and noisy; fusion with GPS speed collapse and duplicate detection is how a report becomes a trusted incident polygon within seconds. Confirmation from independent probes reduces false positives that would erode trust.

The comparison to fixed traffic cameras is about sensor latency, not competence: phones outnumber fixed cameras on most road networks.

Scale, latency, and honest caveats

Moving probe streams through ingest, map matching, aggregation, ML scoring, and tile updates for clients is a distributed systems problem. Sub-minute freshness on busy grids is the product standard users feel.

Coverage is thinner on rural roads and sparse at off-peak hours; congestion colors are noisier there. Any telemetry stack can bias toward device-rich demographics and routes favored by rideshare drivers. The specific models and thresholds are trade secrets. This post reflects systems intuition, not a leaked design doc.

Takeaway

Google Maps often "sees" congestion before you because many devices are already measuring it, the road mesh is a live graph, history separates routine slow from true incidents, and Waze-style reports accelerate verification. The engineering advantage is probe density, graph data, and pipelines built for low latency at continental scale, not a single clever model.

Originally published at renderlog.in · 4 min read

Follow Ashish on LinkedIn for more frontend performance deep dives.

The 16.6ms Frame Budget: Why Fast Loads Still Feel Slow

Ashish Kumar — Thu, 09 Apr 2026 03:38:50 +0000

Related: Why CSS Never Matches Figma which is another place where the browser's rendering pipeline creates unexpected gaps.

At 60Hz, the browser has ~16.67ms per frame for all JavaScript execution, style calculation, layout, paint, and compositing — combined. This is not a soft guideline. It is a hard physical constraint set by the display's refresh schedule. Miss the deadline and the display repeats the previous frame. Miss it consistently and users perceive jank regardless of what Lighthouse reports.

What this covers: Where the 16.6ms number comes from, what work must fit inside one frame, why good Lighthouse scores coexist with bad runtime performance, and why high-frequency data UIs are the most unforgiving stress test for this budget.

Where 16.6 ms comes from

A 60 Hz panel asks for 60 frames per second. One second divided by 60 is ≈16.67 ms per frameoften rounded to 16.6 ms in conversation.

That number is not a browser setting; it is physics of the refresh schedule. If the main thread and compositor together cannot produce a new frame in time, the display repeats the previous one: you have dropped a frame. Enough drops in a row read as jank, stutter, or “laggy” UI, even when First Contentful Paint and Time to Interactive look fine on a cold load.

What must fit inside one frame

On the main thread, a heavy tick might include:

JavaScript: event handlers, your React reconciler, data transforms, garbage collection spikes.
Style: matching selectors and computing layout-affecting properties.
Layout: calculating geometry when something actually moves or sizes (cheap property changes can skip this; wide invalidations cannot).
Paint: rasterizing layers; some effects force more work than others.

The compositor then assembles layers for the GPU. Work that stays compositor-only (for example, many transform and opacity animations) is how sites keep motion smoothbut parsing a giant JSON tick, rebuilding a chart, or mounting hundreds of rows still tends to touch JS + layout + paint first.

Takeaway: the 16.6 ms budget is a ceiling for all of that, not “JavaScript time” alone.

Why good Lighthouse scores can hide the problem

Lighthouse and similar audits focus heavily on load and lab conditions: bundle size, critical path, caching, LCP, CLS in synthetic runs. They are invaluable for shipping fast first paint.

They are easy to misread as “performance is solved” because runtime pain shows up when:

WebSocket or SSE pushes dozens of updates per second.
Each update triggers state changes that re-render large subtrees.
Charts reconcile thousands of points on the main thread.
The user scrolls or zooms while new ticks land.

That is exactly the shape of a trading or operations dashboard: high-frequency mutations plus dense UI. Load metrics stay green; frame time spikes in production.

Real-time data and the main thread

When every tick runs through React setState (or store writes that fan out to hooks), you pay pure JS and often layout. If a single burst exceeds ~16.6 ms, you miss the next v-sync. Miss often enough and users perceive drag even if CPU usage “looks low” averaged over a second.

Patterns that help stay inside the budget (none are magic; all need measurement):

Idea	Role
Throttle / batch updates	Collapse 50 ticks into one RAF-aligned commit per frame.
Isolate subscriptions	Keep fine-grained listeners so unrelated panels do not re-render.
Virtualize lists	Render viewport rows only for order books and tape-style feeds.
Move work off-thread	Web Workers or WASM for parsing and aggregation; ship snapshots to UI.
Prefer cheap motion	Animate `transform`/`opacity`; avoid layout-thrashing read/write loops.

Profiling beats guessing: Performance panel in Chrome, React Profiler, and Long Task marks tell you whether you are fighting JS, layout, or paint.

Mental model checklist

60 Hz ⇒ ~16.6 ms per opportunity to show a new frame; there is no secret “extra time.”
Fast load ≠ smooth runtime; streaming UIs punish per-tick cost on the main thread.
Dashboards and trading surfaces are stress tests Optimize them like games: budget, batch, measure.

Runtime performance is not a different hobby from web performance; it is the same discipline applied after the first paint. Once you internalize the frame budget, “why does this feel slow?” stops being mysterious and becomes a timeline question.

Originally published at renderlog.in · 5 min read

Follow Ashish on LinkedIn for more frontend performance deep dives.

Why CSS Never Matches Figma: Browser vs Canvas Pipelines

Ashish Kumar — Thu, 09 Apr 2026 03:37:50 +0000

Open any Figma file. Look at those perfectly smooth corners, the glass blur with real depth, the stroke that sits cleanly inside the element without touching the spacing.

Now build it in CSS.

It’s close. But something is always slightly off. The corners feel harder. The blur is flat. The border is eating into your padding.

You’ve probably blamed yourself: wrong tool version, wrong browser, not enough CSS tricks. The real reason is simpler: Figma and your browser are two different rendering engines running different math. Some things Figma draws don’t exist in CSS yet. Some things look the same but work differently under the hood.

This post breaks down how each engine works, where they diverge, and what that means for every design-to-code handoff.

How Chrome turns CSS into pixels

When you write CSS and open it in Chrome, six things happen in sequence for every frame and every element.

1. Parse

Chrome reads your HTML and builds the DOM (a tree of every element). In parallel it reads CSS and builds the CSSOM (a tree of every style rule). Those two trees are combined into the render tree.

2. Style

Chrome walks every element and decides which CSS rules apply. It resolves specificity, inheritance, and the cascade. Every node ends up with computed styles; each property has an exact value.

3. Layout

Chrome figures out where each element sits and how much space it needs. This step is expensive. Change one width and Chrome may recalculate layout for a large subtree. That’s what people mean by reflow, and why it hurts performance.

4. Paint

Chrome records drawing instructions, not pixels yet: things like “fill this rectangle,” “draw this text run.” Order follows the CSS painting spec.

5. Composite

The page is split into layers and sent to the GPU. The GPU composites layers into the bitmap you see. Properties like transform and opacity can often skip heavy work earlier in the pipeline. That’s why they’re cheap to animate.

The crucial idea: every CSS property is implemented with math (fixed by web standards) (W3C / CSS WG). You write border-radius: 40px, and you get a circular arc, because the spec says so. You write backdrop-filter: blur(10px), and you get a Gaussian blur on the spec’s terms. You can’t extend that math from your stylesheet; browsers implement one interoperable definition.

How Figma draws outside the DOM

Figma made a different bet when it launched in 2015: the canvas is not HTML and CSS.

C++ / Rust core

Figma maintains its own document model and scene graph: a tree of layers, effects, and constraints. When you nudge a frame or tweak corner smoothing, that graph updates in a compiled native/WASM layer, not in ad-hoc DOM updates from your UI JavaScript.

WebAssembly

The renderer runs in the browser at near-native speed. That’s how huge files with thousands of layers stay usable. The heavy work isn’t “the browser laying out divs,” it’s Figma’s code inside WASM.

WebGL / WebGPU

Figma walks its scene graph and issues raw GPU draw calls. Effects are often custom shaders (GLSL / WGSL): the math for corner smoothing, glass, blend modes, etc. is whatever Figma ships, not “whatever all browsers agreed to implement.”

Screen

The GPU composites and displays the canvas. Chrome is not rendering Figma’s pixels. It’s hosting a surface where Figma’s engine draws.

Bottom line: Figma can ship a new visual primitive by writing shader + scene-graph logic and releasing. No multi-year standards track. No waiting for Safari and Firefox to match. That freedom is exactly why mocks can outpace CSS.

Where design-to-code breaks: property by property

Once you see both pipelines, mismatches stop feeling mysterious.

`cornerSmoothing` (Figma) vs `border-radius`

Figma can use a superellipse-style curve, where curvature ramps smoothly into the corner instead of a hard hand-off. CSS border-radius uses circular arcs; you can get a subtle “kink” at the join. (Apple’s app-icon shape (is the famous real-world parallel).) There is W3C interest (corner-shape, etc.), but nothing you can rely on in production everywhere yet.

Workaround: SVG squircle paths, clip-path, or tools like figma-squircle, and accept some authoring cost.

Stroke alignment vs `border`

In Figma, inside / center / outside stroke keeps geometry predictable relative to the frame. With box-sizing: border-box, a CSS border lives inside the box you sized. It isn’t a free-floating “outside stroke” the same way. A 2px inside stroke in Figma is not identical to border: 2px solid.

Workaround: box-shadow / inset rings, extra wrappers, or explicit dimensions that include the border math you need.

Glass vs `backdrop-filter`

Figma glass is often a physically inspired stack (refraction, highlights, depth cues) implemented in shaders. CSS backdrop-filter: blur() is a Gaussian-style blur (and friends) on underlying pixels: powerful, but not the same light model.

Workaround: layered backdrop-filter, shadows, gradients, and aim for convincing, not pixel-perfect.

Multiple fills

Figma stacks many fills on one layer, each with opacity and blend mode. In CSS you mostly compose background layers, with background-color at the bottom of that stack, so the model is flatter.

Workaround: extra DOM (::before, ::after, stacked children) to fake additional “fills.”

Negative gap (Auto Layout) vs CSS `gap`

Figma Auto Layout can use negative gap for deliberate overlap (avatars, stacks). CSS gap cannot be negative.

Workaround: negative margins on children. That works, but you’re outside the same mental model as Auto Layout; test breakpoints carefully.

Plus Lighter vs `mix-blend-mode`

Figma’s Plus Lighter is not a 1:1 alias of a single CSS mix-blend-mode. The compositing math is Figma’s.

Workaround: approximate with something like mix-blend-mode: screen and tune opacity by eye.

Why the gap is structural (specs vs product shaders)

CSS is a shared contract. New visual power means proposals, implementer consensus, shipping in multiple engines, and years of iteration. That friction is why your stylesheet behaves predictably on phones, kiosks, and four different browsers.

Figma is a product renderer. New visuals ship when the team writes the shader and merges the release.

Neither model is “wrong.” They’re optimized for different goals: interoperability vs. design-tool expressiveness. Pretending they’re equivalent on every frame is where handoff pain comes from.

Handoff checklist: sanity-check the file before CSS

The gap isn’t something you “fix” with more clever CSS alone. It’s architectural. It is manageable.

Before you write markup, skim the file for:

Corner smoothing above 0%? Plan for squircle/clip-path workarounds, not vanilla border-radius alone.
Outside / center stroke? Don’t assume border is a drop-in.
Glass / heavy blur stacks? Expect backdrop-filter to be a rough match, not a clone.
Multiple fills on one layer? Plan extra elements.
Negative Auto Layout gap? Plan a margin-based layout, not pure gap.

Have the conversation early: not “impossible,” but “native on the web / workaround, or intentional approximation.” That clarity saves hours on every project.

Figma features with no production CSS twin (today)

cornerSmoothing · stroke alignment models beyond border · full glassFill fidelity · unconstrained multipleFills on one node · negativeGap in flex/grid · some advanced layerBlur looks · plusLighterBlend

Some of this is moving (corner-shape, Houdini in Chrome in places). The gap is real now and will shrink slowly, and it’s worth tracking if you live in design systems.

Engineer’s breakdown of two pipelines, so your next build starts with the right expectations, not the wrong guilt.

Originally published at renderlog.in · 7 min read

Follow Ashish on LinkedIn for more frontend performance deep dives.

DRM Explained: Why JioHotstar Goes Black When You Screen Share

Ashish Kumar — Wed, 08 Apr 2026 17:54:08 +0000

If you try to screen share or record a JioHotstar cricket stream, the video often goes pitch black, while playback controls, the app chrome, and system navigation still look normal. That split is the giveaway: the wall is not around the whole phone. It sits between your capture API and the decrypted picture.

This post unpacks Digital Rights Management (DRM) as an engineering system: Encrypted Media Extensions (EME) on the web, Content Decryption Modules (CDMs) such as Widevine, and hardware-backed paths on modern phones (Trusted Execution Environment, secure video output).

Also see: PiP Loophole: Why DRM Is Not Always Unbreakable, when Picture-in-Picture sometimes bypasses this protection.

What you are actually seeing

Screen capture reads from the composition path the OS exposes to recorders and mirroring tools. DRM-protected premium video is composited through a protected surface: the decoder and GPU cooperate so that plaintext frames either never land in CPU-accessible buffers, or are flagged so capture returns empty, black, or static for that layer only.

That is why screenshots sometimes show UI perfectly while the video rectangle is blank, exactly the behavior you see in the split image above.

Web playback: Encrypted Media Extensions (EME)

In the browser, EME is the W3C API surface that connects JavaScript to a CDM. Your app:

Receives encrypted media (often CENC or vendor-specific packaging).
Uses EME to create MediaKeys sessions and exchange license data with a license server.
Never receives decrypted samples as ordinary ArrayBuffer objects in page memory.

The browser negotiates with the CDM, a sandboxed or vendor component, depending on OS and Widevine level. Decryption and key material stay on the CDM side of the boundary; the page just drives playback. Your JavaScript code never "gets" raw frames in a way that can be copied to canvas or piped to a recorder without violating the security model.

Native apps like JioHotstar use the same conceptual split (Android MediaDrm and Widevine-class stacks), not the DOM API literally, but the same job: keys and decryption happen outside normal app memory.

Content Decryption Modules and Widevine levels

A CDM (for example Google Widevine) implements license handling and decryption policy. Implementations are graded: conceptually L3 software vs L1 hardware on many devices:

L3: Software CDM. Decode runs without strong TEE binding. Studios often cap resolution at 720p or 1080p for L3-only clients.
L1: Hardware-backed. Keys and decode touch secure silicon paths designed to resist exfiltration. 4K HDR titles typically require L1.

That stack exists because broadcast and studio deals are priced on windowing and anti-redistribution. The client is treated as hostile; DRM is the contractual and technical compromise that lets live sports and premium content stream on commodity hardware at all.

Phones, TEE, and the black rectangle in screen recorders

On many modern phones, a high Widevine level ties decoding and output to a trusted path: a TEE or similar isolation holds key operations so the main OS cannot read protected plane pixels like a normal texture. When Screen Record requests frame data, the compositor omits or masks that layer. You see black, while unprotected UI layers (status bar, player controls) composite normally.

This is not a bug in your screen recorder. It is working as designed for rights-managed content.

Honest limits

DRM raises the bar for casual HD ripping from client devices. It does not make piracy mathematically impossible; attacks shift to HDMI re-encode, CAM rips, leaks from insider sources, etc.
Policies differ by platform, title, and studio rules. Some tiers allow limited mirroring on approved receivers.
Fair use and accessibility debates are legal and product questions, not something a pipeline diagram settles.

Takeaway

JioHotstar and similar services go black on capture because decrypted video is routed through a DRM-controlled path (EME/CDM on the web, MediaDrm/Widevine-class stacks on device) so the OS-level share or record surface never receives those pixels. Controls stay visible because they are ordinary UI, not the protected media plane.

Understanding that split turns a confusing UX moment into a predictable security boundary: the invisible wall between licensed playback and uncontrolled redistribution.

Originally published at renderlog.in · 4 min read

Follow Ashish on LinkedIn for more frontend performance deep dives.

Browser Rendering Pipeline: How JS and CSS Become Pixels

Ashish Kumar — Wed, 08 Apr 2026 17:53:07 +0000

Related: The 16.6ms Frame Budget, the wall clock deadline that every stage in this pipeline must fit inside.

Every rendered frame runs through a fixed pipeline: Parse → Style → Layout → Paint → Composite. Understanding which stage runs on which thread, what triggers each stage to re-run, and which stages can be skipped entirely is the mechanical foundation behind every browser performance optimization.

What this covers: The full pipeline stage by stage, how the compositor thread separates from the main thread, what "jank" physically is at the hardware level, and how to read the DevTools flame chart to pinpoint which stage is your bottleneck.

The pipeline, stage by stage

When the browser receives HTML bytes, it doesn't hand them to a rendering function and wait. It runs a multi-stage pipeline, and each stage has a different cost profile and different triggers for re-running. Understanding the stages is the prerequisite for understanding why your specific change makes something slow.

Parse HTML → DOM tree

The HTML parser converts raw bytes into a tree of DOM nodes. The parser is incremental; it doesn't wait for the full document. As it encounters <script> tags it may pause, execute the script synchronously (if not async or defer), then resume.

The DOM is not the visual page. It's a tree of objects representing content and structure. Style is a separate concern.

Fetch CSS → CSSOM

While the HTML parser runs, any <link rel="stylesheet"> causes the browser to fetch the CSS. The CSSOM (CSS Object Model) is built in parallel: a tree of rules, specificity-resolved, cascade-computed. The CSSOM blocks rendering the browser will not paint anything until it has enough CSS to avoid a flash of unstyled content.

This is why render-blocking CSS matters for First Contentful Paint: the larger and more complex your CSS, the later the browser can actually start putting pixels on screen.

Merge → Render Tree

The render tree is a merger of the DOM and CSSOM. Crucially, it contains only visible nodes. Elements with display: none are absent. Elements with visibility: hidden are present (they take up space). Pseudo-elements like ::before are included even though they don't exist in the DOM.

This step is relatively cheap, but it happens whenever structural DOM or CSS changes occur.

Layout (Reflow)

Layout (also called reflow) is where the browser figures out the geometry of every element: position, width, height, margin, how text wraps. This is expensive because the layout of one element can cascade. Changing the width of a parent can reflow every child.

Layout is the most painful stage to trigger unnecessarily. It runs on the main thread and can take tens of milliseconds on a complex page.

Paint

Paint is where the browser fills in the actual pixels for each element's visual appearance: colors, borders, shadows, text. Paint produces display lists a set of drawing instructions that are then handed to the GPU.

Not all property changes trigger paint. Properties like transform and opacity can be handled without repainting.

Composite

Compositing is where the browser takes individual layers (more on those below) and combines them into the final image. This step happens on the compositor thread, separate from the main thread. This is the key insight behind why transform and opacity animations are "free": they only require compositing, not layout or paint.

Main thread vs compositor thread vs GPU process

Chrome has a multi-process architecture. The rendering work is split across at least three distinct actors.

Thread/Process	Responsibility
Main thread	JavaScript execution, style calculation, layout, paint display-list generation
Compositor thread	Handles scroll, `transform`/`opacity` animations, layer compositing, independently of the main thread
GPU process	Rasterizes layer display lists into actual pixels on the GPU

The practical implication: the compositor thread can keep animations and scrolling smooth even when the main thread is busy. But only if those animations involve properties that don't require the main thread transform and opacity. If your animation touches width, top, padding, or margin, it forces the main thread back into the loop.

This is why you can see silky-smooth parallax scroll effects on a page that's simultaneously doing heavy JavaScript work, as long as the scroll transform is isolated to its own compositor layer.

What "jank" physically is

Jank is a frame drop. The display has a fixed refresh rate, commonly 60Hz, meaning it redraws 16.67ms. At each refresh, it either shows a new frame or repeats the previous one. If the browser misses the deadline, you see a repeated frame.

This is called missing a v-sync. The human visual system is highly tuned to smooth motion. A single dropped frame is barely perceptible. Two or three in a row is "stuttery." A consistent pattern of drops, caused by main-thread work exceeding 16ms, reads as a sluggish, broken UI even if the rest of the page is perfectly fine.

The timeline looks like this in DevTools: frames that take longer than ~16ms appear highlighted in red in the frame timeline. The Performance panel's frame section will show you each frame's actual duration; anything over 16ms is a potential jank source.

requestAnimationFrame and the pipeline

requestAnimationFrame (rAF) is the browser's invitation to do visual work at the right moment. When you call requestAnimationFrame(callback), the browser schedules your callback to run at the start of the next frame, just before layout and paint.

function updateAnimations(timestamp) {
  // This runs before layout and paint, inside the frame budget
  element.style.transform = `translateX(${calculatePosition(timestamp)}px)`;
  requestAnimationFrame(updateAnimations);
}

requestAnimationFrame(updateAnimations);

What rAF does not do: it doesn't guarantee your callback will fit inside 16ms. It just ensures you're called at a frame boundary instead of some arbitrary async point. If your rAF callback takes 30ms, you've still dropped a frame. The discipline of the 16ms budget is yours to maintain.

Also important: rAF callbacks are batched to the display's refresh rate. If you call requestAnimationFrame 500 times per second, you won't get 500 callbacks. You'll get approximately 60.

Forced reflow / layout thrashing

Layout thrashing is one of the most common and painful performance antipatterns. It happens when you write to the DOM and then read a layout-dependent property before the browser has had a chance to batch those updates.

The browser is lazy about layout; it tries to defer it as long as possible. But certain property reads force it to run layout immediately, because the value isn't valid until geometry is computed. These are called forced synchronous layouts or forced reflows.

Properties that force layout when read include: offsetWidth, offsetHeight, offsetTop, offsetLeft, clientWidth, clientHeight, scrollHeight, scrollTop, getBoundingClientRect(), getComputedStyle().

Here's what the bad pattern looks like:

// Layout thrashing  triggers layout on every iteration
const elements = document.querySelectorAll('.card');
elements.forEach(el => {
  const height = el.offsetHeight; // FORCES layout to compute
  el.style.height = (height + 10) + 'px'; // Invalidates layout
  // Next iteration reads offsetHeight again  forces layout AGAIN
});

The fix is to batch reads, then batch writes:

// Reads first: layout computed once
const heights = Array.from(elements).map(el => el.offsetHeight);

// Writes second: no interleaved forced layouts
heights.forEach((height, i) => {
  elements[i].style.height = (height + 10) + 'px';
});

In the bad version, if you have 100 elements, you're triggering 100 separate synchronous layouts. In the fixed version, you get one. This is the difference between a 2ms operation and a 200ms one.

Compositor layers: what promotes an element

Not all elements are on the same compositor layer. By default, most content lives on a single layer. But some properties cause the browser to promote an element to its own compositor layer meaning it gets its own GPU texture and can be transformed independently without touching the rest of the page.

Properties that promote to a new layer:

Property/Condition	Why it promotes
`transform: translateZ(0)` or `translate3d(0,0,0)`	Forces GPU rasterization, historical "hack"
`will-change: transform` or `will-change: opacity`	Explicit hint to browser to promote
`position: fixed`	Must be composited independently from scroll
`<video>`, `<canvas>`, `<iframe>`	Native GPU-accelerated content
CSS 3D transforms (`rotateX`, `rotateY`)	Requires 3D compositing
Elements with `opacity < 1` that also have children	Blending requirements

Why promotion matters: once an element is on its own layer, you can animate its transform and opacity without triggering layout or paint on the main thread. The compositor thread handles it entirely. This is how you get 60fps animations even on pages with heavy JS.

The trap: don't promote everything. Each layer is a GPU texture that consumes memory. Promoting hundreds of elements can exhaust GPU memory (especially on mobile) and cause the browser to swap textures in and out, which is slower than not promoting in the first place.

/* Good: targeted promotion for things you know you'll animate */
.animated-card {
  will-change: transform;
}

/* Bad: promoting everything hoping for magic */
* {
  transform: translateZ(0); /* Please don't */
}

Style invalidation

When you change a CSS class, the browser needs to figure out which elements are affected and recalculate their computed styles. This is style invalidation, and it can be wider than you expect.

If you add a class to the <body>, styles that use descendant selectors (.theme-dark .card, body.loading button) could match or unmatch for any element in the tree. The browser must re-match selectors across the entire DOM.

Specificity aside, there are practical rules that make style invalidation cheaper:

Avoid deep descendant selectors like div > ul > li > span.text the browser has to walk the tree to resolve them.
Use BEM or similar so selectors are flat and high-specificity matches happen quickly.
Batch class changes adding classList.add('a', 'b', 'c') in one call is cheaper than three separate .add() calls because it can trigger a single style recalculation.

The Performance panel's Style & Layout section shows you "Recalculate Style" events. If you see them firing on every scroll or input event, that's style invalidation you can reduce.

Paint vs Composite: why `opacity` and `transform` are "free"

This is the most important practical takeaway from the pipeline. The question "which CSS property is cheap to animate?" has a precise answer based on which pipeline stages the property affects.

Property	Layout	Paint	Composite
`width`, `height`, `padding`, `margin`	Yes	Yes	Yes
`color`, `background-color`, `box-shadow`	No	Yes	Yes
`transform`, `opacity`	No	No	Yes

Properties in the third row skip layout and paint entirely. The compositor thread handles them without touching the main thread. This is why transform: translateX() is categorically different from left: when it comes to animation performance, even though they produce visually identical results.

/* Slow: triggers layout and paint on every frame */
.bad-animation {
  animation: slide-left 300ms ease;
}
@keyframes slide-left {
  from { left: 0; }
  to { left: -100%; }
}

/* Fast: compositor-only, main thread not involved */
.good-animation {
  animation: slide-transform 300ms ease;
}
@keyframes slide-transform {
  from { transform: translateX(0); }
  to { transform: translateX(-100%); }
}

Reading the DevTools Performance flame chart

The Performance panel in Chrome DevTools is the tool for diagnosing rendering bottlenecks. Here's how to read it:

Record a trace: open DevTools, go to Performance, hit Record, reproduce the sluggish interaction, stop recording.

The frame timeline at top: a series of bars representing each rendered frame. Green bars are on-time frames. Red-outlined bars are long frames (janky). Hover to see the exact duration.

The main thread flame chart: this shows all work done on the main thread over time. The width of each block is how long it took. Blocks are stacked when one function calls another. You're looking for:

Wide yellow blocks: JavaScript execution. Find long-running functions.
Wide purple blocks: Layout (Recalculate Style + Layout). Look for what triggered them.
Wide green blocks: Paint events. Large paint areas.
Red triangles: "Long task" markers, meaning the browser flagged a task over 50ms.

Clicking a Layout block will show you in the bottom panel which specific property read caused a forced synchronous layout. This is how I found that offsetHeight call in the scroll listener Chrome directly reported the call stack that triggered the forced layout.

The Layers panel: under the three-dot menu → More tools → Layers. Shows you a 3D view of your compositor layers. Useful for checking if you're accidentally promoting hundreds of elements.

Practical triggers for each pipeline stage

A quick reference for what causes the browser to run each stage:

Stage	Common triggers
Style	Adding/removing CSS classes, inline style changes, pseudo-class changes (`:hover`)
Layout	Any geometry change (width, height, margin), reading forced-layout properties, font loading
Paint	Color changes, shadow changes, visibility changes, border-radius, clip-path
Composite	`transform`, `opacity`, scroll position (on promoted elements)

When you're debugging a performance problem, identifying which stage is the bottleneck tells you exactly where to look. A long "Recalculate Style" event points to selector complexity or broad invalidation. A long "Layout" event points to geometry-changing properties or forced reflows. A long "Paint" event points to large paint areas or expensive paint operations like box-shadow and filter.

The rendering pipeline is not a black box. Every frame of jank has a cause, and it's visible in the flame chart if you know where to look.

Originally published at renderlog.in · 12 min read

Follow Ashish on LinkedIn for more frontend performance deep dives.

Forem: Ashish Kumar

Meta StyleX: Moving CSS-in-JS From Runtime to Build Time

What goes wrong with runtime CSS-in-JS

How StyleX reframes the problem

Runtime vs build time (one table)

Why “compile time” is the headline

Takeaway

DRM PiP Loophole: Why Picture-in-Picture Can Bypass DRM Black-Screen Protection

What people observe (browser + PiP)

Why PiP can change what recorders see

Widevine L3 vs L1 (and why 4K stays stubborn)

Security vs usability

Takeaway

Core Web Vitals and Lighthouse: What the Scores Mean

LCP: Largest Contentful Paint

Which elements qualify

Why images and text blocks differ

What invalidates LCP

CLS: Cumulative Layout Shift

The formula

What causes CLS

Debugging CLS

INP: Interaction to Next Paint

Why FID was replaced

How INP works

What "next paint" means

TTFB: Time to First Byte

Lab vs field data: why they diverge

The 75th percentile rule

Why a perfect Lighthouse score coexists with terrible INP

How to actually measure each metric

Practical debugging workflow

Why React Error Boundaries Are Still Class Components

What an error boundary actually is

Why error boundaries are class components today

Minimal class boundary (copy-paste pattern)

What error boundaries do not catch

Strategy: where to place boundaries

Mental model checklist

React State Management Compared: Redux vs Zustand vs Jotai vs Valtio

Centralized stores: Redux and Zustand

Redux

Zustand

Atomic state: Jotai

Proxy reactivity: Valtio

Architecture comparison at a glance

Decision checklist

How Google Maps Predicts Traffic in Real Time: Live Data and ETA Explained

Crowdsourced probes: speed and direction at scale

The road network as a graph

Historical curves: "slow" versus "wrong slow"

Waze and human-in-the-loop incidents

Scale, latency, and honest caveats

Takeaway

The 16.6ms Frame Budget: Why Fast Loads Still Feel Slow

Where 16.6 ms comes from

What must fit inside one frame

Why good Lighthouse scores can hide the problem

Real-time data and the main thread

Mental model checklist

Why CSS Never Matches Figma: Browser vs Canvas Pipelines

How Chrome turns CSS into pixels

1. Parse

2. Style

3. Layout

4. Paint

5. Composite

How Figma draws outside the DOM

C++ / Rust core

WebAssembly

WebGL / WebGPU

Screen

Where design-to-code breaks: property by property

cornerSmoothing (Figma) vs border-radius

Stroke alignment vs border

Glass vs backdrop-filter

Multiple fills

Negative gap (Auto Layout) vs CSS gap

Plus Lighter vs mix-blend-mode

Why the gap is structural (specs vs product shaders)

`cornerSmoothing` (Figma) vs `border-radius`

Stroke alignment vs `border`

Glass vs `backdrop-filter`

Negative gap (Auto Layout) vs CSS `gap`

Plus Lighter vs `mix-blend-mode`

Paint vs Composite: why `opacity` and `transform` are "free"