Reduce javascript execution time

[steffenkleinle]

Is your feature request related to a problem? Please describe. Google still thinks our mobile performance is too slow, i.e. we have a LCP longer than 2.5 on most sites on mobile. Therefore we should try to speed up our web app more.

Describe the solution you'd like Investigate whether we can reduce javascript execution time: https://developer.chrome.com/docs/lighthouse/performance/bootup-time/?utm_source=lighthouse&utm_medium=lr#how-to-speed-up-javascript-execution

Describe alternatives you've considered None.

Additional context LCP: https://search.google.com/search-console/core-web-vitals/drilldown?resource_id=https%3A%2F%2Fintegreat.app%2F&item_key=CAMQAhgC

Part of #2371 , relates to #2498.

[sarahsporck]

Maybe check out https://web.dev/learn/performance

[sarahsporck]

This adresses bundle size and code compression:

It seams tree shaking does not work for lodash. The bundle still contains unused components. When switching to function imports this is fixed e.g. from import { isEqual } from 'lodash' to import isEqual from 'lodash'. Compare with the bundle analyzer. Sadly, i18next and luxon don't support tree-shaking.

We could also add "sideEffects": false to the translation, shared and build-configs project. This allows webpack to remove unused code from thes projects. https://webpack.js.org/configuration/optimization/#optimizationsideeffects

All over these changes could reduce the bundle size from around 791kb gzipped to 777kb gzipped.

[steffenkleinle]

Hmm, doesn't sound like a lot (< 2%) but I guess it still makes sense to do what we can. No other optimization potential here?

[sarahsporck]

Steps to get the same report:

1. Download Chrome (to have access to lighthouse)
2. Open the Chromedevtools on Integreat
3. Run the dev server in production mode: yarn run webpack-dev-server-ts --env config_name=integreat-test-cms
4. Run lighthouse to checkout the results

[!Warning] Page Speed Insights might use slightly different throttling, resulting in slightly different results

To reproduce the same results: 1.. Create a new hardwareprofile in the network tap using these settings:

• Download: 1638kbit/s
• Upload: 750kbit/s
• Latency: 150ms
  2. Select the newly created hardwareprofile and disable caching in the network tab
  3. Open the performance (leistung) tab and check out what happens on reload.

Things that might have a performance impact:

• [ ] Currently our code is not (properly) really tree-shaken meaning dependencies that we don't use and code that is not used remains inside the web app. However there are some parts that can actually be stripped. To remove that that add sideEffects: false to all of our projects. https://webpack.js.org/guides/tree-shaking/#mark-the-file-as-side-effect-free
• [ ] Lighthouse claims that there is unused javascript code loaded. We could completely strip off lodash (in web production), by implementing the comprehensions ourselves. This especially seems to have an impact on the landing page (as we do some crazy grouping/transforming stuff there). I'll open a proposal for that. Alternatively we could just use module imports as suggested above.
• [ ] When I look at the performance tab I can see that the main bundle is taking around 5s to be fully loaded. As we are using HTTP/2 in production, splitting the bundle into smaller chunks can result in better performance. Check out the AggressiveSplittingPlugin. There are several guides on how to implement this: e.g. splitting react and react-dom into separate chunks or just by setting the chunk max size. I think this block article is a good starting point what can be achived here -> https://medium.com/@addyosmani/progressive-web-apps-with-react-js-part-2-page-load-performance-33b932d97cf2
• [ ] remove logo from splash screen (as the icon needs to be loaded to start rendering)

[ztefanie]

@sarahsporck Thanks for documenting your results here. :+1:

For reducing the main thread work, we have a separate ticket here: https://github.com/digitalfabrik/integreat-app/issues/2498