refactor(releases): speed up loading of documents in archived release

[bjoerge]

Description

Small refactor that speeds up loading of documents in archived release.

Side-by-side comparison. Left: before. Right: after

Screen.Recording.2025-03-14.at.13.33.11.mov

after)

What to review

• We were currently loading the preview for each document in serial (using concatMap), so we'll wait until we've loaded the preview of one document before we fetch the next. This also leads to more preview fetches than needed, because the preview fetches are batched within a time window

Notes for release

• Optimized loading of documents in archived releases

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
page-building-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 14, 2025 0:35am
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 14, 2025 0:35am
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 14, 2025 0:35am

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)			Mar 14, 2025 0:35am
test-next-studio	⬜️ Ignored (Inspect)			Mar 14, 2025 0:35am

[github-actions]

No changes to documentation

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	42.07%	54508 / 129555
🔵	Statements	42.07%	54508 / 129555
🔵	Functions	46.99%	2736 / 5822
🔵	Branches	79.41%	10202 / 12847

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/sanity/src/core/releases/tool/detail/useBundleDocuments.ts	8.33%	100%	0%	8.33%	60-167, 170-252, 255-294, 301-319

Generated in workflow #32331 for commit 246bc2b by the Vitest Coverage Report Action

[github-actions]

⚡️ Editor Performance Report

Updated Fri, 14 Mar 2025 12:38:55 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	24.4 efps (41ms)	20.4 efps (49ms)	+8ms (+19.5%)	✅
article (body)	72.2 efps (14ms)	73.0 efps (14ms)	-0ms (-/-%)	✅
article (string inside object)	25.6 efps (39ms)	22.7 efps (44ms)	+5ms (+12.8%)	✅
article (string inside array)	23.0 efps (44ms)	20.4 efps (49ms)	+6ms (+12.6%)	✅
recipe (name)	43.5 efps (23ms)	30.3 efps (33ms)	+10ms (+43.5%)	🔴
recipe (description)	47.6 efps (21ms)	33.3 efps (30ms)	+9ms (+42.9%)	🔴
recipe (instructions)	99.9+ efps (5ms)	99.9+ efps (6ms)	+1ms (-/-%)	✅
synthetic (title)	20.0 efps (50ms)	18.9 efps (53ms)	+3ms (+6.0%)	✅
synthetic (string inside object)	20.0 efps (50ms)	20.4 efps (49ms)	-1ms (-2.0%)	✅

efps — editor "frames per second". The number of updates assumed to be possible within a second.

Derived from input latency. efps = 1000 / input_latency

Detailed information

🏠 Reference result

The performance result of sanity@latest

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	41ms	45ms	56ms	176ms	526ms	10.8s
article (body)	14ms	15ms	18ms	51ms	57ms	4.8s
article (string inside object)	39ms	43ms	52ms	66ms	190ms	6.9s
article (string inside array)	44ms	46ms	49ms	166ms	169ms	7.0s
recipe (name)	23ms	24ms	27ms	46ms	2ms	9.0s
recipe (description)	21ms	23ms	24ms	39ms	0ms	4.9s
recipe (instructions)	5ms	7ms	8ms	17ms	0ms	3.1s
synthetic (title)	50ms	54ms	59ms	102ms	570ms	14.1s
synthetic (string inside object)	50ms	53ms	62ms	362ms	1163ms	8.8s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	49ms	59ms	84ms	334ms	1351ms	12.3s
article (body)	14ms	16ms	21ms	212ms	265ms	5.6s
article (string inside object)	44ms	46ms	49ms	309ms	415ms	7.5s
article (string inside array)	49ms	51ms	57ms	234ms	689ms	8.1s
recipe (name)	33ms	35ms	37ms	60ms	80ms	8.9s
recipe (description)	30ms	32ms	34ms	48ms	6ms	6.3s
recipe (instructions)	6ms	7ms	10ms	32ms	0ms	3.2s
synthetic (title)	53ms	54ms	62ms	348ms	1028ms	13.0s
synthetic (string inside object)	49ms	50ms	51ms	60ms	530ms	7.4s

📚 Glossary

column definitions

• benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
• latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
• p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
• p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
• p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
• blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
• test duration — how long the test run took to complete.

[pedrobonamin]

Massive improvement! Thank you!