【问题标题】:At what stage do you compress/minimize javascript?您在哪个阶段压缩/最小化 javascript?
【发布时间】:2010-10-10 15:19:19
【问题描述】:

在构建时,或在用户请求页面时“即时”(可能使用缓存)。

各有什么缺点/优点。

【问题讨论】:

    标签: javascript jscompress


    【解决方案1】:

    当网站从开发服务器转移到实时服务器时。

    我总是在开发服务器上有一个未压缩的 JS 版本,在实时服务器上有一个最小化版本。

    这样做的好处是在开发时我可以遇到 JS 问题并非常简单地修复它,但我需要通过最小化程序运行每个更改的脚本,但对我来说并没有那么多。

    【讨论】:

    • 如果您在实时系统上遇到未出现在开发机器上的错误,您会怎么做?压缩器可能会引入错误...
    【解决方案2】:

    在构建或部署到舞台环境时,是压缩 javascript 的好时机。这样您就有机会在舞台环境中对其进行测试并发现可能发生的任何错误。

    压缩时有时会出现错误。您可能希望包含在压缩之前运行的 jslint 命令行版本,以确保 js 通过。这将最大限度地减少但不会消除所有压缩错误。

    【讨论】:

      【解决方案3】:

      我认为动态数据是不必要的,除非您向 JavaScript 添加动态数据(在这种情况下,有更好的方法来解决它)。 IT 只是一项不必要的支出,只会减慢页面加载速度。

      就个人而言,我会在部署/构建应用程序时这样做,这真的是一次性的事情。

      【讨论】:

        【解决方案4】:

        我会说您拥有 js 文件,就像您在源代码控制中编写它们一样,当您启动自动构建时,作为构建脚本的一部分,它会通过压缩器运行所有 javascript 文件。这样,当您将其部署到测试/暂存环境时,您将获得最新的脚本,但也为性能测试进行了压缩,就像它们投入生产时一样。

        【讨论】:

          【解决方案5】:

          我同意如果 JS 没有改变,on-the-fly 可能不是真的必要(并且会占用一些 cpu 周期)。

          可能会涉及一些中间件,但它们可以检查 JS 是否已更改并仅在请求时对其进行压缩(甚至可能将各种 JS 文件组合成一个结果文件)。

          部署时的一件好事也可能是在 JS 链接中添加一些时间戳或随机字符串作为参数(例如 .../scripts.js?t=cdkjnsccsds7sc8cshcsjhbcs)。这样,当 JS 更改时,您将使用不同的字符串,并且不会出现缓存问题,因为它是一个新 URL。 CSS 也一样。

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 2011-08-01
            • 1970-01-01
            • 2012-01-29
            • 2015-01-14
            • 2011-11-26
            • 2010-10-10
            • 1970-01-01
            相关资源
            最近更新 更多