Profiling Render Performance

A search box sits above a 400-row orders table, and typing feels sticky: every keystroke costs roughly 120 ms on a mid-range laptop, the console is silent, and no error fires anywhere. "Feels slow" is a hypothesis, not a measurement, so your first move is not to memoize something — it is to record what Vue is actually doing on each keystroke. Profiling is also the natural next step after the isolation skills from Mocking Modules and Stubbing Children: if you can mount one component in a harness, you can reproduce one slow interaction.

Vue 3 can emit a performance timeline that the Vue DevTools profiler reads:

import { createApp } from 'vue'
import App from './App.vue'

const app = createApp(App)
app.config.performance = true
app.mount('#app')

With that flag on, Vue wraps component setup, render, and patch passes in performance.mark() and performance.measure() calls. Open the Vue DevTools Performance panel, click record, reproduce the keystroke, and stop: the recording becomes a flame graph — one bar per component update, width in milliseconds, stacked so a child update sits above the parent that triggered it. In a Vite dev setup you can skip the browser extension entirely: npm i -D vite-plugin-vue-devtools, add vueDevTools() to plugins in vite.config.js, and the same profiler lives in the dev-server overlay, with a component-tree view showing per-component render counts.

While recording, two readings decide where you look next:

Wasted renders are the number worth chasing. Fixing the render cost of a component that re-renders thirty times a second without changing a pixel is pointless — the win is removing the render entirely.

Read the graph top-down. The wide bar at the bottom belongs to the component that owns the state change, here the one holding the query ref. Every bar stacked above it is a child whose render effect re-ran because a tracked reactive dependency changed. When the entire table subtree lights up for two typed characters, ask the profiler's one hard question: which reactive dependency dirtied each of these components? The flame graph answers who; only reading the component's code answers why.

Typical findings from one five-minute session: OrdersTable re-renders because its parent passes :filter-fn="filterOrders" — a new arrow function on every render. StatCard re-renders because it receives :style="{ active }" — a fresh object each time. And 240 OrderRow children re-render because their parent re-rendered and their props changed by reference, even though every value is deep-equal. Those three explain the 120 ms, and none of them surface as errors.

Two caveats before you close the panel. Dev-mode timings are pessimistic: production builds skip the dev-only diff bookkeeping, so a 12 ms dev bar may be 3 ms after npm run build. Compare dev numbers against each other to find hotspots, and only trust user-facing numbers — Interaction to Next Paint, long tasks in Chrome's Performance panel — measured on a production build. Second, app.config.performance itself adds overhead to every update: leave it on while profiling, ship with it off.

The workflow that works: reproduce, record, sort by the widest bars, note the top three components, then stop profiling and read their code. Profiling tells you where the time goes; code review tells you why. Teams that profile every small change burn an afternoon on a tool that was only ever meant to point.

The profiler named the culprits: an inline function prop, an inline style object, and a cascade of 240 rows. This chapter explains the mechanism behind that flame graph, because in an interview you will be asked why a child re-renders when its parent does — and "because Vue is reactive" is not the answer.

Vue compares a child's props after the parent re-renders with Object.is per prop, once — a same-value reference check, never a deep comparison. Deep-comparing every prop on every parent render would cost O(size of props) per update and defeat the point of fine-grained reactivity. So this template:

<OrderRow
  :order="order"
  :style="{ fontWeight: highlighted ? 700 : 400 }"
  @click="() => select(order.id)"
/>

hands the child two brand-new references on every parent render: the style object literal and the arrow function. Object.is reports "changed", the child's render effect is dirtied, and the row re-renders for a highlight toggle that should have touched one element. The values are identical; the references are not, and references are all Vue checks.

The fix is reference stability. Hoist anything recreated per render into module scope or setup():

const rowStyle = { fontWeight: 700 } // one object, shared by every render

For events the cleanest pattern is to stop passing functions down at all — put the id on the element and handle the click in the parent:

<tbody @click="onRowClick">
  <tr v-for="o in orders" :key="o.id" :data-id="o.id">...</tr>
</tbody>

One listener at the top, zero function props, and a selection change never re-renders rows because of event wiring.

A taxonomy you can recite on demand:

Two tools finish the job. v-memo="[order.id, selectedId]" on the row element caches that element's subtree and reuses it unless one of the memo dependencies changed — with 240 rendered rows, selecting a row patches one subtree instead of 240. And shallowRef protects you when a large collection is replaced wholesale: a 10,000-item orders array made deeply reactive proxies every item on access, while shallowRef keeps the ref itself reactive and leaves the plain API objects untouched.

One trap while fixing these: v-memo's dependency array must list everything the cached subtree reads. Leave query out of [order.id, selectedId] and filtered rows silently keep showing stale text until something else forces a re-render. Memoization that is wrong is worse than memoization you never wrote.

The general rule to carry out of this topic: reactivity should flow from values, not identity. When a prop's reference changes but its meaning does not, you have found a wasted render — and now you can explain exactly why the flame graph lit up.

Rendering fixes cut keystroke latency, but they do nothing for first load: the browser still downloads one big JavaScript file before the app boots. The build output says exactly how big:

dist/assets/index-8f3a2b.js    412.19 kB │ gzip: 128.44 kB
dist/assets/index-8f3a2b.css     14.61 kB │ gzip:   4.12 kB

412 kB of JavaScript is real work on a mid-range phone — call it 400-600 ms of parse and execute before anything renders. To see which modules dominate, add rollup-plugin-visualizer:

// vite.config.js
import { visualizer } from 'rollup-plugin-visualizer'

export default {
  plugins: [vue(), visualizer({ open: true, gzipSize: true })]
}

npm run build then opens a treemap of the entry chunk. The usual offenders, in the order you will find them: a full echarts import (about 975 kB minified, 330 kB gzipped) when three line graphs are all you chart; moment with every locale (about 300 kB minified) where dayjs covers the same calls at 2 kB; and one import _ from 'lodash-es' that drags in the whole library (about 70 kB gzipped) to call debounce once.

Each has a targeted fix, and the size math is worth internalizing:

From 128 kB to 54 kB gzipped — a 2.4× reduction — without removing a feature, only unreachable code. Notice the shape of each fix: never "optimize the library", always change the import boundary so Rollup can tree-shake. The bundler drops only code it can prove is unreached, and a namespace import of everything defeats that proof.

While you are in vite.config.js, check one flag. Vue ships devtools integration code that a build can opt into:

export default {
  define: {
    __VUE_PROD_DEVTOOLS__: false // the default; never flip it on for a public build
  }
}

__VUE_PROD_DEVTOOLS__: true registers the devtools hook in your production bundle and exposes every component's state to anyone with the devtools extension. It exists for internal staging builds; a public app must ship with it off.

Two honest limits of bundle analysis. A treemap shows size, not order — it cannot tell you which module blocks first paint; that needs Chrome's coverage panel or the network waterfall. And it hides runtime cost: a 2 kB utility called inside a scroll handler can hurt users more than 40 kB of dormant code. Sort the treemap, cut the giants, then hand the remaining fat to code splitting — the subject of Async Components and Code Splitting, which attacks the same 412 kB from a different angle: not smaller modules, but later ones.

Carry one number into your next performance review: 128 → 54 kB gzipped saves roughly 90-120 ms of download-plus-parse on a 4G connection. Bundle work is measurable, and measurable wins are the ones that ship.