-
Notifications
You must be signed in to change notification settings - Fork 25.6k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Minimize JSON data #1449
Minimize JSON data #1449
Conversation
Looking good. We might have to think about truncating the excerpts size, but looking at the the I'm showing around 246 kB for an index with all of the body content. Which isn't great, but not awful since the searches for |
_includes/scripts.html
Outdated
@@ -19,8 +19,9 @@ | |||
{% else %} | |||
{% assign lang = "en" %} | |||
{% endcase %} | |||
<script src="{{ '/assets/js/lunr.min.js' | absolute_url }}"></script> | |||
<script src="{{ '/assets/js/lunr-' | append: lang | append: '.js' | absolute_url }}"></script> | |||
<script src="{{ '/assets/js/lunr/lunr.min.js' | absolute_url }}"></script> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably worth adding defer
to each of these three scripts to give priority to the other page content loading first.
eg. <script defer src="{{ '/assets/js/lunr/lunr-...js' | absolute_url }}"></script>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm great idea! We could also use liquid to decide whether to truncate or not based on the number of posts there are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that idea of truncating based on the number of posts. Not sure what a good baseline should be. Guess it really depends on the the size of {{ content }}
.
In the case of the MM demo site, the documentation pages are pretty big and full of words.
Maybe we default to truncating (can probably up it to well over 50 words) and then have an override setting in _config.yml
to index the full post. If the user wants to take the potential hit to page load perf they can.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something like:
#_config.yml
search_full_content: true # true, false (default)
<!-- lunr-store.js -->
{% if site.search_full_content == true %}
{% assign excerpt = doc.content | strip_html | strip_newlines | jsonify %}
{% else %}
{% assign excerpt = doc.content | strip_html | truncatewords: 20 | jsonify %}
{% endif %}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if there is a safe zone parameter which gets activated when there are over a thousand posts and its default size is set to 50 but can also be modified to be lower or higher ? If that's too complicated then we could have some pre-set parameters like: safe which would be somewhere in the 50s and super-safe which would be 20.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m not convinced post count is the way to go, way too unreliable. I could have 2,000 posts with a sentence of text each or have a couple hundred with epic word counts going over 10,000 and get a huge lunar-store.js
because it falls below the threshold.
I think truncating the content to around 50 words by default, with a config override to turn that off would be sensible. If someone wants to get more granular with the amount of words truncated they override the theme file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it really depends on the individual. The switch is great option too since it's more straight forward if the user has too much content they simply turn off the search_full_content parameter.
* Remove Lunr trimmer & bring back colons * Add Greek Stemmer * Translate search_placeholder_text and results_found to Greek * Minimize JSON data * Truncate Words * Move store variable into a new file * Move Lunr files into a new folder * Add defer to lunr scripts * Add search_full_content switch
* Remove Lunr trimmer & bring back colons * Add Greek Stemmer * Translate search_placeholder_text and results_found to Greek * Minimize JSON data * Truncate Words * Move store variable into a new file * Move Lunr files into a new folder * Add defer to lunr scripts * Add search_full_content switch
* Remove Lunr trimmer & bring back colons * Add Greek Stemmer * Translate search_placeholder_text and results_found to Greek * Minimize JSON data * Truncate Words * Move store variable into a new file * Move Lunr files into a new folder * Add defer to lunr scripts * Add search_full_content switch
Undo changes in mmistakes#1449
I was thinking of maybe moving the last function ( where the search takes place and the results are displayed ) into a new file too but I am not currently sure if it's going to stay the same for every language that I add.
Live Preview