{"id":139,"date":"2017-05-09T23:15:21","date_gmt":"2017-05-09T20:15:21","guid":{"rendered":"https:\/\/iamakulov.com\/notes2\/?p=139"},"modified":"2018-01-21T11:51:47","modified_gmt":"2018-01-21T08:51:47","slug":"webpack-front-end-size-caching","status":"publish","type":"post","link":"https:\/\/iamakulov.com\/notes\/webpack-front-end-size-caching\/","title":{"rendered":"webpack for real tasks: decreasing front-end size and improving caching"},"content":{"rendered":"
\nThis is the second part of a three-part introduction into webpack:<\/p>\n
    \n
  1. Bundling front-end and adding compilation<\/a>\n
  2. Decreasing front-end size and improving caching (you are here!)<\/em><\/li>\n
  3. Speeding up build and improving the development workflow<\/li>\n<\/ol>\n

    Want to stay tuned for the future posts? Subscribe<\/a><\/p>\n<\/div>\n

    Last updated on 21 Jan 2018: replaced the recommended plugin in the Moment.js part<\/a>.<\/em><\/p>\n

    Task<\/span> Decrease front-end size#<\/a><\/h1>\n

    Given:<\/em> you have a front-end application. You want to decrease its size to make it load faster.<\/p>\n

    Let\u2019s see how webpack can help with this.<\/p>\n

    Minification#<\/a><\/h2>\n

    Minification is when you compress your code by removing extra spaces, shortening variable names, etc. Like this:<\/p>\n

    \"\"<\/p>\n

    Webpack has two approaches to minify the code: the UglifyJS plugin<\/em> and loaders options<\/em>. They should be used simultaneously.<\/p>\n

    The UglifyJS plugin works on the level of the bundle and compresses it after compilation. As you might\u2019ve guessed, it used UglifyJS<\/a> under the hood. This is how it works: <\/p>\n

    \n
    You write code like this<\/div>\n
    \n
    \/\/ comments.js\r\nimport '.\/comments.css';\r\nexport function render(data, target) {\r\n    console.log('Rendered!');\r\n}\r\n<\/code><\/pre>\n<\/div>\n<\/div>\n
    \u2193<\/p>\n
    \n
    Webpack compiles it into approximately the following<\/div>\n
    \n
    \/\/ bundle.js (part of)\r\n"use strict";\r\nObject.defineProperty(__webpack_exports__, "__esModule", { value: true });\r\nvar __WEBPACK_IMPORTED_MODULE_0__comments_css__ =\r\n  __webpack_require__(4);\r\nvar __WEBPACK_IMPORTED_MODULE_0__comments_css___default =\r\n  __webpack_require__.n(__WEBPACK_IMPORTED_MODULE_0__comments_css__);\r\n__webpack_exports__["render"] = render;\r\n\r\nfunction render(data, target) {\r\n    console.log('Rendered!');\r\n}\r\n<\/code><\/pre>\n<\/div>\n<\/div>\n
    \u2193<\/p>\n
    \n
    The UglifyJS plugin minifies it into approximately the following<\/div>\n
    \n
    \/\/ bundle.js (part of)\r\n"use strict";function r(e,t){console.log("Rendered!")}\r\nObject.defineProperty(t,"__esModule",{value:!0});\r\nvar o=n(4);n.n(o);t.render=r\r\n<\/code><\/pre>\n<\/div>\n<\/div>\n
    To enable the plugin, add it to the plugins<\/code> section of the config:<\/p>\n
    \/\/ webpack.config.js\r\nconst webpack = require('webpack');\r\n\r\nmodule.exports = {\r\n  plugins: [\r\n    new webpack.optimize.UglifyJsPlugin()\r\n  ]\r\n};\r\n<\/code><\/pre>\n
    The second approach is loaders options. It allows compressing things that UglifyJS can\u2019t minify. Its point is that some code (e.g. CSS that you import) is compiled as a string which UglifyJS can\u2019t handle:<\/p>\n
    \/* comments.css *\/\r\n.comment {\r\n    color: black;\r\n}\r\n<\/code><\/pre>\n
    \u2193<\/p>\n
    \/\/ bundle.js (part of)\r\nexports = module.exports = __webpack_require__(1)();\r\nexports.push([module.i, ".comment {\\r\\n    color: black;\\r\\n}", ""]);\r\n<\/code><\/pre>\n
    To minify it, you should configure the loader. Here\u2019s how you do it with css-loader<\/em><\/a>:<\/p>\n
    \/\/ webpack.config.js\r\nmodule.exports = {\r\n  module: {\r\n    rules: [\r\n      {\r\n        test: \/\\.css$\/,\r\n        use: [\r\n          'style-loader',\r\n          { loader: 'css-loader', options: { minimize: true } }\r\n        ]\r\n      }\r\n    ]\r\n  }\r\n};\r\n<\/code><\/pre>\n
    \n
    Pitfall: ES2015 code#<\/a><\/h2>\n
    UglifyJS 2 (which is used in webpack) can\u2019t compile ES2015+ code. This means that if your code uses classes, arrow functions or other new language features, and you don\u2019t compile it to ES5, UglifyJS won\u2019t handle it. In this case, you can use Babili, a Babel-based minifier. See babili-webpack-plugin<\/a>\n<\/div>\n
    NODE_ENV=production#<\/a><\/h2>\n
    Another way to decrease the front-end size is to set NODE_ENV<\/code> environmental variable to the value \u201cproduction\u201d.<\/p>\n
    NODE_ENV<\/code> is an environmental variable that is commonly used in libraries to detect in which mode the library works \u2013 in development mode or on a production server. The library can behave differently based on this variable. For example, React does additional checks and prints warnings when it\u2019s built for development:<\/p>\n
    \/\/ \u2026\r\n\r\nif (process.env.NODE_ENV !== 'production') {\r\n  validateTypeDef(Constructor, propTypes, 'prop');\r\n}\r\n\r\n\/\/ \u2026\r\n<\/code><\/pre>\n
    When you\u2019re building your app for production, it\u2019s better to also tell that your libraries. For Node.js libraries, it\u2019s done by configuring the environment and setting the NODE_ENV<\/code> variable to \u201cproduction\u201d. For front-end libraries, it\u2019s done by replacing process.env.NODE_ENV<\/code> with a specific value:<\/p>\n
    \/\/ webpack.config.js\r\nconst webpack = require('webpack');\r\n\r\nmodule.exports = {\r\n  plugins: {\r\n    new webpack.DefinePlugin({\r\n      'process.env.NODE_ENV': '"production"'\r\n    })\r\n  }\r\n};\r\n<\/code><\/pre>\n
    DefinePlugin<\/a> takes an object with keys referring to variables to be replaced and values referring to the values that should be substituted. With this configuration, it\u2019ll replace all process.env.NODE_ENV<\/code> instances with \"production\"<\/code>, which will make UglifyJS understand that the comparison expression is always false and remove it:<\/p>\n
    \"\"<\/p>\n
    ECMAScript imports#<\/a><\/h2>\n
    The next way to decrease the front-end size is to use ECMAScript imports and exports.<\/p>\n
    When you use ECMAScript imports and exports, webpack becomes able to do tree-shaking. Tree-shaking is when a bundler traverses your whole dependency tree, checks what of them are used, and keeps only the used ones. So, if you use ECMAScript module syntax, webpack can eliminate the unused code:<\/p>\n
    \n
    You write two files where only one export is used<\/div>\n
    \n
    \/\/ comments.js\r\nexport const commentRestEndpoint = '\/rest\/comments';\r\nexport const render = () => { return 'Rendered!'; };\r\n\r\n\/\/ index.js\r\nimport { render } from '.\/comments.js';\r\nrender();\r\n<\/code><\/pre>\n<\/div>\n<\/div>\n
    \u2193<\/p>\n
    \n
    Webpack realizes that commentRestEndpoint<\/code> is not used and doesn\u2019t generate a separate export point in the bundle<\/div>\n
    \n
    \/\/ bundle.js (part of)\r\n(function(module, __webpack_exports__, __webpack_require__) {\r\n  "use strict";\r\n  \/* unused harmony export commentRestEndpoint *\/\r\n  \/* harmony export *\/__webpack_exports__["b"] = render;\r\n\r\n  var commentRestEndpoint = '\/rest\/comments';\r\n  var render = function () { return 'Rendered!'; }\r\n})\r\n<\/code><\/pre>\n<\/div>\n<\/div>\n
    \u2193<\/p>\n
    \n
    UglifyJS removes the unused variable<\/div>\n
    \n
    \/\/ bundle.js (part of)\r\n(function(n,e){"use strict";e.b=r;var r=function(){return"Rendered!"}})\r\n<\/code><\/pre>\n<\/div>\n<\/div>\n
    This works even with libraries; the library should also be written with ECMAScript modules.<\/p>\n
    \n
    Pitfall: tree-shaking doesn\u2019t work without UglifyJS#<\/a><\/h2>\n
    The less-known fact is that the unused code is removed not by webpack, but by UglifyJS. Webpack just removes export statements for the exports that aren\u2019t used, which makes them possible to be removed by a minifier. Therefore, if you compile your bundle without the minifier, the bundle won\u2019t get smaller.<\/p>\n
    See how to enable UglifyJS in the \u201cMinification\u201d section<\/a>.<\/p>\n
    Pitfall: don\u2019t transpile ECMAScript imports to the CommonJS format#<\/a><\/h2>\n
    If you use Babel with babel-preset-env<\/a> or babel-preset-es2015<\/a>, check the settings of these presets. By default, they transpile ECMAScript\u2019s import<\/code> and export<\/code> to CommonJS\u2019 require<\/code> and module.exports<\/code>. Pass the { modules: false }<\/code> option to disable this:<\/p>\n
    \/\/ webpack.config.js\r\nmodule.exports = {\r\n  module: {\r\n    rules: [\r\n      {\r\n        test: \/\\.js$\/,\r\n        use: [{'babel-loader', options: {\r\n          presets: [['es2015', { modules: false }]]\r\n        }]\r\n      }\r\n    ]\r\n  }\r\n};\r\n<\/code><\/pre>\n
    Pitfall: complex cases aren\u2019t optimized#<\/a><\/h2>\n
    In some complex cases \u2013 e. g. when you re-export something (export * from 'file.js'<\/code>), or when you compile classes with the TypeScript compiler \u2013 webpack can\u2019t optimize your bundle. The bad things about this are that the cases when this happens aren\u2019t obvious, and it\u2019s unclear when this will be fixed. Here\u2019s the corresponding GitHub issue: webpack\/webpack#2867<\/a><\/p>\n
    Webpack team is working on a solution for re-exports though<\/a>.<\/p>\n<\/div>\n
    Moment.js#<\/a><\/h2>\n
    \n
    Tested with moment.js 2.18.1<\/div>\n
    \n
    Moment.js<\/a> is a library for working with dates. By default, when you include it in your app, it takes 217 kB of minified code. That\u2019s huge \u2013 the average size of JavaScript on a page was 417 kB in April 2017<\/a>. The good part, however, is that it can be easily reduced.<\/p>\n<\/div>\n<\/div>\n
    165 kB of the size of moment.js is localization files. They\u2019re included even if you don\u2019t use them. This happens because moment.js chooses the localization files dynamically, during runtime:<\/p>\n
    \"\"<\/a><\/p>\n
    Webpack doesn\u2019t know which files you\u2019ll need, so it includes all<\/em> files from the locale<\/em> directory.<\/p>\n
    To deal with it, specify the exact files with MomentLocalesPlugin<\/a><\/em>:<\/p>\n
    \/\/ webpack.config.js\r\nconst MomentLocalesPlugin = require('moment-locales-webpack-plugin');\r\n\r\nmodule.exports = {\r\n  plugins: [\r\n    \/\/ Or: To strip all locales except \u201cen\u201d, \u201ces-us\u201d and \u201cru\u201d\r\n    \/\/ (\u201cen\u201d is built into Moment and can\u2019t be removed)\r\n    new MomentLocalesPlugin({\r\n      localesToKeep: ['es-us', 'ru'],\r\n    }),\r\n  ],\r\n};\r\n<\/code><\/pre>\n
    Lodash#<\/a><\/h2>\n
    Lodash<\/a> is a collection of JavaScript utilities.<\/p>\n
    \n
    Tested with Lodash 4.17.4<\/div>\n
    \n
    When you include Lodash, your bundle grows by 72 KB of minified code. That\u2019s the size of all the 316 Lodash methods. If you use only, like, 20 of them, then approximately 65 KB of the code do just nothing except slowing down the page loading.<\/p>\n<\/div>\n<\/div>\n
    Thankfully, Lodash lets you include only the methods you need. The most basic way to do this is to import methods from the files they\u2019re implemented in:<\/p>\n
    \n
    72 KB \u2192 8.27 KB<\/div>\n
    \n
    - import _ from 'lodash';\r\n- _.get();\r\n+ import get from 'lodash\/get';\r\n+ get();\r\n<\/code><\/pre>\n<\/div>\n<\/div>\n
    This approach might work if you\u2019re starting a project from scratch, but it doesn\u2019t work for existing projects. What you\u2019re gonna do, rewrite all imports? That\u2019s too much work. That\u2019s why I prefer using babel-plugin-lodash<\/code> and sometimes lodash-webpack-plugin<\/code>.<\/p>\n
    babel-plugin-lodash<\/code><\/a> is a plugin for Babel that replaces generic imports with concrete ones during compilation. That is, it does exactly the same thing as depicted in the snippet above:<\/p>\n
    \n
    72 KB \u2192 8.27 KB<\/div>\n
    \n
    \/\/ Before babel-plugin-lodash\r\nimport _ from 'lodash';\r\n_.get({ a: { b: 5 } }, 'a.b');\r\n\r\n\u2193\r\n\r\n\/\/ After babel-plugin-lodash\r\nimport _get from 'lodash\/get';\r\n_get({ a: { b: 5 } }, 'a.b');\r\n<\/code><\/pre>\n<\/div>\n<\/div>\n
    lodash-webpack-plugin<\/code><\/a> is a plugin for webpack that modifies Lodash behavior by removing some code and thus cutting the bundle size. For example, _.get<\/code> by default supports deep paths. If you don\u2019t need this, you can enable lodash-webpack-plugin<\/code>, which will remove this support:<\/p>\n
    \n
    72 KB \u2192 772 B<\/div>\n
    \n
    \/\/ Before babel-plugin-lodash + lodash-webpack-plugin\r\nimport _ from 'lodash';\r\n_.get({ a: { b: 5 } }, 'a.b');\r\n\/\/ \u2192\u00a0returns 5\r\n\r\n\u2193\r\n\r\n\/\/ After babel-plugin-lodash + lodash-webpack-plugin\r\nimport _get from 'lodash\/get';\r\n_get({ a: { b: 5 } }, 'a.b');\r\n\/\/ \u2192\u00a0returns undefined\r\n<\/code><\/pre>\n<\/div>\n<\/div>\n
    Keep in mind, however, that you can\u2019t just enable the plugin and leave it as-is. This plugin changes the Lodash functionality, so your existing code could break. Take a look at the list of features<\/a> it removes by default.<\/p>\n
    \n
    Pitfall: duplicated Lodash#<\/a><\/h2>\n
    There\u2019re two common versions of Lodash: the lodash<\/code><\/a> package and the lodash-es<\/code><\/a> package (which is Lodash with ES exports). If you use the former package, and one of your dependencies uses the latter, you will find yourself having two Lodashes in a single bundle. To avoid this, alias lodash<\/code> to lodash-es<\/code><\/a> (or vice versa).<\/p>\n
    An example of a package that uses lodash-es<\/code> is Redux.<\/p>\n
    Thanks to Valentin Semirulnik<\/a> for this tip.\n<\/div>\n
    externals#<\/a><\/h2>\n
    Sometimes you have a large project where some code is compiled with webpack and some code is not. Like a page with crosswords, where the crosswords module is built with webpack, and the site around it is not:<\/p>\n
    \"\"<\/p>\n
    If both pieces of code have common dependencies, you can share the dependencies between them. This is done with the webpack\u2019s externals<\/code> option which lets you alias module imports to something different.<\/p>\n
    The common usage is when you have an instance of a library in the global object (like window<\/code>), and you want to alias the library imports to this instance. In this case, you pass an object mapping the module names to the variable names:<\/p>\n
    \/\/ webpack.config.js\r\nmodule.exports = {\r\n  externals: {\r\n    'react': 'React',\r\n    'react-dom': 'ReactDOM',\r\n  }\r\n};\r\n<\/code><\/pre>\n
    \n
    Example of the bundle generated with externals<\/code><\/a><\/div>\n
    \n
    Webpack will replace all module references with variable references.<\/p>\n<\/div>\n<\/div>\n
    A less known approach is when the old code doesn\u2019t put the libraries into the global object but loads them with an AMD-compatible loader. In this case, you can compile your webpack as an AMD bundle and alias modules to paths to the libraries:<\/p>\n
    \/\/ webpack.config.js\r\nmodule.exports = {\r\n  output: { libraryTarget: 'amd' },\r\n\r\n  externals: {\r\n    'react': { amd: '\/libraries\/react.min.js' },\r\n    'react-dom': { amd: '\/libraries\/react-dom.min.js' },\r\n  }\r\n};\r\n<\/code><\/pre>\n
    Webpack will wrap your bundle into define()<\/code> and make it depend on the libraries from externals<\/code>:<\/p>\n
    \/\/ bundle.js\r\ndefine(["\/libraries\/react.min.js", "\/libraries\/react-dom.min.js"], function () { \u2026 });\r\n<\/code><\/pre>\n
    Then, the loader will load your libraries along with the bundle. The good thing here is that the libraries will be cached in the browser or in the loader cache \u2013 so they won\u2019t be loaded twice.<\/p>\n
    \u03a3: Decrease front-end size#<\/a><\/h2>\n