I maintain a product on the AppExchange that currently references both JQuery and custom JavaScript that are included in a static resource. Now that I am making some additional updates to the package, I am thinking that it would be easier to manage the scripts on the server rather than adding them to the package.

Is this a dealer's choice type of situation, or are there specific advantages or disadvantages of linking directly to external JavaScript files versus adding the scripts to static resources?

3 Answers 3


I suspect that the benefits of static resource are:

  1. Salesforce should auto-cache requests for static resources
  2. If the CDN you reference the external JS file from happens to go down for whatever reason, you aren't reliant on it.
  • 2
    Zoompf has something to say about it; basically, using a JS CDN external to your site only benefits if all major sites are using it. Since only very few are, most likely you'll suffer an extra cache miss anyways, so there's no performance benefit to using an external CDN (plus, the cost of extra TCP/IP connections, DNS lookups, etc). Many others also advocate avoiding linking to a public JS CDN instead of using a local copy.
    – sfdcfox
    Commented Jan 20, 2014 at 21:20
  • Also, salesforce.com uses a very long cache time to ensure that the file will remain in cache nearly indefinitely until the user deletes their cache or the developer uploads a new version. It does this with a combination of a very long expiry time plus a random number URL to force cache miss/updates.
    – sfdcfox
    Commented Jan 20, 2014 at 21:21
  • As a note, static resources are delivered via CDN to sites users and can be cached for performance for internal Salesforce users by setting the resource to be public.
    – pbattisson
    Commented Jan 23, 2014 at 7:32

Your custom JavaScript should definitely be stored in salesforce.com to avoid extra TCP/IP connections, DNS lookups, and avoiding the possibility of a partial network failure from affecting your AppExchange app's performance.

Your standard jQuery should probably be stored in salesforce.com for the same general reasons as above, plus you'll benefit from code stability (so you don't accidentally use an auto-upgrade url and suffer cache misses, etc). Also consider that browsers use pipelining, so having both scripts on the same CDN results in better performance anyways. Plus, if they eventually upgrade to the SPDY protocol, you'll enjoy even more benefits on speed.


With everything offered by the platform (content distribution, caching and cache invalidation, major and minor and patch versioning, package encapsulation as the single source of truth) there's no tangible advantage to linking external JavaScript files.

In fact, you run the risk of excitable auditor types noting that you're loading JavaScript from offsite.

What's the upside? Not worth breaking your package encapsulation IMHO. With static resources:

  • what you see in your packaging org is what the customer gets,

  • you avoid loading third-party JavaScript from cross-domain sources you don't control,

  • can zip them up avoid resource proliferation {!URLFOR($Resource.MyZip, '/jquery.js')}

  • Salesforce is an application platform, not a brochure site - nobody's gonna smack you for 300ms

You must log in to answer this question.

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