Vue computed(): What It Caches and When It Reruns

You call a computed() getter fifty times in one render and it only runs once. You mutate a ref it depends on and — nothing happens, not yet. Then you read .value and it recomputes. If that sequence feels slightly magical, it's because computed() isn't a function you call. It's a cached, lazily-evaluated effect with its own subscription list, and once you see the actual rule, none of it is magic anymore.

By the end of this article you'll be able to:

You've written a Vue 3 component with <script setup> and used ref, reactive, and computed at least once. This article assumes you know what a computed property looks like in code; it's here to fix how you think it behaves internally, which the syntax alone doesn't teach you. If the read-time tracking that makes any of this possible is still fuzzy, Vue Reactivity: ref vs reactive builds that foundation — useful background, not required reading.

This is written against Vue 3.5.x (verified 3.5.43 on npm, September 2026). Vue 3.6 is currently a release candidate adding an alien-signals-based reactivity core and an opt-in "Vapor Mode" compiler — neither changes the caching contract described here, so this article holds for both.

Say you're rendering a cart summary and you need a formatted total:

formattedTotal is a plain method, so the template calls it every time it appears, and again on every re-render triggered by anything else in the component — a hover state, an unrelated ref, a parent re-rendering. The console fills with recalculating total… for work whose answer hasn't changed. It's correct, but it's wasteful, and the waste scales with how many places in the template read the value and how often the component re-renders for unrelated reasons.

The fix looks trivial — wrap it in computed() — but why that fixes it, and exactly what it changes, is the actual subject of this article.

The mental model: a computed() ref is a special reactive effect that (1) tracks whatever reactive state its getter reads, exactly like a component render or a watchEffect does, (2) caches the return value instead of re-running immediately when a dependency changes, and (3) only re-runs the getter the next time something reads .value after it has been marked dirty.

That's two separate events, not one:

This is the same pull-based laziness that makes computed cheaper than a method call under repeated reads, and it's also exactly the behavior that surprises people the first time they log something inside a getter and see it fire at a moment they didn't expect.

Even though the template reads sum three times in one render, getterRuns is 1. Key concept: the first read evaluates and caches; every subsequent read before an invalidation returns the cached value without touching the getter at all.

Key concept: writing to a doesn't run the getter — it only marks the cache stale. The getter runs on the next read, which might be immediately, might be several ticks later, or might never happen if nothing ever reads that computed again (say, the component that used it unmounted first).

This is also why mutating a dependency ten times in a row before anything reads the computed still only costs one recompute, not ten:

A computed's dependency list isn't fixed at creation — it's rebuilt on every evaluation, so branches matter:

If useB is false, this run only reads useB and a — writing to b will not invalidate result at all, because b was never touched during the last evaluation. Flip useB to true and the next evaluation reads b instead, and from then on b is a real dependency and a is not. Key concept: the subscription list is a snapshot of what the getter actually read last time, not what it could theoretically read.

A computed can accept writes by passing { get, set } instead of a bare function:

The caching rule for the get side is identical to the read-only form. The set side isn't cached at all — it's a plain function call every time you assign.

All three are reactive effects that track dependencies the same way. What they're for is different:

If you find yourself putting fetch(), console.log(), or a router push inside a computed() getter, that's the signal you wanted watch or watchEffect instead — a computed getter must stay pure, because Vue may call it, skip it, or defer it based on caching, and a getter with side effects makes those decisions unpredictable for you.

No. It reruns only on a read that happens after a tracked dependency has changed since the last evaluation. Reading the same, non-invalidated computed any number of times returns the cached value.

Almost always one of two reasons: the property you changed was never read during the getter's last run (so it isn't a tracked dependency — see Stage 3), or you mutated a plain destructured variable instead of the reactive source itself. A third, rarer one: the getter reads something that isn't reactive at all — computed(() => Date.now()) never updates.

No — the getter must return a value synchronously. Model async derived state with a plain ref updated from inside watchEffect or watch instead.

It's memoization plus an automatic, fine-grained invalidation signal — you don't hand it a dependency array like useMemo; it discovers its dependencies by watching what the getter reads.

No. The cached value and the dirty flag live on the computed ref itself, shared by every reader — the getter still runs at most once per invalidation, regardless of how many places read .value.

That console full of recalculating total… from the opening example disappears the moment formattedTotal() becomes a computed() — not because Vue got smarter about when to call it, but because you stopped calling it directly at all. You're reading a cache that knows, dependency by dependency, exactly when it's stale. Once you can picture that dirty flag and the lazy pull that clears it, computed properties stop being a syntax you memorized and become a piece of Vue's design you can reason about.

If you've been burned by a computed that "wouldn't update," what turned out to be the actual dependency it was missing? Drop it in the comments — it's almost always Stage 3 in disguise.

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

Think it clicked? Take the 8-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

🚀 Want more like this? Every guide, playground, and quiz lives on bestpractic.org — open it and sign up free so the next one finds you.

Thanks for reading! Let's stay connected: