Streaming jquery(JS files) from a CDN (Google)

2019-01-26 17:29发布

问题:

This one is a case of not doing your homework.:-)

Apart from dynamic loading advantage, does it make sense to include a JavaScript library(jQuery in my case ) from a Google server when I can load it from my server as a single file comprised of the 19kb jQuery zip file + the additional JavaScript code I have written – all compressed with a JS compressor and served HTTP deflated.

With Google server I’ll have 2(parallel) HTTP round trips. One to get the jquery file and the other to get the site JavaScript code. One 19kb and the other say 20-25kb. Under normal circumstances it would be a single 30-35kb download from my site.

回答1:

Consider that a jQuery script downloaded from the google CDN might well already be cached on a visitor's browser, since it has consistent headers and cache control no matter where it is downloaded from. Hence, on average most users will only have to download your site-specific javascript scripts. Also, CDN generally have faster response times than single servers, since they respond from a server nearest to your location.

There is no cut and dry answer to your question, as both approaches offer good performance on modern connections. You should profile your system under duress and see what solution offers the best results (and if such optimization is even needed).



回答2:

Are you sure scripts would be downloaded in parallel? This example from Cuzillion seems to be saying that only IE8 can do that.

Also worth finding out is how many of your pageviews are first time visitors and how many have visited the site before to help you decide how much caching will influence download time. If you have a significant number of first time visitors it's probably worth skewing it in their favour to make the first time experience as fast as possible.



回答3:

A benchmark test done by httpwatch for js files from google.

http://blog.httpwatch.com/2008/11/27/google-adds-https-support-to-the-ajax-libraries-api/



回答4:

Is this a real question? Just make sure your Cache-Control in your HTTP headers are properly configured and the end user's client will only pull it once. This is an absolutely trivial amount of data.



回答5:

In my opinion, there isn't any real downside to using a well-known jQuery CDN (such as Google's), and there are some potential upsides, so my personal preference is to take the CDN approach. If nothing else, that's one less file for me to have to worry about and maintain as part of my source tree.

There are several advantages I see to using a CDN vs. a single fat JavaScript archive:

  • Reducing latency for retrieving uncached resources, since these assets are served from edge locations
  • For 3rd-party scripts, the user's browser probably already has them cached and won't have to download them again for your site.
  • Working around per-host browser limitations for parallel requests, by distributing your assets across multiple hostnames (of course, this can also be done via your own servers using simple subdomain tricks).
  • Reducing overall load on your primary servers, esp. important during peak usage periods or YC/Slashdot "attacks".

When to care about download time for HTML page assets:

  • When you have a significant number of first-time visitors (from search engines and/or social media). Research shows that people aren't very patient these days, so you really need to go out of your way to make a good first impression. (See also Jakob Nielsen's articles on Page Abandonment, Answer Engines and Response Times.)
  • For visitors using mobile devices. Mobile data networks are often slow and/or congested.
  • For shops practicing continuous delivery and causing frequent churn in assets (more common for brand-new sites and apps)

P.S. - Aaron Hopkins has one of the best write-ups on optimizing page load time I've seen. A bit dated, but still quite relevant.

P.S.S. - You might want to take a look at Zepto, a light-weight (24K vs 100K), api-compatible alternative to jQuery.