Image 当图像通常是最大大小的HTTP请求时，为什么要担心缩小JS和CSS？

我想我的问题说明了一切。由于许多成功的网站使用了大量用户输入的图像（例如Instagram），在我看来，源代码的缩减可能会错过时机

不管是为哪些设备（移动设备/桌面设备/两者）编写代码，开发人员的时间不应该花在担心他们提供的图像而不是代码大小上吗

为了优化速度较慢的移动浏览器，我想如果用户在手机上，最好是使用多个大小的图像并编写代码来提供最小的图像

---

这听起来合理吗？

首先，我不知道许多开发人员确实“担心”脚本的缩小。很多面向公众的网站并不麻烦

其次，缩小是去除不必要的空白，而减小图像的大小通常意味着降低图像的质量，因此存在一些差异

---

第三，我相信，如果在部署过程中实现一个小型化步骤不是那么容易的话，它将更不受欢迎。它不会节省很多带宽，但如果只需几分钟就可以配置一个部署脚本，那么为什么不呢？

100KB的数据对于中等大小的JS库来说并不是轻量级的。你应该尽可能优化你的网站。如果通过缩小一个脚本，你可以将它缩小到一半大小，然后通过gzip压缩它，再保存三分之一，你为什么不呢

我不知道你是如何缩小的，但是有很多脚本可以自动完成这个过程，并且经常会动态地将所有的JS捆绑到一个包中。这节省了带宽和麻烦

---

我的哲学总是“用你需要的”。如果可以在不损害任何东西的情况下为您和您的用户节省带宽，那么就这样做。如果你可以压缩你的图像，但它们看起来仍然不错，那么就这样做。同样，如果您有web应用程序绝对必须具备的某些功能，并且占用了相当大的空间，请无论如何使用它。

嗨，Spencer，谢谢您的想法，我并不主张不要缩小脚本，因为它非常简单。正如布拉德所说，为什么不呢？我想我只是想知道开发人员是否真的根据设备提供不同大小的图像。可能不是。但我怀疑客户端的带宽是否是改善网页大小的原因。至少当我们谈论10kb的差异时。用户不会注意到差异。不过，服务器带宽更昂贵，当您每小时提供几十万次点击时，10kb的带宽加起来很快。所谓“改进网页大小”，您的意思是“更快地加载网页”？我认为浏览器性能对企业的影响可能与服务器成本一样大。很抱歉，我澄清了我的意思。我认为缩小规模通常不会对客户产生实质性影响。如果网站管理员担心他们的页面需要很长时间才能加载，我想他们通常会寻找更大的空间来节省空间。消除内容、图片等。嗨，布拉德，谢谢你的想法，我不主张不要缩小你的脚本，因为这很容易。我想我只是想知道开发者是否真的根据设备提供不同大小的图像。看起来，网站通常可以有100多KB的图像或大型电影/歌曲文件，这些文件的大小甚至可以使100KB的JS库相形见绌。谢谢，我要这么做，你对最好的JS捆绑包有什么建议？我还是一个新手，所以简单易用对我来说仍然很重要。一般来说，JS和CSS请求会被阻塞，也就是说，理论上，在下载并解析引用的Javascript之前，浏览器不会“呈现”更多的html。对于图像，浏览器不会阻塞，图像可以在单独的线程上并行下载，而html处理将继续进行。因此，大型图像对用户体验的影响不会像html标题中提到的大型javascript文件那样大。嗨，Kiran，我正在页面底部加载我的JS，因此它应该是非阻塞的。另外，我不喜欢大图像在你眼前从上到下填充的渲染效果。它看起来很糟糕，人们开始考虑廉价网页。如果你可以根据设备提供更小的图像，那么你就不太可能看到这种自上而下的丑陋渲染，你不这么认为吗？