|
2 | 2 | aside: deep |
3 | 3 | --- |
4 | 4 |
|
5 | | -# Performance Guide <Badge text="WIP" /> |
| 5 | +# Performance |
6 | 6 |
|
7 | | -## Page Load Performance |
| 7 | +## Overview |
| 8 | + |
| 9 | +Vue is designed to be performant for most common use cases without much need for manual optimizations. However, there are always challenging scenarios where extra fine-tuning is needed. In this section, we will discuss what you should pay attention to when it comes to performance in a Vue application. |
| 10 | + |
| 11 | +First, let's discuss the two major aspects of web performance: |
| 12 | + |
| 13 | +- **Page Load Performance**: how fast the application shows content and becomes interactive on the initial visit. This is usually measured using web vital metrics like [Largest Contentful Paint (LCP)](https://web.dev/lcp/) and [First Input Delay](https://web.dev/fid/). |
| 14 | + |
| 15 | +- **Update Performance**: how fast the application updates in response to user input. For example, how fast a list updates when the user types in a search box, or how fast the page switches when the user clicks a navigation link in a Single-Page Application (SPA). |
| 16 | + |
| 17 | +While it would be ideal to maximize both, different frontend architectures tend to affect how easy it is to attain desired performance in these aspects. In addition, the type of application you are building greatly influences what you should prioritize in terms of performance. Therefore, the first step of ensuring optimal performance is picking the right architecture for the type of application you are building: |
| 18 | + |
| 19 | +- Consult [Ways of Using Vue](/guide/extras/ways-of-using-vue.html) to see how you can leverage Vue in different ways. |
| 20 | + |
| 21 | +- Jason Miller discusses the types of web applications and their respective ideal implementation / delivery in [Application Holotypes](https://jasonformat.com/application-holotypes/). |
| 22 | + |
| 23 | +## Profiling Options |
| 24 | + |
| 25 | +To improve performance, we need to first know how to measure it. There are a number of great tools that can help in this regard: |
| 26 | + |
| 27 | +For profiling load performance of production deployments: |
| 28 | + |
| 29 | +- [PageSpeed Insights](https://pagespeed.web.dev/) |
| 30 | +- [WebPageTest](https://www.webpagetest.org/) |
| 31 | + |
| 32 | +For profiling performance during local development: |
| 33 | + |
| 34 | +- [Chrome DevTools Performance Panel](https://developer.chrome.com/docs/devtools/evaluate-performance/) |
| 35 | + - [`app.config.performance`](/api/application.html#app-config-performance) enables Vue-specific performance markers in Chrome DevTools' performance timeline. |
| 36 | +- [Vue DevTools Extension](/guide/scaling-up/tooling.html#browser-devtools) also provides a performance profiling feature. |
| 37 | + |
| 38 | +## Page Load Optimizations |
8 | 39 |
|
9 | 40 | ### Bundle Size and Tree-shaking |
10 | 41 |
|
11 | | -### Full Build vs. Runtime-only build |
| 42 | +One of the most effective ways to improve page load performance is shipping smaller JavaScript bundles. Here are a few ways to reduce bundle size when using Vue: |
| 43 | + |
| 44 | +- Use a build step if possible. |
| 45 | + |
| 46 | + - Many of Vue's APIs are ["tree-shakable"](https://developer.mozilla.org/en-US/docs/Glossary/Tree_shaking) if bundled via a modern build tool. For example, if you don't use the built-in `<Transition>` component, it won't be included in the final production bundle. Tree-shaking can also remove other unused modules in your source code. |
| 47 | + |
| 48 | + - When using a build step, templates are pre-compiled so we don't need to ship the Vue compiler to the browser. This saves **14kb** min+gzipped JavaScript and avoids the runtime compilation cost. |
| 49 | + |
| 50 | +- If you are using Vue primarily for progressive enhancement and prefer to avoid a build step, consider using [petite-vue](https://github.com/vuejs/petite-vue) (only **6kb**) instead. |
12 | 51 |
|
13 | 52 | ### Code Splitting |
14 | 53 |
|
15 | | -### Big List Virtualization |
| 54 | +Code splitting stands for the build tool splitting the application bundle into multiple smaller chunks which can then be loaded on demand or in parallel. With proper code splitting, features required at page load can be downloaded immediately, with additional chunks being lazy loaded only when needed, thus improving performance. |
16 | 55 |
|
17 | | -### Avoid Unnecessary Component Abstractions |
| 56 | +Bundlers like Rollup (which Vite is based upon) or webpack can automatically create split chunks by detecting the ESM dynamic import syntax: |
| 57 | + |
| 58 | +```js |
| 59 | +// lazy.js and its dependencies will be split into a separate chunk |
| 60 | +// and only loaded when `loadLazy()` is called. |
| 61 | +function loadLazy() { |
| 62 | + return import('./lazy.js') |
| 63 | +} |
| 64 | +``` |
| 65 | + |
| 66 | +Lazy loading is best used on features that are not immediately needed after initial page load. In Vue applications, this is typically used in combination with Vue's [Async Component](/guide/components/async.html) feature to create split chunks for component trees: |
| 67 | + |
| 68 | +```js |
| 69 | +import { defineAsyncComponent } from 'vue' |
| 70 | + |
| 71 | +// a separate chunk is created for Foo.vue and its dependencies. |
| 72 | +// it is only fetched on demand when the async component is |
| 73 | +// rendered on the page. |
| 74 | +const Foo = defineAsyncComponent(() => import('./Foo.vue')) |
| 75 | +``` |
18 | 76 |
|
19 | | -## Update Performance |
| 77 | +If using client-side routing via Vue Router, it is strongly recommended to use async components as route components. See [Lazy Loading Routes](https://next.router.vuejs.org/guide/advanced/lazy-loading.html) for more details. |
20 | 78 |
|
21 | | -### Reducing Reactivity Overhead |
| 79 | +### SSR / SSG |
22 | 80 |
|
23 | | -- Use shallow APIs to hold immutable data |
| 81 | +Pure client-side rendering suffers from slow time-to-content. This can be mitigated with Server-Side Rendering (SSR) or Static Site Generation (SSG). Check out the [SSR Guide](/guide/scaling-up/ssr.html) for more details. |
24 | 82 |
|
25 | | -### Component and Reactivity Boundary |
| 83 | +## Update Optimizations |
26 | 84 |
|
27 | | -- Identify unnecessary updates with `renderTriggered` |
| 85 | +### Props Stability |
28 | 86 |
|
29 | | -### Provide / Inject |
| 87 | +In Vue, a child component only updates when at least one of its received props has changed. Consider the following example: |
30 | 88 |
|
31 | | -- Avoid props drilling |
32 | | -- Avoid duplicated computed properties |
| 89 | +```vue-html |
| 90 | +<ListItem |
| 91 | + v-for="item in list" |
| 92 | + :id="item.id" |
| 93 | + :active-id="activeId" /> |
| 94 | +``` |
| 95 | + |
| 96 | +Inside the `<ListItem>` component, it uses its `id` and `activeId` props to determine whether it is the currently active item. While this works, the problem is that whenever `activeId` changes, **every** `<ListItem>` in the list has to update! |
| 97 | + |
| 98 | +Ideally, only the items whose active status changed should update. We can achieve that by moving the active status computation into the parent, and make `<ListItem>` directly accept an `active` prop instead: |
| 99 | + |
| 100 | +```vue-html |
| 101 | +<ListItem |
| 102 | + v-for="item in list" |
| 103 | + :id="item.id" |
| 104 | + :active="item.id === activeId" /> |
| 105 | +``` |
| 106 | + |
| 107 | +Now, for most components the `active` prop will remain the same when `activeId` changes, so they no longer need to update. In general, the idea is keeping the props passed to child components as stable as possible. |
33 | 108 |
|
34 | 109 | ### `v-once` |
35 | 110 |
|
| 111 | +`v-once` is a built-in directive that can be used to render content that relies on runtime data but never needs to update. The entire sub tree it is used on will be skipped for all future updates. Consult its [API reference](/api/built-in-directives.html#v-once) for more details. |
| 112 | + |
36 | 113 | ### `v-memo` |
| 114 | + |
| 115 | +`v-memo` is a built-in directive that can be used to conditionally skip the update of large sub trees or `v-for` lists. Consult its [API reference](/api/built-in-directives.html#v-memo) for more details. |
| 116 | + |
| 117 | +## General Optimizations |
| 118 | + |
| 119 | +> The following tips affect both page load and update performance. |
| 120 | +
|
| 121 | +### Virtualize Large Lists |
| 122 | + |
| 123 | +One of the most common performance issues in all frontend applications is rendering large lists. No matter how performant a framework is, rendering a list with thousands of items **will** be slow due to the sheer amount of DOM nodes that the browser needs to handle. |
| 124 | + |
| 125 | +However, we don't necessarily have to render all these nodes upfront. In most cases, the user's screen size can display only a small subset of our large list. We can greatly improve the performance with **list virtualization**, the technique of only rendering the items that are currently in or close to the viewport in a large list. |
| 126 | + |
| 127 | +Implementing list virtualization isn't easy, luckily there are existing community libraries that you can directly use: |
| 128 | + |
| 129 | +- [vue-virtual-scroller](https://github.com/Akryum/vue-virtual-scroller) |
| 130 | +- [vue-virtual-scroll-grid](https://github.com/rocwang/vue-virtual-scroll-grid) |
| 131 | + |
| 132 | +### Reduce Reactivity Overhead for Large Immutable Structures |
| 133 | + |
| 134 | +Vue's reactivity system is deep by default. While this makes state management intuitive, it does create a certain level of overhead when the data size is large, because every property access triggers proxy traps that performs dependency tracking. This typically becomes noticeable when dealing with large arrays of deeply nested objects, where a single render needs to access 100,000+ properties, so it should only affect very specific use cases. |
| 135 | + |
| 136 | +Vue does provide an escape hatch to opt-out of deep reactivity by using [`shallowRef()`](/api/reactivity-advanced.html#shallowref) and [`shallowReactive()`](/api/reactivity-advanced.html#shallowreactive). Shallow APIs create state that is reactive only at the root level, and exposes all nested objects untouched. This keeps nested property access fast, with the trade-off being that we must now treat all nested objects as immutable, and updates can only be triggered by replacing the root state: |
| 137 | + |
| 138 | +```js |
| 139 | +const shallowArray = shallowRef([ |
| 140 | + /* big list of deep objects */ |
| 141 | +]) |
| 142 | + |
| 143 | +// this won't trigger updates... |
| 144 | +shallowArray.value.push(newObject) |
| 145 | +// this does: |
| 146 | +shallowArray.value = [...shallowArr.value, newObject] |
| 147 | + |
| 148 | +// this won't trigger update... |
| 149 | +shallowArray.value[0].foo = 1 |
| 150 | +// this does: |
| 151 | +shallowArray.value = [ |
| 152 | + { |
| 153 | + ...shallowArray.value[0], |
| 154 | + foo: 1 |
| 155 | + }, |
| 156 | + ...shallowArray.value.slice(1) |
| 157 | +] |
| 158 | +``` |
| 159 | + |
| 160 | +### Avoid Unnecessary Component Abstractions |
| 161 | + |
| 162 | +Sometimes we may create [renderless components](/guide/components/slots.html#renderless-components) or higher-order components (i.e. components that render other components with extra props) for better abstraction or code organization. While there is nothing wrong with this, do keep in mind that component instances are much more expensive than plain DOM nodes, and creating too many of them due to abstraction patterns will incur performance costs. |
| 163 | + |
| 164 | +Note that reducing only a few instances won't have noticeable effect, so don't sweat it if the component is rendered only a few times in the app. The best scenario to consider this optimization is again in large lists. Imagine a list of 100 items where each item component contains many child components. Removing one unnecessary component abstraction here could result in a reduction of hundreds of component instances. |
0 commit comments