[PERF]: Docs page takes two minutes to scan - can we optimize further

[tombrunet]

Project

a11y checker engine

Browser

Chrome

Operating system

MacOS

Description

File stored at https://ibm.ent.box.com/file/1270551723607 - Scan info: [INFO]: Scanning complete in 110787ms with 78841ms in rules [PERF: text_quoted_correctly] 125 [PERF: text_contrast_sufficient] 174 [PERF: text_quoted_correctly] 115

Steps to reproduce

Scan file. Not clear if performance is just large file, or if some rules are taking too long. Three listed items are potential slow spots.

[tombrunet]

First glance, the page has 41,449 nodes, so we’re spending 2.7ms per node on average checking.

[shunguoy]

triage: check if caching can improve performance.

[j-mendez]

Just a helpful tip @tombrunet @shunguoy, at A11yWatch we tested equal-access with kayle our web accessibility engine and equal-access was about 20x-50x slower than fast-axe ( our axe-core rewrite which is about 2-15x faster than axe-core for most case. Equal-access was about 1,000x - 10,000x slower than our fast-htmlcs the rewrite of htmlcs_codesniffer.

That being said these are huge speed differences, stepping back and comparing to what normally people use which is axe-core and htmlcodesniffer it is still slower than the two by a drastic amount even for simple test. It seems that theres a drawback in the way the test runner initiates the audits, since it takes time to even load in a browser env and the audit rules being written without performance measuring.

We also tested this prior to 2.2 - you can test the runner here on an older commit before we removed the runner since it was way too slow for the cloud. When users use other runners and switched to IBM ace it was big change when performing audits site-wide and people would think theres a big because of how slow it would perform on certain pages etc. https://github.com/a11ywatch/kayle/tree/0556cfb981f8a724d6927f076d92feb72b6ff41b