From 1a2ec0b6385de7a27cd2b3d1e6804d2afa60b1e0 Mon Sep 17 00:00:00 2001
From: Marko Lahma <marko.lahma@gmail.com>
Date: Fri, 14 Aug 2026 10:49:52 +0300
Subject: [PATCH 1/5] Update Jint to 4.16.0

Two of the engine's changes land on the render path without anything here
having to ask for them. A repeat import no longer goes through the module
loader: the engine records the referrer and specifier the first time it loads
a module and answers later imports from that record, so the Resolve this
renderer performs twice per render -- once for the framework's server entry,
once for the view -- along with the full path and the Uri it builds each time,
is gone. The rest is interpreter work the views sit on: the cheapest built-in
calls run without a frame, a function's own let and const live in fixed slots,
and resolving an inherited global no longer allocates a string for the name.

It also brings the two APIs this project had to hand-write against, which the
next commits adopt.
---
 src/JsxCore/JsxCore.csproj | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/JsxCore/JsxCore.csproj b/src/JsxCore/JsxCore.csproj
index 3c3a2a5..797df8b 100644
--- a/src/JsxCore/JsxCore.csproj
+++ b/src/JsxCore/JsxCore.csproj
@@ -64,7 +64,7 @@
   </ItemGroup>
 
   <ItemGroup>
-    <PackageReference Include="Jint" Version="4.15.3" />
+    <PackageReference Include="Jint" Version="4.16.0" />
   </ItemGroup>
 
   <!--

From 037d7e42f9d9f96011620a7817b0306ef74fd40b Mon Sep 17 00:00:00 2001
From: Marko Lahma <marko.lahma@gmail.com>
Date: Fri, 14 Aug 2026 10:50:54 +0300
Subject: [PATCH 2/5] Ask the engine what a module is called instead of
 deriving it here

A prepared module is named when it is prepared, and that name is what the
engine hands back as the referencing location when the module's own relative
imports are resolved. Deriving it here meant keeping a copy of a rule this
project does not own: a name that differs from the engine's by a character
sends every relative import in that module to the wrong base directory, with
nothing in the error to say why.

Jint 4.16 publishes the rule as ModuleFactory.LocationOf for this reason. It
agrees with the copy for every specifier resolved here, which all carry an
absolute file Uri, and it keeps agreeing if that ever stops being true.
---
 src/JsxCore/Rendering/JsxModuleLoader.cs | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/JsxCore/Rendering/JsxModuleLoader.cs b/src/JsxCore/Rendering/JsxModuleLoader.cs
index dd3467f..dceaa9c 100644
--- a/src/JsxCore/Rendering/JsxModuleLoader.cs
+++ b/src/JsxCore/Rendering/JsxModuleLoader.cs
@@ -161,8 +161,8 @@ public Module LoadModule(Engine engine, ResolvedSpecifier resolved)
 
         // The name the engine gives back as the referencing location when this module's own
         // relative imports are resolved, so it has to be the one the engine would have derived
-        // from the resolved specifier itself.
-        var location = resolved.Uri?.LocalPath ?? resolved.Key;
+        // from the resolved specifier itself. LocationOf is that rule, published for exactly this.
+        var location = ModuleFactory.LocationOf(resolved);
         var prepared = _modules.GetOrParse(location, () => ReadSource(resolved.Key));
         return ModuleFactory.BuildSourceTextModule(engine, in prepared);
     }
@@ -231,7 +231,7 @@ private Module LoadPackageModule(Engine engine, ResolvedSpecifier resolved)
 
         // What is cached is the module as the engine sees it, after the CommonJS wrapping, so a
         // second engine pays for neither the read nor the transform.
-        var location = resolved.Uri?.LocalPath ?? resolved.Key;
+        var location = ModuleFactory.LocationOf(resolved);
         var prepared = _modules.GetOrParse(
             location,
             () => ModuleTransform.Apply(path, kind, File.ReadAllText(path), new EngineSpecifierRewriter(npm)).Source);

From b3f03d5891873de2209c76f42d5cfe77d5edc0bf Mon Sep 17 00:00:00 2001
From: Marko Lahma <marko.lahma@gmail.com>
Date: Fri, 14 Aug 2026 10:52:34 +0300
Subject: [PATCH 3/5] Take the whole-render deadline from the engine instead of
 keeping one here

The render's own budget was a hand-written constraint: armed before the engine
goes to work, cleared when it returns to the pool, and deliberately deaf to the
per-entry reset the engine performs every time the host calls in. Jint 4.16
ships that shape as OperationDeadlineConstraint, down to the details that made
it worth writing -- a non-positive budget means no budget rather than one that
has already run out, a budget too large to add to the clock is clamped instead
of overflowing into the past, an aborted token raises a real
OperationCanceledException so a host filtering for one still sees it, and the
constraint stays cheap enough for the engine to keep its tight-loop path.

So there is nothing left here worth maintaining a copy of, only a message: the
engine reports that a budget elapsed without saying whose, and a host reading
the log wants to know it was the render timeout it configured. The render says
that itself and keeps the engine's own report underneath, so the exception a
caller catches is unchanged.
---
 src/JsxCore/Rendering/JsxServerRenderer.cs | 18 ++++-
 src/JsxCore/Rendering/RenderDeadline.cs    | 86 ----------------------
 2 files changed, 16 insertions(+), 88 deletions(-)
 delete mode 100644 src/JsxCore/Rendering/RenderDeadline.cs

diff --git a/src/JsxCore/Rendering/JsxServerRenderer.cs b/src/JsxCore/Rendering/JsxServerRenderer.cs
index 2ada394..d8ab664 100644
--- a/src/JsxCore/Rendering/JsxServerRenderer.cs
+++ b/src/JsxCore/Rendering/JsxServerRenderer.cs
@@ -2,6 +2,7 @@
 using System.Text.Json;
 using Acornima.Ast;
 using Jint;
+using Jint.Constraints;
 using Jint.Native;
 using Jint.Runtime;
 using Jint.Runtime.Interop;
@@ -186,6 +187,14 @@ private ServerRenderResult Render(
                 $"JsxCore failed to server-render '{view.ViewName}': {ex.Message}{Environment.NewLine}" +
                 $"{ex.JavaScriptStackTrace}", ex);
         }
+        catch (TimeoutException ex)
+        {
+            // The engine reports an elapsed budget in its own words, which do not say whose budget
+            // it was. Which one ran out is the part a host can act on, so the render says it.
+            throw new JsxRenderException(
+                $"JsxCore failed to server-render '{view.ViewName}'.",
+                new TimeoutException("The render exceeded the configured server rendering timeout.", ex));
+        }
         catch (Exception ex) when (ex is not OperationCanceledException)
         {
             throw new JsxRenderException($"JsxCore failed to server-render '{view.ViewName}'.", ex);
@@ -316,7 +325,12 @@ private PooledEngine CreateEngine(string buildId)
             _moduleCache.Get(buildId, static () => new ServerModuleCache()));
 
         var settings = _options.ServerRendering;
-        var deadline = new RenderDeadline();
+
+        // One budget for the whole render rather than one per entry into the engine. The engine
+        // resets its constraints at every entry from the host, and a render enters several times,
+        // so a plain timeout would give each entry the configured budget over again; this one is
+        // armed by the host and declines that reset.
+        var deadline = new OperationDeadlineConstraint();
 
         var engine = new Engine(options =>
         {
@@ -398,5 +412,5 @@ private sealed record PooledEngine(
         Engine Engine,
         string BuildId,
         GlobalSnapshot CleanGlobals,
-        RenderDeadline Deadline);
+        OperationDeadlineConstraint Deadline);
 }
diff --git a/src/JsxCore/Rendering/RenderDeadline.cs b/src/JsxCore/Rendering/RenderDeadline.cs
deleted file mode 100644
index 85bfc2d..0000000
--- a/src/JsxCore/Rendering/RenderDeadline.cs
+++ /dev/null
@@ -1,86 +0,0 @@
-using System.Diagnostics;
-using Jint;
-
-namespace JsxCore.Rendering;
-
-/// <summary>
-/// The time budget for one render, and the request it belongs to.
-/// </summary>
-/// <remarks>
-/// The engine re-arms its built-in timeout at every entry from the host, and a render enters the
-/// engine several times, so a configured timeout used to bound each entry rather than the render.
-/// This holds one deadline for the whole render: armed before the engine goes to work, cleared
-/// when it returns to the pool, and deliberately untouched by the engine's own per-entry reset.
-/// It also watches the request's abort token, so a client that has gone away stops paying for
-/// JavaScript it will never receive.
-/// </remarks>
-internal sealed class RenderDeadline : Constraint
-{
-    /// <summary>A budget that never runs out, which is how an unarmed engine sits in the pool.</summary>
-    private const long Disarmed = 0;
-
-    private long _deadline;
-    private CancellationToken _aborted;
-
-    /// <summary>
-    /// Reads a clock and a token without consuming anything, so the engine may check on its
-    /// amortised cadence.
-    /// </summary>
-    public override bool IsAmortizable => true;
-
-    /// <summary>Arms the budget for one render.</summary>
-    /// <remarks>
-    /// A timeout of zero or less asks for no budget at all, which is what
-    /// <see cref="Timeout.InfiniteTimeSpan"/> means and what the engine's own timeout did with one.
-    /// Arming it arithmetically instead would put the deadline at or before the render's own start
-    /// and end every render the moment it began.
-    /// </remarks>
-    public void Begin(TimeSpan timeout, CancellationToken aborted)
-    {
-        _aborted = aborted;
-
-        if (timeout <= TimeSpan.Zero)
-        {
-            _deadline = Disarmed;
-            return;
-        }
-
-        var start = Stopwatch.GetTimestamp();
-        var budget = timeout.TotalSeconds * Stopwatch.Frequency;
-
-        // A budget too large to add to the clock is one no render was ever going to reach, so it
-        // becomes the furthest deadline there is rather than an overflowed one in the past.
-        _deadline = budget >= long.MaxValue - start
-            ? long.MaxValue
-            : Math.Max(start + (long) budget, Disarmed + 1);
-    }
-
-    /// <summary>Disarms the budget, so a pooled engine carries no deadline between renders.</summary>
-    public void End()
-    {
-        _deadline = Disarmed;
-        _aborted = default;
-    }
-
-    /// <inheritdoc />
-    public override void Check()
-    {
-        if (_aborted.IsCancellationRequested)
-        {
-            throw new OperationCanceledException(_aborted);
-        }
-
-        if (_deadline != 0 && Stopwatch.GetTimestamp() >= _deadline)
-        {
-            throw new TimeoutException("The render exceeded the configured server rendering timeout.");
-        }
-    }
-
-    /// <summary>
-    /// Does nothing, deliberately. The engine resets constraints at every entry from the host, and
-    /// this budget belongs to the whole render rather than to any one entry into the engine.
-    /// </summary>
-    public override void Reset()
-    {
-    }
-}

From e93b444fade4d198453940a97813e406928ef246 Mon Sep 17 00:00:00 2001
From: Marko Lahma <marko.lahma@gmail.com>
Date: Fri, 14 Aug 2026 10:57:57 +0300
Subject: [PATCH 4/5] Build the .NET globals bridge only for the renders that
 read it

A registered global is resolved from the request's service scope, so it can be
a database context, a localizer, or anything else the scope builds on demand.
Every render resolved all of them and wrapped each one for the engine, whether
the view asked or not -- and most views ask for none. An application that
registers six globals paid for six service resolutions and six wrappers to
render a page that mentions none of them.

The JavaScript side was already lazy about this: dotnet:globals hands out
proxies that touch the bridge only when a member is read, which is what lets a
client-rendered view import a global harmlessly. The host is now lazy in the
same way. The engine holds the global as a factory declared once per engine,
run the first time a view reads it and not at all otherwise.

Declaring it before the engine's clean surface is captured is what makes it a
per-render bridge with no per-render write. Returning an engine to the pool
restores that surface, which puts an unresolved lazy global back to unresolved,
so the next render resolves against the next request's scope -- the behaviour
the two tests for a global held at module scope already pin. Installed after
the capture instead, it would be a property the restore removes and the next
render adds again, which is a mutation of the global object per render and
costs every warmed global lookup in the engine its cached answer.

The bridge is built as a whole on first read rather than a member at a time, so
a view reading one of six globals still resolves six. That is the next step
rather than this one; the step here is that a view reading none resolves none.
---
 src/JsxCore/Rendering/JsxServerRenderer.cs    | 81 +++++++++++++----
 .../Component/Rendering/GlobalsBridgeTests.cs | 91 +++++++++++++++++++
 2 files changed, 154 insertions(+), 18 deletions(-)
 create mode 100644 test/JsxCore.Tests/Component/Rendering/GlobalsBridgeTests.cs

diff --git a/src/JsxCore/Rendering/JsxServerRenderer.cs b/src/JsxCore/Rendering/JsxServerRenderer.cs
index d8ab664..69a1f89 100644
--- a/src/JsxCore/Rendering/JsxServerRenderer.cs
+++ b/src/JsxCore/Rendering/JsxServerRenderer.cs
@@ -9,6 +9,7 @@
 using JsxCore.Compilation;
 using JsxCore.Compilation.Assets;
 using JsxCore.Compilation.Modules;
+using JsxCore.Interop;
 using JsonParser = Jint.Native.Json.JsonParser;
 
 namespace JsxCore.Rendering;
@@ -132,14 +133,20 @@ private async Task<ServerRenderResult> ExecuteAsync(
         {
             var buildId = _compilation.BuildId;
             var pooled = Rent(buildId);
+
+            // The scope the engine's globals bridge resolves from, for as long as this render holds
+            // the engine. Cleared afterwards so an engine waiting in the pool is not holding on to
+            // a request whose scope has ended.
+            pooled.Globals.Services = services;
             pooled.Deadline.Begin(_options.ServerRendering.Timeout, cancellationToken);
             try
             {
-                return Render(pooled.Engine, view, modelJson, contextJson, services, entryPoint);
+                return Render(pooled.Engine, view, modelJson, contextJson, entryPoint);
             }
             finally
             {
                 pooled.Deadline.End();
+                pooled.Globals.Services = null;
                 Return(pooled);
             }
         }
@@ -154,13 +161,10 @@ private ServerRenderResult Render(
         LocatedView view,
         string modelJson,
         string contextJson,
-        IServiceProvider services,
         string entryPoint)
     {
         try
         {
-            InstallGlobals(engine, services);
-
             var parser = new JsonParser(engine);
             var props = new JsObject(engine);
             props.Set("model", parser.Parse(modelJson));
@@ -216,22 +220,49 @@ private ServerRenderResult Render(
     /// <summary>The object the registered .NET globals are installed on, for one render.</summary>
     private const string GlobalsName = "__jsxcore_dotnet";
 
-    private void InstallGlobals(Engine engine, IServiceProvider services)
+    /// <summary>
+    /// The .NET side of the globals bridge for one pooled engine: what the application registered,
+    /// and which request's scope the render currently holding the engine resolves it from.
+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// The registered objects come from the request's service scope, so one of them can be a
+    /// database context, a localizer, or anything else a scope builds on demand — and most views
+    /// read none of them. Building the bridge is therefore left until a view asks for it: the
+    /// engine holds the global as a factory, and a render that never mentions <c>dotnet:globals</c>
+    /// resolves no service and builds no wrapper. Importing one is not asking for it either, since
+    /// the JavaScript side hands out proxies that reach this only when a member is read.
+    /// </para>
+    /// <para>
+    /// Read at the moment a view asks, rather than captured per render, so a global registered
+    /// after startup is still reachable — which is what the catch-all export exists for.
+    /// </para>
+    /// </remarks>
+    private sealed class GlobalsBridge(JsxGlobalRegistry globals)
     {
-        var registrations = _options.Globals.Registrations;
-        if (registrations.Count == 0)
-        {
-            engine.SetValue(GlobalsName, JsValue.Undefined);
-            return;
-        }
+        /// <summary>The scope of the render holding this engine, or null between renders.</summary>
+        public IServiceProvider? Services { get; set; }
 
-        var globals = new JsObject(engine);
-        foreach (var (name, registration) in registrations)
+        public JsValue Build(Engine engine)
         {
-            globals.Set(name, JsValue.FromObject(engine, registration.Factory(services)));
-        }
+            var registrations = globals.Registrations;
+            var services = Services;
+
+            if (services is null || registrations.Count == 0)
+            {
+                // What an application that registered nothing has always presented, and what the
+                // runtime reads as "there is nothing here to reach" when a view asks anyway.
+                return JsValue.Undefined;
+            }
+
+            var bridge = new JsObject(engine);
+            foreach (var (name, registration) in registrations)
+            {
+                bridge.Set(name, JsValue.FromObject(engine, registration.Factory(services)));
+            }
 
-        engine.SetValue(GlobalsName, globals);
+            return bridge;
+        }
     }
 
     private PooledEngine Rent(string buildId)
@@ -358,12 +389,21 @@ private PooledEngine CreateEngine(string buildId)
         // and isServerRender() used to answer that wrongly.
         engine.SetValue(ServerFlag, true);
 
+        // Declared once for the engine, and before the snapshot below, which is what makes it a
+        // per-render bridge without a per-render write: the engine resolves the factory the first
+        // time a view reads the global and not at all otherwise, and returning the engine to the
+        // pool puts the property back to unresolved, so the next render resolves against the next
+        // request's scope. Installed after the snapshot instead, it would be a global the restore
+        // has to remove and the next render has to add again.
+        var globals = new GlobalsBridge(_options.Globals);
+        engine.Advanced.AddLazyGlobal(GlobalsName, globals, static (engine, globals) => globals.Build(engine));
+
         // Taken last, so that everything above it is part of what the engine is built with: a render
         // returning the engine to the pool restores this surface, and the shims and the flag have to
         // survive that rather than be swept away with the render's own leavings.
         var cleanGlobals = engine.Advanced.CaptureGlobalSnapshot();
 
-        return new PooledEngine(engine, buildId, cleanGlobals, deadline);
+        return new PooledEngine(engine, buildId, cleanGlobals, deadline, globals);
     }
 
     private static IEnumerable<string> MemberNames(System.Reflection.MemberInfo member)
@@ -408,9 +448,14 @@ public void Dispose()
     /// <param name="Deadline">
     /// The engine's own time budget, armed for the render currently holding it.
     /// </param>
+    /// <param name="Globals">
+    /// The engine's bridge to the registered .NET objects, pointed at the scope of the render
+    /// currently holding it.
+    /// </param>
     private sealed record PooledEngine(
         Engine Engine,
         string BuildId,
         GlobalSnapshot CleanGlobals,
-        OperationDeadlineConstraint Deadline);
+        OperationDeadlineConstraint Deadline,
+        GlobalsBridge Globals);
 }
diff --git a/test/JsxCore.Tests/Component/Rendering/GlobalsBridgeTests.cs b/test/JsxCore.Tests/Component/Rendering/GlobalsBridgeTests.cs
new file mode 100644
index 0000000..5b7a9b5
--- /dev/null
+++ b/test/JsxCore.Tests/Component/Rendering/GlobalsBridgeTests.cs
@@ -0,0 +1,91 @@
+using JsxCore.Rendering;
+using JsxCore.Tests.Fixtures;
+using Microsoft.Extensions.DependencyInjection;
+using Shouldly;
+
+namespace JsxCore.Tests.Component.Rendering;
+
+/// <summary>
+/// What a registered .NET global costs a render: whatever the view actually reads, and nothing at
+/// all for the views that read none.
+/// </summary>
+/// <remarks>
+/// A registration is resolved from the request's service scope, so it can be a database context, a
+/// localizer or anything else a scope builds on demand. Most views in an application read none of
+/// them, and every view that renders while one is registered used to pay for all of them.
+/// </remarks>
+public class GlobalsBridgeTests
+{
+    public sealed class Clock
+    {
+        public string Now() => "tick";
+    }
+
+    [Fact]
+    public async Task RegisteredGlobal_ImportedButNeverRead_IsNotResolved()
+    {
+        using var project = JsxProjectFixture.Create();
+        project.Options.TypeChecking = TypeCheckingMode.Off;
+
+        var resolutions = 0;
+        project.Options.Globals.Register("Clock", _ =>
+        {
+            resolutions++;
+            return new Clock();
+        });
+
+        // Imports the global and holds it, which is what a view sharing a module with one that does
+        // use it looks like. Nothing here reads a member, so nothing here needs the instance.
+        project.AddView("Home/Index.tsx", """
+            import { Clock } from "dotnet:globals";
+            const held = Clock;
+            export default function Index() { return <p>{typeof held}</p>; }
+            """);
+
+        await project.CompileAsync();
+
+        var renderer = project.CreateServerRenderer();
+        var services = new ServiceCollection().BuildServiceProvider();
+        var view = project.Locate("Home/Index");
+
+        await renderer.RenderAsync(view, null, new Dictionary<string, object?>(), services);
+        var second = await renderer.RenderAsync(view, null, new Dictionary<string, object?>(), services);
+
+        second.Html.ShouldBe("<p>object</p>");
+        resolutions.ShouldBe(0);
+    }
+
+    [Fact]
+    public async Task RegisteredGlobal_ReadByTheView_IsResolvedOncePerRender()
+    {
+        using var project = JsxProjectFixture.Create();
+        project.Options.TypeChecking = TypeCheckingMode.Off;
+
+        var resolutions = 0;
+        project.Options.Globals.Register("Clock", _ =>
+        {
+            resolutions++;
+            return new Clock();
+        });
+
+        // Read twice, so a bridge resolved per read rather than per render would be caught.
+        project.AddView("Home/Index.tsx", """
+            import { Clock } from "dotnet:globals";
+            export default function Index() {
+                return <p>{(Clock as any).Now()}{(Clock as any).Now()}</p>;
+            }
+            """);
+
+        await project.CompileAsync();
+
+        var renderer = project.CreateServerRenderer();
+        var services = new ServiceCollection().BuildServiceProvider();
+        var view = project.Locate("Home/Index");
+
+        await renderer.RenderAsync(view, null, new Dictionary<string, object?>(), services);
+        var second = await renderer.RenderAsync(view, null, new Dictionary<string, object?>(), services);
+
+        second.Html.ShouldBe("<p>ticktick</p>");
+        resolutions.ShouldBe(2);
+    }
+}

From c5633bb92fcd4c6bce40142af07d2c666826ecb7 Mon Sep 17 00:00:00 2001
From: Marko Lahma <marko.lahma@gmail.com>
Date: Fri, 14 Aug 2026 11:05:03 +0300
Subject: [PATCH 5/5] Prepare modules the cheaper way while the views can still
 be recompiled

Preparing a module does two walks: the parse, and an analysis pass that writes
the interpreter's own bookkeeping onto the tree it produced. The second costs
about as much as the first, and it is paid once for a parse however many
engines go on to read it -- so it is a trade rather than a saving, and which
way it falls depends on how many engines that is.

An application being developed answers that badly. Every edit recompiles, and
every recompile throws this compilation's parses away for a new set that one
or two engines will read before the next edit does it again, so the analysis
is paid for readers who never arrive. A server that will not recompile answers
it the other way: its parses last for the life of the pool and every engine in
it reads them.

Measured on this branch, same binary with the flag on and off, Preact first
and React after it. One engine: -16.7% and -26.0% to build it and render.
Four: -28.3% and -24.4%. Sixteen, which no dev loop reaches: the time is still
-20.3% and -7.4%, but the allocation has crossed over to +6.9% and +1.1%,
because the part each engine does for itself is paid sixteen times while the
parse it saves is paid once. Steady-state rendering is untouched either way,
to the byte.

Watching is the difference between those two shapes, and it is already the
flag that says which one this is. Nothing about what a view renders changes
either way, which the two new tests state -- including several engines
rendering at once from one shared parse, since with the analysis declined they
fill in that state themselves as they reach it.
---
 src/JsxCore/Rendering/JsxServerRenderer.cs    | 10 +-
 src/JsxCore/Rendering/ServerModuleCache.cs    | 22 ++++-
 .../Rendering/ParseOnlyPreparationTests.cs    | 92 +++++++++++++++++++
 3 files changed, 121 insertions(+), 3 deletions(-)
 create mode 100644 test/JsxCore.Tests/Component/Rendering/ParseOnlyPreparationTests.cs

diff --git a/src/JsxCore/Rendering/JsxServerRenderer.cs b/src/JsxCore/Rendering/JsxServerRenderer.cs
index 69a1f89..abc0bb0 100644
--- a/src/JsxCore/Rendering/JsxServerRenderer.cs
+++ b/src/JsxCore/Rendering/JsxServerRenderer.cs
@@ -349,11 +349,19 @@ private static void Discard(PooledEngine engine)
 
     private PooledEngine CreateEngine(string buildId)
     {
+        // Watching means the views can be recompiled while the application runs, and every rebuild
+        // throws this compilation's parsed modules away for a new set that one or two engines will
+        // read before the next edit does the same. Preparing those the cheaper way is worth more
+        // than the bookkeeping the fuller preparation would hand each engine. A server that will
+        // not recompile keeps its parses for the life of the pool, which is where the fuller
+        // preparation earns back what it costs.
+        var staticAnalysis = _options.WatchForChanges != true;
+
         var loader = new JsxModuleLoader(
             _compilation.Layout,
             _runtime,
             _options.AllowNodeModules ? _npm : null,
-            _moduleCache.Get(buildId, static () => new ServerModuleCache()));
+            _moduleCache.Get(buildId, () => new ServerModuleCache(staticAnalysis)));
 
         var settings = _options.ServerRendering;
 
diff --git a/src/JsxCore/Rendering/ServerModuleCache.cs b/src/JsxCore/Rendering/ServerModuleCache.cs
index 745e8fd..405906a 100644
--- a/src/JsxCore/Rendering/ServerModuleCache.cs
+++ b/src/JsxCore/Rendering/ServerModuleCache.cs
@@ -10,17 +10,35 @@ namespace JsxCore.Rendering;
 /// grows, or refills after a rebuild.
 /// </summary>
 /// <remarks>
+/// <para>
 /// A pool fills under a burst of requests, and the engines it builds walk the same modules in the
 /// same order — so the natural race is every engine parsing every module and all but one result
 /// being thrown away. The <see cref="Lazy{T}"/> holds that door: whoever asks first parses, and
 /// the rest wait for that result instead of duplicating it.
+/// </para>
+/// <para>
+/// <paramref name="staticAnalysis"/> chooses which half of the engine's preparation trade this
+/// compilation wants. Preparing with the analysis pass costs about twice a plain parse and hands
+/// every engine a tree with the interpreter's own bookkeeping already on it; preparing without it
+/// leaves each engine to work that out as it reaches a node. Whichever is cheaper depends on how
+/// many engines end up reading a parse, and a set of modules thrown away on the next edit is read
+/// by very few.
+/// </para>
 /// </remarks>
-internal sealed class ServerModuleCache
+internal sealed class ServerModuleCache(bool staticAnalysis)
 {
+    /// <summary>
+    /// Shared, because it is a description of how to prepare rather than state: one instance for
+    /// every cache that wants a parse without the analysis pass.
+    /// </summary>
+    private static readonly ModulePreparationOptions ParseOnly = new() { StaticAnalysis = false };
+
+    private readonly ModulePreparationOptions? _preparation = staticAnalysis ? null : ParseOnly;
+
     private readonly ConcurrentDictionary<string, Lazy<Prepared<AstModule>>> _modules = new(StringComparer.Ordinal);
 
     public Prepared<AstModule> GetOrParse(string location, Func<string> readSource) =>
         _modules.GetOrAdd(
             location,
-            l => new Lazy<Prepared<AstModule>>(() => Engine.PrepareModule(readSource(), l))).Value;
+            l => new Lazy<Prepared<AstModule>>(() => Engine.PrepareModule(readSource(), l, _preparation))).Value;
 }
diff --git a/test/JsxCore.Tests/Component/Rendering/ParseOnlyPreparationTests.cs b/test/JsxCore.Tests/Component/Rendering/ParseOnlyPreparationTests.cs
new file mode 100644
index 0000000..5d21678
--- /dev/null
+++ b/test/JsxCore.Tests/Component/Rendering/ParseOnlyPreparationTests.cs
@@ -0,0 +1,92 @@
+using JsxCore.Rendering;
+using JsxCore.Tests.Fixtures;
+using Microsoft.Extensions.DependencyInjection;
+using Shouldly;
+
+namespace JsxCore.Tests.Component.Rendering;
+
+/// <summary>
+/// An application whose views can be recompiled prepares its modules the cheaper way, which changes
+/// when the engine works out what a module means but must never change what it renders.
+/// </summary>
+/// <remarks>
+/// The parses are shared by every engine in the pool, and with the analysis pass declined each
+/// engine fills in what it needs as it reaches a node — so several engines rendering at once are
+/// writing that state onto one shared tree. The engine supports exactly this, and these renders are
+/// how JsxCore says it depends on it.
+/// </remarks>
+public class ParseOnlyPreparationTests
+{
+    private const string Card = """
+        import type { JsxNode } from "dotnet:rendering";
+        export function Card({ title, children }: { title: string; children?: JsxNode }) {
+            return <section class="card"><h2>{title}</h2>{children}</section>;
+        }
+        """;
+
+    private const string View = """
+        import { Card } from "../Shared/Card.tsx";
+        import type { ViewProps } from "dotnet:rendering";
+        export default function Index({ model }: ViewProps<{ name: string; items: string[] }>) {
+            return (
+                <Card title={`Hello ${model.name}`}>
+                    <ul>{model.items.map((item) => <li key={item}>{item}</li>)}</ul>
+                </Card>
+            );
+        }
+        """;
+
+    private sealed record Model(string Name, string[] Items);
+
+    private static Model TheModel => new("world", ["one", "two", "three"]);
+
+    [Theory]
+    [InlineData(true)]
+    [InlineData(false)]
+    public async Task Render_PreparedEitherWay_ProducesTheSameMarkup(bool watching)
+    {
+        using var project = JsxProjectFixture.Create();
+        project.Options.TypeChecking = TypeCheckingMode.Off;
+        project.Options.WatchForChanges = watching;
+        project.AddView("Shared/Card.tsx", Card);
+        project.AddView("Home/Index.tsx", View);
+
+        await project.CompileAsync();
+
+        var result = await project.RenderAsync("Home/Index", TheModel);
+
+        result.Html.ShouldBe(
+            "<section class=\"card\"><h2>Hello world</h2><ul><li>one</li><li>two</li><li>three</li></ul></section>");
+    }
+
+    [Fact]
+    public async Task Render_WhileWatching_FromSeveralEnginesAtOnce_IsConsistent()
+    {
+        using var project = JsxProjectFixture.Create();
+        project.Options.TypeChecking = TypeCheckingMode.Off;
+        project.Options.WatchForChanges = true;
+        project.Options.ServerRendering.MaxPooledEngines = 4;
+        project.AddView("Shared/Card.tsx", Card);
+        project.AddView("Home/Index.tsx", View);
+
+        await project.CompileAsync();
+
+        var renderer = project.CreateServerRenderer();
+        var services = new ServiceCollection().BuildServiceProvider();
+        var view = project.Locate("Home/Index");
+
+        // Task.Run, because a render completes synchronously while a pool slot is free: called in a
+        // loop they would run one after another on one engine and share no parse at all.
+        var renders = new Task<ServerRenderResult>[8];
+        for (var i = 0; i < renders.Length; i++)
+        {
+            renders[i] = Task.Run(() =>
+                renderer.RenderAsync(view, TheModel, new Dictionary<string, object?>(), services));
+        }
+
+        var results = await Task.WhenAll(renders);
+
+        results.Select(result => result.Html).Distinct().Count().ShouldBe(1);
+        results[0].Html.ShouldContain("<h2>Hello world</h2>");
+    }
+}