Efficient Wire Usage and Getter Performance
By the end of this lesson, you'll be able to:
- Recognize that getters re-execute on every access, not just once
- Memoize an expensive getter to avoid redundant recomputation
- Wire only the fields a component actually needs
Prerequisites: "Minimizing Server Calls and Caching Strategies"
Getters Run Often
// Recomputes the full sort on every single access, even if
// this.accounts hasn't changed since the last time
get sortedAccounts() {
return [...this.accounts].sort((a, b) => a.name.localeCompare(b.name));
}
Unlike a plain class field, a getter (Module 3) is a function that re-executes every time it's read, including during re-renders triggered by unrelated state changes. Sorting or filtering a large array inside a getter means redoing that work far more often than the underlying data actually changes.
Memoizing Expensive Getters
_sortedCache;
_sortedForData;
get sortedAccounts() {
if (this._sortedForData === this.accounts) {
return this._sortedCache;
}
this._sortedCache = [...this.accounts].sort((a, b) => a.name.localeCompare(b.name));
this._sortedForData = this.accounts;
return this._sortedCache;
}
Tracking the last input the computation ran against, and only redoing the work when that reference has genuinely changed, keeps the getter's cost proportional to actual data changes rather than every render.
Wire Usage Pitfalls
// Wasteful: requesting fields the component never displays
@wire(getRecord, { recordId: '$recordId', fields: [NAME_FIELD, INDUSTRY_FIELD, PHONE_FIELD, WEBSITE_FIELD, DESCRIPTION_FIELD] })
account;
Wiring more fields than a component actually uses increases response payload size for no benefit, and each additional @wire adapter on a component adds its own tracking overhead. Being deliberate about exactly which fields are genuinely needed is a small habit with a real, compounding effect across many components.
Exercise
Explain, as a comment, why a getter that filters a 5,000-item array is more concerning performance-wise than the same filter running once in connectedCallback.
Show hint
Think about how many times each one actually runs.
Exercise
Challenge: add memoization to this getter so it only re-sorts when this.contacts has actually changed.
Show hint
Track the last input reference and compare against it.
Efficient Wire Usage and Getter Performance Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
A getter is not a cached value — it runs fresh every time it's accessed, which means expensive logic inside one can quietly become a real performance problem as a component re-renders.