Technical performance analysis of the latest Node.js release.
Why Async Hooks Deserve Another Look
Async Hooks give you a way to track the lifecycle of asynchronous resources as they are created, run their callbacks, and are destroyed. That visibility is what makes context propagation, request-scoped tracing, and diagnostic tooling possible in a runtime where a single logical operation is spread across many event-loop ticks. The tradeoff has always been cost: every async resource in the process pays a small tax whenever the hooks are active, and in a hot path that tax adds up.
Re-evaluating Async Hooks in the current release means asking two separate questions. First, how much overhead does the mechanism impose when it is enabled but doing little? Second, how much of what people historically reached into Async Hooks for can now be handled by higher-level abstractions built on top of it?
What Actually Costs You
The performance of Async Hooks is dominated by how many async resources your workload creates and how much work your hook callbacks do per resource. A service that opens a connection, awaits a few promises, and responds is cheap to instrument. A service that fans out into thousands of concurrent async operations, each triggering init and destroy callbacks, is where the overhead becomes measurable.
When profiling, separate the cost of the runtime tracking async context from the cost of your own callback logic. It is common to blame the hooks themselves when the real expense is a heavy callback running on every resource creation. A few practical checks:
- Confirm whether hooks are enabled globally or only around the code that needs them.
- Measure the per-resource callback duration, not just aggregate request latency.
- Watch for accidental resource amplification — libraries that create many short-lived async handles.
Prefer the Abstraction Over the Primitive
Most application code does not need the raw hook callbacks. If your goal is to carry a request identifier or user context across awaits, the context-tracking abstraction layered on top of Async Hooks is usually the better fit. It exposes the propagation behavior you want while letting the runtime manage the tracking in a more optimized path, which reduces the surface area where your own code can introduce overhead.
Reserve direct use of the low-level hooks for diagnostic and observability tooling that genuinely needs to see every resource lifecycle event. For everything else, treating the primitive as an implementation detail keeps your code simpler and gives the runtime room to make the mechanism faster underneath you.
How to Approach the Upgrade
Do not assume a performance report changes your numbers until you measure your own workload. Establish a baseline on your current version, then run the same load profile after upgrading, holding the instrumentation constant so you are comparing the runtime and not your configuration. Pay attention to tail latency and event-loop delay, since async-tracking overhead tends to show up there before it shows up in average response time.
If your service leans heavily on context propagation, test with your tracing enabled rather than in a clean benchmark. The realistic question is not whether Async Hooks are fast in isolation, but whether your instrumented application meets its latency budget under production-like concurrency.