整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
多社交網(wǎng)站都使用無限滾動(dòng)的翻頁技術(shù)來提高用戶體驗(yàn)，當(dāng)你頁面滑到列表底部時(shí)候無需點(diǎn)擊就自動(dòng)加載更多的內(nèi)容。這個(gè)實(shí)現(xiàn)并不復(fù)雜，通過簡(jiǎn)單幾句jquery代碼就可以寫出一個(gè)滾動(dòng)到底部加載的雛形，當(dāng)然，要體驗(yàn)好一點(diǎn)，還有很多細(xì)節(jié)要特別處理的，下面為你推薦 10 個(gè) jQuery 的無限滾動(dòng)的插件：
1.jQuery ScrollPagination
jQuery ScrollPagination plugin 是一個(gè) jQuery 實(shí)現(xiàn)的支持無限滾動(dòng)加載數(shù)據(jù)的插件。
2.jQuery Screw
Screw (scroll + view) 是一個(gè) jQuery 插件當(dāng)用戶滾動(dòng)頁面的時(shí)候加載內(nèi)容，是一個(gè)無限滾動(dòng)翻頁的插件。
3.AutoBrowse jQuery Plugin
Autobrowse jQuery Plugin 插件在用戶滾動(dòng)頁面的時(shí)候自動(dòng)通過 Ajax 加載更多內(nèi)容，使用瀏覽器內(nèi)置緩存。
4.Scroll Extend Plugin
scrollExtend 插件用來在頁面滾動(dòng)到屏幕底部時(shí)自動(dòng)加載內(nèi)容并追加 DOM 元素到頁面底部，該插件其最初目的是為了跟 WordPress 集成。
5.Infinite Scroll
用了這個(gè)插件，用戶訪問你的網(wǎng)站就不用翻頁啦!實(shí)際上它是預(yù)讀了后續(xù)頁的內(nèi)容并將其直接添加到了當(dāng)前頁面。
6.Load Content While Scrolling With jQuery
該插件可幫助非常快速的加載頁面的更多內(nèi)容
7.Triggered Infinite Scroll
Triggered Infinite Scroll 是一個(gè) Twitter 風(fēng)格的自定義觸發(fā)器，不過它不是自動(dòng)的。
8.Infinite Ajax Scroll, a jQuery Plugin
Infinite Ajax Scroll 可將你現(xiàn)有的網(wǎng)頁變成支持無限滾動(dòng)的頁面，無需太麻煩就可搞定。
9.Infinite Scrolling jQuery Plugin
InfiniScroll 原先是一個(gè) 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、移動(dòng)webapp切圖，響應(yīng)式web布局，edm郵件模板制作、hybridapp切圖，微網(wǎng)站、微場(chǎng)景html制作等前端技術(shù)領(lǐng)域開發(fā)外包服務(wù)。
行 阿里云開發(fā)者 2024年07月15日 08:31 浙江
阿里妹導(dǎo)讀
對(duì)電商網(wǎng)頁的性能而言，圖片優(yōu)化是至關(guān)重要的事情，本文就此探討了一些簡(jiǎn)單、可靠的圖片優(yōu)化手段。
一、圖片對(duì)網(wǎng)頁性能優(yōu)化的重要性
對(duì)電商網(wǎng)頁的性能而言，圖片優(yōu)化是至關(guān)重要的事情，一個(gè)典型的電商網(wǎng)頁加載的圖片無論從數(shù)量還是字節(jié)數(shù)都不容小覷。
而圖片優(yōu)化的思路非常清晰明了，常見的有三個(gè)方向：
隨著圖片壓縮技術(shù)和瀏覽器渲染技術(shù)的發(fā)展，既淘汰了很多過時(shí)的圖片性能優(yōu)化技巧，又應(yīng)運(yùn)而生了不少簡(jiǎn)單、可靠的圖片優(yōu)化手段。
二、提前首屏圖片的加載時(shí)機(jī)
一般首屏使用的圖片決定了頁面的 LCP[1]指標(biāo)，首屏圖片的加載優(yōu)先級(jí)至關(guān)重要，而盡可能提前加載圖片是圖片性能優(yōu)化的首要問題。
2.1 優(yōu)化網(wǎng)絡(luò)建連
在用戶首次訪問居多的場(chǎng)景，網(wǎng)絡(luò)建連時(shí)間是一個(gè)被大部分人忽略，但至關(guān)重要的因素，也許我們的性能優(yōu)化輸在了起跑線上，這部分介紹的內(nèi)容不止對(duì)圖片加載有效，對(duì)于所有靜態(tài)資源乃至 HTML、異步接口等道理相似。
CDN 的重要性不用贅述，將內(nèi)容緩存到離用戶更近的邊緣服務(wù)器上，可以顯著提升網(wǎng)絡(luò)建連效率，當(dāng)然更重要的是使用 CDN 減少了數(shù)據(jù)在用戶和服務(wù)器之間傳輸?shù)木嚯x，大幅提升資源下載速度。
HTML 默認(rèn)支持兩種預(yù)建連機(jī)制：
<head>
<link rel="dns-prefetch" href="https://examplecdn.com">
<link rel="preconnect" href="https://examplecdn.com">
</head> 在 HTTP/1.1 協(xié)議下，由于瀏覽器通常會(huì)對(duì)每個(gè)域名并行連接數(shù)的限制（大部分瀏覽器限制在6個(gè)左右），在多個(gè)域名間分散圖片曾經(jīng)是常見的優(yōu)化手段，以此突破對(duì)單一域名的并發(fā)限制。然而這也意味著對(duì)于每個(gè)新的域名，瀏覽器必須進(jìn)行額外的 DNS 查找，并且可能需要建立新的TCP連接，這可能會(huì)增加一定的延遲。?
HTTP/2 開始支持多路復(fù)用，意味著多個(gè)請(qǐng)求可以在單個(gè)TCP連接上同時(shí)進(jìn)行，減少了對(duì)多個(gè)域名的需要。因此在 HTTP/2 環(huán)境中，收斂圖片域名反而可以優(yōu)化圖片加載，因?yàn)?
HTTP/3 是下一代 HTTP 協(xié)議，基于 QUIC（Quick UDP Internet Connections）協(xié)議。QUIC 是由 Google 開發(fā)并隨后由 IETF 標(biāo)準(zhǔn)化的傳輸層協(xié)議。HTTP/3 對(duì)網(wǎng)絡(luò)建連進(jìn)行了優(yōu)化，和建連、傳輸性能相關(guān)的主要有
2.2 流式渲染 preload
很多頁面為了性能優(yōu)化引入了 SSR 技術(shù)，這樣 HTML 請(qǐng)求發(fā)起后，頁面組建在服務(wù)器進(jìn)行渲染，完成后返回給客戶端。如果沒有配合流式渲染，會(huì)讓頁面等待服務(wù)器取數(shù)、渲染出現(xiàn)較長時(shí)間的白屏。
流式渲染通過 HTTP 1.1 引入分塊傳輸 Transfer-Encoding: chunked 特性，允許一個(gè) HTTP 的請(qǐng)求的連接中可以多次響應(yīng)，在 SSR 的場(chǎng)景中，服務(wù)端在響應(yīng)一個(gè) HTML 頁面的請(qǐng)求時(shí)至少可以拆分成兩個(gè)分塊。
<!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ù)器計(jì)算時(shí)間，頁面可以對(duì)部分域名提前建連、提前加載頁面 CSS 和 JavaScript、加載骨骼圖，等手段優(yōu)化頁面性能。
如果使用的 CDN 廠商支持邊緣計(jì)算，可以將頁面靜態(tài)部分換存在 CDN，用戶請(qǐng)求時(shí)第一時(shí)間返回，同時(shí) CDN 向源站請(qǐng)求頁面后續(xù)動(dòng)態(tài)內(nèi)容，來進(jìn)一步提升網(wǎng)頁性能。
?前端性能優(yōu)化：當(dāng)頁面渲染遇上邊緣計(jì)算-阿里云開發(fā)者社區(qū)[2]?。
2.3 fetch-priority
在 web 開發(fā)中資源的加載順序?qū)撁娴男阅苡酗@著影響。瀏覽器通常會(huì)根據(jù)資源類型、它們?cè)贖TML文檔中的位置以及一些內(nèi)部算法來決定資源加載的優(yōu)先級(jí)。然而瀏覽器的默認(rèn)優(yōu)先級(jí)可能并不總是與開發(fā)者的意圖或頁面性能最優(yōu)化的目標(biāo)一致。
fetch-priority 特性就是為了解決這個(gè)問題而提出的。通過顯式地設(shè)置資源的fetch-priority 屬性，開發(fā)者可以指示瀏覽器按照特定的優(yōu)先級(jí)順序加載資源。一般情況下圖片的加載優(yōu)先級(jí)相對(duì)較高，但為了更精準(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)先級(jí)值，high、low 和 auto（默認(rèn)）。可以應(yīng)用于各種資源，如<img>、<link>、<script>等元素。目前 Chrome、Safari、Edge 均已支持。
三、降低加載圖片的體積
在保證清晰度滿足要求的前提下，減少圖片的字節(jié)數(shù)明顯可以改善圖片加載性能。
3.1 圖片字節(jié)數(shù)的構(gòu)成
圖像的尺寸可以表示為橫向像素?cái)?shù)×縱向像素?cái)?shù)，圖像的總像素?cái)?shù)（即分辨率）是橫向像素?cái)?shù)和縱向像素?cái)?shù)的乘積。例如，一個(gè)1920×1080的圖像含有2,073,600個(gè)像素點(diǎn)，通常稱為二百萬像素。決定圖片字節(jié)數(shù)的有幾個(gè)關(guān)鍵因素。
顯然圖片格式、分辨率可以顯著影響圖片的字節(jié)數(shù)。
3.2 圖片縮放、裁剪、壓縮
根據(jù)顯示場(chǎng)景不同，調(diào)整圖片的尺寸、分辨率、質(zhì)量可以改變圖片的字節(jié)數(shù)，最常見的方法就是：
設(shè)計(jì)師、開發(fā)可以通過工具實(shí)現(xiàn)對(duì)圖片的調(diào)整，但成本略高，比較簡(jiǎn)單的做法是讓源站或者 CDN 可以根據(jù)圖片 URL 參數(shù)對(duì)圖片進(jìn)行處理。阿里云目前具備完整的圖片處理能力
有了圖片裁剪、縮放能力，在必要的時(shí)候可以響應(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)分級(jí)，并記錄到圖片域名的 cookie 中。下次用戶發(fā)起圖片請(qǐng)求，CDN 可以根據(jù) cookie 中的快慢網(wǎng)信息，決定返回給用戶的圖片質(zhì)量。
3.3 選擇合適的圖片格式
大部分 Web 開發(fā)者對(duì) WebP 格式非常熟悉了，但可能對(duì) AVIF 格式還沒有開始應(yīng)用。AVIF 是一種基于 AV1 視頻編碼的新圖像格式，用于將AV1壓縮的圖片或圖片序列存儲(chǔ)為HEIF文件格式。相對(duì)于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 邊界條件下可能會(huì)超過 JEPG。
類型 | 50分位數(shù)壓縮率 | 85分位數(shù)壓縮率 |
WebP | -30% | -20% |
AVIF | -50% | -40% |
主流瀏覽器的支持情況非常不錯(cuò)，唯一的遺憾是 Edge 還不支持。
瀏覽器在在其圖片請(qǐng)求時(shí)候會(huì)在 Accept 頭部信息中聲明支持的圖片格式，可以利用這個(gè)在 CDN 識(shí)別，使用相同的圖片地址，返回不同格式的圖片內(nèi)容。
避免前端加載 1px 透明圖判斷瀏覽器是否支持特定圖片格式，然后修改圖片 URL 來獲取對(duì)應(yīng)格式圖片。這樣的處理方式有兩個(gè)弊端:
在 Chrome Dev Tools 網(wǎng)絡(luò)面板中可以看到淘寶、京東等網(wǎng)站都已經(jīng)開始使用 AVIF 格式圖片。
3.4 堪稱雙刃劍的漸進(jìn)式加載
圖片的漸進(jìn)式加載是一種在網(wǎng)頁瀏覽過程中逐步顯示圖片的技術(shù)。圖片沒有完全下載前用戶先看到圖片的低質(zhì)量版本，然后圖片會(huì)逐漸變得更清晰，直到完全加載完成。一般有兩種做法：
圖片漸進(jìn)式加載效果類似于加強(qiáng)版的骨骼圖，然而漸進(jìn)式加載也有幾個(gè)問題
To be or not to be, that is the question.
四、減少加載圖片數(shù)量
4.1 CSS sprites 可能過時(shí)了
CSS sprites 將多個(gè)小圖像合并成一個(gè)大圖像，利用 CSS 的背景定位屬性，可以僅顯示合并圖像中相應(yīng)的部分，來代替單獨(dú)的圖像文件。減少HTTP請(qǐng)求的數(shù)量，這在HTTP/1.1時(shí)代是提升頁面加載速度的常用方法。
然而在 HTTP/2 情況發(fā)生了變化，HTTP/2 引入多路復(fù)用、頭部壓縮等特性，顯著改善了同時(shí)發(fā)送多個(gè)請(qǐng)求的性能。多路復(fù)用允許多個(gè)請(qǐng)求通過單一的TCP連接并行傳輸，減少了由于建立多個(gè)連接而產(chǎn)生的延遲。因此在HTTP/2 環(huán)境下，CSS sprites 的性能優(yōu)勢(shì)不如HTTP/1.1時(shí)那么明顯，甚至可能產(chǎn)生反效果，因?yàn)椋?/span>
同時(shí) CSS sprites 需要額外的維護(hù)工作，每當(dāng)圖像發(fā)生變化時(shí)，都需要重新生成整個(gè)sprite圖，并更新CSS定位，這使得管理起來更加復(fù)雜。在 HTTP/2 時(shí)代 CSS sprites 可能不再是性能優(yōu)化的最佳方案，icon fonts、base64 或 SVG 圖像可能是更好的選擇。
4.2 load="lazy" 不依賴 JavaScript 的懶加載
在圖片較多的場(chǎng)景通常會(huì)對(duì)非首屏圖片懶加載，一般通過 JavaScript 實(shí)現(xiàn)，現(xiàn)在大部分主流瀏覽器通過load="lazy"原生支持了圖片懶加載，使用方法也非常簡(jiǎn)便。
<img src="image-to-lazy-load.jpg" loading="lazy">這個(gè)屬性有三個(gè)可能的值：
1.lazy：?jiǎn)⒂脩屑虞d。瀏覽器會(huì)在圖片即將進(jìn)入視口時(shí)才開始加載。
2.eager：禁用懶加載。圖片會(huì)隨著頁面加載立即開始加載，無論圖片位置如何。
3.auto：瀏覽器自行決定何時(shí)加載圖片，這是默認(rèn)值。
當(dāng)對(duì)圖片設(shè)置了這個(gè)屬性后，瀏覽器會(huì)根據(jù)自己的啟發(fā)式算法決定圖片的加載時(shí)機(jī)。這些算法會(huì)考慮多個(gè)因素，比如圖片即將進(jìn)入視口的距離，或者用戶當(dāng)前的網(wǎng)絡(luò)條件等。通常啟發(fā)式算法的工作方式如下：
雖然開發(fā)者無法精準(zhǔn)控制圖片加載的時(shí)機(jī)，但瀏覽器原生支持考慮的因素不僅僅是滾動(dòng)位置，相對(duì)而言更加合理。順便說一句，使用 JavaScript 懶加載本身也有性能開銷，可能會(huì)影響到頁面的 FPS。
4.3 content-visibility 另外一種懶加載
content-visibility 是 CSS 屬性，允許瀏覽器跳過不在屏幕上的元素的渲染工作，直到用戶滾動(dòng)到它們的位置。通過跳過不可見內(nèi)容的渲染，content-visibility 可以顯著減少頁面的初始加載時(shí)間，并降低內(nèi)存的使用，從而改善用戶體驗(yàn)。配合 contain-intrinsic-size 屬性可以對(duì)容器進(jìn)行渲染前的占位。
<style>
.image-gallery {
content-visibility: auto;
contain-intrinsic-size: 1000px 500px; /* 設(shè)置一個(gè)合適的占位大小 */
}
</style>
<div class="image-gallery">
<img src="image1.jpg" alt="描述1">
<img src="image2.jpg" alt="描述2">
<!-- 更多圖片 -->
</div>content-visibility 的瀏覽器兼容性并不是非常樂觀，需要開發(fā)者在使用時(shí)候加以判斷。
4.4 decoding="async" 非首屏圖片異步解碼
解碼圖像和視頻是計(jì)算密集型的操作，可能會(huì)占用大量的CPU資源，特別是對(duì)于高分辨率或者復(fù)雜編碼格式的媒體文件，如果主線程被圖像或視頻的解碼操作阻塞，用戶在滾動(dòng)頁面或嘗試交互時(shí)可能會(huì)感受到卡頓或延遲。
對(duì)非首屏圖片或視頻添加 decoding="async" 可以允許瀏覽器在后臺(tái)處理圖片、視頻解碼，而不阻塞主線程，繼續(xù)處理和渲染頁面的其余部分，這樣可以有助于改善頁面的加載性能，減少用戶感知到的延遲，并提供更加平滑的用戶體驗(yàn)。
<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)瀏覽器。
第一個(gè)正式的 ("out-of-beta") Safari 版本于 2003 年 6 月發(fā)布。在 2005 年 4 月，Safari 成為 Mac 系統(tǒng)的默認(rèn)瀏覽器。
如同蘋果的許多產(chǎn)品，Safari 以易用和清爽的設(shè)計(jì)聞名。Safari 支持 Mac 和 Windows 系統(tǒng)。
下載 Safari
Safari 統(tǒng)計(jì)
下表是 瀏覽器統(tǒng)計(jì)信息 中關(guān)于 Safari 使用情況的細(xì)節(jié)：
| 2014 | 總計(jì) | 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 | 總計(jì) | 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 | 總計(jì) | 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 | 總計(jì) | 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 | 總計(jì) | 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 | 總計(jì) | 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 | 總計(jì) | 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)計(jì)數(shù)據(jù)是基于 W3CSchool 網(wǎng)站的用戶。
Safari 7
Safari 7/6.1 于 2013 年 6 月 10 日發(fā)布。
Safari 7（針對(duì) OS X Mavericks）和 Safari 6.1（針對(duì) Lion 和 Mountain Lion）隨著 OS X Mavericks 于 2013 年 10 月 22 日發(fā)布。
新特性：
改進(jìn)的 JavaScript 性能和內(nèi)存使用
Top 站點(diǎn)的新外觀和側(cè)邊欄（Sidebar）
iCloud Keychain - 存儲(chǔ)/生成在線使用的隨機(jī)密碼。也可以安全地存儲(chǔ)您的信用卡信息
分享鏈接的功能 - 收集了所有的分享鏈接
電源保護(hù)功能 - 在不使用插件時(shí)，暫停這些插件
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 支持 - 定時(shí)文本的軌道，媒體同步
改進(jìn)的 JavaScript 支持 - ECMA 262 版本 5.1
瀏覽權(quán)限檢測(cè)
重新設(shè)計(jì)的 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ū)動(dòng)，執(zhí)行 JavaScript 的速度比 Safari 4 快 30%。
使用 DNS 預(yù)取來加速頁面加載 - 就像 Google 的 Chrome 瀏覽器，利用 DNS（域名系統(tǒng)）預(yù)獲取功能提高了加載新網(wǎng)頁的速度，同時(shí)改進(jìn)了歷史頁面緩存，令返回到這些頁面的響應(yīng)更加快速。
Safari 閱讀器 - 通過新的可滾動(dòng)顯示的界面呈現(xiàn)文章，排除了多余的內(nèi)容和混亂的信息，不論單頁還是多頁文章都將變得更易閱讀。當(dāng) Safari 5 檢測(cè)到某篇文章時(shí)，用戶可以點(diǎn)擊智能地址欄中的閱讀器圖標(biāo)以顯示整篇文章，獲得清晰、連續(xù)不間斷的閱讀界面，并能夠?qū)⑵浞糯蟆⒋蛴』蛲ㄟ^電子郵件發(fā)送。
HTML5 特性 - 新增了十多種強(qiáng)大的 HTML5 特性，例如 HTML5 視頻的全屏回放和對(duì)隱藏式字幕的支持，可讓網(wǎng)頁開發(fā)者創(chuàng)造出富媒體體驗(yàn)。Safari 5 新增的其它 HTML5 特性包括 HTML5 地點(diǎn)標(biāo)記、HTML5 頁面分割元素、HTML5 拖拽屬性、HTML5 表單驗(yàn)證、HTML5 Ruby、HTML5 AJAX 歷史、EventSource 和 WebSocket 等。
安全擴(kuò)展 - 新的免費(fèi)的 Safari 開發(fā)者計(jì)劃允許開發(fā)者使用基于標(biāo)準(zhǔn) web 技術(shù)（例如 HTML5、CSS3 和 JavaScript）的擴(kuò)展工具來自定義和增強(qiáng) Safari 5。Safari 5 新增的擴(kuò)展創(chuàng)建器簡(jiǎn)化了擴(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（針對(duì) Mac 和 Windows） - 于 2009 年 6 月發(fā)布。
Safari 3（針對(duì) Mac 和 Windows） - 于 2007 年 10 月發(fā)布。
Safari 2（針對(duì) Mac） - 于 2005 年 4 月發(fā)布。
Safari 1（針對(duì) Mac） - 于 2003 年 6 月發(fā)布。
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
