#优质博文 #React #性能优化 #JavaScript #course
How to Measure and Optimize React Performance | DebugBear：全面介绍了衡量和优化 React 应用性能的工具与技术，重点讲解了 React 19.2 的新特性以及各类运行时和构建时的优化策略。

AI 摘要：文章深入探讨了如何应对 React 应用随规模增长而出现的性能退化问题。内容涵盖了从 React 19.2 新引入的性能轨道（Performance Tracks）到经典的 Profiler 工具的使用方法。作者详细讲解了运行时优化（如记忆化、虚拟列表和状态管理）、并发特性（useTransition 和 useDeferredValue）、包体积控制、服务端渲染（SSR）以及最新的 React Compiler。最后，文章强调了在生产环境中使用真实用户监控（RUM）来持续跟踪性能表现的重要性。

[以下是方便搜索索引的大纲 (AI 生成)，请读原文]

1. 衡量 React 性能的工具
• React 性能轨道 (React Performance Tracks)：介绍了 React 19.2 引入的新功能，在 Chrome DevTools 的性能面板中可视化调度器、组件渲染及服务器请求。
• React DevTools Profiler：讲解了如何使用火焰图（Flame Chart）定位瓶颈，并利用“记录组件渲染原因”功能排除不必要的重绘。
• Profiler API 与 Chrome 性能面板：介绍如何通过代码编程式地收集渲染时长，以及如何在主线程时间线中分析 JavaScript 的执行耗时。

2. 运行时优化策略
• 记忆化：详细对比了 memo()、 useMemo() 和 useCallback() 的使用场景，强调避免对简单计算过度使用。
• 代码分割：利用 lazy() 和 Suspense 实现组件按需加载，减少初始加载负担。
• 列表虚拟化：推荐使用 react-window 等库处理长列表，仅渲染可视区域内的 DOM 节点。
• 状态管理优化：提倡状态共存（State Colocation）原则，并建议在复杂场景下使用 Zustand 或 Jotai 等支持选择器优化的轻量库。

3. 并发特性与编译器
• 并发渲染挂钩 (Concurrency Hooks)：讲解了 useTransition 如何标记非紧急更新以保持 UI 响应，以及 useDeferredValue 如何延迟处理从父级传递的频繁变动的值。
• React Compiler：介绍了 2025 年推出的自动记忆化工具，它能在构建时自动优化组件，减少手动编写 useMemo 的需求。

4. 交付与架构优化
• 包体积控制：使用 Lighthouse Treemap 和 Webpack Bundle Analyzer 分析依赖，提倡按需引入（Tree Shaking）以减少解析耗时。
• 服务端渲染与流式传输 (SSR & Streaming)：探讨了 renderToPipeableStream 带来的流式 HTML 交付，以及 React 服务端组件（RSC）如何通过零客户端 JavaScript 提升性能。

Debugbear

How to Measure and Optimize React Performance | DebugBear

Learn how to measure the performance of your React app and identify what's slowing it down.

#优质博文 #前端 #JavaScript #V8 #benchmark #性能优化
JavaScript's for-of loops are actually fast (V8)：探讨现代 V8 引擎中 for-of 循环的性能表现，打破了开发者社区中关于其性能显著弱于传统循环的固有印象。作者建议现在除非是处理极端海量数据且对每一毫秒都敏感的场景，否则应优先使用语义更佳的 for-of 循环。

AI 摘要：这篇文章通过一系列严谨的基准测试（Benchmark），对比了 JavaScript 中六种不同的数组遍历方式。测试结果显示，在现代 V8 引擎（如 Chrome 143）中，曾经被认为因为迭代协议（Iteration Protocol）开销而较慢的 for-of 循环，现在的性能已几乎与缓存了长度的经典 for 循环持平。文章强调，虽然在大规模数组的首次执行中 for-of 可能存在优化延迟，但经过引擎预热（Warmup）后，其表现非常出色。作者建议在非极端性能敏感的场景下，应优先考虑 for-of 的开发易用性。

author Suren Enfiajyan

WaspDev Blog

JavaScript's for-of loops are actually fast (V8)

Running some benchmarks with different types of loops in JavaScript to see how well for-of loops perform compared to other loops.

#AI #React #前端 #性能优化
vercel 开源了他们写 react 以及各种情况下的用到的 skill（
通过 npx add-skill vercel-labs/agent-skills 安装

vercel-labs/agent-skills

AI 摘要：vercel-labs/agent-skills 是一个 GitHub 仓库，汇集了专为 AI 编程代理（AI Coding Agents）设计的“技能”（Skills）。这些技能通过预打包的指令和脚本，增强了代理在代码开发、审查和部署方面的能力。目前包含 react-best-practices（专注于 React/Next.js 性能优化）、web-design-guidelines（审查 UI 代码的无障碍性、性能和用户体验）以及 vercel-deploy-claimable（快速将应用部署到 Vercel）等核心技能。通过简单的命令行安装后，AI 代理可自动识别并利用这些技能来完成相关任务，极大地提升了自动化开发和部署的效率。

GitHub

GitHub - vercel-labs/agent-skills: Vercel's official collection of agent skills

Vercel's official collection of agent skills. Contribute to vercel-labs/agent-skills development by creating an account on GitHub.

#优质博文 #前端 #工程化 #性能优化 #Electron
记 LobeHub 的性能和 DX 优化

AI 摘要：作者回顾入职一个月在 LobeHub 进行的性能与开发体验优化。主要内容包括：替换 react-layout-kit、移除 CSS-in-JS 动态样式以降低渲染与内存开销；优化首屏返回速度并大幅提升消息列表渲染性能；重构 Tooltip、Popover 等基础组件；削减 Electron App 体积约 100MB；改进 i18n 与 IPC 开发体验；并计划未来将 Next.js 迁移至 Vite，以显著降低开发期内存占用。

author Innei

innei.in

记 LobeHub 的性能和 DX 优化

距离去新的工作差不多一个多月了。这段时间刚入职，其实都挺忙的，而且公司也正在筹划发布 2.0 的版本，所以我加入的时候刚好算是个好时机（忙到起飞）。 这一个月基本都是在冲刺。我发现，我每次换一个公司，刚进去的一段时间都会去做一些项目中的性能优化，以及对一些开发体验不友好的事情，做过多的调教。 尤

#优质博文 #JavaScript #性能优化
Why Object of Arrays (SoA pattern) beat interleaved arrays: a JavaScript performance rabbit hole

AI 摘要：本文通过基准测试对比了 JavaScript 中 Array of Objects (AoS) 和 Object of TypedArrays (SoA) 两种数据存储模式的性能。实验发现 SoA 模式比 AoS 模式快 4 倍。文章深入分析了这种性能差异并非仅源于 TypedArrays 的优势，而是多种因素共同作用的结果，包括对象属性查找开销、内存布局、缓存效率以及循环开销等。最终结论是，消除对象开销、减少循环迭代次数、利用属性访问提升（property access hoisting）以及 TypedArray 提供的性能保证是 SoA 模式性能更优的关键。

#优质博文 #React #前端 #性能优化 #异步编程 #course
讲了怎么使用 TanStack Pacer 来管理前端应用中的异步事件时序，以优化性能并避免 RxJS 的复杂性。
Moving beyond RxJS: A guide to TanStack Pacer - LogRocket Blog

AI 摘要：TanStack Pacer 是一个专为前端应用设计的轻量级库，旨在解决常见的异步事件时序问题，例如防抖、节流、批处理和速率限制。文章通过构建一个类似 Pinterest 的无限滚动图片画廊，详细展示了如何在 React 应用中集成并使用 Pacer 的核心功能，以优化用户界面性能并避免 RxJS 带来的复杂性，从而提供了一个更易学、更小巧、更符合 React 生态的解决方案。

author Emmanuel John

LogRocket Blog

Moving beyond RxJS: A guide to TanStack Pacer - LogRocket Blog

Build a React infinite scroll gallery with TanStack Pacer. Learn debouncing, throttling, batching, and rate limiting without RxJS complexity.

#优质博文 #前端 #工程化 #性能优化 #JavaScript #BundleSize #TreeShaking #course
相当实用的好文，教你怎么减小打包体积（PS：初学者友好）
Bundle Size Investigation: A Step-by-Step Guide to Shrinking Your JavaScript

AI 摘要：本文提供了一份详细的逐步指南，旨在帮助开发者调查并缩减 JavaScript 打包文件的大小，以提高网页性能。作者通过一个实际项目案例，展示了如何使用打包分析器来识别大型或冗余的代码块。文章深入探讨了摇树优化（tree-shaking）的工作原理和局限性，特别是针对 CommonJS 模块和 * 导入模式。此外，还介绍了如何通过识别和移除重复库、以及处理由第三方依赖引入的传递依赖（transitive dependencies）来进一步优化代码体积，最终将示例项目的 bundle size 从 5MB 显著减少到 600KB 左右。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 初始项目设置 (Initial Project Setup)
• 作者创建了一个故意膨胀的示例项目（其 JavaScript 包大小为 5MB），作为演示如何调查和缩小打包体积的起点。
• 提供项目 GitHub 仓库链接，鼓励读者通过实际操作来验证文章内容。
2. 分析打包大小 (Analyzing Bundle Size)
• 介绍了打包分析器（bundle analyzer）工具的使用，例如 Vite 项目中的 Rollup Plugin Visualizer。
• 解释如何解读打包分析图（treemap），识别出项目中最大的代码块，尤其是供应商（vendor）代码和应用程序自身代码。
• 指出可以通过配置更改可视化模板（template），如使用火焰图（flamegraph），以获得不同视角的分析。
3. 调查流程 (Investigation Process)
• 确定要移除的包 (Step 1: Identify a Package to Eliminate)：通过打包分析图识别出体积巨大且可能存在问题的包，如 @mui 相关的包。
• 理解包 (Step 2: Understand the Package)：快速研究包的功能和用途，以理解其在项目中的角色。
• 理解包的使用方式 (Step 3: Understand the Usage of the Package)：通过代码搜索确定包在项目中的导入和使用模式，特别是是否存在 * 导入所有内容的模式。
• 确认问题 (Step 4: Confirm That This is the Problem)：通过临时注释掉问题包的导入代码并重建项目，验证其对打包大小的实际影响。
4. 摇树优化和死代码消除 (Tree Shaking and Dead Code Elimination)
• 解释摇树优化（tree-shaking）的原理：现代打包工具如何识别并移除未使用的代码（dead code）。
• 通过示例代码展示了 tree-shaking 在原生 ESM 模块中的有效性。
• 揭示了 * 导入模式（ import * as Something from 'library'）会阻止 tree-shaking 对外部库生效，导致整个库被打包。
• 提出解决方案：避免使用 * 导入，改为精确导入所需模块，以确保 tree-shaking 正常工作。
5. ES 模块和非摇树优化库 (ES Modules and Non-tree-shakable Libraries)
• 解释 JavaScript 模块格式（如 ESM, CommonJS）对 tree-shaking 能力的影响。
• 强调 ESM 格式易于 tree-shaking ，而 CommonJS 等旧格式则难以优化。
• 介绍 is-esm 工具，用于检查一个 npm 包是否为 ESM 格式。
• 以 lodash 库为例，展示了非 ESM 格式导致 tree-shaking 失败的问题，即使是精确导入特定函数也无济于事。
• 提供解决方案：使用库提供的精确子路径导入（import trim from 'lodash/trim'）来只引入所需部分，或在功能允许的情况下替换为原生 JavaScript 函数。
6. 常识和重复库 (Common Sense and Repeating Libraries)
• 指出在大型项目中，多个库可能实现相同功能，导致代码冗余。
• 以日期处理库 date-fns、moment 和 luxon 为例，展示了如何识别并移除这些重复的库。
• 强调选择替换库时需考虑 tree-shaking 能力、API 易用性、维护状态以及对打包大小的影响。
• 通过将 moment 和 luxon 的使用重构为 date-fns，显著减少了打包体积。
7. 传递依赖 (Transitive Dependencies)
• 解释传递依赖：当项目直接依赖的库又依赖了其他库时，这些间接依赖也会被打包。
• 介绍 npm-why 工具，用于追溯一个包的所有依赖路径，从而识别其作为传递依赖的来源。
• 以 @emotion 库为例，即使从项目中移除了直接使用，它仍可能通过 @mui 等库作为传递依赖存在。
• 说明移除传递依赖可能需要移除其上游所有依赖，这是一项需要权衡成本和收益的复杂任务。
• 通过将 @mui 组件替换为 Radix UI 组件并替换图标，成功移除了 @mui 及其传递依赖 @emotion。
8. 结果 (The Result)
• 总结了整个优化过程的成果：示例项目的 JavaScript 包大小从 5MB 显著减少到 600.98 KB。
• 指出尽管取得了巨大进步，但仍有进一步的优化空间，例如通过懒加载（lazy loading）处理 tiptap 和 prosemirror 等大型库。

author Nadia Makarevich

Developerway

Bundle Size Investigation: A Step-by-Step Guide to Shrinking Your JavaScript

A practical guide to analyzing and reducing JavaScript bundle size. Learn bundle analysis, fix tree-shaking issues, remove duplicate libraries, and otherwise optimize your React app's JavaScript size.

#优质博文 #前端 #R3F #WebGL #性能优化 #course
Infinite Canvas: Building a Seamless, Pan-Anywhere Image Space | Codrops

AI 摘要：本教程深入探讨了如何利用 React Three Fiber 构建一个无缝、可无限平移的 3D 图像画布。文章核心在于通过“区块” (chunk) 分块渲染、确定性 (deterministic) 内容生成、基于距离的剔除 (culling) 与渐隐，以及惯性 (inertia) 驱动的相机控制器等技术，创造出无限探索的视觉错觉，同时确保在高性能设备上达到 120 帧的流畅体验。它还详细介绍了包括延迟加载、像素密度限制、禁用抗锯齿等多种性能优化策略，为开发者提供了构建响应式、沉浸式 3D 体验的实用指南和未来扩展方向。

author Edoardo Lunardi

#优质博文 #前端 #性能优化 #调试 #新动态
Chrome DevTools 144 版本可以让你单独对每个网络请求限速。
Throttle individual network requests

AI 摘要：Chrome DevTools 在 144 版本中引入了“Individual Request Throttling”功能，允许开发者为单个网络请求设置独立的限速（throttling）或阻断（blocking）条件。这一改进使得在不影响整个页面加载速度的情况下，测试特定资源（如第三方 API 或大型图片）在慢速网络条件下的表现成为可能。新功能整合在“Request conditions”面板中，用户可以自定义限速模式和 URL 匹配规则，并清晰地在“Network”和“Performance”面板中识别被限速或阻断的请求，从而更精准高效地进行前端性能调试。

Chrome for Developers

Throttle individual network requests  |  Blog  |  Chrome for Developers

Use the Request conditions tab to block specific URLs or apply custom network throttling profiles to individual resources.

#优质博文 #前端 #CSS #Astro #ISR #性能优化
想起以前做的 ISR，心血来潮搜一下 Astro 里的 ISR 怎么做，做一下。
On-Demand ISR For Astro on Vercel

AI 摘要：本文详细介绍了如何在 Vercel 平台上为 Astro 静态网站配置按需增量静态再生成 (On-Demand ISR)。文章首先解释了 ISR 和按需 ISR 的概念及其适用场景，然后通过一步步的代码示例，指导读者如何初始化项目、添加 Vercel 适配器并配置 ISR 参数、创建动态页面，以及最关键的部分——如何通过一个受保护的 API 端点来手动触发缓存失效和页面重建，从而实现对静态内容更新时间的精细控制。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 概念解析
• 什么是 ISR：解释增量静态再生成 (ISR) 的概念，即无需重新构建或部署整个网站即可更新静态内容（如博客文章或 GET API 端点）。
• 什么是按需 ISR：对比传统基于 TTL（生存时间）的 ISR，说明按需 ISR 允许在 TTL 到期前手动使缓存失效并触发重建，从而更精确地控制内容的新鲜度。
• 适用场景：列举按需 ISR 的典型用例，如不常更新但更新后需立即生效的内容，或渲染成本高（计算、时间、外部 API 费用）的频繁访问内容。

2. 项目配置
• 初始化 Astro 项目：使用命令行工具创建一个包含 Tailwind CSS 和 React 的 Astro 项目，并初始化 Git。
• 添加 Vercel 适配器：通过 astro add vercel 命令添加适配器，并在 astro.config.mjs 文件中配置 ISR 参数，包括设置 bypassToken（用于授权缓存失效的密钥）和 exclude（排除 API 路由不被缓存）。

3. 实现与验证
• 创建动态页面：在首页添加一个显示服务器渲染时间戳的组件，用于验证缓存效果。部署后，刷新页面时间戳不变，且响应头 x-vercel-cache 显示 HIT，证实页面来自缓存。
• 实现按需失效端点：创建一个受保护的 API 端点 (/api/invalidate)，该端点接收 POST 请求，内部向目标路由发送带有 x-prerender-revalidate 头（值为 bypassToken）的 HEAD 请求，以触发缓存失效和重建，并验证响应头确认操作成功。
• 测试：通过 curl 命令调用该 API 端点，成功使首页缓存失效，再次访问首页时看到新的时间戳，证明按需 ISR 生效。

author Shawn

Shawn's Blog

On-Demand ISR For Astro on Vercel | Shawn's Blog

Here's how to set on-demand incremental static regeneration for an Astro website when deploying to Vercel.

#优质博文 #git #开源 #性能优化 #rust #版本管理 #新动态
锈化！都给我锈化！
Highlights from Git 2.52

AI 摘要：Git 2.52 是一次重要更新，带来了全新的 git last-modified 命令，大幅提升了目录级变更追踪性能。改进了 git maintenance 的几何级（geometric）打包策略，使大型仓库的维护更高效。除此之外，还新增了 git repo 命令用于仓库信息查询，引入 Rust 代码优化内部实现，并为 Git 3.0 的默认分支名更改（从 master 到 main）和 SHA-256 过渡打下基础。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. Tree-level 责任追踪
• 新增 git last-modified 命令，用于快速查询目录中每个文件最后一次被修改的提交。
• 相比传统 git log + 脚本方式速度提升约 5 倍以上。
• 功能源自 GitHub 内部工具 blame-tree，现上游化至 Git 主干。
• 支持未来改进，比如结果缓存的磁盘格式。

2. 高级仓库维护策略
• git maintenance 命令新增 geometric 任务，实现高效打包与逐步清理策略。
• 该模式基于几何打包（geometric repack），在性能和空间之间取得平衡。
• 相关技术源自 GitHub 自用工具，从 Git 2.33 起逐步完善。

3. 其他核心更新与实验功能
• 新增 git refs list 与 git refs exists 子命令，统一引用（reference）操作接口。
• 全新实验命令 git repo，整合查询仓库结构、对象与格式信息的能力。
• 性能显著提升：git describe、git log -L、git ls-files 等命令获优化。
• Bloom filter 算法改进，支持更复杂的路径匹配（pathspec）。

4. 迈向 Git 3.0 的过渡性变更
• 默认分支配置 init.defaultBranch 将在 3.0 版改为 “main”。
• 引入 SHA-256 作为对象哈希算法的未来默认值，兼容 SHA-1 环境。
• 开放 WITH_BREAKING_CHANGES 构建标志，提前体验 3.0 功能。

5. Rust 支持与内部重构
• 可选启用 WITH_RUST 编译选项，部分内部功能迁移至 Rust 实现。
• 当前用于变量宽度整数 (variable-width integers) 编码/解码。
• 为未来更多核心模块迁移铺路，Git 3.0 将全面要求 Rust。

6. 细节改进与工具增强
• sparse-checkout 新增 clean 子命令，便于清理异常文件状态。
• 多处底层库（特别是 xdiff）获得性能优化补丁。
• 跨工具一致性与脚本可编程性进一步提升。

author Taylor Blau

The GitHub Blog

Highlights from Git 2.52

The open source Git project just released Git 2.52. Here is GitHub’s look at some of the most interesting features and changes introduced since last time.

#优质博文 #前端 #性能优化 #监控工具 #工程化
Effectively Monitoring Web Performance — Smashing Magazine

AI 摘要：本文系统阐述了如何制定一套有效的网站性能监测策略，从 Google 的核心指标 Core Web Vitals（包括 LCP、CLS、INP）出发，结合合成测试（Synthetic test）与真实用户监测（Real User Monitoring, RUM），构建可持续的性能优化循环。作者提出“识别 → 诊断 → 监控”三步法，强调在持续对比与回溯的过程中找出性能瓶颈，利用工具如 DebugBear 完成检测与验证，实现网站在用户端和技术端的双重优化。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 网站性能指标基础
• 无单一定义性能标准，推荐从 Google Core Web Vitals 入手，包括 LCP（Largest Contentful Paint）、CLS（Cumulative Layout Shift）、INP（Interaction to Next Paint）。
• 除核心指标外，还需分析技术层面指标（如服务器响应时间、页面体积），并可利用 User Timing API 自定义关键加载节点。

2. 合成数据与真实用户数据（Synthetic vs Real User Data）
• 合成测试环境可控，便于重现和分析性能问题。
• 真实用户监测基于实际访问数据，可洞见不同用户群体的真实体验。
• 建议双管齐下：Synthetic 提供细节层面的技术分析，RUM 补全真实使用场景的覆盖。

3. 三步法优化流程
• Identify（识别）：通过用户数据发现加载缓慢页面，优先处理高访问量且体验差的页面。
• Diagnose（诊断）：分析瓶颈点，按指标类型分别使用 RUM 或 Synthetic 工具定位问题来源，如 LCP 图像加载、INP 交互事件延迟。
• Monitor（监控）：建立持续检测机制，监测变更效果并在性能回退（Regression）时即时响应。

4. 深入分析阶段
• 负载时间调试：Synthetic 数据帮助精确定位加载瓶颈，可做实验验证优化方案。
• 交互延迟诊断：RUM 数据揭示实际用户交互的慢响应来源，例如脚本阻塞或后台任务负载。

5. 性能回退检测与应对策略
• 合成数据回退：通过前后 Test 对比结果，定位资源变更带来的性能波动，例如新增图片竞争带宽。
• 真实用户回退：需区分访客来源变化（如广告流量）与技术改动，通过分析 LCP/INP 子部分（subparts）锁定性能劣化来源。

6. 综合结论
• 单次测试仅是起点，持续的性能监控体系才能确保长期高效。
• 工具如 DebugBear 可整合 Synthetic 与 RUM 数据，实现可视化性能追踪与优化决策。

author Matt Zeunert

Smashing Magazine

Effectively Monitoring Web Performance — Smashing Magazine

There are lots of tips for [improving your website performance](https://www.debugbear.com/blog/improve-website-performance?utm_campaign=sm-10). But even if you follow all of the advice, are you able to maintain an optimized site? And are you targeting the…

#优质博文 #CSS #前端 #性能优化 #Chrome #浏览器
从性能角度来看，对 CSS width 和 height 进行动画处理是不好的，因为它会导致渲染管线中发生布局操作（也称重排）。这一点至今仍然正确。

但最近， Chrome Canary 版本中最近有一个令人兴奋的动画/性能改进：

在 Chrome 144.0.7512.0（当前 Canary 版本）中，我们扩展了 width / height 检查，以检查 width 或 height 是否真的发生了变化。
如果 width / height 不变，则无需计算布局，因此也无需强制动画在主线程上运行。

Animating CSS width or height no longer forces a Main Thread animation (in Chrome, under the right conditions)

AI 摘要：文章介绍了 Chrome Canary（144.0.7512.0 版本）在动画性能上的新改进：当 width 或 height 在关键帧中并未实际变化时，动画不再被强制在主线程运行，而是可在合成线程（Compositor）上执行，从而显著提升性能。该优化改变了 Blink 对动画可合成判断的逻辑，对视图过渡（View Transitions）等场景尤其有利。作者也讨论了后续可控方案、兼容性影响与手动优化替代方法。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 性能与动画基础
• 解释为何过往 width / height 动画会触发 Layout，必须在主线程执行
• 说明渲染管线（rendering pipeline）中 Layout 的代价
• 传统认为应避免对这些属性做动画

2. Chrome 新改进（从版本 144.0.7512.0 开始）
• Blink 引擎增加了判断逻辑：若关键帧中 width / height 值不变，则动画可在合成线程上运行
• 展示了新旧判断流程图差异及其性能收益
• 对视图过渡动画（::view-transition-group(*)）的直接正面影响

3. 实现细节与特殊情境
• 介绍设计判断逻辑时考虑的复杂情境，如隐式关键帧、auto 值等
• 提及其他浏览器（Firefox、Safari）尚未有类似优化
• Blink 团队确保多种 CSS 表达形式都在判断范围内

4. 后续展望与开发者优化建议
• 链接至 W3C 讨论提案 w3c/csswg-drafts#13064，计划为开发者提供更多控制
• 提出当前自我优化方案：用 scale 动画取代宽高变化
• 引用了 Google Search 实际应用与 Motion 框架在变形修正上的做法

5. 影响与意义
• 此更改让许多原本“卡顿”的过渡动画直接获得加速
• 鼓励社区和其他浏览器跟进，共同提升 Web 动画性能

author Bramus!

web.dev

Rendering performance  |  Articles  |  web.dev

Users notice if sites and apps don't run well, so optimizing rendering performance is crucial!

#优质博文 #CSS #性能优化 #动画 #前端 #浏览器
The Web Animation Performance Tier List - Motion Blog

AI 摘要：本文系统梳理网页动画性能的分级标准，从浏览器渲染管线（render pipeline）的底层原理出发，解释为何某些动画（如 transform、opacity 等）能高效运行于 GPU 的 compositor 线程，而另一些（如涉及布局、重绘的动画）则极为耗费资源。作者将动画按性能分为 S 到 F 六个等级，指出各层级的触发条件、适用场景及典型陷阱，并给出实践经验（如 will-change 的使用、CSS 变量的潜在灾难、“thrashing”问题等），帮助开发者建立动画性能直觉与优化策略。

[以下是方便搜索索引的大纲（AI 生成），请读原文]

1. 渲染管线与性能基础
• 解释浏览器渲染的三个阶段：Layout、Paint、Composite，并指出触发一个阶段会引发其后所有阶段。
• 区分主线程（main thread）与合成线程（compositor thread）的运行逻辑，说明主线程阻塞将导致动画卡顿。

2. 分级体系（Tiers）总览
• S-Tier：完全运行于 compositor 线程的硬件加速动画，性能最佳。
• A-Tier：在主线程驱动但仅触发 compositor 操作的动画。
• B-Tier：含有一次性 DOM 测量成本的动画。
• C-Tier：触发 Paint 的动画。
• D-Tier：触发布局（Layout）重新计算。
• F-Tier：存在频繁读写 DOM 的“thrashing”灾难级动画。

3. S-Tier：硬件加速动画策略
• 可在 compositor 线程执行的属性有 transform、opacity、filter、clip-path。
• 借助 CSS、Web Animations API（WAAPI）或 Motion 等库实现流畅动画。
• 滚动动画的性能优势源于滚动本身在 compositor 线程执行。
• “去优化”风险：Safari 等浏览器可能丢失硬件加速。
• GPU 图层（layer）太大易耗尽内存，滤镜（尤其是 blur）成本高昂。

4. A-Tier：主线程驱动的合成动画
• 动画触发合成层更新而非重绘，前提是元素已成为图层（如 will-change）。
• JS 动画库（如 GSAP）或 requestAnimationFrame 实现的动画多属此类。
• 利用 IntersectionObserver 可节省主线程资源并暂停不可见动画。
• 提及 Shader 动画性能超强但仍受主线程同步影响。

5. B-Tier：带有预处理的高效布局动画
• Motion 的 layout 动画使用 FLIP（First, Last, Invert, Play）技术，通过 transform 模拟尺寸变化，减少重排。
• 初始测量存在成本，但整体能显著优化动画流畅度。

6. C-Tier：触发重绘的动画与陷阱
• 改变颜色、圆角等属性触发 Paint，相比几何变化轻一些。
• 警惕 CSS 变量（CSS Variables）导致不可预测性能开销：尤其全局继承时全树样式重算。
• 优化策略：缩小变量作用域或用 @property 禁止继承。
• SVG 属性动画与 View Transition API 动画的性能权衡与实践改进。

7. D-Tier：布局驱动的高成本动画
• 改变 width、margin、grid-template-columns 等属性会引发重布局。
• 使用 position: absolute/fixed 或 contain CSS 属性可减少布局范围。

8. F-Tier：性能“地狱”——样式与布局 Thrashing
• 反复读写 DOM 尺寸（如 offsetWidth）导致强制同步布局。
• 建议通过批量化读写（如 Motion 的 frame API）避免 thrashing 问题。

9. 结论
• 动画性能优化不止是“黑魔法”，而是一门平衡内存、渲染步骤与硬件加速的艺术。
• 理解渲染管线可让开发者具备判断性能瓶颈的直觉，S 级动画不代表无代价，关键是为实际体验做正确取舍。

author Matt Perry

motion.dev

The Web Animation Performance Tier List - Motion Magazine

Learn what makes web animations fast, slow, and everything in between with our 2025 web animation performance tier list.

#优质博文 #V8 #性能优化 #JavaScript
CF 不愧是赛博活菩萨捏，大气的。

@DIYgod: 一周前 Vercel 发了篇博客指责竞争对手 Cloudflare Workers 性能差，今天 Cloudflare 回应了篇博客承认错误，解释了造成问题的各种技术细节，现在把性能也追上来了 太佩服这种在竞争对手面前勇于承认错误的勇气和快速透明解决问题的态度了，现在倒是显得 Vercel 小肚鸡肠了...

https://fixupx.com/DIYgod/status/1978461834731512072

Unpacking Cloudflare Workers CPU Performance Benchmarks

AI 摘要：本文由 Cloudflare 首席架构师 Kenton Varda 撰写，针对独立开发者 Theo Browne 公布的基准测试结果展开调查与回应。原测试显示 Cloudflare Workers 在 CPU 密集型 JavaScript 任务中比 Vercel（基于 AWS Lambda）慢至 3.5 倍。Cloudflare 分析后发现，性能差异主要源自调度算法、V8 垃圾回收参数旧配置、OpenNext 框架实现低效及测试方法偏差。经过多项修复与调优，Workers 性能已与 Vercel 持平甚至超越。文中还披露了 Cloudflare 对 V8 与 Node.js 性能改进的贡献，证明其优化不仅服务自家平台，更惠及广泛的 JavaScript 生态。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 基准测试背景与问题调查
• 独立开发者 Theo Browne 公布测试，显示 Cloudflare Workers 明显落后 Vercel
• 两者皆基于相同的 V8 引擎，理论上应相近性能
• 性能差异达到 3.5 倍，引发 Cloudflare 团队深入分析
• 指出测试方法主要反映“等待时间”而非“实际 CPU 使用”

2. 平台调度算法与运行时优化
• Workers “warm isolate routing” 策略导致 CPU 密集型请求排队
• 调整调度算法，让系统更快检测并扩展新 isolate，避免阻塞
• 改进后大幅降低延迟波动，提高自动扩展效率

3. V8 (JavaScript 引擎) 垃圾回收 (Garbage Collector, GC) 调优
• 发现旧参数设定限制了“young generation”空间大小
• 放宽 GC 配置让 V8 自调内存区间，性能提升约 25%
• 改进已全球部署，影响所有 Workers

4. 优化 OpenNext 与 Next.js 性能
• 识别大量不必要的内存复制与 Buffer 分配
• 对流式响应 (Streaming) 做性能补丁，减少冗余数据操作
• 提交多个 PR 改进 OpenNext，包括缓存优化、流管道调度、正则重用等
• 针对 JSON.parse reviver 函数的低效执行向 V8 上游提交补丁，提升约 33% 性能

5. Streams 适配与数据传输改进
• Node.js 与 Web Streams API 转换时存在重复缓冲问题
• 改用原生 ReadableStream.from(chunks) 避免多层拷贝
• 调整 ReadableStream highWaterMark，使字节流读取更高效

6. Node.js 三角函数性能修复
• Node.js 未启用 V8 trig 函数快速路径
• Workers 已默认启用，因此跑分更好
• Cloudflare 提交 PR 修复 Node.js 构建配置，使全生态受益

7. 对基准测试方法的反思与改进
• 本地测试中网络延迟影响 CPU 计算评估
• Cloudflare 与 Vercel 所用硬件代际不同，会引入性能噪声
• Next.js 与 React SSR 测试中存在 force-dynamic 与 NODE_ENV 配置错误导致性能偏差
• 建议未来基准采用可控环境与更准确指标（TTLB 而非仅 TTFB）

8. 后续计划与开放协作
• 所有平台级修复已上线，无需用户手动更新
• 将继续优化 OpenNext 与 V8，推动上游框架改进
• Cloudflare 鼓励社区提交性能测试，团队会分析并修复问题
• 长期目标：通过改进开放源代码基础设施提升整个生态性能

author Kenton Varda

FixupX

DIŸgöd ☀️ (@DIYgod)

一周前 Vercel 发了篇博客指责竞争对手 Cloudflare Workers 性能差，今天 Cloudflare 回应了篇博客承认错误，解释了造成问题的各种技术细节，现在把性能也追上来了

太佩服这种在竞争对手面前勇于承认错误的勇气和快速透明解决问题的态度了，现在倒是显得 Vercel 小肚鸡肠了...

#优质博文 #性能优化 #CSS #Lighthouse #前端 #移动端适配
How to Optimize Viewport for Mobile for Faster Interactions | DebugBear

AI 摘要：文章围绕 Lighthouse 的新性能洞察 “Optimize viewport for mobile” 展开，分析移动端点击延迟 (300 ms) 的成因及对用户体验与核心网站性能指标 (Core Web Vitals) 的影响。通过剖析 Qatar Airways 的示例，作者说明 JavaScript 覆盖 viewport 设置会导致移动端性能劣化，并给出优化建议：应使用 <meta name="viewport" content="width=device-width, initial-scale=1"> 与 CSS 媒体查询来实现响应式布局，而非固定宽度或 JS 动态改写，从而避免延迟、提升 INP (Interaction to Next Paint)。最后介绍如何利用 DebugBear 持续监测网页性能与真实用户数据 (RUM)。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 概述：Lighthouse 新洞察“Optimize viewport for mobile”
• 取代旧的 <meta name="viewport"> 静态检查，采用动态分析判断页面是否真正移动友好
• 若检测失败，用户点击将产生高达 300 毫秒延迟，严重影响 INP

2. 300 毫秒点击延迟的背景与机制
• 浏览器历史上为保留“双击放大”功能而引入延迟
• 当网站非移动优化时，为兼顾可访问性，浏览器继续保留延迟
• 若 viewport 固定宽度（如 desktop 模式缩小版），则自动启用此延迟

3. 案例分析：Qatar Airways 官网 viewport 问题
• HTML 中声明了标准 viewport：width=device-width, initial-scale=1.0
• 但随后被 JS 在两个断点下改写为固定宽度 width=480
• 因此反过来触发非移动优化逻辑，导致交互延迟、INP 崩溃
• 使用 window.screen.width 而非 window.innerWidth，使得问题在 DevTools 模拟测试中难以察觉

4. 优化方案与最佳实践
• 使用标准 viewport 配置：<meta name="viewport" content="width=device-width, initial-scale=1">
• 避免使用固定宽度或在 JS 中修改 viewport
• 采用 CSS media queries 管理不同尺寸布局
• 通过 viewport 宽度进行断点分布，避免依赖物理屏幕宽度

5. 持续监测与性能保障
• 借助 DebugBear 可设定定期性能测试与性能预算 (performance budgets)
• 提供 Lighthouse 集成、图形对比、阈值报警等功能
• 支持真实用户监控 (RUM)，捕获真实点击延迟与 INP 细节
• 推荐结合模拟测试与生产环境监控，确保页面长期稳定

author DebugBear

Debugbear

How to Optimize Viewport for Mobile for Faster Interactions | DebugBear

Optimize viewport for mobile for faster interactions is a new Lighthouse performance insight that helps you detect viewports that are not optimized for mobile.

#优质博文 #React #性能优化 #前端 #工程化 #新动态
React Compiler 1.0 来辣！（虽然是 10.7 的消息但是我真的很忙才看到）
不过想尝鲜的应该早用上了（）
React Compiler v1.0 – React

AI 摘要：React 团队发布 React Compiler 1.0，这是一个稳定且可在生产环境中使用的构建时优化工具。它可自动分析 React 组件与 hooks 的数据流与可变性，实现自动记忆化，从而减少渲染次数并提升性能。该编译器适用于 React 与 React Native，与 Babel、Vite、Next.js、Expo 等生态紧密集成，并提供增量迁移指南和内置 lint 规则以强化 “Rules of React”。此次发布标志着历时近十年的工程成果落地，开启 React 新的性能优化时代。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 背景与发布概况
• React Compiler 1.0 正式发布，可在 React 与 React Native 中使用。
• 支持与 Expo、Vite、Next.js 等集成，默认在新项目中启用。
• 历经十年研发，从 Prepack 到 HIR（高阶中间表示 High-Level Intermediate Representation）的多次重构。

2. 编译器原理与功能
• React Compiler 作为构建时优化工具，在 Babel 插件阶段分析 AST（抽象语法树 Abstract Syntax Tree）。
• 通过自动记忆化优化组件与 hooks，可在条件渲染后仍实现 memoization。
• 拥有验证与诊断机制，通过数据流分析发现潜在违反 Rules of React 的代码。
• 与 eslint-plugin-react-hooks 集成，为开发者提供静态规则检测支持。

3. 安装与使用方式
• 支持 npm、pnpm、yarn 等安装方式：babel-plugin-react-compiler@latest。
• 改进了依赖分析算法，支持可选链与数组索引依赖。
• 提供 Playground 与文档供开发者测试优化效果。

4. 性能表现与生产验证
• 已在 Meta Quest Store 等大型应用投入使用。
• 实测初始加载与页面切换性能提升 12%，部分交互速度提升 2.5 倍。
• 性能提升同时保持内存中性，证明优化可靠。

5. 兼容性与 Lint 集成
• 兼容 React 17+，React 19 可直接启用编译器特性。
• ESLint 规则合并入 eslint-plugin-react-hooks@latest，替代独立插件。
• 强化了 setState、ref 等模式检测，防止渲染循环和 unsafe 渲染行为。

6. 与 useMemo / useCallback 的关系
• 默认由编译器自动进行 memoization，大多数情况下无需手动使用 useMemo/useCallback。
• 对需要精准控制依赖的场景仍建议保留或使用手动记忆化。

7. 新项目与渐进式迁移方案
• Expo SDK 54+ 默认启用编译器，Vite 与 Next.js 模板可直接启用。
• 提供渐进迁移指南，帮助旧项目分阶段集成 React Compiler。

8. swc 与构建工具支持
• 支持 Babel、Vite、Rsbuild 等构建工具，swc 插件仍在实验阶段。
• Next.js 15.3.1+ 可显著提升构建性能，Vite 通过 vite-plugin-react 启用编译器。
• 正在与 oxc 团队合作，为未来 rolldown 支持做准备。

9. 升级与版本管理建议
• 未来版本可能改变 memoization 策略，需保持端到端测试。
• 建议固定编译器版本（--save-exact）以避免意外行为变化。
• 强调遵守 Rules of React 以确保编译器优化安全有效。

author Lauren Tan, Joe Savona, Mofei Zhang

react.dev

React Compiler v1.0 – React

The library for web and native user interfaces

#优质博文 #前端 #性能优化 #图片优化 #CSS #course
很好很详细的一篇文章。
Your Images Are (Probably) Oversized

AI 摘要：本文指出大多数开发者在前端实现中无意间给用户加载了远大于实际需求的图片，这浪费了带宽与计算资源。作者以 NextJS <Image> 组件为例，解释 sizes 属性在响应式图片 (responsive images) 中的重要性，并系统讲解了 srcset、sizes、图片加载策略 (lazy vs eager loading)、设备像素比 (DPR) 等概念，最终提供完整的 “Cheat Sheet” 实用总结，帮助开发者高效地为不同屏幕设备提供最佳尺寸的图片。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]

1. 现实检视 (Reality Check)
• 使用高分辨率原图在小屏幕设备上会导致带宽浪费
• 即使使用 NextJS <Image> ，若缺少 sizes 属性，仍会传输超大图

2. sizes 属性的核心作用
• 明确规定图片渲染尺寸，帮助浏览器选择最佳匹配
• 设置 sizes="100vw" 显著压缩文件大小（最高可减少 25 倍）

3. 响应式图片的基本概念
• 像素限制**：超过屏幕物理限制的像素冗余无意义
• 引入 srcset 与 sizes：提供多种分辨率图片并让浏览器选择最优版本

4. 在复杂布局中的使用
• 当图片宽度并非等于屏幕宽度时，必须结合 sizes 指定实际渲染逻辑
• 支持多断点 (media queries)，可为不同 viewport 设置不同加载策略
• sizes="auto" 仅在懒加载 (lazy loading) 模式下生效，且浏览器兼容性有限

5. 图片加载策略
• loading="eager"：默认立即加载，适合首屏关键图片 (FCP)
• loading="lazy"：延迟加载，推荐用于非关键图片，高效节省资源

6. 设备像素比 (Device Pixel Ratio, DPR)
• 区分 **CSS pixel 与 device pixel
• 对应关系由 DPR 决定，例如 DPR=2 需要两倍分辨率图片
• srcset 支持 w 单位（推荐）和 x 单位（DPR 描述符），前者更适合响应式

7. 实用指南 (Cheat Sheet)
• 固定尺寸图片（如 icon）：设置固定 sizes，srcset 使用 DPR 描述符即可
• 响应式图片：
• 若为首屏内容：指定具体 sizes
• 若非首屏内容：加上 loading="lazy" 并优先用 sizes="auto, ...fallback"

8. 参考资料
• MDN Responsive Images
• HTML Living Standard
• Use density descriptors (web.dev)

author Henrique Yuji Rossetti Inonhe

Reason Under Pressure

Your Images Are (Probably) Oversized

Or why you should always set the `sizes` and `srcset` attributes on your (responsive) <img> tags.

#优质博文 #前端 #CSS #SVG #性能优化 #动画
Replace Your Animated GIFs with SVGs

AI 摘要：文章介绍了使用 SVG 动画 作为 GIF 动画 替代方案的优势。与 GIF 相比，SVG 动画文件体积更小、分辨率无损放大、与部分 CSS 媒体查询兼容，还可以直接嵌入 img 标签或作为背景图使用。但也存在局限：如不支持 prefers-reduced-motion、无法触发交互事件（hover/click）、限制 JavaScript 等。整体上，SVG 动画是 GIF 的现代替代，尤其适用于形状移动或变换类动画，性能和画质优势明显。

author John Rhea

Frontend Masters

Replace Your Animated GIFs with SVGs

No one loves dancing hamster GIFs more than I do. But all those animated frames can add up to files so large you don’t even see the dancing hamster. Your other tab has already loaded and you’ve followed the dopamine hits down another social media rabbit hole.

#优质博文 #性能优化 #CSS #font #前端
Should you preload fonts for performance?

AI 摘要：本文探讨了字体预加载 (font preload) 对网站性能的利弊。虽然预加载可以减少字体切换导致的双重渲染和版式抖动，但在 Chrome 等浏览器的机制下，可能会推迟 First Contentful Paint (FCP) 和 Largest Contentful Paint (LCP)。文章重点分析了预加载在不同场景下的风险与收益，并提出了实践建议：仅预加载关键字体、自托管字体、谨慎区分文本字体与图标字体。结论是：预加载并非万能方案，而应基于实际数据与场景做针对性优化。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 不预加载字体的情况
• 默认情况下，浏览器会先渲染系统字体，再替换为下载完成的 Web 字体，造成二次渲染与视觉抖动。
• 开发者常用预加载来避免多次绘制。

2. 预加载字体的权衡 (Trade-offs)
• 预加载强制浏览器提前下载字体，但可能延迟首屏渲染。
• 大多数现代浏览器支持 link rel="preload"，但行为存在差异。

3. 浏览器行为与渲染延迟
• Chrome 从 2023 年起更改机制：延迟首屏渲染 (first paint)，等待字体加载完成，从而减少布局错位。
• 这种优化虽然稳定首屏效果，却可能推迟 FCP 与 LCP。

4. Chrome 的预加载超时 (Preloading timeout)
• Chromium 设计了两个超时机制：
• 1500ms 自导航开始计算，避免过长等待。
• 100ms 自最后一个阻塞性资源加载完成开始计算，保证不会显著拖慢首屏渲染。

5. 预加载最佳实践
• 仅预加载首屏必需字体，避免过度使用。
• 始终加上 crossorigin 属性，即使同域下载。
• 尽量自托管字体，避免额外 DNS/TLS 开销。
• 优先预加载文本字体，不建议预加载图标字体（初期核心是可读内容，而非交互按钮）。

6. 结论 (Bottom line)
• 字体预加载可以优化体验，也可能破坏性能。
• 建议从小规模测试入手，基于真实用户数据决策，不盲目“一刀切”。

author Erwin Hofman

Erwin Hofman [sitespeed consultant]

Should you preload fonts for performance?

Preloading fonts can speed up or slow down your site. Learn how it affects FCP/LCP, how Chrome handles preloads, and when to use them for better performance.