Come Check out Managing Application State with SPA’s at TDX18

I am very honored to be participating as a panelist asking questions about Managing Application State with SPA’s. The session will be on Thursday, March 29, 2018 from 1-3:00 pm and is titled, “The Extracurricular: “Why Did That Do That?” Managing Application State w/ SPAs”.

It is a really cool format and one I think will be very fun and interactive (with lots of audience participation), so if you have any interest in this topic, I highly encourage you to attend. The main speaker is the incredible Matt Lacey and he will be talking about the challenges he has faced building a Visualforce application that used VF Remoting and React + Redux to manage application state.

The best part of this is it is not just your typical session in which the speaker just tells you a bunch of stuff and shows a bunch of boring slides. Not, this one is special. It will involve Matt briefly telling and showing us his app and then the rest of the time will be a very interactive discussion about managing application state that will involve not only the panelists and myself, but you the audience member as well. How super cool is that?

Ok, so if you are going to TDX18 and have some time on Thursday, please stop by.

And also be sure to check out Camp Quick Start  (that is where I will be most of the time), as well as the new and incredibly fun Robotics Ridge.

See you there…

Top 5 Tips for Improving Visualforce Pages

#1 – Reduce or eliminate view state   top5

View State is not your friend when it comes to page performance, so if you do not need it (as in your page does need to persist data between page requests), then do not use it at all. This is especially true for pages that will run on the Salesforce1 mobile platform!!!

How do you not use it all?

Do not include the <apex:form> tag unless you absolutely have to. This tag should only be used when you are accepting input from the user, so if you are only displaying data to the user, you should not have a form tag.

Like this Post? Then you will really like the “Improving Visualforce Performance” course that I designed for It was based on this post specifically and goes into great detail about each one of the tips in this post. Check it out!

And, even if you are accepting input, it is likely that not all the data on your page needs to be submitted through a POST request. For example, you could have a page that lists some account data, but only allows the user to change one particular field. In cases such as these, you could use the Transient keyword in the Controller class to make all the data fields (and especially collections) that are not being changed read-only. This means they will not be stored in the view state and your page will load faster.

You should also consider using JavaScript Remoting to avoid View State state by invoking the Apex Controller or Extension from JavaScript instead. This puts more load on the front-end and typically results in more code, but for certain pages that demand fast performance (especially those on the Salesforce1 mobile platform), this may be a necessary tradeoff to consider. But, if you do decide to go this route, make sure you use very efficient JavaScript code, so you do not violate Tip #5.

#2 – Evaluate SOQL for Efficiency

There are several ways you can write better SOQL code. For starters, ALWAYS make sure you place SOQL queries outside of loops. This should be done no matter what. It will not only make your page perform better, but will help avoid limit errors and should be standard practice. This also applies to DML.

Beyond that essential tip, you should also consider:

  • Only return fields that you are using on the page
  • Use WHERE clauses as much as possible to restrict the number of records returned
  • Use indexed fields in your WHERE clause as it will make the query optimizer work better. Default indexed fields are Id, Name, Owner, LastModifiedDate, and any foreign key or ExternalID fields.
  • Use the LIMIT keyword when possible
  • Use aggregation functions such as COUNT()
  • Use the WITH SHARING keyword in your controllers since the sharing architecture is used by the Query Optimizer and you will only retrieve the records that the users has access to
  • Additional suggestions (per reader JSON Hammerle) are to:
    • Use native (more selective indices) when possible
    • Hash your composite key (if you have one) into the native name field and use this hash in your WHERE clause This is comparable to a skinny table but you don’t have to work with support – and it can be delivered in a managed package.
    • Order your WHERE clause from most selective to least

#3 – Reduce use of Action tags

This kind of goes with tip #1, but since it is so important, I wanted to make it a separate point. Action tags such as <apex:ActionPoller> and <apex:ActionFunction> seem great on the surface since they are VERY easy to use, but they are memory hogs, so limit your use of them and consider alternatives.

Rather than using the ActionPoller tag, you should consider using the Streaming API. It means more code for you, but it results in no view state (remember tip #1). If you do not like the Streaming API, then consider using traditional polling using a Meta tag with a refresh and a window.location.reload.

Rather than using the ActionFunction, ActionSupport, ActionRegion tags, use Visualforce Remoting which uses no view state. Like I said earlier, it results in more code and complexity for you, but for certain pages this may be necessary. Again though, make sure you incorporate efficient JavaScript. Do NOT just copy and paste the first JavaScript snippet you find by doing a Google search.

#4 – Take Advantage of StandardSetControllers when dealing with lists of data

StandardSetControllers, which are used to create list controllers are your friends and you should use them whenever possible. The StandardSetControllers are optimized to work with large data sets of up to 10,000 records and include pagination features (which you should be using) automatically. There is no need for you to do this yourself.

When you do use them, instantiate them using a list of sObjects instead of from a query locator, as this is a more efficient way.

#5 – Incorporate Best Practices with all JavaScript, CSS and Images

No Visualforce page will perform well if it includes poorly used or inefficient HTML technologies. Make sure you incorporate best practices when including things such as Javascript, CSS and images. Things such as this:

  • Remember less is more and smaller is better.
  • Files should be minified and use Static Resources
  • Avoid using global variables
  • Place Javascript at the bottom of the page when possible and use the <script> tag and not <apex:includeScript>
  • Use browser caching when you can
  • Avoid use of iframes

There are tons of documents out there about best practices. Two of my favorites are:




Considerations when using Javascript in Visualforce

As part of my research for the new course I am doing on Visualforce, I have been going through posts on the Salesforce forums. I ran across this one in which the poster was asking what was the best way to select multiple checkboxes on a Visualforce page when a “Check All” checkbox was selected.

The best answer that was chosen was a recommendation by someone to use the ActionSupport component. The accepted responder even provided sample code. While the response was technically correct, I did not think it was the best solution. The reason I say this is because if you execute the sample code provided, you will note that there is a significant delay between the time you select the “Check All” checkbox and the time the other checkboxes are selected.

What causes the delay?

The ActionSupport component, which adds AJAX support to another component, allows that component to be refreshed asynchronously. While you might first think, “Asynchronous, that executes on the client and that is good and fast, right?”, that is not really the case. You see, when you use ActionSupport, or ActionFunction, or any of the action tags, you are essentially invoking server-side logic that is contained in your controller. This means that the AJAX request includes the pages view state and this can affect performance, as it did in the very simple example from this post.

So why use these controls?

Well, they are much easier to use than some of the other alternatives (which you can read more about here) and typically result in less code. But, if you are a good software developer, then you should not just blindly accept the path of least resistance. The other alternatives (namely Visualforce Remoting) will certainly perform better, but then they do require more code to be written. There is always a trade off, you see.

So, what is the best solution for this problem?

Well, I know you are going to be annoyed when I say this, but the answer is, “it depends”.

You could say the best alternative is one that was suggested by another responder on this post. That responders suggestion to use client-side JSJavascript (such as is provided in this post) was not accepted as the solution, but if you execute the code provided it does execute extremely fast. The difference in performance between the two suggestions is day and night (IMHO). But, this requires you to write and maintain the extra Javascript code.

If you are just sold on the whole, “it is better to use the built-in Action components provided by Visualforce because they simplify the code”, then you might want to consider adding an ActionStatus component right below the ActionSupport component. This is used to provide a message to the user telling them when the process starts and ends. That would prevent the user from just sitting there dumfounded for 1 – 3 seconds while the code was executing.

You might also want to consider using some of the other Javascript alternatives suggested in this excellent Developer Relations post on Using Javascript with

You see, it really all depends on what you are trying to accomplish and what skills you already have. If you are blessed to have the time to consider other options, then I suggest you do so. There are often many ways to accomplish the same thing and rarely is one way always the best way.