What does NextNodeServer.createComponentTree span mean in OpenTelemetry scope

[abnud11]

Summary

In my Next.js app, I enabled instrumentation through OpenTelemetry, and I'm exporting traces to AWS X-Ray.
While viewing one of the traces, I saw a span called NextNodeServer.createComponentTree, its description is "build component tree", and it sometimes takes around 1 second

I'd like to optimise its performance, but I can't optimise what I don't understand.

What does this span exactly mean? What work does Next.js do during this span?
The child spans under this span are two spans with a huge gap between them, both are of the same "NextNodeServer.getLayoutOrPageModule" type with description "resolve segment modules"

Additional information

Next.js version: 16.0.1
Opentelemetry uses @vercel/otel
Deployment environment: I'm deploying Next.js to AWS Lambda using sst v3(https://github.com/sst/sst)
NodeJS version: 22(minor version depends on what AWS Lambda uses)

Example

No response

[magictalent]

The span NextNodeServer.createComponentTree represents the internal work Next.js does when building the React component tree for a specific route during the rendering process.

In more detail, this span covers:
Resolving and loading layout/page modules (which appear as the getLayoutOrPageModule child spans you saw).
Composing the React tree based on your route segment configuration — including nested layouts, pages, and any shared components defined in your app/ directory.
Initializing server components and collecting metadata such as generateMetadata, generateStaticParams, and data-fetching calls that happen during the tree build phase.

[abnud11]

I wish I could accept your answer, but while my route does a few requests to a backend service, those requests spans don't appear as children to NextNodeServer.createComponentTree, they don't even appear in the same time range, the traces show that NextNodeServer.createComponentTree happens and only after it finishes does Next.js start response and starts fetching data for the server components.

So maybe data-fetching calls are not part of this span?

[magictalent]

From what I’ve seen in the Next.js internals, that span mainly covers the phase where Next.js resolves and constructs the React component tree, including layouts, pages, and segments — but before it actually starts rendering or triggering async data dependencies.

The data-fetching for server components (for example, async calls in RSC or fetch() inside components) usually happens after the tree is built, during the render / flight generation phase, which appears under separate spans (often something like renderToReadableStream or renderToString).

So in your trace, it makes sense that createComponentTree completes first, and then the spans for your backend requests start — that sequence reflects Next.js building the tree first and only then starting to stream or resolve async parts.

It might be worth checking whether those fetches appear under spans related to RSC payload rendering rather than the component tree creation itself.

[abnud11]

So why would it take so much time for my specific page? How do I optimise it?

[magictalent]

NextNodeServer.createComponentTree span duration depends on how complex your route’s component hierarchy and data dependencies are.
Even though this phase doesn’t include the actual data fetching, it still involves:
Resolving all layout and page modules under the current route segment (recursive imports).
Running async module resolution for any dynamic imports.
Evaluating static exports like generateMetadata or generateStaticParams.
Preparing server component trees before rendering starts.
If your route has deeply nested layouts, multiple generateMetadata functions, or many dynamic imports, this step can easily add latency (especially in serverless environments where cold start and file I/O matter).
Optimization ideas:

1. Reduce nesting — simplify your layout hierarchy where possible.

2. Avoid dynamic imports in layouts if not necessary.

3. Move heavy generateMetadata logic (e.g. DB calls or fetches) into a cached helper.

4. Precompute static data during build instead of resolving at runtime.

5. If you’re on AWS Lambda or Vercel, enable provisioned concurrency or keep warm functions to reduce cold-start time.

You can confirm which parts are slow by checking for gaps between getLayoutOrPageModule spans — large gaps there usually mean slow module resolution or layout initialization.