xml地图|网站地图|网站标签 [设为首页] [加入收藏]
刨根问底,Chrome开发者工具不完全指南
分类:web前端

Web性能优化:图片优化

2014/12/20 · JavaScript · 图片, 性能优化

原文出处: wizcabbit的博客   

HTTP Archieve有个统计,图片内容已经占到了互联网内容总量的62%,也就是说超过一半的流量和时间都用来下载图片。从性能优化的角度看,图片也绝对是优化的热点和重点之一,Google PageSpeed或者Yahoo的14条性能优化规则无不把图片优化作为重要的优化手段,本文覆盖了Web图片优化的方方面面,从基本的图片格式选择、到尚未被广泛支持的响应式图片均有所提及。

Google Web Fundamentals的说法我很喜欢:

图片优化既是一门艺术,也是一门科学,图片优化是一门艺术,是因为单个图片的压缩不存在最好的特定性方案,而图片优化之所以是一门科学,是因为许多开发得很出色的方法和算法可以明显减小图片的大小。要找到图片的最优设置,需要按照许多维度进行认真分析:格式能力、编码数据内容、像素尺寸等。

传送门:跳过理论直达自动优化图片 点这里

图片 1

Chrome开发者工具不完全指南(六、插件篇)

2015/07/13 · CSS, HTML5, JavaScript · Chrome, 插件

原文出处: 卖烧烤夫斯基   

本篇是Chrome开发者工具的结尾篇,最后为大家介绍几款功能强大的插件。在chrome商店里面有很多插件,没事建议大家去逛逛。不过需要FQ,所以诸位请自备神器。

一、皮肤插件

首先是大家期盼已久,翘首以盼的皮肤插件。这款插件叫DevTools Theme: Zero Dark Matrix.在商店中下载之,然后打开这个地址:chrome://flags,找到Enable Developer Tools experments (可以查找experments关键字迅速锁定之)勾选启用复选框。重启浏览器,打开开发者选项,点击小齿轮,可以看到Experments这选项,选择后在弹出面板中勾选 Allow custom UI themes,重启浏览,然后看到:

图片 2

高达上的皮肤就是这样出来滴。据说还有许多方式可以更改,不过露珠目前就用的事这种方式。有兴趣的同学可以去试试看。

二、Performance-Analyser(网页性能分析)
这款插件是用来分析你的网页加载性能的,包括http请求,执行期的时间,以及每种http请求文件的大小,占比。首先下载之,随意打开一个界面,按下插件图标,可以看到分析页面:

图片 3

你可以利用这款插件来分析你的界面资源加载的整体情况,并试着做一些优化和调整。

三、(FeHelper)WEB前端助手
这款插件包括了一系列功能,很丰富。是国人开发的,功能包括:json格式化,html格式化,二维码生成,编码规范检测等等不一而足。当你在浏览器中打开一个后台接口的时候,如果该接口返回的是json字符串,那么它会自动将其格式化。下面是它的一些功能列表,不具体一一示范:

图片 4

四、POSTMAN
该插件是模拟发送请求的,后台和前台开发人员都可以用到。它是一个简化版的fiddler,功能虽然没有它强大,但是界面胜之,操作性也胜之,还有规范的API,更新也一直在继续。所以用之有木有:

图片 5

五、Visual Event

网页事件监听,能帮你捕获到目前网页上的各个元素的事件监听状况。打开一个界面,按下扩展按钮:

图片 6

把鼠标放到有背景色的元素上去,可以看到它们的时间来源和绑定的函数。对于一些简单的事件检测还是蛮有用的。比较复杂的就没什么卵用了。

六、二维码扫描

这个功能对手机开发来说还是不错的。扫一扫就在浏览器中打开了。在FF浏览器中自带的功能,对于Chrome来说怎么可以木有呢?不过这功能太简单,太低档次,太多了(不过很有用)。就不上图了。

七、WhatFont

找到网页的字体。开启功能后把鼠标停留在文本上,会弹出该字体名称。所以你可以所以copy你喜欢的字体啦。

八、Speed Tracer

这个是一个强大版本的性能分析器,比Profiles还强大。可以跟踪事件,查看css样式,找到js中内存泄露,检测js语法。功能之强大,无出其右!Speed Tracer是一款很强大的网页性能分析工具,通过它你可以找到你的网页运行缓慢的原因。针对它们改善网站。不过因为它的功能强大,所以操作比较复杂。篇幅原因露珠不做介绍。感兴趣的同学可以自己去捉摸捉摸。下面是盗图一张:

图片 7

结束语、

到此为止,露珠的Chrome开发者工具不完全指南系列宣告结束,露珠通过了六篇博文,向诸位比较想尽地介绍了chrome开发者工具的功能使用。从基础的dom查找到性能分析,大体上涵括了前端开发的各个方面。在如今前端开发日益复杂的趋势下,掌握了几件好的工具,是可以能够事半功倍的。而chrome毫无疑问的是这些好工具中的一个。讲到这里露珠想到《庄子》里面的一个故事:有一天孔子的学生子贡经过一块菜畦,看到有一位老者为了浇水而打了一条通向水井的地道,然后抱着水瓮来回于水井和菜畦之间,为的是给菜畦浇水。子贡见了就对老者说这样打水太累,为什么不自己做一个打水的机器呢?种菜的老人说:“有机械之事者必有机心。机心存与胸,大道不载也”。意思是有了偷懒的心,人就变得懒,这不是人的本性,也不是天的本性,所以大道也就不会充实他的心田。其实露珠想说运用工具和偷懒或机心是两回事儿,时代在变迁,人类早就不再是刀耕火种的人类了,如果一直停在旧的时代,跟不到新时代的进步,不学会与时俱进这样只有被历史淘汰。这跟我们现在处的环境是一样的,特别是前端开发,技术更新跟翻书一样快,隔三差五的新框架出现,几年的时间就有一大堆新鲜的东西跳将出来把你们吓一跳,不仅仅开发的时间在增加,学习的成本也在不停增加,所以时间变得尤其宝贵。如果有好的工具可以在少付出的情况下为我们达到同样的目的,何乐而不为呢?毕竟大家的目标都一样,只是殊途同归罢了。当然,庄子是道家人物,借个故事来调侃儒家也是理所当然,断章取义还是不行滴哈。

1 赞 14 收藏 评论

图片 8

CSS十问——好奇心+刨根问底=CSSer

2015/06/24 · CSS · 1 评论 · CSS

原文出处: 一个小学生   

最近有时间,想把酝酿的几篇博客都写出来,今天前端小学生带着10个问题,跟大家分享一下学习CSS的一些体会,我觉得想学好CSS,必须保持一颗好奇心和刨根问底的劲头,而不是复制粘贴,得过且过。本人能力有限,这篇文章从构思加完成用了四五天,如果你和我一样是前端小白,不妨仔细斟酌体会,以期领悟到一些东西;如果你是业界大牛,也请你驻足随意瞄上两眼,把言辞内容不妥的地方指出来,我们共同讨论。

时刻保持好奇心

  第一问:当margin的值为百分比形式时,为什么浏览器会根据父容器宽度得出计算值?

在我之前一篇博客检验你的前端基础——Sit the test中,聊到了margin值为<percentage>时的计算方法。假如有一个父容器宽度400px,高度600px,其子元素设置margin:20% 20%后的计算值应该为“margin:120px 80px”还是“margin:80px 80px”呢?按照那篇博客中的理论,第二个是正确答案。但是在今天这篇文章中,我给出的答案是第一个肯定错,第二个也不一定对。一个符合W3C标准的浏览器会根据父容器的宽度进行计算,但是这个仅限于书写模式为横向的时候。因为在横向排版时,宽度“有迹可循”,可以把浏览器宽度作为参考,但是高度是不固定的,所以margin百分比值在计算时会参考父容器的宽度。当书写模式改为纵向,其计算参考便会变为父容器的高度了。戳我查看DEMO(请在webkit内核或IE下查看)。

CSS

/*修改书写模式*/ .demo{ -webkit-writing-mode: vertical-rl; /* for browsers of webkit engine */    writing-mode: tb-rl; /* for ie */ }

1
2
3
4
5
/*修改书写模式*/
.demo{
    -webkit-writing-mode: vertical-rl; /* for browsers of webkit engine */
   writing-mode: tb-rl; /* for ie */      
}

  第二问:margin:auto为什么只能实现水平居中,不能垂直居中?

当一个常规流块级元素的margin属性左右值设为关键字auto,且它拥有固定宽度时,它便会平分剩余的水平空间,居中显示。然而如果设置上下值为auto,浏览器得到的计算值为0,并不起任何的效果。那么问题来了,为什么垂直方向的auto不生效?

与上一问类似,这与布局相关。网页排版时,常规流的块级元素水平方向总是铺满浏览器窗口,垂直方向各块级元素按照先后顺序从上往下排列,当页面内容过多时网页会出现纵向滚动条,因此原理上纵向是可以无限扩展的,计算时找不到一个固定的参考值,所以纵向的auto无法生效。

同样,margin:auto会受书写模式的影响。当书写模式为纵向时,margin:auto垂直方向是可以居中的,水平方向仍然可以居中。不信?请自己写个demo试试吧。其实受到书写模式影响的属性除了这些外,还有margin折叠、padding百分比值的计算等。

  第三问:可以让一个position:fixed的元素相对于一个容器定位而非浏览器视口吗?

提到position:fixed,很多人都会说这是一个定位属性,与absolute的区别是它针对浏览器视口定位。我的博客导航栏就是利用“position:fixed”属性,让其始终保持在窗口的最上方。不过还是不要忘记“世事无绝对”,CSS实现了一个position:fixed的元素相对于一个容器定位,请在FireFox下查看此DEMO。

当一个元素应用了CSS3的transform属性后,它的后代元素的fixed都将失效。。因此可以利用这个Bug模拟出一个相对于某个包含块fixed的效果。

关于transform更多的影响可以在张鑫旭的博客中看到:CSS3 transform对普通元素的N多渲染影响。

  第四问:可以用CSS实现面板的隐藏和显示吗?

现在要实现这样一个功能,通过CSS切换某个面板的显示或隐藏。当提到CSS,我们自然而然想到了控制某个单一元素的样式,一旦涉及到多个元素交互,我们往往使用JavaScript操作Dom。事实上这个需求不但可以用CSS来实现,甚至实现方式不止一种,请狂戳DEMO:三种CSS方式实现面板隐藏和显示。

第一种利用了label和checkbox,使控制方和被控制方不需要有特定的HTML结构关系,但是需要额外的HTML标签来支持。第二种方式利用了hover和子元素选择器,第三种方式利用了focus和兄弟元素选择器,后两种都受限于特定的HTML结构。三种方法都只使用CSS实现了面板的隐藏显示。

  第五问:可以用CSS做出一个图标吗?比如一个三角形?一个小房子?

一个标签,放在HTML中,只能代表一种语义。然而一个标签加CSS,则可以创造出无限的可能。请看DEMO:CSS实现三角形,小房子图案。

利用border互相覆盖呈现出的斜线,可以模拟出多种多样的几何状。在CSS3中,每个元素都有::before和::after两个伪元素,对同一个标签,由CSS可以操控的单位由一个变为三个,再加上绝对定位的辅佐,各种各样的形状被创造了出来。

图片 9

你能想象吗?这些图标都是用CSS画出来的。要想了解更多的CSS3图标,可以访问这个网站:

  第六问:我想写针对IE6,7的hack,该怎么写呢?

你可能会这么回答:使用 “>”,“_”,“*”等各种各样的符号来写hack。是的,这样做没错,但是需要记住每个符号分别被哪些浏览器识别,并且如果写的太乱将造成代码 阅读起来十分困难。学习CSS必须抱有一种质疑精神,有没有一种hack方法可以不写这些乱七八糟的符号,并且代码易维护易读呢?我们可以看看好搜首页是怎么做的:在页面顶端有这样一句话:

XHTML

<!DOCTYPE html> <!--[if lt IE 7 ]><html><![endif]--> <!--[if IE 7 ]><html><![endif]--> <!--[if IE 8 ]><html><![endif]--> <!--[if IE 9 ]><html><![endif]--> <!--[if (gt IE 9)|!(IE)]><!--><html class="w3c"><!--<![endif]--> <head>

1
2
3
4
5
6
7
<!DOCTYPE html>
<!--[if lt IE 7 ]><html><![endif]-->
<!--[if IE 7 ]><html><![endif]-->
<!--[if IE 8 ]><html><![endif]-->
<!--[if IE 9 ]><html><![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--><html class="w3c"><!--<![endif]-->
<head>

在页面的CSS中,会看到这样的规则:

CSS

.ie7 #hd_usernav:before, .ie8 #hd_usernav:before { display: none } .ie6 .skin_no #hd_nav li, .ie7 .skin_no #hd_nav li, .ie8 .skin_no #hd_nav li { border-right-color: #c5c5c5 } .ie6 .skin_no #hd_nav a, .ie7 .skin_no #hd_nav a, .ie8 .skin_no #hd_nav a { color: #c5c5c5 } ……

1
2
3
4
5
6
7
8
9
10
.ie7 #hd_usernav:before, .ie8 #hd_usernav:before {
    display: none
}
.ie6 .skin_no #hd_nav li, .ie7 .skin_no #hd_nav li, .ie8 .skin_no #hd_nav li {
    border-right-color: #c5c5c5
}
.ie6 .skin_no #hd_nav a, .ie7 .skin_no #hd_nav a, .ie8 .skin_no #hd_nav a {
    color: #c5c5c5
}
……

这样做的优点就是克服了使用特殊符号hack的那些缺点,缺点是需要写更多的代码,使页面增大。

一个前端er对上面这些问题知道与否,并不影响他是否可以完成一个项目,建设一个网站。但是如果没有好奇心,不想追究内在原因,仅抱着“我不想知道这么多东西,反正我会用就行”这样一种态度,那么他充其量算是一个“程序员”,而非一位“工程师”。

就是要刨根问底!

  第七问:行内级元素可以设置宽高吗?**

不会为自身内容形成新的块,而让内容分布在多行中的元素叫做行内级元素。此类元素可以与其它行内级元素在同一行中显示而不会另起一行,例如span,strong。在面试时,当被问到行内级元素可否设置宽高时,根据我们的经验往往会回答不能。但是这样往往着了面试官的道,因为有一些特殊的行内元素,比如img,input,select等等,是可以被设置宽高的。一个内容不受CSS视觉格式化模型控制,CSS渲染模型并不考虑对此内容的渲染,且元素本身一般拥有固有尺寸(宽度,高度,宽高比)的元素,被称之为置换元素。比如img是一个置换元素,当不对它设置宽高时,它会按照本身的宽高进行显示。所以这个问题的正确答案应该是置换元素可以,非置换元素不可以

  第八问:CSS规则根据优先级生效,低优先级的规则会被浏览器忽略还是覆盖?

在我的之前一篇博客中,提到了浏览器中CSS优先级的使用规则:多个优先级的样式都会被渲染,只不过高优先级会覆盖住低优先级,元素呈现为高优先级的样式。现在请考虑这样一个问题,在一个div应用了两条background-image规则,照之前的理论来看,两条规则都会渲染,那么请问浏览器会请求被覆盖规则的背景图片吗?

真实情况是浏览器会聪明到只请求当前应用的背景图片。简单理解的话,浏览器只会为生效的CSS规则中的图片资源发出http请求。如果深究的话,就必须谈谈浏览器的工作原理了。本人目前水平不够,以下红色字体为个人理解,请选择性阅读。

在现代浏览器中,一个页面从请求到呈现,大致需要经过解析-构建DOM树-构建呈现树(框架树)-布局(重排)-绘制等几个步骤。一个页面的展现并不是一蹴而就的,而是分步骤有条不紊的进行。众所周知的样式表层叠顺序和特异性计算发生在构造呈现树的过程中,就是为了解决规则不止一个时的问题。以上面提到的背景图案为例,浏览器计算完优先级后,只有后定义的背景图案规则被构建到呈现树上。接下来浏览器会进行重排和绘制,浏览器在绘制时才会请求背景图片规则用到的图片文件。这就是为什么只发出一个HTTP请求的原因。

了解浏览器的工作原理不仅可以认清CSS解析和渲染过程,还可以体会到重排和重绘发生的时机,这对我们写出高效的CSS规则和JavaScript Dom操作有着非常深刻的指导意义。这个话题太大,目前我的水平也不足以涉猎到此,等学有所成后我会再发一篇文章详细谈谈。这里有一篇经典的文章,感兴趣的可以看看:浏览器的工作原理:新式网络浏览器幕后揭秘。如果无法访问,查看此国内地址:w3ctech:浏览器的工作原理。

第九问:使用margin可以做出圆角按钮的原理是什么?

当不能使用border-radius时,如何制造一个圆角按钮?现在有一个制造1px圆角的小技巧:button中嵌套span,设置span的margin为:“margin:1px -1px”。戳我查看DEMO。

知道这个小tip的人不在少数,那么是什么原理导致这种现象呢?学习CSS就需要刨根问底,一张图可以把这个问题说明白。

图片 10

图中红色框为span标签,蓝色框为a标签。当设置span的左右margin为-1px时,其便会在左右各突出1px,造成一种1px圆角的视觉效果。同样的道理,在实现一些古老浏览器下的圆角与底色渐变的按钮时,通常也会利用到多层元素层叠制造视觉误差的原理。

  第十问:清除浮动有N种方式,他们间有什么共同点吗?

所谓清除浮动,一般是为了解决子元素浮动导致父容器高度坍塌。目前有多种方式来解决这个问题,最常见的有after伪元素,父元素设置“overflow:hidden”等等,请看DEMO:七种清除浮动的方法。

其实按照原理,这几种方法可以归纳为两种:clear:both法和构造BFC法。

方法 分类
浮动末尾添加新标签,设置样式为clear:both clear:both
浮动末尾添加<br />标签 clear:both
使用::after伪元素 clear:both
父元素设置display:table 构造BFC
父元素设置overflow:auto 构造BFC
父元素设置overflow:hidden 构造BFC
让父元素也浮动 构造BFC

使用“clear:both”来清除浮动自然不必多说,那么什么是构造BFC法呢?

Block formatting contexts(BFC),块级格式化上下文是在CSS2.1中提出的一个概念,在布局中,BFC自成体系,对自己内部的元素负责,不会与浮动元素重叠,相邻BFC上下margin也不会重叠。所以我们会通过构造一个BFC来防止margin重叠,清除浮动或者实现一个双栏布局。

那么如何构造一个BFC呢?1.float设置为非none值;2.overflow设置为非visible;3.display设置为table-cell,table-caption,inline-block;4.position设置为absolute或fixed。这些方法刚好与上面提到构造BFC来清除浮动的方法相呼应。

需要特别注意的是,在IE6,7下没有BFC这个概念,但是有一个与BFC性质相似的概念:layout。在IE6,7中遇到的很多bug都可以通过让元素has layout来解决,比如浮动margin双边距,躲猫猫,3像素间距等等。

有些元素例如table,input本身就has layout,那么如何让一个普通元素has layout呢?包括但不限于以下几种方法:1.position:absolute;2.float不为none;3.display:inline-block;4.height:除auto外任意值;5.width:除auto外任意值;6.zoom:除normal外任意值;7.overflow非visible(仅限IE7)。

这也是为什么我们会在IEhack中经常看到“height:1%”、“zoom:1”、“display:inline-block”、“overflow:hidden”这些字眼的主要原因,其实就是为了让元素has layout嘛!

所以在IE6-7下,清除浮动除了可以使用clear:both外(::after伪元素无法使用),另一种方法就是让父元素has layout。

关于清除浮动更多的探讨可以在一丝冰凉的博客中看到:那些年我们一起清除过的浮动。

总结

学习任何一门语言,或者一个事物都不能得过且过,抱着前人播种后人收的思想。纵然站在巨人的肩膀上可以少走很多弯路,但是个人仍然要保持好奇心和刨根问底、质疑的精神。多想一下“为什么”,少记一些“该这样做”,这在CSS的学习中尤其重要。

CSS很简单,她的出现仅仅是为了排版。CSS很复杂,一个简单的排版往往有N种解决方案。

望诸君共勉。

2 赞 8 收藏 1 评论

图片 11

真的要用图片吗?

要实现需要的效果,真的需要图片吗?这是首先要问自己的问题。浏览器和Web标准的发展速度极快,记得数年前我在用微软Silverlight 1.0写视频播放器的时候,中文还不能使用自定义字体显示,所以那时候写了很多糟糕的代码把需要的文字在服务器上生成图片并缓存起来。用户下载起来很慢,搜索引擎也完全无法检索这些文字。

但是现在不一样了,很多特效(渐变、阴影、圆角等等)都可以用纯粹的HTML、CSS、SVG等加以实现,实现这些效果少则寥寥数行代码,多则加载额外的库(一张普通的照片比非常强大的效果库也大了许多)。这些效果不但需要的空间很小,而且在多设备、多分辨率下都能很好的工作,在低级浏览器上也可以实现较好的功能降级。因此在存在备选技术的情况下,应该首先选择这些技术,只有在不得不使用图片的时候才加入真正的图片。

备选技术

  • CSS效果、CSS动画。提供与分辨率无关的效果,在任何分辨率和缩放级别都可以显示得非常清晰,占用的空间也很小。
  • 网络字体。现在连很多图标库都是用字体方式提供,保持文字的可搜索性同时扩展显示的样式。

前端工程师最好能和设计师、产品经理保持沟通,帮助他们了解到什么样的效果比较“简洁、高效、可维护”,毕竟对于CSS来说改变圆角矩形的Radius可以实时看到效果,用图片的话至少要重新生成图片、切图并替换资源。Retina、高分辨率屏幕、多尺寸的设备,这些都加快了非图片特效的发展,想想在高分辨率屏幕下Windows 7的惨不忍睹,就知道原生的图片资源绝对不是多多益善。

图片格式的选择

如果效果真的需要图片来表现,那么选择图片格式是优化的第一步。我们经常听到的词语包括矢量图、标量图、SVG、有损压缩、无损压缩等等,我们首先说明各种图片格式的特点

图片格式 压缩方式 透明度 动画 浏览器兼容 适应场景
JPEG 有损压缩 不支持 不支持 所有 复杂颜色及形状、尤其是照片
GIF 无损压缩 支持 支持 所有 简单颜色,动画
PNG 无损压缩 支持 不支持 所有 需要透明时
APNG 无损压缩 支持 支持 Firefox
Safari
iOS Safari
需要半透明效果的动画
WebP 有损压缩 支持 支持 Chrome
Opera
Android Chrome
Android Browser
复杂颜色及形状
浏览器平台可预知
SVG 无损压缩 支持 支持 所有(IE8以上) 简单图形,需要良好的放缩体验
需要动态控制图片特效

其中APNG和WebP格式出现的较晚,尚未被Web标准所采纳,只有在特定平台或浏览器环境可以预知的情况下加以采用,虽然均可以在不支持的环境中较好的功能降级,但本节暂不讨论这两种格式。图片格式选择过程如下:

图片 12

颜色丰富的照片,JPG是通用的选择

  • 人眼的结构很适合查看JPG压缩后的照片,可以充分的忽略并在脑中补齐细节
  • JPG在压缩率不高时保留的细节还是不错的
  • WebP能够比JPG减少30%的体积,但目前兼容性较差

如果需要较通用的动画,GIF是唯一可用的选择

  • GIF支持的颜色范围为256色,而且仅支持完全透明/完全不透明
  • GIF在显示颜色丰富的动画时可能出现颜色不全、边缘锯齿等问题

如果图片由标准的几何图形组成,或需要使用程序动态控制其显示特效,可以考虑SVG格式

  • SVG是使用XML定义的矢量图形,生成的图片在各种分辨率下均可自由放缩
  • SVG中可以通过JavaScript等接口自由变换图片特效,可以完成其中部分元素的自由旋转、移动、变换颜色等

本文由澳门新葡亰手机版发布于web前端,转载请注明出处:刨根问底,Chrome开发者工具不完全指南

上一篇:没有了 下一篇:没有了
猜你喜欢
热门排行
精彩图文