整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
CSDN 編者按】谷歌通過官博發文稱，在通過谷歌搜索和 Chrome 瀏覽器的通力合作，以及重磅引入 Core Web Vitals（CWV，網站性能指標）后，Chrome 瀏覽器給用戶節省了 1 萬年的等待時間，以及超過 12000 年的等待網頁響應用戶輸入時間。
Chrome 作為時下主流瀏覽器，在 pc、移動端的市場占有率一直處于遙遙領先地位。近日，谷歌在 Chromium Blog 上表示，Chromium 團隊在引入 Core Web Vitals（CWV，網站性能指標）體驗優化之后，Chrome 瀏覽器（桌面版和 Android 版）已經為用戶節省了一萬年的網頁加載時間。
圖源：statcounter
谷歌在文章中介紹了 CWV 指標改進的背景、優化措施進而提升用戶體驗，讓網頁加載變得更快的同時，開發者生態系統也在努力改善網頁性能。以下是對原文的編譯。
2020 年，谷歌引入了 Web Vitals 基本質量信號，旨在確保更好的用戶體驗。如今，有 40% 的網站通過了所有的核心網絡指標，網頁加載的和響應交互都變得更加快速。借此，本文將詳細記錄這次性能優化旅程以及在瀏覽器和生態系統中實現這些成就所做的具體工作。
Chrome 對速度的追求
高效快速地提供信息和服務一直是谷歌業務的核心，也是 Chrome 團隊的工作動力。長期以來，他們注意到，即使網站在一段時間之內改善了性能，但隨著時間的推移，性能會隨之下降，即使 Chrome 搜索速度再快，當頁面加載緩慢時，用戶體驗也會受到影響。
既然無法幫助這些網站提高性能，那該如何提高用戶體驗呢？為此，谷歌搜索團隊和 Chrome 團隊展開協作，合力解決網頁性能、加載等諸多用戶體驗問題。
定義快速網絡
他們檢查了數百萬個網頁之后，給那些快速、用戶友好的網頁定義了一個公共標準（最初發布在《Web Vitals 背后的科學》），并將規范和數據發布到開放的生態系統獲取一些反饋。其次，他們還引入了核心網絡指標（CWV），諸如具有突破性指標的最大內容繪制（LCP），進而可以查看用戶在某個網頁的停留時長。
2021 年 8 月，谷歌更新了搜索排名算法，這里面考慮了是否滿足 CWV 所確定的速度和可用性標準等因素。
小改變帶來的大提升
在引入 CWV 等指標及調整后，Chrome 的平均頁面加載速度快了 166 毫秒。到目前為止，該項目已為用戶節省了超過 10000 年的網頁等待加載時間，以及超過 12000 年的等待網頁響應用戶輸入時間。而且，網絡的速度還在不斷提高。在跟蹤了符合 CWV 的導航次數改進后，他們得到了最新的數據是，移動端為 64.45%（比原來 64% 高了一點）桌面端 68.39%（原來是 67%）。Chrome 數據團隊預測年底的通過率會達到約 69%。
多項優化措施
后退/前進緩存（bfcache）旨在通過啟用即時的后退和前進導航來改善瀏覽體驗。BFCache 的命中率在 Android（3.6%）和桌面（1.8%）上逐月提高。
另一個具有特別影響的優化示例是 PreconnectOnAnchorInteraction 功能，它在指針按下而不是指針抬起時連接到來源。這個完全推出的功能在 Android/桌面上使中位數 LCP 改善了 6/10 毫秒（0.4/1%），并且跨源 LCP 在 Android 和桌面上改善了約 60 毫秒。該功能的推出還導致內容廣告收入增加了0.08%，凸顯了性能優化對用戶參與度和生態系統健康的重大影響。
預渲染功能，通過在用戶實際訪問之前對頁面進行渲染，使頁面可以立即加載。通過在地址欄直接輸入 URL 加載頁面時進行預渲染，根據平臺不同，中位數 LCP 可以提高 500-700 毫秒（14-25%），全局中位數 LCP 在所有導航中提高了 6.4 毫秒。他們目前正在推出由地址欄發起的搜索的預渲染功能。
Chrome一直在努力將后臺標簽頁保持在用戶的視線之外。在 Windows 11 上實施的后臺標簽頁限制運行于 EcoQOS，以及在 macOS 上的任務角色和 QoS 調整，已經改善了最大內容繪制（LCP）和與下一次繪制的交互（INP）。
Web 現代化能夠運行各種類型的應用程序，這也需要管理這種工作負荷。他們一直在優化多個活動標簽頁下的 Chrome，并且很高興地報告，在過去 6 個月中通過調度和爭用的改進，INP 提高了 5%，LCP 提高了 2%。
在 2022 年，他們還對 Chrome 的頁面加載代碼進行了有針對性的改進。這導致 Android 上的 LCP 提高了 10%，CWV 通過率提高了 1.5%。
Chrome的渲染器也進行了一些改進。渲染器的主線程包括 JavaScript、渲染和圖像加載的任務隊列。一些改變優化了這些任務的優先級，以實現最佳的CWV，這些改進包含：高優先級的圖像加載、延遲后優先合成、SVG 柵格優化。
Chrome 優先加載 HTML 中解析的前五個圖像的示例。這將 LCP 從 3.1 秒改善到了 2.5 秒。
對生態的影響
博客中列舉了 CWV 對給網站生態帶來的變化，其中最重要的成就是驅動超三分之一的內容管理系統 WordPress 的性能改進，對比基于 LCP 的 WordPress 6.2，WordPress 6.3 的主題加載速度提高了 27%，經典主題加載速度提高了 18% 。
通過 CWV 三項核心指標（LCP、FID、CLS）并獲得“良好”體驗的 Web 占比
在 JavaScript 框架上，Chrome Aurora 與 Next.js、Angular 和 Nuxt 合作發布基于性能為重點的功能，如 next/script 組件、NgOptimizedImage 和nuxt/google-fonts。在 2022 年，Next.js 的通過率從 20.4% 提高到 27.3%，Angular 的通過率從 7.6% 提高到 13.2%，Nuxt 的通過率從 15.8% 提高到 20.2%。
在商業方面，性能優化帶來了顯著的增長。例如，RedBus 改善了 INP，并觀察到轉化率增加了 7%。Economic Times 改善了 INP，頁面瀏覽量增加了 42%，跳出率減少了 49%。Meesho 成功將 LCP 從 6.9 秒降低到 2.5 秒，跳出率減少了 16.6%，轉化率增加了 3%。
以上所列舉的數據不僅僅只是數據變化，更多的是帶來了用戶體驗的提升。
原文地址：https://blog.chromium.org/2023/11/how-core-web-vitals-saved-users-10000.html
T之家 9 月 28 日消息，谷歌 Chrome 106 正式版更新相比 105 變化沒有那么大，但仍然包含一些有趣的功能，還棄用了一些功能。
在谷歌 Chrome 106 中棄用了三個功能。在 requestFileSystem () 方法中不推薦使用持久配額類型，因為給代碼增加了不必要的復雜性，由于其使用率低，這尤其不受歡迎； HTTP / 2 推送流將遭受同樣的命運，Chrome 將不再接收、存儲在內存中或使用此配置發送的流；同樣，Chrome 106 也放棄了對 cookie 域名屬性中的非 ASCII 字符的支持，以符合 RFC 6265bis 規范中的最新標準化。
在新功能方面，Chrome 106 一項主要改進是支持 SerialPort 中的自帶緩沖區 (BYOB)。谷歌描述如下：
“開發人員可以通過調用 getReader ({mode: 'byob'}) 來檢測對 BYOB 讀取器的支持，因為舊實現在傳遞新參數時會拋出 TypeError。BYOB（或“自帶緩沖區”）讀取器允許開發人員指定讀取數據的緩沖區，而不是為每個塊分配新緩沖區的流。除了潛在地降低內存壓力之外，這還允許開發人員控制接收到的數據量，因為流返回的數據量不能超過提供的緩沖區中空間。從端口讀取特定數量的數據能力使這個 API 對于習慣于針對串行設備的 Windows 和 POSIX API 進行編程的開發人員更加熟悉，這些 API 以同樣的“自帶緩沖區”原則運行。相比之下，當前的 API 要求開發人員針對多余的不需要的數據進行防御性編碼，而不是只讀取他們準備處理的內容。”
除此之外，無前綴 hyphenate-character 屬性 CSS 屬性現在很穩定，將隨 Chrome 106 一起提供。“-webkit-hyphenate-character”屬性將在稍后未指定的日期棄用。
Chrome 106 的另一個關鍵改進是支持 Intl.NumberFormat API v3 。此版本具有以下新功能：
添加 3 個新函數來格式化數字范圍：formatRange / formatRangeToParts / selectRange
分組枚舉
新的舍入 / 精度選項
舍入優先級
將字符串解釋為小數
舍入模式
符號顯示為負
此外，還為 WebCodecs 中的音頻和視頻接口引入了出隊回調。它允許開發人員在編碼和解碼接口中找出隊列大小是否減少，而不是設置定時函數來隨機檢查相同。
IT之家獲悉，Chrome 106 現在支持 CSS“ic”長度單位。這用于表示日文和中文字體的“相對于水象形文字的高級度量”的長度，并且已經存在于 Safari 和 Firefox 中。展望未來，CORS 將通過 Signed HTTP Exchange 在子資源預取和加載中強制執行。
此版本的 Chrome 中也有一些實驗性功能。有兩個開發者試驗被鎖定在 flag 中。第一個是將文件系統訪問 API 中的異步方法更新為同步方法。這將提高性能并為 API 帶來一致性。其次，谷歌將繼續其 UA 用戶代理減少計劃的第 5 階段。這個想法是為了提高隱私，同時減少在解析復雜的 User-Agent 字符串時出錯的機會。
同樣，兩項能力也已進入 Origin 試驗階段。匿名 iframe 提供了一種通過臨時上下文在外部 iframe 中加載文檔的方法。由于它是 Cross-Origin-Embedder-Policy (COEP) 的概括，因此消除支持 COEP 的第三方 iframe 作為嵌入到 COEP 頁面的先決條件的要求。此試用將持續到 Chrome 108。
現在也通過 Origin 試用版提供彈出式 API，它允許開發人員在 Web 應用程序之上的交互式瞬態 UI 元素。這類似于“對話框”元素，但具有新功能，例如包括光標關閉行為、彈出交互管理、動畫、事件支持和非模態模式。
接下來是 Chrome 107 瀏覽器，它將于 9 月 29 日進入 Beta 通道，并將于 10 月 25 日進入穩定版頻道。
下將以Linux為例
一、Linux安裝chrome
獲取安裝包
# wget https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm
安裝依賴
# yum install -y lsb
# yum install -y libXScrnSaver
# yum install liberation-fonts
# yum install vulkan
本地安裝
# yum localinstall google-chrome-stable_current_x86_64.rpm
命令執行完成以后可通過以下命令查看chrome的版本
# google-chrome -version
如果正常顯示chrome版本號表示我們的chrome已經安裝完成
二、生成圖片和PDF文件
1、生成圖片
#通過URL地址生成
google-chrome --headless --disable-gpu --screenshot=/data/app-server/google/2.png --window-size=630,1100 --hide-scrollbars --no-sandbox https://resource.xgjk.info/form/1660635773921_1973.html
#通過本地文件生成
google-chrome-stable --no-sandbox --headless --disable-gpu --screenshot=test.png -run-all-compositor-stages-before-draw --window-size=400,1200 /data/app-server/google/chufang.html
2、生成PDF
#通過URL地址生成
google-chrome --headless --disable-gpu --no-sandbox --print-to-pdf-no-header --print-to-pdf=/data/app-server/google/18.pdf https://resource.xgjk.info/form/1660635773921_1973.html
#通過本地文件生成
google-chrome --headless --disable-gpu --no-sandbox --print-to-pdf-no-header --print-to-pdf=/data/app-server/google/18.pdf /data/app-server/google/chufang.html
--screenshot 圖片位置
--window-size 圖片寬高
--print-to-pdf PF文件位置
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
