[Angular] Increasing performance

[Aukevanoost]

Hi everyone!

I've started a discussion to keep track of performance improvements. To keep everything transparent and everyone in the loop. While performance has drastically increased, and is not a problem for small micro frontends. It starts to decrease rapidly on bigger Angular projects. The biggest issue was a lack of cache which has been resolved. Now there are some other solutions that should be researched.

How the builder now works:

The builder currently is a wrapper around the Angular builder and exists of 3 steps:

• 1. Build node modules (once because they don't change)
• 2. Build micro frontends (exposed modules)
• 3. Build main.ts with the default Angular builder.

This is highly stable but as you might guess, some work is done multiple times. We've fixed a huge chunk by re-enabling the compilation cache but there is more performance to gain:

Improvement 1, Expand sharing the cache

Currently step 2 and 3 have their own cache. Unfortunately, Angular currently doesn't support providing a cache to its default builder. This prevents us from sharing the compilation cache between step 2 and 3. I've already created a PoC and am waiting for a response from the Angular team to implement this option into the Angular builder [1]

Improvement 2, Improving cache invalidation

Right now, the Angular builder decides which files have changed using "watchPack" [2]. This is cool but we don't have access to this watcher in step 2, therefore we don't know which files to invalidate and just to be sure we invalidate all source files [2]. We can also fix this with improvement 1, but in the case that Angular is not merging our PR, we can see if we can run a second watchpack that buffers file changes and releases them when we run subsequent builds of step 2.

Improvement 3, A slim builder

On the surface this feels like a no-brainer, but is more complex then initially appears: Completely removing step 3. The argument could be that step 3 is not helping us that much since we've already compiled the micro frontends. But unfortunately, step 2 is using the Angular compilation plugin which does most of the work but not all, so this means that we're moving a lot of Angular's work like running the vite server, potential edge cases like internationalization and other stuff to our builder, increasing maintenance and fragility on our side.

What we can do is create an experimental slim builder where we remove step 3 and figure out the extra complexity it brings as we go, but it will not be as robust as the builder we have now. Since the 3rd step is the "batteries included" part of our builder that does all the "extra stuff" after the compilation.

Conclusion

There is still a lot to gain in terms of performance, and it's most definitely on our radar, but all improvement steps might take some time to implement.

[Aukevanoost]

Update

The recently released RC10 implements a custom file-watcher (Improvement 2). Have a look and see if it improves your setup!

https://github.com/native-federation/angular-adapter/releases/tag/v21.1.11

[ladler1]

In comparisson to my test: native-federation/angular-adapter#18 (comment)
i can see a massive improvement:
modified files: 2
building-time: 912.674ms

[ladler1]

Thanks for the explanation.
In addition to my measurement yesterday I did more test today and the result are not as clear. The first rebuild especially for 'root' services (propably used in many places) is slow around 10 - 15 seconds. The next subsequent build is fast as described yesterday. When switching between different 'root' services it stays slow only subsequent rebuilds of the same file are fast. For other files only used at one place rebuild is always fast.

[Aukevanoost]

Interesting! Maybe the recompilation of that particular file retriggers recompilation of dependent files.

[ladler1]

@Aukevanoost is there an update from the angular team if cache can be shared?

[Aukevanoost]

Hi @ladler1! I'm not going to lie, I don't think it would be anytime soon.

I gave a nudge but no response so far. However, for micro frontends we still can experiment with the slim-builder option. Are you still experiencing big delays?

[ladler1]

@Aukevanoost unfortunately yes especially for services used in many different parts of the application the first rebuild takes a longer time. Afterwards subsequent rebuilds are fast. For e.g. components not used in different parts first rebuild is fast as well. This is not the biggest problem since usually work is done in a specific set of files and the subsequent rebuilds are fast.