In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >
Share
Shulou(Shulou.com)06/01 Report--
This article introduces the relevant knowledge of "performance optimization analysis of Vue list rendering". 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!
Background
The team's current Web-side products need to display two list views: a card list and an item list, and switch between the two lists when the toggle button is clicked.
When the development is completed for simple performance testing, it is found that when the number of lists reaches hundreds, switching views will cause obvious page stutters and poor user experience. So we started to optimize the performance.
First optimization: solving known problems
Because the project is implemented using Vue.js (hereinafter referred to as "Vue"), first check to see if there is a performance bottleneck in Vue, and if so, consider replacing Vue for optimization.
By looking at the official benchmark results, we can see that Vue's list rendering performance is poor when highlighting and swapping list elements, and is good when creating lists and adding list elements, and the execution time is in milliseconds.
Since Vue does not give us a low performance ceiling, we can continue to optimize performance based on the use of Vue.
Let's take a look at the code to see what happens when you click on the switch.
When the click event is triggered, the component property cViewType changes, and then the list of the two views is rendered according to the value of cViewType. Some of the codes are as follows:
. .
Here, the list is switched through the v-if directive, each time the previous view list is destroyed, and then a new view list is created. When there are a large number of list elements, a large number of DOM elements are created and destroyed, and the performance overhead is very expensive.
So the easiest way to optimize is to cache the list that has been rendered. The corresponding code is also simple: change v-if to v-show, so that you can control the display / hiding of the two lists through CSS, thus avoiding repeated creation of DOM elements.
The effect after the change is indeed very obvious, and things seem to be over here, but if the number of lists increases to an order of magnitude or two, say 10,000, is it still smooth?
Second optimization: troubleshooting possible problems
When I increased the number of list elements to 10, 000, the stutter problem came up again.
The browser page stutters for two reasons, either the script engine is executing js code, or the rendering engine is rendering the page.
Since we have previously optimized the execution of js code by the script engine, this time we will turn to the rendering engine.
The rendering engine program needs CPU to perform rendering operations, and CPU itself is not good at handling batch rendering of graphics, so you can leave this part of the rendering work to GPU.
You can call GPU by setting the CSS style. Here is one way to do this.
First, set both view lists to absolute positioning, away from the document flow.
Then the z-index property of the view list is dynamically modified in the click event to control the cascading relationship between the two lists, and the show / hide effect is achieved by letting one list overwrite the other.
It is important to note that although the effect can be achieved by keeping the card list out of the document flow, because the item list is higher than the card list, the entry list element still appears at the bottom when the card list is displayed. so set both elements to absolute positioning and have separate scroll bars.
After optimization, ten thousand pictures can be switched in milliseconds, which is very smooth.
The third optimization: the side effects of thinking schemes
There is no silver bullet in the world, and even borrowing GPU to speed up rendering will have some side effects.
Because GPU is not sensitive to the number of rendered graphics but sensitive to the number of rendering times, and the browser has a limit on the number of concurrent requests (8 concurrent 6 requests at a time), this will increase the rendering times of GPU to a certain extent, thus affecting the user experience.
To solve this problem, we can improve the concurrency ability through the HTTP/2 protocol or preload in batches (wait for a batch of image resources to be preloaded and then updated to the card list).
Since these plans have not yet been put into practice, they will not be carried out here.
This is the end of the content of "performance Optimization Analysis of Vue list rendering". 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.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.