Build assets generated by webpack in production mode
Fix #956508 - gitlab: webpack should build assets in production mode
Fix #927297 - gitlab: Update browser cache after upgrade
Issue description is copied from #956508 - gitlab: webpack should build assets in production mode
Current assets building through webpack is done by the following call
set in /usr/lib/gitlab/scripts/rake-tasks.sh
:
runuser -u ${gitlab_user} -- sh -c 'NODE_OPTIONS="--max-old-space-size=2048" webpack --max-old-space-size=16384 --config config/webpack.config.js'
The issue with this command is that it does not build assets optimized for use in production, making parts of the GitLab interface heavy on bandwidth usage, and slow to use on networks with limited bandwidth.
The suggested replacement should fix this issue by explicitely building assets optimized for production use:
runuser -u ${gitlab_user} -- sh -c 'NODE_ENV="production" NODE_OPTIONS="--max-old-space-size=4096" webpack --config config/webpack.config.js'
The modifications are:
- Add
NODE_ENV="production"
, this is what triggers the correct assets build mode - Replace
NODE_OPTIONS="--max-old-space-size=2048"
byNODE_OPTIONS="--max-old-space-size=4096"
, as it seems build in production mode uses more memory (an alternative would be to make the value configurable in/etc/gitlab/gitlab-debian.conf
)
Thanks to these tweaks, served assets are much smaller and the overall
UI is much more responsive. As an example it takes main.chunk.js
from
~25 MB to less than 3MB, before application of gzip compression by
nginx.
For a comparison, both of these GitLab instances use the same GitLab version based on buster-fasttrack repositories:
- https://gitlab.debian.net/explore - not using the production assets
- https://forge.dotslashplay.it/explore - using the production assets
The difference in responsiveness is easily noticeable, and the difference is bandwidth usage is important.