SalesforceSummaries: a series delivering key insights from Salesforce YouTube videos, to save you time as you keep up to date with the latest technological changes within the Salesforce ecosystem.
Introduction:
As per the ‘Migrating from Visualforce pages to Lightning’ summary, although Lightning Experience is the future, a significant amount of customers are still on Salesforce Classic and will continue to use Visualforce pages for providing a more customised UI experience to users. Therefore, understanding about how Salesforce developers can deliver efficient Visualforce pages remains a very important topic.
This article summarises the very comprehensive ‘Building Efficient Visualforce Pages’ tutorial from the Dreamforce YouTubechannel. You will learn how to best improve the speed of Visualforce pages by reducing the view state as much as possible.
https://youtu.be/D2dAk99Yxvs
Details:
Video: ‘Building Efficient Visualforce Pages’
Presenter: Steve Bobrowski, Markus Spohn
Date: November 25th 2013
Time: 45 minutes
Key terms: Visualforce, View State, Force.com Query Optimiser
Key points:
- To design memory efficient Visualforce pages, one needs to build database efficient Visualforce pages, design efficient controller logic and make efficient design choices.
- More efficient Visualforce pages mean happy customers, as a faster user experience is delivered.
- The Streaming API can be leveraged to update Visualforce pages in real-time in a very efficient manner, compared to traditional polling via the actionPoller tag which is less efficient.
Summary:
- @3: The 2 most common things which impede Visualforce page performance is high memory on the page and how the page accesses the database
- @6: The view state is something that Visualforce automatically maintains as soon as you use an component on the page. The tag is used when requesting input from the user.
- @6.20: The max view state of a Visualforce page is 135kb. If your page exceed this limit, the user will receive a ‘maximum view state size limit (135KB) exceeded‘ error on the page.
- @6.25: The view state is very helpful because the inputs are saved on the page. Let’s say there’s a validation rule on the sObject that is referenced in the controller and the user inputs data into the fields and selects the commandButton, the server would come back with any errors and post these back to the browser (client).
- @6.30: The Visualforce page uses the view state to rebuild the page so that no input data is lost. This way, the user doesn’t lose any data that have been populated in the .
- @6.50: The Visualforce page view state is encrypted and travels back and forth between client and server. Therefore, the lower the view state, the better as it results in a faster response time. This is especially true for mobile customers.
- @7.15: To view the view state on a page, enable ‘ Development Mode‘ on the user record and select the ‘View State in Development Mode’.
- @7.20: In the Development footer, you’ll see a third tab that shows the view state inspector. The view state enables you to see which component on the page is contributing to the view state size.
- @9.45: Minimize data, so as to ensure that your SOQL queries only have the fields that you absolutely need for the Visualforce page.
- @10.30: Analyze your controllers and ensure that you’re only querying the fields that your page requires. In the demo, this reduced the view state from 27kb to 4kb.
- @10.50: Use WHERE clauses to reduce the data set to reduce the view state further.
- @13.30: You can tell Visualforce to not maintain view state for data which should only be visible and not editable (so to all intents and purposes it is read-only data on the page). This can be achieved by using the transient key word in front of your collection or sObject variables.
- @14.30: Traditional polling, which typically leverages the actionPoller Visualforce tag, will always require view state as it requires an tag. However, is there a more benefical approach which we can adopt which doesn’t maintain a view state at all?
- @15: One can use the Streaming API in your Visualforce pages, which will enable you to push a notification to the browser (client) whenever a change has happened in the database. This notification is stored in JavaScript in the page, and this will refresh the browser.
- @15.40: Minimise your data (force the field list in SOQL queries, use WHERE clauses), use the transient keyword for read-only variables and consider alternative page designs which don’t use .
- @16.20: Visualforce pages are built for data-driven applications and so we want to ensure the database is not in a bottle neck. So it is critical to build database efficient Visualforce pages.
- @16.50: The key things to make database efficient Visualforce controllers is efficient SOQL and logic.
- @17.40: The com query optimiser won’t use an available index on a field if you use non optimisable operators. Negative operators go after a much larger dataset and so indexes won’t be used. Refer to developer.force.com/architect where these concepts are published.
- @19.40: The easiest way to optimise a SOQL would be to ‘flip’ it from NOT Closed to Open — meaning if there’s an index on this field, then it will be used in the query.
- @19.50: There are three steps to build a selective WHERE query: a) Optimisable operator b) The set of values you’re searching for are selected in the record set c) Ensure you have an index in place.
- @20.00: You will to work with the support team to add a custom index. There are standard fields already in the Salesforce schema, but if you’re using a custom field, you will need to create one yourself.
- @21.30: There are selectivity thresholds to consider when querying large datasets.
- @22.00: The sharing architecture is used by the query optimiser.
- @22.15: Public **with sharing **(‘sharing’ key word) can help to optimise the query further. For example, if you have a private sharing model, using the ‘with sharing’ keyword in your controller would reduce the data set for the Visualforce page further. So, you can take advantage of the sharing architecture for objects which have a private OWD.
- @23.30: To recap, execute efficient SOQL queries by using optimisable operators, filtering on selective field values, leverage indexed fields and leverage the sharing architecture when possible.
- @23.40: Use standard set controllers in your logic when possible as these are optimised for large data sets, they play nicely with list views and they provide robust paging capabilities.
- @23.50: A standard set controller enables ‘query more’; which works best with pagination as it queries once and keeps the curser in a cache. And when the next page is requested, instead of requerying, the next set of records is taken by incrementing the curser in the cache.
- @25.00: In your logic, ensure that you place DML and SOQL outside of loops. Make sure you use bulk processing principals when you can when creating custom controllers.
- @27.00: Long polling is a much more modern version of traditional polling. Whenver an update is received on the database, a push is sent to the page (so this is very impactful and efficient).
- @28.00: By using long polling via the Streaming API, you can update a page in real-time without the need of the tag (providing that user input isn’t required). Therefore, this reduces the view state and offers a very efficient page. This developer.salesforce article covers this extensively.
- @35.15: How can one scan a Salesforce environment and determine where a Visualforce’s page could be made more efficient? This can be achieved with the help of the MavensMate IDE.