10個滾動到底部自動加載插件

多社交網(wǎng)站都使用無限滾動的翻頁技術(shù)來提高用戶體驗，當(dāng)你頁面滑到列表底部時候無需點(diǎn)擊就自動加載更多的內(nèi)容。這個實現(xiàn)并不復(fù)雜，通過簡單幾句jquery代碼就可以寫出一個滾動到底部加載的雛形，當(dāng)然，要體驗好一點(diǎn)，還有很多細(xì)節(jié)要特別處理的，下面為你推薦 10 個 jQuery 的無限滾動的插件：

1.jQuery ScrollPagination

jQuery ScrollPagination plugin 是一個 jQuery 實現(xiàn)的支持無限滾動加載數(shù)據(jù)的插件。

2.jQuery Screw

Screw (scroll + view) 是一個 jQuery 插件當(dāng)用戶滾動頁面的時候加載內(nèi)容，是一個無限滾動翻頁的插件。

3.AutoBrowse jQuery Plugin

Autobrowse jQuery Plugin 插件在用戶滾動頁面的時候自動通過 Ajax 加載更多內(nèi)容，使用瀏覽器內(nèi)置緩存。

4.Scroll Extend Plugin

scrollExtend 插件用來在頁面滾動到屏幕底部時自動加載內(nèi)容并追加 DOM 元素到頁面底部，該插件其最初目的是為了跟 WordPress 集成。

5.Infinite Scroll

用了這個插件，用戶訪問你的網(wǎng)站就不用翻頁啦!實際上它是預(yù)讀了后續(xù)頁的內(nèi)容并將其直接添加到了當(dāng)前頁面。

6.Load Content While Scrolling With jQuery

該插件可幫助非常快速的加載頁面的更多內(nèi)容

7.Triggered Infinite Scroll

Triggered Infinite Scroll 是一個 Twitter 風(fēng)格的自定義觸發(fā)器，不過它不是自動的。

8.Infinite Ajax Scroll, a jQuery Plugin

Infinite Ajax Scroll 可將你現(xiàn)有的網(wǎng)頁變成支持無限滾動的頁面，無需太麻煩就可搞定。

9.Infinite Scrolling jQuery Plugin

InfiniScroll 原先是一個 jQuery 插件，用于博客的文章列表顯示，不過現(xiàn)在已經(jīng)不止這些了。

10.Unlimited Scroll using the Twitter API

-----------------------

切圖工作室始于2007年，2014年成立公司（qietu.com），是國內(nèi)最早的前端開發(fā)服務(wù)公司，提供高品質(zhì)網(wǎng)頁切圖、psd轉(zhuǎn)html5、移動webapp切圖，響應(yīng)式web布局，edm郵件模板制作、hybridapp切圖，微網(wǎng)站、微場景html制作等前端技術(shù)領(lǐng)域開發(fā)外包服務(wù)。

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

阿里妹導(dǎo)讀

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

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

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

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

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

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

二、提前首屏圖片的加載時機(jī)

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

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

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

使用 CDN

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

預(yù)連接

HTML 默認(rèn)支持兩種預(yù)建連機(jī)制：

dns-prefetch：用來提前解析外部域名的 DNS 查詢。當(dāng)瀏覽器知道將來可能會從某個特定的外部域名請求資源時，使用 dns-prefetch 可以減少等待 DNS 查詢的時間；
preconnect：不僅會告訴瀏覽器提前進(jìn)行 DNS 查詢，還會提前建立到資源服務(wù)器的 TCP 連接，并在使用 HTTPS 的情況下執(zhí)行 TLS 握手。這意味著當(dāng)瀏覽器實際請求資源時，它已經(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ā)限制。然而這也意味著對于每個新的域名，瀏覽器必須進(jìn)行額外的 DNS 查找，并且可能需要建立新的TCP連接，這可能會增加一定的延遲。?

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

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

升級 HTTP/3

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

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

2.2 流式渲染 preload

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

流式渲染通過 HTTP 1.1 引入分塊傳輸 Transfer-Encoding: chunked 特性，允許一個 HTTP 的請求的連接中可以多次響應(yīng)，在 SSR 的場景中，服務(wù)端在響應(yīng)一個 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 讓頁面提前加載首屏確定性的圖片，提升頁面圖片加載速度。當(dāng)然流式渲染不僅僅可以優(yōu)化圖片加載，充分利用服務(wù)器計算時間，頁面可以對部分域名提前建連、提前加載頁面 CSS 和 JavaScript、加載骨骼圖，等手段優(yōu)化頁面性能。

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

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

2.3 fetch-priority

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

fetch-priority 特性就是為了解決這個問題而提出的。通過顯式地設(shè)置資源的fetch-priority 屬性，開發(fā)者可以指示瀏覽器按照特定的優(yōu)先級順序加載資源。一般情況下圖片的加載優(yōu)先級相對較高，但為了更精準(zhǔn)控制，可以使用 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 屬性可以設(shè)置不同的優(yōu)先級值，high、low 和 auto（默認(rèn)）。可以應(yīng)用于各種資源，如<img>、<link>、<script>等元素。目前 Chrome、Safari、Edge 均已支持。

三、降低加載圖片的體積

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

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

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

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

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

3.2 圖片縮放、裁剪、壓縮

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

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

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

圖片縮放：
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

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

@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 標(biāo)簽：

<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)進(jìn)行快慢網(wǎng)分級，并記錄到圖片域名的 cookie 中。下次用戶發(fā)起圖片請求，CDN 可以根據(jù) cookie 中的快慢網(wǎng)信息，決定返回給用戶的圖片質(zhì)量。

3.3 選擇合適的圖片格式

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

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

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

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

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

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

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

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

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

3.4 堪稱雙刃劍的漸進(jìn)式加載

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

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

圖片漸進(jìn)式加載效果類似于加強(qiáng)版的骨骼圖，然而漸進(jìn)式加載也有幾個問題

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

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

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

4.1 CSS sprites 可能過時了

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

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

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

同時 CSS sprites 需要額外的維護(hù)工作，每當(dāng)圖像發(fā)生變化時，都需要重新生成整個sprite圖，并更新CSS定位，這使得管理起來更加復(fù)雜。在 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：啟用懶加載。瀏覽器會在圖片即將進(jìn)入視口時才開始加載。

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

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

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

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

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

4.3 content-visibility 另外一種懶加載

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

<style>
  .image-gallery {
    content-visibility: auto;
    contain-intrinsic-size: 1000px 500px; /* 設(shè)置一個合適的占位大小 */
  }
</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資源，特別是對于高分辨率或者復(fù)雜編碼格式的媒體文件，如果主線程被圖像或視頻的解碼操作阻塞，用戶在滾動頁面或嘗試交互時可能會感受到卡頓或延遲。

對非首屏圖片或視頻添加 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

afari 瀏覽器

在 2003 年 1 月，史蒂夫喬布斯（Steve Jobs）宣布蘋果正在開發(fā)自己的瀏覽器：Safari。

在此之前，Mac 系統(tǒng)使用 Netscape Navigator 或 Internet Explorer 作為其默認(rèn)瀏覽器。

第一個正式的 ("out-of-beta") Safari 版本于 2003 年 6 月發(fā)布。在 2005 年 4 月，Safari 成為 Mac 系統(tǒng)的默認(rèn)瀏覽器。

如同蘋果的許多產(chǎn)品，Safari 以易用和清爽的設(shè)計聞名。Safari 支持 Mac 和 Windows 系統(tǒng)。

下載 Safari

Safari 統(tǒng)計

下表是瀏覽器統(tǒng)計信息中關(guān)于 Safari 使用情況的細(xì)節(jié)：

2014	總計		S 7	S 6	S 5
5 月	3.8 %		3.0 %	0.7 %	0.3 %
4 月	4.0 %		2.8 %	0.8 %	0.4 %
3 月	3.9 %		2.5 %	0.9 %	0.5 %
2 月	4.0 %		2.5 %	1.0 %	0.5 %
1 月	3.9 %		2.3 %	1.1 %	0.5 %

2013	總計	S 7	S 6	S 5	S 4
12 月	3.8 %	2.2 %	1.1 %	0.5 %	0.0 %
11 月	4.0 %	2.0 %	1.4 %	0.6 %	0.0 %
10 月	3.8 %	1.0 %	2.1 %	0.7 %	0.0 %
9 月	3.9 %		3.1 %	0.8 %	0.0 %
8 月	3.9 %		3.0 %	0.9 %	0.0 %
7 月	3.6 %		2.8 %	0.8 %	0.0 %
6 月	3.9 %		3.0 %	0.9 %	0.0 %
5 月	4.0 %		2.9 %	1.0 %	0.0 %
4 月	4.0 %		2.8 %	1.1 %	0.0 %
3 月	4.1 %		2.8 %	1.2 %	0.1 %
2 月	4.1 %		2.7 %	1.3 %	0.1 %
1 月	4.2 %		2.7 %	1.4 %	0.1 %

2012	總計		S 6	S 5	S 4
12 月	4.2 %		2.6 %	1.5 %	0.1 %
11 月	4.4 %		2.6 %	1.7 %	0.1 %
10 月	4.3 %		2.3 %	1.9 %	0.1 %
9 月	4.2 %		1.9 %	2.2 %	0.1 %
8 月	4.0 %		1.4 %	2.5 %	0.1 %
7 月	3.9 %		0.2 %	3.6 %	0.1 %
6 月	4.1 %			4.0 %	0.1 %
5 月	4.3 %			4.2 %	0.1 %
4 月	4.5 %			4.4 %	0.1 %
3 月	4.4 %			4.3 %	0.1 %
2 月	4.5 %			4.4 %	0.1 %
1 月	4.3 %			4.2 %	0.1 %

2011	總計		S 5	S 4	S 3
12 月	4.2 %		4.1 %	0.1 %	0.0 %
11 月	4.2 %		4.1 %	0.1 %	0.0 %
10 月	4.2 %		4.0 %	0.2 %	0.0 %
9 月	4.0 %		3.8 %	0.2 %	0.0 %
8 月	3.8 %		3.6 %	0.2 %	0.0 %
7 月	3.6 %		3.4 %	0.2 %	0.0 %
6 月	3.7 %		3.5 %	0.2 %	0.0 %
5 月	4.0 %		3.6 %	0.3 %	0.1 %
4 月	4.1 %		3.7 %	0.3 %	0.1 %
3 月	4.0 %		3.6 %	0.3 %	0.1 %
2 月	4.1 %		3.6 %	0.4 %	0.1 %
1 月	4.0 %		3.5 %	0.4 %	0.1 %

2010	總計		S 5	S 4	S 3
12 月	3.8 %		3.2 %	0.5 %	0.1 %
11 月	4.0 %		3.1 %	0.7 %	0.2 %
10 月	3.9 %		3.1 %	0.7 %	0.1 %
9 月	3.7 %		2.9 %	0.7 %	0.1 %
8 月	3.5 %		2.6 %	0.8 %	0.1 %
7 月	3.4 %		2.3 %	1.0 %	0.1 %
6 月	3.6 %		1.4 %	2.1 %	0.1 %
5 月	3.5 %			3.3 %	0.2 %
4 月	3.7 %			3.5 %	0.2 %
3 月	3.7 %			3.5 %	0.2 %
2 月	3.8 %			3.5 %	0.3 %
1 月	3.7 %			3.4 %	0.3 %

2009	總計			S 4	S 3
12 月	3.6 %			3.3 %	0.3 %
11 月	3.8 %			3.4 %	0.4 %
10 月	3.8 %			3.3 %	0.5 %
9 月	3.6 %			3.0 %	0.6 %
8 月	3.3 %			2.6 %	0.7 %
7 月	3.3 %			2.4 %	0.9 %
6 月	3.1 %			1.7 %	1.4 %
5 月	3.0 %			0.9 %	2.1 %
4 月	3.0 %			0.9 %	2.1 %
3 月	3.1 %			1.0 %	2.1 %
2 月	3.0 %			0.2 %	2.8 %
1 月	3.0 %			0.1 %	2.9 %

2008	總計				S 3
12 月	2.7 %				2.7 %
11 月	2.7 %				2.7 %
10 月	2.8 %				2.8 %
9 月	2.7 %				2.7 %
8 月	2.6 %				2.6 %
7 月	2.5 %				2.5 %
6 月	2.6 %				2.6 %
5 月	2.4 %				2.4 %

以上統(tǒng)計數(shù)據(jù)是基于 W3CSchool 網(wǎng)站的用戶。

Safari 7

Safari 7/6.1 于 2013 年 6 月 10 日發(fā)布。

Safari 7（針對 OS X Mavericks）和 Safari 6.1（針對 Lion 和 Mountain Lion）隨著 OS X Mavericks 于 2013 年 10 月 22 日發(fā)布。

新特性：

改進(jìn)的 JavaScript 性能和內(nèi)存使用
Top 站點(diǎn)的新外觀和側(cè)邊欄（Sidebar）
iCloud Keychain - 存儲/生成在線使用的隨機(jī)密碼。也可以安全地存儲您的信用卡信息
分享鏈接的功能 - 收集了所有的分享鏈接
電源保護(hù)功能 - 在不使用插件時，暫停這些插件

Safari 6

Safari 6 于 2012 年 7 月 25 日發(fā)布。

蘋果已經(jīng)聲明："Safari 6 可以在 Mountain Lion 和 Lion 上運(yùn)行。Safari 5 可繼續(xù)在 Windows 上運(yùn)行。"

新特性：

iCloud 標(biāo)簽
Web audio API - 允許用戶在交互式的 web 應(yīng)用中創(chuàng)建音頻效果
支持 CSS 過濾器
更好的 HTML5 支持 - 定時文本的軌道，媒體同步
改進(jìn)的 JavaScript 支持 - ECMA 262 版本 5.1
瀏覽權(quán)限檢測
重新設(shè)計的 Web inspector
自定義閱讀

Safari 6 集成到 OS X Mountain Lion - 不能從蘋果網(wǎng)站或其他資源站下載。

蘋果通過 Software Update 為 OS X Lion 的用戶發(fā)布 Safari 6。蘋果不再發(fā)布 Lion 之前的 OS X 版本和 Windows 版本。

Safari 5

Safari 5 于 2010 年 6 月 7 日發(fā)布。

Safari 5 可以在 Mac 和 Windows 上運(yùn)行。

新特性：

Nitro JavaScript 引擎 - Mac 版本的 Safari 5 由 Nitro JavaScript 引擎驅(qū)動，執(zhí)行 JavaScript 的速度比 Safari 4 快 30%。
使用 DNS 預(yù)取來加速頁面加載 - 就像 Google 的 Chrome 瀏覽器，利用 DNS（域名系統(tǒng)）預(yù)獲取功能提高了加載新網(wǎng)頁的速度，同時改進(jìn)了歷史頁面緩存，令返回到這些頁面的響應(yīng)更加快速。
Safari 閱讀器 - 通過新的可滾動顯示的界面呈現(xiàn)文章，排除了多余的內(nèi)容和混亂的信息，不論單頁還是多頁文章都將變得更易閱讀。當(dāng) Safari 5 檢測到某篇文章時，用戶可以點(diǎn)擊智能地址欄中的閱讀器圖標(biāo)以顯示整篇文章，獲得清晰、連續(xù)不間斷的閱讀界面，并能夠?qū)⑵浞糯蟆⒋蛴』蛲ㄟ^電子郵件發(fā)送。
HTML5 特性 - 新增了十多種強(qiáng)大的 HTML5 特性，例如 HTML5 視頻的全屏回放和對隱藏式字幕的支持，可讓網(wǎng)頁開發(fā)者創(chuàng)造出富媒體體驗。Safari 5 新增的其它 HTML5 特性包括 HTML5 地點(diǎn)標(biāo)記、HTML5 頁面分割元素、HTML5 拖拽屬性、HTML5 表單驗證、HTML5 Ruby、HTML5 AJAX 歷史、EventSource 和 WebSocket 等。
安全擴(kuò)展 - 新的免費(fèi)的 Safari 開發(fā)者計劃允許開發(fā)者使用基于標(biāo)準(zhǔn) web 技術(shù)（例如 HTML5、CSS3 和 JavaScript）的擴(kuò)展工具來自定義和增強(qiáng) Safari 5。Safari 5 新增的擴(kuò)展創(chuàng)建器簡化了擴(kuò)展工具的開發(fā)、安裝和打包工作。為了增強(qiáng)安全性和穩(wěn)定性，Safari 的擴(kuò)展工具均運(yùn)行在沙盒中，使用 Apple 的數(shù)字證書進(jìn)行簽名，并且只運(yùn)行于瀏覽器中。
內(nèi)建 Bing 搜索 - 可選擇 Google、Yahoo! 或 Bing 作為 Safari 搜索欄的搜索服務(wù)。

更舊的 Safari 版本

Safari 4（針對 Mac 和 Windows） - 于 2009 年 6 月發(fā)布。

Safari 3（針對 Mac 和 Windows） - 于 2007 年 10 月發(fā)布。

Safari 2（針對 Mac） - 于 2005 年 4 月發(fā)布。

Safari 1（針對 Mac） - 于 2003 年 6 月發(fā)布。

在線咨詢

上一篇：Web前端性能優(yōu)化：html、css、js篇
下一篇：HTML input type=file文件選擇表單元素二三事

您的項目需求

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

整合營銷服務(wù)商

10個滾動到底部自動加載插件

使用 CDN

預(yù)連接

收斂域名

升級 HTTP/3

您的項目需求