本次宣讲是前端早早聊第52届大会实录

大会介绍

前端早早聊目前已经举办51届，内容涉及话题有：转管理、基建、搭建、规划、监控、Serverless、微前端、大厂面试、在线文档、跨端跨栈、前端女性的职业路、可视化、构建、成长与晋升、报表、组件化、框架、性能优化、团队成长、小程序、页面搭建、CI/CD、算法、晋升述职、互动、跨端 Flutter、WebGL、可视化、BFF、前端质量、安全...

第一页 主题

今天主要要跟大家分享的主题，是如何通过观测云提升用户体验，要深入讲性能优化，可能需要的时间远远不是短短这次交流，前端性能优化范围很广，今天把我这几年前端研发工作的实践、阅读的书，以及在过程中的一些思考，抛砖引玉，希望对大家有所启发。

第二页 目录

第三页 可观测性的引入

Gartner在10.18日发布企业机构在2023年需要探索的十大战略技术趋势，Gartner 2023年战略技术趋势围绕优化、扩展和开拓这三大主题，这些技术能够帮助企业机构优化韧性、运营或可信度、扩展垂直解决方案和产品交付并利用新的互动形式、更加快速的响应或机会进行开拓。”

第四页 可观测性的引入

在Gartner的这个报告中显示，应用可观测性排行第二。 可观测性的应用能够是企业利用他们的数据获取竞争优势，它能够在正确的时间提高正确数据的战略重要性，以便根据确认的相关行动而不仅仅是意图采取快速行动，因此是一种强大的工具。如果能够在战略中予以规划并成功执行，可观测性应用将成为数据驱动型决策的最强大来源。可观测性这么重要，那么到底什么是可观测性呢

第五页 可观测性的介绍

CNCF 早在定义云原生的概念时就提到了可观测性 ，它声称可观测性是云原生时代的必备能力。可观测性是通过技术手段引导系统从 不可预知性 去往 确定已知性 的 全新思维理念，当我们将可观测性的概念应用于软件系统时，主要是为了：了解应用程序的内部运行情况。简单的说，可观测性是一种度量能力，帮助使用者能够更好的理解和解释系统当前所处的任何状态，无论你之前是否遇到过或者这个状态有多奇怪。都有能力通过各种维度和各种角度去分析发现和理解这个系统当前所出现的状态，而不需要预先定义或预测那些调试需求。如果能够在不发布新代码（如增加一个用于调试的日志）的情况下理解任何奇怪或不确定性的状态，那么你的系统就具备可观测性。 管理学大师彼得·德鲁克：If you can't measure it, you can't improve it.“如果你不能够衡量，那你就不能有效的增长。”

第六页 可观测性的资料

而随着可观测性的概念明晰化，相关产品纷纷涌现，“可观测性”越来越成为云原生一个绕不开的话题。该如何更多的了解可观测性，这里给大家推荐一本书，叫做oe，这本书我也参与了翻译，很快就会在国内出版。等不及的小伙伴呢，或者更习惯看音视频来成长的话，可以扫描右侧的二维码，《深入浅出可观测性》是一份理论和实战的短视频课程，有概念篇、基础篇和实战环节。可以 帮助快速深入了解可观测性。

第七页 前端可观测性的简介

了解应用程序可能得状态，这种可能是前端开发的同学没见过和无法预测的。举个简单的例子来说 随着网站交互的增多，网站的复杂度变高了，前端可观测性就更难做了。大多数前端同学能看到的是本地开发环境，我们能够根据经验设定一些指标的值来预警，虽然大多情况下并不能理解为什么发生了告警，尤其是对线上异常的解释，比如发现某个问题和某些东西相关，但是无法进一步分解定位到根因，那么更无法进行相对应的进行优化，无法达到线上可观测的目标。

第八页

首先需要讲的是产品或者系统的性能与系统稳定有关，经常会出现用户经常反应的一个情况，就是页面报错或者卡顿。但是因为设备不同、浏览器兼容、网络快慢、产品设计等原因，开发或者研发很少能复现。还有更常见的场景，便是报错或者卡顿还没来得及上传到RUM系统或者反馈上来，用户已经流失了。很明显系统稳定跟留住用户有关，系统报错与用户体验有关，用户体验跟用户增长有关。而且通常前端开发工程师的一个难题是，能否快速定位系统性能问题是发生在前端这一侧每一个用户实际请求所产生的性能问题导致的缓慢，还是其他环节呢？

第九页

要解决这个问题，首先需要尽可能多的收集事件的详细信息，对数据进行聚合分析，并采取相应的行动。但首先收集上来的数据量级巨大， 这些聚合的数值并不能告诉我们更多的信息，让我们了解在相应的系统中发生了什么——它们不会告诉你是哪些过程导致了这种状况， 为了缓解高基数数据量带来的无法快速定位构建可观测性的难题，一种解决办法是使用仪表盘，通过仪表盘能了解系统的运作状态，最重要的是，能够对指标的值有所了解，而且能清楚的了解指标的趋势。如果仪表盘界面上增加了过滤器和下钻，让你可以更深入和缩小可视化，以提供更多的分析故障的能力。当前服务收集的各种指标是无法在一个仪表盘中进行展示的，各个角色的人也有个各自的需求，后面我将同时展示一些相关的图表。 可观测性满足的是如何使团队能够识别先前已知和未知的问题。 其实重点还是在于探索了解系统的未知问题。

第十页

观测云能提升用户体验，他具备丰富的追踪能力，能利用精准的用户会话数据，对网站进行详细的分析，并通过强大的仪表进行展示。

第十一页

第十二页

第十三页

第十四页

第十五页

第十六页

第十七页

第十八页

阈值检测：基于设置的阈值对指标数据进行异常检测，当数据达到阈值时，触发告警并通知用户。 突变检测：基于比较两个不同时间段内同一个指标的绝对或相对（%）变化值来判断是否产生异常情况。多应用于追踪某个指标的峰值或者数据变化，当出现异常情况时可以更精准的产生事件留做记录。

第十九页

现在开始这次对提升性能的第一个实践和经验分享，便是FCP。 FCP是早期性能指标发展中比较早的一个指标，在常见的client-side-rendering场景中的spa架构中，因为body下id为app的div的渲染的结束，导致fcp通常大于等于first paint，FCP更适合在ssr场景中对首次内容渲染后用于衡量网站的加载体验，如在ssr的网站性能监控中，就比较建议针对FCP做告警设置。虽然fcp对于提升网站提升有效，但这个指标对于用户真实体验有较大的差异。fcp和真实发生的页面渲染之间往往还存在着网络资源队列处理请求、资源解析和dom的实际渲染中特别多的因素，随着页面内容复杂度攀升，当前渲染页面是否允许用户操作，页面渲染是否令人愉悦，但随着将rendering更多的放在浏览器侧，Fcp已经远远不能满足用户体验对性能检验的需求。便是今天还要跟大家分享在实践中需要关注的几个指标。

第二十页 核心指标及实践

今天跟大家聊一聊几大核心指标，首先是这些指标的含义，和指标如何解读，还有这些核心指标的影响因素。 这三大指标分别是从页面加载、用户交互以及视觉稳定性的角度入手。这个有点类似谷歌2022开发者大会的数据，但又不完全一样，主要是long task和errors，后面我也会根据观测云的仪表来给大家展示，

第二十一页 度量loading的指标

LCP是一项以用户为中心的指标，用于衡量网页被感知到的加载速度，指的是可见的最大内容元素的渲染时间； 如图中所示，LCP应该在页面首次开始加载的2.5秒内，超过2.5sLCP则被定义为poor； 我们来查看一下LCP的影响因素呢，当用户访问一个网站，从端上发起请求后通常有好几个阶段，一般浏览器都不知道接下来要用什么内容，可能是css、js、字体和图片、或者音视频，其中浏览器大部分时间都花在等待服务器的数据。从端上传输到服务器，然后再返回设备。如果能预拉取这些内容，那么能极大的提高加载速度，即使只是预先拉取部分文件，也能有很显著的网页速度提升。 观测云推荐用户能够预拉取部分文件，预拉取部分文件应该是常用、公共、有良好缓存策略的文件。 当然这部分还是要根据业务和用户的需求来决定。如何能提前预提取呢。对此我想介绍两个可供参考的，能简单快捷的使用，并且对LCP和网站速度有明显提升。

第二十二页 如何提升lcp

这两项是技术基本都是很多年前就有，但经常被用户忽略的。 第一点是 让页面提前可与目标网站建立直接连接来获取资源。 由于这些请求每次都会发送到你的服务器，因此能够提高向用户显示的内容的速度。 一次DNS查询的平均时间大概是60-120ms左右，看似一个很短的时间，但是相对于网页的渲染来说，这是一个非常长的时间。 DNS预取技术是利用CPU和网络带宽来域名解析机制，可以针对多个域名采取并行处理的方式，每个域名开启一个新的线程。   信息告诉浏览器，需要做dsn预解析  使用link标签对后端api进行预解析， 尤其对于client side rendering的架构来讲，在已经构建完空白节点后在由client fire http request时建立连接其实已经滞后很多。

第二点是预拉取 在meta标签内Preload source，是声明式的 fetch，可以强制浏览器请求资源，同时不阻塞文档 onload 事件。 Prefetch 提示浏览器这个资源将来可能需要，但是把决定是否和什么时间加载这个资源的决定权交给浏览器。

Fetchpriority=“high” rel=“preload” href=“resource.jpg” Preload本来是一个专门针对音视频进行优化的一个标签，目前可以用对静态资源、关键公共js css 字体进行加载的一项技术 以上便是一些实践中对于提升lcp有帮助的一些经验。

除了以上的这些内容，还有什么能影响LCP呢，一般是服务器响应慢、js阻塞、资源加载慢、客户端渲染架构。 这里需要讲到服务器响应慢、资源加载慢， 目前观测云能全链路展示耗时占比，如果是服务器响应慢，则能快速看出来。 资源加载慢，观测云有两个字段对大家做性能调优有帮助。第一个是view_resource_count页面资源数量，第二个是resource_size。 一般情况下浏览器会限制同一个域名下可以下载资源的数量，以chrome为例，在建立连接阶段客户端最多与主机建立6个tcp连接，通过划分子域方式，将多个资源分布在不同子域上，减少请求队列的等待时间，这也算得上一种优化的方式。 根据从观测云得到的view_resource_count数量，可以做数量减少的尝试。比如从100到40。这也是非常值得尝试的性能提升。 最后一点便是reduce resource size，可以做大小降低上的尝试。比如从3M到1.5M。这也是非常值得尝试的性能提升。

第二十三页 交互

第二十四页

第二十五页

第二十六页

第二十七页

Cls是衡量视觉稳定性非常重要的指标，它可以量化在页面上布局累计偏移的最终效果，它可以衡量页面是否令人愉悦， 一般CLS应该在0.1以下，如果超过这个数值，就需要关注一下这个指标。 什么情况下会导致CLS比较差呢？ 一般是没有尺寸的图像/视频的dom节点（这里尤其需要考虑css embeded到js中的场景有可能会让cls比较低），不设置宽高的大div，以及字体文件突然加载的闪烁。而且可以通过chrome的devtools能够直接看到对cls影响比较大的dom节点。对于lazy-load的image/video节点，可以设置多套尺寸，能够降低cls。也可以使用类似于骨架屏的策略，对这些节点的样式进行预设。 还有一种情况，就是长列表下滑场景，需要保证盒模型有足够的空间切换，也就是不论盒模型内数据如何变化，都要始终预留出数据变动所需要的布局空间。总之，通过努力，我们认为CLS这个数值，是有机会不断接近0的。

第二十八页

第二十九页

第三十页

第三十一页

“观测云” 内置20余种标准的可视化图表：包括 时序图、概览图、表格图、矩形树图、漏斗图、饼图、柱状图、直方图、SLO、排行榜、仪表盘、散点图、气泡图、中国地图、世界地图、蜂窝图、文本、图片、视频、命令面板、IFrame、日志流图、对象列表图、告警统计图 等，可快速根据不同业务需求快速创建不同的仪表板，满足对数据个性化、全面的展示需求。 时序图一般用于显示数据在相等时间间隔下的趋势变化，同时可以用来分析多组指标数据之间的作用及影响。

第三十二页

比如我们以时序图为例。时序图一般用于显示数据在相等时间间隔下的趋势变化，同时可以用来分析多组指标数据之间的作用及影响。 这里能看到观测云控制台的核心指标FCP基本在2s的箱体

第三十三页

这里能看到观测云控制台的核心指标LCP基本在2s的箱体，存在部分波动。

第三十四页

矩形树图用于展示不同分组下指标数据的占比分布可视化。这里能看到观测云控制台的核心指标LCP基本在2s的箱体，存在部分波动。

第三十五页

矩形树图用于展示不同分组下指标数据的占比分布可视化。这里能看到观测云控制台的核心指标LCP基本在2s的箱体，存在部分波动。

第三十六页

这里可以通过这张图片能看出什么来呢？这是观测云控制台在阿里云的数据。 整体来看不论是页面切换，还是首次加载，cls整体绝大多数情况都在0.1以下，整体性能数据还是不错的，但是有明显超过0.1的情况存在。

第三十七页

让我看一下官网的数据，这里可以通过这张图片能看出什么来呢？ 整体来看不论是页面切换，还是首次加载，cls整体绝大多数情况都在0.1以下，但是有明显超过0.1的情况存在。

第三十八页