As we continue to develop the solstice theme, the JS file continues to grow. Whether this is from feature growth, shims for ES6 -> ES5, or changes in vendor libraries, our main JS bundle file continues to grow. In keeping the site modern, we should investigate ways of shrinking our files, removing old functionality that is no longer used, and potentially splitting vendor JS out from our JS bundle.
One of the gains we can get with compiling this file is splitting out the vendor files from the main JS file that is being transpiled. This has 2 different benefits for our files. The first benefit would be the reduction in size of the file that changes regularly on the server. While a pure split of the vendor JS wouldn't necessarily mean that file sizes change, the size of the file that would regularly change would be smaller as the larger, static vendor libraries would be in a different file that could have long-lived caches.
In the case of this change, a second benefit is that because less code is being passed through Babel + JS shimming and compilation, and less of the core-js lib is being included in the final product as polyfill.
As we continue to develop the solstice theme, the JS file continues to grow. Whether this is from feature growth, shims for ES6 -> ES5, or changes in vendor libraries, our main JS bundle file continues to grow. In keeping the site modern, we should investigate ways of shrinking our files, removing old functionality that is no longer used, and potentially splitting vendor JS out from our JS bundle.
One of the gains we can get with compiling this file is splitting out the vendor files from the main JS file that is being transpiled. This has 2 different benefits for our files. The first benefit would be the reduction in size of the file that changes regularly on the server. While a pure split of the vendor JS wouldn't necessarily mean that file sizes change, the size of the file that would regularly change would be smaller as the larger, static vendor libraries would be in a different file that could have long-lived caches.
Example change to webpack.mix.js:
Before change:
After change:
In the case of this change, a second benefit is that because less code is being passed through Babel + JS shimming and compilation, and less of the core-js lib is being included in the final product as polyfill.