Performance of happy-dom in tests

[jwm01cg]

Hi! I'm looking at happy-dom as a replacement for jsdom for unit testing my React app with @testing-library/react and vitest. I've managed to integrate it and get some of my tests to start passing.

However, I've noticed so far that the tests are significantly slower when running with happy-dom. One particular test file that took 2m42s to run under jsdom now takes 15m6s with happy-dom. This is confusing to me as all I have read online suggests that happy-dom is more lightweight than jsdom and focuses more on performance.

I am relying heavily on byRole queries which can apparently be problematic according to this discussion in the testing-library repository. However, my app has fairly strict accessibility requirements so I'm not sure I'd really want to start ripping those out in favour of byText.

I did notice in a small test app with vitest and happy-dom that happy-dom takes the lead there, so maybe it is something to do with my app. Which leads me to my main question: is there any data I can collect to work out what is taking so long during my tests? Perhaps also there is some common wisdom about patterns that tend to slow down happy-dom?

[capricorn86]

Hi @jwm01cg! 👋

One way to get some more information on what is expensive is to run a profiler on the tests to see where it spends most time. It is possible to start the debug tool in Chrome dev tools and run the profiler from there.

Looking at the test in the example, I believe that getByRole() is what is expensive in combination with a big DOM tree. waitFor() will loop until getByRole() is resolved.

You have some options:

• Don't use waitFor() to detect when it is available
• Query the element in a different way
• Reduce the size of the DOM node tree for where you are searching for the elements. Testing Library is probably using querySelector(), which will crawl the DOM tree until it finds the element.

Happy DOM should probably look into what exactly Testing Library is doing that takes time and optimize it.

[jwm01cg]

Thank you for the reply. These are some good suggestions. We do use waitFor but usually sparingly to wait for elements to stop having aria-busy, however there is typically a byRole selector in there. We could definitely do a better job of limiting the DOM tree that we have to search by using within.

I've taken a profile of an example test running under happy-dom, which took ~35 seconds as opposed to ~14 seconds in jsdom. Unfortunately I can't really see a smoking gun like 'byRole is taking 80% of your cpu time', it's mostly just Node internals that I don't know how to make sense of 😕 Perhaps I attached to the wrong process and vitest spawned some other process, I'll need to take a closer look.

[capricorn86]

@jwm01cg There has been many optimizations in Happy DOM since you opened the discussion. Happy DOM now has caching when using selectors and there has also been many minor improvements. Any chance you can try again and see if it solved the performance problems?