Invalidation, dirty bits, and contain
How CSS property changes propagate through the pipeline, what controls the blast radius, and how contain/content-visibility isolate the damage.
You change one class on one element and the browser re-paints a thousand elements. You change a different class on the same element and nothing else moves. The difference is which pipeline stage the property invalidates — and whether anything downstream can escape.
The invalidation rule
Why does changing one property cost a millisecond while changing another costs twenty? The answer is which pipeline stage it invalidates — and the downstream stages it drags along for the ride.
Changing a CSS property invalidates one or more pipeline stages. Everything from that stage down must re-run.
| CSS change | Invalidates | Cost |
|---|---|---|
width, height, top, left | Layout (+ paint + composite) | High |
background-color, color | Paint (+ composite) | Medium |
transform, opacity (on own layer) | Composite only | Low |
filter: blur(...) | Paint (+ composite) | Medium–High |
csstriggers.com publishes a per-property map. Learn the cheap ones (transform, opacity, filter on a promoted element) and the expensive ones (anything that affects flow).
How dirty bits propagate
Dirty-bit propagation rules
- Style flags flow down the DOM tree — a class change on a parent dirties all descendants whose selectors match.
- Layout flags flow down the box tree — a width change on a parent may dirty siblings if their position depends on it.
- Paint flags are scoped to the paint layer — a paint-affecting change on a layer invalidates that layer’s bitmap; sibling layers with their own bitmaps are unaffected.
- Composite is always dirty-free — it works from already-rasterised tiles and only re-runs the GPU draw call.
Rule: dirty bits flow DOWN the dependency graph, never UP.
Together these rules explain why a tooltip that changes background-color is cheap (paint flag, one layer) while a tooltip that changes width can re-layout the entire page (layout flag cascades to all dependents). The blast radius is determined by how high in the dependency graph the flag starts, and how many nodes depend on it below.
If you can isolate your changes to an independent subtree, the invalidation stops at the isolation boundary.
CSS Containment: capping the blast radius
CSS Containment gives you a knob to limit how far invalidation propagates.
contain: layout— “this element’s layout cannot affect its ancestors.” If a child resizes, the parent’s siblings do not need to re-layout.contain: paint— painting is contained inside the box (overflow clipped). The browser can skip painting it entirely when it is off-screen.contain: strict— combines layout, paint, and size containment.
The newer content-visibility: auto goes further: it tells the browser to skip the element entirely (no style calc, no layout, no paint) when it is off-screen. Combined with contain-intrinsic-size (which gives the browser a placeholder size), it lets a page with thousands of below-the-fold elements render in milliseconds because only on-screen elements pay the cost.
These are the modern “free wins” for any page rendering large lists, infinite scroll feeds, or long-form content.
▸Edge cases
Fonts and FOIT/FOUT. A web font is a pipeline input often overlooked. The font starts loading when the CSS parser sees a font-family backed by a @font-face with a src. Until the font arrives, the browser either shows text in a fallback font (FOUT — flash of unstyled text) or hides text (FOIT — flash of invisible text). The font-display property controls this: swap shows the fallback immediately then swaps; optional uses the fallback if the font hasn’t arrived within ~100 ms; block hides text for up to 3 s. When the loaded font swaps in, the browser re-runs style recalc and layout, because font metrics change text width, which changes box sizes. On a large text block this swap is visible as frame jank 200–500 ms after first paint.
Images and CLS. An image loading without explicit width and height forces a re-layout when it loads: the image box was 0×0, now it is the actual size, and everything around it shifts — the main cause of CLS regressions. The fix is to set explicit width/height in HTML or use aspect-ratio in CSS; the browser reserves the space up front, and the image load becomes only a paint invalidation, not a layout one. Modern loading="lazy" loads off-screen images lazily, saving bandwidth, but still requires pre-declared sizes to avoid layout shift when the image enters the viewport.
Which property change invalidates only the composite stage (no layout, no paint)?
You add `contain: layout` to a card component. A child element inside it resizes. Which elements need to re-layout?
A page uses `content-visibility: auto` on 10 000 below-the-fold list items. What happens during first paint?
- 01Which pipeline stages does changing `width` invalidate?
- 02What does `contain: layout` tell the browser?
- 03What is the mechanism behind `content-visibility: auto`?
Every CSS property change invalidates exactly one or more pipeline stages; dirty bits then flow downstream. width invalidates layout, which forces paint and composite to re-run. opacity on a promoted element invalidates only composite — which is why it is “free.” CSS Containment (contain: layout, contain: strict) stops the invalidation blast at a boundary. content-visibility: auto takes this further: off-screen subtrees are entirely skipped (display-locked), turning a 1200 ms first-paint into 10 ms for long pages. Images without declared dimensions cause layout invalidation on load, which is the root cause of most CLS regressions. Now when you reach for a CSS property to animate or toggle a state, you’ll instinctively ask: does this enter the pipeline at layout, paint, or composite? The answer decides whether a style change costs 0.5 ms or 20 ms.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
appears again in188
- Why GraphQL gets N+1junior
- DataLoader mechanics: tick-boundary batchingmiddle
- Batch function contracts: ordering, shapes, errorsmiddle
- Federation and lookahead: batching beyond DataLoadermiddle
- Query complexity defences: depth, cost, persisted queriesmiddle
- Senior GraphQL API: scheduling contract, tenant isolation, observabilitysenior
- Why idempotency: making retries safejunior
- Server-side state machine: four states of an idempotency keymiddle
- Outbox and inbox: effectively-once across the dual-write boundarymiddle
- Concurrency and cache architecture for idempotency at scalesenior
- Observability, production failures, and global-scale designsenior
- What is a cache stampede and why it makes things worsejunior
- Lock and single-flight: bounding concurrent rebuildsmiddle
- XFetch: coordination-free probabilistic early expirationmiddle
- Stale-while-revalidate and CDN request coalescingmiddle
- Detecting stampedes and designing TTL for productionmiddle
- Metastable failure, fencing tokens, and production postmortemssenior
- What a relation is: tables, rows, keys, and constraintsjunior
- Constraints, keys, and Postgres data typesmiddle
- Normal forms, denormalization, and why schemas stickmiddle
- JSONB, arrays, and when a side table winsmiddle
- Heap storage, TOAST, and column alignmentsenior
- Schema integrity: deferral, versioning, and production failure modessenior
- Relational vs document, wide-column, graph, and key-valuesenior
- Index-only scans, the Visibility Map, and INCLUDEsenior
- Production failure modes and the index audit playbooksenior
- pg_statistic, ANALYZE, and production observabilitymiddle
- Production failure modes and plan stabilitysenior
- MVCC: why readers and writers never wait for each otherjunior
- Row versions and snapshots: the on-disk mechanicsmiddle
- HOT updates and isolation levels: what you gain and what you paymiddle
- Vacuum and bloat: keeping the storage tax boundedmiddle
- CLOG, XID wraparound, and MultiXact: deep visibility internalssenior
- SSI internals and production autovacuum tuningsenior
- Real-world MVCC failures, deployment patterns, and distributed snapshotssenior
- Connection pools: amortising the cost of a Postgres backendjunior
- PgBouncer session, transaction, and statement modesmiddle
- Pool sizing: the (cores × 2) + spindles formula and the two-layer stackmiddle
- Pool exhaustion and idle-in-transaction: the 3 AM failure modemiddle
- Migrating to transaction mode: rollout playbook and PgBouncer 1.21 prepared statementsmiddle
- The Postgres process model and why raising max_connections degrades throughputsenior
- Pooler landscape 2026, serverless connection storms, and the full failure-mode taxonomysenior
- What a schema migration is and why it replaces ad-hoc DDLjunior
- ADD COLUMN: instant in PG 11+ vs rewrite in older Postgresjunior
- The lock-queue failure mode: why instant DDL can freeze the databasemiddle
- Safe DDL patterns: NOT VALID, CONCURRENTLY, and unsafe-op fixesmiddle
- Expand-contract: zero-downtime for breaking schema changesmiddle
- Advisory locks, migration tools, and deploy coordinationsenior
- Migration failure taxonomy and production disciplinesenior
- Why sharding exists: the single-Postgres ceilingjunior
- Shard-key selection: hash, range, list, and directory strategiesmiddle
- Partitioning vs sharding: same word, two different thingsmiddle
- Co-location and Citus: the invariant that makes sharding usablemiddle
- The hot-shard failure mode: detection, isolation, and durable policymiddle
- Schema-based sharding and multi-tenancy alternativessenior
- Online resharding, 2PC, and the operational cost of shardingsenior
- The seven acts: from CREATE TABLE to Citusjunior
- Acts 1–3 in depth: schema, indexes, and planner statisticsmiddle
- Acts 4–6 in depth: MVCC bloat, connection pooling, and safe migrationsmiddle
- Act 7 in depth: sharding, co-location, and the seven-tier tradeoff cascademiddle
- Observability, anti-patterns, and production triagesenior
- Raft roles, terms, and why majority quorums prevent split brainjunior
- How Raft replicates a log entry and decides it is safe to commitmiddle
- Raft leader election: timeouts, voting rules, and the four safety propertiesmiddle
- Raft in the real world: partitions, slow disks, and client routingmiddle
- Raft extensions: pre-vote, learners, snapshots, and linearizable readssenior
- Raft in production: membership changes, Multi-Raft, and observabilitysenior
- Where data fetching happens — and why it decides LCPjunior
- Fetch waterfalls — diagnosis and the Promise.all curemiddle
- React Server Components and Suspense streamingmiddle
- Client-side cache: TanStack Query, SWR, and stale-while-revalidatemiddle
- LCP, prefetch, and race conditions in interactive fetchingmiddle
- Senior internals: RSC payload, caching layers, and production failure modessenior
- What a JavaScript engine iszero
- Ignition and the bytecodemiddle
- Inside the interpreter loopmiddle
- How V8 represents a valuemiddle
- What a Map really is: opening the hidden classmiddle
- Transition trees, deprecation, and migrationmiddle
- Fast properties, slow properties, and slack trackingmiddle
- Inline caches, deeply: feedback slots and handlersmiddle
- Monomorphic, polymorphic, megamorphic — and the stub cachemiddle
- Four tiers and how warm-up worksmiddle
- Type feedback: the fuel for the optimisersenior
- TurboFan: the sea-of-nodes optimisersenior
- Speculation and guardssenior
- Deoptimization: falling off the cliffsenior
- On-Stack Replacement: swapping the frame mid-loopsenior
- Scopes, contexts, and the scope chainmiddle
- What a closure actually retainsmiddle
- When V8 allocates a Context (and what it costs)middle
- Closures, feedback vectors, and call-site polymorphismmiddle
- Why a GC, and reachabilitymiddle
- Leaks in a garbage-collected languagesenior
- The engine vs the loopmiddle
- Microtasks vs macrotasks: orderingmiddle
- Inside a Promisemiddle
- async/await, desugaredmiddle
- Capstone: optimize a hot pathsenior
- The IP envelopejunior
- Reading the IP headermiddle
- The three-way handshakejunior
- Sequence numbers and connection statemiddle
- DNS: what it does and why it existsjunior
- The resolver walk: referrals, record types, and gluemiddle
- TTL, caching, and DNS propagationmiddle
- What TLS does and why it existsjunior
- The 1-RTT handshake: key shares and ECDHEmiddle
- Session resumption and 0-RTTmiddle
- Key schedule, SNI, ALPN, and extensionssenior
- 0-RTT defenses, ECH, hybrid PQ, and production TLSsenior
- WebSocket: the HTTP upgrade handshakejunior
- WebSocket frame format: opcodes, masking, fragmentationmiddle
- WebSocket backpressure: when clients can''''t keep upmiddle
- Reconnection: jittered backoff, thundering herd, message resumptionsenior
- WebSocket at scale: HTTP/2 multiplexing, permessage-deflate, C10Msenior
- WebSocket in production: proxies, security, and distributed architecturesenior
- What reverse proxies dojunior
- Health checks, connection draining, and slow startmiddle
- Session affinity, consistent hashing, and the right fixmiddle
- Retry storms, circuit breakers, and load sheddingsenior
- Resilient LB architecture: anycast, zone-aware routing, and observabilitysenior
- Why QUIC and not TCP+TLSjunior
- Connection IDs and network migrationmiddle
- 0-RTT resumption and packet encryptionsenior
- DDoS: what it is and why it worksjunior
- Amplification attacks and state exhaustionmiddle
- Rate limiting: algorithms and architecturemiddle
- WAFs, firewalls, mTLS, and HSTSmiddle
- DNS cache poisoning and BGP hijackingsenior
- Defense-in-depth architecture and attack economicssenior
- The twelve layers: one URL, seven actorsjunior
- DNS, TCP, TLS in sequence: where the milliseconds gomiddle
- Proxy intercepts and security gates: rate limiters, WAF, mTLSmiddle
- Alternate paths: QUIC 0-RTT, WebSocket upgrade, connection migrationmiddle
- Observability: distributed traces, USE/RED, and samplingsenior
- Resilience: cascading retries, circuit breakers, and error budgetssenior
- What the three signals are: logs, metrics, and tracesjunior
- Why structured logs exist: the diary vs the spreadsheetjunior
- The production log schema: fields every line must carrymiddle
- PII redaction and log injectionsenior
- OTel Logs Data Model and audit logs as a subsystemsenior
- What is OpenTelemetry: API, SDK, Collector, OTLPjunior
- OTel signals, Semantic Conventions, and the OTLP wire formatmiddle
- The OTel Collector: receivers, processors, exporters, and deployment patternsmiddle
- Vendor neutrality, eBPF instrumentation, the Operator, and browser/serverless OTelsenior
- Operating the OTel Collector: reliability, version skew, failure modes, and governancesenior
- SLI, SLO, and the error budget: reliability by the numbersjunior
- Error budget policy, latency SLOs, and composite journeysmiddle
- Production SLO failures, self-observability, security, and the big picturesenior
- What is trace propagation and why broken propagation is worse than nonejunior
- traceparent and tracestate: the W3C header format in fullmiddle
- Baggage and async boundaries: carrying context across queues and callbacksmiddle
- Async context per language, service mesh, B3 migration, and securitysenior
- Production propagation failures, span links, and platform designsenior
- The debugging funnel: SLO → RED → trace → profilejunior
- OTel architecture: one SDK, four signals, one wire formatmiddle
- The incident loop: from pager to postmortem to preventionmiddle
- Scale, security, and the ROI of observable systemssenior
- Cache lines, struct layout, and false sharingmiddle
- SIMD, SoA vs AoS, and memory bandwidthmiddle
- Cache-oblivious algorithms, PGO, and production failuressenior
- GC in production: observability, security, edge cases, and fleet governancesenior
- Batching: amortize fixed cost per operationjunior
- The batching window: size and wait timemiddle
- Batching in Kafka and Postgresmiddle
- io_uring and observability of batchingmiddle
- From Nagle to io_uring: evolution of batchingmiddle
- Backpressure, failure isolation, and batch security in productionsenior
- CI enforcement and RUM: making budgets stickmiddle
- V8 JIT pipeline, HTTP priorities, and bundle securitysenior
- The performance loop: discipline, not a projectjunior
- Classify and fix: matching bottleneck families to remediesmiddle
- Observability stack and CI gates: catching regressions before they shipmiddle
- Incident to enforcement: SLO burn to verified fix in 35 minutesmiddle
- Culture, economics, and org-scale performancesenior
- At-most-once, at-least-once, exactly-once: the three delivery contractsjunior
- The three failure legs — where duplicates and losses actually happenmiddle
- Consumer-side dedup: the cheapest path to exactly-once processingmiddle
- Kafka exactly-once semantics: idempotent producer and transactionsmiddle
- SQS visibility timeout, DLQ, and the outbox patternmiddle
- Exactly-once in production: impossibility proof, hybrid patterns, and real incidentssenior
- What OAuth is and why passwords are not the answerjunior
- Authorization code flow with PKCEmiddle
- ID token validation and JWKS cache managementmiddle
- Refresh token rotation and scope-based least privilegemiddle
- Sender-constrained tokens: DPoP and mTLSsenior
- OAuth in production: audience attacks, observability, and real failuressenior
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.
Apply this
Put this lesson to work on a real build.