我们的应用程序中有数百个javascript文件，这些文件目前未压缩。我们要获得更多客户端性能的解决方案之一就是缩小我们的javascript文件。我已经创建了一个自动化的解决方案来在构建中执行此操作，但是，当部署这些新文件时，确定是否将其重新发送给客户端的文件时间戳将被更改。这意味着，在以后的每个发行版中，所有javascript文件都将具有新的时间戳。我们的客户将再次重新下载所有缩小的javascript文件，从而破坏了缩小的性能方面。

这是其他人遇到的问题吗？解决方案是什么？我们是否在项目中使用了单独的非最小化和最小化javascript文件，并且不对构建版本进行压缩？

我们还有其他解决方案(例如仅在源代码管理存储库中查找实际更改的文件)，但这是我想了解其他人正在做的一个问题。

解决方案

我们将必须确定实际更改了哪些文件。或者只是不用担心，享受通过缩小文件获得的改进。客户端可能无论如何都不会将文件长时间保存在缓存中，因此，除非我们非常非常频繁地更新文件，否则尝试管理缓存行为可能不会有什么好处。

我们可以在一段时间内推出这些脚本文件，这样就不会有单个用户的请求花费很长时间。但是说真的，我们在谈论多少JavaScript？一次性重新下载与页面相关联的脚本真的有那么大的意义吗？想一想我们将需要付出多少努力才能完成这项工作，并权衡收益。

我们可以编写一个脚本来检查源文件夹和目标文件夹中每个文件的CRC或者MD5哈希值，并且仅在文件已更改时才执行覆盖。这将为未更改的文件保留时间戳，从而为我们提供所需的缓存行为。

同样，我们可以记录前一个时间戳，进行覆盖，然后使用touch命令(假设这些文件在Unix系统上)将时间戳设置回其原始值。

第一种选择可能更好，而不是仅仅一直将时间戳始终设置为相同的值，因为这可能意味着某些客户端暂时不会拾取修改的JS文件，因为服务器声称它没有更改。

阅读Flickr名望的Cal Henderson的http://www.thinkvitamin.com/features/webapps/serving-javascript-fast。希望我们会发现它有用。