starred/karakeep

Fork 0

mirror of https://github.com/karakeep-app/karakeep.git synced 2026-04-26 00:16:03 +03:00

[GH-ISSUE #1892] Tag input becomes extremely slow when too many tags are present #1174

New issue

Closed

opened 2026-03-02 11:55:31 +03:00 by kerem · 6 comments

kerem commented

2026-03-02 11:55:31 +03:00

Owner

Originally created by @qixing-jk on GitHub (Sep 5, 2025).
Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/1892

Describe the Bug

When adding new tags, if there are already a large number of tags, the input field becomes extremely sluggish. Typing or interacting with the input feels laggy, making it difficult to add new tags efficiently.

Steps to Reproduce

Add a large number of tags (not know need how much exactly, I have 12.7K).
Go to one bookmark and edit its tags
Try typing to add another tag or search an existing tag.
Notice how the input lags and becomes unresponsive.

Expected Behaviour

Tag input should remain fast and responsive regardless of how many tags are present. Adding new tags should not cause the input to lag, even with a large number of existing tags.

Screenshots or Additional Context

No response

Device Details

Edge 139.0.3405.125 (Official build) (64-bit) on Windows

Exact Karakeep Version

nightly

Have you checked the troubleshooting guide?

I have checked the troubleshooting guide and I haven't found a solution to my problem

Originally created by @qixing-jk on GitHub (Sep 5, 2025). Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/1892 ### Describe the Bug When adding new tags, if there are already a large number of tags, the input field becomes extremely sluggish. Typing or interacting with the input feels laggy, making it difficult to add new tags efficiently. ### Steps to Reproduce 1. Add a large number of tags (not know need how much exactly, I have 12.7K). 2. Go to one bookmark and edit its tags 3. Try typing to add another tag or search an existing tag. 4. Notice how the input lags and becomes unresponsive. ### Expected Behaviour Tag input should remain fast and responsive regardless of how many tags are present. Adding new tags should not cause the input to lag, even with a large number of existing tags. ### Screenshots or Additional Context _No response_ ### Device Details Edge 139.0.3405.125 (Official build) (64-bit) on Windows ### Exact Karakeep Version nightly ### Have you checked the troubleshooting guide? - [x] I have checked the troubleshooting guide and I haven't found a solution to my problem

kerem

2026-03-02 11:55:31 +03:00

closed this issue
added the
bug

status/approved

pri/medium
labels

kerem commented

2026-03-02 11:55:32 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Sep 7, 2025):

Today, all the tags are loaded for auto complete which is extremely unoptimal. We probably should support proper tag search in the backend. This however will require re-writing the current tags editor.

@MohamedBassem commented on GitHub (Sep 7, 2025): Today, all the tags are loaded for auto complete which is extremely unoptimal. We probably should support proper tag search in the backend. This however will require re-writing the current tags editor.

kerem commented

2026-03-02 11:55:32 +03:00

Author

Owner

@qixing-jk commented on GitHub (Sep 7, 2025):

Today, all the tags are loaded for auto complete which is extremely unoptimal. We probably should support proper tag search in the backend. This however will require re-writing the current tags editor.

Yes, that is also my approach, but I prefer not to build such a large project on my computer or migrate test data from the production server. I might not be able to assist with resolving this issue. Instead, I will continue focusing on extension development, which only requires running independently without relying on all services.

That said, the tag search experience through the browser extension seems better than on website. I'm not sure why.

@qixing-jk commented on GitHub (Sep 7, 2025): > Today, all the tags are loaded for auto complete which is extremely unoptimal. We probably should support proper tag search in the backend. This however will require re-writing the current tags editor. Yes, that is also my approach, but I prefer not to build such a large project on my computer or migrate test data from the production server. I might not be able to assist with resolving this issue. Instead, I will continue focusing on extension development, which only requires running independently without relying on all services. That said, the tag search experience through the browser extension seems better than on website. I'm not sure why.

kerem commented

2026-03-02 11:55:32 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Sep 7, 2025):

@qixing-jk no worries, I really appreciate the work you're doing for the extension :)

The extension uses a shadcn based tags selector which maybe is bit more efficient than the react-select based editor in the web. I've always wanted to get rid of react-select but I need to build something as nice UX wise first.

@MohamedBassem commented on GitHub (Sep 7, 2025): @qixing-jk no worries, I really appreciate the work you're doing for the extension :) The extension uses a shadcn based tags selector which maybe is bit more efficient than the `react-select` based editor in the web. I've always wanted to get rid of `react-select` but I need to build something as nice UX wise first.

kerem commented

2026-03-02 11:55:32 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Nov 3, 2025):

This has been fixed in #1987

@MohamedBassem commented on GitHub (Nov 3, 2025): This has been fixed in #1987

kerem commented

2026-03-02 11:55:32 +03:00

Author

Owner

@sprior commented on GitHub (Nov 3, 2025):

@MohamedBassem Do you have an ongoing release cadence in mind?

@sprior commented on GitHub (Nov 3, 2025): @MohamedBassem Do you have an ongoing release cadence in mind?

kerem commented

2026-03-02 11:55:32 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Nov 3, 2025):

@sprior We should have a new release in the next couple of days. Wanted to do it today, but it's getting late, so probably tomorrow.

@MohamedBassem commented on GitHub (Nov 3, 2025): @sprior We should have a new release in the next couple of days. Wanted to do it today, but it's getting late, so probably tomorrow.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/karakeep#1174

No description provided.

Rows
Columns