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