不严格的讲，在杨致远和费罗在斯坦福大学的机房里撺掇出Yahoo!时，Web前端技术就已经开始进入公众视野，只不过当时没有一个响亮的名字。从那时起，“基于浏览器端的开发”就成了软件开发的新的分支，这也是Web前端技术的核心，即不论何时何地何种系统以及怎样的设备，但凡基于浏览器，都是Web前端开发的范畴。那么当我们说到前端时，第一反应都会想到交互、设计、开发，这是前端的基本组成部分，但其实就在这些表现的背后还隐藏了一个大Boss。
让我们先来看这样一个场景，明明前端设计做的很漂亮，交互做得也很好，但是用户在使用页面的时候却经常会遇到点击页面出现迟缓的现象，大大影响了页面的打开率。据统计，由于页面跳转停留时间长或者打开率低而造成的用户流失率简直高达20%，就算十二星座里面性子最慢的双鱼也受不了。运维发现了问题，找到前端，前端工程师开始采取各种各样优化的方法，比如：
效果如何呢?效果还不错。可是有时候问题却不在前端本身，而是由于后端服务器引起的，怎么破?
还有这样一种情况：
在我们的认知里，一个成熟的公司或项目里，前端一般只负责显示、交互和简单的现实逻辑，后端负责业务逻辑、数据存储。当前端出问题的时候，比如很简单的按钮位置不对，点击后的事件不对等，很轻易就能看出来;但是后端的问题，除非真的是逻辑写错很直白的错误，否则很难一眼看出来。但是不管是什么问题，所有人用户也好其他部门的也好，包括QA在哪第一接触的就是前端界面，所以很自然的就会把BUG扔给前端，前端费劲看半天，才发现可能有一半以上的都是后端问题——做过业务的前端肯定有过这样的经历吧。不是自己的问题但是第一个被指责的却是自己。
不用怕，拯救前端的工具出现了，只要使用了听云全栈溯源功能，让急脾气的白羊座和追求精细的处女座也能爱上的网页就能出现了!
听云全栈溯源——国内首家实现全端、跨应用监控的功能，能够帮助DevOps快速实现不同业务逻辑下的性能排障
什么是全栈溯源?
在复杂的应用环境下，精确定位并判断网络、移动端、浏览器端、服务端性能问题根源的技术手段。其中，它包括：
1、从移动端到服务端的性能溯源
2、从网络到服务端的性能溯源
3、从浏览器端到服务端的性能溯源
4、服务端跨语言跨应用的性能溯源
全栈溯源对DevOps的价值
1、降低跨部门排障沟通成本
2、从3天到5分钟快速追溯性能问题根源
3、性能问题界定，协助运维明确责任，协助研发修改问题
4、完整业务调用链跟踪(业务、运维、研发)
全栈溯源必要条件
在部署听云Server 的同时需部署听云Browser，打通双端。
(登陆听云官网https://account.tingyun.com/cas/login?service=https%3A%2F%2Fsaas.tingyun.com%2Fj_acegi_cas_security_check%3FloginView=casLoginTingyun
了解全栈溯源)
什么是全栈溯源之浏览器端到服务端的性能溯源?
浏览器端性能溯源，是指页面和Ajax请求等对应Web应用过程的服务器端性能分析。听云Browser的性能溯源， 是指浏览器端的慢页面对应的Web应用过程发生慢追踪时的服务器端性能分析。
浏览器端性能溯源，实现了浏览器端到服务端的性能可视化，在定位浏览器端性能瓶颈的同时也发现了服务端性能问题。
如何使用?
一般应用的性能损耗会发生在网页前端、网络以及后端服务器。听云Browser能够监测网页访问的性能情况，配合听云Server可以了解到服务器端响应的性能损耗。
l 在听云Browser应用列表中采用自动嵌码Server探针的，可以直接查看听云Server应用的情报汇总
l 页面分析和AJAX请求中添加到Server的Web应用过程的查看
l 直接跳转到停运Server控制台下对应的web应用过程进行分析
l 在听云Browser的慢页面追踪中，如果元素超过阈值可以继续进行Server的慢应用过程追踪
l 可以继续定位到听云Server慢应用过程追踪详情
全栈溯源可以将所有你能想象得到碎片化的问题完美整合，以一种串行的方式去定位问题，并且无论从研发人员还是运维人员角度去利用听云全栈溯源去解决问题，都可以非常直接、准确定位问题出处，高效将问题解决。
