多快好省圖片批量壓縮和轉(zhuǎn)換

片的批量壓縮和轉(zhuǎn)換是我們經(jīng)常使用的一個功能，但是無論是壓縮還是轉(zhuǎn)換都是統(tǒng)一的設置。如果用戶想要對不同的文件進行不同設置的話，那么只有分批逐次進行操作才可以。但是這樣的話又會消耗太多的時間和精力去操作，為了提高效率，就要想辦法盡量減少用戶的操作步驟。

自定義設置壓縮比和格式

其實之所以遇到這樣的煩心事，主要的問題還是用戶無法自定義進行壓縮和轉(zhuǎn)換操作，所以我們只需要選擇可以自定義設置的軟件就可以了。現(xiàn)在從網(wǎng)上下載一款名為 Imagine 的工具（https://github.com/meowtec/Imagine/），解壓以后運行文件夾里面的可執(zhí)行文件即可。接下來點擊工具欄中的“添加”按鈕，在彈出的對話框中選擇需要進行壓縮或者轉(zhuǎn)換的圖片。當然用戶也可以直接在資源管理器中選擇這些文件，然后通過鼠標拖拽的方式將它們添加到窗口中進行釋放。

現(xiàn)在我們就可以在窗口列表中看到添加圖片的縮略圖，而且在每一個縮略圖的下方都可以看到“質(zhì)量”這個調(diào)整滑塊，通過它就可以進行圖片壓縮比的調(diào)整。軟件默認將“質(zhì)量”參數(shù)設置為80%，用戶可以自定義對其進行調(diào)整，當然隨著“質(zhì)量”的減小圖片的壓縮比也會隨之增大（圖1）。

另外點擊軟件界面右上角的按鈕，就可以統(tǒng)一設定不同圖片格式的輸出品質(zhì)和壓縮比（圖2）。

除此以外，在“質(zhì)量”的下方還有一個圖片格式的列表，默認情況采用的是導入圖片的格式。用戶通過它可以選擇其他的格式，進而就能完成圖片的轉(zhuǎn)換操作了。所有的設置完成以后，在任意一個預覽縮略圖上進行雙擊操作，這樣就可以看到壓縮后圖片和壓縮前圖片的對比效果了（圖3）。點擊工具欄中的“保存”按鈕，在彈出的菜單里面選擇“導出到文件夾”命令。這樣就可以在圖片轉(zhuǎn)換完成以后，將它們保存到我們指定的全新目錄里面。

批量進行自定義壓縮操作

如果用戶不喜歡下載安裝 Imagine 這款工具的話，那么還可以通過瀏覽器利用 Picdiet 這項服務來進行操作。首先通過瀏覽器打開它的頁面（https://www.picdiet.com/），點擊網(wǎng)頁最下方的“簡體中文”選項，使頁面切換到簡體中文的操作界面。接著對網(wǎng)頁中的“輸出圖像質(zhì)量”中進行調(diào)整，這個壓縮比越小的話壓縮的體積就會越小，隨之而來的就是圖片的質(zhì)量也會變得非常的差。然后點擊網(wǎng)頁里面的“選擇你的圖片”按鈕，在彈出的對話框中選擇要進行壓縮的圖片。當圖片選擇完成以后就會馬上對選擇的圖片進行壓縮操作，當壓縮操作完成以后我們可以看到圖片的壓縮信息，點擊“下載文件”按鈕后就可以將文件保存到硬盤里面了（圖4）。

小提示：由于這項服務使用了 HTML5 技術，所以它的所有操作都是在本地瀏覽器里面進行的，因此對用戶上傳的圖片沒有任何的限制。

行阿里云開發(fā)者 2024年07月15日 08:31 浙江

阿里妹導讀

對電商網(wǎng)頁的性能而言，圖片優(yōu)化是至關重要的事情，本文就此探討了一些簡單、可靠的圖片優(yōu)化手段。

一、圖片對網(wǎng)頁性能優(yōu)化的重要性

對電商網(wǎng)頁的性能而言，圖片優(yōu)化是至關重要的事情，一個典型的電商網(wǎng)頁加載的圖片無論從數(shù)量還是字節(jié)數(shù)都不容小覷。

而圖片優(yōu)化的思路非常清晰明了，常見的有三個方向：

提前首屏圖片的加載時機
降低加載圖片的體積
減少加載圖片的數(shù)量

隨著圖片壓縮技術和瀏覽器渲染技術的發(fā)展，既淘汰了很多過時的圖片性能優(yōu)化技巧，又應運而生了不少簡單、可靠的圖片優(yōu)化手段。

二、提前首屏圖片的加載時機

一般首屏使用的圖片決定了頁面的 LCP[1]指標，首屏圖片的加載優(yōu)先級至關重要，而盡可能提前加載圖片是圖片性能優(yōu)化的首要問題。

2.1 優(yōu)化網(wǎng)絡建連

在用戶首次訪問居多的場景，網(wǎng)絡建連時間是一個被大部分人忽略，但至關重要的因素，也許我們的性能優(yōu)化輸在了起跑線上，這部分介紹的內(nèi)容不止對圖片加載有效，對于所有靜態(tài)資源乃至 HTML、異步接口等道理相似。

使用 CDN

CDN 的重要性不用贅述，將內(nèi)容緩存到離用戶更近的邊緣服務器上，可以顯著提升網(wǎng)絡建連效率，當然更重要的是使用 CDN 減少了數(shù)據(jù)在用戶和服務器之間傳輸?shù)木嚯x，大幅提升資源下載速度。

預連接

HTML 默認支持兩種預建連機制：

dns-prefetch：用來提前解析外部域名的 DNS 查詢。當瀏覽器知道將來可能會從某個特定的外部域名請求資源時，使用 dns-prefetch 可以減少等待 DNS 查詢的時間；
preconnect：不僅會告訴瀏覽器提前進行 DNS 查詢，還會提前建立到資源服務器的 TCP 連接，并在使用 HTTPS 的情況下執(zhí)行 TLS 握手。這意味著當瀏覽器實際請求資源時，它已經(jīng)有了一個開放的連接，可以立即開始數(shù)據(jù)傳輸；

<head>
  <link rel="dns-prefetch" href="https://examplecdn.com">
  <link rel="preconnect" href="https://examplecdn.com">
</head>

收斂域名

在 HTTP/1.1 協(xié)議下，由于瀏覽器通常會對每個域名并行連接數(shù)的限制（大部分瀏覽器限制在6個左右），在多個域名間分散圖片曾經(jīng)是常見的優(yōu)化手段，以此突破對單一域名的并發(fā)限制。然而這也意味著對于每個新的域名，瀏覽器必須進行額外的 DNS 查找，并且可能需要建立新的TCP連接，這可能會增加一定的延遲。?

HTTP/2 開始支持多路復用，意味著多個請求可以在單個TCP連接上同時進行，減少了對多個域名的需要。因此在 HTTP/2 環(huán)境中，收斂圖片域名反而可以優(yōu)化圖片加載，因為:

減少DNS查詢：減少域名數(shù)量可以減少DNS查詢次數(shù)，因為瀏覽器需要為每個新的域名解析IP地址。
減少連接建立：多路復用使得在一個連接上并行發(fā)送請求成為可能，因此減少域名可以減少連接建立的次數(shù)和相應的延遲。
提高TLS效率：對于HTTPS連接，收斂域名意味著可以在較少的TLS握手上復用連接，TLS握手是創(chuàng)建安全連接所必需的步驟，它在總體連接時間中占有顯著份額。
緩存效率：使用較少的域名可以提高緩存效率，因為瀏覽器可能會為每個域名分別維護緩存記錄。

升級 HTTP/3

HTTP/3 是下一代 HTTP 協(xié)議，基于 QUIC（Quick UDP Internet Connections）協(xié)議。QUIC 是由 Google 開發(fā)并隨后由 IETF 標準化的傳輸層協(xié)議。HTTP/3 對網(wǎng)絡建連進行了優(yōu)化，和建連、傳輸性能相關的主要有

減少連接建立時間：HTTP/2 基于 TCP 和 TLS，需要多個往返時間（RTT）來完成握手。HTTP/3 使用 QUIC 協(xié)議，它將加密和傳輸合并為一個過程，允許在一個 RTT 完成連接建立，在最佳情況下甚至可以在零 RTT 中恢復會話。
多路復用無阻塞：HTTP/2 雖然支持多路復用，但 TCP 層的隊頭阻塞問題仍然存在。HTTP/3 通過 QUIC 改進的多路復用能力，在 QUIC 中由于是基于數(shù)據(jù)報的 UDP，獨立的流可以在其他流發(fā)生丟包時繼續(xù)傳輸，解決了 TCP 的隊頭阻塞問題。
快速丟包恢復和擁塞控制：QUIC 實現(xiàn)了更快速的丟包恢復機制。TCP 需要等待一段時間來確認丟包，而 QUIC 可以利用更精細的確認機制來迅速響應丟包情況，并相應調(diào)整擁塞控制策略。
連接遷移：QUIC 支持連接遷移，允許客戶端在網(wǎng)絡環(huán)境變化（如從 Wi-Fi 切換到移動網(wǎng)絡）時，保持現(xiàn)有的連接狀態(tài)。在 HTTP/2 這種情況通常會導致連接中斷和需要重新建連。

2.2 流式渲染 preload

很多頁面為了性能優(yōu)化引入了 SSR 技術，這樣 HTML 請求發(fā)起后，頁面組建在服務器進行渲染，完成后返回給客戶端。如果沒有配合流式渲染，會讓頁面等待服務器取數(shù)、渲染出現(xiàn)較長時間的白屏。

流式渲染通過 HTTP 1.1 引入分塊傳輸 Transfer-Encoding: chunked 特性，允許一個 HTTP 的請求的連接中可以多次響應，在 SSR 的場景中，服務端在響應一個 HTML 頁面的請求時至少可以拆分成兩個分塊。

頭部靜態(tài)內(nèi)容：頁面 CSS、JavaScript、字體文件等；
后續(xù)動態(tài)渲染內(nèi)容；

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>流式渲染優(yōu)化頁面性能</title>


  <link rel="preload" href="頁面LCP圖片地址" as="image" /> 


  <link rel='dns-prefetch' href='https://s.alicdn.com'>
  <link rel='preconnect' href='https://i.alicdn.com'>


  <link rel="stylesheet" href="頁面樣式地址">
  <script src="頁面腳本地址"></script>
</head>
<body>
<!--骨骼圖-->


<!--流式渲染后續(xù)內(nèi)容-->
  
</body>
</html>

在流式渲染首段返回內(nèi)容中可以通過 preload 讓頁面提前加載首屏確定性的圖片，提升頁面圖片加載速度。當然流式渲染不僅僅可以優(yōu)化圖片加載，充分利用服務器計算時間，頁面可以對部分域名提前建連、提前加載頁面 CSS 和 JavaScript、加載骨骼圖，等手段優(yōu)化頁面性能。

如果使用的 CDN 廠商支持邊緣計算，可以將頁面靜態(tài)部分換存在 CDN，用戶請求時第一時間返回，同時 CDN 向源站請求頁面后續(xù)動態(tài)內(nèi)容，來進一步提升網(wǎng)頁性能。

?前端性能優(yōu)化：當頁面渲染遇上邊緣計算-阿里云開發(fā)者社區(qū)[2]?。

2.3 fetch-priority

在 web 開發(fā)中資源的加載順序?qū)撁娴男阅苡酗@著影響。瀏覽器通常會根據(jù)資源類型、它們在HTML文檔中的位置以及一些內(nèi)部算法來決定資源加載的優(yōu)先級。然而瀏覽器的默認優(yōu)先級可能并不總是與開發(fā)者的意圖或頁面性能最優(yōu)化的目標一致。

fetch-priority 特性就是為了解決這個問題而提出的。通過顯式地設置資源的fetch-priority 屬性，開發(fā)者可以指示瀏覽器按照特定的優(yōu)先級順序加載資源。一般情況下圖片的加載優(yōu)先級相對較高，但為了更精準控制，可以使用 fetch-priority 調(diào)整。

<img src="important-image.png" fetch-priority="high" alt="Important Image">
<img src="less-important-image.png" fetch-priority="low" alt="Less Important Image">

fetch-priority 屬性可以設置不同的優(yōu)先級值，high、low 和 auto（默認）。可以應用于各種資源，如<img>、<link>、<script>等元素。目前 Chrome、Safari、Edge 均已支持。

三、降低加載圖片的體積

在保證清晰度滿足要求的前提下，減少圖片的字節(jié)數(shù)明顯可以改善圖片加載性能。

3.1 圖片字節(jié)數(shù)的構(gòu)成

圖像的尺寸可以表示為橫向像素數(shù)×縱向像素數(shù)，圖像的總像素數(shù)（即分辨率）是橫向像素數(shù)和縱向像素數(shù)的乘積。例如，一個1920×1080的圖像含有2,073,600個像素點，通常稱為二百萬像素。決定圖片字節(jié)數(shù)的有幾個關鍵因素。

分辨率：也就是我們常說的像素，表示圖片在 width 和 height 分別有多少個點，16x16 表示圖片一共有 256 個像素點；
色深：每個像素能夠顯示的顏色數(shù)量。常見的色深包括8位（256色）、16位（65,536色）、24位（約1677萬色，也稱為真彩色）等。色深越高，每個像素需要的位數(shù)（bits）就越多；
圖片格式與壓縮算法：圖像格式?jīng)Q定了圖片的存儲和壓縮方式。常見的格式包括JPEG（有損壓縮）、PNG（無損壓縮）、GIF（無損壓縮，但限制為256色）、BMP（通常無壓縮）、WEBP（支持有損和無損壓縮）等。不同的壓縮算法會導致不同的文件大小；
文件頭信息和元數(shù)據(jù)：圖片文件通常包括一個文件頭，其中包含了文件類型、尺寸、色深、壓縮類型等基本信息。元數(shù)據(jù)包括拍攝信息（如ISO、快門速度、光圈）、版權信息、編輯歷史、ICC配置文件等；

顯然圖片格式、分辨率可以顯著影響圖片的字節(jié)數(shù)。

3.2 圖片縮放、裁剪、壓縮

根據(jù)顯示場景不同，調(diào)整圖片的尺寸、分辨率、質(zhì)量可以改變圖片的字節(jié)數(shù)，最常見的方法就是：

對圖片進行剪裁：丟棄圖片不會顯示的部分，讓圖片的尺寸變小，不犧牲圖片質(zhì)量。
調(diào)整圖片的分辨率：類似 800x800 改成 400x400，過程中會對圖片進行重新采樣、像素去處或合并，一些像素會被去除，或者原來獨立的多個像素會被合并成一個新的像素。
降低圖片質(zhì)量：當降低圖片質(zhì)量時，壓縮算法會更激進地減少圖片中的數(shù)據(jù)量，包括減少顏色的數(shù)量、合并類似顏色或模糊細節(jié)等，因為存儲的數(shù)據(jù)更少了，文件大小會顯著減少。?

設計師、開發(fā)可以通過工具實現(xiàn)對圖片的調(diào)整，但成本略高，比較簡單的做法是讓源站或者 CDN 可以根據(jù)圖片 URL 參數(shù)對圖片進行處理。阿里云目前具備完整的圖片處理能力

圖片縮放：
https://example.com/image01.png?image_process=resize,fw_200,fh_200
圖片裁剪：
https://example.com/image01.png?image_process=crop,mid,w_400,h_200
?質(zhì)量轉(zhuǎn)換：
https://example.com/image01.png?image_process=quality,Q_90

有了圖片裁剪、縮放能力，在必要的時候可以響應式加載圖片：

@media  screen and (min-width: 1200px) {
  img {
    background-image: url('a.png?image_process=resize,fw_200,fh_200.jpg');
  }
}
@media  screen and (min-width: 1400px) {
  img {
    background-image: url('a.png?image_process=resize,fw_250,fh_250.jpg');
  }
}

也可以使用 HTML5 的 picture 標簽：

<picture>
  <source srcset="a.png?image_process=resize,fw_200,fh_200.jpg" media="(min-width: 1200px)" />
  <source srcset="a.png?image_process=resize,fw_250,fh_250.jpg" media="(min-width: 1400px)" />
  <img src="a.png?image_process=resize,fw_100,fh_100.jpg" />
</picture>?

甚至可以每次用戶加載頁面，根據(jù)用戶的性能表現(xiàn)進行快慢網(wǎng)分級，并記錄到圖片域名的 cookie 中。下次用戶發(fā)起圖片請求，CDN 可以根據(jù) cookie 中的快慢網(wǎng)信息，決定返回給用戶的圖片質(zhì)量。

3.3 選擇合適的圖片格式

大部分 Web 開發(fā)者對 WebP 格式非常熟悉了，但可能對 AVIF 格式還沒有開始應用。AVIF 是一種基于 AV1 視頻編碼的新圖像格式，用于將AV1壓縮的圖片或圖片序列存儲為HEIF文件格式。相對于JPEG，WEBP 這類圖片格式來說，它的壓縮率更高，并且畫面細節(jié)更好，AVIF vs JPEG 大小節(jié)省約 50%，AVIF vs WebP 大小節(jié)省約 20%。

?Comparing AVIF vs WebP file sizes at the same DSSIM?

以 JPEG 做基點總體來看，AVIF全面領先，甚至是邊界條件下，也表現(xiàn)較好。而 WebP 邊界條件下可能會超過 JEPG。

類型	50分位數(shù)壓縮率	85分位數(shù)壓縮率
WebP	-30%	-20%
AVIF	-50%	-40%

主流瀏覽器的支持情況非常不錯，唯一的遺憾是 Edge 還不支持。

瀏覽器在在其圖片請求時候會在 Accept 頭部信息中聲明支持的圖片格式，可以利用這個在 CDN 識別，使用相同的圖片地址，返回不同格式的圖片內(nèi)容。

避免前端加載 1px 透明圖判斷瀏覽器是否支持特定圖片格式，然后修改圖片 URL 來獲取對應格式圖片。這樣的處理方式有兩個弊端:

發(fā)起圖片請求依賴前端格式判斷的異步過程，請求時機被推遲；
使用新格式的圖片包括后期的調(diào)整等，需要修改前端代碼；

在 Chrome Dev Tools 網(wǎng)絡面板中可以看到淘寶、京東等網(wǎng)站都已經(jīng)開始使用 AVIF 格式圖片。

3.4 堪稱雙刃劍的漸進式加載

圖片的漸進式加載是一種在網(wǎng)頁瀏覽過程中逐步顯示圖片的技術。圖片沒有完全下載前用戶先看到圖片的低質(zhì)量版本，然后圖片會逐漸變得更清晰，直到完全加載完成。一般有兩種做法：

使用支持漸進式的圖片格式：PJPEG 或者漸進式 WebP 都原生支持漸進式加載；
使用小圖占位，然后替換為大圖；

圖片漸進式加載效果類似于加強版的骨骼圖，然而漸進式加載也有幾個問題

用戶體驗：漸進式圖片雖然可以讓用戶更快看到內(nèi)容，但是模糊的圖片也可能導致用戶感到困惑，不同用戶對模糊圖片的感受不同，在圖片加載時間較長情況下甚至會理解為網(wǎng)頁故障；
性能開銷：有限的圖片格式或者加載多個圖片，兩種漸進式加載的方案都會增加圖片體積，還會帶來了文件處理、編碼復雜性等開銷。尤其是使用小圖占位，前端替換的方案可能還會帶來 LCP 指標的惡化；

To be or not to be, that is the question.

四、減少加載圖片數(shù)量

4.1 CSS sprites 可能過時了

CSS sprites 將多個小圖像合并成一個大圖像，利用 CSS 的背景定位屬性，可以僅顯示合并圖像中相應的部分，來代替單獨的圖像文件。減少HTTP請求的數(shù)量，這在HTTP/1.1時代是提升頁面加載速度的常用方法。

然而在 HTTP/2 情況發(fā)生了變化，HTTP/2 引入多路復用、頭部壓縮等特性，顯著改善了同時發(fā)送多個請求的性能。多路復用允許多個請求通過單一的TCP連接并行傳輸，減少了由于建立多個連接而產(chǎn)生的延遲。因此在HTTP/2 環(huán)境下，CSS sprites 的性能優(yōu)勢不如HTTP/1.1時那么明顯，甚至可能產(chǎn)生反效果，因為：

緩存效率：如果 sprite 圖中某個圖像發(fā)生變化，即使其他圖像沒有改變，整個sprite圖都需要重新下載和緩存，導致緩存失效；
過度下載：當頁面只需要 sprite 圖中的幾個圖像時，仍然需要下載整個合并的圖像，這可能導致不必要的數(shù)據(jù)傳輸；
渲染性能：大型的 sprite 圖可能對瀏覽器的渲染性能產(chǎn)生影響，尤其是在移動設備上，因為需要更多的 CPU和內(nèi)存去處理大圖像的解碼、背景定位；

同時 CSS sprites 需要額外的維護工作，每當圖像發(fā)生變化時，都需要重新生成整個sprite圖，并更新CSS定位，這使得管理起來更加復雜。在 HTTP/2 時代 CSS sprites 可能不再是性能優(yōu)化的最佳方案，icon fonts、base64 或 SVG 圖像可能是更好的選擇。

4.2 load="lazy" 不依賴 JavaScript 的懶加載

在圖片較多的場景通常會對非首屏圖片懶加載，一般通過 JavaScript 實現(xiàn)，現(xiàn)在大部分主流瀏覽器通過load="lazy"原生支持了圖片懶加載，使用方法也非常簡便。

<img src="image-to-lazy-load.jpg" loading="lazy">

這個屬性有三個可能的值：

1.lazy：啟用懶加載。瀏覽器會在圖片即將進入視口時才開始加載。

2.eager：禁用懶加載。圖片會隨著頁面加載立即開始加載，無論圖片位置如何。

3.auto：瀏覽器自行決定何時加載圖片，這是默認值。

當對圖片設置了這個屬性后，瀏覽器會根據(jù)自己的啟發(fā)式算法決定圖片的加載時機。這些算法會考慮多個因素，比如圖片即將進入視口的距離，或者用戶當前的網(wǎng)絡條件等。通常啟發(fā)式算法的工作方式如下：

視口接近度：瀏覽器會監(jiān)測頁面滾動，檢查懶加載圖片距離視口的距離。當圖片快要出現(xiàn)在視口內(nèi)時，瀏覽器會開始加載圖片。具體開始加載圖片的距離閾值并沒有統(tǒng)一的標準，不同的瀏覽器可能會有不同的實現(xiàn)。
網(wǎng)絡狀況：一些瀏覽器可能會根據(jù)用戶的網(wǎng)絡狀況（例如是否使用數(shù)據(jù)流量或者Wi-Fi）來決定是否提前加載圖片。
CPU和內(nèi)存使用情況：如果用戶設備的CPU或內(nèi)存使用率很高，瀏覽器可能會延遲加載圖片，直到資源使用減少。
電池狀態(tài)：對于移動設備，瀏覽器可能會在電池電量充足時更積極地加載資源。?

雖然開發(fā)者無法精準控制圖片加載的時機，但瀏覽器原生支持考慮的因素不僅僅是滾動位置，相對而言更加合理。順便說一句，使用 JavaScript 懶加載本身也有性能開銷，可能會影響到頁面的 FPS。

4.3 content-visibility 另外一種懶加載

content-visibility 是 CSS 屬性，允許瀏覽器跳過不在屏幕上的元素的渲染工作，直到用戶滾動到它們的位置。通過跳過不可見內(nèi)容的渲染，content-visibility 可以顯著減少頁面的初始加載時間，并降低內(nèi)存的使用，從而改善用戶體驗。配合 contain-intrinsic-size 屬性可以對容器進行渲染前的占位。

<style>
  .image-gallery {
    content-visibility: auto;
    contain-intrinsic-size: 1000px 500px; /* 設置一個合適的占位大小 */
  }
</style>


<div class="image-gallery">
  <img src="image1.jpg" alt="描述1">
  <img src="image2.jpg" alt="描述2">
  <!-- 更多圖片 -->
</div>

content-visibility 的瀏覽器兼容性并不是非常樂觀，需要開發(fā)者在使用時候加以判斷。

4.4 decoding="async" 非首屏圖片異步解碼

解碼圖像和視頻是計算密集型的操作，可能會占用大量的CPU資源，特別是對于高分辨率或者復雜編碼格式的媒體文件，如果主線程被圖像或視頻的解碼操作阻塞，用戶在滾動頁面或嘗試交互時可能會感受到卡頓或延遲。

對非首屏圖片或視頻添加 decoding="async" 可以允許瀏覽器在后臺處理圖片、視頻解碼，而不阻塞主線程，繼續(xù)處理和渲染頁面的其余部分，這樣可以有助于改善頁面的加載性能，減少用戶感知到的延遲，并提供更加平滑的用戶體驗。

<img src="image.jpg" decoding="async">

參考鏈接：

[1]https://web.dev/articles/lcp?hl=zh-cn

[2]https://developer.aliyun.com/article/762599

文簡介

點贊 + 關注 + 收藏 = 學會了

在線咨詢

上一篇：什么是HTML
下一篇：掌握 onmouseover 事件：打造動態(tài) HTML 體驗

您的項目需求

*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。

整合營銷服務商

多快好省 圖片批量壓縮和轉(zhuǎn)換

使用 CDN

預連接

收斂域名

升級 HTTP/3

文簡介

您的項目需求

多快好省圖片批量壓縮和轉(zhuǎn)換