协作翻译 | IE 浏览器背后的原生 JavaScript 开发

这篇文章与是否放弃老版本 IE 支持毫无关系，你们（或你个人）必须要根据网站或应用程序的具体细节来做出决定。

1. JavaScript APIs

在本节中，我们将对 JavaScript 特性，相关 API 及其功能进行讨论。 他们都有什么共同点？ 它们都不能用于老版本 IE，因为他它们都需要使用各种插件或者通过各种其他框架和库（如果可以做到的话）才能达到想要的效果。但在当前的环境（IE11 + Edge）中，它们有本机内置的浏览器的支持，所以可以直接使用。

Base64 的编码和解码（btoa 和 atob）

Base64 是一种非常有用的web工具。许多人可能已经在使用，将字体或图像嵌入 CSS。 另一个常见的用法是，用其处理那些通常会干扰传输协议的各种资源。 HTTP 基本认证 提供了一个很好的例子，其用户名和密钥对使用 Base64 打包，然后发送到服务器。在本机支持编码/解码操作意味着它们会更有效率。 以下是一些资源，您可以从这些资料开始了解：

• atob() 和  btoa() 在 MDN上的文档

• Base64.js 插件

Blob构建

在数据库管理系统中， 二进制大对象（Binary Large Object ）或者  BLOB  是按照单个实体存储的原始数据进行集合。它可以是以 Base64 格式存储的音频剪辑或图像，也可以是单纯的一系列图像。在多数情况下，Blob 字段用于存储下使用正常的表结构数据或者或模式表数据，例如 JSON 对象。有些人可能只记得 BlobBuilderBlob，而不是接口的原型。既然这种方法既然已被弃用，那么，我比较推荐通过新的接口完成对 Blob 的所有操作。

另外，因为这个集合与文件非常相似，所以 Blob 对象的本地接口已被用作 File() 接口的父类。因此，它有一个很好的功能名字是“Blob URL”，其允许开发人员为 blob 对象创建 URL，这个 URL 可以在任何地方使用。考虑到这一点，非常庆幸原生支持现在能覆盖所有的主流浏览器。

• BLOBs on MDN （MDN 上的 BLOB）

• BLOB URLs on MDN （MDN 上的 BLOB URL）

• An Introduction To JavaScript Blobs and File Interface （JavaScript Blobs 和 File接口概述）

信道消息

通常情况下，为了避免大量的安全隐患，两个不同浏览器上下文中的脚本是不能互通的。有时候，这样的通信并不是因为想要，而是需要。这就是信道产生消息（Channel Messaging） API 的原因。这个接口允许两个脚本通过一个双向通道进行通信。这就像是使用同一个信道使用对讲机的双方。很优雅，不是吗？

• MessageChannel on MDN （MDN 上的 MessageChannel）

常量和块级变量

const 和 let 是 ES6 定义数据的两个新方法。与 var 用于定义全局和函数范围内的变量不同，这两个新的数据定义是块级的。换句话说， const 和 let 定义的变量的作用域是在定义它们的两个大括号之间。

使用 let 定义变量与以前的定义方式没多大区别（除了作用域不同）。常量（const 定义的）是只读的，引用着一个确定的值，不能被重新赋值，不能被重新定义，它的名字也不能被同一个作用域内的其它变量或函数使用。唯一的例外是，引用一个拥有自身属性的对象。这些属性不受保护，可以改变，就跟普通的变量一样。

如果想在代码中正确使用常量和块级变量，应该看看这些：

• Constants on MDN （MDN 的常量）

• Let on MDN （了解 MDN）

• Preparing for ECMAScript 6: let and const on SitePoint （准备 ECMAScript 6： SitePoint 上的 let 和 const）

• ES6 let VS const variables by Wes Bos （ES6  通过 Wes Bos 实现  VS const 变量）

控制台日志

多数前端开发者都会同意 Web 控制台是手边最常用的工具之一，如果脚本没有按预期运行，通常会使用它。然而 IE 的性质决定了将这一特性整合在代码中是个漫长的过程，只有从 10 这个版本开始才对它提供完整的支持。如果你想了解相关的知识，或者想找到一些使用控制台的新方法，看看这个：

• Console on MDN （MDN 上的控制台）

跨域资源共享

跨域资源共享 (CORS) 是一个 HTML5 的 API，它允许访问来自当前所有域名之外的资源。它引入了一组 HTTP 头，允许浏览器和服务器通过一个特定的许可请求远程资源。下面的资源对于学习如何正确使用这个功能是个很好的起点：

• DOM Access Control Using Cross-Origin Resource Sharing on Dev.Opera （ 使用 Dev.Opera 跨源资源共享 的 DOM 访问控制）

• HTTP access control(CORS) on MDN （ MDN 上的 HTTP 访问控制（CORS） ）

• An In-depth Look at CORS on SitePoint （ 深入了解 SitePoint 上的 CORS ）

Web 加密 API

如今，安全和隐私是两个最热的特性，对于任何应用来说都是如此。这意味着好（而且快）的加密技术很受欢迎。目前所有主流浏览器都一致支持 Web 加密 API，除了 IE11（它实现了旧一些的规范）和 Safari（需要 crypto.webkitSubtle）。幸好某些特定的功能（比如产生随机数的功能）有更好的实现。因此，和以往任何时候相比，都更容易通过原生支持实现加密元素。下面是一些不错的参考：

• Crypto object on MDN （ MDN 上的加密对象 ）

• getRandomValues on MDN （ MDN 上的 getRandomValues ）

• Web Cryptography API shim for legacy browsers on GitHub （ 用于 GitHub 上的旧版浏览器的  Web Cryptography API shim ）

如今，无处不在的互联网为你的网站带来世界各地的访问者。人们总是相信自己熟悉的东西，因此比较好的做法是把信息都按他们的语言和习惯的格式来提供。这就是 国际化 （Internationalization，或叫 i18n）和 本地化 （Localization，或叫L10n）存在的意义。你是否觉得难以区分？让我们引用Aurelio de Rosa 文章， 如何在 JavaScript 中实现国际化（i18n） ，中的一段话：

国际化(也叫 i18n) 是对产品或服务进行创造或转换的一个过程，这个过程使用产品或服务易于适应特定地域的语言和文化。 本地化 （也叫 L10n）这个过程是将国际化的软件适配到特定的区域或语言。换句话说，国际化是让你的软件能支持多种文化（货币格式、日期格式等），而本地化是实现其中一种或多种文化的过程。

浏览器的支持略好于年初的时候，Safari 9月发布的 v10 开始加入支持。有兴趣吗？这里有一些资源：

• Internationalization API on MDN （ MDN 上的国际化 API ）

• JavaScript Internationalization API – a simple introduction （ JavaScript 国际化 API - 简单的介绍 ）

• How to Implement Internationalization (i18n) in JavaScript （如何在 JavaScript 中实现国际化（i18n）

处理多媒体查询

响应式网页设计是高性能网站设计的当前标准，其中促成这个最核心的特性是支持多媒体查询。matchmedia 把媒体查询从 CSS 带入到 JavaScript 中，为开发人员针对不同类型的设备做内容方面优化提供了诸多便利性。一个很好的例子是在手机和平板电脑上来回切换横屏和竖屏模式。虽然有一个 API 可以检测设备方向 ，但仅部分浏览器的支持，而只有 Microsoft Edge 提供了完全支持。 以下是一些资源，可以帮你从这个主题开始：

• Testing Media Queries on MDN （在 MDN 上测试多媒体查询）

• Window.matchMedia on MDN （MDN 上的 Window.matchMedia）

• How to use Media Queries in JavaScript on SitePoint （如何在 SitePoint 上基于 JavaScript 使用多媒体查询）

媒体源的扩展

媒体源扩展（MSE）增加了对视频和音频元素额外的扩展功能，且不需要插件。这为你提供了诸如自适应媒体流，实时媒体流，拼接视频，和视频编辑等功能。2013 年 9 月，YouTube 就在他们的 HTML5 播放器上使用了 MSE。 在浏览器的支持上也是很好的，仅仅只有 iOS Safari 和 Opera Mini 错过了这个功能。在 Windows 8+ 上，IE11 已经能完全支持这个功能。不幸地是，IE11/Win7 用户不能从这项技术上受益。你是否准备好开始在这些 API 上工作，如果是的话，下面这些资源将会很有用：

• MediaSource API on MDN （在 MDN 上的 MediaSource API）

• Media Source Extensions on MSDN （在 MSDN 上的媒体源扩展）

• HTML5 Media Source Extensions: Bringing Production Video To The Web on Smashing Magazine （HTML5 媒体源扩展： Smashing 杂志 —— 在 Web 上产生视频）

变化观察者

JavaScript 应用正日益变得复杂。作为开发者，你需要控制页面上发生的变化，尤其是 DOM 树的变化。但目前已经有了一个很好的解决方案——变化事件，所以你不用进行时刻监测。这个接口存在一个问题，它会自动同步（在调用时触发，触发过程中会阻止其它事件被触发）并且需要通过 DOM 捕捉或冒泡。相应的，它会引发一些其它事件，如造成 JavaScript 线程过载。在某些情况下，甚至会导致全面连锁失败，最终导致浏览器崩溃。

因此，变化事件已被弃用，改用变化观察者来代替。你可能会问，这有什么不同呢？最首要的一点就是，观察者是异步的。它们不会阻止脚本运行，也不会在每次发生变化时被触发，而是在主要活动结束之后发送一批结果。除此之外，你可以对观察者进行调整，让它们观察节点的所有变化，或者只是指定类别的变化（比如只是子节点列表的变化或者只是属性的变化等）。您通过下面的资源可以了解它：

• MutationObserver on MDN （MDN 上的 MutationObserver）

• Getting to Know Mutation Observers

  （认识变化观察者）

• Evolving a New Mutation on SitePoint

  （SitePoint 上，进入新的变化）

页面可见性

选项卡浏览改变了我们与网页交互的方式。 多人在同一时间打开十多个页面的情况并不常见。  因为这些页面都有自己的事情要干，各自运行脚本，下载所需资源等等。 即使在一个给定的时间内，只有一个选项卡是激活的，所有打开的页面也需要消耗处理器的时间和带宽。 虽然一些应用程序会定期发送和接收更新。但如果你没有活动标签中的应用程序，难道它要在后台每 X 秒就更新一次？这显然有点浪费，尤其是在移动设备上使用数据的情况下，每一个资源都是非常珍贵的。

这时候页面可见性 API 就能发挥作用了。这个接口允许开发人员了解他们的应用程序是在活跃的标签内还是在后台。 让我们以刚才提到的情况为例。 有了页面可见性 API，你可以在应用还在后台运行时就进行检测，并且与之前每 5 秒或 10 秒更新一次不一样，现在你可以每隔 60 秒或者更长时间更新一次。一旦页面再次可见，您可以切换回正常的更新。这样很酷，不是吗？

你还在等什么呢？看一看下面的指南和启用应用程序页面可见性。你的用户会感谢你：

• Page Visibility API on MDN （页面可见性 API（MDN））

• Introduction to Page Visibility API on SitePoint （页面可见性API介绍（SitePoint））

页面变更事件

你在使用页面表单时是否遇到过这种情况：当尝试离开或者关闭这个页面时，它会弹出一条消息显示说还有没被保存的数据。这个现象经常发生在你修改了设置、配置细节等内容的时候。那么，页面里面的脚本是如何获知你要离开的操作的呢? 原来它们侦听了 pagehide 事件。

Pagehide 和 pageshow 是页面变更事件的主要角色。前面我们已讨论过此类角色的主要用途之一。Pageshow 主要用以判断一个页面是从缓存、还是直接从服务器加载的。这个功能并不是最常用的，如果你想使用，可以看看下面的资源:

• pageshow on MDN （MDN 上的 pageshow）

• pagehide on MDN （MDN 上的 pagehide）

requestAnimationFrame

页面上的动画由来已久，从早期的 <marquee> 和 <blink>，经由动态的 GIF，jQuery 特效, 一直发展到当前盛行的 CSS，SVG，canvas 以及 WebGL 动画。动画形式不断演变，不变是对动画流的控制，以尽可能满足平滑流畅的需要。

最初的方法是用 setInterval 和 setTimeout 来控制动画的步骤。但它输出的结果并不可靠一致，而且显示的动画通常很粗糙。这就是为什么会有一个新的接口构想出现 — requestAnimationFrame。这种方式的一个主要优势就是浏览器可以自由地将请求同自己的绘制周期相匹配，让动画的观感平滑起来。与之相对应的还有 cancelAnimationFrame，这两个方法可以说是现代 JavaScript 动画的基础。

同样，下放提供了一些资源来让你掌握这个功能。

• requestAnimationFrame on MDN （MDN 上的 requestAnimationFrame）

• cancelAnimationFrame on MDN （MDN 上的 cancelAnimationFrame）

• Simple Animations Using requestAnimationFrame on SitePoint （SitePoint 上使用 requestAnimationFrame 的简单动画）

• Watch: Performance with requestAnimationFrame on SitePoint （SitePoint 上使用 requestAnimationFrame 的性能观察）

计时 API

在线性能是如今比较流行的主题，每个人都尽最大努力压缩精简资源文件，优化脚本并且最大化地利用手边的工具。实现这一目标主要有两种方式：网络性能 （站点和资源分发的快慢）和使用性能（应用本身执行的快慢）。

网络性能服务由两个 API 提供：导航计时和资源计时。他们都给出了和网络性能相关的各种信息，如DNS，CDN，请求和相应时间，等等。唯一的区别是导航计时着眼于 HTML 页面本身，但资源计时处理所有其他的资源 (图片，脚本，媒体资源，等等）。

在使用性能方面我们有一个使用计时 API。这个 API 涉及两个主要概念：标记（非常详细的时间戳）和测量（两个标记之间的间隔）。利用这些概念可以让开发者计算代码运行的快慢，找到需要优化的位置。但是，Safari 浏览器不支持这一 API，所以需要使用其他的库。

掌握接口的用法是保证网站或 app 最佳性能的一项重要技能。为此，我向大家推荐：

• 导航计时

• Navigation Timing API on MDN （MDN中导航计时API）

• Profiling Page Loads with the Navigation Timing API on SitePoint （在站点中使用导航计时 API 加载页面）

• Navigation Timing API: How to Profile Page Loads Efficiently on SitePoint （导航计时 API: 在站点中如何有效地加载画面）

• 资源计时

• Resource Timing API on MDN （MDN 中资源计时）

• Measuring network performance with Resource Timing API on Google Developers Blog （在 Google 开发者博客中使用资源计时 API 计算网络性能）

• Introduction to the Resource Timing API on SitePoint （站点中资源计时 API 的介绍）

• 使用计时

• Discovering the User Timing API on SitePoint （在站点中发现使用计时 API）

• User Timing API on HTML5Rocks （HTML5Rocks 使用计时 API）

• user-timing-rum.js and  UserTiming.js polyfills on GitHub（user-timing-rum.js 和 UserTiming.js GitHub库）

类型化数组

JavaScript 的类似化数组是一种像数组的对象，它提供了一种访问原始二进制数据的机制。为了最大的灵活性和效率，它的实现分为两个概念：缓冲区（原始数据块）和视图（它提供一个上下文来解释缓存的数据）。不少 Web API 都使用了类型化数组，比如 WebGL、Canvas 2D、XMLHttpRequest2、File、媒体源或二进制的 WebSocket。如果你的代码使用这类技术，你会对下面的资源感兴趣：

• JavaScript typed arrays on MDN （ MDN 上的 JavaScript 类型数组）

• Typed Arrays: Binary Data in the Browser on HTML5Rocks （ 类型数组：HTML5Rocks 上浏览器的二进制数据）

WebSocket

之前我们谈到信道消息以及它是在两个不同的脚本间进行通信的。WebSocket 与之相似，却可以做更多事情。这个 API 可用于在浏览器和Web服务之间创建持续的通信通道。

就像 HTTP 一样，WebSocket 协议有两个版本：非安全的 (ws://...) 和安全的 (wss://...)。它同样重视在代理服务和防火墙中建立隧道。实际上，WebSocket 通过普通的 HTTP 开始连接，这会与现有的基础设施保持兼容性。

WebSocket 是一块迷人的技术（它甚至有一个专门的网站），可以从中学到不少东西。你可以从下面的资源开始了解它：

• About WebSocket on WebSocket.org （ WebSocket.org 上的 WebSocket）

• WebSockets on MDN （ MDN 上的 WebSockets ）

• Introduction to the HTML5 WebSockets API on SitePoint （ SitePoint 上的 HTML5 WebSockets API 简介 ）

Web Worker

默认情况下 JavaScript 只运行在一个线程中。那么页面上的所有脚本会共用同一个时序队列。在只有一个处理器的时候，这很好而且很简单。不过现代CPU有至少两个核心，在某些型号上可以达到4、6 或 8 核。如果能把任务移到其它线程以使用空闲的其它核心凯不更好？正是如此，Web Worker 发明出来了。

使用 Web Worker API 之后，开发者可以将一个命名的脚本文件委托给一个 worker 在另一个线程中运行。这个 worker 只会应答创建它的脚本，并在两者间建立通信，它可以运行 XMLHttpRequest 调用，但不能与 DOM 交互，也不能使用 window 对象原生提供的一些方法和属性。当然也有一些例外，比如 WebSocket（可以将 WebSocket 连接的管理权赋予 worker） 或像 IndexedDB 这样的数据存储机制。主线程专注运行整个应用的时候没有什么会像部下一样去处理将要任务。

想了解这个功能（包括 Web Worker 的一系列函数和类），看看下面的资源：

• Web Workers API on MDN （ MDN 上的 Web Workers API ）

• Functions and classes available to Web Workers on MDN （可用于 MDN 上 Web Workers 的函数和类 ）

• JavaScript Threading With HTML5 Web Workers on SitePoint （ HTML5 Web 站点上的 JavaScript 线程 ）

XMLHttpRequest 高级特性

XMLHttpRequest 的使用标志着 web 开发的新纪元。浏览器和服务器之间的数据交换不再需要重新加载整个页面。 AJAX 是新的标准，它允许每个人都喜欢的单页面应用的存在。

这么有用的技术在未来定会进一步发展。这其中包括 XHR 如何获得新的功能，像文件上传，上传进度的信息或者直接发送表单数据的能力。并且所有的这些功能（在 IE11 或者老版本的安卓浏览器中更少的异常）在老的 IE 浏览器退休后，将被主流的浏览器支持。

了解更多细节, 自行阅读下面的资源:

• FormData on MDN （MDN 中的表单数据）

• Easier Ajax With the HTML5 FormData Interface on SitePoint （在站点中使用 HTML5 表单数据接口简化 Ajax）

2. 多方面的特性

现代 Web 不只是 HTML、CSS 和 JavaScript，还有很多“幕后英雄”在竭尽所能升级用户的在线体验。下面我们来讨论一些这样的特性。注意，上面提到那些特性并不能用于老版本的 IE 浏览器（它们在安全漏洞和对现代特性的支持方面的名声不太好）。

使用“async”和“defer” 实现非阻碍加载 JavaScript

Web 开发者们都知道脚本是“阻碍加载”，而且在它们加载完成之前不能控制整个页面。我们都知道加载 jQuery 的推荐方式是在 </body> 之前进行。这种方式在单页应用中不起作用，因为单页应用中所有行为都是由 JavaScript 控制的，这推翻了我们之前对加载时机的认识。

但是实际情况是大多时候我们的网站或者 Web 应用只需要加载部分 JavaScript 就可以开始运行。剩下的后续才会用到，而且就算现在使用也不会影响到 DOM。显然此处该有一种方法能以常规的方式加载核心脚本，而其它脚本以不给应用带来负面影响的其它方式加载 [译者注：这里负面影响应该包括阻碍带来的体验或性能影响]。而事实上也确实存在两种这样的加载方法。

第一种使用 defer 属性，它标记脚本不会影响 DOM 并准备在文件解析完成后执行。多数情况下这类脚本用于处理用户操作，它们采用这种方式加载是安全的。第二种使用 async 属性，它标记脚本采用并行加载，不过一旦加载完成就立即执行。它不能保证执行顺序与加载顺序一致。

这两个参数的用处不少，因此它们正成为提供网站和 Web 应用性能的重要工具。了解该技术的使用情况及方法，请参阅一下资源：

• Remove Render-Blocking JavaScript on Google Developers

  （Google开发者上的 移除阻碍渲染的 JavaScript）

• Load Non-blocking JavaScript with HTML5 Async and Defer on SitePoint

  （SitePoint上的使用HTML5 的 async 和 defer 非阻塞加载 JavaScript ）

内容安全策略

从一开始，Web 上的安全性就是在“同源”模型的基础上构建的，这意味着只有来自同一域名的脚本才能与特定页面交互。不过，随着后来的发展，我们还必须将第三方脚本集成到网页中：如 CDN 的 JavaScript 库， Facebook、Google+ 或 Twitter 的社交媒体小部件等。这意味着我们敞开了自家大门，允许脚本“宾客”们进入我们的“小院”。这样一来，问题也随之出现了，如果恶意脚本也在里面，并像其他脚本一样正常执行，就会出现问题——这是一种广为人知的攻击方法，称为 跨站点脚本（Cross-Site Scripting） 或  XSS 。

而 内容安全策略 是抵抗  XSS  的主要武器。此机制包含一组策略和指令，用于指定哪些脚本允许执行，和是否可以运行内联样式或脚本等。CSP 基于白名单机制，这意味着默认情况下，所有脚本都会被拒绝执行，只有指定的资源可以被访问。因此，一旦规则被合理安排，即使恶意脚本插入到我们的网站，它也不会被执行。

这里有一些资源，将帮助你更好地理解这种机制：

• Content Security Policy Reference （内容安全策略参考）

• Improving Web Security with the Content Security Policy on SitePoint （内容安全策略帮助改善 Web 安全性）

• An Introduction to Content Security Policy on HTML5Rocks （内容安全策略简介）

HTTP/2 协议

从一开始，Web 就在 HTTP 协议上运行。然而，虽然 Web 发展迅速，但 HTTP 仍然保持着大体不变。在现代网站和应用程序的复杂生态系统中，HTTP 成了一道性能瓶颈。虽然也有一些技术和实践可以优化此过程，但十分有限。

这就是为什么基于 Google 的 SPDY 协议重新开发了名为 HTTP/2 协议的二次迭代版本。它已于 2015 年 2 月获得批准，并在 2016 年 5 月发布名为  RFC 7540 的规范。到目前为止，主流浏览器只能通过加密连接支持 HTTP/2，并且在可预见的未来仍可能保持这种状态，以督促网站所有者切换到 HTTPS 上。

移植到 HTTP/2 并不是简单的更改一些配置参数。而用于提高 HTTP 性能的一些最佳实践可能会对 HTTP/2 的性能产生不同的影响。想知道您的网站是否能使用 HTTP /2，您可以查看以下资源：

• Getting Ready For HTTP/2: A Guide For Web Designers And Developers on Smashing Magazine （为使用 HTTP/2 做准备：给 Web 设计师和开发者的指南）

• How HTTP/2 Is Changing Web Performance Best Practices on New Relic Blog （HTTP/2 改善 Web 性能的最佳实践）

• HTTP/2 For Web Developers on Cloudflare Blog （给 Web 开发者的 HTTP/2 介绍）

资源提示：预取

人们现在对网络性能的追求十分狂热。在这个领域工作过的人都知道，大量的资源下载会影响页面加载时间。但如果在页面加载后将预处理资源作为后续步骤，是不是会有利于提升速度呢？而这就是资源提示发挥的作用。

资源提示是一系列指令， 它们让浏览器提前提供后续需要的特定资源。 该列表包含五个提示，如下：

• DNS预取（dns-prefetch）

• 预连接（preconnect）

• 预取（prefetch）

• 预加载（preload）

• 预渲染（prerender）

除了这五个可能的选项之外，还需要一个支持预取的浏览器。这个提示告诉浏览器缓存用户之后最有可能发出的请求的文档。这限制了它缓存的元素的使用。将它与其他类型的资源一起使用将无法工作。

如果您对这个主题感兴趣，下面资源列表提供了更多的细节：

• Article on Resource Hints on Medium （媒体上资源提示的文章）

• Prefetching, preloading, prebrowsing on CSS-Tricks （预取、预加载、预浏览的CSS技巧）

• Resource Hints on KeyCDN Blog （有关资源提示的博客）

严格传输安全

HTTPS 正在演变为浏览器新的标准，越来越多的网站只接受安全连接。普通连接（对于 HTTP）通常会重定向为 HTTPS 版本，其他正常访问。但是，这样做法存在“人为中间端”攻击的风险，为了窃取你的登录密码而重定向成的钓鱼网站，伪装成你想要的链接（一般是银行网站）。

这就是严格传输安全头字段发挥作用的地方。你首次使用 HTTPS 连接你想登录的网站，头字段会发送到你的浏览器。你下次连接时，即使你只使用 HTTP 版本的 URL 访问，浏览器会自动重定向到 HTTPS 版本，不用经历重定向周期。由于没有在 HTTP 连接，攻击更早的描述不会发生。

查看更多有关严格传输安全头协议详情，可访问以下网址：

• HTTP Strict-Transport-Security on MDN （ MDN上的HTTP严格传输安全 ）

设备像素比例

Window.devicePixelRatio 是一个返回当前显示设备上（垂直）物理像素大小与 CSS 像素大小比例的只读属性。通过这种方式，开发者能发现高密度屏幕（像苹果和高端安卓屏幕中的 Retina 显示）。配合媒体查询和 MatchMedia (上面讨论的)，这一属性允许优化后资源的分发以实现可能的最佳体验.

• Window.devicePixelRatio on MDN （MDN 中的 Window.devicePixelRatio）

Web视频文本追踪

Web 视频文本追踪（或者 WebVTT）是一种标记多媒体资源文本标题的格式。它配合 HTML5 的<track>元素使用来保证子标题的展示、翻译、标题或者以同步方式描述媒体资源（音频或者视频）。文本化资源的展示极大增加了媒体资源的可访问性。

获得这一功能的介绍，请查看以下资源:

• WebVTT on MDN （MDN 中的 WebVTT）

• An Introduction to WebVTT and <track> on Dev.Opera （Dev.Opera 中对 WebVTT 和<track>的介绍）

• Getting Started With the Track Element on HTML5Rocks （HTML5Rocks 中开始使用 Track 元素）