# Performance Course: [Vue.js](https://www.devtutorials.ai/learn/vue) ยท Section: Production Vue Source: https://www.devtutorials.ai/learn/vue/production/performance > Measuring before optimising, stable props, computed stability, v-once and v-memo, virtual lists for huge data, shallow reactivity and markRaw, lazy loading and bundle size, tree shaking, and checking a production build with DevTools, Lighthouse and a bundle report, and accessibility: keyboard, labels, live regions and focus. ## Fast Enough for Everyone - Vue is fast by default. Most apps never need special tricks. - Slow pages usually come from a few causes: huge lists, too many re-renders, or a big first download. - Many visitors use cheap phones and slow networks. Test for them, not only for your laptop. - **Measure first.** Change code only where the measurement says it is slow. **Simple lesson:** measure, find the slow part, fix that part only. ### A Real-World Example - Meera's order history has 20 000 orders. - Making all of them deeply reactive takes time on every load. - The list is only replaced as a whole, so deep tracking is wasted work. - Compare `ref` and `shallowRef` below. interface Order { id: number; dish: string; items: { name: string; qty: number }[]; } function makeOrders(n: number): Order[] { return Array.from({ length: n }, (_, i) => ({ id: i + 1, dish: "Dosa", items: [{ name: "Dosa", qty: 2 }] })); } const deep = ref([]); const shallow = shallowRef([]); const result = ref(""); function load(): void { const data1 = makeOrders(20000); const data2 = makeOrders(20000); let t = performance.now(); deep.value = data1; deep.value.forEach((o) => o.items[0].qty); const deepMs = performance.now() - t; t = performance.now(); shallow.value = data2; shallow.value.forEach((o) => o.items[0].qty); const shallowMs = performance.now() - t; result.value = \`ref: \${deepMs.toFixed(1)} ms, shallowRef: \${shallowMs.toFixed(1)} ms\`; } `, "main.ts": `import { createApp } from "vue"; createApp(App).mount("#app"); `, }} /> - **What happened:** reading every order through a deep `ref` was slower. Each nested object needed a proxy. - `shallowRef` skipped that, because only `.value` itself is watched. ### What You Will Learn 1. How to measure. 2. Stable props, so fewer children re-render. 3. Computed stability. 4. `v-once` and `v-memo`. 5. Virtual lists for very long lists. 6. Shallow reactivity and `markRaw`. 7. Lazy loading and bundle size. 8. Checking a production build. 9. Keyboard, labels, focus and screen readers. ## Measure First - **Vue DevTools** has a Performance and a Timeline tab. They show which components render and how long they take. - The browser's **Performance** panel records everything the page does. - **Lighthouse** (in Chrome DevTools) scores load speed on a slow phone and suggests fixes. - `performance.now()` around a piece of code gives a quick timing, as in the first box. - Always measure a **production build** (`npm run build` then `npm run preview`). Development builds are slower on purpose. Never judge speed in development mode. Dev builds include warnings and extra checks, so they can be several times slower than the real thing. ## Fewer Re-Renders ### Stable Props - A child re-renders when its props change. - Pass each child exactly what it needs. Prefer `:active="item.id === activeId"` over `:active-id="activeId"`. - With `activeId`, **every** child gets a new prop on each change, so every child re-renders. - With a boolean, only the two children whose value really changed re-render.
Animation: when the active item changes, passing activeId makes all five rows flash as re-rendered, while passing an active boolean makes only the old and new active rows flash :active-id="activeId" :active="id === activeId" 5 rows re-render 2 rows re-render
Pass each child only what it needs, so only the changed children render again.
const props = defineProps({ name: String, id: Number, activeId: Number, active: Boolean }); onUpdated(() => renders.count++); `, "renders.ts": `export const renders = { count: 0 }; `, "App.vue": ` `, "main.ts": `import { createApp } from "vue"; createApp(App).mount("#app"); `, }} /> ### Computed Stability - Since Vue 3.4, a computed value only triggers its readers when its **result** really changes. - `isBusy = computed(() => orders.value > 5)` triggers only when it flips between true and false. - If a computed returns a **new object** every time, it always looks changed. Return the old object when nothing changed. ### v-once and v-memo - `v-once` renders an element once, then skips it forever. Good for truly fixed content. - `v-memo="[a, b]"` skips updating that element unless `a` or `b` changed. - `v-memo` helps in very long `v-for` lists where only a few rows change. Use it rarely, and only after measuring. const rows = Array.from({ length: 1000 }, (_, i) => ({ id: i + 1, dish: "Order " + (i + 1) })); const selected = ref(1); const time = ref(""); function pick(id: number): void { const t = performance.now(); selected.value = id; requestAnimationFrame(() => (time.value = \`update took about \${(performance.now() - t).toFixed(1)} ms\`)); } `, "main.ts": `import { createApp } from "vue"; createApp(App).mount("#app"); `, }} /> `v-memo` must list **every** value the row shows that can change. If you leave one out, that part of the row stops updating, which is a hard bug to spot. **Simple lesson:** stable props, stable computed values, and `v-memo` only where measured. ## Very Long Lists - Rendering 10 000 rows creates 10 000 elements. That is slow, even if Vue is fast. - A **virtual list** renders only the rows you can see, plus a few extra. - As you scroll, it swaps which rows are rendered. A tall spacer keeps the scrollbar right. - Libraries such as `vue-virtual-scroller` do this well. Here is the idea in a few lines. const all = Array.from({ length: 10000 }, (_, i) => "Order " + (i + 1)); const rowHeight = 28; const viewHeight = 280; const scrollTop = ref(0); const start = computed(() => Math.floor(scrollTop.value / rowHeight)); const visible = computed(() => all.slice(start.value, start.value + Math.ceil(viewHeight / rowHeight) + 2)); function onScroll(e: Event): void { scrollTop.value = (e.target as HTMLElement).scrollTop; } `, "main.ts": `import { createApp } from "vue"; createApp(App).mount("#app"); `, }} /> ### Shallow Reactivity and markRaw - Big data that you only **replace** should live in `shallowRef`, as in the first box. - Big objects from other libraries (a map, a chart) should be wrapped in `markRaw()`. - Both come from **Advanced Reactivity**. **Simple lesson:** render only what is visible, and do not make big data deeply reactive. ## A Smaller First Download - The first download is often the biggest delay on slow networks. - **Tree shaking:** the build removes code you never import. Import only what you use. - **Lazy loading:** split rarely used pages and heavy components with `() => import()` and `defineAsyncComponent`. - Check what is in your bundle before guessing. // Code in a plain `, "App.vue": ` `, "main.ts": `import { createApp } from "vue"; createApp(App).mount("#app"); `, }} /> ### Checking a Production Build ```bash npm run build # makes dist/, prints the size of each file npm run preview # serves dist/ like a real host npx vite-bundle-visualizer # opens a map of what fills your bundle ``` - Look for unexpectedly big libraries, and for code that every page loads but few use. - Run Lighthouse on the preview, with a slow phone and network. These commands run in a real project on your computer. The lab cannot build or measure network downloads, because every file is already in the preview. **Simple lesson:** import less, lazy-load the rest, and read your bundle report. ## Usable by Everyone - A fast app must also work with a **keyboard** and a **screen reader** (software that reads the page aloud). - Use real elements: `