互联网的发展，有目共睹，网速变得越来越快的同时也让网页越来越复杂，用户的耐心越来越少，网页打开时间稍长，就会造成大量的用户流失。于是， Web性能优化(Web Performance Optimization)成为网站的日常运营中一项非常重要的工作。最近也看了一些关于这方面的文章，总结和收集了一些大神们的优化建议，分享出来希望能帮助到大家：

1、Matt Shull：最常见的错误之一就是无限制使用Render-Blocking内容，很多网站并未因使用Minification机制而获益， Script脚本的响应速度并未改善，请求数量也未降低，因为担心会对Javascript造成延迟，进行影响网站整体的访问速度。

2、Una Kravets：盲目为网站添加许多框架以获得很小的功能是我看到的一种通病，这会大幅增加Web页面的大小，在Web页面设计之初就应该考虑到性能问题，而不是留到最后再去做优化。

3、Dean Hume：最常见的错误也是很简单的错误，包括：未优化图片、未打开GZIP，这些都是每个人都应该掌握的Web优化速效方法。

4、Harry Roberts：说到常见错误，真是太多了，比如只追求数值指标(页面大小，请求数量等)，未关注APP的用户感知性能等。性能最关键一点是网站给人的感觉有多快、用户与页面和APP交互的速度有多快，而不仅仅是网页加载速度快就行了。1.5秒内可以打开且能够接受100个请求的网站，肯定大大优于7秒内才能打开且只能接受32个请求的网站，所以，少关注技术指标，多关注用户体验指标。

5、Sara Soueidan：未优化图片和为了追求差异化使用不常用的字体，是在我浏览大多数有问题网站中，导致页面加载时间较长的两个最常见的原因。

6、Patrick Sexton：我认为最常见的错误是乱用框架，明明不需要框架就可以完成的工作为何要加上框架呢?我见过有人因为一些让人非常抓狂的原因而往页面上添加jQuery ，比如将图片向上移几个像素或完成其它很简单的任务，CSS框架问题也很常见。我们似乎忘了是为用户制作Web网页，而不是为设计师或程序员提供方便。框架的“便利”之处，就是造成Web网页越来越臃肿的罪魁祸首。

7、Kent Alstad：

很多人没有意识到不同网络组件之间的性能影响是相互耦合的(无论是技术方面还是概念方面)，也许稍有变动就会影响其他组件的性能。比如说，你可能对Web页面做出了一点点变动，有四成把握让新优化的代码速度提高5%，结果却发现RUM统计数据变得更糟糕了。所以说，整体性能的优化绝不是件容易的事情，不是每个人都能够理解优化结果，也不是每个人都具备做出合理决策所需的整体性能均衡把控能力。要解决这一问题，我们可以预先设定一个整体性能的衡量标准，这样就可以有效地做出改进并衡量改进的地方。

另外一个常见错误是让开发者利用他们熟悉的旧工具写代码或改写代码，来解决性能问题，大家的第一反应通过性能指标来发现问题和解决问题。大多数时候性能的缓慢都出在前端代码，跟服务器端代码性能关系不大，但我却经常看到运维或后端工程师为了性能优化改写服务器代码的情况。

此外，第三方资源常常把开发团队搞得晕头转向。通常由领导、产品运营部或其它非开发部门决定是否加入新的第三方插件或服务，而当第三方服务失败或数据调用缓慢时，我们并没有相关的性能优化方案，甚至没有足够的文档支持进行优化。这种关心性能却大量依赖第三方服务的网站和应用越来越多，所以必须认真制定策略来管理解决第三方的程序。

8、Andreas Grabner：

§ 以为全世界的人都跟你用同样的浏览器，程序猿爱用Chrome或Firefox浏览器并不代表用户就愿意用这种浏览器，IE的影响力依然巨大!

§ 把App给你的家人体验一下，看看他们是否能不问你下一步该做什么，就能够用好你的APP(吐个槽，工商银行的网银助手简直是反人类的，如今还以Windows 2000和IE6为主要运行环境)。

§ 从来不用2G网络和4吋屏以下的低端智能机测试网站和应用，虽然这样才能真正检验出网站和应用的性能浪费有多厉害。

§ 开发者通常不会认真对待单个用户的体验有多差，总认为这是个案(除非这个用户是他的大Boss);另一个不当回事的是不考虑每个功能的综合资源消耗：用户通过移动端下载App需要多少流量、公司对此需要向CDN支付多少费用、需要向Iaas厂商支付多少CPU费用和存储费用等等。

§ 太依赖于第三方服务或部件(这是一把双刃剑，用或是不用，是个艰难的决定。)

§ 乱用缓冲(浏览器、CDN、Web服务器和App服务器)

§ Web服务器、App服务器和DB服务器上的连接池(connection pools)大小不准确

§ 投入使用之前缺乏压力测试和性能测试

§ 简洁的功能实现并不意味着APP和网站就能部署上线，在云计算和移动互联网时代，测试工作必须站在更高的视角，不仅要关注浏览器，还要从整个交付链的角度检测性能问题、发现优化点!(广告乱入：云智慧压测宝通过500+遍布全球核心骨干机房的云端压测服务器，发起真实的高并发用户访问，针对全链路和全业务进行压力测试，发现应用系统的性能瓶颈。)

9、Denys Mishunov：开发人员太关注毫秒、字节和请求数量这些数字指标，尽管这是性能的一部分，但它们并不承载网站和应用的功能体验。我们首先要思考的是用户使用网站的体验如何，而不是我们可以节省多少字节，只有准确感知用户的感受，我们才有必要谈毫秒、字节和请求数量等问题。

10、Damien：优化Web性能的时候会犯很多常识性错误，为避免这种情况的发生，你需要进行自动化性能监测，并构建自动执行的优化任务，在工作流中也需用到自动执行的任务(如：优化有用的图片)，如果想更好地进行自动化，需要在监测过程中进行合规检查。当然，这件事监控宝能干得猴赛雷!

11、Philip Tellis：不做整体性能的检测，人们往往会根据一系列规则修补他们眼中的“问题”，但不能从用户的视角和交付链条出发(以支付为例，从登录到确认再到返回结果，是一个完整的交易链条)，为业务设置一个性能基线，然后量化的任何改进或回归。

结语：

歪果砖家团观点再度强调了图片优化的重要性，同时他们的经验告诉我们，网站优化不能拘泥于一个页面的性能指标优化，而应该以真实用户的视角，从整个网站的业务逻辑、业务流程出发，制定有针对性的整体优化方案。