Large Refactor: Server-side pagination and optimization #118
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
July 11, 2015 22:14
This commit does several things: - Moves pagination server-side and eliminates the client JSON load delay (also fixing Google indexing) - Makes paging controllable via the config again - Normalizes config differences - Sets top navigation classes (and styling) on generation (eliminating flicker on load) - Eliminates the need to generate a corresponding _tag/<name>.md entry for every new tag - pages are generated directly off the posts themselves - Eliminates two JavaScript file loads: hashchange and browser - Removes the engineering and company folders with lots of duplicate code (now defined in the generator and DRY coded) - Eliminates all global JavaScript variables (by removing most of the JavaScript) - Removes many hidden-on-load stylings since the content is immediately there now - Resolves the reverse-chronological archived comment ordering (due to .prepend()) - Speeds up full rebuilds 15-25x - **Removes** paging on the author page (this is intended to be added back - stop-gap commit here) - **Removes** compression and the compression layout - this had very, very little benefit at a high cost and much more difficult dev debugging While Jekyll is doing far more work here - it’s also doing so much faster due to optimizing how liquid is used. With a combination of removing inefficient liquid loops (especially the tag counts) and moving one-time shared generation to Ruby on the posts, builds went from 300-350 seconds on this 2013 MacBook down to 15-25 seconds. Next steps: re-paginate authors and move archive comments to server-side generation.
|
Side note here: I don't Ruby. If someone wants to tell me everything wrong with that plugin please do. I'd actually love corrections conveyed however you like: via PR (code fixes are as good as comments to me), or here, or...whatever. I'm sure there are missteps in there (I don't even have an IDE for Ruby installed), and I'd honestly appreciate being told what's wrong & can be better. |
This was referenced Jul 12, 2015
This also normalizes a duplicate “announcements” tag on a single post - the rest were “announcement”
Merged
This commit does several things: - Moves pagination server-side and eliminates the client JSON load delay (also fixing Google indexing) - Makes paging controllable via the config again - Normalizes config differences - Sets top navigation classes (and styling) on generation (eliminating flicker on load) - Eliminates the need to generate a corresponding _tag/<name>.md entry for every new tag - pages are generated directly off the posts themselves - Eliminates two JavaScript file loads: hashchange and browser - Removes the engineering and company folders with lots of duplicate code (now defined in the generator and DRY coded) - Eliminates all global JavaScript variables (by removing most of the JavaScript) - Removes many hidden-on-load stylings since the content is immediately there now - Resolves the reverse-chronological archived comment ordering (due to .prepend()) - Speeds up full rebuilds 15-25x - **Removes** paging on the author page (this is intended to be added back - stop-gap commit here) - **Removes** compression and the compression layout - this had very, very little benefit at a high cost and much more difficult dev debugging While Jekyll is doing far more work here - it’s also doing so much faster due to optimizing how liquid is used. With a combination of removing inefficient liquid loops (especially the tag counts) and moving one-time shared generation to Ruby on the posts, builds went from 300-350 seconds on this 2013 MacBook down to 15-25 seconds. Next steps: re-paginate authors and move archive comments to server-side generation.
This also normalizes a duplicate “announcements” tag on a single post - the rest were “announcement”
|
Awesome work. Blazingly fast now. |
JonHMChan
added a commit
that referenced
this pull request
Jul 13, 2015
Large Refactor: Server-side pagination and optimization
JonHMChan
added a commit
that referenced
this pull request
Jul 17, 2015
Large Refactor: Server-side pagination and optimization
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Many changes here that had to be wrapped together, so I'll enumerate:
delay (also fixing Google indexing)
flicker on load)
for every new tag - pages are generated directly off the posts
themselves
code (now defined in the generator and DRY coded)
JavaScript)
immediately there now
.prepend())back - stop-gap commit here)
very little benefit at a high cost and much more difficult dev debugging
While Jekyll is doing far more work here - it’s also doing so much faster due to optimizing how liquid is used. With a combination of removing inefficient liquid loops (especially the tag counts) and moving one-time shared generation to Ruby on the posts, builds went from 300-350 seconds on this 2013 MacBook down to 15-25 seconds.
Next steps: re-paginate authors (even the worst case, Jeff Atwood, performs fine as-is) and move archive comments to server-side generation (this needs a Python => YAML discussion Monday to be crazy efficient).