三种 Polyfill 构建文件大小比较

直接 import
@babel/polyfill (corejs2, deprecated): 87.5 KiB
core-js/stable (corejs3): 153 KiB
core-js/stable & regenerator-runtime/runtime (corejs3 & async function): 160 KiB

preset-env with useBuiltIns: 'usage'
core-js@3: 19.4 KiB
core-js@3 & regenerator-runtime: 48.1 KiB

plugin-transform-runtime
corejs3: 19.3 KiB
corejs3 & regenerator: 52.8 KiB

笨蛋 Bot (@bendan_bot)

写了个 Bot，支持 Serverless 部署到 Vercel，也可以部署到服务器，后面会添加其它功能。https://github.com/sxyazi/bendan


补充：如果需要 /pin 功能，可以注册个免费的 MongoDB Atlas。

“以下言论与IP无关”，一个新梗出现了😥

在 Record & Tuple 中存储 Object

Record/Tuple 可能会在不久后作为新的 primitive type 出现在 Node.js 中，它们与 Object/Array 相似，但它们是 immutable 的。

这意味着在 Record/Tuple 中不能包含 Object 或是 Array，但这种要求时常存在。一种解决方案是，将需要存储的对象放到一个 WeakMap 中，并以 Symbol 作为 key，而在 Record/Tuple 中仅保留这个 key。

值得注意的是，目前 WeakMap 并不支持以 Symbol 为 key，因此需要使用 Map 替代。

#learning

这两天在学习 Web 性能优化，收集了一些评估页面性能（或辅助优化）的工具。

在线工具
WebPageTest
PageSpeed Insights
Search Console
GTmetrix

浏览器工具
Lighthouse
speedline
DevTools performance tab

库
web-vitals
lazysizes
react-window
Guess.js

CI
bundlesize
lighthouse-ci
critical
critters

#learning

#看了什么 https://mp.weixin.qq.com/s/iR2L1j82soWKqr_SoM7aQg

#看了什么 https://web.dev/debug-web-vitals-in-the-field/

介绍了3种核心性能指标的现场测量方式，以及如何定位这些元素。

刚发现惘抑云有道云笔记多了个 付费加速功能，但支持的网站非常有限。为此在一款笔记软件里，硬塞了个浏览器进去，太怪了（

哦本来就是电子垃圾啊，那没事了

所有可能导致浏览器 reflow 的属性或方法

https://gist.github.com/paulirish/5d52fb081b3570c81e3a

两种异步 CSS 加载方案的细微区别

为了避免 DOM 构建被 non-critical CSS 的加载阻塞，有两种常见的异步加载方案。其一（preload）：
<link rel="preload" as="style" href="style.css" onload="this.rel='stylesheet'">

其二（media query）：
<link rel="stylesheet" href="style.css" media="print" onload="this.media='all'">

media query 方案，除了有更好的浏览器兼容性，在加载时机上也和 preload 有细微的区别：

被标记为 preload 的资源，拥有最高的加载优先级，因此很可能导致其它重要资源的下载时机被剥夺，这可能也并非是 non-critical CSS 所需要的。

#learning

几个 Web 营销里的名词

Tags：标签，包括 pixels、custom templates、custom HTML tags

Pixels：通常是一个 1x1px 的透明 GIF 图片，该图片由广告商提供，在图片加载时会携带广告商 server cookies，以及原站的广告标识符（出现在图片 URL 中）

Tag manager：标签管理器，无需修改网站代码，就可以添加和更新网站加载的第三方代码。如 Google Tag Manager

#learning

fetch() keepalive 的出现背景

keepalive 的出现，是为了替代 sendBeacon。

sendBeacon 的功能十分有限，它仅支持 POST 请求，并且不支持设置 request headers，在 CORS 请求上也有一些问题。

在目前的 Chromium 中，sendBeacon 是基于 keepalive 实现的，并在遥远的将来，sendBeacon 会被废弃。

#learning

这个有意思，测量 Embedded content 在不同 viewport sizes 的最小高度，提前生成 CSS，从而避免 CLS

https://github.com/GoogleChromeLabs/layout-shift-terminator

#tools

Google 是怎样定义 CLS 测量的

首先存在两个概念：帧之间的 CLS，下面简称“帧CLS”；会话之间的 CLS，下面简称“会话CLS”。

帧 CLS：使用 PerformanceObserver API，指定 type 为 layout-shift。这由浏览器提供支持，它计算元素由“一个已渲染帧”变更到“下个已渲染帧”的“CLS 分数”，换句话说，它是每帧间的变化差度。

会话 CLS：帧 CLS 往往不能直接使用，为了更加准确，需要再由用户引入 Session（或 Window）的概念，目前 Google 对其定义是：单个会话中每帧间隔最长 1s、每个会话最长 5s、“会话CLS”为每个“帧CLS”累加、仅报告“最大会话CLS”。

看到这里，或许会有一个疑问：为什么要分为“帧CLS”、“会话CLS”两个东西，直接一个 PerformanceObserver API 搞定不也挺好？

原因是，帧 CLS 的算法不会变，但会话 CLS 会随着时间不断进步，也许以后对会话的定义就不是 1s/5s 了，但若集成在浏览器中，老版本的浏览器将无法得到更新，因此决定由用户计算会话 CLS 得分。

#learning