Networking & Protocols
Critical render path and Core Web Vitals
Crux How the browser turns bytes into pixels — the DOM/CSSOM merge, CSS render-blocking, the preload scanner, JavaScript deferral — and how LCP, INP, and CLS measure the user''''s experience of that pipeline.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at middle altitude — in the skyThe network portion of a page load is done in 150 ms. LCP fires at 3.2 seconds. The gap is the browser’s rendering pipeline — and most of it is caused by decisions you made: which CSS to load, where you placed scripts, whether images have dimensions, what JavaScript runs on the main thread before paint. Understanding this pipeline is the second half of page load performance.
The critical render path
After the browser receives the HTML bytes, rendering proceeds in several overlapping stages:
- HTML parse → DOM. The HTML parser builds the Document Object Model as bytes stream in. Parsing starts before the full body has arrived — streaming parse.
- CSS parse → CSSOM. When the browser encounters a
<link rel="stylesheet">tag, it fetches the CSS file and builds the CSS Object Model. Nothing paints until the CSSOM is ready — CSS is render-blocking. Why? Showing a page with unstyled content (FOUC — Flash Of Unstyled Content) and then reflowing it causes layout instability that degrades perceived performance. This is intentional, not a bug. - DOM + CSSOM → render tree. The browser merges the DOM and CSSOM into a render tree containing only visible elements with their computed styles.
- Layout. The browser calculates the exact position and size of each element.
- Paint. The browser rasterises the render tree into pixels.
- Compositing. GPU layers are merged into the final frame.
JavaScript complicates this: a <script> tag without async or defer blocks HTML parsing. The parser pauses, the script is fetched and executed, then parsing resumes. This is why classic scripts placed in <head> dramatically slow first paint.
| Resource type | Blocks HTML parse? | Blocks render? | Fix |
|---|---|---|---|
| CSS (stylesheet) | No | Yes | inline critical CSS; preload |
| JS (classic, in <head>) | Yes | Yes | add defer or async |
| JS (async) | Partially | Partially | executes when ready, not in order |
| JS (defer) | No | No | executes after HTML parse, in order |
| Images (no dimensions) | No | Causes CLS | add width/height attributes |
| Fonts (WOFF2) | No | Causes FOIT/FOUT | preload + font-display:swap |
The preload scanner
The browser runs a lightweight HTML tokeniser called the preload scanner ahead of the main parser. It looks for <link>, <script>, and <img> URLs and fires requests for them before the main parser has processed those tags. Without it, subresource discovery would be sequential — each resource only fetched after the main parser reached it.
The preload scanner is defeated by:
- JavaScript that writes
<script src="...">viadocument.write. - Complex client-side routing that builds URLs after framework initialisation.
- Lazy-loading schemes that hide URLs behind
data-srcattributes.
Modern frameworks (Next.js, Astro, SvelteKit) emit <link rel="preload"> hints automatically to compensate.
Resource hints
| Hint | Effect | Cost |
|---|---|---|
<link rel="dns-prefetch" href="//cdn.example.com"> | Resolves DNS in background | Minimal |
<link rel="preconnect" href="//cdn.example.com" crossorigin> | DNS + TCP + TLS in background | One idle socket per origin |
<link rel="preload" as="font" crossorigin> | Fetches font before parser reaches it | Bandwidth |
<link rel="modulepreload"> | Fetches ES module + its imports | Bandwidth |
<link rel="prefetch"> | Fetches likely-next-navigation resource (low priority) | Bandwidth when idle |
fetchpriority attribute. You can override the browser’s default resource scheduling:
<img src="hero.jpg" fetchpriority="high">— hero image loaded before other images.<script src="analytics.js" fetchpriority="low">— defer non-critical JS below CSS and fonts.
Core Web Vitals
Google’s Core Web Vitals quantify user-perceived performance. Search ranking uses field RUM data (real user measurements via Chrome UX Report), not synthetic Lighthouse scores.
LCP — Largest Contentful Paint. When the largest visible element finishes rendering. Usually the hero image or main heading. Good: under 2.5 s. Poor: over 4 s. Primary causes of poor LCP: slow server TTFB, render-blocking resources delaying the main image, large unoptimised image files.
INP — Interaction to Next Paint (replaced FID in March 2024). The longest delay between any user input (click, tap, keypress) and the resulting visual update across the entire page lifecycle. Good: under 200 ms. Poor: over 500 ms. Primary cause: long tasks on the main thread holding the UI unresponsive.
CLS — Cumulative Layout Shift. Unexpected movement of visible elements during page load. Score: sum of (impact fraction × distance fraction) for each unexpected shift. Good: under 0.1. Primary causes: images without declared dimensions, ads inserting content, web fonts causing text reflow.
Why this works
Google uses field RUM data (real user measurements from Chrome UX Report) for ranking, not Lighthouse. A page scoring 95 in Lighthouse on your laptop may score 55 in CrUX if real users are on slow Android phones in poor signal. Optimise for the field, not the lab.
Quiz
Completed
Why does CSS block rendering by default?
Heads-up Modern browsers parse CSS very fast; blocking is a correctness choice, not a performance limitation.
Heads-up It is intentional behaviour across all major engines.
Heads-up HTML parsing starts immediately; CSS only blocks render, not parse.
Trace it
1/5 Trace what the browser does during HTML streaming — from first byte to LCP.
1
Step 1 of 5
First bytes of HTML arrive. What does the browser do immediately?
Starts the HTML parser AND the preload scanner in parallel. Parser builds the DOM incrementally; preload scanner looks ahead for <link>, <script>, <img> URLs to fire requests before the parser reaches them.
2
Locked
Parser encounters <link rel=stylesheet href=main.css>. HTML parsing continues. Rendering?
Browser fetches main.css. HTML parsing continues (CSS does not block parse). Rendering is blocked — nothing paints until the CSSOM is ready. If main.css takes 200 ms to arrive, LCP is delayed 200 ms.
3
Locked
Parser encounters <script defer src=app.js>. What happens?
Browser fetches app.js (preload scanner may have already started this). The defer attribute means: do not block parsing; execute the script after the HTML is fully parsed. Main thread is not blocked.
4
Locked
CSS arrives. CSSOM built. Render tree constructed. Browser paints first frame. What metric fires?
First Contentful Paint (FCP) fires when any text or image is painted. LCP fires when the largest visible element (hero image, main heading) is painted — could be the same frame or later if the hero image arrives after the first paint.
5
Locked
Hero image loads 400 ms after HTML. LCP fires. What determined whether LCP was Good or Poor?
LCP = TTFB + hero image load time + render time. If TTFB was 150 ms, hero image 400 ms (network) + 20 ms (decode/layout), LCP = ~570 ms — Good. If the hero image was not preloaded and the preload scanner missed it (because it was dynamically injected by JavaScript), LCP could be 2+ seconds — Poor.
✓ Traced.
Order the steps
Completed
Order these interventions by their impact on LCP (highest to lowest, assuming LCP is the hero image):
- 1 Cache HTML at CDN edge so TTFB drops from 300 ms to 20 ms
- 2 Add <link rel=preload as=image> for the hero image so it fetches in parallel with CSS
- 3 Convert the hero image from JPEG to WebP (30% smaller file size)
- 4 Add fetchpriority=high to the hero <img> tag
- 5 Remove render-blocking analytics script from <head> (move to defer)
Quiz
Completed
What is INP measuring that FID did not?
Heads-up That is closer to TTI (Time to Interactive).
Heads-up That is CLS.
Heads-up Total Blocking Time (TBT) measures main-thread blocking; INP is the user-perceived input lag.
- 01Why is the preload scanner critical to fast page loads, and what defeats it?
- 02What causes CLS, and how do you fix it?
- 03Google ranks pages using field RUM data, not Lighthouse. What is the practical implication?
Recap
The browser’s critical render path converts bytes into pixels across six stages: HTML parse, CSS parse, render tree construction, layout, paint, and compositing. CSS is render-blocking — nothing paints until the CSSOM is ready — making it the highest-priority resource to deliver. JavaScript without defer or async blocks HTML parsing, delaying everything. The preload scanner rescues you by firing requests for subresources ahead of the main parser, but it is defeated by dynamically injected URLs. Core Web Vitals (LCP, INP, CLS) measure the user’s perception of this pipeline; Google uses field RUM data (real Chrome users), not Lighthouse scores, for ranking. The four highest-impact fixes are: CDN-cache HTML (reduce TTFB), preload the hero image, defer non-critical JS, and add image dimensions.
Connected lessons
appears again in165
- The journey of a request: seven stops from socket to responsejunior
- Accept and parse: from kernel queue to a typed requestmiddle
- Routing and middleware: choosing what runs, and in what ordermiddle
- Handler and response: from business logic to bytes on the wiremiddle
- Streaming and backpressure: when the client reads slower than you writesenior
- Timeouts and tail latency: budgets, deadlines, and the fan-out trapsenior
- Middleware and DI: the two patterns that shape every backendjunior
- Writing middleware: signatures, next(), and the three framework modelsmiddle
- Inversion of control: how dependencies reach a classmiddle
- DI scopes and lifecycles: singleton, request, transientmiddle
- DI as a testing seam: fakes, mocks, and the boundary that matterssenior
- DI containers in production: resolution graphs, circular deps, and when not tosenior
- Blocking vs non-blocking I/O: two ways to waitjunior
- The event loop: one thread, ordered phasesmiddle
- What blocks the loop: CPU work and sync callsmiddle
- Offloading CPU work: worker threads and the libuv poolmiddle
- Backpressure and bounded concurrencysenior
- Throughput under load: tail latency and saturationsenior
- Why pool: the cost of creating a connectionjunior
- Pool sizing: why bigger is not fastermiddle
- Acquisition and timeouts: the wait queue is the real latency dialmiddle
- Retry strategies: backoff, jitter, and thundering herdmiddle
- Observability, production failures, and global-scale designsenior
- Tasks, microtasks, and scheduler.yield()middle
- Timer accuracy, throttling, and idle workmiddle
- Node.js event loop: phases, nextTick, and loop lagsenior
- Rendering strategies: SSG, SSR, ISR, streaming, and hydrationjunior
- SSG, SSR, ISR, streaming, and RSC — how each worksmiddle
- Hydration cost: selective, progressive, islands, resumabilitymiddle
- Core Web Vitals: what LCP, INP, and CLS measurejunior
- LCP: four phases, one dominant costmiddle
- INP: input delay, processing, presentationmiddle
- Lab vs field: why the two disagree and how to use eachmiddle
- Metric tradeoffs, RUM attribution, and the CI+field loopsenior
- The full picture: URL to LCP to INP as a relay racejunior
- Eight layers traced: from the service worker to the second navigationmiddle
- Five canonical breaks: where production reliably diessenior
- The three-track method: reading traces and building a monitored systemsenior
- What an index is and how it speeds up queriesjunior
- The leading-column rule and composite index designmiddle
- Partial, expression, and covering indexesmiddle
- Index types: GIN, GiST, BRIN, Hash, Bloom, and HOT updatesmiddle
- Index-only scans, the Visibility Map, and INCLUDEsenior
- Production failure modes and the index audit playbooksenior
- Index design exercise: full-text search strategysenior
- EXPLAIN and execution plans: what the planner decides and whyjunior
- Scan types: Seq, Index, Bitmap, Index-Onlymiddle
- Join algorithms and the row-estimate cascademiddle
- pg_statistic, ANALYZE, and production observabilitymiddle
- Extended statistics: fixing correlated-column estimate failuressenior
- Plan cache, cost-constant tuning, and planner internalssenior
- Production failure modes and plan stabilitysenior
- MVCC: why readers and writers never wait for each otherjunior
- 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
- 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
- Migration failure taxonomy and production disciplinesenior
- Shard-key selection: hash, range, list, and directory strategiesmiddle
- Co-location and Citus: the invariant that makes sharding usablemiddle
- The hot-shard failure mode: detection, isolation, and durable policymiddle
- 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 in the real world: partitions, slow disks, and client routingmiddle
- Raft in production: membership changes, Multi-Raft, and observabilitysenior
- What the three signals are: logs, metrics, and tracesjunior
- Metrics and cardinality: the cost model of a time-series databasemiddle
- Logs and volume: the cost model of structured loggingmiddle
- Traces and sampling: the cost model of distributed tracingmiddle
- Join keys and exemplars: making the three signals composemiddle
- Observability 2.0: wide events and the cost shiftsenior
- Failure modes and engineering practice: cardinality budgets, PII, and samplingsenior
- Why structured logs exist: the diary vs the spreadsheetjunior
- The production log schema: fields every line must carrymiddle
- Log levels and alert routingmiddle
- Sampling strategies and log costmiddle
- PII redaction and log injectionsenior
- Trace context propagation in logssenior
- OTel Logs Data Model and audit logs as a subsystemsenior
- OTel signals, Semantic Conventions, and the OTLP wire formatmiddle
- Auto-instrumentation and manual spans: the 80/20 of OTelmiddle
- The OTel Collector: receivers, processors, exporters, and deployment patternsmiddle
- Sampling strategies: head, tail, and parent-basedmiddle
- Vendor neutrality, eBPF instrumentation, the Operator, and browser/serverless OTelsenior
- Operating the OTel Collector: reliability, version skew, failure modes, and governancesenior
- RED and USE: two checklists, one triage disciplinejunior
- Instrumenting RED in Prometheus: counters, histograms, and cardinality disciplinemiddle
- USE on Linux: CPU, memory, disk, network, and PSImiddle
- Golden signals, dashboard layout, and service mesh auto-REDmiddle
- Cardinality as a cost driver: labels, PII, exemplars, and samplingmiddle
- Native histograms, SLO tie-in, and production failure patternsmiddle
- Choosing SLIs and SLO targets: ratios, not feelingsmiddle
- Multi-window multi-burn-rate alerting: why AND beats ORmiddle
- Error budget policy, latency SLOs, and composite journeysmiddle
- Iceberg SLIs, composite SLO math, and SLA vs SLOsenior
- Flame graphs: reading the picture that shows where time goesjunior
- Sampling vs instrumentation profiling: why 99 Hz wins in productionmiddle
- Profile types: CPU, memory, off-CPU, mutex — which one to reach formiddle
- Continuous profiling: always-on flame graphs with eBPF and trace-id correlationmiddle
- How flame graphs are built from samples, and the production workflows that use themmiddle
- Linux perf, eBPF internals, PGO, and the limits of samplingsenior
- Profiling in production: security, war stories, OTel profiles, and the infrastructure designsenior
- The debugging funnel: SLO → RED → trace → profilejunior
- OTel architecture: one SDK, four signals, one wire formatmiddle
- Cost discipline: keeping observability under 5% of infra spendmiddle
- Scale, security, and the ROI of observable systemssenior
- Why profile first: measure where time actually goesjunior
- Amdahl''''s law and self-time: the ceiling on every speedup you can shipmiddle
- The measurement loop: microbench, macrobench, prod profile, observer effectmiddle
- Reading flame graphs: shapes, per-language profilers, and the 60-second scanmiddle
- Statistical baselines: why one run is not a measurementmiddle
- Profiler history and microbenchmark pitfalls: Knuth to GWPsenior
- Hardware counters, cold-start profiles, and profile securitysenior
- Continuous profiling at scale: costs, CI gates, trace correlation, and anti-patternssenior
- What makes a hot path: symptom vs causejunior
- Five shapes of hotspot: CPU, alloc, cache, lock, syscallmiddle
- Reading parent and child chains: where to apply the fixmiddle
- JIT deopt, the fix-and-verify loop, and PR-time profilingmiddle
- Hardware counters and Intel TMA: sub-category diagnosissenior
- False sharing and native-bridge hot pathssenior
- Hot paths in production: security, tail latency, and tooling lineagesenior
- Memory hierarchy: why the same O(N) loop can be 17x slowerjunior
- Row-major vs column-major: access order and the 9x gapjunior
- Branch prediction and branchless codemiddle
- Hardware prefetcher, TLB, and memory-level parallelismsenior
- GC basics: what the runtime taxes you forjunior
- GC algorithms: generational, concurrent, and per-runtimemiddle
- GC tradeoffs: pause, throughput, heap — and object poolingmiddle
- GC tuning: pacing, heap shape, and allocation observabilitymiddle
- GC internals: tri-color invariant, write barriers, and per-runtime deep-divessenior
- GC in production: observability, security, edge cases, and fleet governancesenior
- N+1: one logical operation, many round-tripsjunior
- Fix families: JOIN, IN, preload, and DataLoadermiddle
- Detecting N+1: query logs, APM traces, and CI gatesmiddle
- DataLoader: batching across resolver treesmiddle
- Cross-protocol N+1: HTTP fan-out and Redis MGETmiddle
- N+1 at scale: pool exhaustion, plan changes, and denormalisationsenior
- 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
- What a bundle actually costs: download, parse, compile, executejunior
- Core Web Vitals: LCP, INP, and CLSmiddle
- Code splitting: route-level, component-level, vendor splittingmiddle
- Tree shaking and compression: removing what you don''''t usemiddle
- Third-party scripts: the silent budget killermiddle
- 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