Skip to content
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

Open
straker opened this issue Apr 24, 2024 · 1 comment
Open

axe.runPartial performance on page with 100k nodes #4427

straker opened this issue Apr 24, 2024 · 1 comment
Labels
performance Performance related issues support

Comments

@straker
Copy link
Contributor

straker commented Apr 24, 2024

We recently ran into an issue where a page had 108,000 option nodes in a single select 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 using runPartial the resultTypes option is not used which means the at the end of the runPartial all 108,000 nodes will try to generate a selector even if they will be removed after running finishRun.

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.

@straker straker added performance Performance related issues support labels Apr 24, 2024
@straker
Copy link
Contributor Author

straker commented Apr 25, 2024

We're going to do a few different things to address this problem.

First, there are some small improvements we can make to the getSelector code to handle generating selectors for an element with many children. We can detect that and prefer to use nth-child first rather than going through other indicators (such as id, class, etc.).

Second, a workaround for the performance problem could be to disable selectors in the run options in order to avoid generating them. This would then require having ancestors enabled in order to still get information about where an element is in the DOM when it fails. Generating ancestors is faster but still has performance problems with so many nodes. We can apply the same type of fix from getSelector in the previous point to generating ancestors as well.

Lastly, we'd like to make this switch from selectors to ancestors more dynamic to help speed up performance. We're going to allow the selectors run option to additional be a string with two options: ancestor or dynamic. Setting it to ancestor will make the target property of a node use the ancestor generation rather than the selector generation. dynamic will do this change based on the size of the page. For pages with a very large number nodes (number to be determined) axe will automatically use ancestor generation, where as for anything smaller than the very large number will use selector generation as it does today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Performance related issues support
Projects
None yet
Development

No branches or pull requests

1 participant