Google I/O 2023 — 前端开发者划重点
Google I/O 是谷歌面向开发者举办的年度开发者大会，每年5月在加州山景城举行。大会会聚焦谷歌最新的产品发布和技术分享，并且大力支持开发者创新。
对于前端开发者来说，Google I/O 非常重要，因为谷歌每年都会在大会上介绍很多对 Web 有重大影响的更新。这些更新通常涉及到谷歌的浏览器 Chrome、Web 最新的技术标准以及辅助 Web 应用开发的各种工具。在今年的大会上有数百个专题演讲，我帮大家整理了前端开发者最应该关注的几个主题，并且对其中某些主题进行了深度解读。
重点速览
重新思考 Web 兼容性问题
为了解决另广大 Web 开发者困惑的 Web 兼容性问题，几大主流浏览器（Chrome、Edge、Firefox 和 Safari）合作推出了一个名为 Web 基线的东西，其中会囊括所有当前和以前的浏览器版本完全支持的核心功能集，并且每年都会有一个大的版本更新，你可以理解为 EcmaScript 每年都会推出的 ES2020、ES2021...，基线也会每年推出 Baseline 23、24、25...。它的目的就是不希望大家以一些老旧的浏览器（例如 IE 6/7/8）作为网站的兼容性标准了，如果开发者要判定一个新的 Web 特性能不能在生产环境中使用，看看它是不是被纳入到了 Web 基线的一部分就可以了。详细看：。
Web 平台的最新动态
在这个章节中介绍了 Web 平台最近新推出的，并且已经已经支持了两个最新浏览器版本的功能，也就是最近一批被纳入 Web BaseLine 的功能。包括：CSS 变换、新的 CSS 视口单位、原生深拷贝、focus-visible 伪类、Transform Stream、Import Maps 这几项功能。详细看：Google I/O 2023 — Web 平台的最新动态：
提升 Web 核心性能指标的建议
Web 性能方面有非常多的建议，但很难判断哪些建议会产生最大的影响。Chrome 团队花费了一年的时间确定了每个核心 Web 指标（LCP、CLS、FID）的三项最佳建议，这些建议对于大多数网站可能都是有用的，并且对于大多数开发者来说也是实际可行的。另外，Chrome 团队还透露称 Interaction to Next Paint (INP) 将会提到 FID 成为 2024 年的 Core Web Vitals。详细看：提升 Web 核心性能指标的 9 个建议
使用 DevTools 调试现代 Web 应用
Chrome DevTools 最近改进了使用框架开发的现代 Web 应用的代码调试能力，包括开发部署视图、忽略三方依赖的代码、导入 Source Map、条件断点、日志点、Recorder 等能力。详细看：
准备好迎接三方 Cookie 的终结
为了保护用户隐私，Chrome 将在不久的未来停止支持第三方 Cookies（初步确定是在明年）。这会对现有的 Web 开发方式以及一些正在线上运行的业务造成非常大的影响。所以在 Chrome 停止三方 Cookie 支持之前，大家必须要做好相应的改造。Chrome 团队介绍了 Cookie 独立分区（CHIPS）、Cookie 第一方集（First-Party Sets）两种替代方案来解决这个问题。详细看：准备好迎接三方 Cookie 的终结
Web UI（CSS）的最新特性
过去几个月迎来了 Web UI 的黄金时代，大量新的 Web 功能随着浏览器的功能广泛落地，这里介绍了 20 个关于 CSS 以及 Web UI 开发相关的新特性，包括：Container queries、Style queries、:has() selector、nth-of microsyntax、text-wrap: balance、initial-letter、Dynamic viewport units、Wide-gamut color spaces、color-mix()、Nesting、Cascade layers、Scoped styles、Trigonometric functions、Individual transform properties、popover、anchor positioning、selectmenu、Discrete property transitions、Scroll-driven animations、View transitions。详细看： developer.chrome.com/blog/whats-…
高级 Web API 的真实应用
Google 启动了一个名为 Fugu 的项目，它的目标就是让开发者能够在 Web 生态中做任何事情，包括以前只有客户端应用才能做的事情。我曾经也有过一篇文章来介绍个项目：Web开发未来会完全替代客户端开发吗？在这个章节中，Thomas 介绍了几个强大的 Web API 在真实应用中的案例，包括在 Photopea（一个免费在线图像编辑器）通过 Web File Handling API 进行文件处理；在 Blockbench（一个 3D 模型编辑器）运用 EyeDropper API 提供绘画能力等等，详细看：youtu.be/Y40vMQap9fs
WebGPU 推进 AI 技术在浏览器中的应用
新推出的 WebGPU API 释放了 GPU 硬件的力量，让 Web 真正为 AI 做好了准备。事实上，像 Tensorflow.js 这样的 ML 库在 WebGPU 上的运行速度比常规 JavaScript 快 100 倍，而 WebGPU 的运行速度比 WebGL（Web 图形之前的黄金标准）快 3 倍。WebGPU 在用户设备上运行也有助于开发者节省资金、减少延迟并构建新的隐私保护 AI 功能。详细看：youtu.be/m6T-Mq1BPXg
WebAssembly 让 Android 应用在 Web 上运行成为可能
本章节介绍了WebAssembly GC 这项新技术，可以支持现代编程语言直接在 Web 上运行。这使得使用 Kotlin 等语言编写的跨平台代码能在所有主流浏览器中以接近原生性能运行。详细看：www.youtube.com/watch?v=RcH…
Passkeys 可能淘汰传统的 Web 密码登陆方式
我们终于做好弃用传统的密码登陆方式的准备，Passkeys 可让用户在所有主要平台上轻松获得更简单、流畅、安全的登录体验。本章节详细介绍了密钥 (Passkey) 的优势、如何用密钥简化身份验证流程，以及如何改进身份堆栈来适应这项新技术。详细看：youtu.be/SF8ueIn2Nlc下面我会重点介绍一下前面几个章节的内容。在这个章节中，主要分享了 Chrome 与其他浏览器合作伙伴以及更广泛生态系统合作的方式，目的是尽可能的消除 Web 兼容性的问题，让跨浏览器开发更简单。
重新思考 Web 兼容性问题
旧版浏览器兼容
Web 开发已经经历了 20 年的风风雨雨，这段时间发生了非常大的变化。但有一点始终如一，就是我们一直在苦恼需要兼容哪些较老的浏览器。在以前，浏览器版本的更新频率很低。Web 平台的功能进步缓慢，可能一年只有一次。Internet Explorer 6 到 7 之间经历了 5 年。这段时间没有新版本推出，只能一直处理 bug。但是正因为 Web 平台的进展缓慢，开发者才能够及时追踪平台的变化。
现在，浏览器可能每个月都会有新的版本，每一个浏览器版本都会带来新的功能和修复，从新增单一的 CSS 属性到庞大的 Web GPU 规范。
升级软件是一种常态，所以大部分用户会很快使用到最新版本。新功能快速上线，以前所未有的速度进入我们用户的设备。功能也变得更加容易操作和交互，这意味着它们在所有浏览器引擎中的工作方式都会相同。现在，Firefox、Chrome 和 Safari 同时引入新功能已经是很常见的事情。比如去年，我们看到 Firefox 97、Chrome 99 和 Safari 15.4 同时推出了 CSS 级联层，大家期待已久的容器查询也在几个月后的浏览器版本中互相兼容。
这很令人兴奋，但也给开发者们带来了难题。如此多的新功能这么快的推出，我们跟得上吗？我们怎么判定能不能在生产环境中使用这些功能呢？在以前浏览器更新缓慢的时候，开发者会依赖最老的浏览器作为基准。总有一个浏览器不会消失，我们必须基于它提供支持。为了不断推进平台的发展，我们需要达到这样一个点：那个浏览器的用户足够少，我们只提供基本的支持或使用渐进增强的方法。
- 我们需要
Internet Explorer 11(2013 年推出的已经停止更新的浏览器)消失，这样我们才能使用网格布局。 - 我们希望
Internet Explorer 9消失，因为它不支持Flexbox、CSS多列和渐变等功能。 - 我们希望
Internet Explorer 8消失，这样我们才能使用圆角和颜色的透明度。 Internet Explorer 6推出时带来了很多CSS新特性，但是有很多奇葩的Bug导致页面无法渲然。- 回到更早的时候，我们希望
Netscape 4消失，特别是那些正在实验 CSS 布局的人。因为它有一个巨大的Bug，任何元素在用户重新调整浏览器窗口时会失去之前的定位。
现在，这些浏览器已经消失了，Microsoft 去年终止对 Internet Explorer 11 的支持。所以使用浏览器作为基准已经不再适用了，所有引擎都在快速的发生变化。
解释兼容性依然艰难
虽然如此，我们仍需要解释浏览器的兼容性。我们需要告诉团队哪些特性可以使用，确保利益相关者能够理哪些功能在各个浏览器和版本中能不能用。根据 Google 的研究，开发者很难理解发生了什么以及新功能的兼容性如何，能够跟上 Web 平台的变化和使设计与应用在浏览器中工作方式相同一直都是一个挑战。
Chrome 团队在过去一年一直努力解决这个问题，在去年的 Google I/O 上也分享了一些正在做的一些事情，但是进展并不明显。Chrome 的主要沟通渠道是 web.dev 和 developer.chrome.com，目标是让开发者能够以清楚一致的方式使用 Web 新特性，这里经常会介绍一些令人兴奋的新功能，Chrome 也希望它们能够快速的实现跨浏览器兼容。
比如，今年推出的 View transitions、Web GPU 或 popover API 可能吸引了大家的关注。在今年 Google I/O 的其他演讲中也详细介绍了这些方式，但是这也只是明确仅存在于 Chrome 中的方式。
在 web.dev 上，大家可以找到不同浏览器引擎世界中的最佳实践的指南。我们可以在支持面板清楚地看到这些特性的浏览器兼容情况。 数据来自 MDN 浏览器兼容数据，Chrome 团队会积极的保证它及时更新。
在今年 Google I/O 中，介绍了一些三大浏览器引擎都兼容的 Web 新功能：详细可以看这篇文章：Google I/O 2023 — Web 平台的最新动态
当功能互相兼容时，web.dev 会发表相应的文章来介绍它们，因为当一个特性在所有三个引擎中出现时，大家才会觉得这是一个可以在生产使用的功能。这些文章的目的也是为了告诉大家这个点。
Chrome 推出的新功能的文档也得到了加强，比如这是一个 Chrome 首推的 API 贡献在 MDN 上的文档，并在 developer.chrome.com 上记录功能的起源试用版。到了 Chrome 稳定版推出功能的时候，通常 MDN 上就会存在帮助大家了解如何使用它们的文档。
Interop 项目
Chrome 团队会重点关注多浏览器引擎的多样化 Web，其中一系列关于 Web 平台新功能的文章都会庆祝其他浏览器推出的功能。为了改进开发者生态的体验，不能闭门造车。各大浏览器厂商必须联合起来，一起改善浏览器兼容性和开发者的体验。虽然许多功能在浏览器中很快会得到实现，但许多功能在一个或多个引擎中可能会存在不可用的情况或存在重大 bug 。
Interop项目就是为了解决这个问题，Google 与来自 Mozilla 和苹果的代表以及其他合作伙伴一起工作，定义了 2022 年的一组功能，然后所有浏览器都会一起努力推出这些功能。因为一个这样的倡议，下面一些功能在所有浏览器中都得了兼容：dialog 元素、内置拥有无障碍特性的模态和非模态对话框、新的兼容移动端 UI 的视口单位、CSS 级联层等等，这解决了开发者挣扎了多年的难题。
在这篇文章中有详细介绍：Google I/O 2023 — Web 平台的最新动态
现在正在重复这个过程，Interop 2023 包括了更多更强大的功能。大家可以在这里了解所有包含的功能并在仪表板上跟踪我们的进展。
Chrome 团队还帮助创建了 Web DX 社区小组，目的是关注并改善 Web 平台的开发的体验。小组包括所有浏览器的代表，有两个目标:
- 澄清
Web平台的特征状态，具体来说就是说明哪些 Web 功能目前是是广泛可用的。 - 协同研究，促进所有浏览器供应商对某类问题有共同的理解。
去年，这个小组进行的研究也应用在了 Interop 2023 之中。
文档对于开发者来说是很重要的，Google 和其他公司一起资助了 Open Web Dos（openwebdocs.org/），这个网站试图通过文档改善来 Web 平台的清晰度，也是 MDN 的主要贡献者。
Web BaseLine
Chrome 团队已经做了很多努力，在过去一年也取得了一些进展，但是我们意识到浏览器兼容性现在还是很难理解的。 关于单个功能和 API 的兼容性信息也确实是存在的，但是开发者必须逐个检查每个功能甚至功能的组合，才能确保某些特性是可以跨浏览器工作的。在开发过程中，我们需要为大量的功能确定能否兼容我们设定的浏览器基线，而且我们也必须要确定这样一个基线。为了便于大家理解，在最开始的时候我们提到了几个关键的浏览器版本，但是目前如果没有这几个关键的浏览器版本，就很难界定这个基线了。在每个项目上，团队都需要花费很多的时间来试图弄清楚从何时可以开始使用什么功能，这可能会额外消耗大量的时间。所以，我们有必要给大家提供这样的一个基线，然后帮大家来确定哪些功能是可以安全使用的，哪些需要更多的考虑才能在所有浏览器上很好的工作。几大浏览器厂商也正在积极的界定它。
它的名字就被界定为基线（Baseline），如果某个功能是基于这个基线来开发的，那么它就应该得到广泛的跨浏览器支持，大家也可以放心的使用它。
一个新特性只有在可兼容并可安全使用时才能进入基准，开发者也可以很开心的和产品运营等同学去分享，我们的网站所有的功能都处于基线之中，不用再去兼容什么 IE6 了，只需要把基线内的功能兼容好就可以了。浏览器厂商希望可以做出清晰的指导，解释哪些功能可以进入基线，以及为什么可以进入基线。浏览器厂商们的目标就是基线可以在开发者查找有关功能信息的任何地方采用（比如 MDN、Can I Use 以及 web.dev）。而且也可以供框架开发者采用，这样就可以提供浏览器兼容性的明确指示。
基线中的功能会逐渐增多，每月或每年，我们都很容易看到哪些新特性成为了基线的一部分，这些都是我们可以放心研究并使用的功能。定义好这些安全的功能基线之后，浏览器厂商就可以放心的去开发新功能，并且努力让它们成为基线的一部分，以后任何 Web 平台特性的目标都应该是成为基线的一部分。想要了解 Web 基线的更多信息，可以到这里 web.dev/baseline/ 了解。
最后做个简单的总结，以后大家要判定一个新的 Web 特性能不能在生产环境中使用，看看它是不是被纳入到了 Web 基线的一部分就可以了。强烈不建议大家以一些老旧的浏览器（例如 IE 6/7/8）作为网站的兼容性标准了，它们的市场份额已经少的可怜，投入产出比极差，以后大家只需要根据基线兼容即可！
Web 平台的最新动态
作为一名前端开发工程师，大家是否知道可以利用 HTML 元素来构建网站模型呢？是否知道你有更简单的方式来控制 CSS 变换呢，或者是否知道现在有新的视口单位可以适应移动用户界面？
根据大家在 Web 开发中的关注点或专业领域，可能已经知道了这些特性，但是也可能错过了这些公告，这都没关系。Web 一直在发展，浏览器也在不断更新它们的引擎，来向开发者提供创新平台的工具。曾经需要三方库的东西现在可能已经得到了所有浏览器的本地支持，或者可能有更简单的编码设计元素的方法。这就是 Web 的伟大之处，它始终作为一个平台不断发展和调整我们使用 Web 的方式。
然而，在这个不断发展的过程中，其中也可能遇到一些困惑，比如，怎么快速去梳理或者掌握这些更新呢。我们总是会有一些问题，比如什么时候所有浏览器引擎都支持这个新特性？我什么时候才能在生产代码中实际使用这些功能？或者我们是不是应该长时间支持旧版浏览器？
真正的答案是取决于你的用户群体、技术栈、团队结构和支持的设备。但我们都认为，Web 的当前局面非常令人困惑，做出这些判断会比较困难。
所以，Chrome 团队一直在与其他浏览器引擎和 Web 社区合作，以便为开发者提供更好的体验。下面会重点介绍一些在过去两个版本中所有主要浏览器引擎都可以使用的功能。
Web 平台一直在发展，但我们认为支持两个最新版本的浏览器是一个很好的基础标准，这样大家就可以考虑是否可以在生产环境中使用新的 Web 特性。
Dialog 元素
Dialog 是一个新的 HTML 元素，可以用来创建一个对话提示框。
我们可以用非常简单地方式定义一个模态框，如下所示，然后可以通过调用对话框元素的 showMotor 方法打开对话框。
可能大家会想，这也不是什么新功能，我在使用 JavaScript 框架的时候也有相关的 UI 组件。但使用像这样的原生 HTML 元素的优点在于它具有浏览器的魔力，比如焦点管理、标签跟踪和保持堆叠上下文。
甚至可以让一个对话框元素打开另一个对话框元素，浏览器会自动处理应该显示在前面的元素。所以，我们不需要编写冗长的代码来管理它。
CSS 变换
另一个简化我们代码的功能是独立的 CSS 变换属性，它可以以一种很好的、高性能的方式来为我们的网站添加动画效果。你可能熟悉像下面这样写 CSS 变换的方式。
现在，通过单独的变换属性，我们可以分别指定变换的属性。
当我们编写复杂的关键帧动画时，这是非常方便的。比如现在我们准备从零到百分之百平移元素，并在不同的关键帧点上旋转元素，在中间位置缩放元素。
在以前，我们必须手动计算所有三个属性在不同关键帧点上的值，才能编写如下所示的代码。
但现在，我们无需计算中间点的值，只需为每个单独的属性编写值就可以轻松编写和管理代码。
新的 CSS 视口单位
新添加的视口单位对于移动网站非常重要，因为移动视口的大小可能受动态工具栏的存在或缺失的影响。有时候你会看到 URL 搜索条和导航工具栏，但有时它们完全消失了。
像 Small Viewport 和 Large viewport 高度这样的新视口单位给 Web 开发者提供了最终的控制权，以便在设计移动网站时更好地适应视口大小。
不仅仅是这两个单位，还有 Dynamic viewport 等其他选项。
详细可以看我之前写的这篇文章：Chrome 108 ：发布新的 CSS 布局单位！
深拷贝
深拷贝 JavaScript 对象现在更加简单了。在以前，如果我们想创建一个没有引用原始对象的对象副本，一般我们会选择使用 JSON.stringify 和 JSON.parse。
先把原始的 JavaScript 对象转换为字符串，然后通过 JSON 解析将其转回到 JavaScript 对象。这是一个非常常见的技巧，以至于 V8 引擎都对它进行了积极的性能优化。
但现在，你不需要使用这个技巧，用 structuredClone 就可以了。只需将原始对象传递给 structuredClone 函数，就可以创建一个深度复制的对象副本。虽然这是一个非常小的点，但确实是非常有用的更新。
focus-visible 伪类
focus-visible 伪类对于无障碍方面的功能是非常有用的。我们都熟悉当你使用键盘或单击输入元素导航页面时出现的焦点链接。
这是无障碍必备的功能，但有时它会妨碍不同用户的设计决策。focus-visible 是一个 CSS 伪类，它可以用于检查浏览器是否启发性地认为焦点应该是可见的。
在焦点可见时（例如用户使用键盘导航的页面），你可以应用恰当的设计，比如如把轮廓聚焦在元素上；但如果焦点不可见（例如用户使用鼠标导航），则可以根据整体设计需求去除轮廓。
Transform Stream
Transform Stream 现在对所有主要浏览器都可以使用了。这个能力让流管道化的管理更加方便，例如你可以从一个地方流式传输数据，然后对数据进行复杂的处理，最后将其流式传输到另一个位置。
当你创建一个新的 Transform Stream 时，如果没有参数，它会创建一个身份流，这是一个可读、可写的流对，可以接收任何传递到可写端的东西并将其发送到可读端。
你可以向 URL1 发出请求以获取数据，将响应从 fetch 请求转化为完成流，然后压缩，并将其传输到我们创建的 Transform Stream 中。因为可读和可写端都是身份流，所以任何传递到可写端的东西都会被发送到可读端。
Import Maps
Import Maps 是一种可以在 Web 应用程序中包含和重复使用 JavaScript 模块的新方法。
现在，你可以在应用程序中定义一个 Import Map，它允许你指定模块名称并将它映射到 URL 上。当你在代码中使用 import 语句时，浏览器会自动查找 Import Map，并从 URL 中加载相应的模块。
因此，如果你需要重复使用某些 JavaScript 模块（例如，一些通用工具函数），则可以在 Import Map 中指定它的名称和 URL，然后在代码中使用 import 语句引入它们。
详细可以看我这篇文章：Import Mpas 目前已获得跨浏览器支持！
以上是一些最近所有主要浏览器引擎都可用的新功能的简要介绍。这只是冰山一角，还有许多其他的新特性和更新。但我们建议以最新的、支持的浏览器为基础，并根据大家的情况确定是否可以在生产代码中实际使用新功能。
提升 Web 核心性能指标的建议
Web 性能方面有非常多的建议，但很难判断哪些建议会产生最大的影响。Chrome 团队花费了一年的时间确定了每个核心 Web 指标的三项最佳建议，这些建议对于大多数网站都是可以使用的，并且对于大多数开发者来说也是实际可行的。
LCP 优化建议
首先，让我们来看看网站最大内容渲染时间（LCP）的建议。LCP 是渲染网页最大内容的时间，相比于 CLS 或 FID，LCP 往往是大多数网站最难以应付的衡量指标。
在大多数情况下，约 70-80% 的网站是因为需要渲染或下载图片引起的。去年的 Google I/O 活动上，他们展示了实际的下载时间往往不是图像的最大延迟，今年的分析进一步证实了这一点。
Image 加载优化
为了优化 LCP 的时间，我们可以让使静态 HTML 中的图片资源更易于被发现，这有可以让浏览器的预加载扫描程序更早的找到并加载它。
使用背景图片、客户端渲染和懒加载等方法是可能存在问题的，它们不利于 LCP 的发现。
而使用传统的 img 元素或添加预加载链接等方式则可以使图像资源被预加载扫描程序发现，并被浏览器尽早加载。
你还可以使用 Chrome devtools 中的加载瀑布工具来识别开始加载较晚的资源，通过把图片包含在 HTML 中（让图片元素预加载）即可解决这个问题。但是在将 LCP 图像优化的可以被易于发现后，并不代表就可以更快的加载。因为浏览器更倾向于优先处理阻塞渲染的内容，如 CSS 和同步 JavaScript，而不是图像。
fetch proirity API
新的 fetch proirity API 允许我们自定义标记资源的优先级。只需将 fetchprority 属性添加到我们的图像或预加载 LCP 元素中，就可以使浏览器更早地开始下载它们，并具有更高的优先级，这可以对 LCP 时间产生很大的影响。这个 API 已经在基于 chromium 的浏览器中提供，Safari 和 Firefox 也正在实现相关代码，并且这个属性是渐进式的，在不支持它的其他浏览器中会被简单地忽略。回到之前的例子，我们解决了图片可尽早被发现的问题，但是请求图像和开始下载依然会存在很大的延迟。使用 fetch proirity API 可以将延迟最小化，并且让图像尽快下载。
这是一个优化 LCP 指标的最佳示例，我们还可以通过其他多种方式降低非关键资源的优先级。
例如使用fetchprority=low 或者对它们进行懒加载，以便按需获取，这样就可以让浏览器集中处理更重要的资源，比如影响 LCP 指标的元素。我们只需要确保不要在 LCP 图像本身上使用这些技术即可。
如果我们使用了 JavaScript 框架，建议使用 Chrome Aurora 团队开发的 Image 组件添加图像。其中 Angular 和 XJS 组件已经内置了提取优先级的支持，团队也正在开发 Next.js 的 Image 组件，以支持这个新的 API 。 
Chrome 团队也与其他平台有着合作，例如如果大家使用的是 WordPress，就可以尝试使用官方 WordPress 性能实验室插件的新提取优先级模块。这是 Chrome 团队与 WordPress 核心性能团队开发合作的成果。
使用 CDN
前两个 LCP 的建议是和如何构建 HTML 来让 LCP 资源易于被发现以及优先下载有关，但这都取决于首屏加载 HTML 的速度。所以，最后一个建议是使用 CDN 来优化 First Byte 的时间。
在浏览器收到第一次 HTML 请求响应的第一个字节之前，网站是无法开始加载任何子资源的。越快将首节传递给浏览器，浏览器就可以越快地开始处理它，同时也可以让其他所有的操作都更快的进行。下面是两个减少 ttfb 的最佳方法：
- （1）尽可能地将内容服务器设置为地理位置更靠近用户的位置来减少用户与服务器之间的距离；
- （2）对内容进行缓存，以便最近请求的内容可以快速再次提供。
内容分发网络（CDN）是执行这两个操作的最佳方法。CDN 是一组全球分布式的服务器，它作为用户的连接点。由于最后一英里的传输速度往往是最慢的，而使用 CDN 可以尽可能的优化这个问题。CDN 还允许在这些边缘节点上缓存内容，从而进一步降低加载时间，所以即使必须要返回到我们的源服务器进行回源加载，CDN 通常也可以更快地完成。
开发者经常使用 CDN 来托管静态资源，如 CSS、JavaScript 或 Media 文件，但是通过 CDN 提供 HTML 也可以获得更多的好处。根据 Web Almanac 的统计结果，只有 29% 的 HTML 文档请求会通过 CDN 服务加载。如果你不是这样做的，那么这意味着你还有很大的机会来优化网站的性能。
CLS 优化建议
下面，我们来看看累积布局移位（CLS）的优化建议。CLS 是网页视觉稳定性的度量指标，意味着当有新的内容加载时，页面的内容是否经常跳动。
虽然 CLS 在 2020 年以来得到了很大的改进，但仍然有约四分之一的网站未达到推荐的阈值，所以很多网站在这方面还有很好的改进用户体验的机会。
内容大小
第一个 CLS 优化建议是确保内容能被显式地缩放，当它第一次被浏览器渲染时，它就可以以正确的尺寸渲染。
一般情况下，我们都会热衷于推荐大家设定图像的宽度和高度的尺寸或 CSS 等效尺寸，现在这仍然是影响 CLS 的主要原因，网站也往往可以通过提供这些尺寸来轻松的优化 CLS，但还有一些其他的优化点。
比如我们可以通过新的 CSS aspect-ratio 属性，就可以确保像视频这样的其他非图像内容也能够较好的响应。
另外还可以将渲染的文字设置适当的高度，例如使用 min-height 来为广告卡片等动态的内容保留最小空间，空元素的默认高度为零像素，所以即使对于某些动态的内容，我们不能确定实际的高度，也是可以通过使用 min-height 来减少 CLS 的影响。
BF Cache
我们去年看到 CLS 的最大改进之一是在 Chrome 中推出的回退缓存或 BF 缓存中。另外，Safari 和 Firefox 也已经上线这个功能一段时间了。
一个页面可能在初始加载时具有很大的 CLS ，因为随着其他内容（如图像和广告）的加载，页面的结构会一直产生变化，从而影响 CLS。当然，我们应该尽量在首屏页面渲染时避免加载这些内容。
BF 缓存会在用户离开之后，在内存中存储一个用户加载页面后的完整 CLS 快照。如果用户返回了这个页面，就会恢复这个快照。同样的，如果用户再次向前访问，则也可以恢复这个快照。这就完全消除了任何 CLS 的加载，如果从头开始重新渲染页面，BF 缓存也会默认启用，我们不需要采取任何措施来主动启用它，但是我们可以使用某些 API 阻止浏览器使用它，但这可能会导致浏览器没办法更好的响应，建议大家不要放弃这种免费的性能优化方案。
Chrome DevTools 有一个工具，可以让我们测试页面是否有使用 BF Cache 的资格。如果没办法使用 BF Cache ，工具一般都会告诉我们具体原因。最常见的原因是我们设定了 cache-control 这个 Header 的值为 no-storage或者在页面中使用了 unload handler，这两者都会阻止 BF Cache 的使用。
在 Lighthouse 10 中，也添加了一个类似的检测能力，也可以解释页面不符合资格的原因。
BF Cache 是 Chrome 团队为了让网页浏览更快的正在开发的一系能力之一，这个领域还有一些其他的能力，比如预加载和预渲染也是可以改善网站 CLS 指标的。
动画和转换的处理
最后一个 CLS 建议是处理动画和转换。动画通常用于移动端的内容，如 cookie banner 或从顶部或底部滑入的其他通知横幅，者具体取决于这些动画或过渡是怎么编码的，它们可以更少或者更有效，并且可以帮助优化 CLS。
动画的渲染需要浏览器重新布局页面，因此需要更多的工作，即使脱离正常文档流的绝对定位元素，例如使用 top 或 left 移动内容，也会将其计算为布局移位，即使它不会移动任何周围其他的内容，内容本身也在移动，并且有可能影响其他内容，所以这也会影响 CLS。
使用 translate 进行相同的动画不会在浏览器的布局处理中移动内容，而是在合成器层中进行的，除了对于浏览器来说工作量较小之外，这还意味着它无法影响其他的内容，这也意味着它对 CLS 的影响就变小了。所以我们的解决方案就是替换使用 top 或 left 的动画，并且这种方式在所有的浏览器中都得到了支持。
始终优先使用复合动画，比如如 transform ，而不是图层诱导的非复合动画，如更改 top、right、bottom 和 left。
并且 Lighthouse 也有一个相关的能力来识别这些问题。
FID 优化建议
最后我们来看看用户响应相关的优化建议，这包括用户和页面进行首次交互操作所花费的时间（FID），以及更全面的交互到下一次绘制的时间（INP）。
网站响应性的关键在于确保不阻塞主线程，因为这会导致浏览器无法响应用户输入。
分解长任务
第一个建议是识别并分解长任务，相当于给浏览器一些喘息的空间，以便它能够响应用户输入。
Chrome Devtools和 Lighthouse 将长任务定义为需要 50 毫秒或更长时间的渲染工作。这可能听起来不是很多，但在浏览器术语中，这可以是网站能感觉到比较好的响应或不响应的区别。
JavaScript 是单线程且贪婪的，一旦它占用了 CPU，它就会尽可能地一直保持它，直到它不能处理或者处理完毕为止。在这个例子中，即使有五个子进程，所有的五个进程也是会一个接一个地执行。所以，在我们的代码中放置一些断点就是关键了。
我们可以使用设置超时 settimeout 0 毫秒延迟来放入非关键的工作和新的任务，这些新任务就会在已经排队的任何任务之后执行。
还有一些新的和即将推出的浏览器 API ，如 isInputPending、scheduler.postTask 和 scheduler.yield，它们可以帮助大家决定何时以及如何放弃主线程。有关更多详细的信息，可以去看 web.dev 上优化长任务的相关文章 ：web.dev/optimize-lo… 。另外，在 Google I/O 上，还有一个专门关于优化长任务的独立演讲。
去除不必要的 JS
尽管优化我们页面上的 JavaScript 代码执行是一个不错的方法，但更好的方式是一开始就不要发送太大的 JavaScript。
现在的网站上加载的 JavaScript 越来越大了，但我们需要重新检查一下有这些 JavaScript 是否都是必要的。
我们可以使用 Chrome Devtools 的 Coverage 特性来查看我们的 JavaScript 有多少被执行了。如果在页面加载期间没有使用的大部分 JavaScript ，都可以考虑进行代码分离以在需要时或浏览器不太繁忙的时候加载这些代码。
Aurora 团队还开发了一个 xjs 脚本组件，允许我们加载较少且关键的第三方代码，并采用各种策略来减少这些脚本的影响。标签管理器是另一个容易积累旧 JavaScript 代码的地方，这些代码可能不再需要了。定期检查我们的标签，以确保删除所有标签，因为即使它们不再触发，它们仍然需要下载、解析和编译。
避免大型渲染更新
改善响应性的最后一个建议是避免大型渲染更新。JavaScript 不是唯一可以影响我们网站响应性的东西，如果浏览器需要大量的工作来将页面渲染到屏幕上，那么浏览器本身也可能会变慢。大型渲染更新可能会在有大量Dom 更改时发生，无论是有意还是由于一个更改导致许多其他元素需要重新计算。避免大型渲染更新的最佳方法是保持较小的 Dom 结构，以便即使存在关联效应，也可以快速处理它们。
我们还有一个 Lighthouse 审计工具来帮助大家实现这一目标。
CSS containment 是另一种分离网页区域的方法，它可以告诉浏览器某些区域中的元素可以不受其他区域更改的影响，从而减少布局的工作。
content-visibility 是 CSS containment 的一种扩展能力，允许我们能完全跳过离屏内容的布局和渲染。
最后，大家应该避免滥用 requestAnimationFrame API，它应应该只用于关键的渲染工作，如果通过这个 API 安排了过多的工作，它会导致渲染变慢。
这些就是我们认为大家首先应考虑的九个改善网站核心性能指标的优化建议。这并不是一个明确的列表，而是我们的研究表明可以真正提高大家网站性能的几个更有影响力的选项。包括 Chrome Devtools、Lighthouse 和我们添加到 JavaScript 框架和平台中的组件，许多这些建议已经涵盖在我们的各种工具中。但我们并没有放松警惕，并且也在一直更新我们的工具和文档，来呈现这些关键建议。
使用 DevTools 调试现代 Web 应用
在本章节中，我们将会一起来看一些新的 Chrome Devtoos 特性，来帮助我们更好的调试现代 Web 应用。DevTools 已经存在了近15年了，下面我们可以看到 2008 年 Chrome DevTools 刚刚发布时博客文章的屏幕截图。
15年前，Web 看起来完全不同，没有大型框架，JavaScript 非常缓慢，不同浏览器之间的兼容性差距也很巨大。现在，Web 应用程序开始使用 TypeScript、SAS 以及新的标记语言编写，WebAssembly 甚至为 Web 带来了新的源语言。这也使开发者工具必须作出相应的变化。
SourceMap 发明出来了，Babel 和 webpack 这样的编译器和打包工具也开始出现，Beta 框架也流行起来了。例如，React DevTools、Angular DevTools、Flutter DevTools 等大型框架甚至建立了自己的开发者工具。
绝大多数 Web 开发者至少使用一个大型框架。这意味着 Chrome DevTools 的目标受众也在使用至少一个大型框架。Chrome DevTools 团队做了深入的考察。在现在的 Web 应用程序中，很多可能至少10种不同的工具和框架结合在一起创造了最终的 Web 体验。Chrome DevTools 的目标就是构建像这样一个井井有条、事故少、吞吐量高且光线充足的街道。下面我们来看几个最近出来的新特性：
开发部署视图
在以前，如果我们打开 Sources 面板并使用页面资源管理器来导航文件，可能看起来比较混乱。旗面可能会包括很多重复的文件，其中有一些是代码的实际源文件，还有一些是浏览器接收到的产物文件。这很令人困惑。
去年，Chrome DevTools 引入了 Authored 和 Deployed 视图的概念，它们可以分别把开发视角的源代码文件以及部署视角的产物文件分类管理：
我们只需在 DevTools 中启用实验，一旦检测到 SourceMap 文件，它就会自动出现。
忽略三方依赖的代码
当我们的项目是通过框架搭建的，或者使用了很多三方依赖时，很多三方的文件可能会对我们造成干扰。
大部分情况下，我们只想看到我们自己的代码，而不是一些隐藏在节点模型中的第三方库代码。或者大家可能正在一个大型团队工作，我们可能在每次需要调试事件处理函数的时候都要深入侵入框架代码。Chrome DevTools 现在可以解决这个问题，它可以让我们忽略并跳过特定的文件和文件夹。首先我们可以在页面浏览器中设置忽略列表和文件夹，甚至还可以使他们完全不可见。
调用堆栈也不会显示这些代码的位置，所以我们看到的堆栈跟踪将会非常准确且直接。这在控制台和调试器界面本身都会是这样的。
Chrome DevTools 会默认排除第三方脚本，我们也可以手动设置这个忽略列表，或者如果大家幸运的话，我们使用的框架已经为我们做好了需要做的事情并告诉 Chrome DevTools 要忽略哪些文件夹。例如 Angular 从 14.1 版本开始支持此功能。最近 Vite、Rollup 和 Next.js 也支持了这项功能。
Source Map
我们编写代码和发布代码之间的许多转换都是用 Source Map 技术实现的。Chrome DevTools 和各种框架都接受了 Source Map 处理和利用方式的一大堆优化。如果大家从未听说过 Source Map ，那么大家很可能已经在幕后开始使用它们了，因为大部分主流的框架或包都支持在开发构建配置中生成它们。
要查看 Chrome DevTools 是否正确加载了Source Map，有一个很好的名为 Developer Resources 的 Tab 可以显示任何错误。我们可以在 Other Tools → Developer Resources 或 命令面板中找到它。
条件断点
现代 Web 应用程序一般都非常复杂，大家可能常常通过 console.log 进行调试。console.log 非常好，但有时还不够。这时候我们就得用上互动调试的能力了。
大多数同学应该都了解断点，它们可以在应用程序的某个点暂停执行。试想一下，我们在处理所有传入事件的函数中设置这样的断点，比如这里所示的代码。我们可能注意到处理点击事件有 bug。然后所有传入的事件都会发送到这个函数，包括鼠标位置的改变。如果我们在这里设置断点，将会打断很多次。
现在我们可以将现有的断点转换为条件断点，只有在条件为真时才会暂停执行。在这种情况下，event.type 等于 click 只有在处理点击事件时才会暂停执行。我们前面已经谈到了 Source Map，它让 Chrome DevTools 可以在我们编写的代码和发布的代码之间建立联系。所以，如果 Source Map设置正确，我们就能够非常方便的调试代码了。
日志点
console.log 以及它的兄弟姐妹 console.trace 和 console.debug 都非常有用，它们可以让我们理解应用程序中正在发生的事情。但是它们有一个很大的缺点 — 我们需要将它们添加到代码中并将它们撒得到处都是。然后我们还要重新部署，调试结束之后，我们还要把所有的 console.log 语句清除掉。
日志点是一种非侵入性的替代方法，它拥有 console.log 的大部分好处，但是不需要更改代码和重新部署。我们可以通过 Sources 面板中的断点部分右键单击来添加。
和新建条件断点一样，我们可以添加任何 JavaScript 表达式，然后它将通过控制台进行记录，这也可能导致大量的控制台记录，当然也可以忽略掉。
Recorder
试想一个这样的场景，我们在深度调试的过程中需要同事的帮助。然后同事想要在本地复现你的 bug。我们可以使用 Chrome DevTools记录器来记录我们的复现步骤，而且可以分享导出的录制。
我们可以 Recorder 面板，它就会记录当前打开页面上的操作。完成记录时，别忘了在本地重播一次录制，确保满意之后。使用导出菜单将记录的结果保存在本地 JSON 文件或 Puppeteer 脚本中。然后你的同事就可以使用这个文件将其导入到他们的本地的 DevTools，然后完美的复现你的问题。
准备好迎接三方 Cookie 的终结
在这个章节我们将关注 Web 上的隐私沙箱并分享如何为三方 Cookies 的终结做好准备。Privacy Sandbox 是一组提案，可以帮助我们解决用户身份追踪的问题，Chrome 也将在不久的未来停止支持第三方 Cookies。我们可以在 privacysandbox.com/timeline 查看最新信息（我们可以在时间性中看到，在明年的第三季度，三方 Cookie 将被禁用）。
隐私沙盒的更多介绍也可以看我这篇文章：三方 Cookie 替代品 — 隐私沙盒的最新进展
Chrome 已经在消除 Web 中的用户追踪信息方面取得了一些进展：
Chrome 85中推出了HTTP Cache Partitioning（对 HTTP 缓存的缩减）Chrome 92开始逐步实施User Agent字符串的缩减（注意以后再也不能用 UA 精确标识一个用户了）Chrome 108中推出了Network State Partitioning（对网络状态的缩减）Chrome 113中推出了Storage Partitioning（存储分区，如果我们的站点含有依赖存储的嵌入式内容，例如IndexedDB、Local Storage和Session Storage，并且可以跨多个顶级站点进行访问就可能收到影响）
不过这些信息的削减也给开发者带来了不小的负担，影响了很多正常的业务场景，我之前的文章中也有过相关的介绍：Chrome：听说你们滥用 UA? 废了它！、新的浏览器缓存策略变更：舍弃性能、确保安全
识别三方 Cookie
随着 Chrome 中三方 Cookie 终结的日益临近，Chrome 希望确保我们具备足够的知识和工具来为站点做好迁移准备工作。比如我们可以利用 First-Party Sets 和 CHIPS 来迁移和远离第三方 Cookie。特别是如果我们会负责一个或多个站点，可能在代码中很多地方使用 Cookie，其中一些 Cookie 可能是第三方 Cookie。下面会介绍一些 Chrome 的 Web 标准提案，用于替换默认和被动访问第三方 Cookie 的行为。
根据用户所在的上下文，Cookie 可以是一方或第三方。Web 上的这种一方和第三方上下文之间的区别并不总是很明显的，并且它对不同资源的影响可能会有所不同。通常，发送到跨站点上下文的 Cookie（例如，iframe 或子资源请求）被称为第三方 Cookie。
我们也可以在自己的计算机上设置阻止第三方 Cookie 并尝试浏览我们的站点，在 Network 中来识别第三方 Cookie。三方 Cookie 在保护用户隐私方面存在很大的问题，但它们现在也是 Web 功能的关键组成部分。三方 Cookie 使内容和服务的组合更加灵活，进而为全球用户创造出更好的用户体验。
比如在线电商网站上的嵌入式地图和聊天小部件、同系列产品共享登录状态等，这些都是正常会依赖三方 Cookie 的业务场景。所以 Chrome 会希望尽量在不影响用户体验的情况下，也能禁用掉 Cookie 从而保护用户的隐私。
Chrome 为此已经专门构建了很多 API（如 Topics API 和 Federated Credential Management），以及通过一些 Web 的标准提案来限制 Cookie 的使。其中一些合作的提案现在已经在 Chrome 中推出使用了，包括 CHIPS 和 First-Party Sets，下面介绍一下这两个提案。
我前几天的文章中也专门介绍过这块，详细可以看：Cookie 的访问方式可能要有大变化了！
Cookie CHIPS
第三方库或三方的通用服务是需要使用三方 Cookie 最常见的场景。例如网站上的嵌入式地图和聊天小部件。在这种情况下，三方服务的提供者需要在每个父级网站上维护一些 Cookie 或状态，比如用户的聊天记录、选择过的商品等等。这就是 CHIPS（具有独立分区状态的 Cookie）的用处所在。
我们只需要添加一个额外的 Cookie 属性 partitioned，我们的跨站点 Cookie 就会在每个父级网站上自动获得一个不同的 Cookie Jar，从而防止用户在不同站点之间被跟踪。
使用 CHIPS 可以为用户带来更私密的体验。我们不需要等待三方 Cookie 被淘汰，现在就可以把我们的网站迁移到使用 CHIPS。如果大家以前查看过 CHIPS，在本次 Google I/O 上介绍 CHIPS 以来，Chrome 基于 Web 开发者的一些反馈进行了两项更改：
- 第一，
Chrome删除了主机前缀命名和主机名边界性的要求。虽然这个要求的原始意图是鼓励安全最佳实践，但许多开发者告诉我们，他们目前在子域中大量使用Cookie，这个要求会给造成很大的迁移负担。 - 第二，
Chrome将以前每个分区的Cookie限制从10个更改为每个分区的动态内存限制为10KB。
这限制了开发者可以使用少量的大型 Cookie，或者使用大量的小型 Cookie。
First-Party Sets
根据域名的不同来定义 Cookie 属于第三方有点太狭隘了，毕竟一个公司不可能只有一个域名：
但是当启用了三方 Cookie 的限制后，同一组织下不同域名的 Cookie 共享就很困难了。
First-Party Sets 是一个框架，可以用于开发者来声明域之间的关系，浏览器可以基于第三方域与第一方域之间的关系做出决策。这个框架有三个不同的子集，来满足 Web 上的一些关键用例。
ccTLDs域名：网站可能服务于不同的国家，在每个地区都有一个特定的域名，比如conardli.cn、conardli.jp、conardli.en等等；Service域名：网站可能会使用特定的域名来保证安全性或者提高性能，但是这些不同域名的网站可能也需要共享用户身份。Associated域名：同一个组织下可能有多个不同的子品牌，对应不同的域名，例如bytedance.com、douyin.com就属于这种情况。
对于这些集合，开发者需要向 Chrome 提供的公共 Gtihub 提交一个申请，并确保集合的完整性，以保证特定的技术验证检查和浏览器处理行为。
当浏览器收到 Storage Access API 发出的请求时，它会去确认这个第三方域和第一方域是否在同一集合中，并授予访问请求。
从用户的角度来看，First-Party Sets 可以被看作是同一组相关的站点，他们将能够切换控制来允许 Chrome 基于 First-Party Sets 列表做出访问的决策，同时也能够看到他们正在访问的站点是否在第一方集中，以及他们曾经访问过的其他站点是否在同一集合中。
通过使用 CHIPS 和第一方集，Chrome 团队希望在尽可能不影响用户体验的情况下保护用户隐私。如果大家正在准备迁移远离第三方 Cookie，建议仔细阅读下这些资源，并在禁用之前采取适当的措施。