我需要创建一个非常重图形的网站（撕裂的纸质背景，在纹理图形上带有透明阴影等）。我考虑节省文件大小的一种方法是将所有背景元素放入一个 PNG 中。问题是这个文件现在是 180k。如果我把它分解成各种 GIF 和几个 PNG，那么它会接近 70k。
真的有关系吗？这些天对于文件大小来说，什么是“太大”？有人会注意到文件是 180 还是 70k 吗？
问问题
884 次
5 回答
3
如果您的用户可以快速访问您的网站（例如，在 Intranet 中），那么 180k 几乎不是问题。另一方面，如果该网站被 The Generic Older Person With A Humorously Slow Connection 使用，这可能会成为一个问题。如果您的用户使用 GPRS，但有无尽的耐心，这可能不会成为问题。如果该网站向有耐心等待加载时间的人提供一百万美元，那么传输速度就不是问题。等等。
我在说什么，这实际上取决于您的要求和约束。这需要您了解（并随后告诉我们，以便我们提供更多帮助）许多事情，然后才能使其接近正确。
为了避免那些讨厌的反对非常有效的答案，但只是不讨好某人，这是我的答案：
180k 除以标准 ADSL 调制解调器传输速率 = 180kB / 100kB/s = 1.8s = 耐用。
于 2009-07-22T05:43:27.757 回答
1
有理由不使用较小的图像吗？听起来你已经把它分解了，那么为什么不使用更小、更快的方法呢？
从纯相对论的角度来看，70k 只需要 180k 下载时间的 38%（大约）。如果您期望高流量或想要快速加载时间，那么每一点都会有所帮助。
于 2009-07-22T06:02:44.207 回答
0
您必须比较请求所有单独图像所需的时间和下载一张大图像所需的时间。问题在于 HTTP 请求。
我建议您使用 Google 的 Firefox 扩展程序Pagespeed进行一些测试，看看大 png 或单独的 png 之间是否存在巨大差异。
我能想到的一个好处是，除了更少的 HTTP 请求之外，您的网站将一次性加载，而不是随着所有图形的下载而逐渐加载。然而，正如 Henrik 所说，最重要的是这取决于您的要求。
于 2009-07-22T06:22:40.297 回答
0
我相信您知道拆分成多个图像意味着与服务器建立额外的连接来检索它们，每个图像都有相关的延迟，以及请求和响应标头的额外大小。
由于浏览器限制到每个服务器的活动连接数（取决于浏览器版本），这最终可能比检索单个图像花费更长的时间。解除限制的常用解决方法是使用单独的“图像”服务器，或映射到同一主机的 DNS 别名。
除非你需要动画，否则我总是推荐 PNG 而不是 GIF。
于 2009-07-22T06:23:06.070 回答
0
确保网站看起来不错，首先禁用图像（因此设置了 alt 标签、宽度和高度，使用了正确的颜色），然后将图像分成几组。如果可能的话（使用 css sprite sheet）将所有按钮组合到一个图像中，并将所有边框组合到另一个图像中。将大图像保存在单独的文件中（因此网站背景、标题）。
您拥有的图像越多，浏览器可以并行处理的请求就越多。但是，如果您将它们分开太多，那么不同的图像将在不同的时间加载，从而使网站的某些部分弹出。这有点折衷，但这就是编程的乐趣 :)
您的网站在图像可见之前看起来越好，用户就越不会介意下载图像的速度。
于 2010-02-09T12:06:47.653 回答