为什么性能就是用户体验 (Performance Is User Experience)

为什么性能就是用户体验

性能与用户体验密不可分——它是最明显的维度之一。用户随着时间的推移体验网站：内容出现的速度有多快，他们采取行动的速度有多快，以及交互是否感觉流畅或不连续。 Web 性能包括加载时间和响应等客观测量，以及用户对速度的感知。 MDN

慢速界面在每个阶段都会产生摩擦：

• 空白或缺失的屏幕会让您怀疑该网站是否正常运行。
• 按钮无响应表明是否已采取该操作。
• 布局改变会意外改变内容并导致错误。
• 卡住的滚动或动画使界面感觉不可靠。
• 延误会打断精神流动并增加放弃的可能性。

相比之下，快速稳定的界面让人感觉毫不费力。用户可以专注于他们的目标，而不是管理他们和目标之间的技术。 Web 平台指南将更好的性能与更强的参与度、保留率、满意度和更低的放弃率联系起来。 web.dev

性能体现品质

用户通常将响应能力解释为可靠性和信任的信号。立即做出反应的产品给人一种精心设计的感觉；被冻结、卡住或搁置的产品感觉很脆弱——即使其规格在技术上是正确的。

这就是为什么性能不仅仅与工程或优化有关；还与工程或优化有关。应被视为产品要求。设计选择、内容策略、JavaScript 架构、托管和视觉效果共同塑造用户感知的体验。## 优化什么

以用户为中心的性能策略应该问以下问题：

1. 什么时候出现有意义的内容？ 优化等待体验，而不仅仅是最终加载时间。
2. 用户什么时候可以交互？ 看起来准备就绪但忽略输入的页面仍然感觉很糟糕。
3. 界面稳定性如何？ 防止加载内容、广告、图像或字体时出现意外移动。
4. 交互有多流畅？ 滚动、打字、打开菜单和导航应该感觉连续，而不是不稳定。

Core Web Vitals 有助于衡量这种体验的关键部分；但指标的价值在于它们代表了真实的用户摩擦。我们的目标不是让棋盘变绿，而是让棋盘变绿。就是让产品在真实条件下感觉快速、清晰、可靠。

本节中重复出现的概念```text

📦 Kullanıcının algıladığı performans Deneyimin laboratuvar skorundan değil; kullanıcının hissettiği hız ve güvenilirlik.

📦 Algılanan bekleme süresi Gecikmenin duygusal süresi; çoğu zaman memnuniyeti saat süresinden daha çok etkiler.

📦 Core Web Vitals LCP, INP ve CLS—gerçek kullanıcıların 75. yüzdeliğinde ölçülen yükleme, yanıt ve görsel kararlılık.

📦 Saha verisi ile laboratuvar verisi Gerçek kullanıcı ölçümü ile kontrollü, tekrarlanabilir teşhis testleri.

📦 RAIL Response, Animation, Idle, Load—kullanıcı eylemlerine göre performans hedefleri.

📦 Performans bütçesi “Yeterince hızlı”yı tasarım kısıtı haline getiren ağırlık, gecikme ve kararlılık limitleri.

## 缓慢的代价

速度慢的网站在用户看到主要内容之前就会产生成本。第一次延迟成为第一印象：访问者可能会将其视为产品陈旧、不可靠或困难的标志。因此，表现不仅仅关乎是否留下来，还关乎是否留下。它还影响了人们对网站背后机构的判断。

用户期望内容能够快速显示并且交互能够响应。随着延迟的增加，耐心会减少；他们可能会离开页面，重复操作，或者离开时对产品信心不足。 MDN 将绩效不佳视为放弃、低保留率、低转化率和满意度下降的原因。 [MDN](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Performance/why_web_performance)

### 第一印象是在安装过程中留下的

即使页面在技术上尚未准备好，加载体验也是界面的一部分：

- 空白屏幕没有显示任何进展的迹象。
- 部分呈现的页面可能会让产品感觉不完整。
- 可见的加载指示器有所帮助，但并不能弥补不必要的长时间等待。
- 布局变化使界面感觉不稳定并可能导致误点击。
- 快速的初始响应可确保系统正常运行。

这对于尚未积累信任的首次访问者尤其重要。谷歌的性能指南指出，速度慢的网站在参与度和保留率方面效率较低，并且额外的加载时间会导致可衡量的用户流失。 [web.dev](https://web.dev/learn/performance/why-speed-matters)

### 满意度不断累积

可以容忍单次延迟；但整个会议期间反复出现的延误不断累积。用户产品先等待页面，然后是菜单，然后搜索结果并不是一条通往目标的顺利路径；生活是一系列的障碍。表现也会影响情绪状态。 web.dev 上的研究总结将页面速度滞后与压力升高联系起来；也就是说，缓慢的体验可能比其持续时间本身所暗示的更沉重。随着时间的推移，这种挫败感会降低信任度、参与度、回头率以及推荐产品的可能性。 [web.dev](https://web.dev/learn/performance/why-speed-matters)

### 业务影响

“缓慢的成本”以相互关联的形式出现：

- 更多废弃的访问和未完成的任务。
- 转化率和收入较低。
- 减少重复使用和客户保留。
- 当不清楚行动是否成功时，对支持的需求增加。
- 对品牌的信任度减弱。
- 连接速度慢或受到限制的用户的数据、电池和设备成本更高。

实践教训很简单：速度是产品第一印象以及后续每次交互的一部分。快速的网站不仅可以节省时间，还可以传达对用户注意力的尊重，并使体验感觉更值得信赖。

## 等待心理

等待并不是一种中立的秒数测量方式。人们通过情感和期望来判断延迟：界面立即响应时，两秒可能感觉可以接受；如果屏幕空白、结果不确定或不知道该操作是否有效，则相同的时间会感觉更长。

服务体验研究表明，**感知的等待时间**通常比客观等待对满意度的影响更大。如果等待是空的、无法解释的、不确定的或超出用户的控制，那么感觉会更糟；互动、知识和明显的进步可以使同一时期更易于管理。 [伊拉斯谟研究](https://repub.eur.nl/pub/12176/)

### 为什么数字等待是痛苦的

多种心理影响使得延迟对网络和应用程序尤其有害：- **不忙的时间感觉更长。** 空白屏幕没有什么可关注的；注意力转移到时间的流逝上。
- **不确定的时间感觉更长。** 如果没有反馈，则不清楚系统是否正在加载、冻结或失败。
- **焦虑的时间感觉更长。** 如果涉及金钱、个人数据或重要任务，结果会产生焦虑。
- **不公平或不受控制的时间感觉更长。** 不明白为什么要等待或可以做什么的用户会感到沮丧。
- **被打扰的时间感觉更长。** 重复的停顿会扰乱注意力，让任务感觉比实际更困难。

第一次等待通常特别重要，因为它设定了对其余体验的期望。如果产品在用户获得价值之前速度很慢，那么延迟感觉就像是一个障碍，而不是一个必要的步骤。

### 设计更好的等待

最好的解决方案是良好的性能；但不可避免的等待必须经过精心设计：

- 当用户点击或发送时显示立即响应。
- 用有意义的结构（如骨架布局）替换空白屏幕。
- 如果时间可以测量，则显示进度。
- 如果过程很复杂，请解释发生了什么。
- 给予控制权，例如取消、重试或在后台继续。
- 明确确认成功，以免重复操作。
- 仅当故障可以安全处理时才使用乐观更新。

进度指示器并不能客观地加快进程；它减少了不确定性并发出系统正在运行的信号。目标是将被动等待转变为有意识的进展：用户必须知道某件事正在发生，为什么会发生，以及如果可能的话，它可能会持续多长时间。

## 评估用户体验性能用户体验性能应该从两个角度来衡量：**系统如何执行**和**用户如何成功地完成他们的目标**。一个页面可能会获得出色的技术分数，但如果导航混乱、错误频繁或重要任务花费太长时间，它仍然会让用户感到沮丧。

### 核心网络生命力

Google 的 Core Web Vitals 专注于三个面向用户的维度：加载、响应能力和视觉稳定性。推荐的“良好”阈值是在实际用户体验的第 75 个百分位数处测量的。 [Google 搜索中心](https://developers.google.com/search/docs/appearance/core-web-vitals)

|公制|采取什么措施|好目标|
|---|---|---|
|最大内容涂料 (LCP) |当主要内容可见时 | ≤ 2.5 秒 |
|与下一个油漆的互动（INP）|界面对用户输入的响应速度有多快？ ≤ 200 毫秒 |
|累积布局偏移 (CLS) |页面意外移动了多少 | ≤ 0.1 |

这些指标回答了三个基本问题：*他们能看到重要内容吗？他们可以无需等待就进行互动吗？接口是否保持在原位？*

### 产品和可用性指标

技术指标应与真实用户结果相匹配：

- **任务成功率：**正确完成任务的用户百分比。
- **任务持续时间：**完成目标所需的时间。
- **错误率：**错误、重复操作或失败的频率。
- **放弃率：**流程完成之前放弃的频率。
- **满意度：** CSAT、任务后问题或面试。
- **保留和转化：**更好的表现是否会带来转化、购买、订阅或其他有价值的行动。这些指标显示性能改进是否只是产生更好的诊断分数或有意义的用户体验改进。 [UX Army](https://uxarmy.com/blog/how-to-measure-ux-performance/)

### 现场数据和实验室数据

**现场数据**来自真实用户的真实设备、浏览器、网络和位置。这是了解用户实际获得的体验的最佳方式； Core Web Vitals 报告也使用此类真实世界数据。 [Google Search Console 帮助](https://support.google.com/webmasters/answer/9205520?hl=en)

**实验室数据**来自受控仪器和可重复的测试条件。对于提取回归和比较变化很有用；但它不能代表所有现实世界的设备或网络状况。

强大的测量过程使用两个：实验室来查找原因，现场来验证影响，以及用户结果指标来验证体验是否确实得到了改善。

### 衡量旅程，而不仅仅是页面

页面级分数很有用；但用户体验**流程**：搜索、登录、支付、上传文件或填写表格。从用户的角度衡量这些旅程的绩效：

1. 用户可以开始之前的时间。
2. 每次重要交互后延迟。
3. 错误和重复行为。
4. 完成与放弃。
5.任务后满意度。

因此，最有意义的性能目标不仅仅是“减少 LCP”或“提高 INP”。它是：**帮助用户快速、安全且无需付出不必要的努力即可完成重要任务。**

## 适合所有人的性能快速体验不应该由最新的手机、功能强大的笔记本电脑或高速 Wi-Fi 来定义。真实用户可能使用较旧的硬件、有限的数据计划、繁忙的移动网络、小屏幕或受到大量 JavaScript 和动画挑战的设备。包容性性能意味着在这些条件下使**核心体验**可用且响应迅速。

### 设计基线

不要将速度慢的用户视为异常值，而是从最低的合理能力开始：

- 无需大量下载即可提供重要内容和操作。
- 使用适应屏幕尺寸、方向和输入法的响应式布局。
- 在小屏幕上保持导航、表单和主要交互简单。
- 使用语义 HTML 和渐进增强功能使基本功能正常运行，而无需安装高级功能。
- 不要假设每个设备都支持快速处理器、大内存、触摸或持久连接。

我们的目标不是创建更糟糕的移动版本。传递相同的核心价值；使演示和可选功能适应用户上下文。

### 智能调整资源

浏览器不应将不必要的数据或计算接收到设备中。响应式图片可以通过`srcset`和`sizes`选择合适的大小；下屏图像可以延迟加载，以便为可见内容保留带宽。 [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Responsive_images)

自适应加载可以为每个人提供快速的核心体验，并在设备和网络支持时添加更高质量的媒体、复杂的动画或非必要的脚本。此较小的图像和视频在较慢的连接上；这可能意味着在较低硬件上更少的动画和更便宜的计算。 [web.dev](https://web.dev/articles/adaptive-loading-cds-2019)### 支持有缺陷的连接

网络不稳定。用户可能会在 Wi-Fi 和移动数据之间切换、在电梯中失去连接，或者在带宽看似充足的情况下遇到高延迟。良好的用户体验是因为：

- 应显示清晰的加载、离线和重试状态。
- 保留用户输入以防错误。
- 必须将基础资产缓存在适当的位置。
- 应允许安全操作排队以便稍后同步。
- 出现临时错误后不应强制重新启动整个任务。
- 必须传达操作是否成功、不成功或仍待处理。

在理想条件下，优雅地处理中断的接口只会比快速接口更可靠。

### 测试真实条件

性能测试应包括真实的低端设备、不同的浏览器、小屏幕、CPU 节流以及模拟缓慢或不稳定的网络。在现场和受控测试中衡量核心网络生命力；按设备类别、连接类型、地理位置和关键旅程对结果进行细分。

标准“它可以在我的机器上运行吗？”它不是。就是：“普通设备、连接困难的用户能否看到、理解并完成重要任务？”高性能产品不会将硬件质量或网络速度作为可用体验的先决条件。

## 性能优先的设计

性能优先的设计速度、响应能力和稳定性并不是发布后需要解决的技术问题；从一开始就将其视为产品需求。它要求设计师和工程师考虑每种视觉效果、交互和功能对用户时间、注意力、电池、数据和设备资源的影响。

### 从核心体验开始首先确定用户的主要目标并设计实现该目标的最短可靠路径：

- 首先显示最重要的内容。
- 尽早采取主要行动。
- 删除与核心内容竞争的装饰性项目。
- 推迟高级功能直到需要它们为止。
- 使用渐进式披露来保持初始屏幕简单。
- 设计有用的空白、加载、错误和离线状态。

一个漂亮的界面需要很长时间才能变得有用，这并不是成功的设计。即使次要内容继续加载，主屏幕也应该快速提供价值。

### 负责任地做出视觉选择

设计决策直接影响性能。大型英雄视频、未优化的图像、自定义字体、复杂的阴影、过多的动画和第三方小部件可能会增加下载大小、渲染工作和交互延迟。

选择适当大小的响应式图像、轻量级资源、受限动画和渐进式可渲染组件。

### 设计感知性能

用户需要反馈和速度。响应式界面：

- 必须立即确认输入。
- 加载新内容时保护屏幕。
- 如果页面结构已知，则应使用骨架。
- 进度指标应用于持续时间较长的操作。
- 必须保持布局尺寸不变，以防止视觉移动。
- 解释错误并提供恢复操作。

反馈应该诚实：加载动画不应该隐藏卡住的请求；框架应该类似于它所代表的内容，并且不应该产生错误的期望。

### 将绩效嵌入流程中

性能优先的设计作为通用工作流程效果最佳：

1. 定义页面重量、加载、响应能力和稳定性的性能预算。2. 在设计评审中包括速度较慢的设备和网络。
3、不仅仅是理想的最终画面；原型加载、错误和转换状态。
4. 在实验室和现场条件下测试真实的用户旅程。
5. 发布后监控 Core Web Vitals 和任务结果。
6. 当新功能消耗可用预算时重新审视设计。

中心原则很简单：**不仅仅是理想原型中出现的内容；设计用户实际可以获得的体验。**

## 铁路模型

RAIL 将 Web 性能定义为不单页加载计数；它是一个以用户为中心的框架，用于根据用户操作序列进行思考。将体验分为**响应、动画、空闲和加载**；它根据人们对延迟的看法，为每种情况提供了一个实际目标。 [web.dev](https://web.dev/articles/rail)

|原理|用户体验 |实用目标|
|---|---|---|
| **回应** |确认单击、点击、键入和其他输入 | 100 毫秒内回复 |
| **动画** |保持滑动、拖动和过渡流畅 |生成每一帧大约需要 16 毫秒 |
| **空闲** |使用后台时间而不妨碍以后的交互 |以小块的方式工作，最好在 50 毫秒以内 |
| **加载** |快速提供有用的内容和参与度 |约5秒加载互动内容 |

###回应

当用户单击按钮时，界面应该几乎立即确认操作 - 即使整个过程需要更长的时间。第一个响应可以是按下状态、旋转器、乐观更新或导航切换；其目的是确保已收到输入。长 JavaScript 任务可能会阻塞主线程并延迟此反馈。将昂贵的工作分解成更小的部分可以让浏览器更频繁地将控制权返回给用户。 [MDN](https://developer.mozilla.org/en-US/docs/Glossary/RAIL)

### 动画

滑动、拖动和转换是持续的交互。如果渲染丢失帧，运动就会变得不稳定；界面感觉粗糙且难以控制。

传统 RAIL 的目标是每帧大约 16 毫秒（帧速率为 60 fps）。在实践中，团队应该优先考虑流动性，因为移动有助于理解情况或操纵内容；应避免消耗处理能力的不必要的动画。

### 空闲

空闲时间是为未来交互做准备的机会：预加载可能的内容、解析延迟的数据或初始化非关键组件。然而，后台作业必须保持可中断；独占主线程的任务会让用户在与页面交互时感觉页面变慢。

RAIL 建议将空白工作分成短单元，以便优先考虑交互。这对于低功耗设备尤其重要，因为相同的计算需要更长的时间。 [web.dev](https://web.dev/articles/rail)

###加载

下载并不会随着浏览器下载每个资源而结束。有意义的目标是显示有用的内容，建立视觉稳定性，并尽快提供关键交互。

因此，基于 RAIL 的装载策略优先考虑：

- 关键内容和风格。
- 第一次有意义的亮相。
- 基本交互代码。
- 稳定的布局尺寸。
- 延迟的图像、脚本和不是立即需要的功能。

### 今天使用 RAILRAIL 最好理解为一种不会取代现代指标的规划和优先级模型。将其与 Core Web Vitals、现场数据和任务结果配对，以了解哪些延迟对用户最重要。

例如，产品团队可能会发现登陆页面加载可以接受，但搜索过滤器需要 600 毫秒。 RAIL 将注意力集中在这种相互作用上，因为摩擦力的真正来源不仅仅是初始载荷；还有摩擦力。就是答案。核心原则是：**优化用户行动、等待并弄清楚发生了什么的时刻。**

## 从头开始设计性能

当它嵌入到产品的基础中而不是作为启动后的清理任务时，最容易实现性能。有关内容、布局、视觉效果、字体、JavaScript、API 和架构的早期决策决定了体验的可用速度以及在真实设备上的响应速度。

### 尽早设定目标

在创建详细屏幕之前，定义“足够快”对于最重要的用户旅程意味着什么：

- 有意义的内容应该什么时候出现？
- 用户什么时候应该能够交互？
- 主要行动应多快做出反应？
- 多少订单变动是可以接受的？
- 应支持哪些设备和网络条件？

将这些答案转化为页面重量、图像大小、JavaScript、字体、第三方代码、加载时间和交互延迟的性能预算。预算使性能成为常见的设计约束，而不仅仅是开发人员的问题。

### 首先做出高影响力的选择

最大的收益通常来自于实施前做出的决定：

- 在装饰媒体之前优先考虑基本内容。
- 在次要功能之前设计关键路径。- 选择响应式图像和适当大小的资源。
- 减少自定义字体和第三方脚本的依赖。
- 加载内容时保持布局稳定。
- 使用渐进增强来实现高级功能。
- 避免需要不必要的网络请求的交互。

一个小型的、集中的界面通常比需要优化的功能丰富的界面更容易加速。

### 真实体验的原型

静态设计文件代表最终状态；但不表示等待、部分加载、失败或恢复。原型应包括：

- 初始加载缓慢。
- API 响应延迟。
- 空状态和骨架状态。
- 进度指标。
- 离线或断开连接。
- 错误和重试行为。
- 低端设备限制。
- 键盘、触摸和辅助功能交互。

这会带来与性能相关的用户体验问题，但它们仍然可以廉价地更换。

### 不断测量

每个阶段的性能测试：设计审查、原型、拉取请求、候选发布和生产。使用实验室重现问题，使用现场了解真实用户，并使用任务完成、放弃和满意度等产品指标来验证技术改进是否有效。

指导原则是**向左移动性能**：在编写代码之前做出重要的性能决策，通过预算和测试来保护它们，并将它们视为最终功能定义的一部分。快速产品并不是通过一次最终优化就能生产出来的；它是由从一开始就做出的数百个小决定形成的。

## 最常混淆的配对```text
❌ Performans UX’ten ayrıdır
✓ Performans, UX’in en görünür boyutlarından biridir

❌ Yeşil Core Web Vitals panosu ürünün iyi hissettirdiği anlamına gelir
✓ Metrikler gerçek sürtünme ve görev sonuçlarını temsil ettiğinde işe yarar

❌ Bekleme yalnızca saat süresidir
✓ Algılanan bekleme; geri bildirim, kesinlik ve kontrolle şekillenir

❌ Geliştirici laptopunda hızlı olmak “yeterince hızlı”dır
✓ Kapsayıcı performans sıradan cihazlar ve zor ağlardan başlar

❌ Lansmandan sonra optimize edin
✓ Performansı sola kaydırın: bütçe, prototip ve “bitti” tanımı ilk günden

清单：将性能视为产品用户体验

1. 列出五个最高价值的旅程（在市场中：搜索、产品详细信息、添加到购物车、结帐、帐户恢复）。
2. 对于每一次旅程，用通俗易懂的语言写下“破碎”的感觉——黑屏、无声触摸、布局弹跳、重复点击。
3. 设定有意义的内容、交互准备情况、响应延迟和布局稳定性的目标。 4、不仅仅是理想的屏幕；设计待机、错误、离线和恢复状态。
4. 将核心网络生命（现场+实验室）映射到任务成功、任期、失败、放弃和满意度。
5. 确定发布被视为“完成”之前必须迁移的关键设备和网络。
6. 应用 RAIL 透镜：哪个延迟对响应、动画、空闲或加载影响最大？
7. 将答案转化为设计和工程共同拥有的绩效预算。

如果你不能回答这八个问题，那么性能仍然是次要的；这不是产品要求。

本集要点

1. 性能就是用户体验：用户随着时间的推移体验产品——外观、响应能力、稳定性和流动性。
2. 缓慢会消耗信任、转化、保留和情感能量；第一次等待就是第一印象。 3.感知的等待往往比客观的秒数更重要；将反馈、进度和控制设计成不可避免的延迟。
3. 一起衡量系统性能和用户结果；选择旅程而不是页面虚荣分数。 5、包容性、性能优先的设计从基础设备、不完善的网络、早期的预算开始。
4. RAIL持续关注用户的行为和等待时刻； Core Web Vitals 将这个故事的各个部分数字化。

目标不是让棋盘变绿。目标是帮助用户快速、安全、省力地完成重要任务。

接下来：我们将把用户的感受与工具测量的内容分开，这样指标就成为决策工具，而不是虚荣表。