bitwarden
Performance issues while login or searching with accounts that have access to more than 2000 items
Describe the Bug
If your account has access to more than 2000 items, the login and search process with the browser extension gets strongly degraded.
Steps To Reproduce
- Log into the browser extension.
- Wait for your account to login around 20/30 seconds.
- Search for an item in the browser extension.
- Wait for another 20 seconds for the search process to give you a result.
Expected Result
Not have to wait between 20 and 30 seconds to log in and a similar amount of time to perform a search.
Environment
- Operating system: Windows 10
- Browser: Chrome 88.0.4324.96 and Firefox 85.0
- Build Version: 1.47.1 and 1.48.1
Additional Context
After a successful login with Chrome's browser extension with an account that has more than 8000 items, after 15 minutes of general usage, the overall resource consumption of my laptop was heavily affected. Closing Chrome (and the session) solves the issue almost immediately. Don't have the specific numbers, but could repeat the experiment and document them.
Other users report a similar experience while navigating on their Web Vault as well. Desktop apps seem to be unaffected.
It isn’t only in the browser extension. Same issue is with the desktop application and even the web loads very very long. Desktop application still seems a bit faster
We have over 3000 items in just over 100 collections and are experiencing this issue. Definitely worse in the web vault and browser extensions, but very noticeable in the desktop client as well.
We're making some general improvements in this area:
- improving virtual/infinite scroll implementations, to reduce the amount of DOM elements loaded at once (e.g. https://github.com/bitwarden/browser/pull/1858)
- using web workers for large decryption operations, so that it doesn't lock up the UI. It also appears that this has some performance improvements as well: https://github.com/bitwarden/jslib/pull/333
@chuck614 and @FaserF out of curiosity, what's more of a problem in your experience:
- long loading times on login/unlock, or
- slowdown during general navigation and use?
For me - slow general navigation is most of issue. And slow reloading when I create new item or update on password, seems Bitwarden do a full reload of database instead of pushing only one update to it.
General navigation isn't great at our current level of items, but the larger problem for us is the load times after login or PIN. It is bad enough that if you don't sit and wait for the circle to stop spinning after unlock or login, nothing in the UI works properly. An example is a browser integration that is locked, we type in the PIN and can't go right back to the page to search for an auto-fill. We wait for the spinning to stop, go back to the fields and sometimes a right-click will show results, other times it will just stay stuck at saying the vault is still locked. If we wait another 10 seconds or so we will get results. The other noticeable way this shows up is any editing of items. If we need to change anything in an item, the saving will causing what feel exactly like the load wait after login.
This is all great feedback, thank you. I'm surprised there's such a long delay after editing an item - it should only save that 1 item and then update the search index, which is relatively quick. It shouldn't redo the entire vault. e.g. In my testing with about 4k vault items there was only a 1-2 second pause after saving an item - not great I admit - but also not as long as the unlocking process.
So I can get a better idea of your use cases:
- approximately how many vault items do you have? (including any organization items you have access to)
- what's your delay on unlock? (in seconds)
- what's your delay after editing and saving an item?
- how long does it take Bitwarden to find matching logins after navigating to a page? (e.g. how long does it take for the little number to appear on the badge)
We have somewhere between 3000 and 4000 items as we are still importing and migrating from our old solution. Our delay on unlock/login is anywhere between 6 and 11 seconds depending on browser plugin, website, application. The delay after attempting to edit an item seems to be way worse in the browser plugin. That is 4-5 seconds before it will answer the button press to "Close" the item (while it is showing the green success bar at the bottom which seems to prevent UI interaction) and then it starts another 4-5 second list refresh. The application seems to be about 5 seconds after edit. The delay to find matching items on a page is not noticeable if you recently unlocked it. If you have timed out and need to enter password/PIN, that is when a whole cycle of delays starts and sometimes requires a refresh of the webpage afterwards.
Does anyone uses other password managers like LastPass, RoboForm, etc with similar number of items? How is their performance in same operations, comparing with Bitwarden?
@chuck614 Thanks for that information. There will hopefully be some changes to the browser extension this coming release that will make the experience after logging in/unlocking feel smoother and more responsive. I'll also look into the saving time you've mentioned. I doubt any one thing will be a silver bullet, but I'd like us to be making iterative improvements in this area to support larger users.
No problem. I have also put some suggestions in the Bitwarden feature request forum for larger multi-tenant style deployments that may help if they can be implemented. Things like the ability to choose a "context" for a browser plug-in that is limited to a subset of items; also perhaps a default "view" that you can set per installation or user that only shows personal vault items and then you can choose collections, or vice-versa; etc.
Could you please fix quickly this issue. We purchased 100 business licenses for our On-Premise instance and we have mroe than 3000 items. User experience is very bad .... Login, searching and browsing are very slow!
Hello, This performance problem has a big impact on an on-premise installation. Can you prioritize this ticket in order to satisfy customers with a large number of items in Bitwarden. Thank you very much for your support
Would it be possible to get an update on this? We have seen a lot of new versions stream out this year, but none have helped these 5-11 second delays in browsers, plugins, apps when unlocking, modifying, refreshing, etc.
Would it be possible to get an update on this? We have seen a lot of new versions stream out this year, but none have helped these 5-11 second delays in browsers, plugins, apps when unlocking, modifying, refreshing, etc.
Yes indeed an answer on this performance problem would be welcome. We are users of the solution at the City of Strasbourg (France) and it is quite annoying not to have a resolution predictive on this subject.
Thanks for your patience everyone, I'm aiming to have some improvements in this area in the next 1-2 releases. This will target vault decryption (logging in and unlocking), as that's the biggest bottleneck at the moment for large vaults. After that, we'll do further investigation into delays when saving/modifying ciphers. I'll post any updates in this thread.
Any chance there is movement on this? The thick apps feel quicker for unlocking our vault, but the web plugin is still painfully slow to unlock. I just did it and counted 20 seconds to usable, and then made the mistake of switching from "Vault" to "Tab" and that spinning wheel was another 10 seconds. Thanks!
Same goes for us. I think the issue is that Bitwarden always loads ALL passwords instead only loading the first 10-20 passwords for example in the web vault.
Same goes for us. I think the issue is that Bitwarden always loads ALL passwords instead only loading the first 10-20 passwords for example in the web vault.
I would think it would need to load all passwords for the browser plugins to be able to do URI matching. What might help now that they added a "Vault" drop-down, is to be able to set your default browser plugin context to "My Vault". Then it could only load the couple hundred entries in there every unlock; and silently in the background start loading the other thousands, or maybe wait until I select the organization vault later to load the rest. Not sure, but I hope there is some way to speed up the UI loading.
Hi all! An update from me: #3532 is in the final stages of code review and is intended to address this issue. That PR implements multithreading (via the web workers API), which will speed up decryption times and avoid "freezing" the browser/Bitwarden UI while decryption is occurring. These changes took longer than I initially expected, but they're now targeting the November release. It will be for web and browser initially, there are a few kinks to figure out in desktop before we enable it there.
Partial/incremental cipher decryption is something that we've discussed but (to my knowledge) don't have any plans for at the moment. I think you'd at least need to decrypt the indexed fields to enable vault searching, which would probably end up being most of your vault anyway. @chuck614's suggestion of decrypting the selected vault's ciphers first is a nice one though (at least in browser, not sure it would work with the web/desktop interface which drops you into all vaults by default). It might be something we consider if there's a continued need for improvements in this area after #3532, I'll flag it for further discussion internally after that's merged.
Hi all! An update from me: #3532 is in the final stages of code review and is intended to address this issue. That PR implements multithreading (via the web workers API), which will speed up decryption times and avoid "freezing" the browser/Bitwarden UI while decryption is occurring. These changes took longer than I initially expected, but they're now targeting the November release. It will be for web and browser initially, there are a few kinks to figure out in desktop before we enable it there.
Partial/incremental cipher decryption is something that we've discussed but (to my knowledge) don't have any plans for at the moment. I think you'd at least need to decrypt the indexed fields to enable vault searching, which would probably end up being most of your vault anyway. @chuck614's suggestion of decrypting the selected vault's ciphers first is a nice one though (at least in browser, not sure it would work with the web/desktop interface which drops you into all vaults by default). It might be something we consider if there's a continued need for improvements in this area after #3532, I'll flag it for further discussion internally after that's merged.
That is excellent news, thanks!
The improvements in #3532 are now live in the web vault (November release), and they will be released for the browser extension in the December release. This should improve login/unlock decryption times, as well as loading organization items on the Organizations vault page in the web vault.
We've also identified the problem with long saving times when editing an item. The Organizations vault page (used by admins/owners etc in the web vault) does not cache its decrypted items, so every time you edit and save an item from that page, it will fetch and decrypt all organization items from the server again. I don't have a timeline for improving that behaviour, but I have raised it with the team for further discussion.
We are still having this issue, most noticeably in the browser plugins. It is the same if not a little bit worse now. We are also hesitant to update our KDF settings and just deal with the warning notice on web vault login, since support can't tell us if it will make this persistent issue worse. We have had a new case open without an update since June.
FYI, noting this so the knowledge doesn't get lost: With the 3 PRs above, (especially #6465) the decryption time gets brought down to an acceptable level <1s, most of the time even <0.5s, even on 10k cipher vaults. The most of the rest of the time (~4-6s on a recent test run) is spent handling state (parsing/unparsing? in "structuredCloneInternal") in the stateservice, before and after decryption.
Some additional time is spend building the search index (1.5s), which is required for the vault to initially render. I feel the second part could be fixed by not requiring the search index to be completed for the initial render, which would lower the user-perceived unlock time quite a bit.
For the state service I have not yet looked closely where the time is being spent exactly, but this is where the most gains are to be had after the 3 PRs above are merged.
Our StateService is currently being replaced by a new pattern/class called StateProvider. This is being done as a priority over the next few months to support manifest v3 (but it affects all TS clients). My guess is that this will be more performant than the current solution, however either way it's probably a good idea not to sink too much time into analysing StateService in the meantime.
This is still an issue, we have the Enterprise solution and Bitwarden Web is terrible slow. Every action (e.g. search) takes multiple seconds (> 10s).
I have also significant performance issues with the bitwarden client, mainly on MacOS (13.7). I self-host Vaultwarden. The login takes forever, I mean even minutes sometimes!
I have around 1200 entries. It's so slow that it's almost not usable for me, which is very unfortunate, because I really like bitwarden!
I only have 1270, but it's extremely slow for me, sometimes timing out on login, and frequently taking 3-6 seconds to fill
I'm using the Win 11 client on a decent thinkpad. I defnitely have less than 2000 passwords and less than 100 existing sends. The app became very laggy recently, search becomes unresponsive etc. Latest updates haven't changed anything regarding this.
Mine with 1200 passwords, it was laggy but the perf has improved much, now working fine.
