As a user with a slow device or internet connection, I want the JS and CSS files that need to be loaded for the web application to be as small as possible to make it more usable.
To check the current file sizes (and contents), a frontend production build can be triggered by running the make build-js command in a terminal, or the equivalent npm run ... action if you can't / don't want to run npm through make - see the build-js target specification in the main or extension Makefile, for example:
cd frontend
env BUILD_ENV=production NODE_ENV=production npm run build
Production *.js and *.css files should then be created in the ../assets/static/build sub-directory (excluded from git):
The easiest way to compare file sizes with the previous stable release is to check the production images available on Docker Hub (or use an existing test instance running an old version):
Please also check what additional files the browser may be loading, such as (potentially unused) fonts like Roboto, which we should not need since our UI defaults to the operating system fonts our users have already installed.
Possible Solutions
Besides making sure that Webpack does not include any unused vue components and css in the production builds, as (roughly) described in the Vuetify docs, there may be further ways to reduce the .js and .css file size, for example:
- Use more aggressive whitespace compression/removal if it doesn't break anything (to be tested).
- Split the
translations.json file into separate files for each language that will be loaded on demand, depending on which UI language is actually being used.
- Build a proof-of-concept with Vite instead of Webpack to see if that makes a difference (it seems to be optimized for tree-shaking, while it's not a core feature of Webpack from what I know): https://dev.to/rafaelogic/optimizing-vuejs-performance-a-guide-to-tree-shaking-with-webpack-and-vite-3if7
While my other tasks don't allow me to help much with researching, testing, and reading the related specs/code, I'm happy to provide inspiration and feedback on possible optimizations (the main focus should be on smaller production files to improve loading performance for users with slow connections, but any additional benefits, e.g. for you as a developer, are welcome too, if the effort can be managed).
Getting Started
Documentation
Related Issues
As a user with a slow device or internet connection, I want the JS and CSS files that need to be loaded for the web application to be as small as possible to make it more usable.
To check the current file sizes (and contents), a frontend production build can be triggered by running the
make build-jscommand in a terminal, or the equivalentnpm run ...action if you can't / don't want to runnpmthroughmake- see thebuild-jstarget specification in the main or extensionMakefile, for example:cd frontend env BUILD_ENV=production NODE_ENV=production npm run buildProduction
*.jsand*.cssfiles should then be created in the../assets/static/buildsub-directory (excluded from git):The easiest way to compare file sizes with the previous stable release is to check the production images available on Docker Hub (or use an existing test instance running an old version):
Please also check what additional files the browser may be loading, such as (potentially unused) fonts like Roboto, which we should not need since our UI defaults to the operating system fonts our users have already installed.
Possible Solutions
Besides making sure that Webpack does not include any unused vue components and css in the production builds, as (roughly) described in the Vuetify docs, there may be further ways to reduce the
.jsand.cssfile size, for example:translations.jsonfile into separate files for each language that will be loaded on demand, depending on which UI language is actually being used.While my other tasks don't allow me to help much with researching, testing, and reading the related specs/code, I'm happy to provide inspiration and feedback on possible optimizations (the main focus should be on smaller production files to improve loading performance for users with slow connections, but any additional benefits, e.g. for you as a developer, are welcome too, if the effort can be managed).
Getting Started
Documentation
Related Issues