整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

10个滚动到底部自动加载插件

多社交网站都使用无限滚动的翻页技术来提高用户体验,当你页面滑到列表底部时候无需点击就自动加载更多的内容。这个实现并不复杂,通过简单几句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 的重要性不用赘述,将内容缓存到离用户更近的边缘服务器上,可以显著提升网络建连效率,当然更重要的是使用 CDN 减少了数据在用户和服务器之间传输的距离,大幅提升资源下载速度。

预连接

HTML 默认支持两种预建连机制:

  • dns-prefetch:用来提前解析外部域名的 DNS 查询。当浏览器知道将来可能会从某个特定的外部域名请求资源时,使用 dns-prefetch 可以减少等待 DNS 查询的时间;
  • preconnect:不仅会告诉浏览器提前进行 DNS 查询,还会提前建立到资源服务器的 TCP 连接,并在使用 HTTPS 的情况下执行 TLS 握手。这意味着当浏览器实际请求资源时,它已经有了一个开放的连接,可以立即开始数据传输;
<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 环境中,收敛图片域名反而可以优化图片加载,因为:

  • 减少DNS查询:减少域名数量可以减少DNS查询次数,因为浏览器需要为每个新的域名解析IP地址。
  • 减少连接建立:多路复用使得在一个连接上并行发送请求成为可能,因此减少域名可以减少连接建立的次数和相应的延迟。
  • 提高TLS效率:对于HTTPS连接,收敛域名意味着可以在较少的TLS握手上复用连接,TLS握手是创建安全连接所必需的步骤,它在总体连接时间中占有显著份额。
  • 缓存效率:使用较少的域名可以提高缓存效率,因为浏览器可能会为每个域名分别维护缓存记录。

升级 HTTP/3

HTTP/3 是下一代 HTTP 协议,基于 QUIC(Quick UDP Internet Connections)协议。QUIC 是由 Google 开发并随后由 IETF 标准化的传输层协议。HTTP/3 对网络建连进行了优化,和建连、传输性能相关的主要有

  • 减少连接建立时间:HTTP/2 基于 TCP 和 TLS,需要多个往返时间(RTT)来完成握手。HTTP/3 使用 QUIC 协议,它将加密和传输合并为一个过程,允许在一个 RTT 完成连接建立,在最佳情况下甚至可以在零 RTT 中恢复会话。
  • 多路复用无阻塞:HTTP/2 虽然支持多路复用,但 TCP 层的队头阻塞问题仍然存在。HTTP/3 通过 QUIC 改进的多路复用能力,在 QUIC 中由于是基于数据报的 UDP,独立的流可以在其他流发生丢包时继续传输,解决了 TCP 的队头阻塞问题。
  • 快速丢包恢复和拥塞控制:QUIC 实现了更快速的丢包恢复机制。TCP 需要等待一段时间来确认丢包,而 QUIC 可以利用更精细的确认机制来迅速响应丢包情况,并相应调整拥塞控制策略。
  • 连接迁移:QUIC 支持连接迁移,允许客户端在网络环境变化(如从 Wi-Fi 切换到移动网络)时,保持现有的连接状态。在 HTTP/2 这种情况通常会导致连接中断和需要重新建连。

2.2 流式渲染 preload


很多页面为了性能优化引入了 SSR 技术,这样 HTML 请求发起后,页面组建在服务器进行渲染,完成后返回给客户端。如果没有配合流式渲染,会让页面等待服务器取数、渲染出现较长时间的白屏。

流式渲染通过 HTTP 1.1 引入分块传输 Transfer-Encoding: chunked 特性,允许一个 HTTP 的请求的连接中可以多次响应,在 SSR 的场景中,服务端在响应一个 HTML 页面的请求时至少可以拆分成两个分块。

  • 头部静态内容:页面 CSS、JavaScript、字体文件等;
  • 后续动态渲染内容;
<!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个像素点,通常称为二百万像素。决定图片字节数的有几个关键因素。

  • 分辨率:也就是我们常说的像素,表示图片在 width 和 height 分别有多少个点,16x16 表示图片一共有 256 个像素点;
  • 色深:每个像素能够显示的颜色数量。常见的色深包括8位(256色)、16位(65,536色)、24位(约1677万色,也称为真彩色)等。色深越高,每个像素需要的位数(bits)就越多;
  • 图片格式与压缩算法:图像格式决定了图片的存储和压缩方式。常见的格式包括JPEG(有损压缩)、PNG(无损压缩)、GIF(无损压缩,但限制为256色)、BMP(通常无压缩)、WEBP(支持有损和无损压缩)等。不同的压缩算法会导致不同的文件大小;
  • 文件头信息和元数据:图片文件通常包括一个文件头,其中包含了文件类型、尺寸、色深、压缩类型等基本信息。元数据包括拍摄信息(如ISO、快门速度、光圈)、版权信息、编辑历史、ICC配置文件等;

显然图片格式、分辨率可以显著影响图片的字节数。

3.2 图片缩放、裁剪、压缩


根据显示场景不同,调整图片的尺寸、分辨率、质量可以改变图片的字节数,最常见的方法就是:

  • 对图片进行剪裁:丢弃图片不会显示的部分,让图片的尺寸变小,不牺牲图片质量。
  • 调整图片的分辨率:类似 800x800 改成 400x400,过程中会对图片进行重新采样、像素去处或合并,一些像素会被去除,或者原来独立的多个像素会被合并成一个新的像素。
  • 降低图片质量:当降低图片质量时,压缩算法会更激进地减少图片中的数据量,包括减少颜色的数量、合并类似颜色或模糊细节等,因为存储的数据更少了,文件大小会显著减少。

设计师、开发可以通过工具实现对图片的调整,但成本略高,比较简单的做法是让源站或者 CDN 可以根据图片 URL 参数对图片进行处理。阿里云目前具备完整的图片处理能力

  • 图片缩放:
  • 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
  • 质量转换:
  • 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>

甚至可以每次用户加载页面,根据用户的性能表现进行快慢网分级,并记录到图片域名的 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 堪称双刃剑的渐进式加载


图片的渐进式加载是一种在网页浏览过程中逐步显示图片的技术。图片没有完全下载前用户先看到图片的低质量版本,然后图片会逐渐变得更清晰,直到完全加载完成。一般有两种做法:

  • 使用支持渐进式的图片格式:PJPEG 或者渐进式 WebP 都原生支持渐进式加载;
  • 使用小图占位,然后替换为大图;

图片渐进式加载效果类似于加强版的骨骼图,然而渐进式加载也有几个问题

  • 用户体验:渐进式图片虽然可以让用户更快看到内容,但是模糊的图片也可能导致用户感到困惑,不同用户对模糊图片的感受不同,在图片加载时间较长情况下甚至会理解为网页故障;
  • 性能开销:有限的图片格式或者加载多个图片,两种渐进式加载的方案都会增加图片体积,还会带来了文件处理、编码复杂性等开销。尤其是使用小图占位,前端替换的方案可能还会带来 LCP 指标的恶化;

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时那么明显,甚至可能产生反效果,因为:

  • 缓存效率: 如果 sprite 图中某个图像发生变化,即使其他图像没有改变,整个sprite图都需要重新下载和缓存,导致缓存失效;
  • 过度下载:当页面只需要 sprite 图中的几个图像时,仍然需要下载整个合并的图像,这可能导致不必要的数据传输;
  • 渲染性能:大型的 sprite 图可能对浏览器的渲染性能产生影响,尤其是在移动设备上,因为需要更多的 CPU和内存去处理大图像的解码、背景定位;

同时 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:浏览器自行决定何时加载图片,这是默认值。



当对图片设置了这个属性后,浏览器会根据自己的启发式算法决定图片的加载时机。这些算法会考虑多个因素,比如图片即将进入视口的距离,或者用户当前的网络条件等。通常启发式算法的工作方式如下:

  • 视口接近度:浏览器会监测页面滚动,检查懒加载图片距离视口的距离。当图片快要出现在视口内时,浏览器会开始加载图片。具体开始加载图片的距离阈值并没有统一的标准,不同的浏览器可能会有不同的实现。
  • 网络状况:一些浏览器可能会根据用户的网络状况(例如是否使用数据流量或者Wi-Fi)来决定是否提前加载图片。
  • CPU和内存使用情况:如果用户设备的CPU或内存使用率很高,浏览器可能会延迟加载图片,直到资源使用减少。
  • 电池状态:对于移动设备,浏览器可能会在电池电量充足时更积极地加载资源。

虽然开发者无法精准控制图片加载的时机,但浏览器原生支持考虑的因素不仅仅是滚动位置,相对而言更加合理。顺便说一句,使用 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 7S 6S 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 7S 6S 5S 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 6S 5S 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 5S 4S 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 5S 4S 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 4S 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 月发布。