多媒体：图像与影片

媒体，换句话说就是图像跟影片，平均占了网站超过 70%的下载流量。以下载的效能来考虑的话，减少媒体数量和档案大小是一个简单可以实现的目标。 这篇文章聚焦在优化图像跟影片来改善网站的效能。

备注

这是一篇进阶的在 web 上优化多媒体的介绍，包含基本的原则还有技巧，想了更多的话，可以看 https://images.guide。

---

为什么要优化你的多媒体

对于平均的网站, 51% 的频宽消耗来自图像, 而影像则是 25%，所以我们可以说处理和优化你的多媒体是很重要的。

你必须考虑流量的使用. 很多的人都是使用流量有限制的上网方案， 或是用多少付多少的上网方案，也就是根据用了多少 MB 来付费。这样的问题不是只发生在新兴国家的市场. 在 2018 年, 英国仍有 24% 在使用「用多少付多少」的方案。

你还需要考虑记忆体的问题，因为许多移动设备的 RAM 都有限。有一件很重要的事你必须要记住，下载的图像是被储存在记忆体裡的。

---

优化图像传输

儘管是频宽的最大消耗者，但因为图像是非同步载入的，所以访问者可以在下载的同时看到页面。因此，它们对感知性能的影响远低于许多人的预期。 然而，图像在内容中很常被使用，因此，重要的应该是让访问者尽快地看到它们，以获得良好的体验。

载入策略

对于大多数网站来说，最大改进之一是将不在视窗裡的图像做 lazy-loading ，而不是在初始页面载入时就全部下载下来，不管访问者是否之后会往下滚动查看它们。 许多 JavaScript 函式库都可以为你实现这个功能，例如说 lazysize，并且浏览器的供应商也正在着手原生的 lazyload 属性，然而目前还处于实验阶段。

除了载入图像的子集之外，接下来您还应该研究一下图像本身的格式：

• 你是否正在载入最佳格式？ （见下文）
• 你载入的尺寸正确吗？
• 你已经压缩图像了吗？ (查看 ImageOptim)

最佳格式

这非常值得用一个章节来介绍。因为为图像选择正确的格式可能很棘手。格式通常取决于图像的用途：

• Progressive JPEG—不需要移动卷轴就能看到的网页图像。
• WebP / JPEG-XR / JPEG2000—往下移动卷轴才能看到网页图像。
• PNG / WebP—有透明度的图像。
• SVG—向量图, 图示 (备注： SVGs 比 icon fonts 还要好得多！).

优先在不需要移动卷轴就能看到的网页区域使用 Progressive JPEG 的原因是因为它们会逐渐地进行渲染（因此得名），这意味着用户可以先看到低解析度的版本，然后再逐渐地变得清晰。而不是从顶部一行一行的以最高解析度来载入图像，或甚至只有在完全下载好后才显示。

控制下载图像的优先级别（和顺序）

将最重要的图像更早地呈现在访问者面前，可以改善感知性能。

第一件要确认的事情是，你的前景图像标籤 <img /> 跟你定义在 CSS 裡 background-image 的背景图像 — 前景图像比背景图像被赋予更高的优先级别。

其次，通过采用优先级别提示，你可以在图像标籤中添加importance 属性来进一步控制优先级别。轮播是一个在图像上使用优先级别提示的例子，它的第一个图像的优先级高于其他的图像。

渲染策略

由于图像是非同步载入的，并且会在第一次渲染后继续载入，因此，如果在载入之前未定义尺寸的话，则可能会导致页面内容的重新编排。比如说，当图像载入时，文字内容可能会被挤压到下面。所以， 很重要的是，定义 width 跟 height 或是新的 intrinsicsize 属性。

对于任何的背景图像，设置 background-color 的值非常重要，因为在图像下载之前，它能让上面的内容是能够被阅读的。

优化影像传送

为了确保您不会将不必要的大文件发送给用户，最好 压缩所有你要传输的影像，优化<source> 顺序, 设定 autoplay, 移除静音影像的声音, 优化影像预载, 还有 考虑串流 这部影像。

压缩所有影像

大多数的影像压缩工作都包含，比较影像裡的相邻帧，并删除原始帧和后续帧中相同的细节。你想同时压缩影像并将其汇出为多种影像格式, 包含 WebM，MPEG-4/H.264，以及 Ogg/Theora.

你用来创建影像的软体可能包含优化档案大小的功能。如果没有的话，那么可以考虑几种线上工具，像是之后篇章会讨论的 FFmpeg，他可以协助编码，解码，转换，以及呈现其他神奇的功能。

优化 <source> 顺序

从最小到最大来排序影像的来源。例如说，给定三个压缩影像，分别为 10 MB，12MB，以及 13MB, 把最小的摆在第一个，最大的摆在最后一格。

<video width="400" height="300" controls="controls">
  <!-- WebM: 10 MB -->
  <source src="video.webm" type="video/webm" />
  <!-- MPEG-4/H.264: 12 MB -->
  <source src="video.mp4" type="video/mp4" />
  <!-- Ogg/Theora: 13 MB -->
  <source src="video.ogv" type="video/ogv" />
</video>

就顺序的角度来说，浏览器会下载它看到的第一个影像来源，因此先让他载入一个较小的影像。就＂最小＂的角度来说，要确认你的压缩影响仍然看起来不会太糟。有几个演算法可能会让你的影像看起来像是个会动的 gif 。虽然 128 Kb 的影像可能在用户体验上会比 10 MB 的影像好，可是把看起来像是 gif 粒状的影像放在内容后面，也可能会对你的品牌产生负面影响。

查看 CanIUse.com 来确认现今浏览器对于影像以及不同媒体格式的支持。

影像自动播放

为了确保循环播放背景影像，你需要向影像标籤裡添加多个属性： autoplay, muted, 以及 playsinline.

<video autoplay="" loop="" muted="true" playsinline="" src="backgroundvideo.mp4">

虽然属性 loop 和 autoplay 在对于影像的循环跟自动播放很合理，可是 muted 属性在行动装置的浏览器裡是必须添加的。

Playsinline 在行动装置裡的 Safari 是必须的，他让影像可以在不需要全萤幕的模式下被播放。

移除静音影像的声音

如果你有一个 hero-video 或是其他静音影片, 请将声音从影像中移除。

<video autoplay="" loop="" muted="true" playsinline="" id="hero-video">
  <source src="banner_video.webm"
          type='video/webm; codecs="vp8, vorbis"'>
  <source src="web_banner.mp4" type="video/mp4">
</video>

这段 hero-video 代码, 常出现在许多研讨会网站以及公司的主页， 它是个包括自动播放，循环播放和静音的影像。它不包含任何控制选单，因此无法收听声音。通常它是没有声音的，但仍然存在音轨，因此它仍会消耗频宽。然而，我们没有理由将频宽分给静音影像的声音。移除声音可以节省 20% 的频宽。这代表，如果你的影像是 10 MB，则节省了 2 MB。

根据您的影像创作软体，你也许可以在汇出和压缩过程中删除声音。 如果没有，那么有一个免费的工具 FFmpeg ，可以使用以下指令来为你完成此任务

ffmpeg -i original.mp4 -an -c:v copy audioFreeVersion.mp4

FFmpeg 称自己为＂用于记录，转换和串流音频和影像的完整，跨平台解决方案＂。

影像预载

preload 属性具有 3 个可用选项：auto|metadata|none。预设选项是 metadata.

将选项更改为 auto 会告诉浏览器自动下载整个影像。仅有在极有可能播放时才应该执行此操作，否则会浪费大量的频宽。

preload="metadata" 最多可让 3％ 的影像在页面加载时被下载。 然后对于较大的影像来说，这可能或是大量的频宽。

preload="none" 不会在播放之前下载任何的影像。 这会延迟影像的啟动时间，但能够为播放可能性较低的影像保存大量的频宽。

考虑串流

串流影像让适当的影像大小和频宽 (根据网路速度) 被传递给用户。 就像使用响应式图像一样，正确大小的影像将被传递到浏览器，从而确保用户的快速影像啟动、低缓衝以及优化的播放。