Input lag on search input

doomedramen commented 1 month ago

Hey, noticed I get very bad input lag in the search input, even just a debouce to let me type everything before it searches would help. Happy for me to add it?

(Bug found on iOS 17.5, iPhone 12)

itsthejoker commented 1 month ago

There's a 200ms delay before it tries to reorganize things... what page are you experiencing that lag on? https://github.com/itsthejoker/filamentcolors.xyz/blob/master/filamentcolors/templates/partials/filter_bar.partial#L54-L56

itsthejoker commented 1 month ago

I wonder if it would make sense to detect the page width and use a larger delay on mobile devices. 🤔

itsthejoker commented 1 month ago

for research purposes: https://github.com/desandro/masonry/issues/474

itsthejoker commented 1 month ago

If this is the main library view that's having the issues, depending on your user settings, there can be upwards of 1900 items that Masonry is trying to reorganize. I have a few ideas for how to make this better but nothing that's an immediate fix. Extending the delay before filtering on mobile is the fastest "quick" solution in lieu of a proper fix, but implementing something like infinity.js and proper pagination for the homepage like in #94 is probably the best long-term option.

doomedramen commented 1 month ago

https://github.com/itsthejoker/filamentcolors.xyz/assets/445964/49b1cd7c-44b5-4acb-8ba0-7b8c9616e87b

doomedramen commented 1 month ago

Recorded on an iPhone 12, iOS 17.5, safari. Will test on iPad too.

doomedramen commented 1 month ago

On my iPhone and pre Apple silicone iPad, rendering and filtering long lists is slow, there are a bunch of ways we can speed this up, I am in meetings all day tomorrow but can put a PR in tomorrow with changes for testing.

doomedramen commented 1 month ago

Things to solve:

Why is the debounce not working, seems to be filtering faster than I can type.
How can we implement chunked infinite scrolling.
where is the bottle neck on mobile/low-power/older devices, db query or front end sorting.
Can we show that searching/filtering is happening to the user.

itsthejoker commented 1 month ago

holy fucking shit. I just tested in Safari on desktop and is ungodly slow. I don't have any Apple mobile devices and I don't use Safari, so I didn't realize. fffffffffffff

I've been trying to keep (limited) compatibility with folks who run without JS enabled but if things are that broken then it's probably time to change that.

On Android and desktop, Chrome and Firefox have no problem with the filtering but Safari is just... whew. I straight up forgot Safari existed tbh. Okay. Let me see if there are any "quick fixes" I can push to make things "more tolerable" rather than "fixed". Thanks so much for raising this as a problem, I legitimately had no idea.

itsthejoker commented 1 month ago

To be clear, I would love to see any ideas that you have on what might help this. I'm thinking that the best immediate fix might be to implement infinity.js and start chunking the homepage... but that will require also refactoring search to be an actual endpoint since not all of the items are loaded at first. The solution that I currently have worked when I only had 300 swatches, but 2000 later, it's clearly not working anymore.

itsthejoker commented 1 month ago

I have a WIP for infinite scroll and server-side filtering. I'm not very happy with it, and it needs a lot of testing / tweaking before it's functional. Here's a brief summary:

server-side filtering with a 400ms delay
vastly extended filtering capabilities
added infinite scrolling

Issues:

back button breaks everything
cannot filter + infinite scroll at the same time
experience feels slower, even though in certain circumstances it's much faster
completely breaks multi-select functionality

https://drive.google.com/file/d/1jMwCpVMlcnWhyUcvU49mkDlYIlnA3mvm/view?usp=drive_link

doomedramen commented 1 month ago

Thank you for looking into this, I am taking a look now. btw, does the api provide and endpoint for everything that gets queries by the front end?

itsthejoker commented 1 month ago

Ah... no. "Filtering" right now is pure JS that just loops over each of the swatch cards and sets "display: none" if they don't fit the text in any way. There's really nothing that's done via API and assembled on the front end. In almost every case, any call back to the server results in pre-rendered HTML that gets inserted into the DOM by HTMX.

itsthejoker commented 1 month ago

I've definitely found the problem, and it's Masonry in Safari. I've got some general speed fixes for the search, but I haven't quite figured out yet what to do about masonry given that it's used to recalculate everything after the search has completed. Hrm...

doomedramen commented 4 weeks ago

Hey @itsthejoker sorry I have been a little quote on this for a while. I was actually playing around with making a new front end for the data but stopped when you mentioned that the API is not currently serving much of the data.

Happy to take a look at the Masonry issues, if you have anything specific you want me to look at I am happy to, if not I can just try to debug how Masonry is going through all the data to try and speed it up.

itsthejoker commented 2 weeks ago

It's all good! This is a hobby project, and life is allowed to get in the way ^_^

My conversion work is finished - I'm gonna do some more testing with folks to verify that everything's happy, then looks like this is going to be ready to go!

itsthejoker commented 1 week ago

@doomedramen thanks so much for bringing this to my attention. I'm really pleased with the end result and I think you will be too :)

itsthejoker / filamentcolors.xyz

Input lag on search input #96