Take the 2-minute tour ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

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?

share|improve this question

3 Answers 3

up vote 9 down vote accepted

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.
share|improve this answer
1  
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 Jan 20 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 Jan 20 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 Jan 23 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.

share|improve this answer

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.