An Introduction to Visualforce View State in Salesforce

Visualforce pages that contain a form component also contain an encrypted, hidden form field that encapsulates the view state of the page. 

This view state is automatically created, and as its name suggests, it holds the state of the page - state that includes the components, field values and controller state.

The view state size of your Visualforce pages must be under 170 KB. (Prior to Spring 19 release it was 135 KB. for reference: Spring 19 Release Notes).
By reducing your view state size, your pages can load quicker and stall less often.

Serialization is what occurs when binary computer memory is converted into a format that can be transferred to disk or over a network connection. In Salesforce (and most other web-based platforms), this is commonly called the View state in Salesforce. 

When a Visualforce page receives a view state, it "deserializes" the data into an existing object, and acts as the object initialization routine instead of the constructor that is defined for the class. When there is no view state, the constructor is called instead.

How I can see view state:

To see view state, Enable Development mode from your user record.

View State

Best practices to optimize view state:

---

• Minimize Number of Forms on a Page :

Assume a page contains two forms - form A and form B. Whichever form the user submits and causes a postback, the view state for the page needs to get transferred. To support this, each form on your page will have its own copy of view state. If the associated view state is large, instead of having multiple forms on a page, have a single form and use <apex:actionRegion> to submit portions of the form. This practice will ensure that only a single copy of the view state is associated with that page.

• Declare Variables as Transient to Reduce View State :

An instance variable declared as transient is not saved and is not transmitted as part of the view state. If a certain field is needed only for the duration of the page request and does not need to be part of the view state, declare it as transient.

• Recreate State versus Storing It in View State:

View state should ideally contain only work in progress data. If you can reconstruct the data during postback, via a SOQL query or a web services call, do that instead of storing it in controller data members.

• Use Custom Objects or Custom Settings to Store Large Quantities of Read-Only Data:

Assume that your controller needs to call a Web service and parse a large response object. Storing it in view state may not even be an option given the size. Marking it as transient would incur the cost of an additional Web service call and parsing it again. In such instances, you could store the parsed response in a custom object and store just the record id to get to the parsed response. Custom settings provide another mechanism to cache data needed by your controller. Accessing custom settings is faster than access to custom objects since custom settings are part of your application's cache and does not require a database query to retrieve the data.

• Refine Your SOQL to Retrieve Only the Data Needed by the Page:

Only retrieve and store the fields in variable you need and also filter the records to only retrieve records needed by the visual force page.

• Refactor Your Pages to Make Its View Stateless:

Instead of using <apex:commandLink> or <apex:commandButton> components which need to be inside a <apex:form> component to invoke an action, use an <apex:outputLink> or other non-action method instead and implement the action through an <apex:page> action attribute - where it makes sense.

Enjoy! If you have any questions, comments etc. please feel free to let me know. As always, please feel free to get in touch me as I would be more than happy to assist you with any of your Salesforce development needs.

Next post: Actionpoller Tag in Visualforce Page