您从哪里引入 jQuery 库? 谷歌JSAPI? CDN?

发布于 2024-07-13 11:11:45 字数 946 浏览 8 评论 0原文

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

  • Google 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>

编辑2:以下是我去年如何毫无问题地包含 jQuery:

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

不同之处在于删除了http:。 通过删除它,您无需担心 http 和 https 之间的切换。

There are a few ways to include jQuery and jQuery UI and I'm wondering what people are using?

  • Google JSAPI
  • jQuery's site
  • your own site/server
  • another CDN

I have recently been using Google JSAPI, but have found that it takes a long time to setup an SSL connection or even only to resolve google.com. I have been using the following for Google:

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

I like the idea of using Google so it's cached when visiting other sites and to save bandwidth from our server, but if it keeps being the slow portion of the site, I may change the include.

What do you use? Have you had any issues?

Edit: Just visited jQuery's site and they use the following method:

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

Edit2: Here's how I've been including jQuery without any problems for the last year:

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

The difference is the removal of http:. By removing this, you don't need to worry about switching between http and https.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(16

枕头说它不想醒 2024-07-20 11:11:45

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

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

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

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

我了解,我对 Google 寄予一定的信任,希望 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>

更新 9/8/2010 -
已经提出了一些建议,通过删除 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>

此外,如果您想确保最新的主要版本,您还可以更改 url 以反映 jQuery 主版本号的 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>

Without a doubt I choose to have JQuery served by Google API servers. I didn't go with the jsapi method since I don't leverage any other Google API's, however if that ever changed then I would consider it...

First: The Google api servers are distributed across the world instead of my single server location: Closer servers usually means faster response times for the visitor.

Second: Many people choose to have JQuery hosted on Google, so when a visitor comes to my site they may already have the JQuery script in their local cache. Pre-cached content usually means faster load times for the visitor.

Third: My web hosting company charges me for the bandwidth used. No sense consuming 18k per user session if the visitor can get the same file elsewhere.

I understand that I place a portion of trust on Google to serve the correct script file, and to be online and available. Up to this point I haven't been disappointed with using Google and will continue this configuration until it makes sense not to.

One thing worth pointing out... If you have a mixture of secure and insecure pages on your site you might want to dynamically change the Google source to avoid the usual warning you see when loading insecure content in a secure page:

Here's what I came up with:

<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>

UPDATE 9/8/2010 -
Some suggestions have been made to reduce the complexity of the code by removing the HTTP and HTTPS and simply use the following syntax:

<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>

In addition you could also change the url to reflect the jQuery major number if you wanted to make sure that the latest Major version of the jQuery libraries were loaded:

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

Finally, if you don't want to use Google and would prefer jQuery you could use the following source path (keep in mind that jQuery doesn't support SSL connections):

<script type="text/javascript">
    document.write("\<script src='http://code.jquery.com/jquery-latest.min.js' type='text/javascript'>\<\/script>");
</script>
眼趣 2024-07-20 11:11:45

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

然而,考虑到您正在使用的 jQuery 文件可能不会经常更改,浏览器缓存将启动并使这一点在大多数情况下毫无意义。

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

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

One reason you might want to host on an external server is to work around the browser limitations of concurent connections to particular server.

However, given that the jQuery file you are using will likely not change very often, the browser cache will kick in and make that point moot for the most part.

Second reason to host it on external server is to lower the traffic to your own server.

However, given the size of jQuery, chances are it will be a small part of your traffic. You should probably try to optimize your actual content.

与君绝 2024-07-20 11:11:45

jQuery 1.3.1 分钟只有 18k 大小。 我认为在初始页面加载时问这个问题并不算太大。 之后它将被缓存。 结果,我自己主持。

jQuery 1.3.1 min is only 18k in size. I don't think that's too much of a hit to ask on the initial page load. It'll be cached after that. As a result, I host it myself.

书信已泛黄 2024-07-20 11:11:45

如果您想使用 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>

If you want to use Google, the direct link may be more responsive. Each library has the path listed for the direct file. This is the jQuery path

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

Just reread your question, is there a reason your are using https? This is the script tag Google lists in their example

<script src="http://www.google.com/jsapi"></script>
盛装女皇 2024-07-20 11:11:45

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

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

I wouldn't want any public site that I developed to depend on any external site, and thus, I'd host jQuery myself.

Are you willing to have an outage on your site when the other (Google, jquery.com, etc.) goes down? Less dependencies is the key.

戏蝶舞 2024-07-20 11:11:45

优点: 在 Google 上托管有好处

  • 可能更快(他们的服务器更加优化)
  • 他们正确处理缓存 - 1 年(我们很难被允许进行更改以使标头正确地出现在我们的服务器上)
  • 已经拥有链接的用户另一个域上的 Google 托管版本的缓存中已存在该文件

缺点:

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

我想知道您是否可以从 Google 包含,然后检查某些全局变量或类似变量的存在,以及服务器是否缺少负载?

Pros: Host on Google has benefits

  • Probably faster (their servers are more optimised)
  • They handle the caching correctly - 1 year (we struggle to be allowed to make the changes to get the headers right on our servers)
  • Users who have already had a link to the Google-hosted version on another domain already have the file in their cache

Cons:

  • Some browsers may see it as XSS cross-domain and disallow the file.
  • Particularly users running the NoScript plugin for Firefox

I wonder if you can INCLUDE from Google, and then check the presence of some Global variable, or somesuch, and if absence load from your server?

彻夜缠绵 2024-07-20 11:11:45

这里有几个问题。 首先,您指定的异步加载方法

<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 来说是一个问题,因为它非常依赖插件。 如果您尝试包含带有

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

来自您应该使用 Google 的 Ajax Libraries API 进行托管吗?

至于加载时间,您实际上是
加载两个脚本 - jsapi 脚本
和 mootools 脚本(
上面的压缩版本)。 所以
这是两个连接,而不是
一。 根据我的经验,我发现
加载时间实际上是原来的2-3倍
比我自己加载慢
个人共享服务器,即使它
来自 Google,我的版本
压缩文件的几个
K 比谷歌的还大。 这,甚至
文件加载后
(大概)已缓存。 所以对我来说,自从
带宽并不重要,
没关系。

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

所以最终我无法真正看到我至少使用 Google AJAX API for jQuery(更“完整”的 API 在某些方面是一个不同的故事),除了在这里发布示例。

There are a few issues here. Firstly, the async load method you specified:

<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>

has a couple of issues. Script tags pause the page load while they are retrieved (if necessary). Now if they're slow to load this is bad but jQuery is small. The real problem with the above method is that because the jquery.js load happens independently for many pages, they will finish loading and render before jquery has loaded so any jquery styling you do will be a visible change for the user.

The other way is:

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

Try some simple examples like, have a simple table and change the background of the cells to yellow with the setOnLoadCallback() method vs $(document).ready() with a static jquery.min.js load. The second method will have no noticeable flicker. The first will. Personally I think that's not a good user experience.

As an example run this:

<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>

You (should) see the table appear and then the rows go yellow.

The second problem with the google.load() method is that it only hosts a limited range of files. This is a problem for jquery since it is extremely plug-in dependent. If you try and include a jquery plugin with a <script src="..."> tag and google.load() the plug-in will probably fail with messages of "jQuery is not defined" because it hasn't loaded yet. I don't really see a way around this.

The third problem (with either method) is that they are one external load. Assuming you have some plugins and your own Javascript code you're up to a minimum of two external requests to load your Javascript. You're probably better off getting jquery, all relevant plug-ins and your own code and putting it into one minified file.

From Should You Use Google's Ajax Libraries API for Hosting?:

As to load times, you're actually
loading two scripts - the jsapi script
and the mootools script (the
compressed version from above). So
that is two connections, rather than
one. In my experience, I found that
the load time was actually 2-3 times
slower than loading from my own
personal shared server, even though it
was coming from Google, and my version
of the compressed file was a couple of
K larger than Google's. This, even
after the file had loaded and
(presumably) cached. So for me, since
the bandwidth doesn't matter much,
isn't going to matter.

Lastly you have the potential problem of a paranoid browser flagging the request as some sort of XSS attempt. It's not typically a problem with default settings but on corporate networks where the user may not have control over which browser they use let alone the security settings you may have a problem.

So in the end I can't really see me using the Google AJAX API for jQuery at least (the more "complete" APIs are a different story in some ways) much except to post examples here.

遇见了你 2024-07-20 11:11:45

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

In addition to people who advices to host it on own server, I'd proposed to keep it on separate domain (e.g. static.website.com) to allow browsers to load it into separate from other content thread. This tip also works for all static stuff, say images and css.

若水般的淡然安静女子 2024-07-20 11:11:45

我必须为 Google 托管的库投 -1 票。 他们正在收集数据,谷歌分析风格,以及这些库的包装器。 至少,我不希望客户端浏览器做超出我要求的事情,更不用说页面上的其他任何事情了。 更糟糕的是,这是 Google 不作恶的“新版本”——使用不引人注目的 JavaScript 来收集更多使用数据。

注意:如果他们改变了这种做法,那就太好了。 但上次我考虑使用他们的托管库时,我监控了我网站上的出站 http 流量,并且对 google 服务器的定期调用并不是我期望看到的。

I have to vote -1 for the libraries hosted on Google. They are collecting data, google analytics style, with their wrappers around these libraries. At a minimum, I don't want a client browser doing more than I'm asking it to do, much less anything else on the page. At worse, this is Google's "new version" of not being evil -- using unobtrusive javascript to gather more usage data.

Note: if they've changed this practice, super. But the last time I considered using their hosted libraries, I monitored the outbound http traffic on my site, and the periodic calls out to google servers were not something I expected to see.

茶色山野 2024-07-20 11:11:45

我可能对此很老派,但我仍然不赞成盗链。 也许 Google 是个例外,但总的来说,将文件托管在自己的服务器上确实是一种礼貌。

I might be old-school about this, but I still frown on hotlinking. Maybe Google is the exception, but in general, it's really just good manners to host the files on your own server.

天邊彩虹 2024-07-20 11:11:45

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

最近,TWC 上南加州的一个节点无法解析 ajax.googleapis.com 域(仅适用于使用 IPv4 的用户),因此我们无法获取外部文件。 直到昨天为止,这种情况一直是断断续续的(现在它是持续存在的)。因为它是断断续续的,所以我在解决 SaaS 用户问题时遇到了很多问题。 花了无数的时间试图追踪为什么有些用户在使用该软件时没有问题,而另一些用户却遇到了麻烦。 在我平常的调试过程中,我不习惯询问用户是否关闭了 IPv6。

我偶然发现了这个问题,因为我自己正在使用这个特定的文件“路由”,而且也只使用 IPV4。 我发现了开发人员工具的问题,告诉我 jquery 没有加载,然后开始执行跟踪路由等......以找到真正的问题。

在此之后,我很可能永远不会再回到外部托管的文件,因为:谷歌不必因为这成为一个问题而宕机,并且......这些节点中的任何一个都可能受到 DNS 劫持并传递恶意 js而不是实际的文件。 一直以为我是安全的,因为谷歌域永远不会宕机,现在我知道用户和主机之间的任何节点都可能成为故障点。

I will add this as a reason to locally host these files.

Recently a node in Southern California on TWC has not been able to resolve the ajax.googleapis.com domain (for users with IPv4) only so we are not getting the external files. This has been intermittant up until yesterday (now it is persistant.) Because it was intermittant, I was having tons of problems troubleshooting SaaS user issues. Spent countless hours trying to track why some users were having no issues with the software, and others were tanking. In my usual debugging process I'm not in the habit of asking a user if they have IPv6 turned off.

I stumbled on the issue because I myself was using this particular "route" to the file and also am using only IPV4. I discovered the issue with developers tools telling me jquery wasn't loading, then started doing traceroutes etc... to find the real issue.

After this, I will most likely never go back to externally hosted files because: google doesn't have to go down for this to become a problem, and... any one of these nodes can be compromised with DNS hijacking and deliver malicious js instead of the actual file. Always thought I was safe in that a google domain would never go down, now I know any node in between a user and the host can be a fail point.

素染倾城色 2024-07-20 11:11:45

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

编辑:对于一个主要的网络应用程序,当然要控制它; 下载它并自己提供服务。 但对于我的个人网站,我一点也不在乎。 事物不会神奇地消失,它们通常首先被弃用。 我足够了解它,知道未来版本需要更改哪些内容。

I just include the latest version from the jQuery site: http://code.jquery.com/jquery-latest.pack.js It suits my needs and I never have to worry about updating.

EDIT:For a major web app, certainly control it; download it and serve it yourself. But for my personal site, I could not care less. Things don't magically disappear, they are usually deprecated first. I keep up with it enough to know what to change for future releases.

哽咽笑 2024-07-20 11:11:45

这里有一些有用的资源,希望可以帮助您选择您的 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/

希望可以帮助您选择。

Here some useful resource, hope can help you to chose your CDN.
MS has recently add a new domain for delivery Libraries trough their CDN.

Old Format: http://ajax.microsoft.com/ajax/jQuery/jquery-1.5.1.js
New Format: http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js

This should not send all cookies for microsoft.com.
http://www.asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_from_the_CDN_11

Here some statistics about most popular technology used on the web across all technology.
http://trends.builtwith.com/

Hope can help you to choose.

感悟人生的甜 2024-07-20 11:11:45

如果我负责“实时”网站,我最好了解正在发生的一切
进入并进入我的网站。 因此,我自己将 jquery-min 版本托管在同一服务器或静态/外部服务器上,但无论哪种方式,只有我(或我的程序/代理)可以在验证/测试每个更改后更新库

If I am responsible for the 'live' site I better be aware of everything that is going
on and into my site. For that reason I host the jquery-min version myself either on the same server or a static/external server but either way a location where only I (or my program/proxy) can update the library after having verified/tested every change

情泪▽动烟 2024-07-20 11:11:45

头部:

  (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>

In head:

  (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);
  })();

End of Body:

<script type="text/javascript">
google.load("jquery", "version");
</script>
套路撩心 2024-07-20 11:11:45

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

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

我想知道为什么这一点几乎从未被提及,以及 CDN 似乎如何接管世界:)

I host it with my other js files on my own server, and, that's that point, combine and minify them (with django-compresser, here, but that's not the point) to be served as just one js file, with everything the site needs put into it. You'll need to serve your own js files anyway, so I see no reason to not add the extra jquery bytes there too - some more kbs are much more cheaper to transfer, than more requests to be made. You are not dependent to anyone, and as soon as your minified js is cached, you're super fast as well.

On first load, a CDN based solution might win, because you must load the additional jquery kilobytes from your own server (but, without an additional request). I doubt the difference is noticable, though. And then, on a first load with cleared cache, your own hosted solution will probably always be much faster, because of more requests (and DNS lookups) needed, to fetch the CDN jquery.

I wonder how this point is almost never mentioned, and how CDNs seem to take over the world :)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文