[BUG] Slow page loads due to large search index

[sleepyspider1]

https://docs.vulkan.org/spec/latest/index.html

Navigating the website is painful with Microsoft Edge.
Several seconds for a page to load and be functional.
The bar at the top is frequently unresponsive.

• OS: Windows 11
• Browser: Edge
• Version: 132.0.2957.115 (Official build) (64-bit)
• CPU: Ryzen 7 6800U + 16GB Ram

[SaschaWillems]

While not excruciatingly slow, load times on my side (chromium based browsers, also happens with firefox) is considerably slower than it used to be. I get up to 2 second per page, every time I switch to a different page on the side. The page content itself is loading pretty fast, but it looks like some script takes a long time to load and is loaded on every page load.

[oddhack]

While not excruciatingly slow, load times on my side (chromium based browsers, also happens with firefox) is considerably slower than it used to be. I get up to 2 second per page, every time I switch to a different page on the side. The page content itself is loading pretty fast, but it looks like some script takes a long time to load and is loaded on every page load.

AFAIK the only recent significant changes were dark mode and the new searching code. It's too late to recover a tarball from CI before the search changes in #101, but we could back off the UI build manually and compare. @gpx1000 did you happen to do any testing on #101 that could inform whether that might be related to the issue?

[SaschaWillems]

One thing that seems to be new: The site now tries to load external JavaScript from https://cdn.jsdelivr.net/pako/1.0.3/pako.min.js. Since I use a script blocker, and hadn't had a rule for that I think that's something new which also might be related to the loading times. Might be a good idea to move that JS to our repo, as using external CDNs is something that might require consent from EU users.

[gpx1000]

Pako is a new dependency, we use it for the index which is now binary and compressed instead of ASCII and uncompressed. This makes the index go from 200+mb to around 30. That's what used to cause the download slowdown. Yes bringing pako to our cdn should be faster download.

The amount of times the page load happens hasn't changed nor has the index reload, that code is still the same but a significant improvement might be to make it more complicated by breaking the index up to multiple indexes.

Not sure what you mean by we don't have access to the old tarball, I believe we have access to all of the code and comparing us pretty trivial

[oddhack]

I mean that the build artifacts from CI for the older specs no longer exist as they are purged by Actions after a couple of weeks, so reconstructing a site build with the older UI in order to compare with the current version would require modest additional effort.

[gpx1000]

I see what you're saying, however I'm this case it's a good thing. Every build of antora creates a new index as each index is only valid per version of module. After that it merely passes code into a folder and creates a tarball. As the tarball is a build asset, it would be harder to get anything important from comparing one to the other.

The code itself is still in git and we don't have to so anything to figure out changes to it.

Anyway, I just ran the site under edge, I'm seeing a fairly responsive site with page loads around a sec. I think we might need to bring the js to our host as Sasha recommended. The only way the sure should be slower is if the CPU is overburdened by the decompression. Networking wise downloading a smaller file should be faster so my only guess is it's some form of artificial block like Sasha guessed, a block on external js makes a lot of sense for the problem.

[oddhack]

What I see here under Chromium is that the top of the page being loaded indeed renders rapidly, but the searchbox functionality is grayed out for 5-6 seconds while an activity spinner is shown in the tab, on a gigabit connection. That sounds like the same behavior the OP reported. What's actually causing the delay I don't know, but I don't think it was there in the past.

[SaschaWillems]

Same for me. The content of the page loads very fast, but it takes several seconds before I can access the search box.

[gpx1000]

Okay, I see what you're saying. The index gets loaded in parallel then enables the search box once it is loaded. That way the site is responsive until it has loaded a very large file into memory. That tracks.

[SaschaWillems]

Another issue I noticed: Images for pages seem to be loaded after the search index. So on slower connections (pretty much all of Germany) you'll have to wait for images to show up multiple seconds for every page.

Just tested this with a different connection (than mine) and opening any page of the guide has this issue. You open the page, it takes several seconds to load the search index and only then images AND navigation arrows are loaded. So you actually can't interact with the page at all until the search index is loaded. And caching doesn't seem to work with that index. So right now, the docs site is almost unusable to me over here in Germany.

So we should try to fix that kinda soonish. No idea how to do that though.

[gpx1000]

Hmmm... Maybe what we can do is explode the index in the cache so it loads fast if you already have it and still downloads fast if you don't?

I think real solution is to break up the index but that could take a bit of thought how to do right. I'll start working on the expand in cache.

[SaschaWillems]

That does sound like an option. Or maybe leverage IndexedDB, which to my knowledge was added to browsers for use cases like this?

Though I guess we won't get around having to implement some form of server-side search in the future due to the search index growing and growing.

[gpx1000]

I'm not sure we'll ever need server side. If we break up the index, then make downloading it only required for core modules, it can be cached as it never changes. The assumption would be it will eventually all download.
Keeping the ability to get/use documentation without an active Internet connection is a really awesome feature to me.

[SaschaWillems]

That would indeed be optimal :)