您从哪里包括jQuery库?Google JSAPI?CDN?


242

包括jQuery和jQuery UI的方法有几种,我想知道人们在使用什么?

  • 谷歌JSAPI
  • jQuery的网站
  • 您自己的站点/服务器
  • 另一个CDN

我最近一直在使用Google JSAPI,但是发现建立SSL连接甚至解决google.com都花费很长时间。我一直在为Google使用以下工具:

<script src="https://www.google.com/jsapi"></script>
<script>
google.load('jquery', '1.3.1');
</script>

我喜欢使用Google的想法,以便在访问其他站点时将其缓存并节省我们服务器的带宽,但是如果它一直是站点的慢速部分,我可能会更改包含。

你用什么?你有什么问题吗?

编辑:刚刚访问jQuery的站点,他们使用以下方法:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js"></script>

Edit2:这是去年我一直没有任何问题地包含jQuery的方式:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js"></script>

区别在于删除http:。通过删除此选项,您无需担心在http和https之间切换。


8
达里尔,很棒的编辑。可能我建议您将编辑移至页面顶部,然后将更src改为现在使用的更简单/安全/更快的语法?您的答案已基本成为规范,这两种更改都将帮助人们快速获得所需的东西。
乔什·史密斯

Answers:


153

毫无疑问,我选择让Google API服务器提供JQuery。我没有使用jsapi方法,因为我没有利用任何其他Google API,但是如果发生了变化,我会考虑使用它。

第一: Google api服务器分布在世界各地,而不是我的单个服务器位置:服务器越近,通常意味着访问者的响应时间越短。

第二:许多人选择将JQuery托管在Google上,因此,当访问者访问我的网站时,他们可能已经在其本地缓存中包含了JQuery脚本。预先缓存的内容通常意味着访问者的加载时间更快。

第三:我的网络托管公司向我收取使用的带宽。如果访问者可以在其他地方获得相同的文件,则每个用户会话消耗18k毫无意义。

我了解到,我对Google表示信任,以提供正确的脚本文件并可以在线使用。到目前为止,我对使用Google并没有感到失望,并且会继续进行此配置,直到没有必要为止。

需要指出的一件事...如果您的网站上同时存在安全页面和不安全页面,则可能需要动态更改Google源,以避免在安全页面中加载不安全内容时看到的通常警告:

这是我想出的:

<script type="text/javascript">
    document.write([
        "\<script src='",
        ("https:" == document.location.protocol) ? "https://" : "http://",
        "ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>" 
    ].join(''));
</script>

2010年9月8日更新 -已提出一些建议,以通过删除HTTP和HTTPS并仅使用以下语法来降低代码的复杂性:

<script type="text/javascript">
    document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>");
</script>

另外,如果您要确保已加载最新的Major版本的jQuery库,也可以更改url以反映jQuery主编号:

<script type="text/javascript">
    document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js' type='text/javascript'>\<\/script>");
</script>

最后,如果您不想使用Google而希望使用jQuery,则可以使用以下源路径(请注意jQuery不支持SSL连接):

<script type="text/javascript">
    document.write("\<script src='http://code.jquery.com/jquery-latest.min.js' type='text/javascript'>\<\/script>");
</script>

26
我同意您的所有三个理由,这就是为什么我将Google的jquery包含在生产站点中的原因。代替了SSL页面的js动态注入,我只是在未指定协议的脚本标记中引用url。似乎对我来说很好。<script src =“ // ajax.google ...”> </ script>
亚伦·瓦格纳

1
有趣的主意...但是,如果您要使用DNS中毒来劫持JQuery负载,为什么不劫持整个站点请求呢?还是Google Analytics(分析)脚本呢?
Dscoduc

9
我也同意所有内容,但为了简化起见,我使用以下格式:<script src =“ // ajax.google ...”> </ script>。然后,我不必担心http或https。Thxs亚伦·瓦格纳(Aaron Wagner)。
Darryl Hein

11
我看不到document.write()正在使用什么?一个简单的<script src="..."></script>就可以放在标题中。 →@ Dscoduc:←不会更快,只会删除警告消息。如果您的网站使用的是安全的https,并且您正在从非编码内容(例如http://googleapis)中提取信息,那么您将收到该警告消息。如果仅使用http但要链接到https://googleapis,将会更快一些,“安全”编码会产生一些开销。因此,链接到http://googleapis会更快一些。
vol7ron

5
另外请记住,Google随后将使用它来跟踪用户访问的网站。因此,如果您要创建一个需要保护隐私的网站,则托管几个小文件对于支付隐私而言是很小的代价。
Hans-Christoph Steiner 2014年

19

您可能希望托管在外部服务器上的原因之一是要解决浏览器与特定服务器并发连接的限制。

但是,鉴于您正在使用的jQuery文件可能不会经常更改,因此浏览器缓存将启动并在很大程度上解决该问题。

将其托管在外部服务器上的第二个原因是降低到您自己服务器的流量。

但是,考虑到jQuery的大小,很可能它只是您流量的一小部分。您可能应该尝试优化实际内容。


1
另一个原因-用户在其缓存中已经有来自google的jquery,因此他们甚至不需要在首次访问您的网站时下载它。
Kip

14

jQuery 1.3.1分钟的大小仅为18k。我认为这对初始页面加载没有太大影响。之后将被缓存。结果,我自己托管了它。


7
根据您陈述的理由,我谨不同意。如果您获得大量流量,则每个会话18k的流量很快就会增加到可观的流量。特别是如果您的虚拟主机按使用的带宽收费...
Dscoduc,

1
我的观点是,仅当您的访问者仅浏览一页时,这才值得关注。如果您的个人资料中的访问者较少且页面浏览量较多,那么当每个访问者的页面浏览量分布时,开销就最小。同上的回头客。
克里斯汀2009年

2
除非您的网站绝对很小,否则18k永远只是您流量的一小部分。
Hans-Christoph Steiner 2014年

14

如果您想使用Google,则直接链接的响应速度可能更快。每个库都有列出的直接文件路径。这是jQuery路径

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

只是重新阅读您的问题,您使用https是有原因的吗?这是Google在其示例中列出的脚本标签

<script src="http://www.google.com/jsapi"></script>

3
因为站点是HTTPS,所以使用HTTPS,所以一定要这样做。
Darryl Hein

1
您所有的内容均基于https,或仅其中一部分?
Dscoduc

2
https站点上的http链接很烦人,因为IE(至少默认情况下)使您烦恼“此站点包含安全和不安全的内容”。确认框。
cletus

1
代码的来源完全是SSL,这是极其安全的联系信息。
Darryl Hein

1
如果您完全关心用户的安全性,请始终对JavaScript使用HTTPS。如果没有HTTPS,则很容易中间人(MITM)那些请求并与您打算发送给人们的javascript一起利用漏洞利用程序。将公共wifi,被入侵的家庭路由器等视为可能的MITM位置。看看这些PWN对自己的比赛:他们总是利用浏览器中得到的。
汉斯-克里斯托夫·施泰纳

8

我不想让我开发的任何公共站点都依赖于任何外部站点,因此,我自己托管jQuery。

当其他网站(Google,jquery.com等)出现故障时,您是否愿意在您的网站上停机?减少依赖性是关键。


2
我将用户体验(快速的加载时间)放在了那里,而减少了依赖性。
Dscoduc

1
@slacy嘿,您的网站已关闭!实际上是jk,但我确实注意到您使用的是Google Analytics(分析),并且脚本的开头而不是结尾-如果google速度较慢,这会
稍微

3
嗯... slacy正在使用Google Analytics(分析)?他不是只是说不想让他开发的任何公共站点都依赖外部站点吗?;-)
Dscoduc

1
哇,伙计,那里有一些严厉的评论。:)是的,我确实在我的个人博客上使用Google Analytics(分析),但这不是一个产生收入的生产站点,因此我认为这真的很好。我确定我的网站每年都会关闭很多天。请记住,您对个人网站和工作所做的工作并不相同
slacy

6
使用本地副本还有其他充分的理由:Google在许多国家(例如伊朗,中国等)经常被禁止访问。因此,这意味着有十亿以上的人无法访问。
Hans-Christoph Steiner 2014年

6

优点:托管在Google上有好处

  • 可能更快(它们的服务器进行了更优化)
  • 他们正确地处理了缓存-1年(我们很难进行更改以使标头正确放置在我们的服务器上)
  • 已经链接到另一个域上的Google托管版本的用户的文件已经在其缓存中

缺点:

  • 某些浏览器可能会将其视为XSS跨域并且不允许该文件。
  • 特别是为Firefox运行NoScript插件的用户

我想知道您是否可以从Google包含在内,然后检查是否存在某些Global变量或类似变量,以及是否从服务器上加载了缺勤信息?


3
这是Firefox的缺点,而不是Google的缺点。)
Nakilon

6

这里有一些问题。首先,您指定的异步加载方法:

<script type="text/javascript" src="https://www.google.com/jsapi"></script>
<script type="text/javascript">
  google.load('jquery', '1.3.1');
  google.setOnLoadCallback(function() {
    // do stuff
  });
</script>

有几个问题。脚本标记在检索页面时会暂停页面加载(如有必要)。现在,如果加载速度很慢,那就不好了,但是jQuery很小。上面方法的真正问题在于,由于jquery.js的加载独立地发生在许多页面上,因此它们将在jquery加载之前完成加载和呈现,因此您所做的任何jquery样式对于用户而言都是可见的变化

另一种方法是:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

尝试一些简单的示例,例如,拥有一个简单的表,并使用setOnLoadCallback()方法与带有静态jquery.min.js加载的$(document).ready()来将单元格的背景更改为黄色。第二种方法不会有明显的闪烁。第一将。我个人认为这不是良好的用户体验。

作为示例,运行以下命令:

<html>
<head>
  <title>Layout</title>
  <style type="text/css">
    .odd { background-color: yellow; }
  </style>
</head>
<body>
<table>
  <tr><th>One</th><th>Two</th></tr>
  <tr><td>Three</td><td>Four</td></tr>
  <tr><td>Five</td><td>Six</td></tr>
  <tr><td>Seven</td><td>Nine</td></tr>
  <tr><td>Nine</td><td>Ten</td></tr>
</table> 
<script src="http://www.google.com/jsapi"></script>
<script>
  google.load("jquery", "1.3.1");
  google.setOnLoadCallback(function() {
    $(function() {
      $("tr:odd").addClass("odd");
    });
  });
</script>
</body>
</html>

您(应该)看到表格出现,然后行变成黄色。

google.load()方法的第二个问题是它仅托管有限范围的文件。对于jquery来说,这是一个问题,因为它非常依赖于插件。如果您尝试将带有<script src="...">标签的jquery插件包含在内,则google.load()该插件可能会失败,并显示“未定义jQuery”消息,因为尚未加载。我真的没有办法解决这个问题。

第三个问题(使用任何一种方法)是它们是一个外部负载。假设您有一些插件和自己的Javascript代码,则最多需要两个外部请求来加载Javascript。您最好获得jquery,所有相关插件和您自己的代码,并将其放入一个缩小的文件中。

你应该使用谷歌的AJAX库API的主机?

至于加载时间,您实际上是在加载两个脚本-jsapi脚本和mootools脚本(上面的压缩版本)。因此,这是两个连接,而不是一个。根据我的经验,我发现加载时间实际上比从我自己的个人共享服务器上加载要慢2-3倍,即使它来自Google,而且我的压缩文件版本也比Google大几千倍。即使在文件已加载和(大概)缓存后,也是如此。所以对我来说,由于带宽无关紧要,因此无关紧要。

最后,您可能存在一个偏执浏览器将请求标记为某种XSS尝试的潜在问题。默认设置通常不是问题,但是在公司网络上,用户可能无法控制他们使用的浏览器,更不用说安全设置了。

因此,最终我至少看不到我在使用jQuery的Google AJAX API(在某些方面,更“完整”的API是不同的故事)了,除了在此处发布示例外。


我没有遇到您提到的任何问题。据我所知,按正确的顺序加载东西可以解决几乎所有问题。
Darryl Hein

4

除了建议将其托管在自己的服务器上的人员之外,我还建议将其保留在单独的域(例如static.website.com)中,以允许浏览器将其加载到与其他内容线程分离的位置。本技巧也适用于所有静态内容,例如图像和CSS。


4

对于Google托管的图书馆,我必须投票-1。他们正在使用Google分析样式收集数据,并使用这些库周围的包装器。至少,我不希望客户端浏览器完成比我要求的更多的工作,更不要说页面上的其他任何事情。更糟糕的是,这是Google的“新版本”,它不是邪恶的-使用不引人注目的JavaScript来收集更多使用情况数据。

注意:如果他们改变了这种做法,那就太好了。但是上一次我考虑使用它们的托管库时,我监视了网站上的出站http流量,因此我不希望看到对Google服务器的定期呼叫。


但是,您是否已经在自己的网站上运行Google Analytics(分析)?由于我是我,所以无论JQuery是否来自Google都没有太大的区别,他们可能已经知道我正在我的网站上运行它
Dscoduc

但是它的缓存时间为1年-我们是否同时向Google发送了304个“文件已更改”?
克里斯汀

是的,我也看到过那些定期回电给Google的消息(Safari的活动管理器有一个不错的列表)。
Darryl Hein

Dscoduc-是的,使用Analytics(分析)。至少通过该实现,我提前了解到我正在放弃使用情况数据。JS库不是这样。
jro

3

我可能对此很老套,但是我仍然不喜欢热链接。也许Google是个例外,但总的来说,将文件托管在您自己的服务器上确实是一种很好的方式。


3
“礼貌”是什么意思?Google鼓励您链接到他们的服务器。Google令人难以置信的基础架构已将其淘汰。
Nosredna

2
当您听说使用Google时,一开始肯定有一个困惑。但正如nosredna所言,这令人鼓舞的:“我们将尽一切努力来托管库,正确设置缓存头,保持最新的错误修复等。” - code.google.com/apis/ajaxlibs
Simon_Weaver

3

我将其添加为本地托管这些文件的原因。

最近,TWC上南加州的一个节点无法解析ajax.googleapis.com域(对于使用IPv4的用户),因此我们无法获取外部文件。直到昨天,它一直是断断续续的(现在是持久性的。)因为它是断断续续的,所以我在排除SaaS用户问题方面遇到了很多问题。花了无数小时试图跟踪为什么某些用户的软件没有问题,而其他用户却遇到了麻烦。在我通常的调试过程中,我不习惯问用户是否已关闭IPv6。

我偶然发现了这个问题,因为我本人正在使用指向文件的特定“路由”,并且还仅使用了IPV4。我发现开发人员工具出现了问题,告诉我jquery没有加载,然后开始执行traceroutes等...来查找真正的问题。

在此之后,我极有可能永远不会再返回外部托管的文件,因为:谷歌不必为此而陷入麻烦,并且...这些节点中的任何一个都可能受到DNS劫持的威胁并提供恶意js。而不是实际文件。一直以为我很安全,因为google域永远不会崩溃,现在我知道用户和主机之间的任何节点都是失败点。


2

我只包括jQuery网站的最新版本:http : //code.jquery.com/jquery-latest.pack.js 它适合我的需求,我永远不必担心更新。

编辑:对于大型Web应用程序,当然可以控制它;下载并自己提供。但是对于我的个人网站,我一点也不在乎。事物不会神奇地消失,它们通常首先被弃用。我足够了解它,以了解将来的发行版中要进行哪些更改。


1
我发现这种方法有点危险,如果库中的代码更改破坏了您的站点怎么办?或jQuery的网站出现故障?我宁愿完全控制该文件。
2009年

1
另外,我不喜欢这样影响jQuery的带宽。他们已经提供了一个非常酷的免费工具,并且我讨厌由于带宽成本而放弃它们。如果您不想自己托管它,最好使用Google作为外部资源,因为它们是为此目的而提供的。
nezroy

我建议切换到使用Google而不是JQuery。主要原因是Google可能在全球范围内拥有比JQuery更多的服务器,并且根据我的经验,更多的人使用Google托管,这增加了他们已经对其进行缓存的机会。
Dscoduc

我同意Jason的观点,自动切换到新版本非常危险。如果仅使用jquery,可能不会那么多,但是对于插件,我绝对不推荐。我为一个人在一个可以使用1.2.6但不能使用1.3.x的网站上使用一个插件(至今...)
jeroen

2

这里有一些有用的资源,希望可以帮助您选择CDN。MS最近为通过CDN的交付图书馆添加了新域。

旧格式:http//ajax.microsoft.com/ajax/jQuery/jquery-1.5.1.js 新格式:http//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js

这不应发送microsoft.com的所有cookie。 http://www.asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_from_the_CDN_11

这里是有关所有技术中网络上使用的最流行技术的一些统计信息。 http://trends.builtwith.com/

希望可以帮助您选择。


1

如果我负责的“活”的地盘我好知道是在和去一切进入我的网站。因此,我自己将jquery-min版本托管在同一服务器或静态/外部服务器上,但是无论哪种方式,只有我(或我的程序/代理)可以在验证/测试了每个更改之后才能更新库


我希望Google永远不会更改文件-对于错误修复,他们将托管一个新文件,文件名中使用不同的版本号。还是我天真?他们会使用相同的文件名推出“次要修复程序”吗?
克里斯汀

如果您要求特定的版本,Google绝不要更改文件。
Darryl Hein

1

在头上:

  (function() {
    var jsapi = document.createElement('script'); jsapi.type = 'text/javascript'; jsapi.async = true;
    jsapi.src = ('https:' == document.location.protocol ? 'https://' : 'http://') + 'www.google.com/jsapi?key=YOUR KEY';
    (document.getElementsByTagName('head')[0] || document.getElementsByTagName('head')[0]).appendChild(jsapi);
  })();

身体末端:

<script type="text/javascript">
google.load("jquery", "version");
</script>

0

我将其与其他js文件托管在自己的服务器上,至此,将它们合并并缩小(使用django-compresser,在这里,但这不是重点),可以作为一个js文件使用,并且包含网站上的所有内容需要投入其中。无论如何,您都需要提供自己的js文件,因此,我认为没有理由也不要在其中添加额外的jquery字节-传输更多的kb比发出更多的请求要便宜得多。您不依赖任何人,并且一旦缓存了缩小的js,您的速度也很快。

首次加载时,基于CDN的解决方案可能会获胜,因为您必须从自己的服务器加载额外的jquery千字节(但无需额外的请求)。我怀疑这种差异是否显着。然后,在第一次清除缓存的负载下,由于需要更多的请求(和DNS查找)来提取CDN jQuery,因此您自己的托管解决方案可能总是会更快。

我不知道几乎没有提到这一点,以及CDN似乎如何占领了世界:)

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.