#——OneAPM 使用小记
先用一组数据来开始整篇文章吧。
1.如果亚马逊页面加载每慢 100 ms，将影响他们 1%的收入。
2.如果谷歌页面加载慢 500 ms，流量将锐减 20%。
这是一组来自 gigaspaces 08 年的数据，而现在，页面延迟对公司来说影响会更大(虽然网络变快了很多，但是大家使用网络的习惯变化了，现在大家经常是用手机来接入网络，而移动网络是很不稳定的)。 页面加载速度，是如此的重要，所以我们就需要对前端页面加载速度进行不断的优化。这第一步自然就是获取用户的真实加载的情况，要不然只能闭门造车，纸上谈兵。
其实，我们在这第一步就受阻了。因为我们发现市面上并没有一款产品足够好用，能够让我们即时检测用户的页面加载情况。我们知道一些大公司是有相关的监控工具，但是没有对外开放。而如果公司内部自己开发的话，将是一个非常大的工程，并且统计出的结果未必精确，之后的维护也是很麻烦的一件事情。还好我们一直都有关注前端的一些技术会议。在报名Velocity的时候，我们认识了 OneAPM
大家可以看看 Velocity 的赞助商们（不得不吐槽一下，这届 Velocity，有一半都是赞助商们的广告），基本都是围绕着 APM 这个话题。我也趁机将他们中的绝大多数都试用了一下，最后选中了 OneAPM 作为我们的前端性能监控工具。
OneAPM 前端性能监控都有一些什么特色，让我们最终选择了他呢？我总结了一下大概有以下几点：
##OneAPM 提供了两种前端监测代码注入方式
一种是用户手动在 html 当中插入 script，一种是通过用户部署后台 Agent 自动插入 script。
我想说，大家都习惯了用 google 分析，百度分析，腾讯分析等等，对在页面当中插入一段受信任方的 js 并没有多大的反感。所以我开始试用就是采用了第一种方式，方便快捷，并且对代码影响是最小的。有某些 APM 工具，只支持上面的第二种，门槛略高，要想用一下还得改后台代码，当然各有各的优势。
##OneAPM 提供了非常丰富的展现维度
大家可以去 OneAPM 上看一下，展现的维度是相当的丰富。
OneAPM 并不只是提供简单的浏览器 performance 的上报，而是对其进行了一定的归纳，将其归为，白屏时间、首屏时间、H5 启动时间和网页就绪时间（这样挺好，但是我觉得如果也能同时展示出原始的 performance 信息，对专业调优的前端会更友好一些）。
还支持浏览器, 运营商, 地理三个围度的加载情况查看。提供了慢事务追踪，静态文件加载瀑布流。
其实上面两点，是我们最初想要的功能。能提供我们就已经很开心了。后面的几个额外功能更加让我们确信要使用 OneAPM 了。
##Ajax耗时功能
这是一个非常好用的功能。相信后台艰苦卓绝的将后台 CG I响应减少了 10ms，但是前端一不小心就多了100ms，甚至大几百 ms。所以前端 AJAX 测速同样是非常重要的。我们可以在这查看到哪一些 CGI的速度慢，可以进行专项优化。
##脚本错误功能
这个功能不得不赞一下，因为他让我们发现了不少内嵌 APP 页面的错误。开发过 Mobile APP 内嵌页的同学们都知道，移动端的调试非常麻烦，而移动端的错误就更加难以捕捉。有了这个功能，我们可以迅速知道我们线上页面的健康度（尤其是线上出现重大 BUG ，突发某一些错误时）。
##HTTPS!!!
其实这个最重要。。因为如果不支持 HTTPS 的话，我们就直接 bye bye 走人了。因为我们的页面对安全要求比较高，是全站 HTTPS 的。而 OneAPM 是 HTTP 和 HTTPS 都支持的。
##强大的技术支持
我只是在试用阶段，北京的 OneAPM 同学就直接拉了一个群，非常热心地解决我的各种试用问题，和解答各种技术上的疑惑。企业产品和个人产品不一样，企业产品最重要的是要用得放心，舒心。对于我来说， OneAPM 做到了。
综上，有了详细的用户加载时间，我们才能进行下一步的专项优化。
PS: 当然有要吐槽的：
吞吐量的单位 ppm，还是没有习惯，弄成PV是不是更好一些？
页面展示的维度，取 path 是不够的，这样容易让开发，测试和线上的数据混在一起（这个据说已在开发了，赞一记）。
注：本文转发已等的原作者同意，原文链接 http://my.oschina.net/u/2456862/blog/504697