-
Notifications
You must be signed in to change notification settings - Fork 742
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
axe.runPartial
performance on page with 100k nodes
#4427
Comments
We're going to do a few different things to address this problem. First, there are some small improvements we can make to the Second, a workaround for the performance problem could be to disable Lastly, we'd like to make this switch from |
See also #4273 |
We recently ran into an issue where a page had 108,000
option
nodes in a singleselect
element. Axe-core took a bit to just process that many nodes, but the real problem was processing selectors for that many nodes.Typically our answer to that is to use
resultTypes
to filter out most nodes which allows us to just generate selectors for things like violations. However when usingrunPartial
theresultTypes
option is not used which means the at the end of therunPartial
all 108,000 nodes will try to generate a selector even if they will be removed after runningfinishRun
.One thing we'll have to figure out is how to deal with rules that have after methods which may change the result of a node.
The text was updated successfully, but these errors were encountered: