chore: bound getExternalLinkPaths file reads to a frontmatter-sized prefix

[mvvmm]

Summary

getExternalLinkPaths() (used at config-load time to build the sitemap exclusion set for pages with external_link: in frontmatter) was reading the entire body of every one of ~6,800 docs files just to regex-match one frontmatter key — 27.2MB total across all content, with one file at 606KB. This runs on every astro check, every dev-server start, and every build.

Checked the actual frontmatter block size across all current content: max is 736 bytes. Bounded reads to a 1KB prefix per file instead of the whole body, via a fs.open() + read() helper rather than readFile.

Verified byte-for-byte identical output (235 matched paths, same set) against the prior full-read implementation at the 1KB bound, then confirmed end-to-end in a real build: the sitemap correctly excludes the exact pages with external_link: in frontmatter (spot-checked security-center/cloudforce-one/cloudforce-one.mdx — excluded — while its sibling open-port-scanning.mdx, which lacks external_link:, remains).

Measured the actual effect on local dev/build workflows, since the isolated function-level win doesn't necessarily translate to a visible end-to-end difference:

Measurement	Full read (old)	Bounded 1KB read (new)
Standalone re-implementation benchmark (warm OS cache, 10 runs, median)	451ms	383ms (~15% faster)
In-context timing (console.time around the real call, actual astro sync, 3 runs, median)	~472ms	~450ms (~5%, overlaps with noise)
Whole-command wall time (astro sync, 3 runs)	3.4–4.8s	3.4–4.8s (no distinguishable difference)

Net: this is a correctness/I/O-hygiene improvement (avoids needlessly reading 27MB across 6,800 files, one of which is 606KB, just to check one frontmatter key) rather than a meaningful wall-clock speedup for typical dev workflows — worth doing, but not oversold as a build-time fix. Vite startup and type generation dominate total command time.

Considered gray-matter (the standard Node frontmatter-extraction library) as a more "standardized" alternative to the hand-rolled regex. It's already present in the dependency tree, but only transitively via astro-skills — not importable directly without adding it as an explicit dependency. It wouldn't reduce any further I/O either (still needs to read file content first), just swaps the regex for a library call; not worth a new dependency for a check this simple. No Astro-native or Nimbus-native utility exists for reading just frontmatter outside the content-collection lifecycle — the "standard" way to read frontmatter (getCollection) isn't available at this point in the build, since astro-config.ts runs during config-loading, before astro:content resolves.

Verification

• pnpm run check / lint / format:check / test all clean
• Full pnpm run build succeeds (8709 pages)
• pnpm run test:postbuild passes

Documentation checklist

• The change adheres to the documentation style guide.

[github-actions]

This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:

Pattern	Owners
*.ts	@cloudflare/content-engineering, @kodster28

[github-actions]

Preview URL: https://4a3d161e.preview.developers.cloudflare.com
Preview Branch URL: https://chore-reduce-external-link-scan-io.preview.developers.cloudflare.com

[mvvmm]

half a second savings isn't worth any complexity here, closing.