前端性能优化概述

对于web程序，快速的页面载入速度给用户很好的使用体验，试想，当用户浏览你的个人网站时，网页半天都没有打开，或者打开后由于css文件或者js文件加载失败导致页面巨丑无比，用户的脑袋中可能只有一个想法，这是个嘛玩意儿！这样的结果恐怕也不是你建个人网站的初衷，个人网站无非就几个目的：知识传播，个人推广，知识积累。如果一个差点用户体验，都会把你的最初的好的构想夷为平地。当然你也还有几种提高网站速度的办法：

1.使用现有的代码服务器（比如阿里云的），并且比较稳定，但是使用方法比较有限。
2.使用VPS，然后使用linode构建个人网站服务。 个人也比较推荐这种方式，因为可以使用Linux的所有功能，随意折腾，也是练习Linux的好方法。
3.在带宽一定的情况下，优化前端代码，
我们知道http是网络层协议，是以tcp协议之上的，tcp位于传输层，而传输层又是优化的核心点，我们在介绍优化方法前，先介绍下web的基本知识点：
1、网页自上而下的解析渲染，边解析边渲染，页面内CSS文件会阻塞渲染
2、浏览器在document下载结束会检测静态资源，新开线程下载（有并发上限），在带宽限制的条件下，无序并发会导致主资源速度下降，从 而影响首屏渲染
3、浏览器缓存可用时会使用缓存资源，这个时候可以避免请求体的传输，对性能有极大提高
一般情况下，我们可以通过如下基本手段来优化：

1、合并图片，减少请求的数量
2、合并或者压缩js文件或者样式，有多个压缩工具可以使用（比如http://shrinksafe.dojotoolkit.org/，YUI Compressor，http://dean.edwards.name/packer/等）
3、使用css3的图标
4、开启Gzip.(各个服务器开启gzip服务请自行补脑。暂没有验证过，抱歉！)
5、图片延迟加载
6、图片无损压缩，或者将png格式调整为jpg格式，因为png格式的图片像素较高。
7、减少cookie携带，
8、按需加载，先加载主要资源，其余资源延迟加载(按需加载，比如说异步加载库requirejs,seajs等)
除了这些基本代码层的优化之外，还没有使用浏览器或者服务器端技术来进行速度优化：

1、使用缓存（浏览器缓存、localstorage，sessionStorage,redis等）
2、CDN网络，将图片、js文件或者样式部署到一个独立的网络中(借助nginx)。
如果仅仅是上面这些优化手段，恐怕只有在最理想的情况下。事实情况总是有这样或者那样的不如人意，总会有各种各样的耦合，各种因为项目周期段或者技术问题而欠下的债务，这种债务有时候是巨大的，可能需要原来几倍的时间去填坑。典型的情况有：
1、之前的CSS全部放在了一个文件中，新一轮的UI样式优化，新老CSS难以拆分，CSS体量会增加，如果有业务团队使用了公共样式，情况更不容乐观；
2、UI组件更新，但是如果有业务团队脱离接口操作了组件DOM，将导致新组件DOM更新受限，最差的情况下，用户会加载两个组件的代码；
3、胡乱使用第三方库、组件，导致页面加载大量无用代码；
4、频繁地替换库文件，
工程问题在项目积累到一定量后可能会发生，一般来说会有几个现象预示着工程问题出现了：
1、代码编写并且调试困难
2、业务代码不好维护
3、系统性能严重下降
4、定位问题困难、解决问题不彻底容易引起别的问题。
为了项目的长远发展，我们必须从一开始就要找到优化的便于维护的便于升级的角度去考虑系统的实现。我们可能需要一下的资源(欢迎补充)：
1、框架MVC,框架级别CSS
2、UI组件（header组件、日历、弹出层、消息框……）
3、业务HTML骨架（header, nav,aside,content,footer）
4、业务CSS
5、业务Javascript代码
6、服务接口服务

UI组件本身包括完整的HTML，CSS，Javascript，就UI部分来说容易导致两个工程化问题：
1、升级产生代码冗余
2、对外接口变化导致业务升级需要额外开发

UI升级需要遵守两个原则：
1、核心依赖组件必须保持单一，相同功能的核心组件只能有一个
2、组件升级必须做接口兼容，新的特性可以做加法，绝不允许对接口做减法

UI组成
项目之初，分层较好的团队会有一个公共的CSS文件（main.css），一个业务CSS文件，main.css包含公共的CSS,并且会包含所有的UI的样式.半年后业务频道增，UI组件需求一多便容易膨胀，弊端马上便暴露出来了，最初main.css可能只有10K，但是不出半年就会膨胀至100K,所以比较好的做法是，main.css只包含最核心的样式，理想情况是什么业务样式功能皆不要提供，各个UI组件的样式打包至UI中按需加载,如此UI拆分后，main.css总是处于最基础的样式部分，而UI使用时按需加载，就算出现两个相同组件也不会导致多下载资源.

拆分页面
一个PC业务页面，其模块是很复杂的，这个时候可以将之分为多个模块：header,nav,aside,content,footer.
一经拆分后，页面便是由业务组件组成，只需要关注各个业务组件的开发，然后在主控制器中组装业务组件，这样主控制器对页面的控制力度会增加。
业务组件一般重用性较低，会产生模块间的业务耦合，还会对业务数据产生依赖，但是主体仍然是HTML&CSS&Javascript，这部分代码也是经常导致冗余的，如果能按模块拆分，可以很好的控制这一问题发生.
按照上述的做法现在的加载规则是：
1、公共样式文件
2、框架文件，业务入口文件
3、入口文件，异步加载业务模块，模块内再异步加载其它资源
这样下来业务开发时便不需要引用样式文件，可以最大限度的提升页面载入速度。