Editor: Speed up the hierarchical term selector for large taxonomies

[Mamaduka]

What

PR tries to speed up the Categories panel on sites with thousands of terms. With 5,000 categories, ticking a checkbox blocked the main thread for about 157ms.

How

Each row now uses content-visibility, so the browser skips layout for rows that are off-screen. This was dropped fro this branch and will try to handled separately.

Alongside that, in the same component:

• buildTermsTree builds the tree in a single pass instead of cloning it twice
• sortBySelected partitions the list instead of sorting with a comparator that rewalks each subtree on every comparison
• each checkbox is memoized on primitive props, so ticking one term does not rerender the rest

Testing Instructions

1. Create test data - wp term generate category --count=5000 --max_depth=3.
2. Open a post.
3. Try interacting with the Categories panel.
4. Selection and filtering should feel faster.

Testing Instructions for Keyboard

Same.

Screenshots or screencast

Before

CleanShot.2026-08-10.at.12.40.42.mp4

After

CleanShot.2026-08-10.at.12.38.37.mp4

Use of AI Tools

Assisted by Claude.

[github-actions]

Size Change: +114 B (0%)

Total Size: 7.72 MB

📦 View Changed

Filename	Size	Change
build/scripts/editor/index.min.js	531 kB	+114 B (+0.02%)

_{compressed-size-action}

[tyxla]

Thanks for working on this @Mamaduka.

While this is a perf change, it also changes how the list looks and how it behaves. That mix makes regressions easy to miss.

Should we perhaps split it - tree building and memoization in one PR, CSS and search changes in another?

[tyxla]

I see we're memoizing TermCheckbox here but aren't we still recreating all TermRow elements and their child elements on every render? Is that the intent and why?

[Mamaduka]

The TermRow memoization had no real effect on performance. The memoed TermCheckbox ensures that only one item re-renders when selection changes.

Manual memoization is easy to break, so I decided to split it into smaller parts.

[tyxla]

Hmm, but since TermRow is not memoized, and selectedTerms gets a fresh Set on every terms change, doesn't the tree walking still run in full on each toggle? Or are you saying that's cheap enough even with large trees?

[Mamaduka]

Based on profiler probes, re-rendering rows on selection was cheap. TermCheckbox skipped rendering, and selection became noticeably faster.

[tyxla]

Are we intentionally missing the a11y announcements here?

[Mamaduka]

Good question. This was logical to me, no filter value, no announcement. I'll check which patterns we're using elsewhere.

[tyxla]

The contain-intrinsic-size: auto 36px is set on every .hierarchical-terms-choice, but some of those rows contain a whole subtree inside .hierarchical-terms-subchoices. So a skipped top-level row with 20 children is reported as 36px instead of ~500px.

The 36px value also may also be off for leaf rows on desktop. It comes from $grid-unit-30 (24px), which is the --checkbox-input-size for small viewports, but above the break-small breakpoint the checkbox is 16px, so a actual leaf row is about 28px.

Should we apply content-visibility only to rows without children?

[Mamaduka]

I'll have a look.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: tyxla <tyxla@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Mamaduka]

Should we perhaps split it - tree building and memoization in one PR, CSS and search changes in another?

Makes sense. I got a bit carried away, since the selection interaction improvements required overlapping changes.

[Mamaduka]

Thanks for the review, @tyxla!

I've extracted debouncing into a separate PR. Decide to keep memoization and CSS changes, since they contribute to the same perf improvements.

CSS is updated and should use better scoping and measurements.

[tyxla]

Unless my math is wrong, this applies a negative margin-bottom. And when done on the last leaf of a nested subtree, it will increase the gap after every subtree. Is that intentional?

[Mamaduka]

Maybe I should follow your original suggestion and leave the CSS changes for a follow-up PR 😄

I could also explore better alternatives or fixes where we don't have to do all the calculations and bookkeeping.

[tyxla]

To be fair, I'm a bit nervous about missing cases with the CSS changes. Would be great if we can address these visual changes separately so we can also test them thoroughly and in a focused way.

[Mamaduka]

Couldn't agree more, and I've already missed a lot of cases. I'll remove the CSS part from this PR and work on a follow-up.

[tyxla]

Is this actually taking in consideration longer labels that will wrap on multiple lines?

[Mamaduka]

@tyxla, rebased and updated the branch. It now only contains React-side optimizations.

[tyxla]

This looks good to me, my only remaining question is this one, thanks!

[tyxla]

Let's give that a go. Thanks @Mamaduka!