前端体验优化

首屏衡量指标
首屏资源拆分
客服的初始化时间 window.onload
图片大小适配 ->后置图片请求时机

其实，对于网页高度小于屏幕的网站来说，统计首屏时间非常的简单，只要在页面底部加上脚本打印当前时间即可，或者对于网页高度大于一屏的网页来说，只要在估算接近于一屏幕的元素的位置后，打印一下当前时间即可。

为什么css还没下载完，domcontentloaded（蓝色线） 就完成了？

https://segmentfault.com/q/1010000009162836

合并资源/文件
基本上，每接收到一个外部 CSS 和 JavaScript 文件，浏览器都会构建 CSSOM，执行脚本。尽管几个文件可以在一次往返中传送，但也浪费了浏览器的宝贵时间和资源，最好还是合并文件，减少不必要的加载。

所以我们利用CommonsChunkPlugin插件去抽取这些第三方的部分作为vendor.js独立打包，因为需要利用到

缓存。所以我们添加hash值不能在未改变的情况下更新，否则独立打包vendor.js就没有意义了。

css拆分

看起来和上面有些冲突，这也是css和其它部分优化不同的地方。 一般我们大家都习惯把css放在最上面，js放在最下面。这是一个好习惯，但是对于css来说并不是最好的选择。

在移动端，大家非常重视首屏时间，也就是用户看到页面的时间。把整个页面的css都放在最上面，大量首屏用不到的css会阻塞首屏的展现。

head只放首屏能用到的css，首屏外的css下移
css使用率

一般页面经过多人维护后，会产生大量用不到css，大家也不敢随意删除，这就需要一些检测工具、

Minor GC

从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC。这一定义既清晰又易于理解。

空闲：最大程度增加空闲时间

利用空闲时间完成推迟的工作。例如，尽可能减少预加载数据，以便您的应用快速加载，并利用空闲时间加载剩余数据。

推迟的工作应分成每个耗时约 50 毫秒的多个块。如果用户开始交互，优先级最高的事项是响应用户。

要实现小于 100 毫秒的响应，应用必须在每 50 毫秒内将控制返回给主线程，这样应用就可以执行其像素管道、对用户输入作出反应，等等。

以 50 毫秒块工作既可以完成任务，又能确保即时的响应。

这里推荐一个同样是基于PhantomJS的工具Phantomas,它能运行测试页面获取很多性能指标，加载时间、页面请求数、资源大小、是否开启缓存和Gzip、选择器性能、dom结构等等诸多指标都能一次性得到，并且有相应的grunt插件。你也可以对检测指标进行二次开发，例如移动端定义一个最大图片大小的规则，在开发的时候如果使用了超过限制的大图则进行告警。不过如果把加载过程中的时间点作为常规的测试监控，则最好模拟移动端网络环境。

Combo服务

Combo服务，也就是我们在最终拼接生成页面资源引用的时候，并不是生成多个独立的link标签，而是将资源地址拼接成一个url路径，请求一种线上的动态资源合并服务，从而实现减少HTTP请求的需求。

Combo 缺点

浏览器有url长度限制，因此不能无限制的合并资源。
如果用户在网站内有公共资源的两个页面间跳转访问，由于两个页面的combo的url不一样导致用户不能利用浏览器缓存来加快对公共资源的访问速度。
如果combo的url中任何一个文件发生改变，都会导致整个url缓存失效，从而导致浏览器缓存利用率降低。

WebDriver 曾经是 Selenium 1（又名 Selenium Remote Control, 简写为Selenium RC）的竞争对手。Selenium RC 在浏览器中运行 JavaScript 应用，而 WebDriver 通过原生浏览器支持或者浏览器扩展直接控制浏览器。

Selenium 1.0 + WebDriver = Selenium 2.0

Selenium 1 是一款流行和完善的测试框架，支持众多浏览器（因其 JavaScript 实现），允许用户通过许多编程语言（从 Java/C# 到 PHP、Erlang…）编写测试脚本，而 WebDriver 则弥补了 Selenium 1 的缺点，跳出了 JavaScript 的沙箱，提供快速、轻量级的浏览器模拟器。之所以合并，原因如下：

WebDriver 解决了 Selenium 存在的缺点（比如，绕过 JS 沙箱）
Selenium 解决了 WebDriver 存在的问题（例如支持广泛的浏览器）

点击这个 Layers 选项卡，你会看到一个新的视图。在这个视图中，你可以对这一帧中的所有合成层进行扫描、缩放等操作，同时还能看到每个渲染层被创建的原因。

可行方案
Chrome支持在页面的HTML标签中加入的两个线索来优化资源加载:

在rel中指定的subresource(子资源)和prefetch(预加载)非常相似。不同的是，如果一个link指定rel(relation)为prefetch后，就是告诉浏览器这个资源是稍后的页面中要用到的。而指定为subresource则表示在本页中就会用到,期望能在使用前加载。两者不同的语义让resource loader有不同的行为。prefetch的优先级较低，一般只会在页面加载完成后才会开始。而subresource则会在解析出来时就被尝试优先执行。

还要注意，prefetch是HTML5的一部分，Firefox和Chrome都可以支持。但subresource还只能用在Chrome 中。

使用预渲染优化页面浏览

前面讨论的每个优化都用来帮助减少用户发起请求到看到页面内容的延迟时间。多快才能带来即时呈现的体验呢？基于用户体验数据，这个时间是100毫秒，根本没给网络延迟留什么空间。而在100毫秒内，又怎样渲染页面呢？

大家可能都有这样的体验: 同时开多个页签时会明显快于在一个页签中等待。浏览器为此提供了一个实现方式:

这就是Chrome的预渲染(prerendering in Chrome)! 相对于只下载一个资源的“prefetch", "prerender"会让Chrome在一个不可见的页签中渲染一个页面,包含了它所有的子资源。当用户要浏览它时，这个页签被切到前台，做到了即时的体验。

可以浏览 prerender-test.appspot.com 来体验一下效果，再通过chrome://net-internals/#prerender查看下历史记录和预连接页面的状态。

PageSpeed自动转换模块

Google开发的PageSpeed模块有一个功能，会自动将图像转换成WebP格式或者是浏览器所支持的其它格式。

以nginx为例，它的设置很简单。

首先在http模块开启pagespeed属性。

1
2
pagespeed on;
pagespeed FileCachePath “/var/cache/ngx_pagespeed/”;
然后在你的主机配置添加如下一行代码，就能启用这个特性。

1
pagespeed EnableFilters convert_png_to_jpeg,convert_jpeg_to_webp;

隐性预加载

除了明确的预加载提示，还有一种是通过推进触屏页面进度的趣味互动的方式，笔者称之此种类似的情况为隐性预加载。

Base64

浏览器支持的文件类型

这里有一些坑, 例如设置之后无法抓取网页浏览器上浏览数据

如果chrome浏览器装了SwitchyOmega一类的东西，请禁用，或选择“系统代理”，如此Charles才能正常抓浏览器的数据。

使用 requestAnimationFrame 来更新页面

我们希望在每一帧刚开始的时候对页面进行更改，目前只有使用 requestAnimationFrame 能够保证这一点。使用 setTimeout 或者 setInterval 来触发更新页面的函数，该函数可能在一帧的中间或者结束的时间点上调用，进而导致该帧后面需要进行的事情没有完成，引发丢帧。

requestAnimationFrame 会将任务安排在页面重绘之前，这保证动画能有足够的时间来执行 JavaScript 。

CSS阻塞渲染

通常情况下 CSS 被认为是阻塞渲染的资源，在CSSOM 构建完成之前，页面不会被渲染，放在顶部让样式表能够尽早开始加载。但如果把引入样式表的 link 放在文档底部，页面虽然能立刻呈现出来，但是页面加载出来的时候会是没有样式的，是混乱的。当后来样式表加载进来后，页面会立即进行重绘，这也就是通常所说的闪烁了。

另外常常被忽略的事实是：在浏览器没有下载并解析完成使用 link 引入的 CSS 文件之前，JavaScript 是不会执行的，因为 JavaScript 中可能需要读取样式，而此时样式表还没有加载回来，因此浏览器不会执行 JavaScript。可以给 JavaScript 加上 async 标记，表示 JavaScript 的执行不会读取 DOM ，JavaScript 可以不被 CSS 阻塞，可以在空闲时间立刻执行。

综上所述，你更要保证 CSS 文件加载的足够快。

使用 transform:translateZ(0); 这样的 CSS hark 写法会将元素提升至单独的图层。在这么做之前要考虑为什么要这样做，创建新的图层的目的应该是，避免某个元素的改变导致大面积重绘，比如某个小标签的颜色的改变，导致大面积重绘，因此将其提升至单独的图层中。这里有个例子，小标签背景色的改变会导致大面积的重绘，但是如果将其提升至单独的图层后，改变它的背景色将只会重绘它自身。你可以代码 Chrome 调试工具，通过 Timeline 观察每次闪烁重绘的内容。

其他资源

要详细了解如何优化您的应用的网络性能，请参阅下面的资源：

https://developers.google.com/web/tools/chrome-devtools/network-performance/resource-loading?utm_source=dcc&utm_medium=redirect&utm_campaign=2016q3

使用 PageSpeed Insights 确定可以应用到您网站的性能最佳做法，以及使用 PageSpeed 优化工具将应用这些最佳做法的流程自动化。
Google Chrome 中的高性能网络讨论了 Chrome 网络内部机制，以及您如何充分利用它们让您的网站更快。
gzip 压缩的工作原理提供了 gzip 压缩的高级概览，并介绍了这种压缩为什么是一种不错的方法。
网页性能最佳做法提供了更多用于优化您的网页或应用的网络性能的提示。

预解析

WebKit 和 Firefox 都进行了这项优化。在执行脚本时，其他线程会解析文档的其余部分，找出并加载需要通过网络加载的其他资源。通过这种方式，资源可以在并行连接上加载，从而提高总体速度。请注意，预解析器不会修改 DOM 树，而是将这项工作交由主解析器处理；预解析器只会解析外部资源（例如外部脚本、样式表和图片）的引用。

呈现引擎的线程

呈现引擎采用了单线程。几乎所有操作（除了网络操作）都是在单线程中进行的。在 Firefox 和 Safari 中，该线程就是浏览器的主线程。而在 Chrome 浏览器中，该线程是标签进程的主线程。
网络操作可由多个并行线程执行。并行连接数是有限的（通常为 2 至 6 个，以 Firefox 3 为例是 6 个）。

etag:
W/“5995180c-2a383”