前端的页面主要包括xhtml,css,js。其实xhtml就是现实中所谈到的内容，页面的内容：文字，图片，flash,视频等。
而前端开发工作者可以控制的是什么呢？那就是xhtml，css，js的代码及相应的修饰（背景）图片。下面我就根据我自己的经验来说说：
一、提倡前端开发工程师在书写html的时候做到结构语义化。
结构中主要包括了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文件放到之前或者之后。
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
用 代替 @import
避免使用滤镜
剔除重复脚本
减少DOM访问
开发智能事件处理程序
最好的方案就是按照 HTML 规范在文档 内加载你的样式表。
对于拥有较大浏览量的首页来说，有一种技术可以平衡内置代码带来的 HTTP 请求减少与通过使用外部文件进行缓存带来的好处。其中一个就是在首页中内置 JavaScript 和 CSS ，但是在页面下载完成后动态下载外部文件，在子页面中使用到这些文件时，它们已经缓存到浏览器了。
Coockie:
减小Cookie体积
对于页面内容使用无coockie域名
图片：
优化图像
优化CSS Spirite
不要在HTML中缩放图像
favicon.ico要小而且可缓存
前端优化的目的是什?
1，从用户角度而言，优化能够让页面加载得更快、对用户的操作响应得更及时，能够给用户提供更为友好的体验。
2，从服务商角度而言，优化能够减少页面请求数、或者减小请求所占带宽，能够节省可观的源。
第一类是页面级别的优化
例如HTTP请求数、脚本的无阻塞加载、内联脚本的位置优化等
1,减少HTTP请求数
? 从设计实现层面简化页面
? 合理设置HTTP缓存
? 资源合并与压缩
如果可以的话，尽可能的将外部的脚本、样式进行合并，多个合为一个。另外，CSS、Javascript、Image都可以用相应的工具进行压缩，压缩后往往能省下不少空间。
? CSS Sprites
合并CSS图片，减少请求数的又一个好办法
? Inline Images
使用data:URL scheme的方式将图片嵌入到页面或CSS中，如果不考虑资源管理上的问题的话，不失为一个好办法。如果是嵌入页面的话换来的是增大了页面的体积，而且无法利用浏览器缓存。使用在CSS中的图片则更为理想一些
? Lazy Load Image
这条策略实际上并不一定能减少HTTP请求数，但是却能在某些条件下或者页面刚加载时减少HTTP请求数。对于图片而言，在页面刚加载的时候可以只加载第一屏，当用户继续往后滚屏的时候才加载后续的图片。这样一来，假如用户只对第一屏的内容感兴趣时，那剩余的图片请求就都节省了。有啊首页曾经的做法是在加载的时候把第一屏之后的图片地址缓存在Textarea标签中，待用户往下滚屏的时候才”惰性”加载。
2,将外部脚本置底
3,异步执行inline脚本
4, Lazy Load Javascript
5,将CSS放在HEAD中
6,异步请求Callback
7, 减少不必要的HTTP跳转
8,避免重复的资源请求
第二类则是代码级别的优化
例如Javascript中的DOM操作优化、CSS选择符优化、图片优化以及HTML结构优化等
1. Javascript
(1). DOM
DOM操作应该是脚本中最耗性能的一类操作，例如增加、修改、删除DOM元素或者对DOM集合进行操作。如果脚本中包含了大量的DOM操作则需要注意以下几点：
a. HTML Collection
在脚本中document.images、document.forms、getElementsByTagName()返回的都是HTMLCollection类型的集合，在平时使用的时候大多将它作为数组来使用，因为它有length属性，也可以使用索引访问每一个元素。不过在访问性能上则比数组要差很多，原因是这个集合并不是一个静态的结果，它表示的仅仅是一个特定的查询，每次访问该集合时都会重新执行这个查询从而更新查询结果。所谓的”访问集合”包括读取集合的length属性、访问集合中的元素。
因此，当你需要遍历HTML Collection的时候，尽量将它转为数组后再访问，以提高性能。即使不转换为数组，也请尽可能少的访问它，例如在遍历的时候可以将length属性、成员保存到局部变量后再使用局部变量。
b. Reflow & Repaint
(2). 慎用with
with(obj){ p = 1}; 代码块的行为实际上是修改了代码块中的执行环境，将obj放在了其作用域链的最前端，在with代码块中访问非局部变量是都是先从obj上开始查找，如果没有再依次按作用域链向上查找，因此使用with相当于增加了作用域链长度。而每次查找作用域链都是要消耗时间的，过长的作用域链会导致查找性能下降。
因此，除非你能肯定在with代码中只访问obj中的属性，否则慎用with，替代的可以使用局部变量缓存需要访问的属性。
(3). 避免使用eval和Function
每次 eval 或 Function 构造函数作用于字符串表示的源代码时，脚本引擎都需要将源代码转换成可执行代码。这是很消耗资源的操作 —— 通常比简单的函数调用慢100倍以上。
eval 函数效率特别低，由于事先无法知晓传给 eval 的字符串中的内容，eval在其上下文中解释要处理的代码，也就是说编译器无法优化上下文，因此只能有浏览器在运行时解释代码。这对性能影响很大。
Function 构造函数比eval略好，因为使用此代码不会影响周围代码;但其速度仍很慢。
此外，使用eval和Function也不利于Javascript压缩工具执行压缩。
(4). 减少作用域链查找
前文谈到了作用域链查找问题，这一点在循环中是尤其需要注意的问题。如果在循环中需要访问非本作用域下的变量时请在遍历之前用局部变量缓存该变量，并在遍历结束后再重写那个变量，这一点对全局变量尤其重要，因为全局变量处于作用域链的最顶端，访问时的查找次数是最多的。
(5). 数据访问
Javascript中的数据访问包括直接量(字符串、正则表达式)、变量、对象属性以及数组，其中对直接量和局部变量的访问是最快的，对对象属性以及数组的访问需要更大的开销。当出现以下情况时，建议将数据放入局部变量：
a. 对任何对象属性的访问超过1次
b. 对任何数组成员的访问次数超过1次
另外，还应当尽可能的减少对对象以及数组深度查找。
(6). 字符串拼接
在Javascript中使用”+”号来拼接字符串效率是比较低的，因为每次运行都会开辟新的内存并生成新的字符串变量，然后将拼接结果赋值给新变量。与之相比更为高效的做法是使用数组的join方法，即将需要拼接的字符串放在数组中最后调用其join方法得到结果。不过由于使用数组也有一定的开销，因此当需要拼接的字符串较多的时候可以考虑用此方法。
2. CSS选择符
在大多数人的观念中，都觉得浏览器对CSS选择符的解析式从左往右进行的,例如
#toc A { color: #444; }
这样一个选择符，如果是从右往左解析则效率会很高，因为第一个ID选择基本上就把查找的范围限定了，但实际上浏览器对选择符的解析是从右往左进行的。如上面的选择符，浏览器必须遍历查找每一个A标签的祖先节点，效率并不像之前想象的那样高。根据浏览器的这一行为特点，在写选择符的时候需要注意很多事项，有人已经一一列举了
3. HTML
对HTML本身的优化现如今也越来越多的受人关注了，详情可以参见这篇总结性文章。
4. Image压缩
图片压缩是个技术活，不过现如今这方面的工具也非常多，压缩之后往往能带来不错的效果，具体的压缩原理以及方法在《Even Faster Web Sites》第10章有很详细的介绍，有兴趣的可以去看看。