Optimizing Visualforce View State — Best Practices

What Is View State in Visualforce?

When working with a Visualforce page, interactions between the browser and the server occur through HTTP GET requests (for initial page load) and HTTP POST requests (for form submissions). Because HTTP is a stateless protocol, each request is treated independently. View state provides the mechanism to persist page state across these HTTP requests.
View state is stored as a hidden encrypted form field that is generated when the page renders. When the user submits a form, view state is sent back to the server along with the form data. The server uses this information to reconstruct the page state before applying new changes.

How to Enable the View State Inspector

Salesforce provides the View State Inspector tool, which lets you view the contents of the view state and identify what is contributing to its size. This feature must be enabled by Salesforce Support — file a support ticket to get it enabled for your organization. Once enabled, it appears as a tab in Visualforce development mode.

Best Practices for Optimizing Visualforce View State

Large view state increases page load times because view state is transferred back and forth between the browser and the server on every form submission. The following best practices help reduce view state size and improve performance.

1. Minimize the Number of Forms on a Page

Each <apex:form> component on a page creates its own copy of the view state. If a page has multiple forms, all copies of view state are transferred on every form submission — even if only one form is being submitted.
Instead of using two separate forms:

<apex:page controller="MyController">
 
<apex:form>
   <apex:commandButton action="{!saveAccount}"
 value="Update Account"/>
    <!--Account attributes available for editing -->
 
</apex:form>
 
<apex:form>
    <apex:commandButton action="{!saveContacts}"
  value="Update Contacts"/>
     <!--Contact attributes available for editing -->
</apex:form>
 
 </apex:page>

 
Consolidate into a single form using <apex:actionRegion> to submit only a portion of the form:

 
// Combining into single form and leveraging <apex:actionRegion>

<apex:page controller="MyController">
  <apex:form>
     <apex:commandButton action="{!saveAccount}"
 value="Update Account"/>
     <!--Account attributes available for editing -->
    
     <apex:actionRegion>
       <apex:commandButton action="{!saveContacts}"
 value="Update Contacts"/>
     <!--Contact attributes available for editing -->
    </apex:actionRegion>
 
  </apex:form>
</apex:page>

In the second example, clicking "Update Contacts" only submits the portion of the form within the <apex:actionRegion>, reducing the amount of view state transferred.

2. Declare Variables as Transient

An instance variable declared as transient is not saved as part of the view state and is not transmitted with form submissions. Declare a variable as transient when it is only needed for the duration of the current page request and does not need to persist.

<apex:page controller="ExampleController">
  The Current Time is : {!currentDateTime}
 
  <apex:form>
    <apex:commandLink value="refresh"/>
  </apex:form>
</apex:page>

public class ExampleController {
    transient DateTime currentDateTime;
    public String getCurrentDateTime() {
       if (currentDateTime == null) currentDateTime = System.now();
        return '' + currentDateTime;
    }
}

In this example, currentDateTime is declared as transient, so it is recalculated on each page load rather than being stored in view state.

3. Recreate State Instead of Storing It

View state should ideally contain only work-in-progress data — for example, the current object being edited or multi-page wizard data. If you can reconstruct data during a postback via a SOQL query or web service call, implement that approach instead of storing the data in controller variables.

4. Use Custom Objects or Custom Settings for Large Read-Only Data

If your controller calls a web service and parses a large response object, avoid storing the entire response in view state. Instead:

• Store the parsed response in a custom object and store only the record ID in the controller.
• Use custom settings to cache data needed by your controller. Custom settings are part of your application's cache and do not require a database query, making them faster to access than custom objects.

5. Refine Your SOQL Queries

Only retrieve and store the fields and records your page actually needs. Use WHERE clauses and SELECT field lists to limit the data returned by SOQL queries to exactly what is required by the page.

6. Refactor Pages to Be View Stateless

Instead of using <apex:commandLink> or <apex:commandButton> (which require an <apex:form> and therefore create view state), use <apex:outputLink> or the <apex:page action> attribute for actions that do not require form data. This reduces or eliminates view state for those interactions.

7. Implement Custom State Management

In some cases, you may want to bypass Visualforce view state entirely and manage state yourself. Use an HTML <form> element instead of <apex:form>. This is useful for Visualforce pages served to mobile devices where view state size may exceed what embedded browsers can handle.