Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimize JSON data #1449

Merged
merged 10 commits into from
Jan 5, 2018
Merged

Minimize JSON data #1449

merged 10 commits into from
Jan 5, 2018

Conversation

nickgarlis
Copy link
Contributor

@nickgarlis nickgarlis commented Jan 4, 2018

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

@mmistakes
Copy link
Owner

mmistakes commented Jan 4, 2018

Looking good. We might have to think about truncating the excerpts size, but looking at the the lunr-store.js for the MM demo site it's not too bad.

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 "search" actually produce results now. Guess if someone has a 1,000 post site it might be too big, but otherwise I'm fine with leaving it as is for now.

@@ -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>
Copy link
Owner

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>

Copy link
Contributor Author

@nickgarlis nickgarlis Jan 4, 2018

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.

Copy link
Owner

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.

Copy link
Owner

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 %}

Copy link
Contributor Author

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.

Copy link
Owner

@mmistakes mmistakes Jan 4, 2018

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.

Copy link
Contributor Author

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.

@mmistakes mmistakes merged commit 3fb63f3 into mmistakes:master Jan 5, 2018
kkunapuli pushed a commit to kkunapuli/kkunapuli.github.io that referenced this pull request May 30, 2019
* 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
sumeetmondal pushed a commit to sumeetmondal/sumeetmondal.github.io that referenced this pull request Sep 10, 2019
* 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
jchwenger pushed a commit to jchwenger/jchwenger.github.io that referenced this pull request May 5, 2023
* 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
okitem pushed a commit to okmalls/okmalls.github.io that referenced this pull request Mar 9, 2024
okitem pushed a commit to okmalls/okmalls.github.io that referenced this pull request Mar 9, 2024
okitem pushed a commit to okmalls/okmalls.github.io that referenced this pull request Mar 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants