Laggy search and navigation feedback

[mcfarljw]

I've been using the new Nuxt website for a few months right now and wanted to provide some UX feedback based on my developer usage. For context I find myself using the docs multiple times a day.

1. When searching the docs the text input field gets blocked from rendering which means there is a disconnect with what you're typing and what is displayed. I don't think the search results need to be instant but what you're typing in the text input should not be blocked. For example in the recording below I am constantly typing but it's really choppy and I finished typing a full 10 seconds before my typed text is actually completely displayed.

2. The animations for the menus are cool but the artificial delay trips me up multiple times a day if I'm moving "too fast". I know where I want to go but frequently find myself needing to slow down or try again to get to the menu that I want because of the delay.

All if this feedback is in contrast to the previous website which I didn't have nearly as much friction using when navigation around and didn't feel like I was be throttled when navigating through the docs. If this was only a marketing page that would be fine but since it's also developer documentation I think it should be a bit more responsive.

[sh-at-cs]

To save time for anyone else wanting to look into this: The search is implemented using Nuxt UI Pro's ContentSearch component (you can even observe the same input field lag in the examples on the linked doc page), which isn't open source, so I guess it's not even possible for the community to try and help with this... Unless the issue is actually in CommandPalette which ContentSearch is based on, but to me it doesn't seem like that one suffers from the same issue.

[mcfarljw]

I don't think the laggy search is an issue with the Nuxt UI component specifically but rather how it's being used on both the website in the examples. The first issue is it doesn't seem to be doing any kind of debouncing which causes it to lock up the main thread and the second issue is it's searching a very large JSON file in memory (#1538), add those two things together and it's going to be slow.

It would be better to send a network request which searches the JSON file and returns the results async making using of the loading indicator https://ui.nuxt.com/components/command-palette#loading and also adding in like 300ms debounce.

[loilo]

I did some profiling on the search feature, and what I found is that two things drag down performance significantly:

1. Performing search itself on a large amount of items.
2. The way how entries are passed to the command palette.

Debouncing/throttling can help with both of these problems (as @HugoRCD has already prepared in #1952), but it will only get you so far. It still improves the situation drastically (profiled INP goes down from 11.9s to 3.5s), but as you can see, a 3'500ms INP is not the experience you might want to shoot for.

I've dabbled around with solutions to both of these problems, and I locally brought the INP down to 500ms (still not great, but at least another leap in the right direction). Unfortunately though, I cannot make a PR with my changes since not all of this is directly in the hands of the nuxt.com repo.

1. Performing Search

Using a web worker for search instead of running it on the UI thread does a lot of good, but the search business logic is part of the CommandPalette component, so that component would have to be adjusted.

I can see a world where (the option to) using a worker would benefit many Nuxt UI users, but I'm not sure whether the disproportionate scale of nuxt.com search would justify adding the additional complexity in Nuxt UI for everyone.

(Ideally, the worker approach would be provided as an improvement in VueUse's useFuse composable directly. But to be honest, I don't see this happen — workers, in particular worker URLs, are a pain to get right and almost impossible to offer in libraries.)

2. Passing Entries

The "Ask AI" entry currently really drags down performance, because it echoes the current search term. This establishes a dependency of the searchable entries on the search term, meaning that a new list of entries is passed to Nuxt UI Pro's ContentSearch component (and thus to the CommandPalette) on every keystroke.
While only the "Ask AI" entry actually changes in that list, the ContentSearch component still has to perform the ceremony of processing all the entries to prepare them for search (the mapNavigationItems() function being run a lot was particularly prominent in the profiler).

So, unless there would be a significant redesign of how the Ask AI feature is presented in search (or how semi-permanent items are embedded in the CommandPalette in general), I don't see a quick way to fix this without really downgrading the Ask AI feature.

Just my 2 cents & hints for future improvements.

[HugoRCD]

@loilo Thank you very much for doing this, it's hyper relevant and will help me a little more to move forward in the optimization I think there is clearly work that could be done on the "Ask AI" function by doing something more "native" with Nuxt UI's ChatPalette and Vercel's aiSDK 🤔