如何让你的移动端网站更快

性能测试

优化移动性能的第一步是进行性能测试。目前，业界存在大量免费和付费的资源能够完成这一步。不过，我最喜欢的仍是谷歌 Chrome 内建的开发者工具和 WebPageTest。为了简单起见，本文中我就直接选用 Chrome 的开发者工具了。

你不是一个开发者？不要紧，这个开发者工具很容易就能够上手：

1. 打开 Chrome （固然我已经假设你安装了 Chrome 浏览器）
2. 点击右上角相似汉堡的三条线按钮，那是一个菜单键
3. 选择更多工具，最后选择开发者工具

若是你对开发者工具不太熟悉，或者只了解一点。若是你想再深刻的了解，能够阅读《DevTools Learning》。这篇文章收集了不少有关于开发者工具的学习资料。

如今你应该已经能够看到网格型的屏幕已经大量有趣的信息。其中最重要的，就是顶部的下拉菜单，其中包含了许多不一样的手机和平板模拟模式。太酷了。

接下来，选择一个感兴趣的设备，好比 iPhone 6。在浏览器的地址栏输入站点地址，回车进入！你就能够看到站点被渲染到了 iPhone 6 模拟器上。滚动到页面底部能够看到一系列的性能信息，好比页面加载时间、页面大小和总的请求数。点击 Network 信息栏，能够看到瀑布流形式的页面加载动态，以下所示：

优化移动端图片

根据这份 HTTP 统计，图片大概占据了页面整体积的 60% 之多。只凭直觉来讲，图片通知了网页。若是使用谷歌开发者工具检查你的页面，我相信也会得出相似的结果。当使用缓慢的移动网络加载图片时，大图片就会严重影响页面的响应速度。

虽然解决该问题可使用有损和无损图片优化两种技巧，可是对于移动端，咱们还有其余的考虑：咱们是否应该在页面加载之初就下载图片？那种桌面端分辨率高达 1600px 精致图片，若是直接用在平板和手机上，即便平板和手机是高分率的，仍然显得有些浪费。

如何解决？为移动用户加载更小体积的图片。注意：这里有正确和错误两种优化方式。

提示：在本例中，请确保在页面头部使用了 viewport 元标签。该标签用于通知移动浏览器，当前页面为响应式页面，避免被当成桌面站点缩放成移动屏幕的大小，那就太丑了。此外，若是该标签不存在，那么就会获得不一样的渲染结果。

<meta name="viewport" content="width=device-width, initial-scale=1.0" /> 

错误方式

响应式设计中大量使用了 CSS 媒体查询，用来美化不一样屏幕尺寸下的渲染结果，因此，最简便的图片切换方式就像以下代码所实现的效果：

<!-- DON'T DO THIS --> <style> @media (min-width:376px) { .mobile_image { display: none; } .desktop_image { display: inline; } } @media (max-width:375px) { .mobile_image { display: inline; } .desktop_image { display: none; } } </style> <img src="mobile.png" class="mobile_image" /> <img src="desktop.png" class="desktop_image" /> 

这段代码的功能就是，在页面较宽时显示一种尺寸的图片，在页面较窄时显示另外一种尺寸的图片。

看上去还不错，可是却有个致命的缺点：这两个图片都会被加载！为了验证这一结论，可使用谷歌开发者工具监视整个加载过程：

确实很糟糕。实际上，这比优化前更糟糕了！你浪费了大量的时间加载了一张可能永远都不会用到的图片！

正确方式

相反，当咱们使用 div 的 background-image 属性的时候，就能够实现想要的优化效果，上代码：

<!-- DO THIS --> <style> @media (min-width:376px) { .myimage { background-image: url("desktop.png"); width: 700px; height: 550px; } } @media (max-width:375px) { .myimage { background-image: url("mobile.png"); width: 350px; height: 130px; } } </style> <div class="myimage"></div> 

在开发者工具中监视加载流程，以下所示：

从只能够看出，只有相应尺寸的图片被加载了…… 太棒了！固然，对此还有一点注意事项: 为 div 使用 background-img，须要给给出肯定的尺寸和高度。若是面临大量的图片，或者这些图片的尺寸常常改变，那么这种方案就太繁琐了。但若是只是应用到大尺寸的主图上，就能够在下降复杂度的同时大幅提升响应性能。

提示：虽然使用这种方式能够优化移动响应速度，但只是对于那些高分辨率的大图。

是时候考虑抛弃 jQuery

什么？你没吃错药吧？jQuery 但是神通常的存在，你竟敢如此忽视它的存在？

jQuery 确实很是有用，它的初衷就是为诸多没有乖乖实现 W3C 标准的浏览器，提供统一的接口，避免书写各类条件语句判断当前环境。

可是，jQuery 的统一接口在移动设备上就显得有些多余了。移动端已经被相似 Safari 和 Chrome 的 webkit 内核浏览器统治了，因此无需再抽象出统一的接口。反而是它庞大的体积，即便是经过缓存调用，也应该考虑放弃它了。甚至是压缩和合并后的 jQuery，也有 30KB 之巨。

固然，你也许还想使用相似 jQuery 的简单接口，那么我建议你使用 Zeptojs 来代替。虽然它不是彻底等同于 jQuery，可是压缩后只有 5KB，才是 jQuery 的六分之一。由于 Zeptojs 拥有不少和 jQuery 的接口，你一样可使用较少的代码编写高质量的逻辑操做。对于大部分的基础站点，Zepto 显然更高效。

总结：压缩第三方库，同时使用 Zeptojs 做为 jQuery 的可替换方案。

审查缓存配置

优秀的网页开发者会尽可能减小页面资源大小，从而较少页面加载时间。更优秀的开发者甚至会尽可能减小第一次加载时的页面资源大小。这其中发挥重大做用的就是浏览器混存。若是你的图片、CSS 或者 JavaScript 资源不多改变，那么就应该考虑缓存它们。缓存以后，你的用户就只须要加载资源一次，下次再点击时会直接使用缓存资源。

这里有一篇 Mobify 上关于页面缓存的入门文章：《Beginners Guide to Http Cache Headers》。此外，还有大量免费工具能够测试缓存配置，好比很是酷炫的 REDbot、WooRank，以及咱们本身的 Zoompf。若是你使用了 Apache 或者 Nginx 服务器，建议开启 mod_pagespeed 以精简缓存配置。若是你使用了 WordPress，那么建议使用 W3 Total Cache 这款优秀的插件。

提示：缓存资源是最有效的性能优化方案之一，对于移动端尤为重要。审查你的缓存策略，并针对体积大、不频繁变动的库和图片进行缓存吧。

喜欢动态图？浏览器可不这么认为

动态图最近有了复兴的趋势，但这没法掩饰它年迈的姿态。回溯到三十年前，动态图臃肿而又难如下载，特别是从影片裁剪的那种动态图，真是不堪回首的岁月。很是建议使用 HTML5 的 video 标签替代这些影片裁剪的动态图。全部的现代浏览器都支持该标签，而且它的大小只有动态图的十分之一甚至更少。

另外一个可选方案是使用 Imgur。当你在 Imgur 加载动态图，它会将其转换为 GIFV。GIFV 本质上就是 HTML5 视频，可是被高度优化了。Imgur 托管着你的视频，并根据具体的浏览器兼容性提供 GIFV 或者 GIF。

提示：尽可能避免使用动态图和复杂动效。使用 HTML5 vedio 和 GIFV 提供的现代视频协议，有助于大幅提高性能并下降加载时间。

将来： HTTP/2

网络传输终于缓慢的发展到了 HTTP/2。HTTP/1.1 已经 15 岁了，这真是个龙钟老人，特别是体如今链接移动设备时的不可靠性和不稳定性。HTTP/2 已经被诸多浏览器和服务器所支持。虽然我不建议为了 4 月 21 日的移动友好而激进地使用 HTTP/2，但在将来使用这一协议显然值得列入你的路线图中。更多相关信息请参考早前的文章。

提示：为将来使用 HTTP/2 提早准备吧，这是它的时代！

总结

建立一个响应式、移动友好型的站点比修改样式或标签的细节会更加受到 Google 爬虫的青睐。这些就是移动端须要考虑的细节，若是忽略了它们，显然会严重拖累你的站点响应，甚至失去应有的用户体验。幸运的是咱们有诸多的免费工具能够用来评估移动站点的响应性能。

如今，开始并深刻优化吧！