在開發(fā)中可能會遇到多個 JSONP 請求的回調(diào)函數(shù)名是相同的，這時候就需要自己封裝一個 JSONP，以下是簡單實現(xiàn)

function jsonp(url, jsonpCallback, success) {
  let script = document.createElement("script");
  script.src = url;
  script.async = true;
  script.type = "text/javascript";
  window[jsonpCallback] = function(data) {
    success && success(data);
  };
  document.body.appendChild(script);
}
jsonp(
  "http://xxx",
  "callback",
  function(value) {
    console.log(value);
  }
);

CORS需要瀏覽器和后端同時支持。IE 8 和 9 需要通過 XDomainRequest 來實現(xiàn)。

瀏覽器會自動進(jìn)行 CORS 通信，實現(xiàn)CORS通信的關(guān)鍵是后端。只要后端實現(xiàn)了 CORS，就實現(xiàn)了跨域。

服務(wù)端設(shè)置 Access-Control-Allow-Origin 就可以開啟 CORS。 該屬性表示哪些域名可以訪問資源，如果設(shè)置通配符則表示所有網(wǎng)站都可以訪問資源。

該方式只能用于二級域名相同的情況下，比如 a.test.com 和 b.test.com 適用于該方式。

只需要給頁面添加 document.domain = "test.com" 表示二級域名都相同就可以實現(xiàn)跨域

這種方式通常用于獲取嵌入頁面中的第三方頁面數(shù)據(jù)。一個頁面發(fā)送消息，另一個頁面判斷來源并接收消息

// 發(fā)送消息端
window.parent.postMessage("message", "http://test.com");
// 接收消息端
var mc = new MessageChannel();
mc.addEventListener("message", (event) => {
    var origin = event.origin || event.originalEvent.origin; 
    if (origin === "http://test.com") {
        console.log("驗證通過")
    }
});

眾所周知 JS 是門非阻塞單線程語言，因為在最初 JS 就是為了和瀏覽器交互而誕生的。如果 JS 是門多線程的語言話，我們在多個線程中處理 DOM 就可能會發(fā)生問題（一個線程中新加節(jié)點，另一個線程中刪除節(jié)點），當(dāng)然可以引入讀寫鎖解決這個問題。

JS 在執(zhí)行的過程中會產(chǎn)生執(zhí)行環(huán)境，這些執(zhí)行環(huán)境會被順序的加入到執(zhí)行棧中。如果遇到異步的代碼，會被掛起并加入到 Task（有多種 task） 隊列中。一旦執(zhí)行棧為空，Event Loop 就會從 Task 隊列中拿出需要執(zhí)行的代碼并放入執(zhí)行棧中執(zhí)行，所以本質(zhì)上來說 JS 中的異步還是同步行為。

console.log("script start");

setTimeout(function() {
  console.log("setTimeout");
}, 0);

console.log("script end");

以上代碼雖然 setTimeout 延時為 0，其實還是異步。這是因為 HTML5 標(biāo)準(zhǔn)規(guī)定這個函數(shù)第二個參數(shù)不得小于 4 毫秒，不足會自動增加。所以 setTimeout 還是會在 script end 之后打印。

不同的任務(wù)源會被分配到不同的 Task 隊列中，任務(wù)源可以分為 微任務(wù)（microtask） 和 宏任務(wù)（macrotask）。在 ES6 規(guī)范中，microtask 稱為 jobs，macrotask 稱為 task。

console.log("script start");

setTimeout(function() {
  console.log("setTimeout");
}, 0);

new Promise((resolve) => {
    console.log("Promise")
    resolve()
}).then(function() {
  console.log("promise1");
}).then(function() {
  console.log("promise2");
});

console.log("script end");
// script start => Promise => script end => promise1 => promise2 => setTimeout

以上代碼雖然 setTimeout 寫在 Promise 之前，但是因為 Promise 屬于微任務(wù)而 setTimeout 屬于宏任務(wù)，所以會有以上的打印。

微任務(wù)包括 process.nextTick ，promise ，Object.observe ，MutationObserver

宏任務(wù)包括 script ， setTimeout ，setInterval ，setImmediate ，I/O ，UI rendering

很多人有個誤區(qū)，認(rèn)為微任務(wù)快于宏任務(wù)，其實是錯誤的。因為宏任務(wù)中包括了 script ，瀏覽器會先執(zhí)行一個宏任務(wù)，接下來有異步代碼的話就先執(zhí)行微任務(wù)。

所以正確的一次 Event loop 順序是這樣的

執(zhí)行同步代碼，這屬于宏任務(wù)

執(zhí)行棧為空，查詢是否有微任務(wù)需要執(zhí)行

執(zhí)行所有微任務(wù)

必要的話渲染 UI

然后開始下一輪 Event loop，執(zhí)行宏任務(wù)中的異步代碼

通過上述的 Event loop 順序可知，如果宏任務(wù)中的異步代碼有大量的計算并且需要操作 DOM 的話，為了更快的 界面響應(yīng)，我們可以把操作 DOM 放入微任務(wù)中。

Node 中的 Event loop 和瀏覽器中的不相同。

Node 的 Event loop 分為6個階段，它們會按照順序反復(fù)運(yùn)行

┌───────────────────────┐
┌─>│        timers         │
│  └──────────┬────────────┘
│  ┌──────────┴────────────┐
│  │     I/O callbacks     │
│  └──────────┬────────────┘
│  ┌──────────┴────────────┐
│  │     idle, prepare     │
│  └──────────┬────────────┘      ┌───────────────┐
│  ┌──────────┴────────────┐      │   incoming:   │
│  │         poll          │<──connections───     │
│  └──────────┬────────────┘      │   data, etc.  │
│  ┌──────────┴────────────┐      └───────────────┘
│  │        check          │
│  └──────────┬────────────┘
│  ┌──────────┴────────────┐
└──┤    close callbacks    │
   └───────────────────────┘

timers 階段會執(zhí)行 setTimeout 和 setInterval

一個 timer 指定的時間并不是準(zhǔn)確時間，而是在達(dá)到這個時間后盡快執(zhí)行回調(diào)，可能會因為系統(tǒng)正在執(zhí)行別的事務(wù)而延遲。

下限的時間有一個范圍：[1, 2147483647] ，如果設(shè)定的時間不在這個范圍，將被設(shè)置為1。

I/O 階段會執(zhí)行除了 close 事件，定時器和 setImmediate 的回調(diào)

idle, prepare 階段內(nèi)部實現(xiàn)

poll 階段很重要，這一階段中，系統(tǒng)會做兩件事情

執(zhí)行到點的定時器

執(zhí)行 poll 隊列中的事件

并且當(dāng) poll 中沒有定時器的情況下，會發(fā)現(xiàn)以下兩件事情

如果 poll 隊列不為空，會遍歷回調(diào)隊列并同步執(zhí)行，直到隊列為空或者系統(tǒng)限制

如果 poll 隊列為空，會有兩件事發(fā)生

如果有 setImmediate 需要執(zhí)行，poll 階段會停止并且進(jìn)入到 check 階段執(zhí)行 setImmediate

如果沒有 setImmediate 需要執(zhí)行，會等待回調(diào)被加入到隊列中并立即執(zhí)行回調(diào)

如果有別的定時器需要被執(zhí)行，會回到 timer 階段執(zhí)行回調(diào)。

check 階段執(zhí)行 setImmediate

close callbacks 階段執(zhí)行 close 事件

并且在 Node 中，有些情況下的定時器執(zhí)行順序是隨機(jī)的

setTimeout(() => {
    console.log("setTimeout");
}, 0);
setImmediate(() => {
    console.log("setImmediate");
})
// 這里可能會輸出 setTimeout，setImmediate
// 可能也會相反的輸出，這取決于性能
// 因為可能進(jìn)入 event loop 用了不到 1 毫秒，這時候會執(zhí)行 setImmediate
// 否則會執(zhí)行 setTimeout

當(dāng)然在這種情況下，執(zhí)行順序是相同的

var fs = require("fs")

fs.readFile(__filename, () => {
    setTimeout(() => {
        console.log("timeout");
    }, 0);
    setImmediate(() => {
        console.log("immediate");
    });
});
// 因為 readFile 的回調(diào)在 poll 中執(zhí)行
// 發(fā)現(xiàn)有 setImmediate ，所以會立即跳到 check 階段執(zhí)行回調(diào)
// 再去 timer 階段執(zhí)行 setTimeout
// 所以以上輸出一定是 setImmediate，setTimeout

上面介紹的都是 macrotask 的執(zhí)行情況，microtask 會在以上每個階段完成后立即執(zhí)行。

setTimeout(()=>{
    console.log("timer1")

    Promise.resolve().then(function() {
        console.log("promise1")
    })
}, 0)

setTimeout(()=>{
    console.log("timer2")

    Promise.resolve().then(function() {
        console.log("promise2")
    })
}, 0)

// 以上代碼在瀏覽器和 node 中打印情況是不同的
// 瀏覽器中一定打印 timer1, promise1, timer2, promise2
// node 中可能打印 timer1, timer2, promise1, promise2
// 也可能打印 timer1, promise1, timer2, promise2

Node 中的 process.nextTick 會先于其他 microtask 執(zhí)行。

setTimeout(() => {
  console.log("timer1");

  Promise.resolve().then(function() {
    console.log("promise1");
  });
}, 0);

process.nextTick(() => {
  console.log("nextTick");
});
// nextTick, timer1, promise1

從上表可以看到，cookie 已經(jīng)不建議用于存儲。如果沒有大量數(shù)據(jù)存儲需求的話，可以使用 localStorage 和 sessionStorage 。對于不怎么改變的數(shù)據(jù)盡量使用 localStorage 存儲，否則可以用 sessionStorage 存儲。

對于 cookie，我們還需要注意安全性。

Service workers 本質(zhì)上充當(dāng)Web應(yīng)用程序與瀏覽器之間的代理服務(wù)器，也可以在網(wǎng)絡(luò)可用時作為瀏覽器和網(wǎng)絡(luò)間的代理。它們旨在（除其他之外）使得能夠創(chuàng)建有效的離線體驗，攔截網(wǎng)絡(luò)請求并基于網(wǎng)絡(luò)是否可用以及更新的資源是否駐留在服務(wù)器上來采取適當(dāng)?shù)膭幼鳌Ｋ麄冞€允許訪問推送通知和后臺同步API。

目前該技術(shù)通常用來做緩存文件，提高首屏速度，可以試著來實現(xiàn)這個功能。

// index.js
if (navigator.serviceWorker) {
  navigator.serviceWorker
    .register("sw.js")
    .then(function(registration) {
      console.log("service worker 注冊成功");
    })
    .catch(function(err) {
      console.log("servcie worker 注冊失敗");
    });
}
// sw.js
// 監(jiān)聽 `install` 事件，回調(diào)中緩存所需文件
self.addEventListener("install", e => {
  e.waitUntil(
    caches.open("my-cache").then(function(cache) {
      return cache.addAll(["./index.html", "./index.js"]);
    })
  );
});

// 攔截所有請求事件
// 如果緩存中已經(jīng)有請求的數(shù)據(jù)就直接用緩存，否則去請求數(shù)據(jù)
self.addEventListener("fetch", e => {
  e.respondWith(
    caches.match(e.request).then(function(response) {
      if (response) {
        return response;
      }
      console.log("fetch source");
    })
  );
});

打開頁面，可以在開發(fā)者工具中的 Application 看到 Service Worker 已經(jīng)啟動了

在 Cache 中也可以發(fā)現(xiàn)我們所需的文件已被緩存

當(dāng)我們重新刷新頁面可以發(fā)現(xiàn)我們緩存的數(shù)據(jù)是從 Service Worker 中讀取的

瀏覽器的渲染機(jī)制一般分為以下幾個步驟

處理 HTML 并構(gòu)建 DOM 樹。

處理 CSS 構(gòu)建 CSSOM 樹。

將 DOM 與 CSSOM 合并成一個渲染樹。

根據(jù)渲染樹來布局，計算每個節(jié)點的位置。

調(diào)用 GPU 繪制，合成圖層，顯示在屏幕上。

在構(gòu)建 CSSOM 樹時，會阻塞渲染，直至 CSSOM 樹構(gòu)建完成。并且構(gòu)建 CSSOM 樹是一個十分消耗性能的過程，所以應(yīng)該盡量保證層級扁平，減少過度層疊，越是具體的 CSS 選擇器，執(zhí)行速度越慢。

當(dāng) HTML 解析到 script 標(biāo)簽時，會暫停構(gòu)建 DOM，完成后才會從暫停的地方重新開始。也就是說，如果你想首屏渲染的越快，就越不應(yīng)該在首屏就加載 JS 文件。并且 CSS 也會影響 JS 的執(zhí)行，只有當(dāng)解析完樣式表才會執(zhí)行 JS，所以也可以認(rèn)為這種情況下，CSS 也會暫停構(gòu)建 DOM。

Load 事件觸發(fā)代表頁面中的 DOM，CSS，JS，圖片已經(jīng)全部加載完畢。

DOMContentLoaded 事件觸發(fā)代表初始的 HTML 被完全加載和解析，不需要等待 CSS，JS，圖片加載。

一般來說，可以把普通文檔流看成一個圖層。特定的屬性可以生成一個新的圖層。不同的圖層渲染互不影響，所以對于某些頻繁需要渲染的建議多帶帶生成一個新圖層，提高性能。但也不能生成過多的圖層，會引起反作用。

通過以下幾個常用屬性可以生成新圖層

3D 變換：translate3d、translateZ

will-change

video、iframe 標(biāo)簽

通過動畫實現(xiàn)的 opacity 動畫轉(zhuǎn)換

position: fixed

重繪和回流是渲染步驟中的一小節(jié)，但是這兩個步驟對于性能影響很大。

重繪是當(dāng)節(jié)點需要更改外觀而不會影響布局的，比如改變 color 就叫稱為重繪

回流是布局或者幾何屬性需要改變就稱為回流。

回流必定會發(fā)生重繪，重繪不一定會引發(fā)回流。回流所需的成本比重繪高的多，改變深層次的節(jié)點很可能導(dǎo)致父節(jié)點的一系列回流。

所以以下幾個動作可能會導(dǎo)致性能問題：

改變 window 大小

改變字體

添加或刪除樣式

文字改變

定位或者浮動

盒模型

很多人不知道的是，重繪和回流其實和 Event loop 有關(guān)。

當(dāng) Event loop 執(zhí)行完 Microtasks 后，會判斷 document 是否需要更新。因為瀏覽器是 60Hz 的刷新率，每 16ms 才會更新一次。

然后判斷是否有 resize 或者 scroll ，有的話會去觸發(fā)事件，所以 resize 和 scroll 事件也是至少 16ms 才會觸發(fā)一次，并且自帶節(jié)流功能。

判斷是否觸發(fā)了 media query

更新動畫并且發(fā)送事件

判斷是否有全屏操作事件

執(zhí)行 requestAnimationFrame 回調(diào)

執(zhí)行 IntersectionObserver 回調(diào)，該方法用于判斷元素是否可見，可以用于懶加載上，但是兼容性不好

更新界面

以上就是一幀中可能會做的事情。如果在一幀中有空閑時間，就會去執(zhí)行 requestIdleCallback 回調(diào)。

以上內(nèi)容來自于 HTML 文檔

使用 translate 替代 top

使用 visibility 替換 display: none ，因為前者只會引起重繪，后者會引發(fā)回流（改變了布局）

把 DOM 離線后修改，比如：先把 DOM 給 display:none (有一次 Reflow)，然后你修改100次，然后再把它顯示出來

不要把 DOM 結(jié)點的屬性值放在一個循環(huán)里當(dāng)成循環(huán)里的變量

for(let i = 0; i < 1000; i++) {
    // 獲取 offsetTop 會導(dǎo)致回流，因為需要去獲取正確的值
    console.log(document.querySelector(".test").style.offsetTop)
}

不要使用 table 布局，可能很小的一個小改動會造成整個 table 的重新布局

動畫實現(xiàn)的速度的選擇，動畫速度越快，回流次數(shù)越多，也可以選擇使用 requestAnimationFrame

CSS 選擇符從右往左匹配查找，避免 DOM 深度過深

將頻繁運(yùn)行的動畫變?yōu)閳D層，圖層能夠阻止該節(jié)點回流影響別的元素。比如對于 video 標(biāo)簽，瀏覽器會自動將該節(jié)點變?yōu)閳D層。

文章來源：
https://github.com/InterviewMap/CS-Interview-Knowledge-Map/blob/master/Browser/browser-ch.md