媒体查询与http请求

标签: CSS Tips media query 响应式设计 媒体查询 | 发表时间:2012-05-24 08:00 | 作者:神飞
出处:http://www.qianduan.net

Jason Grigsby发表了篇文章,《 CSS Media Query for Mobile is Fool’s Gold》对媒体查询(media query)吐槽,大意是在移动设备上使用媒体查询会造成很多资源的浪费——浏览器请求到很多用不到的图片等资源,然后 写了一些测试用例测试一些可用方法。然后Tim Kadlec写了篇《 Media Query & Asset Downloading Results》,用js自动化的测试了Jason Grigsby的用例。

本文主要整理自Tim的这篇文章。我们来看看到底会不会浪费资源,并寻找下最优的方案。

直接看结果吧~~

测试一:img标签

运行测试

本测试尝试通过对img标签的父级元素使用display:none来隐藏图片。HTML和CSS代码如下:

1
2
3
<div id="test1">
	<img src="images/test1.png" alt="" />
</div>
1
2
3
@media all and (max-width: 600px) {
	#test1 { display:none; }
}

测试结果

如果有一种应该100%避免的隐藏图片的方法,那就是display:none。它基本上是没有用的。貌似Opera Mobile和Opera mini不会下载图片,而其它浏览器都会下载。Opera可以比较好的控制资源的下载,对于用户看不到的内容,它不会预先下载。

浏览器 请求图片
Android 2.1+ 请求
Blackberry (6.0+) 请求
Chrome (4.1)+ 请求
Chrome Mobile 请求
Fennec (10.0+) 请求
Firefox (3.6+) 请求
IE 请求
iOS (4.26+) 请求
Kindle (3.0) 请求
Opera (11.6+) 请求
Opera Mini (6.5+) 不请求
Opera Mobile (11.5) 不请求
RockMelt 请求
Safari (4+) 请求

结论

很简单:不要这样用。

测试二:背景图片display:none

运行测试

在本例中,div被设置了background-image。如果屏幕宽度小于600px,div就被设置为display:none。HTML和CSS代码如下:

1
<div id="test2"></div>
1
2
3
4
5
6
7
8
#test2 {
	background-image:url('images/test2.png');
	width:200px;
	height:75px;
}
@media all and (max-width: 600px) {
	#test2 {display:none;}
}

测试结果

结果和测试一一样:除了Opera mini和Opera Mobile和 Firefox,所有浏览器都会下载图片。

浏览器 请求图片
Android 2.1+ 请求
Blackberry (6.0+) 请求
Chrome (4.1)+ 请求
Chrome Mobile 请求
Fennec (10.0+) 请求
Firefox (3.6+) 不请求
IE 请求
iOS (4.26+) 请求
Kindle (3.0) 请求
Opera (11.6+) 请求
Opera Mini (6.5+) 不请求
Opera Mobile (11.5) 不请求
RockMelt 请求
Safari (4+) 请求
Silk 请求

结论

同样:不要这样做。不过,像后面其它的测试,有其它的方法可以隐藏背景图片同时避免多余请求。

测试三:背景图片的父级元素被设置为display:none

运行测试

本测试中,对一个div标签设置背景图片,然后对其父元素(也是个div)在浏览器宽度小于600px时设置display:none。HTML和CSS代码如下:

1
2
3
<div id="test3">
	<div></div>
</div>
1
2
3
4
5
6
7
8
9
10
#test3 div {
	background-image:url('images/test3.png');
	width:200px;
	height:75px;
}
@media all and (max-width: 600px) {
	#test3 {
		display:none;
	}
}

测试结果

表面上,这个测试貌似和测试二没太明显的区别,但是结论是这个方法是比较靠谱的。。。

浏览器 请求图片
Android 2.1+ 不请求
Blackberry (6.0+) 不请求
Chrome (16+) 不请求
Chrome Mobile 不请求
Fennec (10.0+) 请求
Firefox (3.6+) 不请求
IE 9+ 不请求
iOS (4.26+) 不请求
Kindle (3.0) 不请求
Opera (11.6+) 不请求
Opera Mini (6.5+) 不请求
Opera Mobile (11.5) 不请求
Safari (4+) 不请求

结论

这个方法不错。除了不太成熟的Fennec,其它浏览器都不请求不必要显示的图片。

测试四:背景图片层叠

运行测试

本测试中,一个div被设置了背景图片。如果浏览器宽度小于600px,该div会被给到另一个背景图片。该测试用来检测是否两个图片都会被请求,还是只请求需要的。HTML和CSS代码如下:

1
<div id="test4"></div>
1
2
3
4
5
6
7
8
9
10
#test4 {
	background-image:url('images/test4-desktop.png');
	width:200px;
	height:75px;
}
@media all and (max-width: 600px) {
	#test4 {
		background-image:url('images/test4-mobile.png');
	}
}

测试结果

比设置display:none好一些,这种方法的结果有点儿乱:

浏览器 同时请求
Android 2.1-3.0? 请求
Android 4.0 不请求
Blackberry 6.0 请求
Blackberry 7.0 不请求
Chrome (16+) 不请求
Chrome Mobile 不请求
Fennec (10.0+) 请求
Firefox (3.6+) 不请求
IE 9+ 不请求
iOS (4.26+) 不请求
Kindle (3.0) 请求
Opera (11.6+) 不请求
Opera Mini (6.5+) 不请求
Opera Mobile (11.5) 不请求
Safari 4.0 请求
Safari 5.0+ 不请求

结论

我会避免使用这种方法。尽管环境在改善,但是在Android市场中占主导地位的Android 2.x版本依然会像Fennec和Kindle一样同时下载两个图片。三者中,尤其因为Android(的碎片化),我会推荐寻找别的方案。

测试五:大背景图片被设置min-width

运行测试

本测试中,一个div元素在浏览器宽度大于601px时被设置一个背景图片,然后在浏览器宽度小于600px时被设置为另一个背景图片。HTML和CSS代码如下:

1
<div id="test5"></div>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
@media all and (min-width: 601px) {
	#test5 {
		background-image:url('images/test5-desktop.png');
		width:200px;
		height:75px;
	}
}
@media all and (max-width: 600px) {
	#test5 {
		background-image:url('images/test5-mobile.png');
		width:200px;
		height:75px;
	}
}

测试结果

这种方案好一点儿:

浏览器 同时请求
Android 2.1+ 不请求
Blackberry (6.0+) 不请求
Chrome (16+) 不请求
Chrome Mobile 不请求
Fennec (10.0+) 请求
Firefox (3.6+) 不请求
IE 9+ 不请求
iOS (4.26+) 不请求
Kindle (3.0) 不请求
Opera (11.6+) 不请求
Opera Mini (6.5+) 不请求
Opera Mobile (11.5) 不请求
Safari (4+) 不请求

结论

这次更多的浏览器一起玩了。但是,Fennec一如既往得不能自已。Android 2.x比较怪异。它会同时请求两个图片——但只有在屏幕宽度大于600px匹配到min-width时才这样。这种行为貌似在Android 3.0版本中被改进了。这是件诡异的事情,我很好奇它为什么会这样。 其实,有个好消息。Jason Grigsby 说他的对本例的测试结果和我的不太一样。所以我又在一些Android 2.x机器上跑了一下这个测试。结论是,我最初的测试结果不太正确,Android 2.x表现很好,我最初测试的那个平台有问题。这不仅仅对于开发者来说是个好消息,对我本人来说更是恢复了对人类的信心。。。。。。。

但是这依然不够,你将需要对IE8以下浏览器提供替代方案,那些版本的浏览器不支持media query,所以没有图片会被显示。当然,这个问题可以用条件注释来简单的兼容一下。

测试六:背景图片display:none(max-device-width)

运行测试

本测试和测试二类似,但是使用了max-device-width来替代max-width。HTML和CSS代码如下:

1
<div id="test6"></div>
1
2
3
4
5
6
7
8
9
10
#test6 {
	background-image:url('images/test6.png');
	width:200px;
	height:75px;
}
@media all and (max-device-width: 600px) {
	#test6 {
		display:none;
	}
}

结论

好吧,不用浪费时间了,这个测试结果和测试二的基本一致。

测试七:层叠覆盖高分辨率

运行测试

最后一个测试,是为了new ipad提供的,它使用了retina屏幕,这样它就要使用更高分辨率的图片了。

本例中,一个div被给到一个背景图片。然后,通过使用min-device-pixel-ratio属性,如果比例大于1.5,一个新的背景图片将会被用到。

HTML和CSS代码如下:

1
<div id="test7"></div>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#test7 {
	background-image:url('images/test7-lowres.png');
	width:200px;
	height:75px;
}
@media only screen and (-webkit-min-device-pixel-ratio: 1.5),
only screen and (-moz-min-device-pixel-ratio: 1.5),
only screen and (-o-min-device-pixel-ratio: 3/2),
only screen and (min-device-pixel-ratio: 1.5) {
	#test7 {
		background-image:url('images/test7-highres.png');
		width:200px;
		height:75px;
	}
}

测试结果

浏览器 同时请求
Android 2.1-3.0? 请求
Android 4.0 不请求
Blackberry 6.0 不请求
Blackberry 7.0 不请求
Chrome (16+) 不请求
Chrome Mobile 不请求
Fennec (10.0+) 不请求
Firefox (3.6+) 不请求
IE 9+ 不请求
iOS (4.26+) 不请求
Kindle (3.0) 不请求
Opera (11.6+) 不请求
Opera Mini (6.5+) 不请求
Opera Mobile (11.5) 不请求
Safari 4.0+ 不请求

结论

为了安全,这个方案可以多测试一些。看起来这种方法在绝大多数情况下是可用的。但是不幸的是,貌似Android 2.x会同时下载两个图片 如果设备像素比大于或等于1.5时(或者你在media query中设置的别的任何值)。所以,在本例中,如果你使用了一个高分辨率的Android 2.x的设备,会比较苦逼。。。

好消息是,到目前位置,我还没听说有那一款Android 2.x的设备的屏幕比例超过1.5.所以如果你的项目面向使用retina屏幕的ios设备,你可以将min-device-pixel-ratio设置到2或者更高,这样会比较安全一点儿。。。

推荐

  • 如果你要隐藏一张内容图片,display:none是无效的,所以我推荐使用javascript方案或者服务器端实现;
  • 如果你要隐藏一张背景图片,最好的方法是隐藏其父级元素。如果你不方便这样做,那就用一个层叠样式覆盖掉它吧(就像上面的第五个方案),然后将设置background-image:none;
  • 如果你要切换多张图片,就把他们全部用media query定义吧。

关于响应式设计的思考

媒体查询现在最大的用处就是响应式设计了,神飞翻译这篇文章也是因为最近在思考响应式设计的效率问题。通过这些测试结果,我们在实现响应式设计的网站时,最好先处理移动设备,然后再向高分辨率设备升级。然后使用图片等外部资源的选择器,一定要写到媒体查询中去。

反馈

如果你觉得这些测试结果有任何错误的地方,欢迎在评论中提出,然后这些测试用例Tim都在 GitHub上开源了,感兴趣的话可以fork下。。。

相关 [媒体 http] 推荐:

媒体查询与http请求

- - 前端观察
Jason Grigsby发表了篇文章,《 CSS Media Query for Mobile is Fool’s Gold》对媒体查询(media query)吐槽,大意是在移动设备上使用媒体查询会造成很多资源的浪费——浏览器请求到很多用不到的图片等资源,然后 写了一些测试用例测试一些可用方法.

用nginx搭建基于rtmp或者http的flv、mp4流媒体服务器

- - 开源软件 - ITeye博客
这种方式要下载FLV视频文件到本地播放,一旦FLV视频文件下载完成,就不会消耗服务器的资源和带宽,但是拖动功能没有RTMP/RTMP流媒体方式强大,很多视频网站都是用HTTP方式实现的,如:YouTube,土豆,酷6等. 2、  RTMP/RTMP流媒体方式. 这种方式不用下载FLV视频文件到本地,可以实时的播放flv文件,可以任意拖拽播放进度条,但是比较消耗服务器的资源.

HTTP Headers 入门

- johnny - Time Machine
非常感谢 @ytzong 同学在twitter上推荐这篇文章,原文在此. 本文系统的对HTTP Headers进行了简明易懂的阐述,我仅稍作笔记. 什么是HTTP Headers. HTTP是“Hypertext Transfer Protocol”的所写,整个万维网都在使用这种协议,几乎你在浏览器里看到的大部分内容都是通过http协议来传输的,比如这篇文章.

HTTP基础

- - ITeye博客
HTTP的结构主要包括下面几个要点:. HTTP的版本主要有1.0,1.1 和更高版本.    1.1 及以上版本允许在一个TCP连接上传送多个HTTP协议,1.0能 .    1.1 及以上版本多个请求和响应可以重叠,1.0不能.    1.1 增加了很多的请求头和响应头.     一个请求行,若干小心头,以及实体内容,其中的一些消息头和实体内容是可选的,消息头和实体内容需要空行隔开.

HTTP Header 详解

- - 博客园_Ruby's Louvre
HTTP(HyperTextTransferProtocol)即超文本传输协议,目前网页传输的的通用协议. HTTP协议采用了请求/响应模型,浏览器或其他客户端发出请求,服务器给与响应. 就整个网络资源传输而言,包括message-header和message-body两部分. 首先传递message- header,即 http header消息.

HTTP/2 in Netty

- -
Here, we created a context for the server with a JDK SSL provider, added a couple of ciphers, and configured the Application-Layer Protocol Negotiation for HTTP/2..

HTTP负载测试

- - 博客 - 伯乐在线
英文原文: ON HTTP LOAD TESTING 来源: oschina. 有很多人在谈论HTTP服务器软件的性能测试,也许是因为现在有太多的服务器选择. 这很好,但是我看到有人很多基本相同的问题,使得测试结果的推论值得怀疑. 在日常工作中花费了很多时间在高性能代理缓存和源站性能测试方面之后,这里有我认为比较重要的一些方面来分享.

HTTP断点续传

- - CSDN博客互联网推荐文章
要实现断点续传的功能,通常都需要客户端记录下当前的下载进度,并在需要续传的时候通知服务端本次需要下载的内容片段. HTTP1.1协议(RFC2616)中定义了断点续传相关的HTTP头 Range和Content-Range字段,一个最简单的断点续传实现大概如下:.   1.客户端下载一个1024K的文件,已经下载了其中512K.

http-kit 1.2 发布

- - 开源中国社区最新新闻
Http-kit 是主要由Java 和Clojure开发,为Clojure定制的零依赖的Http lib,包括异步的高性能HTTP Server 和 HTTP Client. 在普通的PC上进行性能测试时,http-kit server 每秒能处理数万个请求. 修复处理文件上传时,content-type没能正确处理.

HTTP缓存算法

- - PHP源码阅读,PHP设计模式,PHP学习笔记,项目管理-胖胖的空间
HTTP协议缓存的目标是去除许多情况下对于发送请求的需求和去除许多情况下发送完整请求的需求. 以不发送请求或减少请求传输的数据量来优化整个HTTP架构,此目标的实现可以产生如下好处:. 降低对原始服务器的请求量. 减少了传送距离,降低了因为距离而产生的时延. 缓存基本处理过程包括七个步骤. 接收 – 缓存从网络中读取抵达的请求报文.