Performance Optimization

💬 In plain words: Lightning Data Service (LDS) is Salesforce's shared cache for records. By using base components and wire adapters like getRecord , you get free data caching, built-in Field-Level Security (FLS), and real-time auto-refreshes without writing a single line of Apex. You should only write Apex when LDS cannot handle the job—like for complex queries, multi-object logic, or heavy transactional operations.

💬 In plain words: When you use @wire in Lightning Web Components, Salesforce caches the results. If a component asks for the same data twice, it only costs one server trip. That gives you free speed, but it creates a risk of stale data. When you change data, you must manually call refreshApex to force a fresh copy. Lazy loading means you don't fetch or render heavy components until the user actually scrolls down to see them. 📌 Example: Handling Stale Cache Data Screen A uses @wire to fetch getOpenCases . A user opens Screen B, edits a case, and returns to Screen A. The list on Screen A is now stale, because it is being served from the local wire cache rather than the server. To fix this, store the entire wired result object ( wiredCases ) and call refreshApex(this.wiredCases) immediately after the edit in Screen B completes. The cache gives you speed; the refresh gives you the truth.

💬 In plain words: Platform Cache is Salesforce's short-term memory layer. You pay the performance cost once to run a heavy query or API call out, and then you store the result. Thousands of subsequent requests can read that stored result in microseconds. Org cache is shared by everyone; session cache is specific to a single user. Golden rule: Cache is a temporary hint, not a permanent database. Always write your code to handle a cache miss.

In plain words: View State in Salesforce is a hidden, encrypted data package passed back and forth between your browser and Salesforce servers. It remembers your Visualforce page's state (like form inputs and variables) across page refreshes or button clicks. Salesforce enforces a strict maximum limit of 170 KB for this data. If you exceed it, your page will crash with a fatal runtime error. When you build custom Visualforce apps with interactive forms, search filters, or data tables, maintaining information across server requests is crucial. Because standard web traffic doesn't naturally "remember" things, Salesforce uses View State to track your Apex controller variables and component details. If you aren't careful with how much data you store, your page weight will bloat rapidly, leading to slow performance and crashed pages.