Breaking the Bundle: Moving from PostCSS Bundles to NoBuild CSS

[t-kelly]

For years, we've been chasing the dream of individually scoped components for our CSS. While we've achieved that, bundling everything into a single file has been a necessary compromise to ensure fast load times by reducing the number of requests. However, this approach introduced its own challenges:

• Performance issues: Large bundles still block rendering and require additional HTTP request to Shopify CDN
• Complexity: The bundled file becomes a nightmare to debug or modify.
• Build tool dependency: We've relied on PostCSS with minimal plugins to keep things manageable, but even this felt like overengineering.

With performance improvements in browsers, networks, and devices, we questioned if this bundled approach was still necessary. Could we deliver individually scoped CSS files asynchronously or inline them without significant performance costs? This post explores our findings and the shift to a no-build, component-based CSS workflow.

The problem with a single CSS bundle

• Introduces a render-blocking CSS request, delaying page display.
• Our bundle, at 42KB (Brotli compressed), adds a meaningful impact to load time on slower connections. Yes it could be smaller, but 42kb is still relatively small.
• It includes unused CSS for components not present on the current page.
• Requires a build step and build tools, increasing overall solution complexity.
• Creates a massive, hard-to-debug file with thousands of lines. Debugging individual components is challenging without source maps.

The New Approach: Component-Based CSS

How It Works

1. Automatically Inline Critical Styles: Above-the-fold components are inlined directly in the HTML via inline_asset_content.

<style>{{ 'header.component.css' | inline_asset_content }}</style>

2. Async Loading for Other Components: Less-critical styles are loaded asynchronously, reducing render-blocking requests.

<link href="{{ 'media.component.css' | asset_url }}" rel="preload" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="{{ 'media.component.css' | asset_url }}"></noscript>

3. No Build Tools: Each component ships with its CSS included, ready to copy and paste into the theme's asset folder.

Performance Comparison

Summary

Metric	Bundled CSS	NoBuild CSS
Document size	47KB	70KB
External stylesheet size	42KB (blocking), 1 request	42KB (async), 28 requests
First Contentful Paint	7.2 seconds	2.8 seconds

Testing Conditions: Chrome w/ 20x CPU slowdown + emulated 3G (exaggerated conditions by todays standards)

Bundled CSS

Here we can see how things typically flow when you depend on a single CSS bundle:

NoBuild CSS

Implementation Details

Here's our first crack at a new stylesheet component that automatically detects whether to inline or async request a stylesheet. You can even manually provide overrides, e.g cart drawer styles that are included in the header.

{%- comment -%}
  Renders a stylesheet link or inline style based on the section location and index.

  Accepts:
  - name {string} - The name of the stylesheet asset, e.g. 'styles.css'
  - async {boolean} - Whether to load the stylesheet asynchronously
  - inline {boolean} - Whether to inline the stylesheet content
  - blocking {boolean} - Whether to load the stylesheet blocking

  Usage:
  {% render 'stylesheet', name: 'styles.css', async: true %}
{%- endcomment -%}

{%- liquid 
  assign name = name | default: ''

  # Default inline logic based on section location and index
  assign default_inline = false

  if section.location == 'header'
    assign default_inline = true
  endif

  if section.location == 'template' and section.index <= 2
    assign default_inline = true
  endif

  # Proritize specific overrides
  if inline == true
    assign choice = 'inline'
  elsif async == true
    assign choice = 'async'
  elsif blocking == true
    assign choice = 'blocking'

  # Default to async unless default inline criteria are met
  elsif default_inline
    assign choice = 'inline'
  else 
    assign choice = 'async'
  endif
-%}

{%- if choice == 'async' -%}
  <link href="{{ name | asset_url }}" rel="preload" as="style" onload="this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="{{ name | asset_url }}"></noscript>
{%- elsif choice == 'inline' -%}
  <style>{{ name | inline_asset_content }}</style>
{% elsif choice == 'blocking' %}
  {{ name | asset_url | stylesheet_tag }}
{% endif %}

Observations

• Repeated inline styles not a problem with Brotli: Brotli compression on HTML response reduces bytes-over-wire of repeated inline CSS. If a component is included on the page 100 times in the header, they could have styles included inlined 100 times but repeated elements is what compression is good at optimizing.
• Styles inlined for every page request: We've grown our HTML response by ~23kb which does increase the time it takes to download but is at least as fast as requesting an external stylesheet for the first page load. It would be great if Liquid had a request.new_session value that would allow us to inline styles + preload the duplicate external style sheet versions async, and then not inline styles for subsequent navigations, something like:

{% if request.new_session %}
	<style>{{ name | inline_asset_content }}</style>
	<link href="{{ name | asset_url }}" rel="preload" as="style">
{% else %}
	{{ name | asset_url | stylesheet_tag }}
{% endif %}

Closing Thoughts

We're excited by these test results! We've improved performance, eliminated build complexity, and created a more maintainable codebase. While this approach isn't perfect, the benefits far outweigh the drawbacks.

Have you experimented with bundling alternatives or component-based CSS? We’d love to hear about your challenges, successes, and insights. Drop us a comment!

[jpallard6120]

More than 2x improvement on FCP is impressive! Really shows the power of async, where loading more requests concurrently performs so much faster than a single one. The configuration options for async vs inline vs blocking are cool as well, to have flexibility regarding CLS.