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 beforeDOMContentLoaded
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 afterasync
, 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.