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

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 生态。

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 鼓励社区提交性能测试，团队会分析并修复问题
• 长期目标：通过改进开放源代码基础设施提升整个生态性能

FixupX

DIŸgöd ☀️ (@DIYgod)

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

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

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)。

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 细节
• 推荐结合模拟测试与生产环境监控，确保页面长期稳定

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.

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

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 以确保编译器优化安全有效。

react.dev

React Compiler v1.0 – React

The library for web and native user interfaces

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

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)

Reason Under Pressure

Your Images Are (Probably) Oversized

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

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

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.

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)
• 字体预加载可以优化体验，也可能破坏性能。
• 建议从小规模测试入手，基于真实用户数据决策，不盲目“一刀切”。

AI 摘要：作者指出大多数站点把字体当装饰而非基础设施，导致体积臃肿、加载策略失当、CLS 爆炸与隐私合规风险；文章从历史与神话、浏览器渲染管线、现代 CSS 描述符、子集化与可变字体、系统栈与自托管、预加载与 Early Hints、文件格式与图标字体替代、非拉丁脚本与 Emoji、到工具审计与行动清单，给出“系统优先、仅用 WOFF2、内联 + 预加载、智能子集、设计回退、变量字体有的放矢、尊重全球脚本、持续测试”的全套可落地策略。

Jono Alderson

You’re loading fonts wrong (and it’s crippling your performance)

Fonts are one of the most visible, most powerful parts of the web. And yet: almost everyone gets them wrong.

AI 摘要：本文深入探讨了 React 的 useCallback（及部分 useMemo）在许多开发实践中被滥用、实际无效甚至带来额外复杂性的现象。作者指出，只有在需要“引用稳定性”（referential stability）时才有必要使用 memoization（记忆化），但多数情况下由于组件、props 或 state 的传递与依赖管理不当，memoization 实际无法带来性能提升，甚至反而让代码维护变得困难。作者以真实项目为例，分析了 memoization 的链式依赖是如何轻易被打破，进而推荐采用最新引用（Latest Ref Pattern）和即将推出的 useEffectEvent 方案来简化副作用依赖管理。

1. 记忆化的真正动机
• 只有两大理由：性能优化、降低副作用（effect）频繁触发。
• 核心是保持“引用稳定性”，以防止不必要的重新渲染或副作用。

2. 错误/无用的 useCallback 场景分析
• 如果目标组件本身未被 React.memo 包裹，useCallback/useMemo 完全无效。
• 组件自身如果不关心 props 的引用稳定性，多余的 memoization 没有任何作用，例如原生 button 的事件处理。
• 不应将传入的非原始 props 用作内部依赖（dependency array），因为无法控制其稳定性。

3. 真实工作中链式 memoization 失效的例子
• 多层 useMemo/useCallback、props 层层传递，一旦其中任意一环未 memoize，所有下游优化失效。
• 该问题不仅无法通过“层层 memoize”彻底修复，反而增加了理解和维护的负担，导致开发者难以溯源、清理无用优化。

4. 新的依赖管理模式推荐
• 最新引用（Latest Ref Pattern）：通过 useRef 保存当前最新值，通过 effect 始终同步，无需被动依赖。
• useEffectEvent（即将推出的 React 原生特性）：可直接在副作用 effect 内安全访问最新 props/state，无需显性依赖。

5. 结论与建议
• 仅在确有必要的场景使用 useCallback/useMemo，切勿滥用。
• 优先采用更健壮的依赖管理模式，减少人为记忆化的复杂性，提升组件可维护性和开发体验。

tkdodo.eu

The Useless useCallback

Why most memoization is downright useless...

AI 摘要：Chrome DevTools 139 版本专注于提升开发者体验、生产力及工具可靠性，修复了大量已知问题并增强了测试覆盖率。此次更新亮点包括在 AI 辅助中支持上传图片以提供视觉上下文，在 Network 面板中新增请求头列，以及对核心面板如 Performance、Sources 和 Elements 的持续改进，同时优化了各种调试和辅助功能，旨在提供更流畅、更稳定的开发工作流程。

1. 工具性能与稳定性改进
• 核心开发体验提升: 本版本优先提升产品卓越性，解决了大量已知问题，包括长期存在的视觉故障、可用性问题和设计不一致，将开放问题数量减少了 27%。
• 幕后测试覆盖率增强: 大幅提升了 DevTools 的测试覆盖率，调查并修复复杂的测试失败，并将测试相关问题减少了 54%，从而带来了更流畅、可靠和高效的日常调试和开发工作流程。

2. AI 辅助与智能功能
• AI 辅助支持图片上传: 在 AI 辅助面板中，现在不仅可以自动截屏，还可以上传任意图片到与 Gemini 的聊天中，为提示提供额外的视觉上下文。
• Google I/O 2025 亮点整合: 强调了在 Google I/O 2025 中展示的新 DevTools 功能，包括 Sources 面板连接工作区并保存修改、Gemini 驱动的 CSS 修改和保存、查询性能洞察、自动标注性能发现，以及新的性能洞察功能（重复 JavaScript 和遗留 JavaScript）。

3. 开发者工具面板更新
• Network 面板增强: 在 Network 面板中，现在可以右键点击请求表格中的列名，并选择多个请求头将其添加为列。
• Application 面板改进: 清除 IndexedDB 对象存储时，现在会显示确认对话框，以防止不可逆的操作。
• Sources 面板优化: Logpoints 和条件断点旁边的代码行徽章现在在悬停时会显示相应的日志消息或条件工具提示。
• Performance 面板新洞察: "Layout shift culprits" 洞察现在显示未设置大小的图片链接；"LCP request discovery" 洞察现在显示最早起始点之后的图片加载延迟；修复了部分用户本地存储的过期节流设置格式；事件日志过滤速度得到提升。
• 动画面板调整: 弃用了预览截图功能，因为点击预览动画组提供了类似且更好的体验。
• 辅助功能改进 (Accessibility): Sources > DOM 断点侧边栏（如果存在）添加了 aria-labels；修复了 Console 中 Live expression 文本字段内的 Shift + Tab 键盘导航问题；Settings 现在支持 Cmd/Ctrl + +/-/0 缩放快捷键；Elements > Styles 中的 CSS 提示和警告图标以及 Angle clock 现在可以通过键盘聚焦。

Chrome for Developers

What's new in DevTools, Chrome 139  |  Blog  |  Chrome for Developers

A more reliable and productive Chrome DevTools, support for arbitrary image upload in AI assistance for styling, and more.

AI 摘要：本文是作者 Nic Chan 撰写的新网站构建系列的一部分，重点介绍了如何采用现代字体回退方法来优化网站性能，尤其是减少累计布局偏移（CLS）。作者详细阐述了利用在线工具调整 CSS 字体属性（如 size-adjust 等）以实现无缝字体切换的实践，并分享了新增艺术作品和工作展示区的设计与实现，包括使用 View Transitions 和容器查询来提升用户体验。

• 作者 Nic Chan 分享了此篇草稿延迟发布的原因，并感谢读者的支持。
• 介绍了网站新增的拖放功能（桌面端）和改进的窗口分层效果，强调了渐进增强（progressive enhancement）的应用，即在确保无 JS 可用性的基础上，通过 JavaScript 增强用户体验。
• 字体优化与回退 (Font Optimization & Fallbacks): 讨论了网站在字体加载时遇到的累计布局偏移（CLS）问题，特别是自定义字体 W95FA 较窄的特性。作者希望实现像素字体和抗锯齿字体之间的无缝切换。他利用了“Modern Font Stacks”提供的字体堆栈，并发现了一个名为“Font Fallback”的工具，通过调整 size-adjust、ascent-override 等 CSS 属性来创建视觉上无缝的字体回退效果，甚至为此修改了工具的源代码。
• 艺术作品展示 (Artwork Showcase): 作者决定在网站中添加艺术作品展示区，尽管这与专业无关。他受到 Josh Crain 网站的启发，并利用 View Transitions API 实现了窗口最大化时平滑的缩放和标题淡入效果，配合少量 JavaScript 进行状态管理和回退。
• 工作项目展示 (Work Projects Showcase): 面对多种图片尺寸和可选标题的复杂布局挑战，作者采取了非对称设计，并限制了三种核心布局模式，避免每次新增案例都需编写新样式。此处完美运用了容器查询（Container Queries）来适应可用窗口空间内的尺寸变化，并结合 CSS Grid 实现有趣的重叠布局和纹理效果。

AI 摘要：这篇全面的、与平台无关的 2025 年前端性能优化清单，详细阐述了网站速度对于业务增长、用户参与度及 SEO 的关键作用。文章指导开发者如何利用各类工具衡量性能，并提供针对 HTML、CSS、JavaScript、图片与视频处理、字体优化以及主机与服务器配置等核心领域的实战建议。该指南还列举了多项快速提升性能的技巧，强调性能优化是一个持续的过程，对提供闪电般快速的用户体验至关重要。

1. 引言与重要性
• 性能与业务增长: 强调在当今快节奏的世界中，更好的性能直接转化为业务收益，如提升用户留存、转化率、搜索引擎排名（Core Web Vitals）和广告质量得分。
• 性能影响指标: 列举了网站停留时间、页面浏览量、跳出率、转化率/收入、用户满意度与留存、自然搜索流量、带宽/CDN 成本、广告质量得分等受性能影响的关键指标。

2. 性能测量
• 测量工具: 介绍了 Google PageSpeed Insights (PSI)、Chrome Lighthouse、WebPageTest、GTmetrix 以及 CrUX 数据等常用工具，用于获取实验室数据和真实用户数据。
• 测量方法: 建议结合使用实验室工具（获取受控基线）和真实用户监测（RUM，如 Web Vitals JS 库或 SpeedCurve 等平台），以便精准定位优化重点。

3. 前端性能优化清单
• 职责分配: 指出性能优化是整个开发团队的责任，包括平台选择、UX 设计和前端开发实现。
• HTML 优化: 强调优先渲染关键的 above-the-fold HTML 内容，清理冗余代码，启用压缩 (GZIP/Brotli)，正确加载外部文件（CSS 在 <head> ，JS 使用 async/defer），并避免不必要的 <iframe>。
• CSS 优化: 建议移除未使用的样式，模块化和拆分 CSS，避免 @import，使用关键 CSS (Critical CSS)，优化和压缩 CSS，预加载关键 CSS 文件，简化选择器，并利用现代 CSS 特性如 content-visibility: auto。
• JavaScript 优化: 提倡尽可能使用 HTML/CSS 替代 JS，避免过度使用框架/库，代码分割和延迟加载非关键 JS，预加载关键脚本，对脚本使用 async 和 defer 属性，压缩和摇树 (tree-shake) JS，保持依赖最新，移除未使用代码，并明智选择框架并利用其优化特性（如 Next.js 的混合渲染、Astro 的零 JS 默认）。
• 图片处理: 强调使用适当大小的图片，响应式图片 (<img srcset> 和 <picture>)，压缩和优化图片，预加载英雄图片 (<link rel="preload" as="image"> 和 fetchpriority="high"), 延迟加载 below-the-fold 图片 (loading="lazy"), 使用现代图片格式 (WebP/AVIF)，指定图片宽度和高度 (或 aspect-ratio) 以避免布局偏移，并利用框架或 CDN 进行图片优化。
• 视频处理: 建议压缩视频文件，选择现代视频编解码器/格式 (WebM/AV1)，使用正确的 preload 值，延迟加载 below-the-fold 视频，如果不需要则去除音频，考虑流媒体传输长视频，并优化第三方视频嵌入。
• 字体优化: 限制字体家族和字重数量，使用现代字体格式 (WOFF2)，预连接到字体主机源，使用 font-display: swap 避免文本不可见 (FOIT)，通过字体度量调整避免加载时的布局偏移，并考虑使用可变字体。
• 主机/服务器优化: 强调使用 HTTPS (TLS)，最小化 HTTP 请求，使用 HTTP/2 或 HTTP/3，使用 CDN，启用服务器端缓存，优化服务器处理时间 (TTFB 目标 < 200ms)，以及尽可能提供静态页面。

4. 快速提升技巧
• 避免布局偏移: 确保为动态内容预留空间，以减少累计布局偏移 (CLS)，可使用明确的 width/height 或 aspect-ratio，以及骨架屏占位符。
• 使用优先级提示: 利用 fetchpriority="high" 和 importance 属性告知浏览器哪些资源最重要，从而优化网络带宽分配。
• 最小化外部 HTTP 请求和第三方脚本: 审查并移除不必要的第三方脚本和资源，对于必需的脚本可考虑延迟加载。
• 保持单一协议: 确保所有资源都通过 HTTPS 加载，避免混合内容。
• 设置合适的缓存头: 利用 HTTP 缓存，为静态资源设置长 max-age，并通过文件名哈希进行缓存 busting。
• 预取可能访问的页面: 使用 <link rel="prefetch"> 或框架特定预取机制，在浏览器空闲时预加载用户可能接下来访问的页面。
• 利用 Service Workers 进行缓存: 部署 Service Worker 拦截网络请求，实现离线缓存和更快的后续加载。

5. 总结与展望
• 持续优化: 强调 Web 性能是一个持续的旅程，每次微小的改进都能带来显著的用户体验和业务成果。
• 性能与整体成功: 指出速度是网站成功的基础，它能确保优秀的内容、营销、SEO 和设计得以充分展现。
• 行动号召: 鼓励团队采纳“性能优先”的心态，持续优化网站速度。

AI 摘要：本期《Frontend Focus》第702期聚焦前端领域的最新动态、实用工具、深度文章与观点。内容涵盖SVG基础入门、HTML 2025年度调查、AI辅助调试、可访问性标准解读、CSS动画、性能优化、前端框架更新等多个方面，为开发者提供了丰富的学习资源和行业洞察，同时介绍了多款前端实用工具和库，以及一些趣味简讯和广告。

1. 社区动态
• HTML 2025 年度调查启动：第三届年度 HTML 调查，旨在了解开发者如何使用 Web 平台日益增长的能力，其结果将直接影响明年 Interop 项目的优先级。
• WCAG 纯英文版：让无障碍标准易于理解：一个可搜索的资源，为官方 Web 内容无障碍指南（WCAG）提供了一个初学者友好的指南，使其更易于消化。
• Firefox 141 发布：新版本增加了垂直标签页和 AI 标签组织智能功能。
• GitHub 支持欧盟主权技术基金：GitHub 正在倡导设立一项欧盟主权技术基金。
• 为什么不信任 WCAG 2.2 以及对 3.0 的期望：Daniel Schwarz 提出了他对 WCAG 2.2 的担忧，并探讨了 WCAG 3.0 如何改进这些问题。
2. 文章、观点与教程
• 时间不多，范围却很多：滚动驱动动画的 animation-ranges 速查表 —— 一篇关于滚动驱动动画及其可用选项的入门指南。
• 小屏幕，大影响：为功能手机开发 Web 应用的被遗忘艺术：探讨了功能手机在2025年仍有意义的原因，以及如何为这类设备构建和发布Web应用。
• Tailwind 是“最糟糕的综合体”：一篇观点文章，认为 Tailwind 是 “将 CSS 和现代 Web 开发中所有糟糕之处结合在一起的令人遗憾的倒退”。
• 2025 年前端性能检查清单：一份高层次的清单，列出了创建快速、高效 Web 应用时需要牢记的事项。
• 利用 Web Speech API 让你的网站开口说话：一种简单直接的方法，为网站添加语音功能。
• 糟糕导航的隐性成本：信息架构如何直接影响业务指标：探讨了信息架构对业务指标的直接影响。
3. 开发工具与资源
• Glass3D 生成器：一个生成 3D 玻璃效果的 CSS 工具：一个允许编辑背景滤镜设置、颜色和纹理的工具，并实时预览效果。
• Astro 5.12 发布：新版本特性包括升级的 Netlify 开发体验、内容加载器中的 TOML 支持等。
• Tiptap v3：无头富文本编辑器框架：为构建强大的富文本编辑体验提供了基础，v3 版本包含大量开发者体验改进，如动态UI的卸载和重新挂载、创建自定义视图的 “Markviews”、SSR 模式等。
• macOS 光标 PNG 图片集合：一个提供各种 macOS 光标 PNG 图片的网站。

AI 摘要： 本期《Frontend Focus》（第 701 期，2025 年 7 月 16 日）涵盖了前端开发的多个热点话题，包括在严格约束下创新的项目案例、Apple 在浏览器引擎选择上的争议、WebAssembly 的广泛应用、CSS 新特性和工具的使用，以及一系列实用的前端工具和资源。文章还提到 Mozilla 即将为 Firefox 添加 WebGPU 支持，并探讨了 AI 对开源开发者生产力的影响，旨在为前端开发者提供最新的技术动态和实用技巧。

1. “I’m More Proud of These 128 Kilobytes Than Anything I’ve Built Since”：通过一个项目案例，Mike Hall 展示了在带宽和处理能力等严格约束下的创新设计，提醒开发者考虑更广泛的用户需求，设计更具包容性的产品。 #性能优化
2. “Apple’s Browser Engine Ban Persists, Even Under the DMA”：Open Web Advocacy 指出 Apple 在 iOS 浏览器引擎选择上未能有效遵守欧盟《数字市场法案》（DMA），存在阻碍竞争的问题。
3. “WebAssembly: Yes, But for What?”：Andy Wingo 在 ACM Queue 上分享了 WebAssembly 在浏览器和服务器端的广泛应用，探讨其如何逐渐渗透到各个领域。 #WASM
4. 简讯（IN BRIEF）：
• Mozilla 将在 Firefox 141 中添加 WebGPU 支持（初期仅限 Windows，后续扩展至 macOS 和 Linux）。
• 一份报告分析了 AI 对开源开发者生产力的影响。
• Firefox 团队寻求用户对 Mozilla 浏览器的真实反馈。
• Andy Bell 分享了一个 CSS 代码片段，为锚定 URL 添加必要的空间，提升用户体验。
5. 文章、观点与教程（Articles, Opinions & Tutorials）：
• CSS 行长度设置 - Daniel Schwarz 介绍如何利用 clamp() 和 calc() 等工具更轻松地设置文本行长度，并展望未来发展。
• 纯 HTML 和 CSS 编写 - Joel Dare 分享为何在 2025 年仍坚持使用纯 HTML 和 CSS。
• ARIA 角色与属性使用 - Michael Beck 讲解如何有效使用 ARIA 角色和属性。 #WCAG
• 滚动行为设计 - Megan Chan 探讨何时应保存用户的滚动位置。
• AI 与网页设计 - Noah Davis 认为模板而非 AI 才是网页设计的真正“杀手”。
6. 工具、代码与资源（Tools, Code & Resources）：
• SveltePlot - Gregor Aisch 开发的 Svelte 可视化框架，基于 D3，支持多种图表类型。
• Eleventy LibDoc - IT Automotive Design System 提供的一个 Eleventy 起步项目，用于创建美观直观的文档站点。
• SplitThing - Florian Reintgen 开发的工具，可将图像分割为自定义网格并下载。
• Chili3D - xiange chen 开发的基于 Web 的 3D CAD 应用，利用 WebAssembly 和 Three.js 实现接近原生性能。 #webgl
• designtokens.fyi - Design Systems House 提供的设计令牌术语词汇表，包含 33 个相关术语解释。
• Check Server-Side Rendering (SSR) - Punit Sethi 开发的工具，帮助检查网页元素的服务器端渲染情况。
• FontGen - 智能字体配对工具，包含 1000+ 字体（需注册）。
• Pandabox - StJohn 开发的 Astro 轻量级灯箱和画廊组件。

Medium

I’m more proud of these 128 kilobytes than anything I’ve built since

I’m more proud of these 128 kilobytes than anything I’ve built since I once worked with a UI designer who insisted it was impossible to create a product that was both within the Web Content …

AI 摘要：本文详细介绍了在 Three.js 中使用实例化（Instancing）技术来优化性能，同时渲染多个对象。通过实例化，可以将多个共享相同几何形状和材质的对象合并为一个绘制调用（Draw Call），显著减少 CPU 到 GPU 的通信开销，从而提升渲染效率。文章结合 React Three Fiber 和 drei 库，提供了从基础实例化到复杂场景（如森林渲染）的完整教程，涵盖了自定义着色器、实例属性调整以及多种实例集的实现方法。

1. 引言：介绍了实例化的基本概念及其性能优势。实例化允许在一次绘制调用中渲染多个共享几何形状和材质的对象，例如渲染森林中的树木、岩石和草地时，可以大幅减少绘制调用次数，提升性能。
2. 基础实例化：以渲染一千个盒子为例，展示了传统方法与使用 drei/instances 的实例化方法的对比。传统方法需要一千次绘制调用，而实例化方法仅需一次，显著优化了性能。
3. 多组实例化：讨论了如何使用 drei 的 createInstances() 函数创建多个实例集，例如同时渲染盒子和球体（一千个盒子与一千个球体），最终仅需两次绘制调用。
4. 自定义着色器的实例化：讲解了如何为实例化对象创建自定义着色器材料，包括顶点动画（如 blob 效果）。通过 instanceMatrix 属性解决位置重叠问题，确保每个实例有独立的变换。
5. 调整实例属性：介绍了如何通过 InstancedAttribute 为每个实例设置自定义属性，例如为 blob 动画添加时间偏移（timeShift），实现独立动画效果。
6. 创建森林场景：以渲染一千棵树为例，展示了如何加载 3D 模型并应用实例化技术，最终仅用三次绘制调用完成整个森林场景（包括天空盒和地面）。还通过随机位置、高度和旋转增加场景多样性。
7. 进一步阅读：提及了未深入探讨但值得关注的主题，如批量网格（Batched Meshes）、骨骼动画（Skeletons）以及变形（Morphing）与批量网格的结合。

AI 摘要：本文详细介绍了 Chrome 在 Apple Silicon Macs 上推出的 Skia 新光栅化后端 Graphite。Graphite 是一个面向未来的图形渲染技术，显著提升了 Chrome 在 Motionmark 1.3 测试中的表现，同时为未来的图形改进奠定了基础。通过支持现代图形 API（如 Metal、Vulkan 和 D3D12）、多线程设计以及深度测试等创新技术，Graphite 不仅提高了渲染性能，还优化了用户体验，减少了滚动卡顿和页面加载等待时间。

1. Skia 在 Chrome 中的历史：
• 介绍了 Skia 作为 Chrome 图形渲染核心的历史，从最初的性能问题到引入 GPU 加速后端 Ganesh。
• Ganesh 虽性能优异，但因其以 OpenGL 为中心的设计，难以充分利用现代图形 API 的优势，因此团队开发了 Graphite。

2. Graphite 的成果：
• 在 Macbook Pro M3 上，Motionmark 1.3 得分提升近 15%。
• 优化了真实世界指标，如交互到下一帧时间（INP）、最大内容绘制时间（LCP）、图形流畅度（掉帧百分比）以及 GPU 内存使用等。

3. Graphite 与 Ganesh 的区别：
• 现代图形 API：Graphite 利用 Chrome 的 WebGPU 实现 Dawn，支持 Metal、Vulkan 等现代 API，减少维护负担并提升多线程和 GPU 计算能力。
• 2D 深度测试：通过深度测试减少过度绘制（overdraw），优化不透明和半透明对象的渲染顺序，提升性能并降低移动设备功耗。
• 多线程设计：Graphite 的 API 支持多线程，利用独立记录器（Recorders）在多线程上生成记录（Recordings），减轻主线程负担，减少卡顿和延迟。
• 性能悬崖与管线编译：Graphite 减少渲染管线数量，避免因管线编译导致的卡顿，确保复杂内容与简单内容渲染效率一致。

4. 未来计划：
• 多线程光栅化：计划将光栅化任务分配到多线程，进一步提升性能。
• 减少简单内容的 GPU 内存：通过重新发布记录（Recordings）优化滚动，减少不必要的 GPU 内存分配。
• GPU 计算路径光栅化：探索 GPU 计算路径光栅化技术，提升视觉质量和性能，替代传统的 MSAA 和 CPU 光栅化。

AI 摘要：本文详细介绍了 WebGL 性能优化的多种方法，涵盖了从性能瓶颈的识别到具体的技术实现，旨在帮助开发者提升 WebGL 应用的渲染效率。文章从 CPU 和 GPU 的性能测试入手，探讨了纹理优化、绘制调用减少、Shader 逻辑优化、三角形数量削减、内存传输优化等多个方面，提供了大量实用技巧和具体案例，适合对 WebGL 性能优化感兴趣的前端开发者深入学习。

• 性能瓶颈识别与测试
• 介绍了如何通过降低 CPU 或 GPU 的时钟频率来测试性能瓶颈，帮助开发者定位问题根源。
• 纹理优化
• 建议减少 canvas 尺寸或使用低分辨率纹理来测试纹理受限问题。
• 纹理过滤模式中，gl.NEAREST 速度最快但效果块状，gl.LINEAR 因取平均值而模糊。
• 推荐使用 Mip 映射技术优化纹理贴图效果。
• 纹理长宽建议为 2 的幂，采用纹理压缩（如 ETC 格式）减少数据量，使用 PBO 提升纹理上传速度，以及通过纹理合成减少加载次数。
• 上下文与 Program 管理
• 讨论了 WebGL 上下文丢失的处理方法。
• 建议避免频繁切换 Program，减少在 Shader 中使用 if-else 语句，因其会破坏 GPU 的并行计算（Wavefront 机制）。
• 绘制调用优化
• 使用 drawElements() 的 gl.TRIANGLE_STRIP 结合退化三角形，比 drawArrays() 的 gl.TRIANGLES 更节省内存。
• 减少 drawArrays() 和 drawElements() 调用次数，避免从 GPU 读回数据（如 gl.getError()、gl.readPixels()），以优化流水线性能。
• 使用 WebGL Inspector 工具查找冗余调用，减少状态变更操作（如 gl.enable()）。
• 顶点与模型优化
• 顶点数据按数组顺序组织，避免乱序以提高缓存命中率。
• 使用 LOD（细节层次）技术简化模型，根据距离动态调整细节。
• Shader 逻辑优化
• 避免在 Shader 中使用逻辑判断（如 if-else），因其破坏 GPU 并行度；提供替代方案，如使用 step 函数优化逻辑表达。
• 三角形数量优化
• 通过空间分割（如八叉树、四叉树）剔除不可见物体。
• 使用遮挡检测技术（如硬件遮挡查询）避免渲染被遮挡物体。
• 动态调整三角形数量（如 LOD 技术）。
• 使用 GL_TRIANGLE_FAN 或 GL_TRIANGLE_STRIP 替代 GL_TRIANGLES 以重用顶点。
• 采用 glDrawElements 的索引方式减少三角形数量。
• 内存传输优化
• 尽可能使用 VBO/VAO 减少数据传输。
• 在 OpenGL ES 3.0/WebGL 2.0 中利用 Transform Feedback 进行 GPU 通用计算。
• 通过批次合并和 Instance 特性优化多物体渲染效率。

AI 摘要：本文系统介绍了中文字体网络优化的全流程方案，涵盖字体分包、格式选择、CDN 加速、协议优化、代码级调优等核心环节，通过WOFF2格式切割、高并发 CDN、HTTP/2/3协议、Preconnect 预连接、极小量级加载及CLS布局偏移修复等技术，显著提升网页加载速度与用户体验。

1. 字体分包优化
• 工具推荐：使用 cn-font-split 插件或 vite-plugin-font （适配 Vite / Rspack / Next.js ）
• WOFF2 格式优势：
• 默认采用 Brotli 压缩算法，比 WOFF 节省30%体积
• 支持浏览器广泛，现代项目首选格式
• 代码示例展示自动转换 TTF / OTF为分片 WOFF2

2. 分包切割策略
• 分片大小：建议 70KB / 片，平衡加载速度与命中率（1.5 - 2 秒完成加载）
• 动态加载：按需加载分片，避免全量下载

3. 字体下载优化
• CDN关键要求：
• 必须支持高并发（国内 CDN 可达 1 秒内加载）
• 推荐开启 HTTP / 2 / 3 协议提升并发能力
• 缓存策略：
• 字体分片设置永久缓存（哈希命名防冲突）
• CSS 文件需谨慎设置缓存时效

4. 前端代码优化
• Preconnect 预连接：提前建立 CDN 预连接节省时间
• 禁用 Preload 陷阱：避免破坏按需加载机制
• 极小量级优化：
• 通过 vite-plugin-font 扫描代码用字范围
• ?subsets 参数实现字符级摇树优化

5. 布局偏移(CLS)修复
• 问题根源：Fallback 字体与目标字体度量差异导致重排
• 解决方案：
• 使用 ascent-override 等 CSS 属性校准 Fallback 字体度量
• 工具推荐：fontaine 库（中文适配有限）或 vite-plugin-font 1.2.0+ 自动计算

扩展资源
https://web.dev/font-best-practices/
https://web.dev/reduce-webfont-size
https://web.dev/optimize-webfont-loading/

AI 摘要：本文通过对比 Tailwind 和 Linaria 在初始加载性能（LCP）和交互性能（INP）上的表现，发现 Tailwind 虽能减少 CSS 体积（-13%）但增加了 HTML/JS 大小（HTML 最高 +162%），而实际初始加载性能差异可忽略不计。然而，Tailwind 的通用选择器（如 * 和伪元素）导致交互性能下降（如下拉菜单延迟增加 50%）。结论：两者性能差异对多数项目影响微小，框架选择应优先考虑开发体验而非性能优化。

Developerway

Tailwind vs Linaria: Performance Investigation

Investigating performance of Tailwind vs Linaria frameworks, with a focus on initial load and interaction performance.