11 Performance is key

This chapter covers:

Examining how to measure performance when multiple micro frontends exist on one page
How to find regressions and bottlenecks and attribute them to the right team
Typical performance drawbacks that are consequential to the micro frontends architecture
Reducing the amount of required JavaScript by sharing larger vendor libraries across teams
Implementing library sharing without compromising team independence

In 2014 my colleague Jens handed me an article ¹ written by a company that implemented a vertical style architecture. Back then, the term micro frontends didn’t exist. Being a frontend developer who takes pride in delivering fast user experiences, my first gut reaction to this idea was rejection--strong rejection. “Five teams that all roll their own frontend? This sounds like a lot of overhead. The result will surely be inefficient and slow.”

^1.S. Kraus, G. Steinacker, O. Wegner. “Teile und Herrsche: Kleine Systeme für große Architekturen,” OBJEKTspektrum 05/2013 (German), http://mng.bz/xWDg.

11.1 Architecting for performance

11.1.1 Different teams, different metrics

11.1.2 Multi-team performance budgets

11.1.3 Attributing slowdowns

11.1.4 Performance benefits

11.2 Reduce, reuse... vendor libraries

11.2.1 Cost of autonomy

11.2.2 Pick small

11.2.3 One global version

11.2.4 Versioned vendor bundles

11.2.5 Don’t share business code

Summary