Optimization for google Lighthouse review

[tbouliere-datasolution]

Is your feature request related to a problem? If yes, please describe it.

The application currently performs very poorly in the google lighthouse test in mobile mode.
It's true that it's very difficult to optimize angular applications for this test. Even more so with a generic application.

However, there are architectural choices that prevent us from making improvements in our projects:

• The "SharedModule" is huge, taking up 1/4 of the total size of the application.
• Impacting dependencies such as CDK or formly are loaded by default with the ShareModule
• Shell Module loads (even lazily) the SharedModule
• The CMS module automatically loads all components. If an impacting component (such as a product list with slider) is declared, it will be loaded on all pages, even if it is not used.
• Extensions for numerous dependencies. For example, order-template must be loaded on the homepage simply to present a button redirecting users to the order-template functionality.

Describe the desired solution.

• SharedModule should be splited
• Ideally, ShellModule should be self-sufficient.
• CMS component should be loaded lazily
• Extensions should export a light version of shared component for the homepage
• Page hierarchy should be splited as chunk per page with webpack
• Lazy load vendor dependancies should not by contains in vendors.js or common.js

Describe alternatives you've considered.

Splitting ShareModule and lazy loading CMS doesn't take so much time.
The real difficulty lies in the extensions loaded on the home page.

A first cut has been made here as a poc (~ 4/5 hour of work): https://github.com/tbouliere-datasolution/intershop-pwa/tree/refactor/split-shared-module

Provide additional context.

Initial webpack bundle

Expected splitted webpack bundle

AB#94658

[andreassteinmann]

Hi @tbouliere-datasolution, we looked at the changes and figured out several improvements in the Lighthouse test for mobile (Unused JS, FCP, TBT). Thank you for the work! We are not going to take the POC as it is but we are going to look at certain re-arrangements and improvements.

[tbouliere-datasolution]

Hello Andreas.

I understand that this type of modification can be hard to integrate.
That's why we've abandoned the idea of achieving a correct ligthouse score for the time being. It would take us too far away from the initial trunk.

I can, however, add the following comments:

• There aren't enough standalone components in the application. This tends to produce a monolytic application. Shared components and CMS components in particular should be standalone.

• Css is only contained in scss files. There is very little component-specific css. This makes refactoring very complicated and css purging rather inefficient.
  I think this is the result of a one-for-one reworking of the work done several years ago on "inspired". It's not really state-of-the-art anymore.

• The ui librairies, which should be in "demo" mode, are intrasectively linked to the application :

  • Bootstrap 4 is forced (NgbModal is used throughout the code). This version dates from 2018. It's over 6 years old now.
  • Font Awesome is too intrusive. Picto management via svg assets would be much more efficient.
  • Swiper is also an old version.

And once again, all these libraries are loaded into the core (some even via app.module.ts).