In addition to the recommendations and guidelines published in the Force.com Sites Implementation Guide, salesforce.com recommends that you follow these practices to get the best experience out of Force.com Sites:
Salesforce.com recommends setting the sharing to private for the objects on which you grant "Read" access for your Force.com site. This ensures that users accessing your site can view and edit only the data related to your site.
Salesforce.com also recommends securing the visibility of all list views. Set the visibility of your list views to Visible to certain groups of users, and specify the groups to share to. List views whose visibility is set to Visible to all users may be visible to public users of your Force.com site. To share a list view with public users, create a new public group for those users and give them visibility. If the object's sharing is set to private, public users will not be able to see those records, regardless of list view visibility.
Set cache control on Static Resources to Public. Any static resource - for example, favorite icons, stylesheets, images, etc - you want to expose to your site must be set to public. Remember: static resources are auto-cached for a period of 1 day. So, changes will be reflected on your site one day after you make them.
Carefully manage the pages exposed to your site. If you select a Visualforce page for any of the lookup fields on the Site Detail page, any of the error pages, or the Change Password Page under login settings, that page is automatically enabled for your site. If you remove a page from your site, but it is still selected in one of these places, public users can access that page. To completely remove pages from your site, disable them on your site AND make sure they are not selected in any lookup fields for your site.
Generally speaking, take care to expose only the information you DO want to make public.
Allow sufficient time in project plans for thorough testing. Insufficient testing time can introduce significant risk to the success of your projects.
Be sure to include testing of your site across multiple browser platforms and versions. It is reported that some 10% of internet users still use Internet Explorer 6. So, be sure to test a wide variety of platforms to make sure visitors to your site have a positive experience.
Salesforce.com recommends that you use a Developer Sandbox environment to build and test your sites prior to deploying to production. When you are ready to deploy, you will need to manually re-create your site on production. However, all of the supporting assets, e.g., Visualforce Pages, Apex Classes, and Static Resources, can be deployed to production with the Force.com IDE, using the Force.com Migration Tool, or the Force.com Metadata API call deploy.
Force.com Sites imposes two daily limits, i.e., 24 hour rolling limits. These limits depend on the organization type as follows:
|Organization Type||Bandwidth Limit (per day)||Service Request Time (per day)|
|Developer Edition||500 MB||10 minutes|
|Sandbox||1 GB||30 minutes|
|Production||40 GB||60 hours|
The limits govern
When a site reaches one of these limits the site will display the Limit Exceeded error page. Even though these limits are set very high for active orgs, high traffic or pages requiring heavy bandwidth or long processing time may cause a site to reach one of these limits within a given 24 hour period. However, you can virtually increase these limits by leveraging the caching functionalities provided for you. Force.com Sites seamlessly integrates with one of the leading Content Delivery Network (CDN) vendors to allow you to cache your pages all around the world for a duration that you can set. CDN integration not only improves your global reach (more than 40,000 servers all around the world) but it also provides your customers satisfaction by serving content to your end users from the closest location to them.
You can simply decide which pages will be cached and for how long. When a page in cache expires, the CDN system will retrieve the latest version of the page from your organization via the fastest route by leveraging its special traffic optimization logic. To enable a Visualforce page for caching, use the following page declaration:
<apex:page cache="true" expires="600">
The following table explains the cache related parameters and the default system behavior:
|cache||A Boolean value that specifies whether the browser should cache this page. If set to true, the browser caches the page. If not specified, this value defaults to false.|
|expires||An Integer value that specifies the period of cache in seconds.|
By default, caching is set to false so each request counts against request time limit and bandwidth limit.
In order to use static resource on public sites you need to set the Static Resource “Cache Control” attribute to “Public”. Public static resources are auto-cached for a period of one day. However, when you update a static resource the URL for the static resource will have a new time stamp so the new version will be picked up and cached automatically.
Proper schema design is one of the key factors on performance of high traffic Web sites.
Salesforce.com recommends that you
Additionally, Salesforce.com recommends that you consider storing large audio and video files you want to access on your public sites on a 3rd-party system to avoid daily bandwidth limit restrictions.
Be mindful of governor limits for Apex classes associated with your public sites. An Apex class confined to an internal application may experience considerably less load than one exposed on a public Web site. Test your code thoroughly and with realistic numbers of records and queries to make sure it does not exceed any of the limits.
Limit query results and avoid the use of count queries to keep your Apex scripts within limits.
You may want to employ governor limit email warnings for your site to get a warning any time an end-user invokes an Apex script that surpasses more than 50% of any governor limit. To enable email warnings:
Salesforce.com recommends that you use CAPTCHA for public form submissions to avoid spam. The code sample is available on the Developer Community.
You can map your standard company URL to your Force.com Sites Domain Name with a 3rd-party domain name registrar.
Use the Custom Web Address field to set the alias to your Force.com address.
To enable a custom Web address, create a CNAME record with a registrar like Network Solutions or Go Daddy. The CNAME record that you provide to that registrar must be your Force.com domain name and not the site URL. For example, if you entered "mycompany" when registering your Force.com domain, the CNAME must be mycompany.force.com, not the full value of the site URL.
If you have not registered this address with a registrar, entering a value in the Custom Web Address field has no effect.
Because Force.com Sites are directly served from customers’ Salesforce organization, Force.com Sites availability is directly related to their Salesforce org’s availability and up time. For all major releases, customers’ Salesforce orgs and Force.com Sites will be unavailable during the org’s release maintenance window. During the maintenance window, Sites end users will see a Force.com branded maintenance page when they try to access the site via HTTP.
You should work with your customer to ensure they have a communication strategy for informing end users, as well as any other Salesforce stakeholders, of the release maintenance windows and related Force.com Sites unavailability.
Visit http://trust.salesforce.com/trust/status/#maint to understand the specific maintenance windows by instance.