user.type helper is slow even with delay 0
See original GitHub issueDescription: Version: 14.0.0-beta.11
Tested two variants for 100 characters text. I use default config with delay=0
userEvent.clickanduserEvent.paste- 70ms~
await user.click(screen.getByLabelText(/label/));
await user.paste(textMock);
userEvent.type- 1500ms~
await user.type(screen.getByLabelText(/label/), textMock);
keypress - seems to be slow, because there is a sync loop without Promise.all() and each iteration has 10-15ms
This fragment of code is synchronous and slow
if (unpreventedDefault && hasKeyPress(keyDef, config)) {
await keypress(keyDef, getCurrentElement, config)
}
Issue Analytics
- State:
- Created 2 years ago
- Comments:7 (4 by maintainers)
Top Results From Across the Web
`userEvent.click` fails due to timeout when used with `jest. ...
testing-library/user-event version: 14.0.0-beta.7 Testing Framework ... test still does not complete in within the timeout bounds with .type ...
Read more >Very slow typing response and long typing delay in long ...
When typing new text at the bottom of a long text note (about 90000 words; about 5000 lines of text), the typing response...
Read more >Troubleshoot Delay JavaScript execution issues
When using Delay JavaScript execution, certain elements can appear only after some time or user's interaction. If this doesn't interfere ...
Read more >Optimize First Input Delay - web.dev
First Input Delay (FID) is a Core Web Vitals metric that captures a user's first impression of a site's interactivity and responsiveness.
Read more >Slow Google Sheets? Here are 27 Ideas to Try Today
Slow Google Sheets? Follow these 27 techniques to diagnose and improve the performance of even the worst performing Google Sheets.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

I’ll close this issue, as it lacks a reproduction example.
This looks like this is a problem with the environment. When we
await, we allow other code to run in between - the next microtask withdelay: nullor the next macrotask between actions withdelay: 0. It might be the DOM implementation, the event handlers or any other code on the event loop causing the excessive execution time.Which part is not true? There is no reproduction showing any problem with our implementation - neither on this issue nor on the other one which this one is a duplicate of.
If you can create a reproduction example that showcases a problem on our end, I’ll gladly reopen.