function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
pabramspabrams 

VF Page embedded into Contact Layout causes performance problems - please approve my workaround

I have a Visualforce Page that I've embedded in the Contact Detail page layout. My VF Page is complex and I don't expect it to be fast (yet) and hoped that it wouldn't affect the outer page because SF is loading my page inside an iframe.

 

However, my embedded VF Page is causing severe performance problems on the Contact Detail page. The Contact page normally takes a half second to load, but with my VF Page embedded in it the load time increases to around 3 seconds, although the load time is highly variable. (I'm specifically measuring the HTTP response time.)

 

Furthermore, the inline editing features in Firefox are delayed until the iframe loads, which negatively impacts user efficiency. (The document ready events seem to come much earlier in Safari and IE, and this isn't a problem in those browsers.)

 

I've compared performance with a nearly empty VF Page, and found that the contents of the VF Page do indeed affect the outer Contact page. My guess is the Contact page is evaluating the embedded VF Page during the outer page load, which was surprising since I had assumed the reason SF uses iframes was to insulate the outer SF page from the customer VF Page

 

My current workaround/hack is to use a tiny "loader" VF Page that does not have a custom extension controller, Apex components, or much of anything at all, except a client-side redirect to my real VF Page. This speeds up the Contact page considerably, and so far seems like it will work out great. However, I'm a little uneasy building atop a hack, and I would like some SF blessing on this approach.

 

Cheers,

Paul

Best Answer chosen by Admin (Salesforce Developers) 
pabramspabrams
I’ve been testing another approach suggested by Andres Perez, which is to use multiple layers of outputPanels around my larger components, and then rendering the inner panels asynchronously. I had been doing almost exactly like this, but my inner layer had been a tabPanel, which caused all kinds of problems. So far the double outputPanel approach seems to work as well as the iframe, but feels like much less of a hack.

All Answers

mtbclimbermtbclimber
pabrams wrote: 

I've compared performance with a nearly empty VF Page, and found that the contents of the VF Page do indeed affect the outer Contact page. My guess is the Contact page is evaluating the embedded VF Page during the outer page load, which was surprising since I had assumed the reason SF uses iframes was to insulate the outer SF page from the customer VF Page

 

 

This is a performance optimization to get the entire markup for the page with all the pages/scontrols in one request with the subsequent iframe requests being "lighter" on the service.  The assumption under this design is that you want all inline elements as quickly as possible.  Here it seems that is not the case, your inline page can come in through a secondary phase.

 

pabrams wrote:

My current workaround/hack is to use a tiny "loader" VF Page that does not have a custom extension controller, Apex components, or much of anything at all, except a client-side redirect to my real VF Page. This speeds up the Contact page considerably, and so far seems like it will work out great. However, I'm a little uneasy building atop a hack, and I would like some SF blessing on this approach.

 

If the inlined Visualforce page is completely independent of the containing standard page then this should be fine. The only issue is that you are costing the organization an extra request to process this page.   The request limits of the service are generally very high but additional requests should only be added when there is no better option.

 

Another option is to create a button to call up the page only when needed. This way the extra trip only happens when the user needs your UI/information and not on every request with no choice in the matter.

 
pabramspabrams

Hi Andrew,

 

Thanks for looking into this and providing the explanations.

 

We do want our custom page to come up quickly, but the sales reps who beta-tested the app were extremely sensitive to any performance degradation in the Contact page. So our custom page needs to take whatever penalty is necessary to spare the outer page.

 

So far it looks like this trick has netted us a total end-to-end perceived performance boost. Is this possible or do we need to dig more deeply?

 

Cheers,

Paul
pabramspabrams
I’ve been testing another approach suggested by Andres Perez, which is to use multiple layers of outputPanels around my larger components, and then rendering the inner panels asynchronously. I had been doing almost exactly like this, but my inner layer had been a tabPanel, which caused all kinds of problems. So far the double outputPanel approach seems to work as well as the iframe, but feels like much less of a hack.
This was selected as the best answer