Performance penalty of global component registration

I am well aware of the philosophical downsides of global components and we’ve been registering them locally as a rule on our team, no exceptions. But since we use a pattern library, the most common ones (e.g. buttons) are manually imported and registered all over our app.

I was thinking of globally registering the most popular ones (imported > 10 times) to cut down on the amount of boilerplate. Let’s assume we’re aware of the negative implications on readability (harder to understand where things come from etc.) this has. Are there any technical downsides (e.g. serious performance penalties) we should look out for?

1 Like

There’s no performance drawback to globally registered components, except that you can’t lazy-load them anymore - but that wouldn’t make sense for the type of basic components that the app uses everywhere, anyway. Those do belong into the entry chunk.


You didn’t phrase the question in terms of garnering opinion, but some additional thoughts:

You should absolutely be globally-registering these kinds of components.

FYI, you can see all globally-imported components at:


I aim to design core parts of every application as a library with the expectation that functionality should be decoupled and plugin-like. Any component used more than once becomes a candidate for first-class citizenship.

I often use the a structure like the following:

+- src
  +- app
  | +- router
  | +- store
  | +- views
  +- core
    +- services
    +- ui
    +- utils

Webpack aliases also make it much easier to globally reference folders:

// src/core/ui/...
import SomeComponent from 'ui/SomeComponent`

More tricks here to simplify importing:

And I hear good things about Storybook if you are worried about it being “harder to understand where things come from” which can surface and test common components:


Thanks Dave, that’s a lot of useful stuff! We’re already using webpack aliases and storybook, this will not be an issue with anyone editing front end on a daily basis. When I wrote harder to understand where things come from, I was thinking of our back end devs who only occasionally edit Vue components. For them, a locally imported and registered component is something they can directly follow in case they need to edit it while a globally registered one will just “magically” work in the template without any other references. But we can cover that with a bit of documentation.

Anyway, it’s good to hear we’re going in the right direction :+1:

1 Like