On not minifying CSS & JS (part 2)

Jan 27, 2026 · 3 minutes to read

• Tags: 
• 11ty  
• CSS  
• All Tags

Introduction

It was as long ago as yesterday when I wrote about how I had decided to not minify the CSS and JS bundles for the 11ty Bundle website. As stated in the update, the issue that was causing my long build times was not the minifying itself, but rather the way I had configured the CSS and JS bundling in the base layout file. This meant that for every page of the site, the CSS and JS bundles were being re-bundled and minified, leading to excessive build times. Eliminating the minification step dramatically reduced the build time.

That said, what I was left with was the bundling process happening for every page, though it is far less expensive. This did not sit totally right with me and some members of the 11ty Discord community suggested that I look at configuring the bundling outside of the base layout file so that the bundling only happens once per build, rather than once per page.

And so, here we are and here's how I've done exactly that.

Before: The setup I described yesterday

Prior to today's changes, the following code snippet, and what was shown in yesterday's post is from the base layout file for the project.

  {# bundle the global css files #}
  {% css "global" %}
    {% include "public/css/fonts.css" %}
    {% include "public/css/variables.css" %}
    {% include "public/css/reset.css" %}
    {% include "public/css/home.css" %}
    {% include "public/css/global.css" %}
    {% include "public/css/site-header.css" %}
    {% include "public/css/site-footer.css" %}
    {% include "public/css/pagefind.css" %}
  {% endcss %}

  {# load the global css file for all pages #}
  <link rel="stylesheet" href="{% getBundleFileUrl 'css', 'global' %}">

  {# bundle the channel-related css files #}
  {% css "channel" %}
    {% include "public/css/channels.css" %}
    {% include "public/css/showcase.css" %}
    {% include "public/css/blog.css" %}
    {% include "public/css/prism-okaidia.css" %}
    {% include "public/css/lite-yt-embed.css" %}
    {% include "public/css/404.css" %}
  {% endcss %}

  {# conditionally load the channel-related css file #}
  {% if channelsPage %}
    <link rel="stylesheet" href="{% getBundleFileUrl 'css', 'channel' %}">
  {%endif %}

I wanted to remove the bundling from the base layout file so that it only happens once per build, for both the CSS files and the Javascript files.

After: The new setup

What I did was remove the the bundling from the base layout and, for each of the two CSS bundles, create a Nunjucks template file in a "bundles" directory of my input folder. Here's what one of those two files looks like.

---
layout: null
permalink: /css/global.css
eleventyExcludeFromCollections: true
---
{# bundle the global css files #}
{% css "global" %}
  {% include "public/css/fonts.css" %}
  {% include "public/css/variables.css" %}
  {% include "public/css/reset.css" %}
  {% include "public/css/home.css" %}
  {% include "public/css/global.css" %}
  {% include "public/css/site-header.css" %}
  {% include "public/css/site-footer.css" %}
  {% include "public/css/pagefind.css" %}
  {% include "public/css/404.css" %}
{% endcss %}
{% getBundle "css", "global" %}

Rather than having the bundle plugin generate a content-hashed filename for the bundle, I am now specifying a permalink for the file. This means that the bundled CSS file will always be available at /css/global.css.

I have another similar file for the channel-related CSS files and two similar files for the Javascript bundles.

Then, in the base layout file, I simply load the CSS and JS bundles like so:

  {# load the global css file for all pages #}
  <link rel="stylesheet" href="/css/global.css">

  {# conditionally load the channel-related css file #}
  {% if channelsPage %}
    <link rel="stylesheet" href="/css/channel.css">
  {%endif %}

Conclusion

While this had little impact on the build times, I find this to be a much cleaner and more easily maintained approach. The base layout stays cleaner and the CSS and JS bundling is now clearly defined in their own files.

Thanks to Aankhen and John Brooks in the 11ty Discord community for suggesting this approach!

Comment by email