乐趣区

关于chrome:了不起的Chrome浏览器6Chrome-94开始WebGPU试用Web的图像渲染及机器学能力更强了

jiezi

9 月 21 日正式公布的 Chrome 94，带来了哪些有意思的新个性呢？

背景

十多年来，Web 技术突飞猛进，其中 Chrome 功不可没，理解 Chrome 能够帮忙咱们了解前端行业的发展趋势。

因而，我将以《了不起的 Chrome 浏览器》为题，对 Chrome 的每一个版本的重要个性进行具体解读，同时分享一些本人的一些思考：

  • 了不起的 Chrome 浏览器（1）：Chrome 89 开启 Web 利用的物联网时代
  • 了不起的 Chrome 浏览器（2）：Chrome 90 将默认应用 HTTPS，Web 更平安了
  • 了不起的 Chrome 浏览器（3）：Chrome 91 反对 WebAssembly SIMD，减速 Web 在 AI 等畛域的利用
  • 了不起的 Chrome 浏览器（4）：Chrome 92 新增 at 和 randomUUID 办法，Canvas 反对 Display P3 色域
  • 了不起的 Chrome 浏览器（5）：Chrome 93 反对 Error Cause，我国首个 ECMAScript 提案能够用了

通过专一于 Chrome 的写作，既能够能够进步我的业余能力，也能够进步集体影响力。我的长期指标是在 2025 年出版一本对于 Chrome 的书，毕竟出版本人的书每一个写作者最高的谋求。

我是寒雁，一个酷爱写代码和写文章的程序员，欢送关注我的微信公众号 寒雁 Talk。

TL;TR

  • Chrome 94 最大的亮点是什么？全村最靓的仔无疑是 WebGPU，它为 Web 利用提供了间接应用 GPU 的能力，能够用于减速 3D 渲染以及数据并行计算，为 Web 利用在游戏以及人工智能畛域关上了另外一扇窗。WebGPU 失去了各个支流浏览器的反对，因而成为 W3C 规范只是工夫问题。不过，Chrome 94 只是开始试用（origin trial），正式公布要等到 Chrome 98，工夫大略是明年 2 月份。
  • Chrome 94 是哪天公布的？2021-09-21
  • Chrome 94 更新了多少个个性？13 个，具体有哪些个性能够查看 Chrome Platform Status
  • Chrome 94 将应用哪个版本的 V8 引擎？v9.4

  • 我感兴趣的正式个性有哪些？

    • WebCodecs
    • Scheduling APIs: Prioritized scheduler.postTask
    • Idle Detection API
    • JS Self-Profiling API
    • Canvas color management，这个个性我在《了不起的 Chrome 浏览器（4）：Chrome 92 新增 at 和 randomUUID 办法，Canvas 反对 Display P3 色域》博客中介绍了，不过是我搞错了，它并不是 Chrome 92 的个性

  • 我感兴趣的试用（origin trial）个性有哪些？

    • WebGPU
    • 103 Early Hints for Navigation

具体解读

WebGPU

Chrome 94 新增了试用个性 WebGPU，提供了应用 GPU 的 Web API，能够用于图像渲染（比方 3D 渲染）以及进行数据并行计算（比方机器学习）。
​

WebGPU 对于 Web 来说无疑是一个革命性的个性，计算机行业实质上是通过摩尔定律（摩尔为 CPU 厂商 Intlel 的创始人之一）以及黄氏定律（黄氏即黄仁勋，GPU 厂商英伟达的创始人，别号核弹教父）所推动的，芯片计算能力的晋升为咱们带来历次计算机行业反动：个人电脑、互联网、挪动互联网、人工智能。当 GPU 的计算能力越来越强，越来越重要时，Web 却不能很好得利用，这显然是不合理的。
​

WebGPU 这个个性所对应的是 WebGPU 和 WebGPU Shading Language 这 2 个提案，由 Google、Mozilla 以及 Apple 的工程师负责。WebGPU 和 WebGPU Shading Language 提案都是由 W3C 的 GPU for the Web 工作组起草的，该工作组成立于 2017，通过 4 年的致力，WebGPU 终于开始试用了，也是不容易啊！WebGPU 提案定义了 Web 中应用 GPU 的 API，WebGPU Shading Language（WGSL）提案定义了 GPU 代码的编程语言。WebGPU 失去了 4 大浏览器巨头（Safari，Firefox、Edge）的反对，因而 WebGPU 成为正式的 W3C 规范只是工夫问题。
​

WebGPU 于 Chrome 94 开始试用，预计将于 Chrome 98 正式公布，工夫大略是明年 2 月份。如此重要的个性，可能大家还没来得及学会怎么应用，只试用 3 个月工夫就正式公布，仿佛有点太仓促了。
​

WebGPU 是 WebGL 的继承者，它们的指标相似，不过 WebGPU 提供了更加底层的 GPU 能力。因而，WebGPU 的图像渲染能力更强，性能更好，更易用，也更加实用于数据并行计算以及机器学习。
​

依据 Safari 的测试后果，WebGPU 的性能在各种设施上都远高于 WebGL：
​

图片起源：WebGPU and WSL in Safari
​

前端机器学习库 TensorFlow.js 也测试了一下 WebGPU，后果发现 WebGPU 的性能更好，然而差距与 WebGL 并不是特地显著，有待进一步钻研：


图片起源：Fast client-side ML with TensorFlow.js

如下图，WebGPU 是基于各种 GPU API（例如 DirectX 12、Metal、Vulkan）实现的。


图片起源：Access modern GPU features with WebGPU

WebGPU 提供的是底层 API，十分弱小，同时也非常复杂。应用 WebGPU 实现向量乘法的代码长达 200 行，目测社区将会呈现第三方库封装 WebGPU，提供更简略的应用形式用于不同的利用场景。
​

依据测试，应用 WebGPU 进行向量乘法计算时，随着向量长度减少，其性能远优于应用 CPU：


图片起源：Get started with GPU Compute on the web
​

WebCodecs

Chrome 94 正式公布了 WebCodecs，使得咱们能够间接应用 Chrome 所提供的图像、音频以及视频的编码 / 解码能力。
​

WebCodecs 为 W3C 提案，由 Google、Mozilla 以及 Microsoft 的工程师负责，于 Chrome 86 开始试用。来自 Firefox 和 Edge 的工程师独特起草了 WebCodecs 提案，因而预计该提案将最终成为 W3C 规范。
​

Codec 为coder 和decoder 合成词，即编解码器，它能够是硬件，也能够是软件，用于编码以及解码特定的数据格式，比方 MP3/AAC/VP9/H264 等。
​

浏览器器反对各种格局的图片、音频以及视频，然而之前咱们并不能间接调用相应的编解码器。WebCodecs 就是为了解决这个问题，让 Web 开发者能够间接应用各种编解码器。

为了优化性能同时放弃一致性，Google Docs 在往年 5 月份发表将迁徙至基于 Canvas 的渲染计划。不过，之前 Google Docs 在解决 GIF 时，依然应用了 HTML 的 <img> 标签。起初，Google Docs 应用了 WebCodecs 的图片编解码器 ImageDecoder 将 GIF 解码，而后再应用 Canvas 渲染，这样做优化了性能，同时简化了代码架构。
​

Zoom 在其 Web Meeting SDK 和 Web Video SDK 中应用了 WebCodecs，因为源代码并未开源，因而具体怎么应用的不得而知，应该是用到了视频相干的编解码器。值得一提的是，因为 Chrome 93 的对 WebCodes 的更新有 Breaking changes，导致 Zoom 的 Web Meeting SDK 和 Web Video SDK 呈现了 BUG，看来在第三方 SDK 中间接应用并未正式公布的个性，还是有挺大危险的。

Scheduling APIs: Prioritized scheduler.postTask

Chrome 94 正式公布了 Scheduling APIs: Prioritized scheduler.postTask 个性：
​

  • 新增了 scheduler.postTask 办法，反对依据优先级调度工作，并反对指定延时调度工作;
  • 定义了 3 个工作优先级，从高到低顺次为：user-blocking、user-visible、background;
  • 新增了 TaskController，反对动静批改工作优先级以及勾销工作;

​

Prioritized Task Scheduling 为 WICG 提案，由 Google 工程师负责，于 Chrome 86 开始试用。因为该提案暂未失去其余浏览器厂商的参加和反对，因而该个性最大的危险在于是否成为通用规范。

当咱们用 Lighthouse 检测页面时，其中一个检测项为 ”Minimize main-thread work”，它将主线程的工作分为了下图所示的 7 个分类，可知主线程所承当的工作异样沉重：

因为主线程须要负责执行的工作过多，如果主线程被低优先级工作或者耗时工作（Long Task，即执行工夫超过 50ms 的工作）适度占用，则会导致浏览器对用户操作的响应过慢，比方点击按钮长时间没有反馈，这样会极大地侵害用户体验。
​

用一个最极其的例子来举例，如果 JavaScript 代码陷入死循环，则页面将基本上齐全卡顿，无奈响应用户操作。感兴趣的话，能够在控制台执行以下代码：

while (true) {console.log("hello, Chrome!");
}

​

如果非关键 JavaScript 工作（比方日志）过多占用主线程或者要害的 JavaScript 工作（比方响应用户操作）期待太久，都会挫伤用户体验。为了优化主线程的调度，requestIdleCallback 和 isInputPending 等个性相继诞生，requestIdleCallback 能够利用主线程渲染页面的闲暇工夫执行低优先级工作，isInputPending 能够用于防止耗时工作阻塞响应用户操作。与 requestIdleCallback 和 isInputPending 相比，Prioritized Task Scheduling 提案的调度性能更加齐备和弱小，反对依据优先级调度工作，反对指定延时调度工作，反对动静批改工作优先级以及勾销工作。
​

通过应用 scheduler.postTask，Aribnb 的工程师将耗时工作拆分为小工作、推延非关键工作、预下载图片。从优化成果来看，搜寻后果页的 Total Blocking Time（TBT）从 16s 升高到了 6s，大幅优化了用户体验。不过，Total Blocking Time 的最佳值是 300ms 以内，因而 Airbnb 所做的优化看起来还不算太现实。当然，这个值应该与具体利用相干。

Aribnb 的工程师应用 Scheduling APIs 实现了图片预下载：
​

  • 当用户滑动到第 2 个搜寻后果时，提前下载了第 2 张图片；
  • 当用户滑动到第 2 个搜寻后果的第 2 张图片时，顺次提前下载了第 3、4、5 张照片；
  • 咱们能够在 Network 控制台中看到 4 个图片下载申请，依据瀑布图（Waterfall），4 个申请是依照工夫程序顺次申请的；


图片起源：[Building a Faster Web Experience with the postTask
Scheduler](https://medium.com/airbnb-eng…)

随着 Web 利用越来越简单，主线程所承当的工作越来越多，如何加重主线程累赘将成为浏览器以及 Web 开发者所面临的重大课题，依照优先级调度工作将可能成为 Web 利用以及 Web 框架的最佳实际之一。另外，相似的加重主线程累赘的提案将不断涌现，这也会进一步强化 Web 利用的能力。
​

Idle Detection API

Chrome 94 正式公布了 Idle Detection API，用于检查用户是否沉闷，其判断根据是用户是否应用键盘、鼠标、触摸屏等。
​

Idle Detection API 为 WICG 提案，由 Google 工程师负责，于 Chrome 84 开始试用，Chrome 94 正式公布。目前看来这个个性也只有 Chrome 反对，Firefox 和 Safari 出于爱护用户隐衷，都明确示意拥护该个性。
​

Apple 对于用户的隐衷及平安的保持曾经成为其企业文化的一部分，影响了它很多产品和技术上的决策，这是它不依赖广告赚钱的商业模式所决定的。依据 statcounter 的最新数据，Chrome 和 Safari 的市场份额别离为 64% 和 18%，因而 Safari 是 Chrome 最大的竞争对手。有 Safari 这样弱小的对手制约 Chrome，有利于保障 Web 的衰弱倒退。
​

集体也拥护这个个性 Idle Detection API（尽管我的拥护没啥用啊哈哈），它涉嫌进犯了用户隐衷，能够用于追踪用户的日常行为习惯，可能会用于比拟变态的场景。
​

为了爱护用户的隐衷和平安，调用 Idle Detection API 须要失去用户的受权：
​

// 获取 Idle Detection API 受权
const state = await IdleDetector.requestPermission();
if (state !== "granted") {
  // Need to request permission first.
  return console.log("Idle detection permission not granted.");
}

Idle Detection API 能够用在以下场景：对于即时聊天、社交媒体、在线游戏，检查用户是否沉闷，能够帮忙用户判断他们的联系人是否在线。事实上，聊天利用 Slack 和 Google Chat 都表白了对该个性的趣味。
​

当年 PC 版的 QQ 能够依据用户的鼠标键盘操作主动将状态切换至 ” 来到 ”，然而挪动互联网时代的聊天利用默认用户 24 小时在线。挪动互联网给用户带来便当的同时，也绑架了大家的工夫和精力，你能做到 24 小时不必手机吗？
​

Google 工程师提供了一个十分直观的 Demo 利用 Ephemeral Canvas，咱们能够用它画图，当咱们 60 秒内不操作电脑时，所画的图形会主动被擦除掉。
​

JS Self-Profiling API

Chrome 94 正式公布了 JS Self-Profiling API，用于获取 JavaScript 执行时的性能数据。
​

JS Self-Profiling API 为 WICG 提案，由 Facebook 的工程师负责，于 Chrome 78 开始试用，Chrome 94 正式公布。
​

并不意外的是，Safari 拥护该个性，起因在于性能和平安问题。性能问题比拟好了解，收集 JavaScript 执行过程中的性能数据会损耗性能。至于平安问题，Safari 工程师放心的是黑客获取 JavaScript 的编译时长从而造成可能蒙受时序攻打（Timing attack）。
​

看来，对于如何倒退 Web 技术，Chrome 与 Safari 有着十分不一样的观点，前者要激进很多，后者则绝对激进。从我写的《了不起的 Chrome 浏览器》系列博客也能够看进去，Google 工程师开发了十分多浏览器新个性，作为一个跟踪 Chrome 个性的写作者我都有点学不过去了，而对于大部分沉迷于写代码的开发者来说，很多个性可能都没听说过（此处无妨广告一下，如果你对 Chrome 的最新个性感兴趣，无妨关注我的微信公众号 寒雁 Talk）。这是 Google 和 Apple 不同的商业模式所决定的，Apple 打造了关闭而齐备 iOS/macOS/iPadOS/watchOS 生态系统，对 Web 技术的激情没有自家亲儿子那么高；而 Web 技术对于 Google，是其安身立命的基本，网页都没了，搜索引擎还搜个球啊？所以，Chrome 对于 Google 来说，远远不只是一个流量入口那么简略和无聊，Chrome 致力于推动 Web 技术向前倒退不是一句空话，Chrome 当年的产品负责人成为 Google 的 CEO 也并非偶合，对于这一点，详见我 2 年前写的博客《Chrome 是如何胜利的？》。
​

尽管 Safari 对于 JS Self-Profiling API 不感兴趣，不过，来自 Facebook 和 Microsoft 的工程师都示意通过 JS Self-Profiling API 定位到了一些十分重大的性能问题，阐明这个 API 应该还是有两把刷子的。因为 JS Self-Profiling API 并不影响产品性能，所以 Safari 不反对也没什么太大问题。反正苹果自研的芯片足够快，大略不会有性能问题？
​

Canvas color management

Chrome 94 反对在创立 2D canvas 时，应用 Display P3 色域，这将加强 2D canvas 的色彩还原能力。

canvas.getContext('2d', { colorSpace: "display-p3"} );

Canvas color management 于 Chrome 90 开始试用，Chrome 94 正式公布。这个个性我在《了不起的 Chrome 浏览器（4）：Chrome 92 新增 at 和 randomUUID 办法，Canvas 反对 Display P3 色域》博客中介绍了，不过难堪的是我搞错了，它并不是 Chrome 92 正式公布的个性。该个性失去了 Firefox 和 Safari 的反对，因而将成为通用规范。

之前，2D canvas 仅反对古老的 sRGB 色域，然而当初的屏幕和相机早就反对更大的色域了。

色域是什么呢？它的英文名是 Color Gamut 或者 Color Space，是设施（显示器、投影仪、打印机）能够表白的色彩范畴。人眼可见的色彩范畴是无限的，而设施能表白的色彩范畴是人眼可见的色彩范畴的子集，而不同色域规范比方 sRGB 和 Display P3 能表白的色彩范畴也不一样。

Display P3 的色域比 sRGB 的色域大 25%，当咱们比照两者时，会发现 Display P3 要比 sRGB 亮堂很多，区别非常明显：


图片起源：Get Started with Display P3

对于图像、视频、设计、游戏、地图、美食等利用，色彩准确性的重要性显而易见。

一些貌似与色彩无关的利用，如果咱们的利用不能精确还原物体的色彩，也是会影响业务的。大多数状况下，买家秀和卖家秀的显著差别是因为卖家适度 PS 导致的，然而也有可能是色彩没有失去精确还原导致的。

103 Early Hints for Navigation

Chrome 94 新增了试用个性 103 Early Hints for Navigation。
​

103 Early Hints for Navigation 所对应的 IETF 提案为 RFC 8297: 103 Early Hints，它实质上是对 HTTP 协定的更新，该提案由云服务商 Fastly 的工程师 Kazuho Oku 所提出。103 Early Hints for Navigation 于 Chrome 94 开始试用，正式公布的 Chrome 版本还不确定。
​

值得一提的是，Fastly 的 CDN 服务在往年 6 月份的时候出了一次故障，导致 Amazon、Hulu、Reddit、Shopify 等出名服务宕机，可见其影响力之大。Fastly 提出 103 Early Hints 也不是齐全用爱发电，这个个性也帮忙其 CDN 服务。其 CDN 节点收到源站点的 103 状态码之后，能够依据其 Header 中是否蕴含 Cache-Control: private，来提前决定是否复用 CDN 节点缓存的资源，进步响应速度。由这个简略例子也能够看出，有时候一些技术问题是没法在现有的技术标准体系内失去很好的解决，须要扭转规范自身。由此推断，中国的程序员应该更多地参加国内技术标准的制订，这是有现实意义的。当然，这么做短期来看投入产出比可能没有那么高，然而久远来看，也是必由之路吧。
​

下图十分直观地展现了 103 Early Hints for Navigation 的作用，它能够在前一个 HTTP 申请 Header 以及 response 都还没有返回的时候 preload 后续资源，从而将后续的 HTTP 申请大幅提前，从而缩小整体的申请工夫，进步网络的利用率。
​

  • 第 1 种状况：body 返回之后，解析 HTML，再去发动申请获取 css 以及 js 资源：

​

图片起源：[Towards ever faster websites with early hints and
priority hints](https://www.fastly.com/blog/f…)
​

  • 第 2 种状况：header 返回之后，body 返回之前，依据 Header 中的 preload 信息，发动申请获取 css 以及 js 资源：

​
图片起源：[Towards ever faster websites with early hints and
priority hints](https://www.fastly.com/blog/f…)
​

  • 第 3 种状况：103 状态码返回之后，依据 Header 中的 preload 信息，发动申请获取 css 以及 js 资源：

​
图片起源：[Towards ever faster websites with early hints and
priority hints](https://www.fastly.com/blog/f…)

显然，第 3 种状况下，整体的响应工夫要快很多，对网络的利用率也进步了。咱们无妨看一下第 3 种状况下，具体的申请过程。

浏览器发动拜访 example.com 的申请：
​

GET / HTTP/1.1
Host: example.com

​

服务端返回 103，Header 中蕴含 preload 信息，这时浏览器就能够发动 style.css 以及 script.js 申请了：
​

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script

​

服务端返回 200，Header 中蕴含 preload 信息，并且 html 文本中也蕴含所须要的 css 以及 js 文件（这不是废话吗？）。
​

HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script

<!doctype html>
[... rest of the response body is omitted from the example ...]

总结

从 Chrome 94 开始，Chrome 将放慢其更新频率，由每 6 周更新一个版本改为每 4 周更新一个版本。对于一个寰球领有 26 亿用户的产品，放慢公布频率能够为用户提供更好体验，同时也会为研发团队带来微小的挑战。Chrome 可能始终保持稳定的迭代频率，同时提供放弃通明，提供丰盛的文档，这为 Chrome 生态系统内的开发者提供了便当，这一点十分值得咱们学习。

本篇是《了不起的 Chrome 浏览器》的第 6 篇，发明了集体写专题系列博客的记录，之前的《JavaScript 深入浅出》系列只写了 5 篇。Chrome 放慢更新频率之后，我也必须调整本人的写作打算，与 Chrome 的版本迭代放弃同步。
​

仔细的同学可能会发现，我这篇博客有一些轻微的不同点，当前我也会保持这样做：
​

  • 开始介绍每一个 Chrome 个性所对应的规范提案，最顶级的技术公司把握技术标准，理解这些提案也十分有必要。这些提案来自不同的标准化组织，比方 W3C、WICG、IETF，目前来看，Chrome 把握了各种 Web 技术标准的主导权，这事有利有弊；
  • 开始介绍 Safari、Firefox、Edge 以及其余大公司对于各个提案的态度以及背地的商业起因，技术能够推动商业提高，商业能够影响技术倒退，两者是无奈离开的，如果只理解技术，而不了解背地的商业逻辑，也是不够的；
  • 开始对 Chrome 的某些做法表白负面认识，正如我这个系列博客的题目，整体上我对 Chrome 是持侧面态度，因为它的确彻底改变了前端生态系统，扭转了我所在的行业，影响了我集体的职业倒退，然而，这并不意味着我对 Chrome 所做的所有事件都是反对的，我会要求本人更加主观一点；
  • 开始介绍试用（origin trial）个性，Chrome 的每个版本都会公布一些试用个性，而这些试用个性往往比正式个性更重要，不容错过，这样也能够让大家第一工夫理解 Web 技术的最新发展趋势；

本文介绍 7 个个性，其中 6 个个性都波及到新的 Web 技术标准，可见 Chrome 是真的致力于 Make Web Gread Again（MWGA），Google 程序员为了 OKR 也是挺拼的。相比之下，Firefox 和 Safari 看起来要佛系很多，这与各个公司的商业模式以及投入水平无关。不过，Chrome 在把握 Web 技术的主导权之后，有点随心所欲了，有些个性不顾同行的拥护，推动速度也有点太快了，这就不太妙了。Web 与其余平台不一样的中央在于，它是凋谢的，是属于所有人的，也有向后兼容的问题，因而 Web 技术标准不能一家说了算，也不能太随便，否则对 Web 技术的久远倒退并不利。惋惜的是，当初 Web 技术标准和国内的程序员没有什么太大关系，咱们无从置喙，只能当吃瓜大众。。。等哪天国产浏览器领有更大的话语权再说吧。
​

还有一点，对于每一个个性，我都花了大量工夫浏览各种材料来了解其原理，而后依据集体了解来写的，很多个性我也没有工夫去写代码测试，因而我的说法不免有谬误的中央，欢送各位大佬批评指正。感兴趣的同学能够增加我的集体微信交换：KiwenLau。

欢送关注 寒雁 Talk公众号，关注《了不起的 Chrome 浏览器》系列博客，与我一起见证大前端的星辰大海！

参考资料

  • 了不起的 Chrome 浏览器（1）：Chrome 89 开启 Web 利用的物联网时代
  • 了不起的 Chrome 浏览器（2）：Chrome 90 将默认应用 HTTPS，Web 更平安了
  • 了不起的 Chrome 浏览器（3）：Chrome 91 反对 WebAssembly SIMD，加 Web 在 AI 等畛域的利用
  • 了不起的 Chrome 浏览器（4）：Chrome 92 新增 at 和 randomUUID 办法，Canvas 反对 Display P3 色域
  • 了不起的 Chrome 浏览器（5）：Chrome 93 反对 Error Cause，我国首个 ECMAScript 提案能够用了
  • Chrome 94 Beta: WebCodecs, WebGPU, Scheduling, and More
  • [New in Chrome 94: Color management for canvas, WebCodecs, WebGPU, and more!]()
  • V8 release v9.4
  • Intent to Ship: Scheduling APIs: Prioritized scheduler.postTask
  • Building a Faster Web Experience with the postTask Scheduler
  • Zoom on Web: getting connected with advanced web technology
  • Intent to Ship: WebCodecs
  • Chrome 93 Breaking Changes for Web Meeting/Video SDK
  • Benefits of using ImageDecoder when rendering using WebCanvas in Docs
  • Intent to Ship: VirtualKeyboard API
  • Full control with the VirtualKeyboard API
  • HTTP/2 Push is Being Removed, let us discuss
  • Intent to Remove: HTTP/2 and gQUIC server push
  • Detect inactive users with the Idle Detection API
  • Get Started with Display P3
  • Improving Color on the Web
  • Pixar in a Box: Color science
  • Access modern GPU features with WebGPU
  • Fast client-side ML with TensorFlow.js
  • Get started with GPU Compute on the web
  • RFC 8297: 103 Early Hints
  • Towards ever faster websites with early hints and priority hints

招聘

阿里巴巴业务平台事业部长期招聘 P6 及以上前端大佬，参加建设最前沿的阿里前端生态系统，推动行业技术倒退，内推地址：hanyan.lk@alibaba-inc.com

欢送大家关注我的微信公众号 寒雁 Talk。

​

退出移动版