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

Lightning: Generate PDF within Lightning Experience with Salesforce Data

Some time back I posted a solution to generate PDF from Lightning components using in-memory data. Post url: It was developed for a specific scenario, wherein we need to generate PDF where: User interface is Salesforce classic Initiated via Lightning Component Data doesn't exist within Salesforce and is completely in-memory As complex and tricky this situation was, we did end up finding a stable and equally tricky solution. However, I realize that there are still lack of solutions (or maybe my search skills are downgrading) to generate and automatically download PDF document from Lightning Experience, without using any lightning components, wherein data exists within Salesforce. You can use the earlier solution in that case, but it will be an overkill. There are various solutions available to generate PDF from javascript. But, I still think the plain old method of converting HTML to PDF (via