Search Improvement

Yes you have a number of options defer or async.

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.

<script defer src="https://domain.com/a.js"></script>
  • Scripts with defer never block the page.
  • Scripts with defer always execute when the DOM is ready, but before DOMContentLoaded event.
<script async src="https://domain.com/a.js"></script>
  • 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.

1 Like

Zola 12 Still uses full path.

Search_index.en.js:

window.searchIndex = {"fields":["title","body"],"pipeline":["trimmer","stopWordFilter","stemmer"],"ref":"id","version":"0.9.5","index":{"body":{"root":{"docs":{},"df":0,"0":
{"docs":{"https://adeptenglish.com/lessons/english-learn-grammar-2/":{"tf":1.7320508075688772},
"https://adeptenglish.com/lessons/ielts-listening-practice-online/":{"tf":1.4142135623730951},

... 

As previously discussed, a significant improvement could be made if this was just the root path not the full site path.

There were some potential issues with using path but I can’t remember right now :frowning:
I think it might be ok for the search index

Ok thanks for taking a look at it. Shame as it looked like an easy win. :slight_smile:

I’ll double check whether it was an issue with the search index or not, that is an easy win if possible.

V12/13 Search

Other than the path optimization missing search is awesome. It’s everything we could have hoped for :slight_smile: 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 :slight_smile: or update the example used by getzola on github.

1 Like