SPFx overclockers or how to significantly speed up the "gulp serve" command

A few months ago I wrote an article about SharePoint Framework build performance - SPFx overclockers or how to significantly improve your SharePoint Framework build performance. I've tried to reduce the amount of time the "gulp serve" command uses to re-build your code and to finally refresh a browser. I used different optimization technics for that purpose. The idea was to tweak the default SPFx build pipeline. However, those post only partially solves the problem. 

In this post, I will solve the problem from another way around (spoiler: I managed to make "serve" 10-15 times faster). 

The idea

How SharePoint Framework's "gulp serve" works? It gets your sources and outputs javascript bundles. But "gulp serve" becomes slow when your solution grows. How to fix that issue? Well, since it's slow, then don't use it! 

So this is the idea - don't use "gulp serve", use completely custom webpack based build to transform your sources into exactly the same javascript bundles which are produced by "gulp serve". 

What is the input for "gulp serve"? - TypeScript sources, styles. What is the output? - Javascript files. Can we get sources and produce exactly the same javascript? -Yes.

How it works

Some nerdy content goes below. If you don't want to read about internal implementation, go directly to "How can I use it?"

To make it work, we need custom webpack config and webpack dev server to serve webpack output.

webpack config

The most essential part of the webpack config is below:

module: {
    rules: [
        test: /\.tsx?$/,
        loader: 'ts-loader',
        options: {
          transpileOnly: true,
          compilerOptions: {
            declarationMap: false
        exclude: /node_modules/
        use: [{
          loader: "@microsoft/loader-cased-file",
          options: {
            name: "[name:lower]_[hash].[ext]"
        test: /.(jpg|png|woff|eot|ttf|svg|gif|dds)((\\?|\\#).+)?$/
        use: [{
          loader: "html-loader"
        test: /\.html$/
        test: /\.css$/,
        use: [
            loader: "@microsoft/loader-load-themed-styles",
            options: {
              async: true
            loader: 'css-loader'
        test: /\.scss$/,
        use: [
            loader: "@microsoft/loader-load-themed-styles",
            options: {
              async: true
            loader: 'css-loader',
            options: {
              modules: true
          }, // translates CSS into CommonJS
          "sass-loader" // compiles Sass to CSS, using Node Sass by default
  plugins: [
    new ForkTsCheckerWebpackPlugin({
      tslint: true
    new webpack.DefinePlugin({
      'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV),
      'process.env.DEBUG': JSON.stringify(true),
      'DEBUG': JSON.stringify(true)

The key things here are loaders:

  • ts-loader transforms TypeScript to Javascript. It doesn't perform type checking (transpileOnly=true), thus works very fast. More on that below in plugins section
  • @microsoft/loader-cased-file - that's the same loader used by SharePoint Framework webpack task, it loads fonts, images
  • html-loader - loads HTML files. It's included into the default SharePoint Framework webpack task, so I added it as well
  • @microsoft/loader-load-themed-styles - that's also OOB loader, it transforms themable css into real css colors, thus very important
  • sass-loader - loads .scss files and transforms to .css
  • css-modules-typescript-loader - this loader transforms imports from *.module.scss files into TypeScript type definitions. 

Also, I use ForkTsCheckerWebpackPlugin. It performs type checks and linting in a separate asynchronous thread, thus it doesn't affect build performance. 

But it's not all. We also need "externals", "output" and "entry" values for our webpack config. Basically, these values are based on your SharePoint Framework solution configuration. And here is the trick - I have a pre-build task, which writes intermediate SPFx webpack config to the disk. Than when custom webpack build starts, it reads that config and sets correct "externals", "output" and "entry" values. 

webpack dev server

 We also need to serve our bundles. Webpack dev server is a perfect solution for that task:

devServer: {
    hot: false,
    contentBase: resolve(__dirname),
    publicPath: host + "/dist/",
    host: "localhost",
    port: 4321,
    disableHostCheck: true,
    historyApiFallback: true,
    open: true,
    openPage: host + "/temp/workbench.html",
    stats: {
      colors: true,
      chunks: false,
      "errors-only": true
    proxy: { // url re-write for resources to be served directly from src folder
      "/lib/**/loc/*.js": {
        target: host,
        pathRewrite: { '^/lib': '/src' },
        secure: false
    headers: {
      'Access-Control-Allow-Origin': '*',
    https: {
      cert: CertificateStore.instance.certificateData,
      key: CertificateStore.instance.keyData

Some key things here:

  • publicPath should be "https://localhost:4321/dist", since that's the location used by OOB "gulp serve"
  • I use proxy to re-map requests for localization resources from lib folder to src
  • for https configuration, I use OOB certificates (@microsoft/gulp-core-build-serve/lib/CertificateStore)

Customized gulpfile.js

In gulpfile.js we need two things - write intermediate webpack config to disk and ensure that workbench is created. It's possible to do that via below tasks:

const argv = build.rig.getYargs().argv;
const useCustomServe = argv['custom-serve'];
const fs = require("fs");
const workbenchApi = require("@microsoft/sp-webpart-workbench/lib/api");

if (useCustomServe) {
  const ensureWorkbenchSubtask = build.subTask('ensure-workbench-task', function (gulp, buildOptions, done) {
    this.log('Creating workbench.html file...');
    try {
    } catch (e) { }


  build.rig.addPostBuildTask(build.task('ensure-workbench', ensureWorkbenchSubtask));

    additionalConfiguration: (generatedConfiguration) => {
      fs.writeFileSync("./temp/_webpack_config.json", JSON.stringify(generatedConfiguration, null, 2));
      return generatedConfiguration;



How can I use it?

To make it work, you need custom webpack.js file and patched gulpfile.js

To make your life easier, I've created a CLI tool, which does all the job - spfx-fast-serve. These are the required steps:

  1. npm install spfx-fast-serve -g
  2. Open a command line in a folder with your SharePoint Framework solution you want to speed up.
  3. Run spfx-fast-serve and follow instructions. In most cases, you shouldn't do anything specific and the cli "just works".
  4. Run npm install
  5. Run npm run serve and enjoy the incredible speed of serve command!

Which SharePoint Framework versions are supported?

SharePoint Online and SharePoint 2019, which basically means SharePoint Framework 1.4.1 and above.

SharePoint 2016 is NOT supported.

Testing performance gain with different projects

I've tested the tool with various projects, including open-source ones. Check out the table below to see the difference in refresh time (the time needed to compile your project when you change a file and start refreshing a page in a browser) between gulp serve and spfx-fast-serve:

  gulp serve spfx-fast-serve
The default "Hello World"
React web part
3-5 sec 0.3-0.5 sec
PnP Modern Search solution 28-34 sec 2-4 sec
SP Starter Kit solution (v1) 40-50 sec 2-3 sec

NOTE: The actual time depends on the environment, hardware, but at least you can see the difference

The performance gain is significant for all types of projects. 

Final thoughts

spfx-fast-serve has below features/advantages over the default gulp serve:

  • works significantly faster
  • all compilations are done in memory with webpack, no additional "copy", "prepare", "typescript", "whatever" tasks.
  • incremental TypeScript compilation when a file is being changed. It means only necessary files are compiled, not everything.
  • asynchronous type checking and linting.
  • supports local and hosted workbench
  • live reloading (for hosted workbench as well)
  • doesn't mess up your default SPFx build. If you have troubles, simply switch back to regular gulp serve
  • adds only ~30 MB to your node_modules folder

Please try it in your SharePoint Framework solution and tell me if it works for you.