本文章为转载别人的文章，因不知道原博客的地址，再次非常感谢原博主的无私分享
一、提倡前端开发工程师在书写xhtml的时候做到结构语义化。
结构中主要包括了head和body两个部分，但是我们经常说的是结构语义化主要是body中的标签，但是我在这里还是简单的说一下head，head中其实包括了一些对于我们seo很有用的一些东西，比如title,Description,Keywords,这些东西在蜘蛛抓取的时候都是有帮助的，当然，还有其他的一些，我在此就不一一说明了，比如设置缓存等一些其他的信息。
那么body中的话，包括的标签就很多了，我觉得作为一个合格的前端开发人员你应该去熟悉他们，比如div,span,h,ul,ol,dl,p等等这类的标签的使用。应该非常合理，还有就是注意h标签的断层，及h1标签的使用，这些都是非常重要的。
同时在我们的结构中不要出现style和onclick这样的内联的样式和事件。希望大家能够注意结构与表现、行为的分离。
（PS：标签语义化的好处：1.有利于搜索引擎；2.结构清晰的HTML在团队合作中的作用，就不必说了吧；3.有利于盲人屏幕阅读器。至于如何做到标签语义化，就看个人的理解了，这方面我也觉得模糊，跟个人的习惯估计也有一定的关系，总之邹惠斌老师是认为我的标签不语义的。）
二、css，js文件数量及大小的优化
那么关于css、js的优化的话，一般情况下建议css和js采用外联式。但是如果你的页面内容比较多，设计师把整个效果做得比较花的话，恐怕css就非常多了，那么这种情况下，你一定要把你的css规划好，尽量的采用缩写，这样可以减少css文件的大小，那么对css做相应的规划也可以减少css的个数，减少http请求数，js同理。
（PS：减少重复性代码，代码重复利用，在这里显得特别重要）
三、背景图片数量及大小的优化
当我们将设计师的设计稿还原成静态页面后，除非页面所有的修饰全是色块，内容全是文字，没有图片，如果不是这样的话，那么我们需要对图片做优化处理。当然内容图片我们是没有办法了，因为他是属于内容部分的，一般情况是由于编辑处理，当然，我在还是有一个小小的建议，如果我们的网站中需要有内容图片，希望编辑能够将他们最优化以后，在进行上传，一会儿告诉我的方法，下面我在说说，作为前端开发应该如何处理我们的修饰（背景）图片。
由于我们的背景图片数量比较多，这样的话，会给服务器带来影响，增加了http请求数，我们是否有一种好的解决办法呢？这个答案是肯定的，如果你是一个合格的前端开发，你应该清楚，在我们的css定义背景的时候，可以通过坐标来实现对背景进行定位的，既然如此，那么我们可以将这些背景合并起来，这样即可减少http请求数，同时，我们在背景整合的时候，也需要考虑图片质量，同时也需要考虑图片的大小，我在以前有写过相应的博文。
（PS：这里建议使用PNG8格式的图片结合css sprite，同样的图片，PNG8格式会相对来比GIF小）
四、内容图片的大小的优化
其实刚才已经说了内容图片的问题，那么我在这里呢，告诉大家一个比较简单的方法，就是使用雅虎提供的一个工具。他就是smushit：http://www.smushit.com/
不过他这个工具我觉得对于我们需要发布的内容图片还是比较麻烦，但是他可以进行优化，优化图片的目的，最开始已经说了，图片越小，我们的用户下载速度越快，当然对企业的服务器的带宽也可以起到节省的作用。
上面是我关于前端页面性能的一些简单的看法，当然web标准中提到的结构，表现，行为，我们工作说的xhtml,css,js其实他们还有很多东西，需要我们去学习，比如结构语义化他就是一个深入研究的课题，性能优化也是如此，不过只有我们不断的去挖崛，我们才可能进步。下面对我前端开发的出品有一个简单的建议：
1、我们做还原的页面能够通过http://validator.w3.org的验证，当然css希望也能通过http://jigsaw.w3.org/css-validator/validator难证，不过有时候由于需要兼容多浏览器，会受到hack的影响，css不做强制要求。
2、作前端的我觉得应该知道yslow。如果不知道可以看看我以前写的文章，你觉得你的静态页面应该能够通过yslow2.0的classic（V1）级别的检测，检测的结果我觉得应该得到A。
3、你的背景图片保证不超过3个以上，你的css文件不超过2个，js文件不超过3个。而且良好的遵守web标准的一些规定，css放到head中，js文件放到</body>之前或者之后。
4、当然就是希望你能够对你的页面进行裸体检查。其实就是来检验你的结构语义化是否有效果。
裸体检查：就是将你的css和js都去掉，查看你的html，看这些内容你是否能够看懂。
5、检测你的h标签是否断层。
（PS：就是按照h1,h2,h3,h4....，不要中间漏掉h2）
6、建议body中增加text-align:center。
7、当然还有很多，比如什么id，class的命名呀，这些东西，我觉得应该是你的团队中应该做的事情。
（PS：这里得去好好看看clsaa选择器的权重和优先级）
8、作为大型网站来说，首页使用内联式样式表，这样可以减少http请求数的同时，也可以防止裸奔。当然其他页面需要使用外联样式表，这样才可以方便维护。因为作为大型网站来说，他的首页访问量是非常的大的，所以。。
把样式表置于顶部
把脚本置于页面底部
避免使用 CSS 表达式（Expression）
使用外部 JavaScript 和 CSS
削减 JavaScript 和 CSS
用 <link> 代替 @import
避免使用滤镜
剔除重复脚本
减少DOM访问
开发智能事件处理程序
最好的方案就是按照 HTML 规范在文档 <head /> 内加载你的样式表。
对于拥有较大浏览量的首页来说，有一种技术可以平衡内置代码带来的 HTTP 请求减少与通过使用外部文件进行缓存带来的好处。其中一个就是在首页中内置 JavaScript 和 CSS ，但是在页面下载完成后动态下载外部文件，在子页面中使用到这些文件时，它们已经缓存到浏览器了。
Coockie:
减小Cookie体积
对于页面内容使用无coockie域名
图片：
优化图像
优化CSS Spirite
不要在HTML中缩放图像
favicon.ico要小而且可缓存
移动应用：
保持单个内容小于25K
打包组件成复合文本
此文中谈到了编辑，其实通过我走过的公司来看，很多公司其实不止是编辑，甚至连开发，他们对xhtml的规划都还不够非常了解，所以经常会出现已经上线的页面出现一些这样那样的问题，比如注释，或者标签不闭合等等，所以我建议各个公司可以开一些关于交流的会，这样的话，各个职位间可以交互交流，其实也可以说是培训吧，只有这样，才能够打造出一个好的产品。
页面优化——减少HTTP请求数
1．关于减少http请求数
关于减少http请求数,是前端开发性能优化的一个非常重要方面,所以在基本所有的优化原则里,都有这一条原则:减少http请求数.
先不考虑其他的,我们先考虑为什么减少http请求可以优化性能.
减少http请求有这样几个优点:
(1) 减少DNS请求所耗费的时间.
且不说对错,因为从基本来说,减少http请求数的确可以减少DNS请求和解析耗费的时间.
(2) 减少服务器压力.
这个通常是被考虑最多的,也是我用来讲解给别人听的最大理由,因为每个http请求都会耗费服务器资源,特别是一些需要计算合并等操作的服务器,耗费服务器的cpu资源可不是开玩笑的事情,硬盘可以用钱买来,cpu资源可就没那么廉价了.
(3) 减少http请求头.
当我们对服务器发起一个请求的时候,我们会携带着这个域名下的cookie和一些其他的信息在http头部里,然后服务器响应请求的时候也会带回一些cookie之类的头部信息.这些信息有的时候会很大,在这种请求和响应的时候会影响带宽性能.
2．让我们来一一道来
(1) 什么是DNS请求和解析呢?
简单来说,例如:www.taobao.com这样一个url,其中www部分被称为主机名(hostname),taobao这部分则是二级域,com则是一级域,如果是这样一个网址:www.ali.taobao.com.那么ali就是三级域.
当我们去请求一个url的时候,首先会到本地服务器里去寻找缓存中是否有解析结果,如果没有解析结果,就去根域名服务器请求,根域名服务器返回给本 地域名服务器一个所查询的域的主域名服务器的ip地址,然后我们再去请求刚才返回的ip地址的域名服务器,然后返回下一级域名的ip地址,直到我们找到域 名中所指的服务器ip,然后将结果缓存起来供下次使用,并返回此结果.
一个第一次请求的url的DNS解析过程可能耗费是很高的.但是解析一次之后,结果就会被缓存起来,之后再请求的时候就不用走上面这一套复杂的解析过程了.
关于一个正常的DNS请求到底会耗费多少时间,这个没有定论,要看网速状况和地域,但是考虑一个dns解析解析过后会被缓存起来,像淘宝这样的大网站,来的都是回头客,我们是否可以忽略DNS解析花费的时间呢?
在前端优化里还有一个优化方法,那就是增加hostname,例如,淘宝图片服务器,分为img01，img02，img03等主机名,这样做是因 为考虑到浏览器对同一个域名下同时进行的http连接数的限制,具体可以见下表: .然后我们在一个页面里的图片放在不同的hostname下,这样就可以同时下载多个图片了,浏览器http连接数的限制可以被缓解一下,但是这样做的后 果就是yslow评分会下降,因为yslow将DNS请求看的比较重要.
Browser HTTP/1.1 HTTP/1.0 IE 6,7 2 4 IE 8 6 6 Firefox 2 2 8 Firefox 3 6 6 Safari 3,4 4 4 Opera 9.61 8 2
在此,就要引出我们想讨论的东西,为什么yslow评分在合理的情况下分数反而会低,因为yslow只是一个机器程序,它并不知道 我们的网站是什么类型的,是何种规模的,是内容型还是应用型,所以我们可以用异步加载的方式来欺骗yslow对于dom节点的评分,但是异步加载真的适合 我们的网站么?同样,别人写了一篇文章,出了一个原则,一个最佳实践,但是你确定他说的情况适合你的情况么?网站有大有小,大小不同,需要考虑的东西也就 不同.
为什么对于淘宝的图片来说,使用不同的hostname是个更优的方案呢?
首先,因为淘宝网的特殊性,淘宝网大多数访问者都是回头客,他们电脑里大多缓存着dns记录.这种情况,如果是小网站或者新兴网站可能要考虑,因为新用户比较多,可能dns请求的消耗更大一些,而且第一印象对于这些网站来说更为重要.
再者,淘宝里的图片很多,一个页面里通常会用到几十张甚至上百张图片,在这种情况下,我们更需要突破浏览器的http连接数的限制,以便加快加载速 度,这时候加载速度的考虑优先级远远高于DNS的影响,而yslow中对于DNS的着重考虑可能更偏向中小网站,图片比较少的网站.
对于DNS请求或者tcp(tcp握手之类的也会消耗请求时间)请求之类的分配和解析的消耗,还有一个办法是keeplive,让你的链接保持keeplive,这样可以只建立一次链接,然后传输多个文件,可以有效减少建立连接的时间.
(2) 减少服务器压力
过多的http请求对于服务器来说是很危险的,如果你的服务器不是很强,请把这一条考虑放在第一位,其他的优化策略都只是优化,而这里涉及到的是服务器,你要保证你的服务器能正常运转.
当然如果你是在淘宝的话,你就可以安心坐下来跟一群牛人谈论为什么要忽略http对服务器的影响,因为我们要记住:我们是前端开发工程师,我们是在 做前端优化,后台和我们无关,因为我们有足够强大的技术支持和硬件支持,当网站的技术发展到一定程度的时候,我们的关注点应该向用户那里偏重,因为用户看 到的才是我们最终要展示的,用户感受到的体验和速度才是我们要达到的速度,后台我们做的再快,前台呈现慢了,我们的服务器消耗少了,省钱了,但是用户却因 此抛弃了我们,一切都是白费.所以,当后台足够支撑你不用你去考虑后台压力的时候,那就安心考虑如何做好前台的工作吧.
Yslow真的是一个误导人的工具,只要我们按照它的原则对网站进行优化,肯定最后可以拿到高分来欺骗老板,但是对于有些场景,这些优化往往是一种 对性能的破坏,例如淘宝网的商城首页,为了提高Yslow评分,所有的图片都采用了一个hostname,分数提高了,但是并行加载少了,不过商城首页都 是异步渲染和异步加载的,所以这种影响看起来并不明显.
商城首页有很多针对yslow的优化点,当然大多数优化是正确的,例如:导航那里,本来是全部写在页面里的,不要小看那个导航,里面有N个链接节 点,以至于从浏览器里复制源代码的时候浏览器会卡死,因为字节数太多了,这里yslow肯定不会饶过的,后来我们把导航做成了异步加载的,评分理所当然上 去了.但是这是淘宝网,我们有足够的速度来提供足够的用户体验.如果你的服务器提供不了这种速度,也承受不了这种频繁的异步请求的话,这种优化就要慎重 了,延迟可能造成导航不可用.这也是针对场景来协调的.
淘宝现在在广泛部署CDN,CDN可以给我们提供足够的后台资源保障,在CDN和后台环境不断万善的情况下,考虑重点应该更加专注于前台传输速度和展现解析速度的提升.
(3) 合并脚本和样式?
其实在前一篇文章里的那段讨论也是对于不同应用场景的不同考虑,
减少http请求数的一个方法,对于前端来说,那就是合并脚本和样式文件,称为combo,通过将多个文件合并成一个文件,然后一次性传输到客户 端,这样可以减少http请求,的确是个有效的方法,甚至对于一些特殊的页面,例如首页,我们把样式和脚本都写在了页面里,根本没有分离出来,他们不会产 生http请求,当然,也不会被缓存,这是被牺牲的代价.
为什么我们要这么做,因为首页的访问量很大?这样可以有效减少http请求数?恩,这只是一部分原因,的确这样做有这样的好处,而且对于assets服务器不够强大的网站来说,在并发量大的首页上实行这一套是很有效的.
但是,淘宝访问量最大的页面并不是首页,而是detail页面,也就是商品详情页!
这才是我们讨论的重点,为什么首页采用combo甚至写在页面里,而detail则按照正常的样式和脚本来引用.首页是类似静态的页面,detail则是应用型的.首页没有脚本,依然可以起到导向的作用,但是detail页脚本没有运行起来的话,甚至无法购买商品.
其实在这里这样讨论并不能明显看出问题所在,因为淘宝在这些方面也不是很成熟,detail页引用了大量脚本和样式,很多内容是多余的过期的.
这从本质上来说代表两种网页类型,一种是内容型,一种则是应用型.对于内容型的网站,脚本并不是很重要(甚至样式),因为没有脚本,用户仍然可以浏 览页面,只是可能有些效果看不到而已,所以我们可以把脚本合并起来,一起放在body底部,在页面内容都加载完后,再一次性加载进来.而对于应用型的网 页,让应用跑起来才是最重要的,因为没有应用这个网页就变得没有意义了,这时候,按需加载脚本是一种趋势,我们需要先把应用的基本框架和功能按需加载进 来,让它们分别运行起来,而不是一起等脚本加载完再一起初始化,我们需要应用能够快速响应用户,
而且还是说到CDN,当CDN变得足够强的时候,连接数已经不是瓶颈,我们应该更多考虑怎么让网页更快的展现给用户,对于无需脚本也可以提供服务的 内容型的网页,将脚本放在页面底部,合并起来(减少连接数,我们仍然需要减少连接数,在不需要太快的使用脚本的情况下),而对于应用型的网页,我们需要尽 快让功能运转,甚至让他们一部分一部分按优先级初始化,这时候就要将脚本分开,按需加载.
(4) 减少http请求头
http头是个庞大的家伙,你打开taobao.com的首页,alert一下document.cookie,会发现淘宝网的cookie是如此 庞大,甚至比小型网页都大,每次你请求淘宝的服务器都会往返一次这些数据,还有一些其他的头部信息,占用的空间也不小,可想而知这种消耗有多大.
然后其实自从用了CDN,这一切都无需考虑太多,因为CDN和淘宝主站不在一个域名下,cookie不会互相污染,而CDN的域名下基本是没有 cookie和头部信息的,所以每次请求静态资源的时候,不会带着主站的cookie到处跑,而只是传输资源的主题内容,所以这对于性能的影响在使用 cdn之后会变得很小.但是如果你的静态资源服务器和主服务器在一个域名下,那就要控制好cookie和其他头部信息的大小了,因为每次传送都会传送他 们.
最后
总之,优化原则不是绝对的,对于不同的场景应该考虑不同的侧重点,别人的解决方案对于你来说不一定是最优的,应该针对自己的网站规模和类型进行适度的优化,不能盲目追求标准和最佳实践.