Skip to main content

Sneak Peek: What is Visualforce Viewstate? and how to keep it lean

Note: The main content for this blog post was shared by my friend and colleague Shriram Kabra.

There are loads of blogs and articles around managing viewstate in Visualforce pages. As you would know, viewstate is primarily a serialized form of controller state between postbacks. It is very helpful to retain controller's state between client's browser and server.

How viewstate works?

Every time user opens a visualforce page, Salesforce executes related controller(s). As per controller logic, data is retrieved/ created within memory. This data can also be considered as controller state. If you monitor the lifecycle of Salesforce object (object of controller), it ends as soon as it responds to browser and loses its state. Technically, all subsequent requests for it are fresh page loads. In order for visualforce to retain this state between all postbacks, it needs to store this state somewhere. This is where Viewstate comes handy. While rendering visualforce page, engine serializes controller state to string and sends it within page's html content as viewstate (can view it when viewing source of a rendered visualforce page).

In all subsequent postbacks (for e.g. if user clicks on a button which invokes controller method), page sends viewstate back to Salesforce, which is deserialized to recreate state of controller since last postback. This helps in overall processing.

Issues while using Viewstate
Viewstate is quite helpful, as it auto-magically maintains state of controller and avoid developer to write more code to achieve it. But, it comes with its own cost.

Firstly, viewstate adds to the overall data to be downloaded, hence increases data to be downloaded to browser. Heavy viewstate leads to latency in page load or any subsequent user operations.

Secondly, Salesforce restricts viewstate size to a maximum of 135KB. Any page having viewstate greater than that will show a Salesforce thrown error "Maximum view state size limit (135KB) exceeded".

Standard solutions to reduce Viewstate footprint
There are some widely known solutions to manage viewstate, as mentioned below
  1. Avoid using Forms: Well, it's simply killing the chicken, so there are no eggs. With no forms in visualforce page (and components), there is no state to be maintained. So try to reduce it as much as possible. For example, if the page just displays information, there is no need for input fields (and thus a form)
  2. Minimize controller level properties: retain only important data within controller and avoid creating controller properties as much as possible. Use method level variables, which will be automatically disposed when request cycles ends, hence, will not be included within controller viewstate
  3. Use transient properties: controller level properties which are not required to be retained within postbacks, can be marked as transient. By using transient keyword, Salesforce skips those properties for viewstate generation
  4. Use Javascript Remoting: javascript remoting methods are stateless and as a result no data is saved within viewstate
  5. Minimize data: reduce data volume to be retained at controller level. For e.g. if there are some records which are to be fetched only for display purposes, fetch them every time they are required, instead of retaining their data within controller
  6. Avoid components using controller: if a visualforce component uses it's own controller, it's viewstate is also tied up with the viewstate of main page, further increasing the load. So, it is advisable to watch for components using their own controller

Internal Viewstate - The hidden viewstate

Now, as we have covered basics around viewstate, it's considerations and known solutions, we come to problem extension. Even after employing aforementioned techniques, we can often see that page's viewstate is still not very small, even if you have very few controller properties.

What is Internal viewstate?
While using Visualforce controllers and UI tags, Salesforce maintains internal data. This data is stored within Internal viewstate is not available for developers to view/ manipulate. It can increase in size depending on various factors such as:

  1. Controllers/ forms being used in page (including controllers of components being used)
  2. Visualforce tags being used
  3. Any apex repeat tags being used 

Solutions to reduce Internal ViewState:
  1. Use lesser Visualforce components and use more standard HTML components
  2. Use Javascript Remoting to manage data being sent back and forth for each operation
Reference links:


Popular posts from this blog

Quick Tips: Salesforce default Images

Well, I'm sure a lot of you still rely on using out of the box salesforce images for displaying quick icons within formula fields or even using them within your Visualforce pages. Lately, I realized that a lot of earlier resources are no longer accessible, so I tried to quickly extract all images from Salesforce CSS files and provide a quick reference here. Please note, I've referenced all images from SF servers directly, so if anything changes, the image should stop rendering here. As these images are completely controlled by Salesforce, and in case they change anything, it might lead to image not being accessible. Image path Image /img/samples/flag_green.gif /img/samples/flag_green.gif /img/samples/flag_red.gif /img/samples/color_red.gif /img/samples/color_yellow.gif /img/samples/color_green.gif /img/samples/light_green.gif /img/samples/light_yellow.gif /img/samples/light_red.gif /img/samples/stars_100.gif /img/samples/stars_200.gif /img/samples/stars_300.

Lightning: Generate PDF from Lightning components with in-memory data

I'm sure as everyone is diving into lightning components development, they are getting acquainted with the nuances of the Lightning components framework. As well as, its current limitations. Being a new framework, this is bound to happen. Although we have our users still using salesforce classic, we have started using lightning components framework our primary development platform and Visualforce is considered primarily for rendering lightning components within Classic Service console. Recently, while re-architecting a critical module, we encountered a problem wherein we needed to generate PDF from lightning components. Now, being Javascript intensive framework, it has limited room for such features (may be included in future roadmap). As of now, there is no native feature within the lightning framework to do so (at least I didn't find anything). Common Scenario - Create Visualforce page to retrieve data and generate PDF For scenarios where the data exist within Sa

Quick Tips: Setup SFDX Manually without Admin access

We all have faced challenges while working in different enterprise environments, where there may be lot of controls/ checks/ red-tape to get by. In such situations, getting access to simple tools (even git) can take lot of time. Note: This tutorial is to be followed at your own risk, as it may not be complaint to your organization's IT policies. What is SFDX? SFDX is a command line utility for managing salesforce builds/ deployments. Being command line, it can be easily embedded to automation chains, to help build fully automated build and deployment processes. To get started, refer Setup SFDX on Windows machine without admin access As you may have already realized, SFDX installation needs admin access to one's machine. Which may be a luxury a lot of developers may not have. So, i tried to provide a step-by-step guide to setup SFDX on your computer without any admin access Steps: Note: