网站性能与体验 优化实践指南

一、为什么需要关注性能与体验 ........................................................................................ 2二、到底什么是性能与体验？ ............................................................................................ 4三、什么因素影响着产品性能与用户体验 ....................................................................... 6四、落地性能与体验优化的基本原则与流程 ................................................................... 9五、常见性能与体验监测方式 ......................................................................................... 14六、常见性能与体验指标 .................................................................................................. 19七、常见性能与体验分析思路 ......................................................................................... 25八、常见性能与体验优化措施 ......................................................................................... 28九、关于应用实时监控服务-云拨测 ............................................................................... 29

目录

回顾中国互联网发展史，我们可以看到很多退出市场的企业都有着共同特征：用户弃用或使用率降低，企业营收暴跌，最终企业消亡。抛开价格竞争与外部环境影响，我们发现用户弃用或者使用率降低背后很大原因是由于产品用户体验与性能问题。这些问题在业务发展过程中被忽略。毕竟相较于错过业务窗口期而言，体验与性能问题都是“无伤大雅”的细节问题。也许看到这里，很多人依然觉得这是危言耸听。结合对众多企业的调研，我们总结出常见的影响用户体验与性能的问题，不知大家是否似曾相识：

前台业务瓶颈逐渐暴露产品加载或互动反馈速度慢，新客户转化率降低，推广成本被浪费；用户浏览意愿减弱，老客户留存率下降，用户规模不断下跌；随着多业务、多端、出海等战略推进，运营成本不断增加，用户规模未能增长，损失进一步扩大。

后台支持问题不断恶化数据中心、CDN、运营商、云厂商等不同环节、不同服务商的服务质量无法评估与优化；无法准确评估日常发版质量，性能问题叠加放大；缺少性能评估与体验的量化数据支撑，造成权责划分不清晰，各团队互相推诿，相关问题解决困难。互联网发展到“下半场”，「体验至上」成为互联网产品的普遍共识。许多企业已经意识到上述问题，但在优化性能与体验前，企业不得不面对日益复杂的产品逻辑及交付环境，逐渐多元化的体验形态，日趋庞大业务数据量。随着智能手机、智能穿戴设备、智能家电等多屏互动以及物联网的广泛使用，云计算、云原生逐渐普及，使影响产品性能与体验的因素变得越来越复杂。几乎所有构建产品的技术、逻辑、模式都可能会对性能与体验产生影响，并在不断叠加放大后，对产品造成毁灭性影响。

一、为什么需要关注性能与体验

子主题

作为商业洞察、产品设计、代码研发、基础设施运维等诸多元素共同构成的组合体，性能与用户体验作为互联网产品的非功能特性，重点关注功能或服务完成的及时性。如果说用户体验强调的是用户的主观使用感受，产品性能更像是从技术角度将体验逐层拆解成对应技术指标并进行量化。

以网站举例，从用户发起网站访问请求到收到反馈内容，需要经过DNS解析查询、网络传输和接入转发，以及数据库、中间件等众多服务组件的按序处理加工，而这些组件的性能优劣直接影响交互及时性、准确性和可用性。与此同时，这又受到用户使用终端等因素影响，但这些影响无法根除，在开发测试环境下难以发现。正如产品经理之间的段子，我们并不知道用户会用什么奇怪姿势去用我们的产品做什么奇怪的事情。

为了保证「体验至上」，头部互联网企业会有着性能与体验优化团队或者战役，确保产品能为用户带来最佳体验。但对中小型企业而言，性能与体验优化背后是巨大成本，不管是花费人力、财力、时间去搭建相关监控优化平台，还是实践过程中探索尝试与经验沉淀。除此之外，伴随着产研团队组织架构、产品发展规划调整，之前所进行的相关性能与体验可能直接归零的种种意外。

虽然企业在探索性能与体验优化的实践过程中存在着各种困难，但随着技术演进以及行业不断发展。以阿里云为代表的头部云厂商，投入大量人力、财力，加快了产业化进程，帮助企业降低性能与体验优化的学习与落地成本。 一方面，厂商大量资源投入与实践输出，不断完善着性能与体验优化的技术范畴与方法论体系，降低企业落地性能与体验优化的门槛。另一方面，性能监控管理产品的云原生化，使得每家企业、每个开发者可以与行业顶级企业使用相同的云服务帮助自身业务进行性能与体验优化，人力财力成本不再是性能与体验优化的枷锁。

二、到底什么是性能与体验？

要说起什么影响着产品性能与体验这个话题，不同职能的同学都会有自己的独到见解。针对这一问题，我们与众多企业运维工程师以及独立站长展开访谈，发现大家的观点集中在以下方面：

由于互联网红利消退，产品功能与用户体验设计越发内卷。产品功能逻辑设计与用户使用时的理解存在差距，大量秒杀活动、推广活动、UGC内容让产品逻辑愈发复杂，哪怕提供了各种引导与说明文档，用户仍然需要时间理解并培养使用习惯。与此同时，为了让功能模块进一步丰富，大量富媒体、第三方组件、客户广告不断被添加进来，对外合作内容过多且不合理，加重系统负载，拖累产品性能。既要、又要、还要，最终的代价就是不得不牺牲一定的网站性能与用户体验。

「产品与用户体验之间的差距」带来的性能与体验问题

众所周知，全国各地充斥着各种各样一级、二级运营商，这大幅提升了全国网络环境复杂度，由于运营商基础架构更新慢、突发性人为问题多，造成会经常性的IDC故障，企业只能安抚用户并躺平等待修复，而这些问题的排查耗时都只能听天由命。与此同时，广阔的地域分布、零散的用户分布及个性化入网方式造成接入网络复杂，企业对于用户使用环境无法有效估量。哪怕借助广泛分布的数据中心以及多线BGP 接入，想要解决网络环境问题仍旧捉襟见肘，这进一步加剧了网络环境的优化难度，让真实用户的实际使用体验更加难以预测。

「错综复杂的网络环境」带来的性能与体验问题

作为世界上拥有最大网民规模的国家，我国这些海量用户规模背后是巨大的用户端硬件配置差异，可能有人使用着 i9-11900K+RTX3080 Ti 在 bilibili 上看 4K高清直播视频，也有人用着千禧年发布的 Pentium 4 与集成显卡在门户网站浏览文字新闻。这造成不同浏览器版本、自身渲染机制、本地主机性能差异的不同群体，存在譬如访问异常、慢速、本地资源消耗等用户体验差异。面对这一状况，如何去了解广大用户实际体验情况，平衡或评估用户端体验差异，在其中进行取舍成了每个网站运维与研发必须面对的难题。

「差异明显的PC端环境」差异带来的性能与体验问题

由于互联网竞争疯狂内卷，产品在功能窗口期与精细调优这道选择题上，不得不选择性忽视产品架构与稳定性。架构不严谨、业务发展超越架构支撑能力造成系统负载过载、导致系统崩溃、响应超时等问题，造成这一问题的因素很多：首先，业务迭代速度非常快，侵入式监控手段无法在短时间落地，但业务系统出现故障时需要快速感知；其次，开发资源紧张或不配合，基础设施相关监控又不能直接反应业务问题，应用监控实施成本太高。最后，自身应用调用第三方API 接口，第三方API 接口的可用性无法保障，出故障了无法及时响应和处理。拆解来看，我们会觉得这些都是单点问题，但业务上量后出现连锁反应，就会将这些问题叠加放大，直接影响用户体验。

「追求迭代速度的后遗症」带来的系统可用性保障问题

虽然产品功能在上线时会经过各种测试，运营团队也持续关注用户使用情况。但对运维团队而言，只有客户投诉后才知道系统发生了问题，应对起来十分被动，甚至异常复现、定位问题可能就要花费一天时间，严重影响NPS；常见监控手段也大多从自身视角出发，无法直观反映用户的问题。

「缺乏用户视角的监控手段」导致应对客诉比较被动

三、什么因素影响着产品性能与用户体验

开始阐述观点前，我们需要思考一个问题：如果网站性能与体验问题能在用户感知之前事先发现与修复，在研发交付过程中就进行回避或修正，是否能有效提升产品NPS甚至营收？以及我们是否能接受在那些会深远影响用户规模以及企业营收的问题出现之后再修复？而这就是性能与体验优化的出发点。所以，这里有几个基础原则需要在落地开始前明确：n 数据驱动原则：优化策略需要建立在准确的性能与体验数据上，确保最终用户体验以及优化收益可被量化。n 尽早尽快原则：尽早发现未暴露的问题，减少对用户体验的持续影晌。发现问题后，尽快解决主要问题，降低影响程度。n 最佳收益原则：产品不同生命阶段需要平衡性能体验与产研效能，优先选择当前时期最简单、性价比最高的优化方案。n 单元化原则：由于不同组件都会对性能与体验造成影响，因此需要从前端到后端逐层剥离，相关组件、模块进行单元测试，确定关键优化目标。n 持续优化原则：性能与体验优化并非一劳永逸的工作，需要产品在迭代的过程中不断发现问题优化问题，并在这一过程中防止性能与体验退化。

在了解基础原则后，就可以开始组建性能与体验优化团队，该团队可以是实体架构团队，也可以是虚拟团队，但这其中都需要拉通不同研发职能的同学，这其中包括：n 产品运营：用户以及运营角度设计优化用户流程路线，为工程师提供用户场景解读，帮助工程师快速理解业务。n 架构师：通过优化系统架构解决性能瓶颈，提升服务执行效率。n 前端工程师：通过迭代前端逻辑和代码，提升前端程序执行效率。对前端性能数据进行收集和分析。针对与竞品进行评测，提出针对性竞争优化策略。n 后端工程师：针对影响性能的组件、模块、接口进行持续迭代。n 运维工程师：分析系统运行状况以及资源使用效率情况。对IDC、CDN以及云服务等基础资源进行性能测试，确保产品的高性能与高可用。

在构建出性能与体验优化团队后，可以着手实际落地，在实践过程中我们需要遵循「监控-分析-优化」的迭代循环并在每个部分中完成多个对应动作，从而推动优化落地。

不管是自建，还是第三方工具都不可或缺。分析优化的前提是具备足够数据支撑我们进行分析与决策。通过监控工具去获取竞争对手的数据，会获得更具参考价值以及针对性优化方案。最后，在优化后持续监测去检查优化方案效果。小贴示：在建立监控后，优化团队不必不急于开展优化，掌握数据定位短板是首要任务，体系化性能与体验监控机制将所有环境下的性能事件采集汇总，在数据基础上设定优化目标。确保在整个优化体系初期就建立持续、透明的性能与体验监控机制。建立监测体系时可以根据自身业务需求，选择最恰当的性能与体验监测模式。常见的性能监测模式，主要分为主动监测与被动监测。l 主动监测：通过注册会员用户、IDC进行主动访问或模拟访问服务，以获得不同维度的性能数据。云拨测就属于主动监测，这类监测主要用来判断基本应用性能状态。这类监测好处是不需对产品进行额外的嵌码或对可用性造成干扰。l 被动监测：真实用户在使用产品过程中触发监测采集规则，产生对应应用性能数据。移动SDK监测、JS类监测都属于被动监测，但这类监测需要对产品进行嵌码并可能拖累产品性能以及稳定性。另外，日志分析也属于被动监测，但受日志规模和分析能力影响，时效性以及准确性难以保证。

Step 1：通过监测全面评估自身产品及竞争对手在不同使用环境下的性能与用户体验的数据表现。

n 定位异常及瓶颈：针对性能与体验数据，需要分析出影响性能的瓶颈位置，哪些方面需深入监测，收集并处理相关数据，以便优化方案设计。n 优化方案设计：基于分析数据进行设计相关优化方案，并对所需的研发资源以及资源投入进行统筹评估。小贴士：定位异常及瓶颈与设计优化方案的投入都是围绕核心产品或者核心功能展开，力争在同业产品中性能与体验最优。与此同时，在这一过程中，注重沉淀总结性能分析和优化方法，有助于提高优化团队的工作效率，可以让不同产品线的研发团队都能从中受益。

Step 2 通过分析来评估网页/应用/网络等部分的性能，为优化及资源投入提供依据，并针对故障以及瓶颈进行预警、报警。

n 优化方案实施：除了基于优化方案的代码以及逻辑优化外，需要针对可能的关联问题进行相关预案设计。n 效果跟踪反馈：在优化方案完成后，需要利用A/B测试、拨测等不同方式，监测真实用户反馈并进行持续，以便追踪优化效果并挖掘关联的瓶颈与异常。小贴士：产品优化永远不是一个团队的事情，因此与对应的产研团队充分沟通，充分配合是方案落地的大前提。

Step 3 基于优化方案对网络、系统、前端、应用等不同环节、不同层进行优化。

四、落地性能与体验优化的基本原则与流程

随着互联网行业全面红海化，行业竞争愈发激烈，用户体验成为检验企业产品与服务质量的唯一标准。虽然移动端已成为互联网产品的主战场，但PC端网站产品依旧是不可或缺的重要组成部分。通过合作方式在真实用户PC端安装监测客户端收集性能数据是目前PC端网站监测主流方式，通过服务端下发监测任务到客户端，按一定频率主动监测网站性能和体验，并发送到服务器进行数据展现和分析。阿里云应用实时监控服务（ARMS）所提供的云拨测功能即可实现。相较于JS 被动监测，云拨测可以监测国内外、各终端、各浏览器下各产品形态，针对前端、网络、系统、应用层的性能与体验问题进行定向优化。

拨测监测常见指标包括：白屏时间、首屏时间、整页时间、DNS 时间、TCP连接建立时间、首包时间、内容下载时间、基础页面下载时间、网络层时间、可用性、首屏对象数、网页对象数、TCP建立连接次数、页面大小、首屏下载字节数、基础页大小等。

非侵入式监测，让监测更简单，无需人力和时间成本。拨测监测帮助企业建立PC真实用户性能与体验监测体系，通过分布海内外的真实监测客户端，采集浏览器访问网站过程中各项性能与体验指标，从渲染层的白屏时间、首屏时间到网络层DNS 解析时间、建立连接时间、首包时间、下载时间等指标，从不同角度衡量网站性能与体验，为产品设计研发、运维决策提供数据支撑。

与此同时，拨测监测帮助企业快速定位网站性能瓶颈，在影响终端用户前提前发现问题，多维度指导性能优化，不管是物理维度的省份、地域、城市、运营商，还是虚拟维度的某些页面元素级或事物级请求问题。深入分析页面加载每个细节与环节的同时，对比行业竞争对手，驱动产品迭代。

拨测监测

随着应用的不断复杂化，企业对于性能指标采集的自定义需求不断增加，JS 监测很大程度上满足了企业的个性化需求，但由于JS 嵌入到相应页面，可能会对业务代码造成入侵或者耦合。因此一般企业在构建性能监测体系时会选择JS 监测+拨测监控的组合形式。

JS 监测常见指标包括：白屏时间、首屏时间、整页时间、用户可操作时间、首包时间、DNS 时间、连接建立时间、基础页面下载时间、自定义的时间等。

建立基于JS 的网站真实用户性能监测体系，通过轻量安装方式，以最小工程代价，快速实现最大范围和类型的覆盖。支持从不同浏览器收集真实用户使用网站时的性能数据，反映真实用户体验。结合应用系统整个拓扑结构各层次节点的监测数据，有效分析不同地域、浏览器、系统上用户打开页面的体验，在JS 错误、慢页面、资源加载失败等问题跟踪时实现代码级定位。

JS 监测

由于不同规模的运营商竞争激烈，骨干网建设程度不同，不同省份运营商的访问质量不均衡，这让网站无法回避跨运营商解析问题，也让IDC、CDN选址选型更加困难，这要求企业需要实时了解全网解析情况，以便及时进行调整。通过网络监测清楚感知感知服务商相关服务的网络延时，为服务选型、日常运维提供数据支持。

网络监测常见指标包括： Ping 延时、Ping 丢包率、 Traceroute 延时、Traceroute 跳数 、可用性等。

网络监测提供多维度网络性能监控数据，全面了解网络拓扑结构，分析运营商、IDC/CDN 厂商、省份、用户的分布情况，有效评估IDC、CDN、ISP、DNS 等网络分布、优化调度解析合理度。从延时、丢包率、可用性等指标维度评估域名、IP、API 性能情况，或为IDC、CDN服务选型提供数据对比支持，了解各服务商产品服务优劣。提供长期监控数据，当发生如网络跨运营商、跨地域访问、访问过慢等调度、访问异常情况等网络故障时，能及时定位故障原因进行排障。

网络监测

随着短视频成为目前最火热内容形式，不管是视频广告正成为价值越来越高的广告形式，还是在线教育、娱乐直播，确保流媒体播放流畅度，为用户提供最佳体验，成为企业提高营收关键。因此，监测流媒体真实服务质量，对于企业以及服务商而言至关重要。流媒体监测常见指标包括：总等待时间、视频准备时间、缓冲前准备时间、再缓冲次数、再缓冲时间、DNS 解析时间、TCP建联时间、等待响应时间、首次缓冲时间、比特率、码率、可用性等。流媒体监控帮助企业建立全面的流媒体性能监测体系，评估直播、点播等各种流媒体播放模式、不同多种网络协议、不同编码封装格式下的流媒体播放性能情况，真实还原流媒体资源在用户端的播放场景，快速定位性能瓶颈、评估CDN选型情况，优化访问性能，提供给用户更佳播放体验。

流媒体监测

随着互联网的飞速发展，技术与服务创新让产品架构日渐庞大，隐藏的性能问题很难反映在用户层、系统层性能数据上。因此，系统监控成为必选项，通过在服务端安装对应的 Agent，对应用代码、数据库、关联外部服务等进行性能监控，及时发现异常问题并定位性能瓶颈，提供性能问题诊断、追踪及优化依据。

基础设施监测常见指标包括：CPU利用率、内存使用率、磁盘使用率、带宽使用率、系统负载、I/O 利用率、读/写速度、读/写操作、数据包(发送、接收)、错误(发送、接收)、带 宽(发送、接收)、CPU占用率、内存占用、线程等。

系统监测

五、常见性能与体验监测方式

在建立完整监控体系之后，我们需要各种指标抽象展现网站访问过程中系统、网络、前端、客户端等不同环节、组件的体验情况，以便挖掘可能存在的问题。采集到对应数据后 ，在 进行自身环比、同比分析的同时，还可以通过拨测能力去获取同行竞争对手的网站性能与体验情况进行对比，以便帮助我们找到外部竞争的产品短板。接下来，我们将介绍一些常见指标，只有了解这些指标的定义方式及体验具象关联，才能更好进行诊断、优化网站性能与体验问题。

即某个考察时间中，系统正常运行的概率或时间占有率期望值。考察时间为指定瞬间，则称为瞬时可用性；考察时间为指定时段，则称为时段可用性；考察时间为连续使用期间的任一时刻，则称为固有可用性。它是产品、系统可靠性、可维护性和维护支持性的综合特性。作为服务质量保证（SLA）的重要指标以及运维团队核心指标之一。可用性在不同场景下广泛应用，无论是网站、服务、功能模块，还是底层系统、组件、网络都可以通过可用性直接评估监测对象为用户提供服务的质量状况。

可用性（Availability）

即系统能够同时承载的正常使用系统功能的用户总量。但由于用户不同使用状态所发出的请求数量会不断发生变化。与吞吐量相比，并发用户数是一个更笼统直观但又模糊的指标。以网站举例，同时在线用户数与同时发出请求用户数共同构成了并发用户数。因此，我们一般在直观评估网站性能时并发用户数大抵指的是同时在线用户数，而进行准确表述时会使用同时发出请求用户数，这二者的区别在具体应用过程中需要注意。

并发用户数（Concurrent User）

即主机中运行程序所用CPU资源的占比，越大代表系统越繁忙。

CPU使用率（CPU Usage）

即从浏览器发出访问请求开始，到浏览器获得最终访问主机IP地址的耗时。DNS解析原理与过程非常简单，却是影响网站体验的重要因素。比如一个新域名网站上线，可能由于本地域名服务器缓存缺失或者较少，或由于本地域名服务器运营商较小造成解析效率低下，造成DNS 时间拖长。

DNS 时间（DNS Time）

即页面元素、文件大小或网络传输时间。下载速度偏于网络性能，主要用来衡量IDC、 CDN性能。下载大容量文件具备一定参考意义，但对于小文件或者网页，只具备基础参考意义，因为小文件以及由多个小元素构成的网页，下载速度还没达到最大就结束了。

下载速度（Download Time）

即从用户键入URL，浏览器发送完HTTP请求开始，浏览器接收到服务端发送的数据包到浏览器将内容第一个像素渲染到屏幕上的耗时。白屏时间作为与首屏时间同等重要的用户体验指标，在慢网络环境下最为明显。通常两个方面影响白屏时间，一方面是用户本地与应用服务器端间的网络延时决定了白屏时间；另一方面是服务端接收请求到开始发送内容的后端相应时间。

白屏时间 （First Paint）

即浏览器完成HTTP请求发送，到收到Web服务器返回的第一个数据包的耗时。这其中包括了发送HTTP请求时最后一个数据包的网络传输时间、服务器响应此请求时间、服务器返回第一个数据包的网络传输时间。相较于白屏时间，首包时间减少了浏览器本地接收数据和渲染的耗时。首包时间的意义在于重点关注网络性能(DNS 解析时间、TCP建立连接时间等)以及服务器时间(处理请求的后端响应时间等)。如果出现问题，我们可以快速定位后端服 务器以及DNS 解析问题。

首包时间（First package Time）

即单位时间内，系统处于可运行状态和不可中断状态的平均进程数。其中包括了正在使用CPU的进程，还包括等待CPU和等待I/O 的进程。

平均负载（Load Average）

即系统、用户和进程所消耗的内存大小，内存资源直接影响应用的使用性能。

内存使用量（Memory Usage）

即数据传输所用的耗时，从数据进入网络到离开网络，延迟越低速度越快。延迟与服务器所在的地域、运营商都有直接关系。

网络延迟（Network Latency）

即数据在网络传输过程中数据包丢失情况，每个数据包由数据信息和提供数据路由的帧组成，而数据包在传输过程中会由于物理线路故障、设备故障、路由信息错误等各种原因原导致部分丢失。

网络丢包（Network packet Loss）

即从页面加载出第一个元素开始，到整个网页被完整渲染加载完成的总耗时。整页包括除了首屏内容屏外，在拖动滚动条过程中所加载出来整个完整页面。绝大多数网站在首屏加载完成后，很多内容还在未完成渲染加载。在用户关闭或跳转前，这些内容持续渲染加载，直至完成。

整页时间（Pageload Time）

即用户发出请求或者指令到系统响应的耗时，响应时间与用户使用产品的主观感受是非常一致的。响应时间过长，用户会感到不安和沮丧，而响应时间过短会造成用户加快操作节奏，从而导致操作错误。为了能够更具针对性的根据响应时间进行优化，在评估网站性能过程中，我们可以将响应时间划分为两部分。前端浏览器内容渲染响应时间：客户端的浏览器在接收到网站数据时呈现页面所需时间；后端系统响应时间：服务端接收到用户请求到浏览器接收到服务器发来的数据所需时间。

响应时间 （Response Time）

即系统在单位时间内处理请求数量，传输的数据总量，反映服务器承压能力。由于吞吐量与请求数量、CPU资源消耗、接口调用、I/O 有着直接关系。如果配置得当，随着用户量扩增，平均响应时间应保持稳定不变。而我们时常遇到的性能问题，大多与吞吐量超载有直接关系。但随着云原生技术的大规模落地，自动化扩缩容等特性让高可用成为了互联网企业或产品的标配，也让运维成本降到最低。

吞吐量 （Throughput）

即访问并可能更新数据库中各种数据项的程序执行单元(Unit)。事务通常由高级数据库操纵语言或编程语言（如SQL，C++或Java）书写的用户程序的执行所引起，由事务开始和事务结束之间执行的全体操作组成。事务主要用来衡量代码的执行耗时。作为组成产品功能的最小单元以及性能最小载体，事务决定了产品后端性能。因此，我们需要通过事务监测将后端性透明化、量化，从中找出影响用户体验的事务，进而改进产品体验。

事件（Transaction）

即用户通过终端浏览器打开网页开始到浏览器第一屏染完成的耗时。首屏时间作为最直接的用户感知体验指标已经成为性能与体验领域公认的核心指标。2012 年11 月29 日，工信部正式发布了《宽带速率的测试方法用户上网体验》规范标准，也把“首屏时间”作为用户上网体验的重要指标。一般来说，我们以800x600 像素尺寸为标准，从开始加载到浏览器页面显示高度达到600 像素且此区域有内容显示的时间。但随着终端尺寸的不断增大与变化，在实际评估首屏时间时，需要完全基于用户真实显示终端第一屏测览器自然填充并自适应所有分辨率。

首屏时间（Time to Above the Fold）

浏览器与服务器建立TCP连接的耗时。 这个耗时平时不容易被人察觉，因为开发场景下研发团队往往不需要重新建立连接。但在新用户、落地页等场景却会对页面性能造成较大影响。

建立连接时间（TCP Connection Time）

即Web服务器返回的纯文本HTML文件的耗时，由于基础页是浏览器加载的第一个请求，直接影响了首屏时间，并且影响网站所有网页渲染过程。

基础页时间

六、常见性能与体验指标

我们借助监测工具对相关性能与体验指标进行收集与整合后，就要开始进行相关分析，我们以真实用户的性能与体验数据为核心，那么分析流程应与真实用户访问流程一致：终端—网络—应用—系统。在分析的过程中，我们需要确保拥有足够的样本量，以及自身对于不同指标对用户体验影响的权重评估。接下来，分享几个分析维度。一般情况下，我们对用户体验的感知是滞后的。通常是收到用户反馈或投诉后，才去检查系统是否运行正常、问题是否能复现，再定位具体问题位置，这个过程往往是很被动的。 因此我们可以从以下四个维度展开分析：

互联网产品形态是跟随终端演进而逐步产生变化的。当终端设备、操作系统或浏览器不断演进时，产品也需要同步兼容，否则将造成用户使用过程中出现异常，因此在监测、分析应用性能时需要充分考虑产品形态多样性。与此同时，无论是PC端，还是移动端，监测到终端环境下的用户体验的全过程才是最具意义和效果的。PC端环境相较于移动端，由于硬件升级、网络提速、以及PC端自身容错能力，我们主要从三个具体维度考量：操作系统、浏览器、分辨率。

维度一：终端分析

如果说前端决定了产品的呈现，那么后端基本决定了呈现的逻辑及内容。随着业务不断发展，服务端为了支撑规模化、复杂化的业务需求大多进行容器化、微服务化等行为，由于涵盖架构及模块、开发语言、第三方应用，服务端模块涵盖的范围宽泛又复杂，且模块间相互关联也不透明。且后端不像前端、网络、系统那样透明、容易监测。因此，监控优化难度大，我们主要从三个具体维度考量：系统架构及模块、开发语言与逻辑、第三方应用平台API。

维度二：服务端分析

网络决定了数据的传输效率。国内复杂的网络环境，让网络分析成为毋庸置疑的影响网站性能的重要原因之一。相对于终端和服务端，网络性能可视为一种可选择资源。当用户端、服务端保持不变，那么分析重点就落在应用端所处的网络环境下。

我们主要从三个具体维度考量：资源类型、地理位置及分布、运营商、服务供应商。

维度三：网络分析

在做性能与体验优化过程中，需要掌握基础设施资源的运行状态，例如系统负载、内存状态、进程状态、CPU负载等检测和判断系统性能的基本依据。但随着云计算、云原生的不断落地，基础设施资源的管理也愈发简单。我们只需关注以下维度：CPU、内存、网络、I/O。

维度四：系统分析

七、常见性能与体验分析思路

结合上述分析思路，我们基本可以从多维度评估网站或产品的系统瓶颈。接下来，我们将罗列常见优化点，帮助大家快速定位可能的瓶颈位置，便于优化入手。

前端优化

后端优化

网络优化

系统优化

八、常见性能与体验优化措施

对PC端网站而言，也许最好的时代已经结束。但作为现代互联网的重要组成部分，PC端网站依旧占据着不可获取的地位。与此同时，随着应用性能管理概念的不断普及，越来越多的企业、产研团队、运维团队、开发者注意到了其重要性。云拨测作为面向业务的非侵入式云原生监测产品，成为最佳的选择。通过阿里云遍布全球的服务网络，模拟真实用户行为，全天候持续监测网站及其网络、服务、API 端口可用性与性能。实现页面元素级、网络请求级、网络链路级细颗粒度问题定位。丰富的监测关联项与分析模型，帮助企业及时发现与定位性能瓶颈与体验暗点，压降运营风险，提升服务体验与效能。

全球超过20 万LM，500 余个IDC终端监测节点，海内外400+运营商以及数十万量级注册会员，确保监测规模满足日益庞大的业务规模。

全球监测节点覆盖

零侵入式监测，只需输入URL 并进行简单配置即可，无需研发支持。数分钟即可获得完整的网站性能数据分析报告。资源包&按量付费多种购买模式，满足运维测试需求。

无需嵌码，开箱即用

监测周期精细至分钟级别，7 大类20 余项监测关联参数设置、支持多种主流协议，为站点和业务端口等提供7×24 小时细颗粒度故障实时监测、告警及性能分析服务。以最终客户视角，通过地域、运营商等多维度组合分析，下钻分析单样本详情，利用丰富的指标体系与图表类型，直观定位问题、受影响范围及其根因，压降分析时间，提升运维效率。真正做到精细化监测。

面向业务，预置多种分析模型

针对首屏用时、整体性能、可用性实现实时告警，丰富的告警策略设置，与阿里云告警中心深度集成，有效缩短MTTR。支持发现页面元素级错误，问题归因精准定位至单次网络请求过程，提升问题定位效率。

智能告警，精准定位

以某电商企业的营销大促举例，该网站月活用户数超百万，用户群体主要分布在全国三四五线城市，每年网站运营维护支出费用超过200 万元。但由于大促阶段商品信息更新较频繁，更新后经常收到各地用户投诉“商品图片加载不出来”、“页面打开缓慢”，造成用户转化低，也导致运维团队被投诉。面对这一困境，我们通过云拨测产品完成解决这一问题并进一步优化网站性能，以便支撑业务大促。

（一）压力测试在企业的营销活动或新系统上线前，使用云拨测选取全国不同城市运营商的监测点，设定浏览和网络任务，即时获取第一线的真实用户访问体验数据，精准定位出现问题的页面元素，帮助技术团队及时修复问题。模拟峰值用户高并发访问，通过增加峰值压力，观察主要性能指标变化情况，挖掘性能瓶颈。（二）用户体验优化通过首屏监测以及即时监测功能可以立刻进行问题验证和故障复现，对网站性能进行评估与优化。并通过事务流分析，了解用户真实体验流程，优化浏览路径，挖掘转化瓶颈环节，提升转化率。（三）竞品分析迭代借助零侵入特性，收集分析同行业竞品营销活动性能情况，了解竞品营销态势变化以及应对方案，并针对进行针对性IT 投入以及调优迭代，弥补营销短板，稳固领先地位。经过以上相关措施，网站性能大幅提高，用户体验相关量化指标提升30%以上，有效驱动业务增长。除上述场景外，云拨测还可广泛应用于网络接口、服务可用性监测、CDN服务监控与选型、DNS 解析状态、劫持分析等众多场景。为了满足更多企业与独立站长的拨测需求，云拨测上线发布不同规格的月资源包，并开展限时优惠活动。新购用户将获得九折优惠。

九、关于应用实时监控服务-云拨测

网站性能与体验 优化实践指南