DEV Community

Cover image for Improve $destroy performance in Vue
Przemyslaw Jan Beigert
Przemyslaw Jan Beigert

Posted on • Updated on

Improve $destroy performance in Vue


Vue in most of the cases is a fast enough framework. However, the time of nodes destruction can be very long. Of course removing elements from DOM is fast operation but Vue needs to remove all watchers from destruct component and that may take up to several seconds.


Component with nested navigation with 12 groups each has ~20 children. After opening all groups, navigation has ~240 items. After user tries to navigate to another view browser freezes for a couple of seconds.

 - Group x12
   - Item x20
Enter fullscreen mode Exit fullscreen mode


Open chromium dev tools, go to the performance section and set CPU: 4x slower after that browser will behave as on an average user computer.

Image description

Then record the destruction of navigation. The result:

Image description

Oh my God almost 7 seconds of destroy and 0.65 s of update (before destroy) o.O

Image description

In the main $destroy there’s many shorter $destroys and all of them have many removeSub calls. Each of removeSub takes 7–15 ms, not much but in total it’s much time of browser freeze.


Component Item.vue is bind to 5 high order vuex getters was rendered around 240 times.

// Item.vue
...mapGetters('namespace', [
Enter fullscreen mode Exit fullscreen mode

Also Item.vue has 8 computed properties and 5 of them use vuex getters. All this operations are not expensive, however create many subscriptions. And these subscriptions have to be cleared.


Moving all computed props and vuex bindings from Item.vue into Group.vue . Group.vue is rendering many Item.vues so we have to map collection of item like this:


Image description

Time of $destroy reduced from ~7s to 0.3s (-96%). Also update before it wad reduced from 0.65s to 0.45 (-30%). Notice that is not a perfect solution: because mapper should move to Navigation.vue add pass Group.vue as prop. However moving calculation of a, b, c, d, e will “only” reduced bindings by 55 (12 * 5 – 5). This performance is not great but not terrible.


In vue loading data from store to component is pretty easy: just ...mapGetters('namespace', ['getter']), but not all components should know about the store. Before React’s hooks was very popular to write container that connect data from Redux by mapStateToProps and mapDispatchToPros with a component. It was a lot of boilerplate and thank goodness we can use now useReducer however it has one advantage: get the developer to think about where to put the connection with store. In my opinion we still must care about it because separation of components into logic and presentation is important not only to keep code clean but also for performance purposes.

Top comments (0)