# INP将于24年3月全面替代FID（相关调研）
提升 Web 核心性能指标的建议
Web 性能方面有非常多的建议，但很难判断哪些建议会产生最大的影响。Chrome 团队花费了一年的时间确定了每个核心 Web 指标（LCP、CLS、FID）的三项最佳建议，这些建议对于大多数网站可能都是有用的，并且对于大多数开发者来说也是实际可行的。另外，Chrome 团队还透露称 Interaction to Next Paint (INP) 将会替代 FID 成为 2024 年的 Core Web Vitals。
# View Transitions Api
页面过渡不仅看起来很棒，而且还传达了流程方向，并明确了页面之间哪些元素相关。它们甚至可能发生在数据获取期间，从而更快地感知性能。
但是，我们已经在 Web 上有了动画工具，例如CSS 过渡、CSS 动画和Web 动画 API，那么为什么我们需要一个新工具来移动东西呢？
事实是，即使使用我们已有的工具，状态转换也很困难。
即使像简单的交叉淡入淡出这样的事情也涉及两种状态同时存在。这带来了可用性挑战，例如处理传出元素上的额外交互。此外，对于辅助设备的用户来说，有一段时间，之前和之后的状态同时在 DOM 中，并且事物可能以视觉上良好的方式在树上移动，但很容易导致阅读位置和焦点发生变化。迷路了。
如果两个状态的滚动位置不同，则处理状态更改尤其具有挑战性。而且，如果一个元素从一个容器移动到另一个容器，您可能会遇到overflow: hidden其他形式的剪切困难，这意味着您必须重新构建 CSS 才能获得您想要的效果。
这并不是不可能，只是真的很难。
# Authentication: PassKeys
Passkeys 可能淘汰传统的 Web 密码登陆方式
我们终于做好弃用传统的密码登陆方式的准备，Passkeys 可让用户在所有主要平台上轻松获得更简单、流畅、安全的登录体验。本章节详细介绍了密钥 (Passkey) 的优势、如何用密钥简化身份验证流程，以及如何改进身份堆栈来适应这项新技术。详细看：youtu.be/SF8ueIn2Nlc
相关参考：
passkeys.dev/docs/intro/…
web.dev/passkey-reg…
web.dev/passkey-for…
# 弃用第三方cookie
准备好迎接三方 Cookie 的终结
Privacy Sandbox 是一组提案，可以帮助我们解决用户身份追踪的问题，Chrome 也将在不久的未来停止支持第三方 Cookies。我们可以在 privacy-sandbox-timeline 查看最新信息（我们可以在时间轴中看到，在2024的第三季度，第三方 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，并且可以跨多个顶级站点进行访问就可能收到影响）
识别三方 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，建议仔细阅读下这些资源，并在禁用之前采取适当的措施。
Baseline
重新思考 Web 兼容性问题
为了解决另广大 Web 开发者困惑的 Web 兼容性问题，几大主流浏览器（Chrome、Edge、Firefox 和 Safari）合作推出了一个名为 Web 基线的东西，其中会囊括所有当前和以前的浏览器版本完全支持的核心功能集，并且每年都会有一个大的版本更新，你可以理解为 EcmaScript 每年都会推出的 ES2020、ES2021...，基线也会每年推出 Baseline 23、24、25...。它的目的就是不希望大家以一些老旧的浏览器（例如 IE 6/7/8）作为网站的兼容性标准了，如果开发者要判定一个新的 Web 特性能不能在生产环境中使用，看看它是不是被纳入到了 Web 基线的一部分就可以了。
WebAssembly 让 Android 应用在 Web 上运行成为可能
WebAssembly GC 这项新技术，可以支持现代编程语言直接在 Web 上运行。这使得使用 Kotlin 等语言编写的跨平台代码能在所有主流浏览器中以接近原生性能运行。详细看：www.youtube.com/watch?v=RcH…
WordPress Playground
使用 WordPress Playground 和 WebAssembly 构建浏览器内 WordPress 体验
WebGPU 推进 AI 技术在浏览器中的应用
新推出的 WebGPU API 释放了 GPU 硬件的力量，让 Web 真正为 AI 做好了准备。事实上，像 TensorFlow.js 这样的 ML 库在 WebGPU 上的运行速度比常规 JavaScript 快 100 倍，而 WebGPU 的运行速度比 WebGL（Web 图形之前的黄金标准）快 3 倍。WebGPU 在用户设备上运行也有助于开发者节省资金、减少延迟并构建新的隐私保护 AI 功能。详细看：youtu.be/m6T-Mq1BPXg
HD颜色支持
dynamic-range功能可用于测试用户代理和输出设备支持的亮度、对比度和颜色深度的组合
@media (dynamic-range: standard) {
...css-code
}
深拷贝
深拷贝 JavaScript 对象现在更加简单了。在以前，如果我们想创建一个没有引用原始对象的对象副本，一般我们会选择使用 JSON.stringify 和 JSON.parse。
先把原始的 JavaScript 对象转换为字符串，然后通过 JSON 解析将其转回到 JavaScript 对象。这是一个非常常见的技巧，以至于 V8 引擎都对它进行了积极的性能优化。
但现在，你不需要使用这个技巧，用 structuredClone 就可以了。只需将原始对象传递给 structuredClone 函数，就可以创建一个深度复制的对象副本。虽然这是一个非常小的点，但确实是非常有用的更新。
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。
:has选择器
允许我们根据一个元素的后代或任何后续元素来确定其样式。
如何以及何时使用CSS :has选择器
Dialog 元素
Dialog 是一个新的 HTML 元素，可以用来创建一个对话提示框。
我们可以用非常简单地方式定义一个模态框，如下所示，然后可以通过调用对话框元素的 showModal 方法打开对话框。
可能大家会想，这也不是什么新功能，我在使用 JavaScript 框架的时候也有相关的 UI 组件。但使用像这样的原生 HTML 元素的优点在于它具有浏览器的魔力，比如焦点管理、标签跟踪和保持堆叠上下文。
甚至可以让一个对话框元素打开另一个对话框元素，浏览器会自动处理应该显示在前面的元素。所以，我们不需要编写冗长的代码来管理它。
使用 DevTools 调试现代 Web 应用
开发部署视图
在以前，如果我们打开 Sources 面板并使用页面资源管理器来导航文件，可能看起来比较混乱。旗面可能会包括很多重复的文件，其中有一些是代码的实际源文件，还有一些是浏览器接收到的产物文件。这很令人困惑。
去年（2022），Chrome DevTools 引入了 Authored 和 Deployed 视图的概念，它们可以分别把开发视角的源代码文件以及部署视角的产物文件分类管理：
我们只需在 DevTools 中启用实验，一旦检测到 SourceMap 文件，它就会自动出现。
忽略三方依赖的代码
当我们的项目是通过框架搭建的，或者使用了很多三方依赖时，很多三方的文件可能会对我们造成干扰。
大部分情况下，我们只想看到我们自己的代码，而不是一些隐藏在节点模型中的第三方库代码。或者大家可能正在一个大型团队工作，我们可能在每次需要调试事件处理函数的时候都要深入侵入框架代码。
Chrome DevTools 现在可以解决这个问题，它可以让我们忽略并跳过特定的文件和文件夹。首先我们可以在页面浏览器中设置忽略列表和文件夹，甚至还可以使他们完全不可见。
调用堆栈也不会显示这些代码的位置，所以我们看到的堆栈跟踪将会非常准确且直接。这在控制台和调试器界面本身都会是这样的。
Chrome DevTools 会默认排除第三方脚本，我们也可以手动设置这个忽略列表，或者如果大家幸运的话，我们使用的框架已经为我们做好了需要做的事情并告诉 Chrome DevTools 要忽略哪些文件夹。例如 Angular 从 14.1 版本开始支持此功能。最近 Vite、Rollup 和 Next.js 也支持了这项功能。
条件断点
现代 Web 应用程序一般都非常复杂，大家可能常常通过 console.log 进行调试。console.log 非常好，但有时还不够。这时候我们就得用上互动调试的能力了。
大多数同学应该都了解断点，它们可以在应用程序的某个点暂停执行。试想一下，我们在处理所有传入事件的函数中设置这样的断点，比如这里所示的代码。我们可能注意到处理点击事件有 bug。然后所有传入的事件都会发送到这个函数，包括鼠标位置的改变。如果我们在这里设置断点，将会打断很多次。
现在我们可以将现有的断点转换为条件断点，只有在条件为真时才会暂停执行。在这种情况下，event.type 等于 click 只有在处理点击事件时才会暂停执行。我们前面已经谈到了 Source Map，它让 Chrome DevTools 可以在我们编写的代码和发布的代码之间建立联系。所以，如果 Source Map设置正确，我们就能够非常方便的调试代码了。
覆盖HTTP响应标头
其他（Android）
Custom Tabs
以一种安全且便于操作的方式，让用户查看应用中的Web内容； 指定部分式 Custom Tabs 的启动高度，以便实现覆盖部分屏幕或整个屏幕的标签页使用体验。
Jetpack JavaScript Engine
无需创建webview实例，即可评估JavaScript和WASM代码
本文部分内容摘自： # Google I/O 2023 — 前端开发者划重点
