perf: SSR rendering optimizations by ascorbic · Pull Request #15605 · withastro/astro

ascorbic · 2026-02-21T13:07:11Z

Changes

Replaces Object.prototype.toString.call() with instanceof for isHTMLString detection
Reorders renderChild type dispatch to check strings first (most common child type)
Eliminates O(N²) head element deduplication by using a Set
Renders array children and template expressions directly to the destination without buffering when synchronous, falling back to BufferedRenderer only when a Promise is encountered
Adds targeted rendering benchmarks (rendering-perf.bench.js) covering many-components, many-expressions, many-head-elements, many-slots, large-array, and static-heavy page shapes

Codspeed results: all benchmarks improve or stay flat, no regressions on .md or .mdx routes. The .astro page benchmark (10K-item list) doubles in throughput.

Research done with help from Claude. Benchmarks by Claude.

Testing

New benchmarks in benchmark/bench/rendering-perf.bench.js and existing benchmark/bench/render.bench.js.

Results from local tests, compared to main:

rendering-perf.bench.js (non-streaming)

Bench	Original (Hz)	Final (Hz)	Total change
many-components	2,517	3,918	+56%
many-expressions	669	1,291	+93%
many-head-elements	7,662	11,997	+57%
many-slots	4,200	5,700	+36%
large-array	81	170	+110%
static-heavy	7,705	9,047	+17%

render.bench.js (realistic pages)

Bench	Original (Hz)	Final (Hz)	Total change
.astro streaming	64.8	128.1	+98%
.astro non-streaming	62.4	129.0	+107%

Docs

Internal optimizations only — no public API or behavior changes. No docs needed.

Add benchmarks isolating specific rendering hot paths: - many-components: markHTMLString/isHTMLString/validateComponentProps - many-expressions: renderChild dispatch ordering, escapeHTML - many-head-elements: head deduplication - many-slots: eager slot prerendering - large-array: BufferedRenderer per array child - static-heavy: baseline for static HTML overhead

changeset-bot · 2026-02-21T13:07:17Z

🦋 Changeset detected

Latest commit: 4050a6d

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

codspeed-hq · 2026-02-21T13:23:34Z

Merging this PR will improve performance by 72.83%

⚡ 2 improved benchmarks
✅ 7 untouched benchmarks
🆕 9 new benchmarks

Performance Changes

	Mode	Benchmark	`BASE`	`HEAD`	Efficiency
⚡	Simulation	`Rendering: streaming [true], .astro file`	348.3 ms	214.7 ms	+62.21%
⚡	Simulation	`Rendering: streaming [false], .astro file`	337.7 ms	195.4 ms	+72.83%
🆕	Simulation	`many-components (markHTMLString, isHTMLString, validateProps)`	N/A	8.7 ms	N/A
🆕	Simulation	`large-array (BufferedRenderer per child)`	N/A	159.1 ms	N/A
🆕	Simulation	`many-expressions (renderChild dispatch, escapeHTML)`	N/A	23.7 ms	N/A
🆕	Simulation	`static-heavy (markHTMLString baseline)`	N/A	6 ms	N/A
🆕	Simulation	`many-expressions [streaming]`	N/A	23.5 ms	N/A
🆕	Simulation	`many-slots (eager slot prerendering)`	N/A	5.3 ms	N/A
🆕	Simulation	`many-components [streaming]`	N/A	7.9 ms	N/A
🆕	Simulation	`large-array [streaming]`	N/A	148.9 ms	N/A
🆕	Simulation	`many-head-elements (head dedup)`	N/A	5 ms	N/A

_{Comparing bench/rendering-perf (4050a6d) with main (999a7dd)¹}

No successful run was found on main (1cc62dc) during the generation of this report, so 999a7dd was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

Fryuni · 2026-02-22T13:38:37Z

+	if (elements.length <= 1) return elements;
+	const seen = new Set<string>();
+	return elements.filter((item) => {
+		const key = JSON.stringify(item.props) + item.children;


Not that this was added in this PR so it could be changed in another one, but using JSON.stringify seems dangerous here. Two elements with exactly the same properties but in a different order should not be deduplicated?

> a = JSON.stringify({foo: 1, bar: 2}) '{"foo":1,"bar":2}' > b = JSON.stringify({bar: 2, foo: 1}) '{"bar":2,"foo":1}'

I don't think we are normalizing the head elements to have a consistent property ordering.

We already have a dependency on deterministic-object-hash for that, so it should be just a function swap.

I'll sort the keys. It's not a particularly hot path, but deterministic-object-hash is still probably overkill.

deterministic-object-hash

I found out that this package uses node.js APIs, so we can't use it anyway :/ I believe uses node:crypto, last time I checked

Fryuni · 2026-02-22T13:47:12Z

+				flushers[j] = createBufferedRenderer(destination, (bufferDestination) => {
+					return renderChild(bufferDestination, children[i + 1 + j]);
+				});


If we add a detection logic for the types of child that are known to never return a promise we could avoid the allocations for them even when there is a Promise before them. Since the most common child (a plain string) is one such case this might make for a big improvement for pages that do have async parts.

(also could be a separate PR)

We will be able to do that with queued rendering, which enabled batching

ematipico

No particular concerns with the code, but I think we should reword the changeset to make it more friendly for our end- users

ematipico · 2026-02-23T10:49:42Z

+Refactors the internal rendering pipeline to avoid unnecessary object allocations and reduce overhead in hot paths:
+
+- Replaces `Object.prototype.toString.call()` with `instanceof` for HTML string detection
+- Reorders the `renderChild` type dispatch to check strings first (most common case)
+- Eliminates O(N²) head element deduplication by using a `Set`
+- Renders array children and template expressions directly to the destination without buffering when all children are synchronous, falling back to buffered rendering only when a `Promise` is encountered


Not sure this is relevant to our end-users. If we want to talk about performance, perhaps we should say where users will these benefits: e.g. pages with more than 50 components, pages with many strings, etc. Essentially, we should give them something that they can quantify

Yeah, makes sense

ematipico · 2026-02-23T10:52:34Z

-				if (flusher) {
-					const result = flusher.flush();
+				return result.then(() => {
+					let k = 0;


Why is k defined outside the closure? can't we define it before the while loop, inside the closure?

It's in the closure, but needs to be outside of iterate so that it still increments when iterate calls itself

ematipico · 2026-02-23T10:54:23Z

+	// Strings are the most common child type (text expressions like {title}, {name})
+	// so check them first for the fastest dispatch in the common case.
+	if (typeof child === 'string') {
+		destination.write(markHTMLString(escapeHTML(child)));
+		return;
+	}


oh yeah, this was a perf suggestion that the AI agent suggested while I worked on the queued rendering. Short-circuit to simple node types first

yeah, these sort of ones are so obvious once you see them! Cheap/common checks first.

ematipico · 2026-02-23T10:55:01Z

+				flushers[j] = createBufferedRenderer(destination, (bufferDestination) => {
+					return renderChild(bufferDestination, children[i + 1 + j]);
+				});


We will be able to do that with queued rendering, which enabled batching

github-actions Bot added the pkg: astro Related to the core `astro` package (scope) label Feb 21, 2026

ascorbic force-pushed the bench/rendering-perf branch from c7d98f3 to 7325c51 Compare February 21, 2026 15:58

github-actions Bot added pkg: astro Related to the core `astro` package (scope) and removed pkg: astro Related to the core `astro` package (scope) labels Feb 21, 2026

ascorbic force-pushed the bench/rendering-perf branch 2 times, most recently from 16c98bd to b529461 Compare February 21, 2026 17:48

perf: rendering optimizations (A+B+C+E+F, no WeakMap cache)

99e4c80

ascorbic force-pushed the bench/rendering-perf branch from b529461 to 99e4c80 Compare February 21, 2026 18:16

chore: add changeset for rendering perf optimizations

6d6424b

ascorbic changed the title ~~Bench/rendering perf~~ perf: SSR rendering optimizations (up to 2x on data-heavy pages) Feb 21, 2026

ascorbic changed the title ~~perf: SSR rendering optimizations (up to 2x on data-heavy pages)~~ perf: SSR rendering optimizations Feb 21, 2026

ascorbic marked this pull request as ready for review February 21, 2026 18:44

Fryuni approved these changes Feb 22, 2026

View reviewed changes

matthewp approved these changes Feb 22, 2026

View reviewed changes

ematipico approved these changes Feb 23, 2026

View reviewed changes

Changes from review

4050a6d

ascorbic merged commit f6473fd into main Feb 23, 2026
43 of 44 checks passed

ascorbic deleted the bench/rendering-perf branch February 23, 2026 14:22

astrobot-houston mentioned this pull request Feb 23, 2026

[ci] release (beta) #15590

Merged

ascorbic mentioned this pull request Feb 23, 2026

perf: optimize streaming SSR buffer management #15620

Closed

Uh oh!

Conversation

ascorbic commented Feb 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Testing

rendering-perf.bench.js (non-streaming)

render.bench.js (realistic pages)

Docs

Uh oh!

changeset-bot Bot commented Feb 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

codspeed-hq Bot commented Feb 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merging this PR will improve performance by 72.83%

Performance Changes

Footnotes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ematipico left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ascorbic commented Feb 21, 2026 •

edited

Loading

changeset-bot Bot commented Feb 21, 2026 •

edited

Loading

codspeed-hq Bot commented Feb 21, 2026 •

edited

Loading

ematipico left a comment •

edited

Loading