What this is

The ancestor traversal performance budget was exceeded in the previous release. The root cause was buildMatchedRuleMap: it ran a CSS selector match test against every rule in every stylesheet for every ancestor level, making the cost O(ancestors times total rules). On a 121-stylesheet fixture, that was about 96,000 match tests per pick, with buildMatchedRuleMap accounting for 93% of total ancestor time.

The fix restructured the function so per-rule preprocessing (selector split, pseudo-strip, origin classification) ran once per page and the result was reused across the full ancestor chain. A conservative pre-filter was added to fast-reject simple single-token rules before calling el.matches(). The output-equality contract was verified: the rule map fingerprint was identical before and after the change across 30 maps and 646 total entries.

The final performance sweep at 5 runs showed ancestor traversal at 135 to 163 milliseconds across all runs. Every run under budget, with 37 milliseconds of headroom at worst.

What it answers

– why is loupely lens slow on wordpress with many plugins
– how fast is loupely lens on a plugin heavy wordpress site
– does loupely lens work on sites with 100 plus stylesheets
– how did loupely lens fix its ancestor traversal performance
– what is the loupely lens performance budget for css capture

Why we built it

The target user has a plugin-heavy WordPress site. That is the exact profile that hits 100-plus stylesheets and would have felt the performance problem hardest. The fix was required before launch.