我想我的问题说明了一切。许多成功的网站使用大量用户输入的图像(例如 Instagram),在我看来,这似乎是天真的,源代码缩小可能会错过这条船。
不管一个设备正在编码(移动/桌面/两者),开发人员是否最好花时间担心他们提供的图像而不是他们的代码大小?
为了优化移动浏览器较慢的速度,我认为如果用户在手机上,最好有多个尺寸的图像并编写代码来提供最小的图像。
这听起来合理吗?
我想我的问题说明了一切。许多成功的网站使用大量用户输入的图像(例如 Instagram),在我看来,这似乎是天真的,源代码缩小可能会错过这条船。
不管一个设备正在编码(移动/桌面/两者),开发人员是否最好花时间担心他们提供的图像而不是他们的代码大小?
为了优化移动浏览器较慢的速度,我认为如果用户在手机上,最好有多个尺寸的图像并编写代码来提供最小的图像。
这听起来合理吗?
首先,我不知道许多开发人员确实“担心”脚本的缩小。许多面向公众的网站都不会打扰。
其次,缩小是去除不必要的空白,而减小图像的大小通常会降低其质量,因此存在一些差异。
第三,我相信,如果在部署过程中实施缩小步骤不是那么容易,那么它会更不受欢迎。它并没有节省太多带宽,但如果只需要几分钟来配置部署脚本来完成它,那为什么不呢?
100KB 的数据对于一个中型 JS 库来说并不是轻量级的。您应该尽可能优化您的网站。如果通过缩小脚本可以将其缩小到一半大小,然后通过 gzip 压缩它,再节省三分之一,为什么不呢?
我不知道您是如何进行缩小的,但是有许多脚本可以自动执行该过程,并且通常会将您的所有 JS 动态捆绑到一个包中。这节省了带宽和麻烦。
我的理念始终是“使用你需要的东西”。如果可以在不损害任何东西的情况下为您和您的用户节省带宽,那就去做吧。如果您可以将图像压缩得很低并且它们仍然看起来不错,那么就这样做。同样,如果您的 Web 应用程序绝对必须具有某些功能,并且它需要相当多的空间,那么无论如何都要使用它。