Get feedback from users, Receive feedback from usersget feedback from users. 500ms is a good starting point.
Your answer will most likely vary depending on the purpose and platform on which it is run. In general, you want to give feedback to the user as soon as possible about doing something wrong (an incorrectly formatted e-mail address would be a good example). The benefit of quick feedback on form validation is also that they know immediately which field is not filled out properly (instead of completing the form and then being notified that a field is missing somewhere).
So let's look at different use cases and platforms and possible pitfalls if your debouncing is too short or too long.
Problems with too short debouncing
If you ran a debounce in less than 200 ms for the average user, it will be displayed almost immediately. The result would be a user who is just starting to enter his e-mail address, and he will be told immediately that he has the wrong format. Imagine when you were a kid and your parents wiped the floor, and before they're done, say, "Miss a spot!" … you will not take that too nicely. Similar concept here.
Moral of the story, do not make your debouncing too short. Give your user some time to complete the field.
Problems with too long debouncing
Now consider the other side of the time spectrum. You fill in the e-mail field again, and it is the last field in the form. You type away (but for your information, you typed incorrectly), quit the form, click Submit and wait while the form is submitted … Only then will the "Womp Womp" error be displayed.
This is too long a wait. The user entered a field and their focus has been moved further. If you need to drag the user back into a box, you feel he's not making any progress (you want forms to have a sense of progress, so the user can know the tasks are complete).
Stick to the example of housework. In that case, imagine cleaning your room and bathroom. They quit their room and are halfway to the bathroom when their parents come in and say they've cleaned the room in a terrible way (it turns out you can not just throw everything under the bed). Now you have to go back in your room, only to go then back to clean the bathroom. Does not feel like progress.
So we have our two ends of the spectrum.
At one end we have the jabber mouth "You are doing everything wrong" debounce.
And at the other end we have the "Hey, come back" debounce.
Both are not desirable. Rather, we want debunking, which serves as a guide. When we complete the form, we learn (after completing the task) whether we did it right or not. We finish the bed and then our parent tells us that we have done good / horrible work.
So that's the problem we want to solve.
Remember that users have different writing speeds. Some people will probably be at the low end of 20 words per minute while others will burn fast at over 100. When you work with mobile, people tend to type slower on mobile than on a keyboard (I would still type that in if I was on my phone …). All these things affect your debounce time.
If your debounce time must vary significantly due to different write speeds, other approaches may be applicable (for example, a type & # 39; onFieldLeave & # 39;).
Without information about what type of platform / audience you are addressing, Half a second (500ms) can be helpful starting point, They want to give the user time to fill in a field, but they attract his attention before they pass him by. 2 seconds (2000 ms) may be too long, depending on how fast people are typed, and 200 ms would be a blink of an eye (both situations we've already covered).
As suggested by @SteveD in the comments, You really should have some user testing to determine which debounce time is best for your application, Have a few different times and get feedback. Nothing beats the cold, hard answers you get from user feedback.
Here is a short article that gives you an idea of the reaction times of people who might be enlightening.
There is a useful website that documents some basic UX laws (https://lawsofux.com). Look at the Doherty Threshold, which can be useful for measuring interaction time.