function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Huge Custom sForce Control - Load Time Problems

We decided to build a highly customized AJAX front-end to our Leads data, which we renamed to Inquiries. The reason was that we have about 180 custom fields and the built-in UI would have been a pain to work with and train my users on. Coming from a custom development background, I really had a very specific UI in mind and wanted certain fields to always be present on the screen rather than scrolling away.

We opted for an AJAX methodology so that we could eliminate the need for a submit button, create some auto-save and onunload() save functionality, and update certain fields based upon other field selections. Dependent picklists would not have given us enough flexibility.

So we rolled out this massive sforce control last week and the biggest problem we are having is load time. It takes a few seconds for Salesforce to load the control and display it to the browser (we have optimized for Firefox) and then it can take anywhere between 4 and 10 seconds to load all the necessary data. When this is done on a typical user's computer, it can take 15 seconds or more before they can begin interacting with the data.

Here is a link to the code. If you have any suggestions of ways to speed it up, please let me know or post it here. I appreciate any insight that any of you could give. My user's are pulling their hair out waiting to edit a "Lead" or create a new one. It is a call center for drug and alcohol treatment and we handle tons of calls per day.

AJAX Toolkit Beta 2

Funny... I am also working on a large Ajax front end and we seem to have writen some of the same utility functions. But, putting that aside...

I just took a quick look, but one question leaped to mind.

Why are you making all these multiple calls to sforceClient.init()? I make one call followed by a Login() (so I can develop externally) as one of the first things in my execution and just use that sforceClient handle for the rest of the call. You're calling init() many times for data loading. I wonder if that's impacting your startup times.

My load times are faster, but then again I'm not loading as much data at startup time as you are, I only have a few queries and picklists to initialize. Still, you might try removing all the init() calls but one and see what happens? Or perhaps I'm missing something... :-)

Best, Steve.
Ron HessRon Hess
good catch Steve, one init is all you need, from then on you can use the object for multiple queries.

also, ( without looking at the code) i can suggest fetching some of the data first, drawing it, then setting a timeout.
the timeout allows the browser to draw the data, could be the top of the page and then when the timer fires, you fetch the rest of the data, perhaps on a scroll down.

it's not faster, just feels like it and the user can begin to read / interact the first data that appears.
Thanks for your input. I commented out the extra init calls so that there is only one. Unfortunately I am not seeing any increase in load speed. I also updated to the beta3.3 toolkit and made the changes posted previously.

It seems to still take 4 or 5 seconds before the sforce control is loaded into the browser. Is this an overall Sforce or API problem? I guess we will need to look into Ron's suggestion of breaking the load into multiple steps so the user can begin working while other data loads in the background. I am still running 10 to 20 seconds, with the average being 17 seconds before the page is usable. Some users have seen 50, 60 and even hundreds of seconds. What could cause these types of extreme delays?

Our last resort is building a separate VB application or externally hosted AJAX form which will speak to the API. Would this buy us anything?

Ron HessRon Hess
i'd remove those extra files, function.js,steup.js unless you really use them ,
also the AJAX toolkit has a set of timing / profiling calls, you could probably instrument the startup times.
i havent used those functions, yet.
Thanks Ron. Along those same lines, we are looking at streamlining all the Javascript includes, including the toolkit itself. We are not using most of the functions, many appear to still be in testing (prototype?). I am curious what people think about the potential performance increase we might see by only including the key functions from the toolkit at the top of our S-Control (pasting it all into one file)? Might we see a faster load time? I have done this with our CSS as well and even though the function errors out currently, the form displays much faster.
Ron HessRon Hess
each link src=... is another network request and read, aka:round-trip, so if you have any sort of network performance issues you may see a significant improvement from inlining your code into one file, time it and see. Reducing the number of images may help.
Thanks Ron. Actually we don't have any images at all, just the AJAX Toolkit and an external CSS file. We removed the extra function includes, as you recommended, but it did not make a significant difference. I even tried pasting the entire AJAX 3.3 toolkit into the top of my sforce control but I got a BAD LINK error, which I suspect has something to do with exceeding the char limit on sforce controls?

As another test, we commented out most of our var assignment and loadLead() functions so that we only process the fields shown on the first page of our form (we have 6 or 7 separate divs that load dynamically from links). This also made no difference in load time!

So I keep coming back to the API. I am working with SF support to evaluate the load time and see if there are any backend improvements we can make. Ultimately we might need to create our own streamlined AJAX toolkit.