Fixes #3117

Sanitization ran several allocating passes over every user-authored field regardless of content. FilterInvisibleCharacters converted the whole input to []rune and back, FilterCodeFenceMetadata split and rejoined every line, and bluemonday ran unconditionally — so benign text paid full price on every conversion.

Changes

FilterInvisibleCharacters is scan-first / copy-on-first-match. It skips runs of ASCII without decoding them (no filtered rune is ASCII, and no variation selector is either), then copies into a builder only from the first rune that actually changes. Clean input is returned as the original string with zero allocations. Contextual variation-sequence handling is unchanged, and invalid UTF-8 is still re-encoded to U+FFFD to match the []rune round trip it replaces.

FilterCodeFenceMetadata walks lines in place instead of strings.Split/Join, and returns the input untouched when no line changes. sanitizeCodeFenceLine also stops rebuilding a line whose info string is already normalized.

FilterHTMLTags skips bluemonday for provably inert input. The policy tokenizes as HTML and re-emits text through html.EscapeString, so anything it can rewrite must contain one of the five characters EscapeString touches (&, ', ", <, > — also the only way to open a tag, comment, doctype or entity), a byte the tokenizer rewrites (NUL → U+FFFD, CR folded into LF), or a byte outside ASCII that could be malformed UTF-8. The fast path accepts printable ASCII plus TAB and LF minus those five characters, which excludes all three. A loose <>& check would not be sufficient: " and ' are escaped, and CR/NUL are rewritten by the tokenizer.

Sanitize skips the second invisible/code-fence pass when HTML normalization returned its input byte for byte. HTML processing is the only stage that can introduce a character its input did not contain (entity decoding), so if it is the identity there is nothing new to find, and both filters are fixed points on the first pass's output.

Nothing here weakens filtering or broadens allowed HTML. Content that genuinely needs rewriting still goes through the full pipeline, and non-ASCII text still goes through bluemonday by design.

Equivalence evidence

pkg/sanitize/equivalence_test.go keeps a verbatim copy of the previous pipeline and diffs the new code against it:

• ~22k deterministic corpus cases — every existing regression input, every rune class the filters branch on across 11 templates, all adjacent interesting-rune pairs, and 20k seeded pseudo-random strings including raw bytes and invalid UTF-8.
• isHTMLInert checked against the live policy byte by byte (in isolation and in context) and over the whole corpus, plus 50k dense printable-ASCII strings drawn from an HTML-syntax-heavy alphabet.
• Explicit fixed-point tests for the early return: both filters are idempotent, and the fence filter never reintroduces filterable runes.
• Allocation contracts asserted with testing.AllocsPerRun, and a check that a list of known payloads still loses something.
• Two fuzz targets: FuzzSanitizeMatchesReferenceImplementation and FuzzHTMLInertIsPolicyFixedPoint. Ran ~5.7M executions locally with no divergence.

Benchmarks

Committed in pkg/sanitize/bench_test.go and pkg/github/minimal_types_bench_test.go. Intel Ultra 9 185H, -count=6, benchstat:

All differences p=0.002 (n=6). The residual converter allocations are the struct and slice fields, not sanitization.

Projected overhead at 1,250 RPS

Per the issue's shapes, sanitizing one response:

At 1,250 RPS:

• Comment-heavy: 6.3 cores → 0.21 cores, allocation 2.7 GiB/s → 7.6 MiB/s.
• Issue-heavy: 3.8 cores → 0.11 cores, allocation 1.9 GiB/s → 2.3 MiB/s.

Sanitization stops being a GC-bound cost centre for ordinary content. Non-ASCII bodies still pay for bluemonday (~1.0 ms per 64 KiB, down from 2.7 ms); extending the fast path past strict ASCII is deliberately left out of this change.

Validation

script/lint clean, script/test (race) green, script/generate-docs produces no diff.