只说web前端性能优化 - 简书
只说web前端性能优化
更新，内容越来越多，后续会把相关主题拆开来讲
前段时间在公司内部做过一个关于前端性能优化的分享，在这码起键盘来记录下。
&h2&前提：&/h2&
只说前端性能优化，涉及到一些具体可用的手段，都是日常工作中比较容易就可以做到的。不涉及复杂的比如CDN技术，或者服务器端优化技术（服务器端优化也可以改进前端性能）。
分享积累的经验和了解的技巧，因为有时候很多小的改变可以让用户体验有质的提升。比如保持一个良好的编码习惯和一些简单但不太注意到的策略。
先讲一讲一些常见的策略和方案，然后基于一个实际的项目案例来综合分析并给出解决方案。
（以下文章的截图图片都是来自我制作的ppt中）
&h2&问题：&/h2&
为什么进行前端性能优化？
响应速度对用户的影响－用等待时间来衡量.png
可以看出来，前端性能，反应给用户最直观的方面就是页面的响应速度。
3-5秒还能接受，大于8秒甚至上双的响应时间，作为用户肯定是接受不了的。
相信我们自己平常上网逛论坛也有类似的体验。
一句话，页面的响应速度对用户体验至关重要。
&h2&如何提高响应速度？&/h2&
下面就逐一来讲，有的可能没列举实例，对细节感兴趣的朋友可以网上查查相关主题的资料，或者直接问我。
&h3&1 避免坏请求：&/h3&
什么是坏请求？最明显的就是404请求，也可以把无意义的重复请求叫做坏请求。
无意义的请求，浪费了服务器的资源也影响前端性能.jpg
404会导致服务器无谓的响应，所以，没用的请求，比如链接图片，请求无用的资源等都需要及时删除。
&h3&2 合并js和css文件：&/h3&
这样也可以减少http请求次数
合并的策略.png
&h3&3 利用缓存：&/h3&
可以缓存js css等文件资源，也可以缓存请求回来的数据。
开启了缓存之后，有些资源文件，客户端就不用每次都从服务器端重新请求加载，从本地缓存里取，速度会快得多。至于该缓存哪些文件数据，那就看你的需求了。我们的目的还是想办法减少请求次数。
&h3&4 使用css精灵整合图片：&/h3&
通过整合图片和css定位的方法，我们可以把多张图片整合到一起，这样就减少了请求次数。
&h3&5 启用压缩：&/h3&
减少请求资源的数据量，达到更快的速度。
&h3&6 避免css @import语句：&/h3&
此语句顺序加载，会阻塞浏览器的并行加载。
&h3&7 优化脚本js和样式表css的顺序：&/h3&
（经测试IE8及以上没有这个问题，如果还需要兼容IE8以下版本浏览器，请注意这点）
&h3&8 处理小文件：&/h3&
将小文件比如小的js css文件写入到html中，或者第二点提到的合并，减少请求次数。
&h3&9 减少dom数量：&/h3&
想方设法减少dom数量，即减少浏览器处理的时间，因为很多时候客户端javascript处理的就是dom，dom的多少直接影响前端到性能，而且是全方位，多角度的影响。
可以想象下，如果web应用程序中含有成千上万的dom节点，我的意思是比原本多的多多节点。然后我们需要使用选择器操作dom，无论如何优化，这些dom节点都是存在的，这无疑是一项耗时的工作。
我见过一个项目，在一个列表下，有2万多个li节点（没错，是这么多，后面我将会把它当作一个实例放最后来讲），这些节点数据都是ajax请求回来的，更要命的是，在这些节点下，还需要完成搜索的功能。
浏览器解析dom，渲染样式都会花费不少时间，何况还需要操作搜索，和各种重绘。
&h3&10 慎用document.write：&/h3&
会阻塞浏览器的渲染。
&h3&11 使用浏览器文档碎片createDocumentFragment：&/h3&
这个可以减少操作dom的次数，从而减少渲染次数，提高页面性能。
来看个实例，看具体如何运用文档碎片来改善页面的性能。
现在假设页面中有个列表ul元素，我们需要调用ajax获取json数据来填充这个列表。
第一个版本代码：
var list = document.querySelector('ul');
ajaxData.items.forEach(function(item) {
// 创建li元素
var li = document.createElement('li');
li.innerHTML = item.
// li元素常规操作，例如添加class，更改属性attribute，添加事件监听等
// 迅速将li元素注入父级ul中
list.apppendChild(li);
这样的写法实际上是非常慢的，因为每一个元素附加到ul元素之上，顺带着浏览器处理渲染的过程。我们再来看看使用文档碎片的写法如何。
第二个版本代码 ：
var frag = document.createDocumentFragment();
ajaxData.items.forEach(function(item) {
// 创建li元素
var li = document.createElement('li');
li.innerHTML = item.
// li元素常规操作
// 例如添加class，更改属性attribute，添加事件监听，添加子节点等
// 将li元素添加到碎片中
frag.appendChild(li);
// 最后将所有的列表对象通过DocumentFragment集中注入DOM
document.querySelector('ul').appendChild(frag);
使用文档碎片处理之后，我们可以分析下附加节点到ul之上，只需一次就可以，大大减少了浏览器处理渲染的过程，节省了宝贵的时间。
如果没有事件方面的考虑，或者可以使用事件委托的情况下，甚至可以把节点都当成html来处理，那么我们操作的就都是字符串了，请看第三个版本代码。
第三个版本代码：
var htmlStr = '';
ajaxData.items.forEach(function(item) {
// 构建包含HTML页面内容的字符串
htmlStr += '&'+'li&' + item.text + '&'+'/li&';
// 通过innerHTML设定ul内容
document.querySelector('ul').innerHTML = htmlS
当然，如果觉得这样字符串太长，我们可以运用数组。
第四个版本代码：
var htmlStr = '';
var htmlArr = [];
ajaxData.items.forEach(function(item) {
// 构建包含HTML页面内容的字符串
htmlArr.push('&'+li&' + item.text + '&'+/li&');
// 通过innerHTML设定ul内容
htmlStr = htmlArr.join('');
document.querySelector('ul').innerHTML = htmlS
&h2&总结&/h2&
那么按这么说，我们就两招王牌：
减少请求，加快渲染！
提高页面性能，我们从这两个点出发，就可以解决很多问题。
以上大都是总结出来的一些可用的细节点。实际上，我们可以通过工具来检查页面上可供优化的地方，我感觉比较好用的工具是google page speed，大家可以在google应用商店搜索安装，使用方法也很简单。
除了我在文章中列举的优化外，大家可以参考page speed的说明，查找更多可供优化的信息。不过，话说回来，它列举的不一定都是对的，毕竟我们还是有自己的需求在内的。
实际项目中的问题，会表现的更加明显。
&h2&项目背景：&/h2&
企业内部的选择人员的界面，分集团部门等节点展示用户，但是用户人数较多就会出现页面的性能问题，具体表现在：
1 接近3万人，加载速度50s，前台的搜索近20s（很多逻辑，支持拼音搜索，模糊搜索等）
2 前台需要展现的数据量太大，造成无响应崩溃
结合以上我们提到的点，我们的解决办法是：
1 增加单次请求的数据量（3万人，每个人在数据库中都是一条记录，不可能一次就全部请求加载到web客户端）。之前每次请求加载500人，来回60次请求，改成每次请求加载3000人，把请求次数减少到10次左右。这样一来，对于数据的请求加载时间就节约了6倍多。
2 请求数据使用Json，之前是使用xml，然后在前端转换为Json，既浪费转换时间，又需要转换的代码。这个问题属于历史遗留问题，前辈们使用了xml，后来的维护者就一直这样了
3 等数据请求完成后再调用angular组件画地址树。之前是请求一次就渲染一次地址树，即请求回来500人地址树立刻变化（使用的angular，显示和数据是绑定的，数据变了显示就会变）。改成数据请求完成之后再统一调用组件渲染，减少了渲染时间。
4 搜索不使用angular的filter，这个应该是angular的bug，每次都是搜索两次。后来自己写了实现搜索的方法。
5 最最重要的一点是，3万人每个人都需要画一行数据，造成dom渲染慢。所以每次只画20人，用户拖动鼠标的时候，再动态的改变选择区的人。这也是利用了angular数据和显示绑定的特点。
想查看原理，请看：
&h2&最后&/h2&
虽然现在网络速度越来越快，但web前端优化还是非常重要，毕竟没有最快只有更快！我们不能假设用户都使用chrome并且网络速度都和我们一样快不是吗。使用良好的策略，可以让用户在有限的带宽和客户端硬件资源条件下，获取最佳体验！
高效的web应用没有止境。
文章可以随意转发，但请告知作者，并表明来源。
用写作战胜拖延
CSS 绝对底部 - 前端 - 掘金来自国外的设计达人，纯CSS，可以实现: 当正文内容很少时，底部位于窗口最下面。当改变窗口高度时，不会出现重叠问题。甚至，创造该CSS的人还专门成立一个网站介绍这个CSS底部布局方案。不知道他有没有去申请专利:)&!DOCTYPE htm...
前端性能优化指南 AJAX优化 缓存AJAX： 请求使用GET：当使用XMLHttpRequest时，而URL长度不到2K，可以使用GET请求数据，GET相比POST更快速。POST类型请求要发送两个TCP数据包。先发送文件头。再发送数据。GET类型请求只需要发送一个TCP...
用两张图告诉你，为什么你的 App 会卡顿? - Android - 掘金Cover 有什么料？ 从这篇文章中你能获得这些料： 知道setContentView()之后发生了什么？ ... Android 获取 View 宽高的常用正确方式，避免为零 - 掘金相信有很多朋友...
围绕前端的性能多如牛毛，涉及到方方面面，以我我们将围绕PC浏览器和移动端浏览器的优化策略进行罗列注意，是罗列不是展开，遇到不会不懂的点还请站外扩展 开车速度有点快，坐稳了。 tips : 这么多前端优化点你都记得住吗？反正我是收藏起来备查的。 PC浏览器前端优化策略 PC端...
前端开发面试知识点大纲： HTML&CSS： 对Web标准的理解、浏览器内核差异、兼容性、hack、CSS基本功：布局、盒子模型、选择器优先级及使用、HTML5、CSS3、移动端适应。JavaScript： 数据类型、面向对象、继承、闭包、插件、作用域、跨域、原型链、模块化...
这样的问题，可能每个看书人都会遇到，如果你没遇到，你一定不是真正喜欢读书。 有的时候，这个问题并不是别人问你，而是你在问自己。 可能只是很兴奋地合上书页，将心情从飞扬中慢慢落下，然后忽然发觉，自己除了曾经在书中获得的快乐，仍然要面对周遭的一切不如意。 读书究竟做什么？ 这已...
世界那么大，总想去看看 据说，河北工院3D打印中心有一面特殊的墙，世界地图的浮雕主题墙，旁边装饰的钟表代表的是相对应国家的时间。此面主题墙所用的材料为无毒无味，环保，可降解的PLA，地图的浮雕和钟表都是通过三维建模、打印，再到后期上色处理一步步来完成的，所有的钟表都是根据各...
近来，南方已经被连日的暴雨整得湿身多次，而大北方却在迈向盛夏的不归路上走得越发坚挺了，已然是越过了38度高地。 有网友更是感慨：这种天，女票跟人跑了都不带追的，太热了！ 高温天气，大部分人都会选择呆在室内，而后寄情于空调营造的“舒适”空间。 有人说，一到夏天，这条命都是空调...
一直听说北京西郊凤凰岭上的龙泉寺是个“神奇”的地方。 神奇之一在于寺里据说有相当多北大清华的博士，在学习达到一定程度后决心剃度出家。 神奇之二据说微信创始人张晓龙在龙泉寺参观时，随意和扫地僧聊了两句，意外发现对方是IT博士，并且聊的内容相当有深度。受到启发的张晓龙回到腾讯后...博客分类：
14条规则摘自&High Performance Web Sites&,
1.减少Http请求
使用图片地图
使用CSS Sprites
合并JS和CSS文件
这个是由于浏览器对同一个host有并行下载的限制,http请求越多,总体下载速度越慢
2.使用CDN(内容发布网络):当页面中有很多资源的时候,可以从不同的服务中去读取,同时可以提高并行下载速度
3.添加http Expires头:为图片视频之类很少改变的资源设置长的Expires时间将直接减少http请求
如果资源设置了Expires头为将来的某个时间,下次访问时候浏览器发现资源还没有过期,会直接从缓存中读取,不会再次产生http请求
另外一个有点类似的概念是条件Get请求,某些资源比如JS文件,如果我们总是需要最新的JS文件,那么可以设置条件Get请求去服务端验证本地的资源是否需要更新.这种情况下浏览器会向Server发送一个http请求,如果资源没有更新,会返回一个http 304的response,如果资源跟新,则重新下载资源:
条件Get请求每次都会产生一个304的请求
4.压缩组件:在Server端对Response资源进行压缩再传给浏览器,一般使用GZIP
5.将CSS放再顶部: 能加快页面内容显示,并且能避免页面产生白屏
6.将JS放在底部
JS会阻塞对其后面内容的呈现
JS会阻塞对其后面内容的下载
7.避免CSS表达式
8.将JS,CSS放在外部文件中
9.通过使用Keep-Alive和较少的域名来减少DNS查找
10.精简JS和CSS文件
11.寻找一种避免重定向的方法
12.移除重复的脚本
13.配置Etag
14.确保Ajax请求遵守性能知道,必要时候应具备长久的expires头
我们可以使用Yahoo的Yslow firefox插件来检查网站的前端性能.
最后,我们随便打开一个淘宝宝贝页面,用Fiddler查看一下,发现淘宝至少做了如下优化:
大规模使用CDN,图片,jS,css互相之间都使用了不同的域名.单是图片服务器,下面又使用了很多不同的服务器,比如img01.taobaocdn.com等等
当第二次浏览同一宝贝的时候,产生大量的Http 304请求.这样既能保证获取最新的资源,又能尽量减少数据传输
CSS,JS文件大都精简过
对于资源类的东西比如图片,设置为不受保护.也就是说不需要登录依然可以直接访问的,这样就避免设置/读取cookie,达到节省网络资源的目的
唯一一点没有优化的是图片,服务端返回的图片都是没有Gzip压缩的,或许是为了减少服务器的压力
浏览 17874
lijingshou
浏览: 726163 次
来自: 杭州
post请求如何自动跳转呢
有什么办法可以找出合并的图片的位置吗？一张大图片，一张小图片， ...
good point!
Selenium自动化测试从入门到精通(Java版)百度网盘地 ...
请问$Proxy0的.class文件 您是怎么提出来的？
(window.slotbydup=window.slotbydup || []).push({
id: '4773203',
container: s,
size: '200,200',
display: 'inlay-fix'经典面试题-Web前端性能优化方法（1）经典面试题-Web前端性能优化方法（1）内部技术百家号昨天写了一篇文章《经典面试题：从地址栏输入URL到页面加载完成发生了什么？》，是针对所有程序员在面试中可能会被问到的问题。那么今天写的这篇文章就是专门针对前端开发工程师在面试中经常被问到的问题，就是关于Web前端页面的性能优化。Web前端性能优化Web前端性能优化是一个复杂的过程，涉及到的知识点非常多，包括网页，服务器，CSS，Javascript，图片等方面。之前雅虎有总结过Web性能优化的14条原则，在这里我们做一下梳理，下面图片中的内容基本包含了所有可能的方式：性能优化的方式我们会对这些原则一一进行讲解，由于篇幅过长，我会分为几篇文章来写。今天就先来看看跟次数有关的几个内容规则1-减少HTTP请求数量图片-CSS Sprites我们都知道图片对于页面来说是一个独立的资源，每张图片都会发送一次HTTP请求去获取。如果页面上任何大小的图片都发送一次请求，那么对于图片类型的网站性能来说将会是一个噩耗，那么我们该怎么做呢？假想一下，如果多张类似于导航的小图片都集成在一张大图片上，只需要发送一次请求就可以得到，然后通过位置去获取具体的图片，这样是不是会减少很多次HTTP请求呢？没错，这就是CSS Sprites（雪碧图）的由来，它主要是将多个图片合成为一张图片，然后通过位置获取具体的图片。下图就是一张雪碧图雪碧图在使用雪碧图时，一般会设置一个通用的类，它们有共同的background-image属性，然后具体的类通过background-position属性去获取具体的位置，如下代码所示使用CSS Sprites图的样式图片-Base64编码在之前写过的一篇文章《关于图片的Base64编码，你了解吗？》中，讲过Base64编码的图片，也可以减少HTTP请求的次数。但是使用这种方式也存在弊端，太大的图片并不适合Base64编码，而且图片并不会被缓存，Base64编码的图片需要看真实环境再使用。CSS，JS文件合并在一个系统中我们通常会将页面的HTML，CSS样式，Javascript脚本区分开，但是也并不是说CSS和JS文件划分的越细越好，因为每个CSS和JS文件都会发送一次HTTP请求，能合并的CSS和JS文件都合并。一般一个网站会有一个通用的CSS和JS文件，然后每个页面都会有一个CSS和JS文件。规则2-减少DNS查询次数DNS的解析会消耗时间，如果在页面上嵌入不同域下文件比较多，例如在页面广告中嵌入的图片和脚本，在页面的首次加载时，解析这些外部的DNS会消耗一定的时间。下面是CSDN极客头条首页加载请求的JS文件，在该页面中就有很多个来自外域请求的JS文件。外域请求的JS文件规则3-避免页面跳转在服务器处理完HTTP请求后，会返回HTTP响应报文，如果浏览器收到的是一个3XX的响应，则网页会进行重定向。在报文头中会包含如下信息，浏览器会根据重定向的信息重新发送一次请求，如果重定向的次数过多，则网页会一直呈现刷新状态，而用户却看不到内容，这是一中很糟糕的用户体验，因此应该避免页面太多的跳转。响应头信息总结今天这篇文章只是介绍了几种性能优化的方式，后面会继续写剩余优化方式的文章，欢迎持续关注噢~本文由百家号作者上传并发布，百家号仅提供信息发布平台。文章仅代表作者个人观点，不代表百度立场。未经作者许可，不得转载。内部技术百家号最近更新：简介:各种各样的科技成果展览。作者最新文章相关文章Web前端性能优化进阶路 - 文章 - 伯乐在线
& Web前端性能优化进阶路
Web前端性能优化WPO，相信大多数前端同学都不会陌生，在各自所负责的站点页面中，也都会或多或少的有过一定的技术实践。可以说，这个领域并不缺乏成熟技术理论和技术牛人：例如Yahoo的web站点性能优化，以及大名鼎鼎的优化大师。本文并非一篇讨论性能优化技术方法的文章，而更多的是对中文站持续两年多的前端性能优化实践的思路总结。希望对正在从事这个领域研究的前端同学能有所帮助。
简单的说，我们的性能优化实践分为三个阶段：初探期、立规期、创新期， 每个阶段大概持续半年左右，有足够的时间形成一些优化思路的沉淀。
一：初探期
2010年底我们开始接手搜索List页面，这是中文站历史最为悠久的页面之一，当时它的生命体征正如它的年龄一样，非常虚弱：当时的基调网络监控显示，页面的完全加载的时间是16秒！作为以“快”为核心业务指标的搜索页面，这个状态显然已是无法承担重任了。
性能是一定要优化的，但我们也面临着大多数前端同学所面临的共性问题 — 业务需求紧张，况且我们是刚刚接手这个业务，非常不熟悉，别说是优化了，就是做个小需求也都经常出现线上故障。就是在这样的情况下，我们开始了搜索页面的性能优化之路，并且给自己定下了当时看起来非常难以实现的目标：在2011年年中前把全页面加载时间降低到7秒以下。
我们很快成立了一个性能优化小组，3-4个前端同学参与其中，一个人的力量毕竟有限，尤其是应对这样一个历史业务繁多的页面。参与的同学多些，技术氛围也相对浓烈，大家很全面的分解了目前页面上出现的性能瓶颈，并分别领取了自己的优化任务。
在这个阶段里，我们基本是照葫芦画瓢，把雅虎性能优化的那些法则与我们的页面一一对照，完成了许多优化点，例如：
●小图片的合并，形成CSS Sprite，并优化图片
●模块的异步加载
●图片的懒加载
●CSS文件引用放在页面顶部，JS文件引用放在页面底部，并对代码压缩
●缩小cookie体积
前人的技术理论果然是靠谱，经过我们半年时间加班加点的性能优化后，我们奇迹般的达成了优化目标！（附性能曲线图）
众多优化点中，对优化效果贡献最大的就是对图片的处理，包括了CSS sprite的合并及图片的懒加载，说白了就是雅虎性能优化法则的第一条：要尽量地减少HTTP请求。说实话，CSS sprite合并这块的体力活较多，但前端同学一定要引起重视，对页面性能影响确实很大。
初探期优化经验所得：
1、优化前，广泛地获取该领域的各种优化思路。有条件的同学可以参加下WPO领域的一些会议，比较推荐性能优化大会。
成立性能优化组织，明确性能优化目标。
这一点非常重要：可量化的目标以及可持续跟踪的优化数据是性能优化工作得以持续进行的保障，同时也是源动力！大家能持续这么长时间迭代的进行优化工作，正是因为每个阶段我们都有相应的性能优化目标作为指引，并有志同道合的同学一起努力。
3、持续追踪性能数据，要选择合适的页面性能测量工具，一旦选定后，不再更换，以保证历史数据的可参照性。
我们一直在使用，不得不说还是非常专业的，不过是收费工具。 给自家的测试工具也打个广告吧，免费的测量工具–。国外的测量工具也挺多的，不过受网络因素影响太大，数据抖动大，不是很推荐使用。
4、性能优化不仅仅是可以直接的提升用户体验，对参与其中的前端同学而言，也是快速熟悉业务的一种捷径。更进一步说，可以作为技术驱动业务的入口，因为优化重构的过程中你更容易发现历史业务的不合理之处，从而推动业务方的改造，可以提升个人的技术影响力。
二、立规期
性能优化工作并非一朝一夕的事，今天达成了目标，并不意味着明天躺着睡觉也能维持成果。相反，前端性能通常呈现出较高的反复性，这和新的业务需求有着非常直接的关系，但更底层的原因通常是我们并未把性能优化的规范给确定下来。2011年的下半年，我们并未在具体性能优化技术点上投入更多的工作，而是做了性能优化的“守道士”，不过这个“守”不是保守的“守”，而是以攻为守。
一方面我们制定了针对性能优化前端代码规范，其中最重要的是对页面图片资源的管理规范，纳入到SVN管理，提高新图片文件添加的成本。
另一方面我们建立了“性能联盟”：性能优化不仅仅是前端同学单方面就能够保证的，更需要产品经理、设计师、Java开发同学的支持和配合。在这一点上我们做了很多工作，当然更多的是沟通和意识的影响，让大家形成一个共识：性能是最重要的业务功能点！在平时的业务需求中，一定要从性能的角度考虑问题，有理有据的拒绝掉一些有损于前端性能的业务需求。
经过大家的努力，在这个阶段，搜索页面的性能一直维持在７秒钟左右，长达半年的时间。
立规期优化经验所得：
1、攻城难，守城更难。制订优化规范，并严格执行，是优化成果得以长期保持的必要保障。
2、性能优化不是前端同学自己的事情，需要业务各合作方的共同认同和支持。性能是最重要的业务功能点！
3、前端同学要增强自己的技术判断力，正确评估业务需求对性能的影响。同时要提升自身的沟通和影响力。
三、创新期
进入到2012年，随着我们对搜索业务理解的逐步深入，我们已不满足于在原有前端框架上的修修补补，而是有了更多的自信去彻底重写整个搜索前端应用框架。这也使得性能优化工作进入到一个新的阶段。
在这个阶段，我们努力的核心目标是：从应用框架和工具的层面做性能优化，让性能优化成为一件低成本的事，真正的做到 fast by default！
在搜索应用框架的构建过程中，我们将一年多的前端优化实践思路融合在其中，实现了对性能优化友好的模块注册机制、BigRender优化模式、&script&标签无阻塞加载等利用框架即可低成本实现优化的模式的支持。同时jEngine应用框架在模块化、前端异常监控方面也有着自己独特的实现，感兴趣的同学可以研究下。
简单介绍下对性能友好的模块注册机制的实现：jEngine的模块管理引入了“懒注册”的机制，所有的页面模块被分为以下三种模块：
一个模块的是首屏加载还是延迟加载，和它本身的类实现没有关系，只和模块的注册方式有关系。
如果他出现在首屏，就使用正常的模块注册方式：AppCore.register(“sw_mod_sn”, Searchweb.Business.Category);
如果非首屏模块，需要页面滚动加载，或是鼠标事件触发加载，那么它的注册方式只需改成这样：
通过这种的方式，可以低成本的改变页面初始化过程中对页面各模块的加载方式，从而减少首屏加载的文件个数和JS执行时间。
最后这个阶段，我们不仅形成了对性能友好的前端应用框架jEngine，还完全重写了搜索各业务模块代码，完成了从YUI到jQuery基础框架的升级，最终把页面加载时间长期稳定在4秒左右。
创新期优化经验所得：
1、从架构、框架上发力能够降低性能优化的后期维护成本。
2、技术思路上的创新是性能优化持续进行的源动力。
3、性能优化工作是提升前端同学技术能力水平的一个很好的切入点。
性能优化领域一个是值得前端同学深入研究的领域，网站性能直接影响到用户体验和各项业务指标。随着移动互联网的快速发展，这个领域的研究热点也有向移动性能优化转向的趋势，相信今后会有更多更精彩的技术出现。