Performance Webpack Build.js

13

I'm starting with Webpack. It compiles all javascript and css files into a single file Build.js , Bundle.js , whatever ... In the end it generates a fully mined file using the Production Node command, but it nevertheless generates a relatively heavy file. For a large project (which is mine), you can reach 10mb easy. Loading 10mb at once is too bad. How does Webpack handle this? What is advantageous to use it if it brings me a minified but huge file? Does it select 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!

    
asked by anonymous 20.10.2017 / 21:03

1 answer

1

In fact Webpack offers alternatives, Code Splitting using plugins, and on demand loading using import of library SystemJS , 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 on this: in the Vue.js own documentation , and this article . There are several articles on the internet about this.

More options:

  • 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 can already cache the same third-party libraries that you use, mainly bootstrap, jQuery, angular, react ...

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

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

  • Compress your Javascript files with a gzip compression directive on the web server (apache, nginx, IIS) or do it via WebPack even with a plugin type that: link

  • Use a cache policy that matches your use case. Third-party libraries attached to a different file with longer cache expiration time. Most used libraries in another file with less time.

  • 17.01.2018 / 20:46