世界顶级Web性能专家带你优化出高性能网站（下）

这是《世界顶级Web性能专家带你优化出高性能网站》系列的最后一篇，也是云智慧在猴年春节前的最后一次干货传播，首先在这里给大家拜个早年，祝各位云智慧的用户、朋友猴年行大运，事业猴赛雷！
前两天的砖家观点集中在图片优化对于网站性能的重要性，以及网站优化不能拘泥于页面性能指标优化，而应该以真实用户的视角，从整个网站的业务逻辑、业务流程出发，制定有针对性的整体优化方案，那么今天的砖家又带来了哪些精彩观点呢？
这次网站优化调查由keycdn.com发起，邀请二十余位歪果砖家团回答了下面两个问题：
1.        如果只能选择一个方面进行Web优化，您会选择哪个方面？
2.        就Web性能而言，您看到哪些错误最常见？

________________________________________

 Kent Alstad / @kentalstad / webperformancetoday.com
Radware Acceleration部门VP，技术创新者与致力于让互联网更快的性能研究员。

答案1——优化建议

只关注某个方面的优化工作是非常短视的，但我们可以关注某些重点领域：图片是大多数网站和APP中很重要的部分，因此为每个用户提供最好的图片，并将图片缓存在正确位置以便反复调用。根据用户体验，优化或解耦App中第三方插件的性能，将有效控制App的SLA。最后考虑下HTTP/2相关的优化，将传统HTML的应用瓶颈优化至网络层，因为网络层的优化对IT人员干扰更小，且通常更为有效。

答案2——常见错误

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

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

此外，第三方资源常常把开发团队搞得晕头转向。通常由领导、产品运营部或其它非开发部门决定是否加入新的第三方插件或服务，而当第三方服务失败或数据调用缓慢时，我们并没有相关的性能优化方案，甚至没有足够的文档支持进行优化。这种关心性能却大量依赖第三方服务的网站和应用越来越多，所以必须认真制定策略来管理解决第三方的程序。
补充一句，现在的云平台大量使用API来交付服务，同时登录、支付、定位等移动互联网必不可少的功能也是通过第三方API接口来进行数据通信的，所以必须对API的性能进行即时监控，监控宝提供的API监控功能，不但可以即时监测APIs数据及时性、正确性问题，还能对多个API关联组成的业务进行监测。
________________________________________

 Maximiliano Firtman / @firt / firt.mobi
移动+Web开发&咨询，O’Reilly作者

答案1——优化建议

专注移动开发的极致技术，例如如何在1秒之内完成ATF内容的传输。

答案2——常见错误

        未在移动网络和真实的移动设备上进行测试；
        把响应式Web设计当成目的，但我们的真正目的是性能。
        低估了移动浏览器和Web浏览的流量。
        过度使用网络字体。
________________________________________

 Andreas Grabner / @grabnerandi / apmblog.dynatrace.com
软件极客，Dynatrace博主。

答案1——优化建议

对于每个页面和功能都应该认真考虑：如何花费最少代价实现页面功能，至于其它酷炫的和牛逼的功能，为了性能，统统删掉吧！

答案2——常见错误        

以为全世界的人都跟你用同样的浏览器，程序猿爱用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+遍布全球核心骨干机房的云端压测服务器，发起真实的高并发用户访问，针对全链路和全业务进行压力测试，发现应用系统的性能瓶颈。）
________________________________________

Jason Grigsby / @grigs / cloudfour.com
Cloud Four联合创始人，热衷于移动网络技术。

答案1——优化建议

GZIP对服务端文件传输有很大的帮助，也很容易应用于大多数Web服务器，然而大部分网站并未使用GZIP。因此，性能优化不妨从常识GZIP开始，参考网址：http://w3techs.com/technologies/ ... compression/all/all 。

答案2——常见错误

最大的错误是不重视测试，而是只安排一两个人做测试。只有一个清洁工清理乱况和有一个清洁组织专注于系统的整洁程度是两种完全不同的状况，特别是在高访问压力、高负载状态下，即便是一点点系统延缓，也有可能造成业务不可用（参见12306、微信抢红包）。 
________________________________________
  Denys Mishunov / @mishunov / mishunov.me
FastName公司前端开发，Smashing Magazine撰稿人。

答案1——优化建议

很显然，并不是性能优化本身，而是对性能的感知，开发人员通常忽略心理学带给他们的好处（而这一点，骗子和黑阔做的最棒）。心理学可提供简单而有效的工具，帮助管理用户对性能的感知度。这并不是说我们应该忽略代码、资源的性能优化，而是我们可以用其它方式达到这种效果，以节省服务器时间、加载时间、宽带，并遵循响应式Web设计的其它属性。优化是需要时间的，心理学为开发人员提供了宝贵的缓冲时间来完成这些优化工作，同时还能让用户第一眼就满足于页面的设计。

答案2——常见错误

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

 Damien Jubeau / @DamienJubeau / dareboost.com
DareBoost公司CEO，专注于提供分析和监测工具。

答案1——优化建议

图片，因为只需对图片下很少的功夫就能看到很大的成效！

答案2——常见错误

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

  Stefan Judis / @stefanjudis / perf-tooling.today
前端开发，perf-tooling.today管理者

答案1——优化建议

我会重点进行容易实现且会产生很大效果的优化，保留尽可能少的多媒体资源能有效降低页面大小，并为浏览页面的用户带来很大方便。包括减少文本文件（并以压缩文件的方式提供这些文件），但更重要的是使用正确类型的适当压缩的图片（jpeg、png、SVG等，取决于具体的使用情况），对这方面多加注意能让页面大幅度减小。

答案2——常见错误

有人认为就Web性能而言，服务器响应时间是唯一重要的事情，这种理论就跟电脑慢了就要重装系统一样滑稽。实际情况是：拥有最快的服务器并不意味着拥有快速响应的网站，否则x86服务器也不会逐渐取代小型机，我们必须经常监测前端的运行情况，包括检查资源文件大小、寻找渲染受阻请求，并对网络状况有准确的了解。
________________________________________

Stephan Max / @smaxtastic / stephanmax.is
IBM Bluemix的Technical Cloud Specialist，前端开发人员，Sitepoint作者。

答案1——优化建议

当然是图片了，有人说Web开发95%的工作是排版（我完全同意这个观点），根据HTTP Archive于2016年1月份发布的统计数据，图片仍然占页面平均大小的64%（参见：http://httparchive.org/interesting.php）。响应式图片社区（Responsive Images Community Group ）正致力于将应用于Web页面开发的响应式图片新方法标准化。随着浏览器越来越多地考虑指标问题：CPU、网络覆盖、屏幕等，2016年会有更多的变化。

答案2——常见错误

我的很多客户（甚至包括一些大型企业网站）仍在纠结于基础性的东西，如大量复制和粘贴网页代码，而不思考把它们放在哪里更合适，是否需要异步加载这些脚本，或到底需不需要脚本。每个Web开发者都应该知道渲染路径的来龙去脉，并了解如何处理解析器/渲染/脚本阻塞资源。
________________________________________

 Philip Tellis / @bluesmoon / tech.bluesmoon.info
SOASTA首席架构师，LogNormal联合创始人

答案1——优化建议

让UI更为顺畅。

答案2——常见错误

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

总结

每天与Web/应用性能优化打交道的歪果砖家团给我们提供了许多有用的建议，首先值得注意的是图片优化的重要性，几乎50%的答案都重点强调了图片以及图片与页面大小的关系；还有一些专家提到了另一个因素，就是用户感知性能，技术人员往往过于重视从数据分析和速度测试的角度进行优化，但从用户的角度解决问题才更重要；测试在IT基础设施广泛云化、DevOps大行其道、应用交付频率越来越快的今天，其重要性越来越高，有效的测试才能保证不断快速迭代的应用和网站更可靠，性能更好。

云智慧面向产品全生命周期的应用性能解决方案，覆盖终端、网络、服务器、存储和代码等业务链条的各个环节，从应用的开发、测试到线上运维，提供完整生命周期的性能监测、管理和优化，帮助企业解决用户体验前置以及云计算的快速发展带来的系统架构变化的种种性能挑战。

了解监控宝详情，免费使用IT监控神器——监控宝请关注云智慧官方微信（cloudwise2014）。