介绍APM为何应该以用户体验为核心，以及性能极客如何提供新一代web及移动端的 前端性能监控优化服务。

近年来，开源在高科技技术行业正在成为越来越重要的资源。对于web前端开发人员和社区，更是如此。新的理念，框架，和库不断出现和更新。在选择开源框架和库的时候, 可用性和可学习性是开发者们最初最关心的。性能往往会被忽视，有时则可能在项目初始阶段无法预知。

通过Yahoo Media近年来前端web应用JS框架的进化过程，我将会探讨驱动框架演变的各种因素，特别是性能对技术发展和选择的影响。

1. 背景
2. 用户数据采集和计算
• navagation timing
• resource timing
• 数据计算和去噪
3. 性能大数据应用场景
• 发现性能瓶颈
• 性能问题排查
• 提升优化效果预估准确度
• 优化效果衡量
4. 主要优化实践以及提升效果
• dns优化
• https静态资源上cdn和spdy
• tcp优化
• 静态化+ESI，页面动静分离，静态内容边缘化
• 动态加速，主要优化网络链路
• cdn调度优化，统计调度地域的差异，针对差的重点优化

Web 开发最重要的工作之一就是取悦用户。我们非常了解高性能 Web 体验恰恰能做到这一点，而且已经做了大量改进针对性的改进，比如 TCP 的 slow-starts、resource parallelism、单线程渲染以及很多问题。我们称之为“最佳实践”。

现在是 2015 年，仅靠那些“最佳实践”来取悦用户正变得越发困难。用户正通过不同尺寸、操作系统、容量的设备来使用我们的服务，为了提高性能我们的应用也变得越来越复杂。而且情形愈发严重。

本议题中我会探讨在用户期望和产品要求发生变化时取悦用户所面临的新挑战，如何在新技术帮助下改变我们的最佳实践，更重要的是新技术如何和现实结合，在现阶段下 Web 工程师如何平衡二者。

京东618已经过去，在开发和备战618期间总结过一些设计原则，也遇到了一些坑。而且随着网站业务发展，需求日趋复杂多样随时变化；传统静态化方案会遇到业务瓶颈，不能满足瞬变的需求。因此需要一种能高性能实时渲染的动态化模板技术来解决这些问题。

本分享会从如下方面介绍：

1. 京东商品详情页发展历史；
2. 架构设计原则和一些最佳实践；
3. 遇到的一些坑和解决方案。

页面的加载时间大部分都消耗在文件的下载上，而在相同应用、相同网络环境下，决定文件下载速度的是TCP协议栈，通过对TCP协议栈的优化，能够有效的减少页面的加载时间10%-30%，能够将视频的卡顿率减少20%-50%，能够大幅提高在无线弱网环境下的文件下载的成功率。本演讲我们将会从原理上介绍为什么TCP协议栈会影响文件的下载速度，然后我们会讲解现在TCP协议栈存在的一些问题和改进空间。最后我们会介绍一下我们阿里云CDN在TCP协议改进和定制上做的一些成果和经验，包括针对图片的优化、针对视频的优化，端到端的QoS、网络服务质量的采集等。

1. webim系统难点
• 基于通知的系统难点
• 消息实时性难点
• 消息可靠性难点
• 状态同步难点
• 复杂的业务难点
2. webim架构设计与实现
• 协议设计
• 架构分层设计
• 核心模块功能
• 核心业务流程
3. webim性能优化细节
• 百万连接优化
• 消息实时性优化
• 个人消息可达性优化
• 群消息可达性优化
• 数据层性能优化

对于通过 API 部署的服务，理解和管理延迟是创造良好客户体验的重要部分。本议题您将会听到 API 服务性能监测的战略，重点放在延迟和反应测量上。讲话将涵盖监测和测量技术，数据分析和如何使数据可操作。

介绍如何提供精准地评测页面及app的加载速度，以及如何有效 地实施前端性能的监控和优化。

网站的性能越来越成为互联网发展的重中之重。要提升性能前提是先能找出性能的瓶颈。抓准要点，才能一击必中。eBay作为全球领先的互联网公司，很多年前就开始从各个方面监控和测量性能有关的指标，并且提出一些切实有效的方案提升了整体性能。

通过分享一些eBay的真实案例和工具，希望能和大家互相借鉴，取长补短。

• 三种常用方法来监控网站性能
• 网站性能监控: 一次故障实例
• 网站性能监控: 从Site Speed Gauge上观察到的故障影响
• 网页加载时间线示意图
• 实时用户数据搜集架构图
• 为页面加入用户数据采集功能
• eBay计时API
• eBay如何监控广告加载时间
• eBay如何测量可视区域的加载性能
• 合成测试在eBay: 性能报表
• 性能提升: 意大利站点启用DSA后的性能监测
• 性能提升: Global DNS显著提升了俄罗斯的页面加载速度
• 总结, 经验以及未来的发展

随着互联网产品规模的爆发式增长，大型分布式系统的监控复杂性也日益显现。工程师们发现：监控遗漏导致宕机的黑天鹅现象频繁发生；出现故障时很难从海量监控指标中迅速找到故障根因；报警风暴极大地干扰了工程师定位问题的速度；故障恢复速度基本依赖于工程师的操作速度。由此，我们尝试建立一个智能运维监控系统，希望用智能化手段去帮助工程师解决这些问题。

在本议题中，我们会以实际例子来讲解，在百度我们是如何帮助产品完成智能化运维监控之路的。主要包含如下一些内容：

• 如何发现商业数据与运维数据的关系
• 如何进行异常的自动检测
• 如何解决报警风暴
• 如何进行自动故障定位
• 如何形成发现+定位+止损的监控闭环

Betty 之前在 Yahoo 以及目前在 Amazon 都组建过一些专业工程师团队，包括 YSlow 移动团队，近期在 Amazon 的团队启动了全站范围前端框架影响了 amazon.com 超过 90% 的流量。本讲话中她将分享在组建专家团队中的所学，你在寻找什么样的人，如何吸引他们，如何创造愉快的工作环境，在数据不充足的情况下如何作决定，等等。

从交付内部软件系统迁移到在云平台上部署一个服务，对任何企业来讲都是巨大的项目。除了显而易见的技术变化外，文化和商业的转换也是非常重要的。Message Systems 创始人 George Schlossnagle 将讨论如何成功转换到云业务。

做实验是个理解客户非常好的办法，但它在性能和可维护性方面也带来额外代价。在一个复杂系统上同时跑数百个实验情况可能变得更差。本讲话中我们重点会放在实验如何给前端性能带来冲击，并且讨论如何选择一个较好解决问题的方法。

Web App 的 Native 化是这两年比较火热的话题，Hybrid App 是一个使用很广的方案。但是 Hybrid 确无法解决 WebView 在页面流畅度上的卡顿。Facebook 发布的 React Native 比较好的解决了这个问题，但是 React 本身却是对传统Web开发的颠覆（完全不同的UI构建方式、Native化的API），那么有没有一种既能够兼容传统 WebView，又有着媲美 Native 性能的开发方式呢？boostUI的出现就解决了这个问题。

1. 百度直达号中 Hybrid 技术的应用。
2. BoostUI Native 可复用基础组件设计。
3. Native 布局引擎。
4. UI系统与事件队列。
5. Demo 展示。

1. 如何利用 Docker 技术打通程序开发，测试和部署流程。
2. Beyond Docker: 在Docker上增加自定义抽象层辅助管理复杂服务。
3. 版本管理，发布，以及利用 Consul, Prometheus, ELK 等创造自适应可视化运维平台。

一年前,Yahoo Frontpage团队开始开发新一代前端web应用JS框架。我们选择了Facebook的React，同时开始將Flux理念拓展到node.js服务器端, 开发了Fluxible -- 最早客户端和服务器端同构的开源Flux库之一。一年后的现在, 我们已经成功的运用这个框架开发并推出了多个新的Yahoo Frontpage web应用。

我将会分享我们:

• 为什么选择React和Flexible
• 遇到过哪些挑战, 如何解决它们
• 怎样提高React在服务器端的性能
• 提高用户感知性能的技巧和窍门
• 如何运用ATS ESI 进行进一步优化，以满足Yahoo Frontpage严格的性能和可靠性要求。

Hybrid App（混合模式移动应用）看上去是一个Native App， 但只有一个UI WebView，里面访问的是一个Web App，兼具“Native App良好用户交互体验的优势”和“Web App快速迭代的优势”，这里给大家分享一下我们使用这种模式遇到的挑战和解决过的“坑”，特别是在接口调用，资源加载，渲染速度和帧率等方便的优化尝试和经验分享。

互联网上每时每刻都有信息泄露，请求被劫持和篡改的事情发生，为了让用户能够安全、放心的在我们的网站上购物，我们对淘宝进行了全站HTTPS改造工作。这是全球最大的电子商务网站第一次全站HTTPS实践，因此遇到的挑战非常巨大：

1. 淘宝全站HTTPS的背景
2. HTTPS的基本原理
3. HTTPS对架构的影响
4. HTTPS的成本、安全、性能和用户体验
5. 应用改造常见的坑

在服务运维环节，业务监控是非常重要的一个环节，对于业务指标的异常变化要及时发现和处理。通常业务信息是从服务日志中提取，但由于影响业务指标的因素众多，通常需要从多个角度逐层细分到多个维度进行分析和监测，例如对PV按运营商、省份的流量细分，或按URL类别细分，或按浏览器来源细分，等等。业界有ELK的整体解决方案，但在大规模数据下性能表现并不尽如人意，百度服务监控平台针对这种场景专门设计了一套解决方案，主要包括高性能客户端数据采集和归并、Storm计算、HBase存储、异常波动监测、可配置化展示等环节，在性能和灵活性方面有很多考量，业务方只需要提交一些配置信息，即可使用整套服务。

为了满足不同用户的多样性购物需求，过去两年里手机淘宝的业务不断膨胀，从单一的购物工具成为了购物内容平台。在手淘业务快速增长的同时，也带来一些副作用，很多操作环节和页面因为承载功能太多，展示的速度变慢，用户等待时间变长。性能优化势在必行。我们根据手机淘宝用户的购物操作流程，对每个步骤和模块都进行监控，以量化数据为指导来进行优化。这次演讲介绍启动、首页、购物车三个业务环节中，手机淘宝开发团队在网络调优与图片下载两个领域的优化方案。

以手机淘宝前端实践为例，讲讲移动互联网时代，无线前端如何利用技术和工程体验，带给用户体验提升。

• 下载时间：下载时间是web端体验的重要瓶颈，在移动设备上，传统的下载性能优化经验（如雅虎34条军规），有一部分已经不能满足需要，甚至会产生相反的。手机淘宝团队建立了一套的性能监控和测试和研发体系，经过一年的迭代优化，最后得到了一些新的经验结论，也产生了一些工具，会与大家分享。
• 渲染性能：渲染性能决定了页面动画是否流畅体验，大部分这些工作由浏览器和硬件完成。而在移动端webkit统一天下的局面下，深入了解webkit核心的一些机制，可以帮我们得到更好的性能。
• 用户体验：用户体验不仅包含了可量化的部分，也包含了用户心理相关的部分，手势、动画的恰当使用，可以弥补性能的缺陷或者锦上添花。我们一方面与设计师合作推进这部分设计，另一方面也做了大量基础建设。

分享阿里巴巴在移动网络领域相关加速技术。

1. 移动网络特点，对比与有线网络的区别和存在的问题；
2. 针对移动网络的特点阐述网络加速思路，以移动加速解决方案CAS为例介绍加速架构；
3. 介绍移动加速框架下针对通信协议的优化，如SPDY协议；
4. 介绍加速框架中链路层面的优化，包括HTTPDNS的引入、遍布全国的就近加速节点以及加速节点前移的思路；
5. 介绍内容层面的优化，主要是针对图片的压缩、机型的适配等；
6. 总结展望。

1000 QPS的站点，是个工程师就能做的出来。1万QPS的站点如何做？10万QPS的站点又如何做呢？本次演讲告诉你，如何完成10万QPS量级的web server，从技术选型、实践结果以及我们工作亮点举例，以身边的故事走入异步编程网络。如果您已经是openresty的开发一员，那我们多了一个伙伴。如果您还不了解它，那么我相信这次旅行，可能会颠覆你的认知，为啥身边有这么牛X的利器今天才初露光芒。