I’ve been on the road for many of the weeks after Dreamforce ’11, but one of the things that I keep noticing is that I’ll reference a YouTube video for a particular topic after having a conversation with a developer.  They’re a brilliant way to get expert information and you can pull them up in a browser tab, put on the old headphones and switch back to the content to keep an eye on slides.

One of the sessions I highly recommend Visualforce developers to check out is Stephan Morais’ Blazing Fast Visualforce Pages.  Stephan was, right up until Dreamforce ’11 itself, Product Manager for Visualforce and obviously has a deep understanding of the underpinnings that makes the framework tick and watching this video will make concepts like the viewstate more than merely an abstract factor in your development.

A few points from the session:

Watch your viewstate

Developers are often unaware of the viewstate that is being generated on their pages.  If you are one of those developers, it might be a good idea to bring up any random Visualforce page with a form in it, view the HTML source and scroll down to the bottom.  You’ll see a section with a large string of seemingly random characters.  That is the viewstate of the page and serves as a blueprint of sorts to allow robust and stable communication between the client and the server.  When you perform actions like rerender – the viewstate is the guide that makes a lot of that magic work.  For that reason, the viewstate is a good thing – it is a powerful tool for web development.  But the viewstate is also part of the messaging with your HTTP transactions and if your viewstate gets out of control, it can effect the overall performance of your user interface.

Avoid multiple forms

Multiple forms require multiple viewstates and there will be a lot of efficiency lost when needed to put more than one viewstate on the page.  In nearly every situation, only one form should be necessary to communicate back to the page.  There may be some refactoring required with your component architecture to pull this off, but the payoff can be tremendous on complicated pages.  Stephan goes through a lot of great example of streamlining your design in general to make your page blaze.

Filter your SOQL correctly

The data you are pulling in Apex should match what you need on Visualforce.  Data you send down to the client the client doesn’t need is just fattening up that old viewstate with no benefit to your application.  Chris Wall, an engineer on the Visualforce team that held the “Intro to Visualforce” session called this “don’t back up your data dump truckt to the application”.  Less data, less viewstate, faster application.

Use transient variables

Transient is a keyword you can use in Apex to distinct a variable which doesn’t need to be saved and hence does not need to be part of the viewstate created for Visualforce.  That many developers are unaware of transient is probably one of the leading causes of viewstates which are larger than they need to be.  My recommendation is to read the documentation, go through some of the examples in a developer edition instance and then try refactoring a few pages of your own.

And now, the show:

I can’t possibly do justice to all the tips and tricks Stephan goes through – the above is just a few key callouts.  Here’s the whole session for your learning goodness:

Enjoy.  As always you can leave your comments in the section below or catch me on twitter @joshbirk.

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS