JavaScript Runtime Performance: V8 Where It Costs
Serialization, allocation and shape changes dominate real server-side JavaScript cost far more often than algorithmic choices. The engine optimizes aggressively for predictable code and deoptimizes quietly when you surprise it.
Frame the diagnosis
Performance work starts from a symptom and a signal — never from a resource dashboard.
Where the time actually goes in a typical service
Profile a typical JSON-over-HTTP Node service under load and the top of the profile is rarely business logic. It is serialization and deserialization, object allocation, and the garbage collection that allocation causes. The interesting consequence is that the highest-leverage optimizations are usually about *how much data moves through the process*, not about the algorithms operating on it.
JSON.stringify and JSON.parse are the usual leaders. They are implemented natively and are fast per byte, but they are called on every request and their cost scales with payload size — so an endpoint returning 500KB pays a serialization tax on every single call, plus the allocation of that string, plus the GC to reclaim it. Trimming a response from 500KB to 40KB is often a larger win than any algorithmic change in the same handler, and it shows up simultaneously in CPU, GC and network.
The practical ordering, then: measure payload sizes before micro-optimizing loops. Payload Size: 20KB, 200KB, 5MB and Over-Fetching and Under-Fetching are performance lessons as much as API design ones, and this is where the two domains meet.
| Signal | Value | What it tells you | Verdict |
|---|---|---|---|
| JSON.stringify (native) | 31% | Response serialization. Scales with payload size, paid on every request. | smoking gun |
| GC (mark + sweep) | 19% | Caused mostly by the strings and objects the line above creates. | smoking gun |
| JSON.parse (native) | 11% | Request deserialization, plus re-parsing cached values that were stored as strings. | suspect |
| ORM row mapping | 14% | Object construction per row — allocation-heavy, and proportional to rows fetched. | suspect |
| application handlers | 9% | The code the team actually wrote and would have optimized first. | normal |
| crypto (TLS, hashing) | 8% | Expected for an HTTPS service; not the lever here. | normal |
Shapes, and why predictable objects are faster
V8 tracks the *shape* of objects — which properties they have, in which order — and uses that to compile fast property access. Code that repeatedly sees objects of the same shape gets specialized machine code with direct offsets. Code that sees many different shapes at the same call site becomes "megamorphic" and falls back to slower generic lookup.
The practical rules that follow are mundane: initialize all properties in the constructor rather than adding them later, keep property insertion order consistent, avoid delete on hot objects, and do not use plain objects as growable dictionaries in hot paths (use Map, which is designed for it). None of these are exotic — they mostly coincide with code that is clearer anyway.
The honest caveat is important here. These are engine heuristics, not language semantics; they have changed across V8 versions and will change again. Write code that is predictable because predictable code is also easier to read, and let the profile — not folklore — decide whether a shape problem is real. Any advice of the form "V8 optimizes X" is worth a version number and a measurement.
1function toDto(row: Row) {2 const o: any = {}3 o.id = row.id4 if (row.name) o.name = row.name // property sometimes present5 if (row.email) o.email = row.email // and sometimes not6 if (row.isAdmin) o.role = 'admin' // -> several distinct shapes7 delete o.internalFlag // deletion degrades the shape further8 return o9}10 11// Downstream code touching o.name sees many shapes at one call site12// and cannot use a specialized fast path.1interface UserDto {2 id: string3 name: string | null4 email: string | null5 role: 'admin' | 'member'6}7 8function toDto(row: Row): UserDto {9 return { // all properties, same order, every time10 id: row.id,11 name: row.name ?? null,12 email: row.email ?? null,13 role: row.isAdmin ? 'admin' : 'member',14 }15}16 17// One shape reaches every downstream call site.18// It is also the version a reviewer can reason about.The second version gives the engine a single stable shape *and* gives the reader a single stable type. Where a micro-optimization and clear code disagree, prefer the profile; here they happen to agree, which is why this rule is worth following by default rather than as a tuning step.
The measurements worth taking first
Three numbers explain most server-side JavaScript performance questions before any code is read: p99 event-loop lag (Event-Loop Lag: One Callback, Everybody Waits), allocation rate, and payload sizes in and out. Between them they cover blocking, GC pressure, and the serialization cost that drives both.
A CPU profile is the fourth, and it should be read by *self time* rather than total time. Total time attributes everything to main, which is true and useless. Self time shows where cycles actually land, and in Node that answer is frequently a native function called from application code rather than the application code itself — which is exactly the finding that redirects effort from loops to payloads.
For long-lived services, sample profiles continuously rather than capturing them during incidents (Always-On Profiling, and the Diff That Finds Regressions). By the time someone attaches a profiler to a struggling process, the process is usually behaving differently from the one that caused the alert, and the profile describes the recovery rather than the problem.
| Measurement | Answers | Typical finding | Next step |
|---|---|---|---|
| p99 event-loop lag | Is anything blocking the loop? | Sync parse, crypto or compression on the request path | Event-Loop Lag: One Callback, Everybody Waits |
| Allocation rate | Are we creating pressure for the collector? | Serialization and per-row object mapping dominate | Allocation Rate Is a Cost Even Without a Leak, Garbage Collection: Pause, Throughput, Footprint — Pick Two |
| Payload sizes (in / out) | How much data crosses the boundary per request? | Responses far larger than any client uses | Payload Size: 20KB, 200KB, 5MB, Over-Fetching and Under-Fetching |
| CPU profile by self time | Where do cycles actually land? | Native serialization above all application frames | Self Time, Total Time, and Where the CPU Went, Reading a Flame Graph |
Key points
- In typical Node services, serialization, allocation and GC dominate the profile — usually above any function the team wrote.
- Response payload size is a CPU lever, not only a network one: it drives serialization cost, allocation and collection together.
- V8 specializes property access by object shape; consistent, fully-initialized objects keep call sites on the fast path.
- Shape advice is engine heuristics with version-dependent behaviour — follow it because it is also clearer code, and verify with a profile.
- Read CPU profiles by self time; total time attributes everything to the entry point and hides where cycles land.
Follow the diagnosis
The causal chain, hop by hop — and the readings that invite the wrong conclusion.
- 1Handler → serializer: each response materializes a 500KB object graph and stringifies it, once per request.
- 2Serializer → allocator: the resulting strings and intermediate objects push allocation rate high enough to drive frequent collection.
- 3Allocator → collector: GC self time reaches ~19% of process CPU, capacity spent on garbage rather than on requests.
- 4Serialization + GC → loop: both run on the event loop, so p99 lag rises and every endpoint degrades together (Event-Loop Lag: One Callback, Everybody Waits).
- 5Loop → users: p99 climbs across the service while p50 stays acceptable, because only requests overlapping the expensive work absorb the delay.
- • "The application code is only 9% of the profile, so there is nothing to optimize" — the application code *causes* the 31% in serialization by choosing what to return.
- • "CPU is high, we need bigger instances" — a fifth of the CPU is collecting garbage created by payloads nobody reads.
- • "V8 optimizes this away" — folklore without a version number and a measurement is not a plan.
- • "Total time in the profile shows
mainat 100%, so the entry point is slow" — read self time; total time is definitionally uninformative at the root. - • "We profiled during the incident and found nothing" — a struggling process often profiles as a recovering process; sample continuously instead.
Measure, fix, validate
An optimization is not finished until the metric that motivated it has moved.
- • p99 event-loop lag first, since a blocked loop explains global symptoms that no per-endpoint analysis will.
- • Allocation rate in bytes/s plus an allocation profile attributing it to call sites.
- • Request and response payload sizes as histograms per route, which is usually the highest-leverage number in the list.
- • A CPU profile read by self time, ideally sampled continuously rather than captured during an incident.
- • GC CPU percentage, to quantify how much of the machine allocation is costing you.
- • Reduce response payloads to what clients actually consume, which cuts serialization CPU, allocation, GC and network in one change.
- • Avoid re-serializing data that is already a string, and cache serialized representations where the underlying data is stable.
- • Stream large responses rather than materializing them, keeping peak allocation bounded regardless of result size.
- • Keep hot-path objects to a single stable shape, initialized in one place, avoiding `delete` and late property addition.
- • Move genuinely CPU-heavy work off the loop entirely, per [[event-loop-lag]].
- • Serialization self time falls as a proportion of the profile, and GC self time falls with it — the two should move together.
- • Allocation rate drops roughly in proportion to the payload reduction, confirming the causal chain rather than a coincidental improvement.
- • p99 latency improves across endpoints, not just the one that was changed, which confirms the shared resource (loop, collector) was the constraint.
- • Throughput at fixed CPU rises, which is the capacity-terms proof that reclaimed cycles went back to serving requests.
- • Trimming responses can break clients that depended on fields they never officially needed, so it is an API compatibility question as well as a performance one.
- • Caching serialized representations trades memory and staleness for CPU, and introduces an invalidation problem.
- • Streaming complicates error handling: a failure partway through a response cannot be turned into a clean error status.
- • Shape-stable object construction can mean allocating fields that are usually null, a small memory cost for a fast-path benefit.
- • Response size histograms per route with an alert on growth, since payloads grow silently as features add fields.
- • Allocation rate tracked per deploy, so a serialization regression is visible before it becomes a latency incident.
- • Continuous profiling retained across releases, making a shifted profile shape a reviewable diff rather than a discovery.
- • A load test asserting p99 event-loop lag and per-request allocation ceilings in CI.
Accuracy
Performance numbers are conditional. These are the conditions.
- RUNTIME-SPECIFICAll of this is V8 as used by Node.js. Optimization heuristics, hidden-class behaviour and native function performance change between V8 versions; verify against your runtime rather than treating any of it as a specification.
- ILLUSTRATIVEThe profile percentages are a plausible shape for a JSON API, not a measurement of any real service. Your profile is the only authority on your service.