假设您设计了一个网页，并使用了 全屏背景图片。 您非常喜欢该网站使用此背景图片后的外观。 它看起来很棒。 但图片大小为 350k。 您已经决定，虽然知道这很重，但它值得这样做。
但随后您开始考虑移动设备。在小屏幕上，此大型背景图片并没有为设计增加太多内容，并且 350k 在带宽可能较低且总体速度可能较慢的设备上尤其繁琐。 然后考虑一下，移动浏览器通常具有更有限的缓存，因此即使这样也无济于事。 移动流量占您整体流量的 2%。
当然，您可以使用媒体查询在屏幕变窄时不显示背景图片，但这并没有太大帮助，因为该资源仍将被下载。 所以您陷入了困境
您是使用 350k 图片并陶醉于其美丽中，接受对 2% 用户的重大影响？还是放弃图片并接受页面变得有点丑陋但速度更快？
投票（在侧边栏中）将只有两个选项，迫使您做出选择。 但是，如果您认为自己会选择第三个选项，请将其作为评论留下。
更新
不知何故，我完全相信，即使在当前未激活的 @media 查询下，CSS 中引用的背景图片也会被浏览器下载。 我感觉我曾运行过测试用例，与人们讨论过它等等，但我一定是做梦了，或者浏览器已经修复了这个问题。 在读者 Ruben 提供的 此测试用例 中，您可以测试即使通过 @media 查询移除的背景图片也不会加载。
所以这个投票基本上无效……正确的答案是，您始终应通过 @media 查询移除 350k 图片。
有趣的问题。 我选择了保留，但我确实认为这取决于网站的用途。 如果它是一个画廊风格的网站，人们期望等待大型图形，那么我认为是可以的。 但是，如果它是一个人们需要快速获取信息的网站……那么我会避免它。
“当然，您可以使用媒体查询在屏幕变窄时不显示背景图片，但这并没有太大帮助，因为该资源仍将被下载。”
如果图片是通过 CSS 作为背景图片应用的，则可以将媒体查询设置为移动优先。 仅在桌面媒体查询中应用图片将阻止它在移动设备上下载。 问题解决了吗？
我相当确定这不是真的。 CSS 中的所有资源，无论媒体查询是否生效，都会被下载。 我认为这是故意的，这样如果另一个媒体查询突然生效，更改就可以非常快速地发生。
不是“所有”资源，而是所有适用的资源*。 只是为了澄清一些刚刚掌握 CSS 概念的人！ 如果您将一个 5mb 的图片作为未加载页面一部分的 div 的背景，则该图片不会被下载。
Chris 的说法不正确。 移动优先设计的理由之一是浏览器不会下载在桌面媒体查询中定义的资源。 您可以通过使用 Chrome 或 Firefox 中的 NET 选项卡轻松测试这一点。
这是一个很棒的功能
@Chris
如果您首先为小分辨率使用媒体查询，则不会下载较大的桌面资源（如巨大的背景图片）。 然后问题在于，您必须使用 JavaScript 来模拟 IE 的媒体查询，否则默认情况下会为其提供低保真度的移动版本。
查看 320 and up，它本质上是 Less CSS 框架的改进版本，可以实现此目的。
这是真的。您可以在此处进行测试。 请更正本文：媒体片段确实可以解决问题。
@Graham：无需模拟，只需“@media only”。
你说得对，确实如此。
我会更正这一点。 现在我很好奇我为什么会产生这种错误的理解。 我想知道，在支持媒体查询的早期版本的浏览器中，它们是否会下载所有适用资源，或者我只是错误地假设了这一点。
我认为您需要在那里添加另一个选项，用于某种查询以显示或不显示它。 如今，大多数网站都构建在某种平台上，我认为您可以通过仅查询 Web 而不是移动设备的图片来实现双赢。 或者另一个选项可能是使用 jQuery 来使用或不使用它。
无论哪种方式，我认为投票应该有一个“其他”选项，用于一些不同的路径，因为您提供的两个选项不一定是您拥有的唯一两个选项。
/我的 2 分钱！ :)
没错，使用 JavaScript 或服务器端检测来显示图片似乎是最佳选择。 它肯定比仅仅因为移动设备而放弃图片要好。
内联添加样式，并使用服务器端代理/浏览器嗅探将其隐藏在移动设备中。 是的，它违反了几乎所有规则（内联样式、浏览器嗅探），但它确实有效。
或者，您的服务器端嗅探代码可以简单地向元素添加一个类，而不是使用内联样式。
我喜欢 Matt Wilcox 的解决方案：http://adaptive-images.com/
它需要一点 PHP 和 .htaccess，但可以轻松集成到任何现有项目中，因此您无需重新编码您的网站。
同意！ Adaptive Images 绝对是一个非常优雅的解决方案，可以解决此问题！
我会使用某种形式的服务器端 (php) 程序来加载或不加载图片。
RussellUresti 说得对。
Chris，你确定如果你覆盖了移动设备的 background-image，它仍然会被下载吗？
干得好，伙计
http://adaptive-images.com/ 是最佳选择。 它只需几分钟即可实现，并且效果非常好。
首先，Chris，我是你的忠实粉丝。 内容很棒。
其次。 在某种程度上，您是否只需要依赖修改后的浏览器和未来移动手机的处理速度越来越快？ Opera Mini 和显然（希望它很好）Amazon Silk 使用不同的技术对图片进行下采样，以更快地将其交付给移动设备。 我看到的大多数使用旧手机的人甚至都不再尝试上网，因为所有网站的加载速度都慢得令人尴尬。
此外，由于他们现在几乎是在礼品袋中赠送新的智能手机，我认为更换速度比有人紧紧抓住运行 Windows XP 的旧机器要快得多。
所以，我说别管它，让它看起来好看。 自适应设计应该用于更好的阅读，而不是更快的下载。 仅为个人观点。
我认为这确实取决于网站的目的。
就像 Jonathan 说的那样，对于信息类网站来说，这不是一个好主意。
但如果网站的主要目标是娱乐或趣味性，或者网站的“魅力”比功能性更重要，我会使用它！
我明白你故意限制了选项来迫使做出决定，但正如评论中普遍共识的那样，最好的选择（至少对我来说）是某种自适应图像服务器端处理技巧。
我投票保留它。
我相信简洁高效的代码，但也意识到在当今的互联网浏览社会，随着宽带和4G连接的普及，350k 的大小并不是什么大问题。
我可能会使用一些JS在加载时检测屏幕宽度，然后获取正确的图像。如果我想做得更花哨一些，我可能会挂载到浏览器的resize事件，并在需要时动态更新图像。这种方法有什么问题吗？对我来说似乎很简单。
你总是可以通过javascript/jquery将图像添加到背景，并避免在移动设备上下载。
看看这个
http://jsfiddle.net/p4bl1t0/3xdZq/
因为它是一个背景图像，为什么不使用JS为桌面添加一个body类，并围绕它创建一个CSS规则呢？
“我相当确定这不是真的。CSS中的所有资源，无论媒体查询是否生效，都会被下载。”
不。还记得悬停CSS图像吗？它们只有在悬停实际触发时才会被使用。
只需将350k的图像提供给桌面（如果你真的需要），然后为移动设备提供其他图像。无论你是使用某种形式的CSS、JavaScript还是基于服务器的内容协商来实现后者，这都不重要。
我使用该图像，并为我的博客创建了一个更精简、更轻量级的移动版本。 :)
对于全屏背景图像，我将使用移动优先方法：使用较小的文件，并在浏览器/用户从中受益时替换为更高分辨率的文件。
这是测试。使用浏览器的网络检查器观察巨大的图像如何不加载。
然后将max-width更改为20，看看效果如何。
如果是我，我会在页面末尾添加一个JavaScript代码进行检测
如果是桌面，则添加CSS背景图像，甚至根据访客屏幕宽度和高度选择图像以减小图像大小。并使用Photoshop中的“存储为设备和网络”选项压缩图像。