Alfa runtime is very long on certain websites

[TobiasG95]

Dear Alfa team,

While testing the Alfa framework, I came across some local websites where the check takes a very long time (more than a minute). On other sites it takes only a few seconds at most. For example this regular Wordpress site:
https://www.schoenwald.net/#/event

I saw the same behavior with the Siteimprove browser extension. Is this to be expected on some sites or is it a bug?

If it is maybe just a set of specific rules that are taking so long, would it make sense to disable them?

Thanks for your feedback!

[Jym77]

Hi @TobiasG95,
yes, we do also experience some pages being much slower to check than other 😞 It is not always clear what is the cause, the usual suspect is the style system which is not really optimised… If you have similar timings with the extension, it is likely something in the page that causes Alfa to take too long. Long and complex selectors can be a cause (e.g., I've seen a 120,000 characters long CSS selector with around 5,000 .foo + a, .bar + a, … alternatives; that wasn't fast to parse 😅).

When running Alfa locally, you can also measure performances of different steps, as shown in the measuring performances example.

This can often give insight on what is happening, but the results are not always immediate to interpret due to caching of some computations (i.e., some rules appear to be very fast, only because another rule already did the job and stored the result; for example comparing the timing of R66 and R69 makes little sense, only the first one to run is "charged" for the work).

Usually, the slow rules are R44 and R65. Both are fairly heavy on the style system. R65 should not run in the extension (since it always asks questions, which the extension does not support currently). When running Alfa locally, you can disable them by filtering them out of the Rule iterable that is sent to Audit.of. Depending on your case, it might help greatly if this is a rule which doesn't matter on your pages (e.g. R44 if you know you don't use conditional orientation).

We regularly try to improve performances a bit, e.g. with #1366. This is not a very high priority on our end since the average performances are decent for our pipeline (over the past month, our P95 timing of audit is at 30s, the average below 5s, we check around 10 millions pages daily). We do, indeed, see outliers such as this page, but they are rare enough that it is not a high priority to improve these cases.

[TobiasG95]

Hi @Jym77,
thanks for the quick and extensive explanation! And yes this does make perfect sense.

I will try to measure the performance as you suggested and if I find anything conclusive I will let you know.