22 Vue optimization tips (project practical)

The demonstration code is written in Vue3 + ts + Vite, but optimization techniques applicable to Vue2 will also be listed. If an optimization is only applicable to Vue3 or Vue2, I will mark it in the title.

Code Optimization

Using key in v-for

When using v-for to update a rendered element list, the default in-place reuse strategy is used; when the list data is modified, it will determine whether a value has been modified based on the key value. If modified, it will re-render this item, otherwise reuse the previous element;

Notes on using keys:

• Do not use key values ​​that may be repeated or may change (the console will also give a reminder)
• Do not use the array index as the key value, because if you insert an element into the array, the index of the elements after it will change.
• If there is no unique key value available in the array, consider adding a key field with the value Symbol() to ensure uniqueness.

Using key in v-if/v-else-if/v-else

Maybe many people will ignore this point.

Reason: By default, Vue updates the DOM as efficiently as possible. This means that when switching between elements of the same type, it patches the existing element instead of removing the old one and adding a new one in the same place. If elements that are not identical are identified as identical, unexpected side effects may occur.

If there is only one v-if and no v-else or v-if-else, there is no need to add a key.

Compared with the key of v-for, the key in v-if/v-else-if/v-else is relatively simple. We can directly write a fixed string or array.

  <transition>
    <button 
      v-if="isEditing"
      v-on:click="isEditing = false"
    >
      Save
    </button>
    <button 
      v-else 
      v-on:click="isEditing = true"
    >
      Edit
    </button>
  </transition>

.v-enter-active, .v-leave-active {
  transition: all 1s;
}
.v-enter, .v-leave-to {
  opacity: 0;
  transform: translateY(30px);
}
.v-leave-active {
  position: absolute;
}

For example, in the code above, you will find that although the transition effect is added to the button, the transition cannot be triggered if the key switch is not added.
Don’t use v-for and v-if together (Vue2)

This optimization technique is limited to Vue2. The priority of v-for and v-if has been adjusted in Vue3.

Everyone knows this

Never use v-if and v-for on the same element. Refer to Vue 2.x Style Guide

The reason is that v-for has a higher priority than v-if, so when they are used on the same tag, each rendering will be looped first and then the conditional judgment will be performed.

Note: v-if has a higher priority than v-for in Vue3, so when v-for and v-if are used together, the effect is similar to the effect of raising v-if in Vue2.

For example, the following code is not recommended in Vue2, and Vue will also give a corresponding warning

<ul>
  <li v-for="user in users" v-if="user.active">
    {{ user.name }}
  </li>
</ul>

We should try to move v-if to the upper level or use calculated properties to process data

<ul v-if="active">
  <li v-for="user in users">
    {{ user.name }}
  </li>
</ul>

If you don't want the loop to have an unnecessary parent container, you can use template as its parent element. Template will not be rendered as a DOM node by the browser. If I want to determine the content of each item in the traversal object to select the rendered data, I can use computed to filter the traversal object.

// js
let usersActive = computed(()=>users.filter(user => user.active))

// template
<ul>
    <li v-for="user in usersActive">
      {{ user.name }}
    </li>
</ul>

Reasonable choice of v-if and v-show

Everyone is very familiar with the difference between v-if and v-show; v-if controls the display and hiding of elements by directly manipulating the deletion and addition of DOM; v-show controls the display and hiding of elements by controlling the display CSS of DOM. Since the performance of adding/deleting operations on DOM is much lower than that of manipulating CSS properties of DOM, when elements need to be displayed/hidden frequently, we use v-show to improve performance.
When an element does not need to be displayed/hidden frequently, we can remove the DOM through v-if to save the resources needed by the browser to render this part of the DOM.

Using simple computed properties

Complex computed properties should be split into as many simpler properties as possible.

When each computed property consists of a very simple expression with few dependencies, it is easier to write tests to ensure that it works correctly.

Easier to read Simplified computed properties require you to give each value a descriptive name, even if it is not reusable. This makes it easier for other developers (and future you) to focus on the code they care about and figure out what's going on.

Better "embracing change"
Any value that can be named may be used in a view. For example, we might want to display a message telling the user how much money they have saved. We might also want to calculate taxes, but perhaps display them separately rather than as part of the total price.
Small, focused computed properties reduce the assumptions that need to be made when using information, so less refactoring is required when requirements change.

Refer to Vue2 Style Guide

Computed is familiar to everyone. It will be recalculated when the reactive data it depends on in its expression changes. If we write a more complex expression in a calculated property, the number of dependent reactive data will also increase arbitrarily. When any of the dependencies changes, the entire expression needs to be recalculated.

let price = computed(()=>{
  let basePrice = manufactureCost / (1 - profitMargin)
  return (
      basePrice -
      basePrice * (discountPercent || 0)
  )
})

When any of manufactureCost, profitMargin, or discountPercent changes, the entire price will be recalculated.
But if we change it to the following

let basePrice = computed(() => manufactureCost / (1 - profitMargin))
let discount = computed(() => basePrice * (discountPercent || 0))
let finalPrice = computed(() => basePrice - discount)

If discountPercent changes, only discount and finalPrice will be recalculated. Due to the caching feature of computed, basePrice will not be recalculated.

Functional components (Vue2)

Note that this is only an optimization in Vue2, in 3.x the performance difference between stateful and functional components has been greatly reduced and is negligible in most use cases. Therefore, the migration path for developers using functional on SFCs is to remove that attribute and rename all references of props to $props and attrs to $attrs.

Before optimization

<template> 
    <div class="cell"> 
        <div v-if="value" class="on"></div> 
        <section v-else class="off"></section> 
    </div> 
</template>

<script> 
export default { 
    props: ['value'], 
} 
</script>

After optimization

<template functional> 
    <div class="cell"> 
        <div v-if="props.value" class="on"></div> 
        <section v-else class="off"></section> 
    </div> 
</template>

<script> 
export default { 
    props: ['value'], 
} 
</script>

• No this (no instance)
• No responsive data

Split components

What? A Vue file you wrote has more than a thousand lines of code? 🤔
Reasonable component splitting can not only optimize performance, but also make the code clearer and more readable. Single function principle

Sourced from https://slides.com/akryum/vueconfus-2019#/4/0/3

Before optimization

<template>
  <div :style="{ opacity: number / 300 }">
    <div>{{ heavy() }}</div>
  </div>
</template>

<script>
export default {
  props: ['number'],
  methods: {
    heavy () { /* HEAVY TASK */ }
  }
}
</script>

After optimization

<template>
  <div :style="{ opacity: number / 300 }">
    <ChildComp/>
  </div>
</template>

<script>
export default {
  props: ['number'],
  components:
    ChildComp: {
      methods: {
        heavy () { /* HEAVY TASK */ }
      },
      render (h) {
        return h('div', this.heavy())
      }
    }
  }
}
</script>

Since Vue updates at the component level, although each frame causes the parent component to be re-rendered through data modification, ChildComp will not be re-rendered because there is no responsive data change inside it. So the optimized component will not perform time-consuming tasks on every rendering

Using Local Variables

Before optimization

<template>
  <div :style="{ opacity: start / 300 }">{{ result }}</div>
</template>

<script>
import { heavy } from '@/utils'

export default {
  props: ['start'],
  computed: {
    base () { return 42 },
    result () {
      let result = this.start
      for (let i = 0; i < 1000; i++) {
        result += heavy(this.base)
      }
      return result
    }
  }
}
</script>

After optimization

<template>
  <div :style="{ opacity: start / 300 }">
    {{ result }}</div>
</template>

<script>
import { heavy } from '@/utils'

export default {
  props: ['start'],
  computed: {
    base () { return 42 },
    result () {
      const base = this.base
      let result = this.start
      for (let i = 0; i < 1000; i++) {
        result += heavy(base)
      }
      return result
    }
  }
}
</script>

The main difference here is the implementation difference of the calculated property result of the components before and after optimization. The component before optimization accesses this.base many times during the calculation process, while the component after optimization uses the local variable base before calculation, caches this.base, and then directly accesses base.

So why does this difference cause a performance difference? The reason is that every time you access this.base, since this.base is a responsive object, its getter will be triggered, and then the dependency collection related logic code will be executed. If similar logic is executed too often, like in the example, hundreds of components are updated in hundreds of cycles, each component triggers computed to be recalculated, and then the dependency collection related logic is executed multiple times, the performance will naturally decrease.

From the demand point of view, it is enough for this.base to perform dependency collection once, and return its getter evaluation result to the local variable base. When base is accessed again later, the getter will not be triggered, and the dependency collection logic will not be followed, so the performance is naturally improved.

Lead to Revealing the Nine Performance Optimization Tips of Vue.js

Using KeepAlive

When some components with high rendering costs need to be switched frequently, keep-alive can be used to cache the component. After using keep-alive, the vnode and DOM of the component wrapped by keep-alive will be cached after the first rendering. When the component is rendered again next time, the corresponding vnode and DOM are directly obtained from the cache, and then rendered. There is no need to go through a series of processes such as component initialization, rendering and patching again, which reduces the script execution time and improves performance.

Note: Abusing keep-alive will only make your app lag because it will occupy a large amount of memory for a long time.

Destruction of events

When a component is destroyed, we should clear the global events and timers added in the component to prevent memory leaks.
Vue3's HOOK allows us to write event declaration and destruction together, which is more readable

function scrollFun(){ /* ... */}
document.addEventListener("scroll", scrollFun)

onBeforeUnmount(()=>{
  document.removeEventListener("scroll", scrollFun)
})

Vue2 can still achieve this effect through $once. Of course, you can also destroy the event in optionsAPI beforeDestroy, but I recommend the former way more, because the latter will make the code with the same function more scattered.

function scrollFun(){ /* ... */}
document.addEventListener("scroll", scrollFun)

this.$once('hook:beforeDestroy', ()=>{
  document.removeEventListener("scroll", scrollFun)
})

function scrollFun(){ /* ... */}

export default {
  created() {
    document.addEventListener("scroll", scrollFun)
  },
  beforeDestroy(){
    document.removeEventListener("scroll", scrollFun)
  }
}

Image loading

Image lazy loading: It is suitable for the situation where there are many images on the page and not all images are displayed on one screen. The vue-lazyload plug-in provides us with a very convenient image lazy loading instruction v-lazy

However, not all images are suitable for lazy loading. For example, for banners and photo albums, it is recommended to use image preloading technology to give priority to downloading the previous and next images of the currently displayed image.

Use reasonable data processing algorithms

This is a relatively test of the knowledge of data structure and algorithm. For example, a method to convert an array into a multi-level structure

/**
 * Array to tree structure, time complexity O(n)
 * @param list array * @param idKey element id key * @param parIdKey element parent id key * @param parId parent id value of the first level root node * @return {[]}
 */
function listToTree (list,idKey,parIdKey,parId) {
    let map = {};
    let result = [];
    let len ​​= list.length;

    // Build the map
    for (let i = 0; i < len; i++) {
        //Convert the data in the array into a key-value pair structure (the array and obj here will reference each other, which is the key point of the algorithm implementation)
        map[list[i][idKey]] = list[i];
    }

    //Build a tree array for(let i=0; i < len; i++) {
        let itemParId = list[i][parIdKey];
        // Top-level node if(itemParId === parId) {
            result.push(list[i]);
            continue;
        }
        // Orphan node, discarded (no parent node exists)
        if(!map[itemParId]){
            continue;
        }
        //Insert the current node into the children of the parent node (because it is a reference data type, if the node in obj changes, the corresponding node in result will change accordingly)
        if(map[itemParId].children) {
            map[itemParId].children.push(list[i]);
        } else {
            map[itemParId].children = [list[i]];
        }
    }
    return result;
}

other

In addition to the methods mentioned above, there are many other optimization techniques, but I don’t use them too often in my projects🤣

• Freeze objects (to prevent unnecessary responsive data from becoming responsive)
• Rendering long lists - batch rendering
• Long list rendering-dynamic rendering (vue-virtual-scroller)
• ...

First screen/volume optimization

In my project, I mainly have the following optimization directions for the first screen optimization

• volume
• Code Splitting
• network

Volume optimization

• Compress the bundled code: webpack and vite's production environment packaging will compress your code by default. This generally does not require special processing. Webpack can also manually implement it through the corresponding compression plug-in
• Cancel source-map: You can check whether there is a .map file in your packaged product. If so, you can set the value of source-map to false or empty to turn off code mapping (this takes up a lot of space)
• Enable gizp compression for packaging: This requires the server to also enable gizp transmission, otherwise it will be useless if enabled (webpack has a corresponding gzip compression plug-in, different versions of webpack compression plug-ins may be different, it is recommended to check the official website first)

Code Splitting

The role of code splitting is to split the packaged product into small products one by one, which depends on esModule. So when you use the import() function to import a file or dependency, the file or dependency will be packaged separately as a small product. Both lazy loading of routes and asynchronous components use this principle.

• Routing lazy loading
• Asynchronous components

For UI libraries, I generally don’t use on-demand component loading, but prefer to optimize by introducing them through CDN.

network

• CDN: First of all, the CDN is introduced as mentioned above. Local libraries are used in the development phase, and these dependencies are excluded when packaging by configuring external extensions (Externals). Then import them in the HTML file through CDN
• Server Push: HTTP2 is relatively mature; after the introduction of the CDN mentioned above, we can use the Server Push function of HTTP2 on the website to let the browser load these CDN and other files in advance.
• Enable gzip: This has been mentioned above. The principle is that when both the client and the server support gzip transmission, the server will give priority to sending files compressed by gzip, and then the client will decompress them after receiving them.
• Enable caching: Generally I use negotiated caching, but this does not apply to all situations. For example, for files that use Server Push, you cannot modify their file names at will. So I usually fix the file name of the main file produced

This concludes this article about 22 Vue optimization techniques (practical for projects). For more relevant Vue optimization techniques, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!