Sprite/PNG 图形较多的网站,天哪!

发布于 2024-07-27 04:53:30 字数 196 浏览 7 评论 0原文

我需要创建一个图形较多的网站(撕破的纸张背景,纹理图形上有透明阴影等)。我考虑节省文件大小的一种方法是将所有背景元素放入一个 PNG 中。 问题是这个文件现在有 180k。 如果我把它分成各种 GIF 和几个 PNG,那么它会接近 70k。

真的有关系吗? 如今对于文件大小来说什么是“太大”? 有人会注意到文件是 180 还是 70k 吗?

I need to create a site that is very graphics-heavy (torn paper backgrounds with transparent shadows over textured graphics, etc.) One way that I was thinking of saving on file size was to drop all my background elements into one PNG. The issue is that this file is now 180k. If I break it up into various GIFs and a couple PNGs then it would be closer to 70k.

Does it really matter? What is "too large" these days for file size? Will anyone notice if the file is 180 or 70k?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

下雨或天晴 2024-08-03 04:53:30

如果您的用户可以快速访问您的站点(例如在 Intranet 中),180k 几乎不是问题。 另一方面,如果该网站由“连接速度缓慢的普通老年人”使用,则可能会出现问题。 如果您的用户使用 GPRS,但有无限的耐心,这可能不会成为问题。 如果该网站向有耐心等待加载时间的人提供一百万美元,那么传输速度就不是问题。 等等。

我所说的,这实际上取决于您的要求和限制。 这需要您了解(并随后告诉我们,以便我们提供更多帮助)许多事情,然后才能接近正确。

为了避免对非常有效的答案但简单地不讨喜某人的讨厌的否决,这是我的答案:

180k 除以标准 ADSL 调制解调器传输速率 = 180kB / 100kB/s = 1.8s = 耐用。

If your users have fast access to your site (like, in an intranet), 180k is hardly a problem. If, on the other hand, the site is used by The Generic Older Person With A Humorously Slow Connection, it's probably going to be a problem. If your users use GPRS, but have endless patience, it's probably not going to be a problem. If the site gives out a million dollar to whoever has the patience to wait out the load time, transfer speeds are not an issue. And so on.

What I'm saying, it really depends on your requirements and constrains. This requires you to know (and subsequently tell us, for us to be more helpful) many things before you can get it close to right.

To avoid those pesky downvotes for very-valid-answers-but-simply-doesn't-please-someone, here's my answer:

180k divided by a standard ADSL modem transfer rate = 180kB / 100kB/s = 1.8s = endurable.

奈何桥上唱咆哮 2024-08-03 04:53:30

是否有理由使用较小的图像? 听起来您已经将其分解了,那么为什么不采用更小、更快的方法呢?

从纯粹的相对论角度来看,70k 只需要 180k 所需下载时间的 38%(大约)。 如果您期望高流量或想要快速加载时间,那么每一点都会有所帮助。

Is there a reason not to use the smaller images? It sounds like you've already broken it up, so why not go with the smaller, faster method?

From a pure relativistic point of view, 70k will take only 38% of the download time that 180k would (approximately). If you're expecting high traffic or want fast load times, every bit helps.

久而酒知 2024-08-03 04:53:30

您必须比较请求所有单独图像所需的时间和下载一张大图像所需的时间。 问题出在 HTTP 请求上。

我建议您使用 Google 的 Firefox 扩展 Pagespeed 运行一些测试,看看是否有大png 或单独的png 之间存在巨大差异。

我能想到的一个好处是,除了更少的 HTTP 请求之外,您的网站将一次性加载所有内容,而不是在下载所有图形时逐渐加载。 然而,正如 Henrik 所说,底线是这取决于您的要求。

You have to compare the time it takes to request all the separate images and the time it takes to download the one large one. The issue is with HTTP requests.

I suggest you run some tests with Google's Firefox extension, Pagespeed to see if there is a huge difference between the large png or the separate ones.

One benefit I can think of, besides fewer HTTP requests is that your site will load all at once instead of gradually as all the graphics are downloaded. The bottom line however, as Henrik said is that it depends on your requirements.

是你 2024-08-03 04:53:30

我相信您知道分割成多个图像意味着与服务器的额外连接以检索它们,每个图像都有相关的延迟,以及请求和响应标头的额外大小。

由于浏览器限制到每个服务器的活动连接数量(取决于浏览器版本),这最终可能比检索单个图像花费更长的时间。 解除限制的常用解决方法是使用单独的“图像”服务器,或映射到同一主机的 DNS 别名。

除非您需要动画,否则我总是推荐 PNG 而不是 GIF。

I'm sure you're aware that splitting into multiple images means additional connections to the server to retrieve them, with associated lag on each, and the additional size of the request and response headers.

Since browsers restrict the number of active connections to each server (browser version dependent) this may end up taking longer than retrieving a single image. The usual workaround to lift the limit is to use a separate "images" server, or a DNS alias that maps to the same host.

And unless you require animation, I'd always recommend PNG over GIF.

情独悲 2024-08-03 04:53:30

首先确保网站在禁用图像的情况下看起来不错(因此 alt 标签、宽度和高度设置、使用正确的颜色),然后将图像分成组。 如果可能的话,将所有按钮分组到一个图像中(使用 CSS 精灵表),并将所有边框分组到另一个图像中。 将大图像保存在单独的文件中(例如网站背景、标题)。

拥有的图像越多,浏览器可以并行处理的请求就越多。 但是,如果您将它们拆分太多,那么不同的图像将在不同的时间加载,从而使网站的某些部分弹出。这是一种权衡,但这就是编程的乐趣:)

您的网站在图像之前看起来越好可见,用户越不会介意下载图像的速度。

Make sure that the site looks fine with images disabled first (so alt tags, width and heights set, correct colours used) and then split the images based up into groups. Group all of your buttons into one image if possible (using css sprite sheets), and all of the borders into another. Keep large images in separate files (so site background, headers).

The more images you have, the more the browser can parallelize the requests. However, if you split them up too much then different images will load at different times, making parts of the site pop in. It's a bit of a trade off, but that's the joy of programming :)

The better your site looks before the images are visible, the less the user will mind the speed of downloading the images.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文