稀土掘金的小册写的真好啊，十几块钱花的太值了！
输入 URL 到页面加载完成，发生了什么？(详情见另一篇博客Web页面请求历程 - 长谷川)
DNS解析
TCP连接
HTTP请求抛出
服务端处理请求，HTTP响应返回
浏览器拿到响应数据，解析响应内容，渲染展示给用户
前端能做的优化在网络与渲染两个层面（我想当全栈，技术栈广一点多好啊）
网络部分
DNS与TCP步骤开发者干不了啥。HTTP作为应用层协议，软件开发者能动的手脚就很多了，主要在两方面：
减少请求次数 （资源的合并）
减少单次请求所花费的时间 （资源的压缩）
构建工具webpack优化方案
构建过程提速(我自己也不太会，抄的小册，以后自己实践一下)
不要让loader做太多事情
例如最常见的优化方式是，用 include 或 exclude 来帮我们避免不必要的转译。
第三方库的优化
使用DllPlugin这个插件，DllPlugin 是基于 Windows 动态链接库（dll）的思想被创作出来的。这个插件会把第三方库单独打包到一个文件中，这个文件就是一个单纯的依赖库。这个依赖库不会跟着你的业务代码一起被重新打包，只有当依赖自身发生版本变化时才会重新打包。- -
Happypack——将 loader 由单进程转为多进程
Happypack 会充分释放 CPU 在多核并发方面的优势，帮我们把任务分解给多个子进程去并发执行，大大提升打包效率。
构建结果体积压缩
文件结构可视化，找出导致体积过大的原因。有个非常好用的包组成可视化工具——webpack-bundle-analyzer，配置方法和普通的 plugin 无异，它会以矩形树图的形式将包内各个模块的大小和依赖关系呈现出来
拆分资源
用DllPlugin，同上。
删除冗余代码
经典 tree-shaking 他的针对性很强，更适合用来处理模块级别的冗余代码。官方介绍长这样：
基于 import/export 语法，Tree-Shaking 可以在编译的过程中获悉哪些模块并没有真正被使用，这些没用的代码，在最后打包的时候会被去除。
还UglifyJsPlugin 不过webpack4 之后已经默认使用 uglifyjs-webpack-plugin 对代码做压缩了——在 webpack4 中，是通过配置 optimization.minimize 与 optimization.minimizer 来自定义压缩相关的操作的，可以配置自动删除console或注释啥的杂七杂八的玩意。
按需加载
一次不加载完所有的文件内容，只加载此刻需要用到的那部分（会提前做拆分），当需要更多内容时，再对用到的内容进行即时加载。
Gzip
可以在请求头中加一句accept-encoding:gzip 就行，相当于在服务端对代码做一次压缩，浏览器到时候做一次解压缩。权衡一下压缩与解压缩消耗和传输消耗，除了极小的项目剩下的都可以试试Gzip（前提是服务器顶的住）。
图片优化
前端性能优化中，图片远比js和css重要。找到图片质量与性能之间的平衡。
经典小图标解决方案——雪碧图（Sprites）
雪碧图、CSS 精灵、CSS Sprites、图像精灵，说的都是这个东西——一种将小图标和背景图像合并到一张图片上，然后利用 CSS 的背景定位来显示其中的每一部分的技术。可以有效减少http请求次数。
base64编码图片
Base64 是一种用于传输 8Bit 字节码的编码方式，通过对图片进行 Base64 编码，我们可以直接将编码结果写入 HTML 或者写入 CSS，从而减少 HTTP 请求的次数。
Base64 编码后，图片大小会膨胀为原文件的 4/3（这是由 Base64 的编码原理决定的）。如果我们把大图也编码到 HTML 或 CSS 文件中，后者的体积会明显增加，即便我们减少了 HTTP 请求，也无法弥补这庞大的体积带来的性能开销，得不偿失。
在传输非常小的图片的时候，Base64 带来的文件体积膨胀、以及浏览器解析 Base64 的时间开销，与它节省掉的 HTTP 请求开销相比，可以忽略不计，这时候才能真正体现出它在性能方面的优势。
省流：大图别用，小图用。
Webp（年轻的全能型图片格式）
WebP 像 JPEG 一样对细节丰富的图片信手拈来，像 PNG 一样支持透明，像 GIF 一样可以显示动态图片——它集多种图片文件格式的优点于一身。
与 PNG 相比，WebP 无损图像的尺寸缩小了 26％。在等效的 SSIM 质量指数下，WebP 有损图像比同类 JPEG 图像小 25-34％。 无损 WebP 支持透明度（也称为 alpha 通道），仅需 22％ 的额外字节。对于有损 RGB 压缩可接受的情况，有损 WebP 也支持透明度，与 PNG 相比，通常提供 3 倍的文件大小。
但是现在兼容性属实一般，并且编码webp占用更多计算资源，增加服务器负担。
现在限制我们使用 WebP 的最大问题不是“这个图片是否适合用 WebP 呈现”的问题，而是“浏览器是否允许 WebP”的问题，一旦我们选择了 WebP，就要考虑在 Safari 等浏览器下它无法显示的问题，也就是说我们需要准备 PlanB，准备降级方案。