Overview
An important aspect of Turnilo is its web performance. Upon every change to the codebase we should track how performance changes.
JS bundle size
Bundle size can easily inflate, particularly when an app has plenty of dependencies, just like Turnilo. With every change we should keep track of the bundle size, especially when we add a new dependency.
Before adding a new dependency, please consider a smaller alternative in terms of bundle size. Tools like Bundlephobia will help to recon cost of library and find alternatives.
Size-limit
Size-limit GitHub Action will help to stay with assets size in the budget. On each pull request this action will post a comment with current bundle size and its delta.
Each time budgets are exceeded CI will fail.
You can adjust budgets in size-limit section of package.json.
Bundle analysis by Statoscope
On every build a report about Webpack’s bundle is made by Statoscope. You can find these under build/report-*.html. Among others, it offers detailed tree-map of the client bundle. For example, it helps to figure out which dependencies are the heaviest.
Transpiling dependencies
Usually pre-transpiled dependencies are bad for bundle size, since they can include utilities like Babel’s helpers or TS’ tslib. It’s a problem because stuff like this is unnecessary for modern browsers and hence it should not be included in the bundle. If possible import dependencies from an untraspiled source. Any dependency that has to be transpiled should be listed within Webpack configuration.
Manual (dead) code elimination
Sometimes we can’t rely on libraries’ authors or on Webpack in terms of tree-shaking aka dead-code-elimination, and we have to take matters into our own hands.
Webpack by IgnorePlugin allows to drop selected modules and this how Moment’s locales are not included in the final bundle.
Lighthouse
On each pull request Lighthouse-CI action will post link to lighthouse report. It can help to measure current performance and notice potential performance issues.