I have a few visualforce pages that, together, make up a custom dashboard. The first page or "shell" page is just a HTML form that lets you select a client services rep and an optional client type selector. Clicking submit calls an AJAX load call (via jquery) to inject the second page body contents - which is a VF page with a list of accounts and some embedded data (in sub-queries).

The very first time you load the page, it can take up to 20-30 seconds...after that it takes about 2-3 seconds. This is regardless of which client rep I select and the number of accounts or amount of embedded sub-query data.

None of the pages use an apex:form (to eliminate viewstate tax). The issue arises only sporadically and only the first time a person loads the page.

When I used the Dev Console it shows a huge block of time where the DB transaction holds the page for like 19 seconds.

I'm wondering if anyone has seen a case where there is some delay or deferred processing because of the way the page is being called and injected. I can't for the life of me figure out what would cause such a huge delay on a query - it contains a number of sub-queries but I have a third page (predicated on this page) that loads even more data with more conditions and is never a problem. Given that the third page works fine I'm wondering if its an authentication or caching issue...but if that was the case, why would the Timeline blame the DB call (unless it's mistakenly identifying the hold up)? Stumped.

  • Interesting question, I was using jQuery.load() in a home page component yesterday and was seeing long load times, but only 3-4 seconds nothing like what you're seeing Nov 26, 2012 at 22:01
  • Have you tried executing the query independently, say in Workbench or via the Dev Console? If it takes a long time for independent execution, consider making one of the selector fields in the Where clause an External id, so it is indexed and more efficient to query on. Nov 26, 2012 at 22:13
  • 1
    Following up on @techtrekker I've had lots of issues over the years with subqueries, such as timeouts, strange and inaccurate error messages, or just slow responses. If possible I avoid them, particularly if the subquery will return more than a trivial (<100) records. Hard to say if that's your issue, but could be related. Nov 27, 2012 at 4:12
  • Also, if you're trying to benchmark the queries, be careful. Result caching means that if you do multiple tests only the various first query will represent the slowest speed and the second ones can be sped up. Nov 27, 2012 at 4:13
  • 1
    I think you need to optimize your SOQL-Query. We has the same problem - the query took up to 40 secs because of a large amount of data. After optimization it took 'only' about 5 secs. Nov 29, 2012 at 8:41

1 Answer 1


Since no one has posted an answer I'll have a go.

As you suggest, the problem probably isn't the injection of the second page, but the DB call.

There are a number of things you can do to reduce time in the DB such as the obvious narrowing your query, and adding indexes by way of making any fields involved in WHERE clauses indexed by using the "External Id" checkbox in the field configs.

About a year ago, we've also added the ability to add custom indexes by contacting support. Custom indexes can be turned on in fields that didn't previously support indexing (even formula fields). Custom indexes even support a composite index of up to 2 fields.

There was a great blog post about this back in February that you might want to read about. http://blogs.developerforce.com/engineering/2013/02/force-com-soql-best-practices-nulls-and-formula-fields.html

  • 1
    Turned out it was a relatively small result set for the query but the initial tablescan needed to construct the possible query was resultset was very large. Optimization!
    – AJ D
    Aug 1, 2014 at 3:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .