Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "what is the performance trap in Vue.js". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Investigate the reasons for performance degradation

I first did a quick test using Lighthouse. Fortunately, Firefox provides a browser plug-in for this:

Https://addons.mozilla.org/en-US/firefox/addon/google-lighthouse/

Here are the results I got.

The figure of 89% is pretty good. In fact, compared with many popular websites, this performance is quite excellent. This test points out some potential problems, such as the speed index and the first meaningful and meaningful drawing steps. In theory, solving these problems will further improve the score, but it may not necessarily solve the serious performance problems faced by the application.

We have some image and audio material resources in our game, but neither of them will let the game get stuck there. We can also over-optimize these optimized resources, but this may not help at all.

This test does not allow us to really find out the possible cause of this performance problem. So I started thinking, "it's not Vue's problem, is it?" There's no reason for this idea to pop up, but it would be stupid not to check it out. I checked the console of the deployed site and found it was blank. But warnings are often not displayed in production. When I did the same thing locally, I was surprised by a bunch of Vue warnings.

Like most developers, I don't care so much about console warnings and think they are warnings, not errors; so I tend to focus on something else. Maybe eliminating these warnings will solve my production problems, and I decided to delve into each problem and fix them.

All of these warnings come from a self-created component that displays the option called Cards.vue, so this component may need to be heavily rewritten.

I decided to resolve these console warnings in order.

[Vue warn]: Avoid using non-primitive value as key, use string/number value instead. Found in-> at src/components/Cards.vue

Vue.js has many instructions to make it more intuitive to use the framework, such as v-for to quickly render arrays as lists. When using it, we need a: key to effectively re-render the component. But we used an object as a key, which is a non-original value, which led to this error. I decided to use index.description as a new key because it is a string and can be better re-rendered when the value changes.

> [Vue warn]: Duplicate keys detected:'[object Object]'. This may cause an update error. Found in-> at src/components/Cards.vue

Changing: key to a string (index.description) to resolve the previous error will solve the error of the duplicate key. We can only write string types to DOM, so when we pass an object to render, it will be converted to an equivalent string (that is, [object Object]); and because this used to be our key, each object will be converted to [object Object] (unless the object has a different value), leading to a duplicate key warning. Now that the key is not an object, the warning will disappear and the efficiency will be improved.

> [Vue warn]: You may have an infinite update loop in a component render function. Found in-> at src/components/Cards.vue

In terms of a very vague warning, this warning seems to be the most important: an infinite loop means memory consumption. This message doesn't tell us what might be wrong, but it does imply that the problem is related to the render function in the component. Maybe it's because the code we write is so clever that it triggers constant updates and takes up so much computing power that browsers and devices crash.

This warning at least tells us to check the Cards.vue, so my first idea is to check the reaction properties in the component, because this can lead to errors. The response attribute triggers re-rendering when it is changed.

We are displaying data from index.days and index.description. But we won't change the data, we get the index from the cardInfo array.

> vmurfort = "index in cardInfo.sort (() = > Math.random ()-0. 7) .slice (0P4)"

We use this code to randomly sort the elements in the array, and then display the first four elements as options selected by the player. The effects () function is called when the user clicks an option, which not only calculates how an action affects the state of the game, but also deletes the first four elements using the splicing prototype on cardInfo.

In a framework that uses virtual DOM such as Vue, when a reaction property such as cardInfo is used, re-rendering is triggered whenever the value of the data property changes. In our application, we will directly use the sort () prototype to change it, and then delete the element to reorder. All of this triggers a re-rendering of "infinity", causing a warning.

I decided to change the logic of data filtering and stop making multiple changes to the reaction property cardInfo. I installed lodash.shuffle and defined a calculation property, shuffledList (), which creates a copy of cardInfo named list. I applied a random sort operation to it, returned a "frozen" result, and then split it to display four cards. We used Object.freeze (), which will make the object we return immutable, thus stopping all re-rendering operations completely.

At this point, the problem is solved.

Fall into the pit of the frame

To be honest, when I first started to investigate the reasons for the performance degradation, I thought I would have to optimize a lot of resources to solve the problem. This final result shows that we have to be very careful when using many framework abstractions-- especially in Vue, that an instruction is used only when necessary, and that usage must not go wrong, because they definitely have their own price.

It also got me thinking about other work I've done, in which applications may have unnecessary performance problems because of the framework. Most modern front-end frameworks have a lot of abstractions that make it easier to build applications for Web. But we should keep in mind that using these things can cause potential performance problems.

I used Vue.js a lot, so I decided to explore some of the instructions I used before without considering their possible performance impact on my application. Three of the most popular instructions came into my sight.

1. V-if and v-show

Both instructions are used to render elements conditionally, but the working mechanisms behind them are very different, so the usage is very different. V-if does not render the component at first, but only when the condition is true. This means that when you switch the visibility of the component many times, it will continue to re-render. If you want to change the visibility of components multiple times, do not use this feature. This will affect your performance.

V-show is a good substitute. Whether you enable CSS or not will render your component, but it will only decide whether the component is visible based on whether the condition is true or false. This approach does have its drawbacks because it does not delay rendering of non-essential components until you need them to actually appear on the screen. If your initial rendering is not that complex, then it is appropriate.

2. V-for

This instruction is usually used to render a list from an array. It has a special syntax in the form of item in list, where list is the source data array and item is the alias of the array element to be iterated over. By default, Vue adds watchers to the source data array, which triggers re-rendering whenever a change occurs. This continuous re-rendering can adversely affect application performance. If you only want to visualize objects, then Object.freeze () is a good solution that can greatly improve performance. But keep in mind that you will not be able to update components or edit object data.

In the course of this study, I also realized that Lighthouse may be looking at application performance metrics that affect the user experience in a more direct way, so my next question is how to track application performance on the server.

That's all for "what are the performance traps in Vue.js?" Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.