为什么从 Google 的 AJAX 库 API 加载 JS 框架很重要？
我记得在某处读到，从 Google 的 AJAX 库 API 加载 JS 框架比使用本地托管的框架要好得多。
这意味着，而不是：
<script src="jquery.js"></script>
你从谷歌加载框架：
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
我认为优势主要在于缓存，但我不确定这一点。
有人可以向我解释为什么最好从 Google 加载框架而不是在本地托管它们吗？
I remember reading somewhere that it is a lot better to load a JS framework from Google's AJAX Libraries API, rather than using a locally hosted one.
This means that instead of :
<script src="jquery.js"></script>
You load the framework from Google:
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
I think that the advantage was mostly about caching but I'm not sure about it.
Can someone explain to me the reason exactly on why it is better to load frameworks from Google instead of hosting them locally ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
另一个网站很可能也会使用来自 Google 服务器的相同 js 文件，因此该文件已经被您的浏览器缓存，无需为您的网站再次下载。
查看 这篇文章还有其他一些好处。
There is a good chance another site will also be using the same js files from Google's servers, so the file will already be cached by your browser and it won't need to download it again for your site.
Check out this article for some of the other benefits as well.
让 Google 托管您的 javascript 库有利有弊。
优点：
：
根据我的经验，我在本地托管方面获得了出色的结果，因为我统一了 Google JQuery lib 和我的其他 javascript 代码，对其进行 gzip 压缩，并在统一的 javascript 文件中获得了很高的压缩率。这样，浏览器使用已经打开的连接来下载包含所有内容的“小”文件。
There are pros and cons to having Google host your javascript libs.
PROS:
CONS:
In my experience, I got excellent results in hosting locally because I unified Google's JQuery lib with my other javascript code, gzipped it and got great compression rates in the unified javascript file. This way, the browser uses an already opened connection to download a "tiny" file with everything on it.
首先，这意味着负载在 Google 的服务器上，而不是您自己的服务器上，这将节省您的服务器处理时间和带宽。其次，对于绝大多数互联网用户来说，谷歌的服务器很可能比你自己的服务器更快。
另外，从 Google 的角度来看，它可以让他们获得更多有关人们如何使用互联网及其 API 的数据。
ETA：此外，如果 Google 更新其 API，则意味着您将始终使用最新版本。这可能是好事，也可能不是好事（错误修复与向后兼容性）。
Firstly, it means the load is on Google's servers, rather than your own, which will save you both server processing time and bandwidth. Secondly, it's quite likely that Google's servers are faster than your own for the vast majority of internet users.
Plus, from Google's point of view, it lets them get more data about how people use the internet and their APIs.
ETA: Also, if Google update their APIs, it means you'll always be using the latest version. This may or may not be a good thing (bug fixes vs. back-compatibility).
这归结为足迹：Google 拥有一组分布式网络位置，从而确保向几乎所有地方提供低延迟传输。
因此，如果您能够尽可能多地通过 Google 提供服务，您的客户QoE（体验质量）将会提高。
客户关心这一点是因为他们获取网页的速度越快，完成的任务就越多。
客户关心这一点是因为他们获取
Google 关心这一点，因为客户访问网页的速度越快，他们每天可以提供的服务就越多，从而赚到的钱也就越多（当然来自广告）。
It comes down to footprint: Google has a distributed set of network locations thereby ensuring a low latency delivery to almost everywhere.
So, if you get to serve as much as possible from Google, your customers QoE (Quality of Experience) will improve.
Customers care about this because the faster they get their web page, the more than can get done.
Google cares about this because the faster customers get their web page, the more they can serve per day and thus the more money$ they make (from advertising of course).
为什么只有谷歌？ Microsoft 也推出了 CDN，这些天我链接到 MS CDN 而不是 Google 来获取 Jquery。
如果我将您的问题改写为“从 CDN 链接的优点是什么？”，我会这样回答。
就是这样。我想不出还有什么其他优点了。没有任何。没什么。零。
事实上，我可以想到一个缺点，即您对内容的控制力会稍差一些。
不要以为大公司会慷慨地出钱为您提供免费带宽。控制您的网站是他们的事。
Why only Google? Microsoft has launched a CDN too and these days I am linking to the MS CDN instead of Google to fetch Jquery.
If I rephrased your question to read 'What is the advantage of linking from a CDN?', I would answer it thus.
That's it. I can't think of any other advantage. None. Nada. Nil.
In fact I can think of a disadvantage that you are going to have slightly less control over your content.
Don't think that the big corps are being generous with their money giving you free bandwidth. Being in control of your website is their business.