即將推出的 chrome 95 新特性❗　從中我們能學到什麼❓

前言

為什麼會想到開始寫這類的文章呢?

我想先從大的方向來談:

Google 坐擁了全球第一大作業系統 Android 以及全球第一大瀏覽器 Chrome，67.14%市場佔有率的 Chrome 簡直可以為所欲為．

人們總是對 Google 亦步亦趨，畢竟這十年裡逐漸崛起的 Google Chrome 在眾多的瀏覽器中已經無敵手了．

對於前端開發者而言，雖然是樂意看到 Chrome 一統天下的，畢竟誰也忘不了曾經被 IE 支配的恐懼。但壟斷並不是一件好事！因為它大概率會帶來技術的停滯，IE 就是一個鮮活的例子。IE 當初脫離標準，形成自己的 API 規範的初衷，就是為了壟斷瀏覽器市場！（大家應該對壟斷心懷警惕！）

微軟 Edge 瀏覽器換用 Chromium 核心已經不是新聞了，Chromium 核心的 Edge 也已經正式釋出，雖然沒有通過 Windows Update 推送，但大家可以手動到 Edge 官網下載安裝。

開源是一個非常有效的達到合謀的方式，可以迅速的成就一個「虛擬的寡頭」乃至於造成事實上的壟斷。
高舉規範、開源(chromium)旗幟的 Chrome，正在悄悄的成為巨龍．．．

為什麼選擇從這個時候開始寫呢？

因為從 chrome95 開始，chrome 會每隔 4 周就會更新一個版本。
版本更迭之快，從中我們能嗅探到很多前沿的技術趨勢，以及未來哪些東西會面臨淘汰！

我想在之後的每一個大版本更新後,我都會第一時間把其中的重要資訊總結出來給與大家一起分享學習!

Chrome 95 測試版於 2021 年 9 月 23 日釋出，預計將於 2021 年 10 月下旬成為穩定版本。

新版本特性分享

新增特性

EyeDropper API
EyeDropper API 提供瀏覽器提供的吸管，用於構建自定義顏色選擇器。為 Web 構建的創意應用程式可以受益於從螢幕上的畫素中取樣顏色的能力。
這個可以在螢幕的任何地方取顏色哦~ 包括瀏覽器外面的區域,它有什麼好處呢?不知道大家用過 figma，或者藍湖沒有,諸如此類的 web 端 ui 設計應用,取色是一個很常用的功能項（包括我們平時開發頁面時，不需要借用其他工具去別的視窗提取ＵＩ給出的設計圖某塊區域的顏色值，現在通過這個特性就能簡單的實現！）
self.reportError API
該全域性方法可用於報告錯誤控制檯或全球事件處理程式，模擬一個未捕獲的 JavaScript 異常。
詳情
```
var newError = new Error("Some error message", "someFile.js", 11);
self.reportError(newError);

window.onerror = function(message, source, lineno, colno, error) {
    console.log("message:" + error.message + ", lineno: " + lineno);
    return true;
};

self.addEventListener("error", (error) => {
    console.log(error.filename);
});

// Output
// > "message:Some error message, lineno: 11"
// > "someFile.js"
```
此功能主要用於自定義事件排程或回撥操作庫。庫可以使用此功能來捕獲回撥程式碼中的錯誤並將它們重新丟擲到頂級處理程式。這確保了一個回撥中的異常不會阻止其他回撥的處理，同時確保堆疊跟蹤資訊仍可用於頂層除錯。
URLPattern
作為一個新的 API，提供作業系統支援，用於將 URL 與提供的模式相匹配。
詳情和MDN
除錯皮膚中對屬性值的便捷修改
DevTools 新增了一種更簡單而靈活的方式來更新 CSS 中的長度！
在“樣式”窗格中，查詢任何具有長度的 CSS 屬性（例如 height, padding）。
將滑鼠懸停在單位型別上，注意單位型別帶有下劃線。單擊它以從下拉選單中選擇一個單位型別。
配合 chrome 94 支援中文的特性,控制檯變的越來越方便 ?
改進了 DevTools 命令選單的 UI
對於經常在 chrome 中查詢頁面資源的開發者還是挺有用(ctrl+P 調出)
改進前
改進後
在 Console、Sources 皮膚和 Properties 窗格中對自定義的屬性進行加粗和排序

除了這些更改之外，“屬性”窗格中的屬性現在也被扁平化，以獲得更好的 DOM 屬性除錯體驗，尤其是對於[Web components]
對於 web component 以後有機會我單獨拎一篇文章來講，大家可以檢視這裡
Lighthouse 現在更新到了 8.4
我們都知道,網站使用體驗的三大核心指標 - LCP, FID, CLS
Lighthouse 現在將檢測 LCP 元素是否是惰性載入的影像，並建議刪除它的 loading 屬性。
影響 LCP 的四個因素如下:
- 較慢的伺服器響應時間
- 渲染阻塞的 js 和 css
- 較慢的資源載入時間
- 客戶端渲染
因為最近一項 WordPress 中延遲載入的最新研究發現，對於某些站點來說，如果初始檢視中的影像沒有延遲載入，LCP 可以提高 15%。
詳情可以看這裡
最新的 lighthouse 支援通過 npm 下載

通過命令lighthouse https://www.example.com --view

這裡我通過百度為例子,大家替換為自己想測試的站點即可

![](https://gitee.com/wangrongding/image-house/raw/master/images/202110091628536.gif)

刪除與棄用

刪除了 FTP 支援
Chrome 正在取消對 FTP URL 的支援。瀏覽器中 FTP 的使用率足夠低，投資改進現有 FTP 客戶端已不再可行。此外，所有受影響的平臺上都提供了功能更強大的 FTP 客戶端。
Google Chrome 72 及更高版本取消了對通過 FTP 獲取文件子資源和呈現頂級 FTP 資源的支援。當前導航到 FTP URL 會根據資源型別顯示目錄列表或下載。Google Chrome 74 及更高版本中的一個錯誤導致不再支援通過 HTTP 代理訪問 FTP URL。在 Google Chrome 76 中完全刪除了對 FTP 的代理支援。在 Chrome 86 中，預釋出渠道（Canary 和 Beta）的 FTP 支援被關閉，並且實驗性地關閉了百分之一的穩定使用者，儘管它可以通過命令列重新啟用. 在 Chrome 87 中，它對 50% 的使用者關閉，但也可以通過命令列啟用。從 Chrome 88 開始，它只能通過棄用試用版獲得，現在已被禁用。
FTP 支援現在被完全刪除
自 Chrome 88 以來，它只通過廢棄試驗提供，但現在已經完全取消了。
支援以數字結尾的非 IPv4 主機名的 URL
大多數不是有效 IPv4 地址但以數字結尾的主機名都被視為有效，並通過 DNS 查詢（例如，http://foo.127.1/）。根據公共字尾列表規範，該 URL 中主機名的 eTLD+1 應為127.1. 如果將其反饋到 URL 中，則由 URL 規範http://127.1/對映到http://127.0.0.1/，這似乎具有潛在危險。127.0.0.0.1也可能被用來迷惑使用者。現在拒絕帶有這些主機名的 URL。
WebAssembly 跨源模組共享
Chrome 現在不贊成在跨域但同站點的環境之間共享 WebAssembly 模組，以允許代理叢集長期作用於源。
棄用 U2F API（加密令牌）
Chrome 用於與安全金鑰互動的舊版 U2F API 已棄用，並在 Chrome 95 中開始棄用試用，其中該 API 預設保持啟用狀態，但試用令牌將禁用參與站點的金鑰。U2F 安全金鑰本身並未被棄用，並將繼續有效。
受影響的站點應遷移到Web 身份驗證 API。最初通過 U2F API 註冊的憑據可以通過 Web 身份驗證進行質詢。Web Authentication API 也支援 U2F API 支援的 USB 安全金鑰。
U2F 是 Chrome 的原始安全金鑰 API。它允許站點在 USB 安全金鑰上註冊公鑰憑據，並挑戰它們以構建防網路釣魚的兩因素身份驗證系統。U2F 從未成為開放的 Web 標準，而是被 Web 身份驗證 API（在 Chrome 67 中啟動）所包含。Chrome 從未直接支援 FIDO U2F JavaScript API，而是提供了一個名為 cryptotoken 的元件擴充套件，它公開了一個等效的chrome.runtime.sendMessage()方法。U2F 和 Cryptotoken 一直處於維護模式，並在過去兩年鼓勵站點遷移到 Web 身份驗證 API。