Creeper
Creeper
@silhouettesia `fetch/XMLHttpRequest` 需要和服务器交互，必然是异步的，且是 macrotask 的。 很直观的经验：和服务器交互的时间可能很长，怎么会让当前 event loop 必须等到服务器返回才结束。 `Promise` 本身也是异步的，且不同实现可能会是 macrotask 或者 microtask，但一般是 microtask 的。 ```js new Promise((resolve)=>{ // 1. 同步 resolve，但实际是当前执行栈（execution context stack）为空（准确说只有平台代码）后才会调用 then 注册的回调——microtask resolve() // 2....
@googya ```js // 执行第 1 步 const p = new Promise(resolve => { resolve(1); // 第 1.1 步，首先输出 4 console.log(4) // 第 1.2 步，压入microtask 队列 Promise.resolve(2).then(e => console.log(e)) // 第...
> 标题：[从浏览器多进程到JS单线程，JS运行机制最全面的一次梳理](http://www.dailichun.com/2018/01/21/js_singlethread_eventloop.html) > 作者：Lichun Dai 一篇从浏览器进程/线程角度来解释浏览器环境中JS运行机制的文章，通俗易懂，对理解浏览器环境的 event loop 很有帮助。 **核心知识点：** 1. 现代浏览器（如Chrome）每个tab页对应一个独立进程，有**独立的渲染引擎（浏览器内核）实例**，内核一般包括以下线程： ``` +-------------------------------+ |+-----------------------------+| || GUI渲染线程 || || || |+-----------------------------+| | | |+-----------------------------+| || JS引擎线程 || || || |+-----------------------------+|...
### [浏览器 event loop 简易归纳：](https://html.spec.whatwg.org/multipage/webappapis.html#event-loops) #### 关于 taskQueue - 首先浏览器可以拥有不止一个 taskQueue。易于理解的一个解释是，不同 taskQueue 可以放不同类型的 task，比如处理鼠标/键盘事件的可以放一个 taskQueue，便于优先响应用户操作。（但不能*饿死*其它 taskQueue）。 - taskQueue 不是 queue，而是 set。每次取最先可以运行的 task，而不是队列头部的 task。 #### 关于运行流程（已简化） 1. 取一个 taskQueue，并且 taskQueue 有...
@spademan 我实际测了下，直接`btn.click()` 和 页面点击按钮输出不一样。  可以看到，`btn.click()` 时，两个 handler 显然合并在同一个 event loop 执行了；而在页面里点击按钮则不一样。这个是浏览器自身实现细节，我没有查到相关文档，估计要去看相关代码才能知道原因了。 我的猜测是：用户点击，是属于用户交互，浏览器认为在UI上需要立即反馈，于是每处理完一个handler，立即更新页面UI。（看看就行，别当真 😸 有官方解释可告知我）
## 基于HTTP/2的Web优化 ### 从HTTP/1.x到HTTP/2的通用优化规则 尽管HTTP/2相比HTTP/1.x有很大的不同，但有几条优化规则是仍然适用的： 1. 减少DNS查询。DNS查询需要时间，没有resolved的域名会阻塞请求。 2. 减少TCP连接。HTTP/2只使用一个TCP连接。 3. 使用CDN。使用CDN分发资源可以减少延迟。 4. 减少HTTP跳转。特别是非同一域名的跳转，需要DNS，TCP，HTTP三种开销。 5. 消除不必要的请求数据。HTTP/2压缩了Header。 6. 压缩传输的数据。gzip压缩很高效。 7. 客户端缓存资源。缓存是必要的。 8. 消除不必要的资源。激进的提前获取资源对客户端和服务端都开销巨大。 ### 因HTTP/2而不一样的优化规则 然后下面要介绍一些HTTP/1.x里推荐而HTTP/2禁止的优化。 1. Domain Sharding（域名分片）：HTTP/1.x中浏览器一般每个域名最多同时使用6个连接。每个连接都会经历3次握手，会消耗服务器资源，甚至会相互堵塞。然而1.x中我们仍然使用Domain Sharding（域名分片）来突破连接数的限制（提高并行加载能力）。 但是，多少域名合适，每个连接的资源消耗，带宽竞争，DNS查询时间等等都是问题。在HTTP/2里，多路复用完美解决问题。所以请不要在HTTP/2里使用域名分片。 2....
## 参考 - [HTTP2主页](https://http2.github.io/) - [HTTP,HTTP2.0,SPDY,HTTPS你应该知道的一些事](http://www.alloyteam.com/2016/07/httphttp2-0spdyhttps-reading-this-is-enough/) --- 朴实易懂！ - [Optimizing Application Delivery](https://hpbn.co/optimizing-application-delivery/) - [HTTP2 is here, let's optimize!](https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present?slide=id.p19) --- 超棒的PPT！ - [HTTP 2.0的那些事](http://mrpeak.cn/blog/http2/) **截图来自 HTTP2 is here, let's optimize!**
> HOLB has several causes, of which packet retransmission is one, but it's not the one relevant to HTTP and SPDY. The one relevant to HTTP and SPDY is the...
@zengyuangai Head-Of-Line Blocking 的确描述的不够准确，我更新一下。 1. *HTTP 1.0*：下个请求必须在前一个请求返回后才能发出，`request-response`对按序发生。显然，如果某个请求长时间没有返回，那么接下来的请求就全部阻塞了。 2. *HTTP 1.1*：尝试使用 pipeling 来解决，即浏览器可以一次性发出多个请求（同个域名，同一条 TCP 链接）。但 pipeling 要求返回是按序的，那么前一个请求如果很耗时（比如处理大图片），那么后面的请求即使服务器已经处理完，仍会等待前面的请求处理完才开始按序返回。所以，pipeling 只部分解决了 HOLB。 3. *HTTP 2.0*：通过多路复用解决了 HTTP 层面的 HOLB。 4. *HTTP 3*：通过 QUIC 解决了 tcp...