00:00:00
⚡ 卷④ 性能与可访问性
20 条。适用场景：页面慢了，或者无障碍检查不过。
「要点」「我的补充」为本人撰写，非原文摘录。
一、核心指标与图片优化
61. Fix your website's Largest Contentful Paint by optimizing image loading
来源：MDN Blog · developer.mozilla.org 读它解决什么：LCP 指标不合格，而首屏最大元素通常是一张图。
要点
- LCP 衡量视口内最大内容元素的渲染完成时间，多数站点这个元素就是首屏主图
- 优化链条有四段：发现时机（浏览器多早知道要加载它）、传输大小、解码耗时、渲染阻塞
- 关键手段是
fetchpriority="high"、preload、正确的srcset/sizes，以及不要给首屏图加loading="lazy"
我的补充：首屏图加 loading="lazy" 是常见的自伤——懒加载让浏览器晚一步才开始请求，LCP 直接变差。规则是：首屏图片显式 loading="eager" 加 fetchpriority="high"，视口以下的才 lazy。另外 CSS 背景图的发现时机比 <img> 更晚（要等 CSSOM 构建完），首屏主视觉尽量用 <img> 而不是 background-image。这个博客的壁纸是 banner 背景，属于可接受的取舍，因为它不是内容主体。
62. Fixing your website's JavaScript performance
来源：MDN Blog · developer.mozilla.org 读它解决什么：交互卡顿、输入延迟，需要系统地定位 JS 侧问题。
要点
- 关键指标是 INP（Interaction to Next Paint），衡量交互到下一帧绘制的延迟
- 长任务（超过 50ms 的主线程任务）是卡顿的直接原因，需要拆分或让出
- 让出主线程的手段：
scheduler.yield()、requestIdleCallback、把计算搬进 Worker
我的补充：定位长任务用 DevTools Performance 面板，找红色三角标记。最常见的三个来源：一是事件处理里做了大量同步计算（排序、过滤大数组）；二是一次性渲染几千个 DOM 节点（该用虚拟列表）；三是第三方脚本（统计、客服组件）——这个用 Lighthouse 的 "Reduce the impact of third-party code" 一眼就能看到。第三方脚本加 defer 或延迟到交互后加载，通常是收益最大的一刀。
63. Monitoring and optimizing website performance
来源：MDN Blog · developer.mozilla.org 读它解决什么：实验室数据（Lighthouse）和真实用户数据不一致，该信哪个。
要点
- 实验室数据（lab）可复现、适合回归检测；真实用户监控（RUM）反映实际体验，但有噪声
- 两者都需要：RUM 发现问题，lab 用来复现和验证修复
- RUM 的关键是看分位数（p75）而不是平均值
我的补充：Core Web Vitals 的官方判定用的就是 p75——75% 的访问要达标。看平均值会严重低估问题：一半用户 0.5 秒、四分之一用户 8 秒，平均看着还行但那 25% 的人已经走了。免费的 RUM 方案：web-vitals 库上报到自己的接口，或者直接看 Chrome UX Report（CrUX）的公开数据。静态博客用 Cloudflare Web Analytics 也能拿到基础 vitals。
64. New to the web platform in April
来源：web.dev · web.dev 读它解决什么：跟进平台侧新增的性能相关能力。
要点
- 性能相关的平台能力更新往往比框架优化收益更大，因为是浏览器原生实现
- 值得关注的类别：调度 API、资源提示（
preload/preconnect/prefetch）、渲染控制（content-visibility） - 新能力多数是渐进增强，不支持时无害
我的补充：content-visibility: auto 是被低估的一条——长页面上跳过视口外元素的渲染，对文章列表、长文档效果显著，加一行 CSS 就有。代价是需要配 contain-intrinsic-size 给个高度估值，否则滚动条会跳。资源提示里 preconnect 用于第三方域（提前建 TCP + TLS），比 prefetch 更常用也更安全。
65. New to the web platform in March
来源：web.dev · web.dev 读它解决什么：继续跟进平台能力，尤其是与渲染性能相关的。
要点
- 月度汇总里性能相关条目通常集中在渲染与加载调度
- 需要区分"新语法糖"与"真能改善指标的能力"
- 对已有项目，改造成本与收益要一起算
我的补充：判断一个新性能特性值不值得上，问三个问题：当前瓶颈是不是它解决的那个（先测再改）、不支持的浏览器占比多少、改造需要动多少代码。多数情况下把图片优化好、第三方脚本延后加载，收益就超过大部分新特性。别本末倒置。
66. New to the web platform in February
来源：web.dev · web.dev 读它解决什么：跟进平台能力更新的第三个月度样本。
要点
- 连续跟进几个月能看出趋势：哪类能力在集中推进（近年是 CSS 与滚动、视图过渡、AI 相关 API）
- 趋势判断比单个特性更有价值，能指导学习投入方向
- 也能看出哪些方向进展缓慢
我的补充：这类汇总的正确读法是扫标题不读全文，只对与自己当前项目相关的深入。我个人的做法是维护一个"技术雷达"笔记，把看到的新能力按"现在能用/明年能用/长期观察"三档记下来，需要时回查。比试图记住所有细节现实得多。
67. February 2026 Baseline monthly digest
来源：web.dev · web.dev 读它解决什么：从可用性角度确认某个性能特性能不能上生产。
要点
- Baseline 状态变更是"可以规划使用"的信号
- 性能特性的可用性判断尤其重要：降级路径要么无害，要么需要额外代码
- 关注从 Newly 升到 Widely available 的条目
我的补充：性能特性的好处是降级通常无害——不支持 content-visibility 的浏览器只是没有优化，不会坏掉。这类特性可以比功能性特性更激进地采用。反之涉及交互和布局的新特性必须配降级，否则老浏览器上是破的。判断标准就这一条：不支持时会不会出错。
68. March 2026 Baseline monthly digest
来源：web.dev · web.dev 读它解决什么：持续跟进 Baseline 状态，作为技术选型的依据。
要点
- Baseline 数据也被工具链消费：ESLint 插件、浏览器兼容检查可以按 Baseline 目标报错
- 这让"团队约定用哪一档能力"变成可自动化的规则
- 比人工 code review 判断兼容性可靠
我的补充：值得配进项目：eslint-plugin-compat 或 Baseline 相关的 lint 规则，把目标定在 Widely available。这样新人写了超前的 API，CI 会直接拦住，不必靠 review 时有人恰好知道。同类工具还有 stylelint 的兼容性插件管 CSS 侧。配置一次长期受益。
69. January 2026 Baseline monthly digest
来源：web.dev · web.dev 读它解决什么：年初的 Baseline 状态快照，适合做年度技术规划参考。
要点
- 年初盘点适合决定"今年团队要开始用哪些新能力"
- 与 Interop 年度目标结合看，能预判年底的可用性
- 对长周期项目，可以据此设计代码的扩展点
我的补充：实践建议：每年做一次前端技术栈体检，检查项包括"哪些 polyfill 可以删了""哪些第三方库可以换成原生""浏览器支持目标要不要上移"。这件事不做的话，项目里的历史包袱只会累积。花半天，通常能减掉可观的依赖体积。
二、DevTools 与调试
70. What's new in DevTools (Chrome 149)
来源：Chrome for Developers · developer.chrome.com 读它解决什么：DevTools 的新能力你多半没跟进，而它们能省很多时间。
要点
- DevTools 的更新常包含性能面板的分析能力增强、CSS 调试工具、网络请求覆写
- Performance 面板的洞察（Insights）会直接指出问题原因，不必自己读火焰图
- 本地覆写（Overrides）能在不改代码的情况下验证修复
我的补充：三个被低估的功能。一是本地覆写：直接在 DevTools 里改线上文件并持久化，验证修复不用重新部署。二是 Network 面板的请求阻断，测第三方脚本挂掉时页面是否还能用。三是 Rendering 面板里的 Paint flashing 和 Layout Shift Regions，排查 CLS 时肉眼可见哪块在跳。这三个都不需要装任何插件。
71. New in Chrome 149
来源：Chrome for Developers · developer.chrome.com 读它解决什么：了解 Chrome 版本级的能力变更，包括可能影响现有站点的行为调整。
要点
- 版本公告里除了新特性，还包含弃用与移除，后者才是可能弄坏现有站点的部分
- 涉及默认行为变更时（比如某个头的默认值、某个 API 的权限要求）需要主动检查
- Origin Trial 里的能力可以提前试用但不能依赖
我的补充：弃用公告要认真看——Chrome 移除能力前会有几个版本的过渡期，控制台会打印弃用警告。定期在 DevTools Console 里看有没有黄色的 deprecation 警告，比等站点坏掉再查好得多。Origin Trial 的能力有到期时间，试用代码里务必留降级路径，试用期结束会直接失效。
72. Chrome 150 beta
来源：Chrome for Developers · developer.chrome.com 读它解决什么：提前一个版本知道即将到来的变更。
要点
- Beta 公告给出下一个稳定版的内容，留出适配窗口
- 对涉及安全策略、Cookie 行为、权限模型的变更尤其要提前验证
- 用 Chrome Beta/Canary 跑一遍关键路径成本很低
我的补充：值得建立的习惯：关键业务流程在 Chrome Beta 上定期走一遍。历史上多次出现 Chrome 收紧策略（第三方 Cookie、混合内容、自动播放）导致站点部分功能失效，提前一个版本发现就能从容处理。个人博客风险低，但如果有登录、支付、iframe 嵌入这类功能就该测。
73. Introducing the Safari MCP server for web developers
来源：WebKit Blog · webkit.org 读它解决什么：想让 AI 工具能读取 Safari 的实际渲染与调试信息。
要点
- MCP（Model Context Protocol）让外部工具向 AI 提供结构化上下文，这里是把浏览器调试信息暴露出来
- 对开发者的意义是 AI 辅助调试可以基于真实运行时状态，而不是只看代码
- Safari 特有问题的排查成本可能因此降低
我的补充：Safari 的兼容性问题历来最难查——很多人没有 Mac 设备，只能靠猜。这类工具如果成熟，能缓解这个痛点。当下的现实方案仍然是：用 BrowserStack 之类的服务，或者至少在 iOS 真机上开 Web Inspector（设置里打开"网页检查器"，用 Mac 的 Safari 连）。iOS 上所有浏览器都用 WebKit 内核，所以测 Safari 等于测 iOS 全部。
74. WebKit Features for Safari 26.6
来源：WebKit Blog · webkit.org 读它解决什么：确认某个特性在 Safari 上到底哪个版本开始能用。
要点
- Safari 的版本发布说明是判断"这个特性 iOS 上能不能用"的一手来源
- Safari 与 iOS 版本绑定较紧，用户升级节奏影响可用性
- WebKit 的实现细节有时与其他引擎有差异，即使都"支持"
我的补充：做移动 Web 必查这个。两个长期存在的实践要点：一是 iOS 用户的浏览器版本跟随系统，所以支持面取决于 iOS 版本分布，通常比 Chrome 更新更快也更集中；二是**"支持"不等于"行为一致"**，Safari 在滚动、输入法、视频自动播放上有不少特有行为，功能测试不能只在 Chrome 做。
75. Release Notes for Safari Technology Preview 250
来源：WebKit Blog · webkit.org 读它解决什么：跟进 WebKit 最前沿的实现进展。
要点
- Technology Preview 是 Safari 的实验版本，能看到尚未进入正式版的能力
- 对判断"Safari 会不会支持某特性"有参考价值——出现在 STP 里通常意味着在路上
- 也会列出 bug 修复，可以确认自己遇到的问题是否已修
我的补充：实用场景是确认某个 Safari bug 是否已在修。遇到疑似浏览器 bug 时，先搜 WebKit Bugzilla 和 STP 发布说明，能避免花时间给一个已知问题写 workaround。如果确实是新 bug，报上去——WebKit 团队对有最小复现的报告响应还不错。
三、可访问性：做对比做多重要
76. Blocked aria-hidden: The Warning is Right, and Every Fix You've Found is Wrong
来源：CSS-Tricks · css-tricks.com 读它解决什么：控制台报 aria-hidden 相关警告，网上搜到的修法可能都不对。
要点
- 核心问题是给包含可聚焦元素的容器加
aria-hidden="true"：视觉上隐藏了但键盘仍能 Tab 进去，屏幕阅读器用户会聚焦到一个"不存在"的元素 - 常见的错误修法是加
tabindex="-1"，这治了症状但破坏了其他行为 - 正确方向是用
inert属性，或者干脆不渲染该内容
我的补充：inert 是这个问题的标准解——它同时移除可聚焦性、点击和辅助技术可见性，语义正好是"这块内容暂时不参与交互"。模态框打开时给背景加 inert 就对了（<dialog showModal()> 会自动做这件事）。记住这条判据：aria-hidden 只该用在纯装饰性、不含交互元素的内容上，比如装饰图标。
77. The Siren Song of ariaNotify()
来源：CSS-Tricks · css-tricks.com 读它解决什么：想给屏幕阅读器主动播报消息，评估新 API 是否是好办法。
要点
- 主动播报的传统做法是 live region（
aria-live），行为由辅助技术决定 - 直接命令式播报的 API 看起来更方便，但会绕过用户对辅助技术的配置与控制
- 可访问性的原则是提供语义、让辅助技术决定呈现，而不是替用户决定
我的补充：这条讲的是可访问性里一个反复出现的教训：方便开发者的 API 常常损害用户控制权。当下的正确做法仍是 live region：给一个 <div aria-live="polite"> 容器，往里写文本即可。polite 等用户空闲时播报，assertive 立即打断——除了真正紧急的错误，一律用 polite，滥用 assertive 会让屏幕阅读器用户无法正常操作。
78. Creating Memorable Web Experiences: A Modern CSS Toolkit
来源：CSS-Tricks · css-tricks.com 读它解决什么：想做有质感的交互效果，同时不牺牲可访问性和性能。
要点
- 现代 CSS 能力（滚动动画、视图过渡、锚点定位）让效果实现成本大幅下降
- 但效果的边界条件更多：减少动画偏好、键盘操作、低端设备性能
- 好效果的判据是"关掉它之后功能依然完整"
我的补充：这个判据值得记住——所有视觉增强都应该是可选的。检查方法：在 DevTools 里模拟 prefers-reduced-motion: reduce，再用键盘走一遍全流程，如果都正常，你的效果就是健康的。这个博客的动态壁纸、缓动动画都属于纯装饰，关掉不影响读文章，是合适的用法。
79. Reminder that system-ui is well supported
来源：Frontend Masters · frontendmasters.com 读它解决什么：字体栈该怎么写，能不能少加载自定义字体。
要点
system-ui直接用操作系统 UI 字体，零下载、渲染即刻可用- 用系统字体的界面在各平台上更"原生"，也避免了字体加载导致的布局跳动
- 局限是设计一致性：不同平台看起来不同
我的补充：UI 部分用 system-ui、正文才考虑自定义字体是很好的折中。中文场景要注意字体栈要写全：system-ui, -apple-system, "Segoe UI", "PingFang SC", "Microsoft YaHei", sans-serif——只写 system-ui 在部分 Windows 环境下中文回退不理想。自定义中文字体动辄几 MB，务必做子集化（fonttools 的 pyftsubset），否则得不偿失。
80. Ending Responsive Images
来源：Frontend Masters · frontendmasters.com 读它解决什么：srcset/sizes 那套复杂语法，有没有更省心的路。
要点
- 响应式图片的复杂性来自浏览器需要在 CSS 布局完成前决定加载哪张图，因此要开发者手写
sizes - 容器查询单位与新的图片能力可能简化这件事
- 现实中大量
sizes属性是写错的，反而加载了过大的图
我的补充：sizes 写错很常见且没有任何报错，浏览器默认 100vw 会让你在侧栏小图位置加载全宽尺寸的图。检查方法：DevTools Network 面板看实际加载的图片尺寸与显示尺寸是否匹配，或者在 Elements 面板看 <img> 的 currentSrc。最省心的方案是让 CDN 或图片服务按需裁剪（URL 带参数），配合 sizes="auto"（配合 loading="lazy" 时可用）。
本卷小结
三条：
- 首屏图别加
loading="lazy"。懒加载推迟请求，LCP 直接变差；首屏用fetchpriority="high"。 aria-hidden别用在含可聚焦元素的容器上，用inert。加tabindex="-1"是错的修法。- 看 p75 不看平均值。Core Web Vitals 的官方判定就是 p75，平均值会掩盖那 25% 已经流失的用户。