-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI becomes unresponsive while searching docs #231
Comments
It is generating a lot of react elements per keystroke https://github.com/lodash/lodash.com/blob/master/assets/js/docs.js#L253 Don't know if this is the cause. However, if you notice in the perf chart above each keypress gets shorter. This is likely due having less react elements to rebuild as the list gets shorter. The actual search library seems fast enough by itself https://fusejs.io/ I think a really simple fix would just to debounce search for 200ms. This will likely allow the user to type in several characters and narrow the results to be a short list which renders quickly. But the root cause is the long layout time. |
This is sus Line 347 in c8d41c6
getComputedStyle can be slow, but is it here? |
This is taken care of part of #201 |
Description
When searching the docs, while typing in the search field, UI becomes unresponsive. The issue seems to be caused due to the fact that the whole page is repainted on every keystroke and the event handler responsible to perform the search does not seem to be debounced. As a side note, if you switch to the docs of version 2.4.2, the issue still exists but is less obvious as the length of the page is much smaller than when in version 4.17.15 (latest at the time of writing).
Enabling "Paint flashing" in Chromium developer tools might be helpful for debugging.
Steps to reproduce
Expected result
UI should be responsive while user types in search field.
Actual result
Searching causes the whole page (which is long) to repaint on every keystroke resulting in UI being unresponsive.
Device details
Chromium: 87.0.4280.67 (Official Build) (x86_64)
Additional information
Issue seems to be more obvious in Chromium browsers (tested in both MacOS and Linux). Tested in Firefox 83.0 and Safari 14.0 and they don't seem to suffer that much.
The text was updated successfully, but these errors were encountered: