fix: blog

Author: Messiahhh

docs/HTML.md

@@ -2,20 +2,8 @@
 sidebarDepth: 4
 ---
 # HTML
-## 浏览器解析流程
-
-浏览器收到HTML -> 解码 -> 资源预加载 -> 解析HTML（HTML -> Token -> DOM）-> DOM和CSS Tree生成渲染树 -> 布局 -> 绘制 -> 渲染层合成。
-
-### 解码
-
-根据编码方式进行解码。
-
 ### 资源预加载
 
-在解析HTML前先获取到HTML内部的外链地址并放入请求队列当中，因此不必等到HTML解析到某行代码的时候再去加载资源。
-
-##### preload
-
 预加载资源时进入请求队列的先后顺序是根据资源在代码中出现的顺序决定的，我们也可以使用`preload`来手动调整资源的预加载顺序。
 
 ``` html
@@ -37,14 +25,12 @@ sidebarDepth: 4
 </body>
 ```
 
-### 解析HTML
+### async and defer
 
 解析HTML的时候需要注意JavaScript**脚本的执行会阻塞HTML的解析**，因此当解析HTML解析到一行外链脚本的时候，我们需要等待**脚本的加载**、再等待**脚本的执行**，才能继续后续HTML的解析。
 
 
 
-##### async and defer
-
 如果我们不希望**脚本的加载**阻塞HTML的解析，我们可以给`script`标签加上`async`或者`defer`，此时该外链脚本的加载将不会阻塞后续HTML的解析（也就是解析后续HTML的同时并行加载该脚本，当该脚本被成功加载后则会停止后续HTML的解析并开始执行该脚本）
 
 - `async`：外链脚本加载完成后会立刻停止HTML的解析并开始执行该脚本
@@ -75,56 +61,6 @@ sidebarDepth: 4
 
 
 
-### 布局
-
-定义：浏览器根据渲染树，获取每个渲染对象在屏幕上的位置和尺寸
-
-##### 重排（回流）
-
-定义：重新布局。当渲染对象的位置，尺寸，或某些属性发生改变时，浏览器重新渲染部分或全部文档的过程。
-
-可能引起重排的操作包括：
-
-1. 元素位置或尺寸发生变化。
-2. 浏览器窗口大小发生变化。
-3. 添加或删除可见的DOM元素。
-4. 查询某些属性或调用某些方法，如`clientWidth`、`clientHeight`、`scrollIntoView()`、`getComputedStyle()`、`getBoundingClientRect()`、`scrollTo()`
-
-
-
-
-### 绘制
-
-将计算好的像素点绘制到屏幕
-
-定义：重新绘制/样式的改变不改变渲染对象在文档流中的位置时（如：color, background-color的改变）浏览器重新绘制
-
-**回流一定引发重绘，重绘不一定引发回流。回流比重绘的代价要更高**。
-
-**优化手段**
-
-1. 浏览器会维护一定队列，所有引起回流或重绘的操作会放进这个队列，一定时间后会对这些操作进行批处理。
-
-   但当访问clientWidth, clientHeight之类的属性时，会刷新这个队列，所以要尽量减少这些属性的访问
-
-2. 浏览器使用的流式布局模型，避免使用table。
-
-3. 对DOM元素进行修改时，可以先使用`display: none`使其脱离文档流，再进行DOM操作，执行完再放回文档流。
-
-4. 对于复杂的动画效果，可以用`position: absolute`使其脱离文档流
-
-5. 使用CSS3中的`transform, opacity, filters`属性，启动GPU加速，这些属性的改变不会引发回流或重绘。
-
-
-
-### 渲染层合成
-
-多个绘制后的渲染层按照恰当的重叠顺序进行合并，而后生成位图，最终通过显卡展示到屏幕上。
-
-
-
-
-
 
 
 

docs/browser.md

@@ -298,7 +298,7 @@ localStorage.clear()
 
 浏览器内部的数据库，可用于存储大容量的结构化（或二进制数据）数据。目前有两个比较好用的库。
 
-#### localforage
+#### localforage库
 
 更像容量加强版的LocalStorage，感觉读写性能并不是很高，特点是在不支持IndexedDB的浏览器中会从IndexedDB实现降级成LocalStorage实现。
 
@@ -315,7 +315,7 @@ if (hasLocalCache) {
 }
 ```
 
-#### Dexie
+#### Dexie库
 
 更贴近IndexedDB底层操作，读写性能更高。
 
@@ -470,7 +470,9 @@ const data = jwt.verify(token, 'key')
 
 #### 跨站（Cross Site）
 
-同站要求两个源的顶级域和一级域都相同。
+![](../static/img/tld.png)
+
+同站要求两个源的顶级域和一级域都相同，即这里的`TLD+1`完全相同。
 
 ![](../static/img/samesite.png)
 
@@ -546,6 +548,34 @@ Access-Control-Allow-Headers: x-my-header
 
 
 
+### 跨域隔离（cross-origin isolation）
+
+为了在我们的项目中使用`SharedArrayBuffer`来实现多个线程的共享内存，我们需要开启跨域隔离，这要求我们的网站同时开启了跨源开放者政策Cross Origin Opener Policy（COOP）和跨源嵌入程序策略Cross Origin Embedder Policy（COEP），即我们返回顶级文档的响应需要带上这样的响应头：
+
+``` http
+Cross-Origin-Opener-Policy: same-origin
+Cross-Origin-Embedder-Policy: require-corp # or credentialless
+```
+
+我们可以通过`window.crossOriginIsolated`来检测当前站点是否开启了跨域隔离。
+
+#### Cross Origin Opener Policy（COOP）
+
+通常我们在某个页面通过`window.open`来打开一个新的页面时，这两个页面是共享一个渲染进程的，被打开页面可以通过`window.opener`访问父页面的上下文。通过设置COEP能够禁止跨域页面的该行为
+
+
+
+#### Cross Origin Embedder Policy（COEP）
+
+我们都知道`img`、`video`、`script`等标签加载资源是不受浏览器同源策略限制的，而通过设置COEP能够禁止这些静态资源的跨域访问。
+
+这个策略几乎使得我们的页面不可用，浏览器提供了两种方式让某个资源可以跨域访问：
+
+- CORS。服务端给对应资源返回CORS头，同时要求加载资源的标签需要带上`crossorigin=anonymous`或者`crossorigin=use-credentials`。
+- **Cross Origin Resource Policy**（CORP）。服务端给对应资源返回CORP头`Cross-Origin-Resource-Policy: cross-origin`
+
+
+
 ### JSONP
 
 简单来讲，JSONP是利用了`<script>`加载资源时不受同源策略限制。以往我们在`src`里写的是资源的地址，但这里我们是在给接口发请求，同时接口返回的文本会被我们当成JS解析。
@@ -598,7 +628,23 @@ window.on('message', function (e) {
 
 > TODO
 
+### [SharedArrayBuffer](https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer)
+
+在上文中，我们介绍了在Web Worker的多线程场景下，借助指定转移对象可以实现ArrayBuffer的零拷贝，这满足了我们部分的使用场景。但在一些情况下，我们期望主线程和Worker线程能够读写同一块内存，SharedArrayBuffer就是用来做这个的。
 
+```js
+const sab = new SharedArrayBuffer(1024);
+worker.postMessage(sab);
+```
+
+
+
+但是想要开启SharedArrayBuffer的能力，我们需要设置两个 HTTP 消息头以跨域隔离你的站点：COOP和COEP
+
+```js
+Cross-Origin-Opener-Policy: same-origin
+Cross-Origin-Embedder-Policy: require-corp
+```