前端性能优化—前端工程师不得不说的痛_心得技巧教程-查字典教程网

摘要：前言在上一篇文章《我的css架构理念》中，承蒙园内的朋友们抬爱，竟然一路被推荐，让我这小小一枚前端攻城狮既意外又兴奋进而惶恐。惶恐的是资历实...

前言

在上一篇文章《我的css架构理念》中，承蒙园内的朋友们抬爱，竟然一路被推荐，让我这小小一枚前端攻城狮既意外又兴奋进而惶恐。惶恐的是资历实在有限，知识实在匮乏，相当害怕误人子弟。此真心话！但接下来我依然会坚持有时间就写写文章，既能总结，又能学到新知识，还能分享给诸位，我认为，分享---是件功德无量的事，互联网不就是因此而绚丽多彩嘛！

上篇文章的留言里有好多朋友是对我css架构就http请求的问题提出质疑，我本想回答的，但不知道从何说起。前端性能方面的知识我了解得并不深入，囫囵吞枣地看过一两本重构的书、喜欢查查资料，看看一些大牛写的文章，觉得人家那么做有道理了，就搬过来用，林林总总的做些总结，于是有了此文。都不是什么新东西，但是因为小知识点太多，希望这里面的东西有你想要的答案吧。

前端性能优化--前端工程师不得不说的痛

1.html、css、js三者相分离。分离得彻底点！为什么这三者要分离，相信大家都明白，不多说。

2.css的导入方式。css用link而不用@import，因为在 IE 中 @import 指令等同于把 link 标记写在 HTML 的底部，延长css的载入时间，还可能出现文件下载次序被更改的情况。

3.理性对待jquery。jquery让我们“write less,do more”，它有太多优势：强大的选择器、DOM操作的完美封装、完善的Ajax、良好的兼容性处理。但是，我们是否就此离不开它呢？我觉得应该根据需求，根据业务逻辑来。一个页面如果只需要几行或几十行js代码可以搞定的效果，为什么要用jquery？让页面先加载个jquery.js，再书写自己的代码？没必要吧。

4.合理布局页面的内容。DOM的加载顺序是由上而下的，遇到css，加载css，遇到js，停滞下来，加载并解析js。在布局页面的时候，把主体内容优先显示，把重要内容靠上布局，让浏览器优先解析，是种较好的方案。

5.js的导入方式。《javascript王者归来》里有对js的导入方式进行优劣对比。我个人认为，在不考虑js代码重用及维护的前提下(但是往往这点成为我最重要的衡量指标)，把具有重要业务模块的js代码置于title里，把次要的具有操作效果的js代码置于DOM相对应的对象之后。而这样做的理论依据即DOM的加载顺序。上面那话不好理解，举例来说：

前端性能优化—前端工程师不得不说的痛1

上图是QQ音乐首页的导航，主导航的重要作用不言而喻，如下是两段相应的代码：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<head>

<title>test--js导入方式1</title>

</script>

</head>

<body>

<ul>

<li>

<div>

</div>

</li>

<li><a href="">下载客户端</a></li>

</ul>

</body>

</html>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<head>

<title>test--js导入方式1</title>

</head>

<body>

<ul>

<li>

<div>

</div>

</li>

<li><a href="">下载客户端</a></li>

</ul>

</script>

</body>

</html>

两段代码的js效果为鼠标移到MV菜单项时显示子菜单选项。第一段代码中，当浏览器解析到<script>标签时，会停滞下来，直到都解析完了，再继续往下，当MV显示时，我们鼠标一移上去，子菜单就会显示出来；而第二段代码中，浏览器解析到MV时，再到<script>，得先加载js，直到完成，子菜单才会显示。显然，对于这种重要功能模块，更适合采用第一段代码。关于这个原理，我理解的方向不知道有没有偏差或者错误，园中朋友有深入研究的请纠错。

6.图片文件格式的选择。关于这点，淘宝UED的图片格式与设计那点事儿有很深入地探讨，我个人觉得受益匪浅，但是文章太长，写得太深入，没耐心还真看不下去，所以后来我又自己总结了下，可以参考下三种图像文件格式的选择。当时总结完这篇文章后，工作的时候就严格按照这上面的来执行了。

7.sprites贴图技术。这是一项从一出现就备受争议的技术，第一、我们需要打开ps，把许多小图标有规则地排放在一起；第二、我们需要打开ps，最好再放大5倍，再水平垂直拉下两条参考线，然后对到标尺，记下left/top值，写到css文件里；第三、sprites贴图技术与height、line-height关系紧密，因为它们，第二点中定位的left/top又将变得不准确，这时你应该给图标之间留出一定的间隙，不然当心显示出来的都是一半的图标哦。我实在没精力再去截图写代码来证明我是对的，这个自己可以有。我似乎把这项技术说得一文不值，让Dave Shea情何以堪！贴图技术之所以到现在还在被广泛使用，我想最主要的原因就是它大大减少了请求数并在一定程度上减少了图片的总体积的缘故。跟这两点比起来，我前面所说的那些缺点似乎不值一提了。

8.让页面渐进增强。将分辨率、操作系统、浏览器、项目针对的用户目标群相结合，在页面制作的过程中采用渐进增强的原则。如果项目的用户目标群普遍采用的是1024*768、Mac os x、ie7+浏览器，那么在设计页面的时候，宽度要做相应的限制，最好水平不出现滚动条；字体也不再选择宋体，采用其他web安全字体；接下来我们开心了，因为可以不考虑ie6，是不是觉得工作忽然间变得很幸福？渐进增强不单单可以应用到大的方向上，还可以具体到单页面模块中;

前端性能优化—前端工程师不得不说的痛2

（图1)

前端性能优化—前端工程师不得不说的痛3

（图2）

图1和图2是截取自一列表中的一个li，图2为鼠标移到li上的效果--显示“取消关注”。我将在这模块中应用渐进增强原则：第一、需要考虑ie6，那么由于ie6不支持除了a标签以外的其他标签的hover效果，且“取消关注”又是个重要的功能，不要不行，所以只能采用js代码来实现鼠标移入移出效果；第二、如果不考虑ie6，那么假设“取消关注”的标签为span，就可以在css样式表里这么书写：li:hover span{display:block;}；第三、如果“取消关注”功能换成无关紧要文字显示，如时间显示，那么一样可以采用第二点写法，让其他浏览器显示、ie6不显示影响也不大。

9.少用滤镜、表达式和hack。这在很多重构书上都会被提到，项目中有对滤镜进行过测试，一堵照片墙过去，全用上滤镜，浏览器加载页面速度那个慢啊，亲眼见到了！表达式不晓得。hack打一开始就在规避，几乎没用过，所以不发表意见。

10.借助一些外在的应用来减少css、js文件的请求数。php程序的可以考虑用minify来把每个页面的css和js整合到一起，再在页面中进行调用，这样页面就只请求一次css和js，性能会优化许多。

我暂时能想到的就先写到这里了。关于前端性能的优化应该还有很多，这些都是皮毛而已，慢慢再深入了。好吧，再侃点其他的！

前端与美工人员

前端工程师上衔美工、下接后端、背靠产品，缺一不可。职责分工要明确，前端要告诉美工能少用图片尽量少用、合理地选择图片的文件格式、网站页面风格尽量同一、给出网站主业务链接色、辅链接色、主文本颜色和其他文字颜色等等。美工都是单一页面做出来的，往往没办法考虑到整个网站最终的效果，这个时候前端就应该起到一个提示的作用，如果这个环节没把该确定的东西确定下来，到时候改版起来会相当痛苦。

前端与后端人员

把命名方式沟通清楚、跟后端人员解释前端css、js、image目录结构定义的想法、了解后端的工作原理。

前端与产品经理

每个职位的人员都不容易，产品经理更是，最终对产品负责的还是产品经理。不知是否是这样的原因，我所遇到的产品经理都格外细致，有的甚至细致到跟原型效果图差2、3px他都能看得出来！产品经理如果过于追求细节，前端会很悲催。怎么处理这样的情况？和产品经理一样站在产品和用户的角度去思考问题，千万不要站在个人的职位上去想问题，不然永远无法说服他。当然，这有点难度...

终于侃完了，做个总结吧，关于程序设计的些许想法：程序跟人生一样，有的时候需要妥协，不能说为了减少请求数，就不注重代码维护，对待使用2M的用户和10M的用户是不能使用同样的处理方式的，网站访问量的多少也应该考虑在内，多个方面综合考虑、权衡，给出一个最优化方案。我想这才是最合理的。