mkdocs-material
mkdocs-material copied to clipboard
squidfunk
Search: caching for faster startup
Context
In our docs, it takes about 5 seconds for the search plugin to become ready.
Description
Currently, the search index input is requested and indexed on every page load. Instead, the final search index could be kept in local browser storage and loaded from there if the search index input can be determined to be the same.
Related links
- https://github.com/squidfunk/mkdocs-material/issues/2976
Use Cases
The user would need to provide a version identifier (e.g. git SHA, release number) that will be used as the cache key. Alternatively, material could compute a hash of the docs itself, though I'm not sure how realistic that is.
The advantages would be reduced bandwidth usage and less delay until the search plugin is ready.
Visuals
No response
Before submitting
- [X] I have read and followed the change request guidelines.
- [X] I have verified that my idea is a change request and not a bug report.
- [X] I have ensured that, to the best of my knowledge, my idea will benefit the entire community.
- [X] I have included relevant links to the documentation, related issues, and discussions to underline the need for my idea.
Thanks for suggesting! We're currently reworking the search implementation to be much more powerful that what we currently have in place. Caching is something we'll also be investigating. In the meantime, you can use instant loading, which means you will only pay the cost of index initialization on the first request.
If I understand #2976 correctly, the prebuilt search index will be removed in the next iteration of the search functionality.
One of the strengths of Material for MkDocs thus far has been its support for offline usage.
Will the caching mechanism proposed here (or the instant loading workaround) support the offline use case with the new search features?
The prebuilt index was removed in Material for MkDocs 8 1,5 years ago. Offline search already works pretty well, and the new search will definitely continue to do so. We'll investigate caching on file:// locations, but I think for most docs, it won't be necessary, as the new search needs a fraction of the time to create the search index. My tests show that the new search index builds up to 5x faster, i.e., for our docs, the time dropped from 200ms to 40ms.
Instant loading does not work on file:// due to browser limitations. Same goes for some other features.