But the elasticlunr search engine will need to be initialised locally at some point and if the file is large it will be slow, the user may end up thinking that search does’nt work at all. We ended up accepting that the user will just have to have the file downloaded in the background once on the first page they hit, then rely on caching.
The page content shows up immediately: async doesn’t block it.
DOMContentLoaded may happen both before and after async , no guarantees.
Async scripts don’t wait for each other.
It can get complicated if you have dependencies in your scripts.
Ultimately deffering the pain cost of a large download does not solve the problem unless you don’t expect a user to use search. Obviously caching, gzip compression help.
You might be able to give a better first time impression of site performance.
Control over the size of the search index is the only way to go, if you have a page size (Kb budget) for a page (ours is a max of 1Mb) and about 800kb for critical pages. You can balance the search download costs with graphics and other media.
Other than the path optimization missing search is awesome. It’s everything we could have hoped for Thank you for implementing this.
I might suggest that you mention there are now 3 fields available in the search_index.en.js
title
description
content
It’s not really a zola issue as the search is mostly elasticlunr But for those who want to implement search mentioning that Zola generated three fields and that the JS implementation might want to boost (elasticlunr term…) these to specify importance placed on the field text the users search term was found.
Thinking about it, zola should just say the absolute minimum or update the example used by getzola on github.