[yangshun]

Summary

Pages clients eagerly load a manifest that repeats page IDs and layout chains. Emit compact rows and share identical layout chains to reduce this payload.

Initialization expands the rows into the existing component and layout lookup objects. Static routes before the first dynamic route use a path Map; remaining routes retain ordered regex matching to preserve precedence.

Generated structure

Simplified example with two static pages sharing a layout. Loader names represent lazy imports; dynamic routes are omitted.

Before:

const components = {
  about: loadAbout,
  contact: loadContact,
  layout: loadLayout,
};

const layoutTree = {
  about: ["layout"],
  contact: ["layout"],
};

const routes = [
  { pattern: /^\/about$/, id: "about" },
  { pattern: /^\/contact$/, id: "contact" },
];

After:

const layoutChains = [["layout"]];
const rows = [
  ["about", loadAbout, 0],
  ["contact", loadContact, 0],
];

const components = {};
const layoutTree = {};
const staticRouteIds = new Map();

for (const [id, load, chain, path = "/" + id] of rows) {
  components[id] = load;
  if (chain >= 0) layoutTree[id] = layoutChains[chain];
  if (!staticRouteIds.has(path)) staticRouteIds.set(path, id);
}

components.layout = loadLayout;

Component and layout selection continue to use object lookups. Static route matching uses Map.get(path).

Caution

Yes this format is less readable (by a bit), but it's definitely more space and runtime efficient for large number of pages. I'd argue this is a better change.

Bundle size

React production builds with generated static pages, a homepage, and one shared layout. Only the void package changes between variants; the adapter and external dependencies are identical. Sizes measure the emitted Pages client entry.

Generated pages	Gzip level 6, before → after	Brotli quality 11, before → after
1	68,726 → 68,776 B (+0.07%)	59,489 → 59,516 B (+0.05%)
100	72,725 → 72,021 B (−0.97%)	61,356 → 61,038 B (−0.52%)
1,000	107,695 → 98,216 B (−8.80%)	76,396 → 72,989 B (−4.46%)
5,000	249,580 → 206,988 B (−17.07%)	142,147 → 124,254 B (−12.59%)

The complete JavaScript dependency set required to hydrate page 1 also shrinks; bytes were not moved into another eagerly required chunk.

Runtime measurements

At 5,000 generated pages:

Metric	Before	After	Change
Cold manifest parse + initialization	15.784 ms	9.659 ms	−38.8%
Module initialization alone	2.529 ms	4.510 ms	+78.3%
Retained heap after initialization	3.03 MiB	2.66 MiB	−12.4%
Warmed last-page route lookup	153.734 µs	0.291 µs	−99.8%

The compact representation adds about 2 ms of initialization work, while combined cold parse + initialization improves by 6.12 ms (paired 95% interval: 5.12–7.15 ms faster; adjusted p = 0.00012). The one-page cold case increases 29.3%, equivalent to 0.019 ms.

Measurements made using:

• Chrome 155 on Apple M5 with 70% idle CPU host
• 16 randomized pairs per page count
• Cold timing uses an isolated function wrapper; initialization and heap measurements use real ES modules, with heap sampled after forced garbage collection.

End-to-end loading and hydration speed remain unmeasured.

Note

Why keep objects for components and layoutTree?

Click to see comparison

A separate 16-pair experiment replaced both lookup objects with Maps while keeping compact rows, layout chains, and route matching identical.

Metric at 5,000 generated pages	Objects	Maps	Change
Module initialization	4.590 ms	4.364 ms	−4.9%
Cold parse + initialization	10.325 ms	10.267 ms	−0.6%
Retained heap after initialization	2.66 MiB	2.69 MiB	+1.2%
Component + layout lookup	10.83 ns	9.44 ns	−12.9%

Maps improved initialization by 0.226 ms, but combined cold timing showed no statistically significant improvement (p = 0.90). Reads saved approximately 1.4 ns, while retained heap increased by 32.5 KiB.

We retained objects because these gains did not establish an overall startup improvement and would require changing shared runtime and adapter interfaces. The static-route Map replaces a linear regex scan, where the benefit is much larger.

Validation

• 15 focused tests across the core and four framework adapters passed.
• Core and installed fixture typechecks passed.
• Ten production SSR builds passed, including identical repeated build fingerprints.
• Browser hydration, counter interaction, and client navigation passed.
• All 128 samples in each runtime experiment passed their route and lookup checks.
• Benchmark tests, checks, formatting, and lint passed.

Measurements compare baseline 6ab6559ccec2f905c693bedeedd5734287946f1b with candidate 1b5ba4384f06a5df0d0c0092692d61fe13e5f882 and cover static React Pages output with a shared layout. Dynamic-route-heavy applications and other engines may produce different results.

[Brooooooklyn]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-22T03:49:29.253927Z	b0dc9e5	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Hooray!

Reviewed commit: b0dc9e54ec

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".