perf(components): scan for component tags without copying the document per tag (#1945)

`findComponentTags` walks the document looking at every `<`. To test whether a
tag name matched, it sliced the whole remaining document and ran an anchored
`^...` pattern against the copy:

    const afterLt = html.slice(tagStart + 1)
    const m = afterLt.match(new RegExp(`^(${tagPattern.source})(?![\w.:-])`))

Both halves are per-`<`: a copy of the rest of the page, and a regex compile.
It runs three times per pass (kebab, PascalCase, lowercase) and again for every
nested component.

A sticky matcher does the same test at an offset in the original string. Same
pattern, same lookahead, no copy, compiled once per source rather than once per
character.

Measured with a String.prototype allocation profiler over one steady-state
render, on four fixture shapes:

                        before      after
  component-dense      107.57MB    14.28MB    -87%
  expression-dense      18.88MB     3.83MB    -80%
  stores + composables   6.02MB     3.91MB    -35%
  plain signals page     3.53MB     3.53MB      0%   (no component tags)

On the component-dense page this one site was 95.5MB of the 107.6MB the render
allocated -- 89% of it, 4,250 slices averaging 23KB each. It is the largest
single item behind this issue by a wide margin; the three commits before this
one moved 377KB between them.

The plain-signals row is not a disappointment, it is the control: a page with no
component tags never entered the loop, and its number does not move.

Three things the rewrite had to preserve, each pinned by a sabotage run:

The #1845 lookahead. `(?![\w.:-])` is what stops the pattern matching a PREFIX
of a longer tag -- `<ion-button />` matched `ion`, lost the hyphen that marks it
a custom element, and resolved `ion.stx` from disk, splicing an ENOENT into the
page. Dropping it from the shared matcher fails 3 component tests.

The offset. A sticky regex matches at `lastIndex`, so it must be set to
`tagStart + 1` before every exec. Leaving it at 0 fails 78 tests.

Flags. The old matcher was built from `.source` alone, so it was case-sensitive
whatever the caller's pattern said, and the kebab/Pascal/lowercase dispatch
depends on that. The sticky matcher adds `y` and nothing else.

The new matchers are cached by pattern source. The three call sites declare
their patterns as literals inside a function, so each call passes a fresh RegExp
object with a familiar source -- keying on the object would miss every time, and
keying on the source holds three entries. A caller building patterns dynamically
would need to bound it; none does.

Verified byte-identical against HEAD across 12 renders (4 fixture shapes x SEO
on / SEO off / colorMode). 5 new tests covering the sticky-index risks the
existing suite does not reach. Suite 12,709 pass / 0 fail.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: glennmichael123

packages/stx/src/component-processing.ts

@@ -91,6 +91,44 @@ export interface ComponentTagMatch {
   isSelfClosing: boolean
 }
 
+/**
+ * Sticky tag-name matchers, one per pattern source.
+ *
+ * `findComponentTags` tests every `<` in the document, and it used to do that
+ * by slicing the whole remaining document and matching `^...` against the copy.
+ * On a component-dense 237KB page that was 4,250 slices totalling 95MB in a
+ * single render -- 89% of everything the render allocated, and the largest
+ * single item behind stacksjs/stx#1945. A sticky match runs at an offset in the
+ * original string and copies nothing.
+ *
+ * Compiling once per pattern instead of once per `<` takes a regex compile out
+ * of the same loop. The three call sites pass module-level literals, so this
+ * map holds three entries; a caller that builds patterns dynamically would need
+ * to bound it.
+ *
+ * Flags are deliberately NOT carried over from `tagPattern`. The old matcher
+ * was built from `.source` alone, so it was always case-sensitive whatever the
+ * caller's pattern said -- and the PascalCase / kebab / lowercase dispatch
+ * depends on that.
+ *
+ * The lookahead is the #1845 fix and has to stay: a tag name ends at the first
+ * character that cannot appear in one. Without it the pattern matches a PREFIX
+ * of a longer tag -- `<ion-button />` matched `ion`, lost the hyphen that marks
+ * it a custom element, and resolved `ion.stx` from disk, splicing an ENOENT
+ * error into the page. The paired form `<ion-button></ion-button>` was already
+ * ignored, so only self-closing custom elements were affected.
+ */
+const tagNameMatchers = new Map<string, RegExp>()
+
+function tagNameMatcherFor(tagPattern: RegExp): RegExp {
+  let matcher = tagNameMatchers.get(tagPattern.source)
+  if (!matcher) {
+    matcher = new RegExp(`(${tagPattern.source})(?![\\w.:-])`, 'y')
+    tagNameMatchers.set(tagPattern.source, matcher)
+  }
+  return matcher
+}
+
 /**
  * Find component tags in HTML, properly handling quoted strings
  * This solves the issue where `>` inside attribute values would incorrectly end the tag
@@ -110,15 +148,10 @@ export function findComponentTags(html: string, tagPattern: RegExp, skipTags?: S
     if (tagStart === -1)
       break
 
-    // Check if this matches our tag pattern
-    const afterLt = html.slice(tagStart + 1)
-    // A tag name ends at the first character that cannot appear in one.
-    // Without this lookahead the pattern matches a PREFIX of a longer tag:
-    // `<ion-button />` matched `ion`, lost the hyphen that marks it a custom
-    // element, and resolved `ion.stx` from disk — splicing an ENOENT error
-    // into the page. The paired form `<ion-button></ion-button>` was already
-    // ignored, so only self-closing custom elements were affected (#1845).
-    const tagNameMatch = afterLt.match(new RegExp(`^(${tagPattern.source})(?![\\w.:-])`))
+    // Check if this matches our tag pattern, at that offset in `html` itself.
+    const matcher = tagNameMatcherFor(tagPattern)
+    matcher.lastIndex = tagStart + 1
+    const tagNameMatch = matcher.exec(html)
 
     if (!tagNameMatch) {
       pos = tagStart + 1

packages/stx/test/components/component-tag-scan.test.ts

@@ -0,0 +1,69 @@
+/**
+ * `findComponentTags` scans without copying (stacksjs/stx#1945).
+ *
+ * The scan tests every `<` in the document. It used to do that by slicing the
+ * whole remaining document and matching an anchored pattern against the copy:
+ * on a component-dense 237KB page, 4,250 slices totalling 95MB in one render --
+ * 89% of everything that render allocated, and the single largest item behind
+ * the issue. It matches at an offset in the original string now.
+ *
+ * The behaviour that has to survive is pinned by the component suite at large;
+ * what is pinned HERE is the risk the rewrite introduces and nothing else
+ * covers: a sticky regex carries `lastIndex` between calls, and the matcher is
+ * now shared across calls rather than rebuilt per `<`. A stale index silently
+ * skips tags near the start of the next document.
+ */
+
+import { describe, expect, it } from 'bun:test'
+import { findComponentTags } from '../../src/component-processing'
+
+const PASCAL = /[A-Z][a-zA-Z0-9]*/
+
+describe('component tag scanning', () => {
+  it('finds a tag at the very start of the document', () => {
+    // Offset 0 is where a leaked lastIndex bites first.
+    const tags = findComponentTags('<Card />', PASCAL)
+
+    expect(tags).toHaveLength(1)
+    expect(tags[0].tagName).toBe('Card')
+    expect(tags[0].startIndex).toBe(0)
+  })
+
+  it('gives the same answer on a second call with a fresh pattern object', () => {
+    // The three callers declare their patterns inside the function, so every
+    // call passes a NEW RegExp with the same source -- the matcher is looked up
+    // by source, which is what makes reuse (and lastIndex) possible at all.
+    const html = '<Card /><Badge />'
+    const first = findComponentTags(html, /[A-Z][a-zA-Z0-9]*/)
+    const second = findComponentTags(html, /[A-Z][a-zA-Z0-9]*/)
+
+    expect(second.map(t => [t.tagName, t.startIndex])).toEqual(first.map(t => [t.tagName, t.startIndex]))
+    expect(second.map(t => t.tagName)).toEqual(['Card', 'Badge'])
+  })
+
+  it('does not carry an index over from a longer previous document', () => {
+    findComponentTags(`${'<p>filler</p>'.repeat(40)}<Card />`, PASCAL)
+    const tags = findComponentTags('<Badge />', PASCAL)
+
+    expect(tags.map(t => t.tagName)).toEqual(['Badge'])
+  })
+
+  it('still refuses a prefix of a longer tag name', () => {
+    // #1845: `<ion-button />` matched `ion`, lost the hyphen that marks it a
+    // custom element, and resolved ion.stx from disk -- splicing an ENOENT
+    // error into the page. The lookahead that prevents it moved into the
+    // shared matcher, so it is worth asserting where it now lives.
+    const tags = findComponentTags('<ion-button />', /[a-z][a-z0-9]*/)
+
+    expect(tags).toHaveLength(0)
+  })
+
+  it('reports offsets into the original string, not a slice of it', () => {
+    const prefix = '<div class="wrap">\n  '
+    const tags = findComponentTags(`${prefix}<Card title="x" />\n</div>`, PASCAL)
+
+    expect(tags).toHaveLength(1)
+    expect(tags[0].startIndex).toBe(prefix.length)
+    expect(tags[0].fullMatch).toBe('<Card title="x" />')
+  })
+})