Skip to main content Accessibility Feedback

Build tool plugins for web performance

Last week, Keith Cirkel tweeted out…

Writing a Webpack plugin that makes build times at least as long as it takes to download them.

class WebpackPluginUXGtDX {
  apply(compiler) {
    compiler.hooks.emit.tapPromise(
      'UX is more important than DX',
      (compilation) => {
        return new Promise(resolve => {
          const ms = getP95ForBundleOn3g();
          console.log(`This bundle takes ${ms}ms to download`);
          console.log(`I'm making you wait at least as long as that.`);
          console.log(`If you want a faster build, work on that.`);
          setTimeout(resolve, ms);
        });
    });
  }
}

The included code, in theory, gets the download time for the bottom 5th percentile of users on 3g connections, and forces the build to wait that long before proceeding.

While this is a joke (I think?), I also think Keith is on to something.

A lot of “thought leaders” in our space obsess over the developer experience (DX), and have bought into the myth that better DX leads to a better user experience (UX). They also often work on really expensive high-end machines, connected to a fast and reliable network.

That’s just not the reality for a lot of people who use what we build. It’s hard for a lot of people to feel empathy without experiencing that pain themselves.

I’d love to see build systems have a built in setting that you can use to throttle builds to what actual users experience.

You can automate some aspects of performance. Minifying and gzipping help. Service workers do, too.

But a lot of web performance is baked into the core of your code, how you write it, and what you ship.