You need to sign in to do that
Don't have an account?
Jeff Douglas (Personal)
Slow Page Loads?
There has been some concerns regarding the slow load times of Sites pages. I was wondering what the specific plans are to address this? Caching? Pre-compiling?
Thanks
Jeff Douglas
Informa Plc
http://blog.jeffdouglas.com
Vote for my Idea: Ehanced Apex Testing Functionality (JUnit)
Jeff,
Please check the best practices caching section. Force.com Sites is out of the box integrated with the market leader CDN partner. You will need to include the caching attributes to your page headers.
Keep in mind we do not cache any information for SSL and for authenticated sessions. Caching only applies to unauthenticated HTTP sessions.
All Answers
Jeff,
Please check the best practices caching section. Force.com Sites is out of the box integrated with the market leader CDN partner. You will need to include the caching attributes to your page headers.
Keep in mind we do not cache any information for SSL and for authenticated sessions. Caching only applies to unauthenticated HTTP sessions.
Pages with dynamic content can't be cached. Caching is not a solution to bad performance, it's band-aid guys, come on.
I'm often seeing really bad performance, and even images not appearing sometimes, the product seems pretty flaky.
Caching/CDN integration provides the following benefits:
1- your content will be cached on 50,000+ servers all around the world
2- end users would get the requested content from the closest location to their location
3- if the content is not cached or expired in cache then integration leverages the fastest route to the origin to refresh the cache, so that the next requester would get it from cache
4- you have the full control of how long the page would be cache by using the page cache attributes
and finally, sandbox and developer edition orgs are not integrated to the CDN, so you would see these benefits only for your production sites.
if you don't see the images on your site you need to check the static resource Cache control attribute. You need to set this attribute to "Public", otherwise they won't be rendered on your public page.
Bulent, I understand and appreciate the benefits of caching. My point is caching is not a complete solution for performance. If a page contains dynamic content/data from the CRM (which is likely to be the main people using Salesforce Sites) then caching must be turned off in most cases to ensure the content/data is current.
The problem I saw with the image wasn't a permissions issue, as the image worked sometimes and sometimes it did not. I sat pressing F5 and the image appeared sometimes, and not at others.
Performance is bad. I'm not sure we would be able to go live with Salesforce Sites in its current iteration, it's too slow. This will have an impact on end-users (they will be frustrated, they're likely to view less pages) and potentialy also SEO as some suggest Google favours faster sites.
There might be other factors on the performance such as how the object structure is created or SOQL queries, index existence or not.
I'll be happy to get on a all to explore the reason, we can run a test from your location see the performance
please send me an email at bcinarkaya@salesforce.com so we can schedule a call
After exchanging couple of emails the main issue turned out to be related to the referencing the static resources. 404 erros were slowing down the pages.
The "Delivering Static Resources with Visualforce" article is a good read if any one has any questions on this topic.
I'm curious as to the exact cause as I'd like to avoid this issue. I assume you may get a 404 if you reference a static resources that doesn't exists. What happens if you have a static resource that is a zip of files and you try to reference a file in this zip that does not exists?
Can both of these scenarios case performance degradation?
The primary performance issue for me was referencing resources directly using salesforce.com URLs (including an image stored under Documents), rather than static resources. Fixing that improved the performance noticably.
It did look from the perf measurements Bulent kindly sent me that the 404s were causing delays, but I'm sure he will confirm either way.
His other suggestion was to enable caching at every available opportunity, though one problem with this is when developing a page you can't see the changes until the cache contents expire which is why, for now at least, I have all caching turned off. When we go properly live, that will change for static-content pages.
yes, broken images/files will slow down the page load. For this reason we auto cache the static resources for a day (when you update them your pages pick up the latest version, no worries). For this reason, we recommend storing these files as static resource rather than relying on some other servers might have a slow response time.
i you want to test your pages with out cache (which we recommend testing in sandbox orgs -no caching- not on production), you can do the following two methods:
1- set page cache attribute to false. If not specified your page is cached for 10 minutes
2- use the secure url for testing. https://<name you registered>.secure.force.com. No caching for https access
and finally I recommend using firefox with firebug plug-in to check the network performance