Sass Build Times

Posted on 24 January 2024 by Lee Moody.

TL;DR:Sass build times got you down? Enable Sass monitoring in your project and let us know.

We’ve heard many teams at the FT are struggling with slow Sass build times. Friction between making a change and seeing the result can be pretty painful, right! It slows down our ability to iterate and deliver, and gives ample opportunities for distraction… and doom scrolling… as we wait.

We can’t blame Sass too much, it’s wonderful, but we have a large estate of complex Sass that has become slow. In our view, now is the time to migrate away from Sass.

Enable Sass Monitoring

If you’re working on a project which builds with Page Kit (dotcom-build-sass), please setup remote Sass monitoring. This will help us make a case to invest in migrating away from Sass more quickly.

Remote Sass monitoring

1. Upgrade your project to dotcom-build-sass@9.3.2 or above.
2. Add the following environment variables to Doppler for dev, we want these during local development.
   • FT_SASS_STATS_MONITOR – on, to enable remote logging to biz-ops-metrics
   • FT_SASS_BIZ_OPS_API_KEY - Generate a prod Biz Ops Metrics API key for your system.
   • FT_SASS_BIZ_OPS_SYSTEM_CODE - The biz-ops system code for your project, so we know where to attribute Sass build times.
3. Prepend your local front-end build script in package.json to fetch Doppler secrets, doppler run --project [your-project] --config dev --. This may vary depending on your project. E.g:

"build": "dotcom-tool-kit build:local",
"build": "doppler run --project [your-project] --config dev -- dotcom-tool-kit build:local",

"watch": "webpack --progress --mode=development --watch",
"watch": "doppler run --project [your-project] --config dev -- webpack --progress --mode=development --watch",

Now, each time Sass is built, the duration is sent to biz-ops.

Local Sass monitoring

After your project has updated to dotcom-build-sass@9.3.2 or above, you will periodically see a log showing your cumulative Sass build time. Like this:

Whilst remote monitoring will prove very useful, this local report is more for fun. Or, motivation. It highlights the total time you have spent waiting for Sass in all – at least since the temporary file it’s stored in was last deleted by your operating system.

Set the FT_SASS_STATS_NOTICE environment variable to configure how often you see the port on on your machine. One of throttle, never, or always.

E.g. to see your cumulative Sass build time after every build FT_SASS_STATS_NOTICE=always npm run build

More ways for you to help

1. Share your experience in #sass-to-css! If Sass build times have you down, feel free to have a good moan. We’d also love to see your cumulative Sass build time – let’s we’ll see who gets the high score! 😬
2. Become an early adopter of our new Origami components, which don’t use Sass. Let us know you’re interested in #origami-chat and we’ll help you get started.
3. Write less Sass yourself and refactor custom variables, functions, or mixins. Our Sass to CSS proposal includes examples of FT Sass and modern CSS alternatives.
4. Praise Ben Holmes and the Developer Automation team (#developer-automation). They’re working on automated Origami Sass to CSS migration tools (codemods). Checkout this prototype, how cool! More news to follow.

Big thanks to

• Joel Carr and the CP Platforms team for supporting us to use PageKit to roll out Sass monitoring to key Customer Products projects.
• Kiya Gurmesa, Rhys Evans, and Engineering Insights for support using the Biz-Ops Metrics API. This is how we plan to aggregate local build times.
• Ben Holmes and Developer Automation for working on Origami Sass to CSS migration tools (codemods). Watch this space for more information!
• Andy Gout for helping us test this out, and for rolling out so quickly to next-newsletter-signup (PR).