The build is slow

[bryanbraun]

So slow.

I'm pretty sure it's because of this code here. I'm thinking the big O complexity isn't very favorable.

I still want to be able to do related articles, so if there's a way to optimize these loops without changing how related articles work, that would be ideal. If we need to, we can change how related articles are formatted in the metadata.

[bryanbraun]

Ok I did some reasearch and here's what I found:

1. The slowness is in the _head.html include and the default.html include.

$ jekyll build --profile
Configuration file: /Users/bryanbraun/Code/bryanbraun/bryanbraun.com/_config.yml
            Source: /Users/bryanbraun/Code/bryanbraun/bryanbraun.com
       Destination: /Users/bryanbraun/Code/bryanbraun/bryanbraun.com/_site
 Incremental build: disabled. Enable with --incremental
      Generating...

Filename                                                 | Count |     Bytes |   Time
---------------------------------------------------------+-------+-----------+-------
_layouts/default.html                                    |   383 | 10719.14K | 75.495
_includes/head.html                                      |   383 |  3965.61K | 73.147
_layouts/compress.html                                   |   383 |  8218.11K |  6.085
_layouts/post.html                                       |   370 |  4074.32K |  1.658
sitemap.xml                                              |     1 |    50.94K |  0.385
_includes/comments.html                                  |   370 |   444.42K |  0.129
rss.xml                                                  |     1 |    43.63K |  0.075
_includes/logo.html                                      |   384 |  1471.12K |  0.040
_pages/archives.html                                     |     1 |    96.67K |  0.026
...

2. The build gets way faster if I remove the CSS inlining which makes sense. The current setup requires me to compile my sass once for each page.
3. Other possible high-hanging fruit to investigate for slow builds is the related links loops and html minification.

Some options for solving 2 include:

• Manually compile sass once before the build and then inline the CSS. This would require gulp, a rake task, or some other external system. It feels like it would be a kludge and wouldn't work well with all of jekyll's build and serve options.
• Move away from using sass completely, and use a combination of css variables and liquid includes. This sounds nice, but around 8% of my visitors use browsers that don't support CSS variables (like IE 11 and lower, and Opera Mini). Also, the fallbacks are just redundant css, in which case, I might as well get rid of variables (which I suppose is also an option... they aren't being used a whole lot).
• Stop inlining CSS. I really like inlining it because the site is so fast for users. There's ZERO flash or delay because the CSS is just there. I might be able to compensate for this effect with something like service workers or http2 push (looks like http2 push isn't supported).
• Figure out a way to use cached includes in local builds (because github pages doesn't support them). I can bypass the whitelist locally, but I'd still end up with those custom liquid tags in my templates, which production probably won't like.

In short, it looks like my options right now are switch back from SASS to CSS, or undo my some of my performance tweaks. 😞

[bryanbraun]

Just an idea: I might be able to use Jekyll Hooks to find a time during the build lifecycle after my _includes/main.scss file is generated but before the pages are built, where I can convert that file into css ONCE, so it can just be imported as-is. It would probably be ignored on github-pages, but I only need it to run locally (which can be done with environment variables). I would have to figure a way for it to "fallback" to the current method for Github Pages though... 🤔.

Also, with a different approach I might not need to source it from _includes. It could be a normal css file that just gets included with a special template token or something. That would need a fallback, but that seems doable with template conditions.

[bryanbraun]

Update: the SCSS compiling performance will improve when updating to to Jekyll 4 (because it uses csass , instead of Ruby Sass). I can get those performance upgrades once github pages supports Jekyll 4. For progress on that, see github/pages-gem#651

Alternatively, I could move away from using pages-gem, and use something like Github actions to do a manual build on git push. This would let me upgrade to jekyll 4 and add other custom stuff (like a Jekyll hooks thing). But then I'd be responsible for managing bugs & security issues in my custom setup, instead of offloading that work to pages-gem.

[bryanbraun]

Update: I checked the analytics again, and the % of visitors using browsers that don't support CSS Custom Properties has dropped to less than 2.5%. That makes me feel better about switching away from Sass to CSS.

[bryanbraun]

Here's the profiling after some fixes:

Original Build (done in 68.763 seconds).

Filename                      | Count |     Bytes |   Time
------------------------------+-------+-----------+-------
_layouts/default.html         |   426 | 14068.21K | 59.113
_includes/head.html           |   426 |  4688.12K | 57.499
_layouts/compress.html        |   426 |  9444.33K |  4.186
_layouts/post.html            |   413 |  6197.91K |  1.660
sitemap.xml                   |     1 |    56.99K |  0.326

Switching from SCSS to CSS (done in 13.698 seconds).

Filename                      | Count |     Bytes |  Time
------------------------------+-------+-----------+------
_layouts/compress.html        |   426 | 11076.36K | 4.899
_layouts/default.html         |   426 | 15994.78K | 3.011
_layouts/post.html            |   413 |  6197.91K | 1.700
_includes/head.html           |   426 |  6614.69K | 1.387
sitemap.xml                   |     1 |    56.99K | 0.274

Switching to CSS and removing HTML compression (done in 7.811 seconds):

Filename                      | Count |     Bytes |  Time
------------------------------+-------+-----------+------
_layouts/default.html         |   426 | 15994.78K | 2.798
_layouts/post.html            |   413 |  6197.91K | 1.506
_includes/head.html           |   426 |  6614.69K | 1.279
sitemap.xml                   |     1 |    56.99K | 0.275

Yeah, this is a pretty huge improvement, and it should have minimal effect on the end-user.

The only additional user cost is that the SASS comments are no longer stripped out, and the html isn't compressed. The more I've research html compression, the more I feel like it's not really worth it, especially after gzipping.