前端优化

对于前端优化的手段，基本可以几个字就能说清楚：

　　传输层面：减少请求数，降低请求量

　　执行层面：减少重绘&回流

① 网页自上而下的解析渲染，边解析边渲染，页面内CSS文件会阻塞渲染，异步CSS文件会导致回流

② 浏览器在document下载结束会检测静态资源，新开线程下载（有并发上限），在宽带限制的条件下，无序并发会导致主资源速度下降，从而影响首屏渲染

③ 浏览器缓存可用时会使用缓存资源，这个时候可以避免请求体的传输，对性能有极大提高

衡量性能的重要指标为首屏载入速度（指页面可以看见，不一定可交互），影响首屏的最大因素为请求，所以请求是页面真正的杀手，一般来说我们会做这些优化：

减少请求数

① 合并样式、脚本文件

② 合并背景图片

③ CSS3图标、Icon Font

降低请求量

① 开启GZip

② 优化静态资源，jQuery->Zepto、阉割IScroll、去除冗余代码

③ 图片无损压缩

④ 图片延迟加载

⑤ 减少Cookie携带

很多时候，我们也会采用类似“时间换空间、空间换时间”的做法，比如：

① 缓存为王，对更新较缓慢的资源&接口做缓存（浏览器缓存、localsorage、application cache这个坑多）

② 按需加载，先加载主要资源，其余资源延迟加载，对非首屏资源滚动加载

③ fake页技术，将页面最初需要显示Html&Css内联，在页面所需资源加载结束前至少可看，理想情况是index.html下载结束即展示（2G 5S内）

④ CDN

......

有一些网站初期比较快，但是随着量的积累，BUG越来越多，速度也越来越慢，一些前端会使用上述优化手段做优化，但是收效甚微，一个比较典型的例子就是代码冗余：

① 之前的CSS全部放在了一个文件中，新一轮的UI样式优化，新老CSS难以拆分，CSS体量会增加，如果有业务团队使用了公共样式，情况更不容乐观；

② UI组件更新，但是如果有业务团队脱离接口操作了组件DOM，将导致新组件DOM更新受限，最差的情况下，用户会加载两个组件的代码；

③ 胡乱使用第三方库、组件，导致页面加载大量无用代码；

 

UI组件本身包括完整的HTML&CSS&Javascript，一个复杂的组件下载量可以达到10K以上，就UI部分来说容易导致两个工程化问题：

① 升级产生代码冗余

② 对外接口变化导致业务升级需要额外开发

UI升级需要遵守两个原则：

① 核心依赖组件必须保持单一，相同功能的核心组件只能有一个

② 组件升级必须做接口兼容，新的特性可以做加法，绝不允许对接口做减法

 

解决冗余便抛开了历史的包袱，是前端优化的第一步也是比较难的一步，但模块拆分也将全站分成了很多小的模块，载入的资源分散会增加请求数；如果全部合并，会导致首屏加载不需要的资源，也会导致下一个页面不能使用缓存，如何做出合理的入口资源加载规则，如何合理的善用缓存，是前端优化的第二步。

经过几次性能优化对比，得出了一个较优的首屏资源加载方案：

① 核心框架层：mvc骨架、异步模块加载器（require&seajs）、工具库（zepto、underscore、延迟加载）、数据请求模块、核心依赖UI（header组件消息类组件）

② 业务公共模块：入口文件（require配置，初始化工作、业务公共模块）

③ 独立的page.js资源（包含template、css），会按需加载独立UI资源

④ 全局css资源