Performance Webpack Build.js

Question

I’m starting with Webpack. It compiles all javascript and css files into a single file Build.js, Bundle.js, whatever it is... In the end it generates a fully minified file using the Node command Production, but even so it generates a relatively heavy file. For a large project ( Which is mine ), it can reach 10mb easy. Charging 10mb at once is very bad.
How does Webpack control this? What is the advantage of using it if it brings me a minified but huge file? It selects the scripts that will be loaded from import?

var path = require('path')
var webpack = require('webpack')

module.exports = {
  entry: './src/main.js',
  output: {
    path: path.resolve(__dirname, './dist'),
    publicPath: '/dist/',
    filename: 'build.js'
  },
  module: {
    rules: [
      {
        test: /\.vue$/,
        loader: 'vue-loader',
        options: {
          loaders: {
            'scss': 'vue-style-loader!css-loader!sass-loader',
            'sass': 'vue-style-loader!css-loader!sass-loader?indentedSyntax'
          }
        }
      },
      {
      test: /\.css$/,  
      include: /node_modules/,  
      loaders: ['style-loader', 'css-loader'],
      },
      {
        test: /\.js$/,
        loader: 'babel-loader',
        exclude: /node_modules/
      },
      {
        test: /\.(png|jpg|gif|svg)$/,
        loader: 'file-loader',
        options: {
          name: '[name].[ext]?[hash]'
        }
      },
      {
        test: /\.s(a|c)ss$/,
        loader: 'style-loader!css-loader!sass-loader'
      },
      { test: /\.(png|woff|woff2|eot|ttf|svg)$/,
        loader: 'url-loader?limit=100000'
      }
    ]
  },
  resolve: {
    extensions: ['.json', '.min.css', '.min.js', , '.scss' , '.css', '.js' ],
    alias: {
      'vue$': 'vue/dist/vue.esm.js'
    }
  },
  devServer: {
    historyApiFallback: true,
    noInfo: true
  },
  performance: {
    hints: false
  },
  devtool: '#eval-source-map',
  plugins:[
    new webpack.ProvidePlugin({
       $: "jquery",
       jQuery: "jquery"
    })
  ]
}

if (process.env.NODE_ENV === 'production') {
  module.exports.devtool = '#source-map'
  // http://vue-loader.vuejs.org/en/workflow/production.html
  module.exports.plugins = (module.exports.plugins || []).concat([
    new webpack.DefinePlugin({
      'process.env': {
        NODE_ENV: '"production"'
      }
    }),
    new webpack.optimize.UglifyJsPlugin({
      sourceMap: true,
      compress: {
        warnings: false
      }
    }),
    new webpack.LoaderOptionsPlugin({
      minimize: true
    })
  ])
}

Thank you!

Answer 1

In fact Webpack offers alternatives, the Code Splitting using plugins, and demand loading using import library Systemjs, to which returns a Promise.

But I see from your code that you’re using Vue.js. You can Vue.js makes loading on demand even easier, See more about this: in own documentation of Vue.js, and in that article. There are several articles on the internet about this.

More options:

1. If the application is on the internet or you are 100% sure that the user will have internet connection. Use CDN wherever possible.

   a) The user may already cache the same third party libraries that you use, mainly bootstrap, jQuery, angular, React browser...

   b) probably the user will download the contents of a library on the CDN server than on the hosting server and with the minimum latency, reduced response times to download each file. CDN servers are robust to ensure bandwidth, low latency and availability.

   c) Here I recommend CDN to third party libraries almost always, because of item (b). It is up to the developer to make benchmarks and simulate use cases, because there may not be much difference in the case of a site hosted on good servers within walking distance of most users. Spoiler: Even with multiple separate HTTP requests, very low latency and bandwidth give CDN an advantage.

2. Compress your Javascript files via a gzip compression on the web server (apache, Nginx, IIS) or do it for Webpack even with a plugin like this: https://github.com/webpack-contrib/compression-webpack-plugin

3. Use a cache policy adjusted with your use case. Third party libraries joined in a different file with longer cache expiration time. Most commonly used libraries in another file with less time.

4. Rethink the need for each library if it’s not worth implementing its own function or extracting it from the library instead of downloading the entire library altogether.