你在什么阶段压缩/最小化 javascript？
当构建时，或者当用户请求页面时“动态”（可能使用缓存）。
以及各自的缺点/优点是什么。
When building, or "on the fly" (perhaps with caching) when the users request pages.
And what are the dis/advantages of each.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
当站点从开发服务器转移到实时服务器时。
我总是在开发服务器上有一个未压缩版本的 JS，在实时服务器上有一个最小化版本。
这样做的好处是，在开发时我可以遇到 JS 问题并非常简单地修复它，但我需要通过最小化器运行每个更改的脚本，但对我来说并没有那么多。
When the site moves from dev to the live server.
I always have an uncompressed version of the JS on the dev server and a minimized version on the live server.
The advantage of that is when developing i can run into JS trouble and fix it very simply, but i need to run each changed script through a minimizer, but for me its not that much.
构建或部署到阶段环境时是压缩 javascript 的好时机。 这样您将有机会在舞台环境中测试它并捕获可能发生的任何错误。
有时，压缩时会出现错误。 您可能需要包含在压缩之前运行的 jslint 命令行版本，以确保 js 通过。 这将最大限度地减少但不能消除所有压缩错误。
When building or deploying to a stage environment is a good time to compress javascript. That way you will have a chance to test it in the stage environment and catch any errors that could occur.
Occasionally, there are errors that do come up when compressing. You may want to include a command-line version of jslint that runs before compressing, to make sure that the js passes. That will minimize, but not eliminate, all compression errors.
我想，除非您向 JavaScript 添加动态数据（在这种情况下有更好的方法），否则 on-the-fly 是不必要的。 IT 只是一种不必要的支出，只会减慢页面加载速度。
就我个人而言，我会在部署/构建应用程序时这样做，这确实是一次性的事情。
I'd imagine that on-the-fly would be an unnesessary unless you were adding dynamic data to the JavaScript (in which case there are better ways around it). IT's just a needless expenditure that will only slow down the page load.
Personally, I'd do so when deploying/building the app, it's a one-time thing really.
我想说的是，您拥有 js 文件，因为您在源代码管理中对其进行编码，当您启动自动构建时，作为构建脚本的一部分，它会通过压缩器运行所有 javascript 文件。 这样，当您将其部署到测试/登台环境时，您不仅可以获得最新的脚本，而且还可以进行压缩以进行性能测试，就像它们投入生产后一样。
I'd say you have the js files as you'd code them in source control, when you kick off an automated build that's when, as part of your build script, it runs all the javascript files through a compressor. This way when you deploy it to a test / staging environment you've got the latest script but also compressed for performance testing and as they would be once they go to production.
我同意，如果 JS 不改变，on-the-fly 可能并不是真正必要的（并且会占用一些 cpu 周期）。
可能涉及一些中间件，它们可以检查 JS 是否已更改，并仅在请求时才压缩它（甚至可能将各种 JS 文件分组为一个结果文件）。
部署时的一个好处可能是添加一些时间戳或随机字符串作为 JS 链接的参数（例如
.../scripts.js?t=cdkjnsccsds7sc8cshcsjhbcs）。 这样，当 JS 更改时，您可以使用不同的字符串，并且不会出现缓存问题，因为它是新的 URL。 CSS 也一样。I agree that on-the-fly is probably not really necessary (and eats up some cpu cycles) if the JS does not change.
There might be some middleware involved though which can check if the JS has changed and compress it only if requested (and maybe even group various JS files into one resulting one).
A good thing when deploying might also be to add some time stamp or random string as parameter to the JS link (e.g.
.../scripts.js?t=cdkjnsccsds7sc8cshcsjhbcs). That way when the JS changes you use a different string and there will be no caching problems because it's a new URL. Same for CSS.