All configuration page is unresponsive

[tqvarnst]

Describe the bug
When I go to the all configuration options page https://quarkus.io/guides/all-config it takes a really long time for the search field to become available and Chrome says the page is unresponsive. See the attached video (coming soon)

Which pages
https://quarkus.io/guides/all-config

I'm on Mac OS using Version 116.0.5845.187 (Official Build) (x86_64) of Chrome

[tqvarnst]

Screen.Recording.2023-09-25.at.13.24.55.mov

[maxandersen]

I can confirm Chrome has a hard time on https://quarkus.io/guides/all-config.

I had same issue in past but hadn't noticed it for a while because I use firefox and here I can the days type in text in search almost instantly (maybe 1-3s delay).

@FroMage or @ia3andy didn't you do some updates recently to this page to fix something similar to this or do i remember wrong?

[FroMage]

Not recently no, years ago I added support for shadow DOM to make filtering much faster. I guess either the option count increased.

[FroMage]

Just checked on Chrome on Linux, and it's still 1-2s delay, so not something I can improve.

Can someone with a Mac use the Chrome profiling tools to figure out what it's stuck on?

[tqvarnst]

@FroMage, I can do it if you can send details of what profiling tool you want me to use and how to use it. 😉

[FroMage]

Ctrl-Shit-I (to open the inspector), Go to Performance tab, and click Record (or Ctrl-E):

This is what happens when I type panache in the search field:

100ms search and update, not bad.

You can also start recording and reload, there's an option for that (or Ctrl-Shift-E):

Next week I'll have access to a Mac, I can try it then. Not sure a remote debug session will help us much :(

[michalvavrik]

I don't think this can improve as long as all configuration properties that fit the search term are rendered (part of DOM). IMHO this can only be fixed with lazy loading on scroll down. Now that there is actual back end used for searching, can it be also used to serve configuration properties that match given term (paginated sorted result).

@yrodiere WDYT? I have actually wanted to do that for a long time (both FE and BE part), but I somehow expected that this was a priority and someone already had already planned to fix it. @insectengine @gsmet do you happen to know what is current state?

I'll wait, but if there is consent that proposed solution would do, I'm happy to have a look. Thanks

[FroMage]

I frankly doubt that we'll get remote search results faster than 100ms. Not to mention that the returned results page size will be gigantic for the first letters typed.

[michalvavrik]

I frankly doubt that we'll get remote search results faster than 100ms. Not to mention that the returned results page size will be gigantic for the first letters typed.

Sorry @FroMage , maybe I formulated it wrong. IMHO: core issue is that all these data are rendered, if you keep it in browser memory, you will get better rendering times. Loading of page content won't get better because it is still a static page. But at some point, loading all these properties eagerly will slow things.

So:

1. keeping all these config properties as JS variables should be enough to get significant improvement, and using lazy loading on scroll to show them
2. if we could use back end (e.g. Quarkus instance, I presumed that is how search for Quarkus guides work) to just load this static file into memory and serve configuration properties in chunks, I expect you will get better results because I have done that in past. But it was on huge data sets, maybe this deserves some metrics and is not necessary yet.

If we can agree at least on 1., I can try it, but again, I don't know what are current plans for configuration page and I don't know where to find discussion on that topic.

[michalvavrik]

Not to mention that the returned results page size will be gigantic for the first letters typed.

I mentioned lazy loading, what I am suggesting is to serve content in chunks to front end that loads it on demand (scroll).

[yrodiere]

@yrodiere WDYT? I have actually wanted to do that for a long time (both FE and BE part), but I somehow expected that this was a priority and someone already had already planned to fix it. @insectengine @gsmet do you happen to know what is current state?

I think you're looking for quarkusio/search.quarkus.io#313. If you want to make suggestions regarding a remote search endpoint, that would be the place.

I think the idea would be to have some yaml/json file with the data about configuration properties available somewhere, and to have search.quarkus.io index that, so that it can expose a search service. You could then change the page on quarkus.io to not display all properties by default, but just offer a search box and display the ~50 first matches by default, then lazy-load the next matches upon scrolling (we already have the frontend code for something similar). And you'd be done.

I cannot personally make this a priority, but we gladly accept PRs.

[michalvavrik]

Thank you @yrodiere , I'll definitely look into it. I'll start by the end of the week, if anyone has different suggestions / preferences, there is time.

[yrodiere]

Thank you @yrodiere , I'll definitely look into it. I'll start by the end of the week, if anyone has different suggestions / preferences, there is time.

Thanks. If you end up working on the search.quarkus.io issue, feel free to ping @marko-bekhta or me, we can help you get started with the codebase.

[marko-bekhta]

One thing I'd add is that if we end up changing the search on that page, should we also consider changing how that page looks?
My thinking here is that if we show just a "first page" of config properties (even if sorted by an extension) we'll lose the current table-lake grouped structure. Hence, maybe we should add some sort of facet-like filters so that users can still easily find all the properties for a particular extension..

feel free to ping @marko-bekhta or me, we can help you get started with the codebase.

+1 😃

[insectengine]

Looking at the web stats for December, this page is the 12th most popular (of ~1800) so making it more user friendly would be a benefit for the users.

Would definitely be worth a conversation on how to organize the content in order to display it better display it besides the tables.

I'd say before running off to code this, we should determine the final form of the page/content.

[gsmet]

While I'm all to make it better, the current behavior is not so bad, at least for me, it used to be a lot worse.

If you adjust things, keep in mind that I tweaked a lot the rules to have a header appear so that the context is not lost. Let's make sure we keep that if we change that.

[insectengine]

Also, isn't this edited via asciidoc? Seems like wholesale changes to this would impact the editability and potentially backwards compatibility to previous versions of the guides.

[michalvavrik]

sure @gsmet , I need to start working on it before elaborating more. For me, when I use the all config page, my user experience is still bad.

Also, isn't this edited via asciidoc? Seems like wholesale changes to this would impact the editability and potentially backwards compatibility to previous versions of the guides.

You decide what you generate with ASCIIDOC, if I decide to additionally to generate json object or something, there is no reason why it can't be compatible with what other versions do. What I take from that @insectengine is that I should keep in mind backwards compatibility. Thanks, good point.

[gsmet]

Yeah so the thing is that some context is kept by the previous rows. If you just get the JSON properties from a search engine, you might miss some context (like the section or the extension).

So you need to make sure you push the sections + the extension when indexing.

If you experiment with the current search, you will see we try hard keeping the extension + section context (this is recent, thus why I underline it).