【问题标题】:Where to place my JS code and where/how to load multiple jQuery plugins?在哪里放置我的 JS 代码以及在哪里/如何加载多个 jQuery 插件?
【发布时间】:2010-10-07 18:10:32
【问题描述】:

我有几个问题有些相关,所以我将它们全部发布在 SO...上的一个问题上......

问题 1:

我目前正在使用 jQuery UI 选项卡做这个 Facebook 应用程序,只有 4 个通过 Ajax 加载其中的 2 个。主页是 index.html,这是放置选项卡代码的位置,对于通过 Ajax 加载的 2 个选项卡,我有两个不同的文件,tab1.html 和 tab2.html。

目前,jQuery 选项卡初始化和 Facebook JavaScript 初始化是在 index.html 上完成的。 tab1.html 和 tab2.html 都有属于这些页面的 JavaScript 代码。例如,tab2.html 有一个表单,并且有一些 JS(使用 jQuery)代码来验证表单,此代码与 tab1.html 无关,因为 tab1.html 上的 JS 代码与 tab2.html 无关。

我的问题是,我应该继续这样做还是将 index.html、tab1.html 和 tab2.html 中的所有 JS/jQuery 代码聚合到一个 global.js 文件中,然后将其包含在 index.html 中?

我虽然会这样做,但如果用户从不打开 tab1 或 tab2,则会加载不相关的代码。使用单个 global.js 文件的好处是我可以打包/缩小文件,如果我将每个代码块包含在每个相应的 tabX.html 文件中,我就无法做到这一点。

问题 2:

当我使用 jQuery 时,我也使用了很多插件(实际上现在只有 3 个,但这个数字可以增长)。其中一些提供了一个缩小的 JS,我在可用时使用它们,当它们不可用时,我当然使用普通版本。

还有请求问题。如果我有很多插件,比如 10 个,那么对这些插件的请求将是 10 个。还有一个事实是tab1.html中使用了一些插件,但tab2.html中没有使用,反之亦然。

我应该如何在单个 Web 请求中加载压缩/打包版本中的所有插件?我应该在发布我的应用程序之前手动执行此操作(将它们打包并合并到一个文件中)还是可以使用PHP version of Dean Edwards's Packer 并即时打包/合并所有插件?这是一个好方法吗?

问题 3:

如果第一季度的答案类似于“将所有代码合并到一个 global.js 文件中”,我是否应该将 global.js 文件包含在我上面在第二季度描述的打包/合并脚本中?

这样做会简化一切。我可以将我的开发环境与所有 .js 文件、插件和 global.js 正确组织在适当的文件夹中,而无需担心其他任何事情。打包/合并应该处理剩下的事情(从各自的文件夹中提取文件,发送各自的 JS 标头并输出一个打包的 .js 文件)。

最让我困惑的一件事是,并非所有插件都用于每个选项卡,并非所有代码也用于每个选项卡。尽管如此,大部分代码对于每个选项卡和索引都是全局的。这也将所有内容简化为: a) 我不必担心将所需的代码添加到每个 tabX.html 文件中,我可以简单地将它们视为 HTML 模板而不是其他任何东西; b)我不必费心在我需要它们的地方包含必要的插件,因为我目前正在使用 jQuery 中的 $.getScript() 来加载我需要的插件,当且仅当我需要它们时,但我是不确定这是一个好方法,而且代码感觉像这样又脏又丑。

【问题讨论】:

    标签: javascript jquery jquery-plugins


    【解决方案1】:

    问题 1:

    将它们全部打包到一个 .js 文件中。这将使维护更容易,并且用户加载他们可能不使用的小 js 的一点点开销并不重要。我还会让 Google 为您加载 jQuery 库,然后将您的所有 js 代码放在一个单独的文件中。

    问题 2:

    由于这些插件并没有真正改变,我会手动组合它们。 Closure Compiler 擅长于此。缩小时使用不发出任何警告的最高设置。

    问题 3:

    是的,你会想要缩小 global.js

    当浏览器下载 global.js 时,它会被缓存一段时间。因此,当您在不同的页面上再次调用整个 global.js 时,它不会重新下载,它会首先查看您的本地副本。所以一开始你会在初始下载时多做一些工作,但从那时起,它应该会更快。

    【讨论】:

    • 最后一个问题,我应该为全局 JS 代码和插件代码 (global.js/plugins.js) 提供 2 个文件,还是只为我的所有 JS 代码和插件提供一个全局文件?此外,Closure Compiler 看起来不错,但每次我添加/删除插件或更新我自己的 JS 代码时,它都会迫使我使用它,这有点无聊。也许 Minify (code.google.com/p/minify) 是一个更好的选择?
    • 这取决于个人喜好。我通常将它们分开,因为插件很少会改变,所以我宁愿它们在别处。另一方面,如果我只有 1 或 2 个插件,我会将它们全部添加到 1 中。
    • 我没有亲自使用过 minify,但看起来它只是自动手动进行更新。所以这也取决于你。
    【解决方案2】:

    通常与 javascript 相关的加快网站加载速度的最佳做法是:

    1. 缩小所有 javascript 并将其全部放入一个文件中(尽可能多地使您的 javascript 外部化)。
    2. 将 javascript 放在文档的底部。
    3. 强制 Web 服务器指定未来的到期日期,并使用带时间戳的查询字符串使旧版本的 javascript 文件无效,这样可以防止对未更改的 javascript 的不必要请求。 (即:在 httpd.conf 中 ExpiresByType application/x-javascript "access plus 1 year",在您的文档中:<script type="text/javascript" src="/allmy.js?v=1285877202"></script>
    4. 将您的网络服务器配置为 gzip 压缩所有文本文件。

    【讨论】:

    • 恕我直言,我没有要求“一般最佳实践”,而是针对自己的问题提出了具体问题。
    • @Nazgulled:要尝试更具体地回答您的问题——您必须权衡留下嵌入式 js 片段与合并到外部文件的复杂性、性能和潜在带宽节省,具体取决于您的应用程序的具体情况。在您的情况下,将 javascript 移出外部文件可能会提高性能,降低复杂性,并且在我的帖子中实现的点甚至可能会减少带宽。除非您在选项卡中生成自定义 js,否则您无法将该特定 js 移出。
    【解决方案3】:

    您应该远离标签页的主要原因是因为它会破坏用户体验。当用户第一次点击一个标签时,它会即时抓取所有需要的组件,这使得它有点迟钝。

    您的问题只是半具体的,因为我们对您的网站知之甚少,例如确切的文件大小、模块的实际使用方式。

    总体思路是在模块化和速度之间找到平衡

    当您将模块组合在一起时,您应该考虑以下一般想法:

    • 此模块多久更换一次?
    • 这个模块的使用频率如何?
    • 这个模块有多大(文件大小)?

    然后把最常用的、稳定的代码库合并成一个。然后,您应该在标签页上包含其余站点特定的功能。

    另外,请确保异步加载 javascript,因为它不会阻止页面(和选项卡)的呈现。

    【讨论】:

    • 每个人似乎都在避免 Q2/Q3... 尽管是第一个,但它是最不重要的。我需要更好的 Q2/Q3 答案:(
    • 如果你仔细阅读我回答了你的问题:我不建议你制作一个大文件,因为如果它有任何改变,用户必须重新下载。这就是为什么我写了你应该按照文件更改的频率对文件进行分组。并制作一个几乎不会变化的稳定代码库,与频繁变异的代码库分开。
    • 光是想想就觉得工作量太大了,我认为这样做的好处不值得。
    • 这不是因为懒惰,而是因为这个特定的网站不值得……我不是在开发下一个 Facebook,它只是一个简单的应用程序。
    【解决方案4】:

    另一个综合答案:

    如果在打包/缩小版本中将所有 JS 加在一起生成不超过 30k 的文件大小,则最好将其组合起来。一个文件的一个额外连接(假设它没有被缓存)值得 10-20k 的额外 JS 下载。这与浏览器打开和关闭连接与在已建立的连接上流式传输额外的 20k 有关。阈值还取决于您的用户分布。如果您有很多拨号或低带宽用户,您的阈值会更小。

    我通常建议组合并加载为 1 个文件,除非库非常晦涩并且需要非常极端的情况才能在页面上触发它。例如:悬停会触发 Y 功能,但它位于获得不到 1% 流量的反馈小部件上 - 不要费心组合。

    如今,缩小和打包有点被高估了。由于绝大多数浏览器都支持 gZip,因此 gZip 在浏览器传输期间通过网络提供的文件数据整合量与 min/pack 的效果几乎相同。但是,在浏览器上解压它需要花费很小的成本。话虽如此,压缩/打包代码仍然是一种好习惯,因为并非所有浏览器都支持它,您可能不希望文件启用 gZip 等。

    我已经针对第 3 方模块使用了在线打包程序,它运行良好。但是,有时它可能会导致问题,因此请务必在部署之前测试您手动打包的版本。

    替代:

    如果您觉得您的用户会在您的索引页面停留超过 10 秒,您可以使用 Js Loader Prototype 模式单独预加载其他库。

    【讨论】:

      【解决方案5】:

      Steve Souder 的《更快的网站》是一本值得一看的书。

      首先,速度会变慢,因为每当链接外部脚本时,浏览器都会等待脚本下载、解析然后执行。只有在此之后,它才会重新处理请求的其余部分。因此,为了避免这种减速,可以考虑并行下载脚本。如果脚本在同一个域中,很少有技术是 Ajax 脚本,或者如果脚本在外部域中,则使用 Script Dom 元素或 iframe 中的脚本

      Q1:对我来说,如果必须不断更改页面内容,则将所有内容模块化是进一步开发的更好选择。响应能力对于最终用户来说非常重要。一个小的 global.js 将有助于启动和运行应用程序。并行可以下载 tabX.html。

      Q2:因为 jquery 插件很少改变。 tabX.html 页面的插件可以并行下载并在本地缓存,因此在加载 tabX.html 时不需要获取所需的插件。所以主页所需的所有插件都应该在一个文件中,而 tabX.html 使用的插件应该在不同的文件中。

      Q3:这是个人选择。您希望它对开发人员友好还是对用户友好。我依靠用户友好性。制作响应迅速且高效的应用程序是我们的工作!!!。将所有内容打包到单个文件中的所有优点是您可以轻松开发。丑陋的代码会产生漂亮的应用程序:)。用户是速度狂。例如。当谷歌将其每页 10 个结果更改为 20 个时,他们发现搜索查询大幅下降。所以我的意见是不要将它们全部打包并并行加载每个

      一些测试技术和相关链接:

      XHR 评估 /ajax : http://stevesouders.com/cuzillion/?ex=10009

      XHR 注入:http://stevesouders.com/cuzillion/?ex=10015

      Iframe 中的脚本:http://stevesouders.com/cuzillion/?ex=10012

      脚本 DOM 元素:http://stevesouders.com/cuzillion/?ex=10010

      【讨论】:

        【解决方案6】:

        问题一:

        最佳做法是将所有 js 文件放在一个“全局”文件中。这可以最大限度地减少您的 HTTP 请求。假设你有 5 个插件,这意味着你需要做 5 个请求,如果你将它们合并为一个,你只需要请求一次。这在第一次加载时可能会有点重,但下次这个文件将被浏览器缓存,所以..不用担心大小。 但是,在组合脚本时要注意脚本的顺序。 (即:JQuery 脚本应首先放在 js 文件中,然后放在 JQuery UI 之前)

        http://articles.sitepoint.com/article/web-site-optimization-steps/4

        http://code.google.com/speed/page-speed/docs/rtt.html

        问题 2: 您可以手动或自动完成。Dean Edward 的 Packer 是一个不错的选择。如果您使用的是 ASP.NET,您可以查看MB Compression Handler,如果您使用的是 APACHE 和 PHP,也许您可​​以查看 change the configuration of your htaccess to gzip it

        问题 3: 如果您也打包“全局”javascript文件会更好。这可以节省带宽并节省更多的加载时间。您明白了,将网站所需的所有 js 文件组合起来可以节省您包含单个脚本的时间。

        【讨论】:

        • 您误解了我的所有问题... Q1 与多个请求没有任何关系,因为没有任何 .js 文件。 Q2 与压缩无关,而是打包。实际上我从来没有谈论过压缩,这是一个完全不同的话题,我不想在这里讨论。
        猜你喜欢
        • 1970-01-01
        • 2019-07-23
        • 1970-01-01
        • 2012-05-31
        • 2015-10-31
        • 2010-11-16
        • 2014-10-27
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多