Googlebot 先前一直都是用 Chrome 41 版的引擎在跑，如果要考慮 SEO (for JavaScript)，就得確認網站在 Chrome 41 上面可以執行 (於是 ES6 就...)。
今天從 John Resig 的 Twitter 上看到 Googlebot 更新了引擎：「The new evergreen Googlebot」。
The day has finally arrived - Googlebot is now evergreen!!! https://t.co/pByE8WWjYT Time to drop so many polyfills, this is really exciting!
— John Resig (@jeresig) May 7, 2019
這樣針對 JS 的 SEO 省了不少事情...
前陣子看到「JavaScript Loading Priorities in Chrome」這篇，在分析 Google Chrome 對各種 JavaScript 的優先順序。
優先順序分成讀取的「Loading priority (network/Blink)」與執行的「Execution priority」，另外文章裡也有整理建議「Where should this be used?」。
看起來 <script defer> at the end of <body> 是全部裡面最低的，建議是給 Load "Related articles" 或是 "Give feedback" 這類功能，不過應該沒什麼人真的這樣用...
然後要注意的是，這邊分析的對象是 Google Chrome，實際在設計時應該要先考慮一般性的定義，再考慮對各瀏覽器的最佳化... (雖然以現在市占率來說沒什麼人想管其他瀏覽器...)
我的桌機平常都是跑 beta channel 的 Chrome，所以前陣子已經升級到 72，然後發現兩個問題：
從 dev console 可以看到問題都是 Referer 沒被送出，導致有檢查 Referer 的網站拒絕存取，後來在「chrome.webRequest」這邊發現是 Chrome 72+ 改了規則，裡面提到了：
Starting from Chrome 72, the following request headers are not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec:
Accept-Language
Accept-Encoding
Referer
CookieStarting from Chrome 72, the Set-Cookie response header is not provided and cannot be modified or removed without specifying 'extraHeaders' in opt_extraInfoSpec.
不確定這個設計的目的是什麼，但反正已經中獎了，總是得回報給各 extension 的維護者讓他們修正 (用 beta channel 的重要任務之一？)。
所以就先去 Tampermonkey 開 ticket，也很迅速的在 beta 版修正了 (所以只能先改裝 beta 版)：「GM_xmlhttpRequest unable to set referer in Chrome 72+ #629」。
另外跟 Referer Control 的開發者回報這個問題，也修正出新版上架了，更新就生效了：「refererControlDisqus.html」。
目前看起來還有「Spoofs Lang」得修，不過這個軟體好久沒更新了，不知道有沒有機會...
CECPQ1 是 Google 在研究對抗量子電腦的演算法，作為測試用的演算法，曾經在 Google Chrome 的 54 beta 版 (2016 年) 存活過一段時間，最近又開始在開發新一代的演算法 CECPQ2 了，這次會是基於 TLS 1.3 上測試：「CECPQ2」。
CECPQ2 will be moving slowly: It depends on TLS 1.3 and, as mentioned, 1.3 is taking a while. The larger messages may take some time to deploy if we hit middlebox- or server-compatibility issues. Also the messages are currently too large to include in QUIC. But working though these problems now is a lot of the reason for doing CECPQ2—to ensure that post-quantum TLS remains feasible.
目前對抗量子電腦的演算法好像都跟 Lattice 有關，找時間來補一下基礎理論... @_@
這篇文章批評了 Medium 不適合當作 Blogging Platform：「Medium is a poor choice for blogging」。
文章裡提到的情況我之前也常遇到 (然後默默的點 X 關掉...)，我是還蠻建議把 [*.]medium.com 放到 Google Chrome 的 javascript 禁止清單裡面，這樣畫面會乾淨很多，而且也省很多 CPU 資源...
不過自訂網域的部分就沒辦法用這個方式擋了，有點可惜...
Update：Apple 也宣佈了，時間點跟大家都差不多：「Deprecation of Legacy TLS 1.0 and 1.1 Versions」。
Mozilla 宣佈了「Removing Old Versions of TLS」，而 Google 也宣佈了「Modernizing Transport Security」，兩篇都是講自家瀏覽器 TLS 1.0 與 TLS 1.1 的退役時程。
Mozilla 這邊的計畫是 2020 年三月移除：
In March of 2020, Firefox will disable support for TLS 1.0 and TLS 1.1.
Google 這邊的計畫則是 Chrome 81 移除，換算成時間會從 2020 年一月開始影響到 canary channel，到 release channel 應該跟 Firefox 差不多時間：
In line with these industry standards, Google Chrome will deprecate TLS 1.0 and TLS 1.1 in Chrome 72. Sites using these versions will begin to see deprecation warnings in the DevTools console in that release. TLS 1.0 and 1.1 will be disabled altogether in Chrome 81. This will affect users on early release channels starting January 2020.
差不多試從現在開始的一年半。
雖然這是講瀏覽器端的支援，但如果伺服器想要只支援 TLS 1.2+ 的話，就得考慮一下舊 client 支援的情況了。
桌機影響會比較小 (升級比較方便，替代方案也比較多)，而行動平台看起來需要 Android 4.4+、iOS 7+，就要看各網站或是服務的族群了...
Cloudflare 決定支援 QUIC 了：「Get a head start with QUIC」、「The QUICening」。
QUIC 目前被使用的範圍比較小 (相較於 HTTP/2)：
而 Google Chrome 上面可以安裝「HTTP/2 and SPDY indicator」看到連線的狀態。雖然套件名稱沒有 QUIC，但實際上是可以看出 QUIC 的，基本上 Google 的服務應該都是走 QUIC。
最近吵的蠻凶的一個話題... 當你在 Google Chrome 瀏覽器內登入 Google 帳號後 (像是 Gmail)，你的 Google Chrome 就會自動也一起登入了。
官方目前拒絕承認這是個錯誤的設計，所以現在大家都在找 workaround 解。目前看到比較好的方式是這篇，提供了設定方式 (包括 Windows 與 Mac 平台)：「Disable Google Chrome Sign In and Sync」。
裡面有兩個步驟，第一個 SyncDisabled 設為 true 是把同步功能關掉，第二個 RestrictSigninToPattern 設為 .*@example.com 是把同時登入功能限制在 example.com 上，而這個 domain 則是在 RFC 2606 (Reserved Top Level DNS Names) 被保護起來，不開放任何單位註冊，也就是讓 Chrome 不可能找到符合的條件。
另外一個方法是跳到 Firefox，但順暢度應該還是目前最主要的障礙吧...
先前在「關閉新版 Google Chrome 網址列雞婆省略 www 的行為...」提到 Google Chrome 把 www 這些常見的 subdomain 從顯示列上移除的事情。我是因為用 beta channel 所以比較快就開始抱怨，而一般使用者在這幾天 stable channel 更新後開始收到這樣的改變，於是就爆炸了：「Incorrect transforms when stripping subdomains」。
有人直接噴這是什麼鳥蛋決策 XDDD
I actually thought Chrome was malfunctioning. This decision seems totally arbitrary. Was there any research done to justify this decision, or was it the whimsy of a PM who thought it would be a cool UX thing?
另外有人問 Google 是不是應該去開個 CVE，直接認定是安全性威脅... XD
然後一如往常的，被打上 Restrict-AddIssueComment-EditIssue 不讓其他人加意見進去了... 大概不會有下文了 XD
話說回來，這幾天測 Firefox 發現頗吃 CPU 與 GPU 的效能 (相較於 Google Chrome)，實在換不過去...
Twitter 上看到的：
I see Chrome Canary v70 is trialing the removal of EV-SSL company names, wonder if that will make it into the final release? @troyhunt pic.twitter.com/u8KkDZHPGm
— Si (@west_mill) August 29, 2018
不知道是什麼背景決定做這個實驗... 盯一下這個消息的後續發展 @_@