无需登录 数据私有 本地保存

DOM 变更性能分析器 - 记录并统计重排重绘

73
0
0
0

Core Web Vitals 核心概念

Core Web Vitals 是 Google 定义的一组标准化的 Web 用户体验指标,用于量化网页在加载性能、交互响应性和视觉稳定性方面的真实用户表现。这些指标基于 Chrome 用户体验报告(CrUX)的真实用户数据,反映了实际用户的体验感受而非实验室模拟数据。Core Web Vitals 是 Google 搜索排名算法的重要组成部分,满足"良好"阈值的页面在搜索结果中会获得排名优势。核心指标会定期更新,当前(2024 年起)的三个核心指标是 LCP、INP 和CLS。开发者应持续关注 Core Web Vitals 的更新动态,及时调整优化策略。

Largest Contentful Paint 最大内容绘制详解

LCP 是 Core Web Vitals 中衡量加载性能的核心指标,测量视口中最大内容元素完成渲染的时间点。LCP 的计时从页面开始加载算起,包括了 DNS 解析、TCP 连接、TLS 握手、服务器响应、HTML 解析、资源加载和渲染的完整过程。LCP 的候选元素按优先级排列为:使用 url() 加载背景图的元素、img 元素、video 元素的封面帧、通过 CSS 等包含文本节点的块级元素。当页面中有多个候选元素时,取最后渲染完成的那个作为 LCP 元素。影响 LCP 的主要因素包括:服务器响应时间(TTFB)、关键渲染路径上的资源加载时间、客户端渲染和布局计算时间。优化 LCP 的核心策略包括:优化服务器响应、使用 CDN、预加载关键资源、优化图片加载、减少渲染阻塞资源。

Interaction to Next Paint 交互到下一次绘制详解

INP 是 Core Web Vitals 中衡量交互响应性的核心指标,替代了之前的 FID(First Input Delay)指标。INP 测量用户与页面所有交互中,从输入事件发生到下一次视觉更新(绘制)之间的最大延迟。INP 捕获的是整个页面生命周期中最差的交互体验,而不是仅首次交互。INP 的评估涵盖了所有类型的用户交互:点击、按键、触摸、手势等。一个完整的 INP 测量包括三个阶段:输入延迟(Input Delay,从用户操作到事件处理程序开始执行的时间)、处理时间(Processing Time,事件处理程序的执行时间)、展示延迟(Presentation Delay,从事件处理程序完成到浏览器绘制下一帧的时间)。优化 INP 的核心策略包括:拆分长任务、使用 Web Worker 分离计算、减少 DOM 操作、优化事件处理程序、使用 requestIdleCallback 处理非关键工作。

Cumulative Layout Shift 累计布局偏移详解

CLS 是 Core Web Vitals 中衡量视觉稳定性的核心指标,测量页面整个生命周期中所有意外布局偏移的累计分数。布局偏移发生在已渲染的元素在视口中意外改变位置,通常由以下原因导致:图片或视频没有设置明确的尺寸、动态插入或加载的内容将现有内容推开、Web 字体加载后文字重排、异步加载的广告或嵌入内容。CLS 的计算公式为:布局偏移分数 = 影响分数(Impact Fraction)乘以 距离分数(Distance Fraction)。影响分数是不稳定元素影响的视口面积比例,距离分数是元素移动的最大距离占视口高度的比例。Google 将 CLS 的计算从"会话窗口"方式改为"页面全生命周期累计"方式,更准确地反映用户的真实体验。

First Contentful Paint 首次内容绘制详解

FCP 是一个辅助性能指标,测量浏览器渲染出页面中第一个 DOM 内容(文本、图片、canvas 元素或非空 iframe)的时间。FCP 反映了用户看到页面上第一点内容的速度,是用户感知加载速度的第一个正向信号。FCP 的测量范围比 LCP 更广,任何 DOM 内容的渲染都算作 FCP,而 LCP 只关注最大的那个元素。良好的 FCP 应在 1.8 秒以内。影响 FCP 的主要因素包括:服务器响应时间、关键 CSS 资源的加载、HTML 解析速度、首屏内容的复杂度。虽然 FCP 不是 Core Web Vitals 的核心指标,但它与 LCP 有强相关性——FCP 较快的页面通常 LCP 也较好。优化 FCP 的策略包括:内联关键 CSS、减少 CSS 和 JavaScript 阻塞、优化服务器响应、使用预渲染技术。

Total Blocking Time 总阻塞时间详解

TBT 是一个实验室指标,测量在 FCP 到 TTI(Time to Interactive)之间,主线程被长任务(执行时间超过 50 毫秒的任务)阻塞的总时间。每个超过 50 毫秒的任务的超出部分(执行时间减去 50 毫秒)会被累加到 TBT 中。TBT 反映了页面在加载过程中主线程的繁忙程度,间接影响用户的交互体验。TBT 较高意味着主线程被大量 JavaScript 执行占用,用户在加载过程中的交互会被延迟。良好的 TBT 应在 200 毫秒以内。虽然 TBT 不是 Core Web Vitals 的核心指标(INP 替代了其在真实用户衡量中的角色),但 TBT 是实验室中评估交互响应性的重要指标,也是 Lighthouse 性能评分的重要组成部分。降低 TBT 的策略包括:拆分长任务、延迟加载非关键脚本、使用代码分割、减少第三方脚本影响。

Time to First Byte 首字节时间详解

TTFB 测量从浏览器发起请求到接收到来自服务器的第一个字节的响应数据的时间。TTFB 包含了 DNS 解析、TCP 连接建立、TLS 握手和服务器处理请求的时间。TTFB 是所有后续性能指标的起点,TTFB 较慢意味着所有后续操作都要等待。良好的 TTFB 应在 800 毫秒以内。影响 TTFB 的因素主要来自服务器端:服务器处理性能、数据库查询速度、应用层缓存命中率、服务器地理位置距离。TTFB 较慢的优化策略包括:使用 CDN 将内容分发到离用户更近的节点、优化数据库查询、使用服务端缓存、升级服务器硬件、启用 HTTP/2 或 HTTP/3 减少连接建立开销。

Speed Index 速度指数详解

Speed Index 是一个综合性的视觉加载性能指标,测量页面内容的可见速度。它基于页面渲染过程中每个像素的可见时间计算,反映了用户在页面加载过程中看到内容变化的速度。Speed Index 的计算方法是:对视口中的每个像素,计算其变为可见的时间点,然后计算所有像素的加权平均时间。Speed Index 越低表示用户越早看到页面内容。Speed Index 是 Lighthouse 性能评分中权重最高的指标之一。优化 Speed Index 的策略与优化 LCP 类似,但更强调首屏所有内容的整体加载速度,而不仅是最大元素。使用骨架屏(Skeleton Screen)可以改善用户对 Speed Index 的感知。

First Input Delay 首次输入延迟详解

FID 测量用户首次与页面交互(点击、按键等)到浏览器实际开始处理事件的时间延迟。FID 仅测量输入延迟,不包括事件处理和渲染时间。FID 在 2024 年已被 INP 正式替代,但了解 FID 仍有价值,因为许多历史数据和优化建议仍基于 FID。FID 的"良好"阈值为 100 毫秒以内。FID 较高通常是因为主线程正在执行长 JavaScript 任务,导致输入事件排队等待。优化 FID 的策略与优化 INP 类似:减少主线程的 JavaScript 执行量、拆分长任务、将非关键工作推迟到空闲时段。

Navigation Timing API 导航计时

Navigation Timing API 是浏览器提供的 JavaScript API,用于获取页面导航和加载过程中的详细时间数据。通过 performance.timing 和 performance.getEntriesByType("navigation") 接口,开发者可以获取从导航开始到加载完成的每个阶段的时间戳,包括 DNS 查询时间、TCP 连接时间、服务器响应时间、DOM 解析时间、资源加载时间等。Navigation Timing API 的数据是计算 Core Web Vitals 指标的基础数据源。开发者可以在生产环境中使用 Navigation Timing API 采集真实的用户性能数据,结合 RUM(Real User Monitoring)系统进行持续的性能监控。

Chrome User Experience Report 用户体验报告

CrUX(Chrome User Experience Report)是 Google 提供的真实用户性能数据集,收集了数百万匿名 Chrome 用户的网页体验数据。CrUX 数据覆盖了 Core Web Vitals 的所有核心指标,按来源(origin)或 URL 聚合,按设备类型(移动/桌面)和地区分类。CrUX 数据是 Google 搜索排名中 Core Web Vitals 评估的数据来源,也是评估网站真实性能表现的权威数据。开发者可以通过 CrUX API、PageSpeed Insights 工具或 CrUX Dashboard 获取 CrUX 数据。本工具的评估引擎参考了 CrUX 的统计分布和阈值定义,确保评估标准与 Google 的官方标准一致。