网站剖析：5173首页前端性能优化实践

5 ]6 P/ E, S9 T
: A2 O3 j0 `' h: [' Y  e从制定打算，到前后端的开发，最终到测试以及上线，历时4个月，5173首页前端性能优化项目终于顺当上线，并达到达预期的性能优化目标。这次的项目并不是改版，而是原来首页的设计和功能未变，只做重构和优化。虽然项目名叫前端的性能优化，但也并不单只是前端单方面的办公，要想彻底的把优化做好，就需要前后端的通力配合。
　　历史背景
4 ~. ?8 A4 O& r, p" _- H7 V　　老首页应当是09年上线的，首页也是各部门争夺资源的地方，大家都想在首页有一席之地，各部门在首页都有各自的小豆腐块，假如有新项目标上线，大多是打补丁的形式，而且唯一的规范就是能保障功能正常运行，至于性能方面，那是很辽远的事。苦逼的是开发成员，每每有首页的修改都是担惊受怕的，怕改了这个那个又出问题，历史端由导致的问题越来越多。
　　最先看不下去的应当是前端成员，因为首页在不断的修补缀补中，性能已经差到前端成员感到很没面子的境地了。不过看不下去也仅只是看不下去，没法采取实质性的措施来改善，因为这涉及各部门的利益，也如上头说的，优化不单只在于前端，于是前端成员也只能向上头反映问题。到达今年，终于上层也看不下去了，某上层在海外过访我司的818和5173首页，对比起来前者首页很快(插播一句，818首页前端开发成员也正是我^_^)，后者首页很慢，差异较大。于是在上层看得起的推动下，5173首页的前端性能优化项目才情节批准，开发成员终于可以放手斗胆的折腾了。
　　问题剖析
" x& x0 m; r( o% U% |* }6 H' T　　在动手前要制定打算，制定打算要从解决实际问题起航，先来看看老首页的问题，这是我在制定打算时收集的相关数据：
　　1、烦请数过多，其中CSS外链数有12个，JavaScript外链数竟有41个;
: c3 i9 n3 u  U+ d& I7 N* }　　2、页面总体积过大，众多静态资源都没加gzip，动态站点的JS甚而都没有压缩过;
5 u# y: s! H/ n. G- W+ H1 M! K　　3、资源占用严重，在IE6下骨碌页面时CPU占用率高达80百分之百以上，内存泄漏也很严重;
　　4、广告系统，广告图片都是以document.write的形式在加载，页面拥塞的情况很严重;
　　5、页面有7个iframe;
　　6、数据源接口惑乱;
　　7、页面加载速度过慢，有白屏现象，首屏完成加载很慢;
6 A# Z1 l' D' |0 R6 |　　上头的数据让你很吃惊，这也申说了有巨大的优化空间。找出了问题所在，接下来才有具体的实行方向。总之，不论是常理的办法，亦或是奇淫技法，目标只有三个字，“快，更快”。
1 L; P6 k/ u* u. C; ]2 s5 Z9 X　　具体实行
- ?6 f; R5 e- H　　虽然粗看页面的内容并不是众多，不过具体到功能板块，都是很费时费劲的。我们老大有一句很经典的话，“通常我会问面试成员一个问题，假如你独自来做5173首页的前端办公，多久能完成?假如谜底只有一个星期，要么是没看过页面，要么就是很不专业。”我就独自花了一个多月的时间才完成首页的前端开发办公。下边来说说具体的实行吧。
　　HTML&CSS 的重构
　　页面的设计和功能没有变动，不过HTML页面仍然要做彻底的重构，这搭我也尝试了使役 HTML5 的新标签来对页面施行布局。CSS 的重构也是当仁不让的，原来有12个外链的 CSS，这些都要统统干掉的，有点板块假如不光首页有用到，就需要板块化，该放到公用文件就放到公用文件中，在开发的时分可以分多个板块，而后使役 @import到一个文件中，打包发布的时分再合并成一个文件。这需要把握好一个度，即要合理利用缓存，又要避免单文件过大，同时也要做好板块化。
　　老首页有众多 CSS 取舍器过长的问题，可能一个 CSS 取舍器的组合长达6-7个也是常有的事，CSS 取舍器过长不单只是性能方面的影响，同时也因为 CSS 权值的关系，给后期保护带来了众多的麻烦。应当多使役 class 来定义取舍器，再加上 tag 取舍器的组合，最多3个取舍器的组合就能知足绝多数的需要了，额外在 CSS 的编著方面禁阻使役 id 取舍器和 !important，养成优良的 CSS 编著习性很关紧。
: d+ g/ [/ f( Q　　JavaScript 的重构
% }  W! g9 C+ v7 x　　JavaScript的重构太迫切了，原来竟有41个 JavaScript 外链文件，当然这些外链也涵盖了15个广告的外链，广告的优化我稍后再说，不过还余下26个外链 JavaScript。这些臃肿不堪的 JavaScript文件即是导致页面加载拥塞的元凶，也是系统资源占用的蛀虫，这是囫囵项目标难点之一。
　　从新梳理了四级联动搜索的业务逻辑，并对四级联动搜索的交互功能做优化，增强用户体验。这个板块的 ajax 交互功能较多，最大的 JSON 数据包竟至有94.4KB，此时合理的利用现时页面的缓存功能($.fn.data)很关紧。体积最大的 JSON 数据包在页面 Dom Ready 后行加载，而后拼装第一屏的 HTML 代码并缓存，当用户按字母引得取舍游戏的时分再到已加载完的 JSON 数据包中寻觅相应的数据去拼装 HTML 代码，而后缓存该引得的 HTML 代码。假如接下来再取舍区、服、交易类型时，再到服务器去取相应的 JSON 数据，拼装成 HTML 代码后行缓存，此时只缓存最终一次的取舍结果。
　　

　　便民核心也同等是首页业务逻辑很复杂的板块，关乎到众多的ajax交互以及表单的操作。各个TAB中的表单是依据烦请的JSON数据来世成HTML结构的，原来是每每点击TAB都会烦请一次数据，而后生成HTML结构，每切换一次TAB都要烦请，再生成，这真得很二。同等的数据和结构只要烦请一次，并生成一次即可，这种重复的操作是赤裸裸的浪费资源。该板块的JavaScript原来烦请的动态站点的文件，没有做缓存也没做过压缩，每每页面加载都在这搭阻梗一小会。这搭的服务端的数据源接口也很乱，开发成员匮缺规范化数据接口的概念。这搭的诸多问题，我已无力吐槽了。最终也是从新梳理蛋痛的业务逻辑，重构代码。
（以上由 军蚂蚁百度竞价软件小编：http://www.junmayi.com 原创发布）
1 F3 P1 ]% w# I( O
! G* @0 D4 I) x# ]

楼主辛苦了，整理这么多内容，必须点赞收藏

完全赞同，我也是这么认为的，英雄所见略同～

这个思路很新颖，打开了新世界的大门，谢谢分享

蹲了这么久，终于看到有价值的讨论，支持一下！

刚好遇到类似问题，看完这个帖子心里有底了