` 标签外面的内容，如 `index.html` 文件中的其他部分。
#### 如何缓存 App Shell 内容
在这个示例中，`service-worker.js` 文件是通过 SW Precache Webpack Plugin 插件生成的，可以参考 [sw-precache-webpack-plugin](https://github.com/goldhand/sw-precache-webpack-plugin#readme) 文档。代码如下所示：
```javascript
// build/webpack.prod.js #13 行
// 引入 sw-precache-webpack-plugin 插件
const SWPrecacheWebpackPlugin = require('sw-precache-webpack-plugin');
// build/webpack.prod.js #121 行
// 添加 sw-precache-webpack-plugin 插件生成 Service Worker 文件
new SWPrecacheWebpackPlugin(config.swPrecache.build)
```
它的配置写在 `config/sw-preache.js` 文件中，开发者可以对它做一定的修改。
编译之后，会在 `dist` 目录中生成 `service-worker.js` 文件，第四章中有对 Service Worker 详细的介绍，在这里我们不必关心这个文件中过多的细节。插件生成的 Service Worker 做了很多事情，如下：
* 列出了项目中静态文件列表
* 预缓存了 App Shell 的静态文件
* 具有预缓存动态更新机制
* Service Worker 的更新机制
```javascript
// 预缓存文件列表，其中包含 App Shell 所有的文件
var precacheConfig = [["/index.html","cb8786927330e5bdd417a47314a7300b"],["/static/css/app.5be76b7d213b43df9723e8ab15122efb.css","5b0aa7a24708300b7176f0304923ab39"],["/static/images/icons/icon_144x144.png","4bf0757895bd1cda44ee9204fe06a661"],["/static/images/icons/icon_152x152.png","c69908d502224c5317453f8ae725bbf0"],["/static/images/icons/icon_192x192.png","c69908d502224c5317453f8ae725bbf0"],["/static/images/icons/icon_512x512.png","8eaee831d59442821083453b174df0f6"],["/static/js/0.2dd5b370dbfb9afda866.js","5455b40e8991749d4aeb904f09389394"],["/static/js/1.f740f9813d49b7661238.js","65b7858bacef211f345d0d88fda81092"],["/static/js/app.e9b2b9e109561a7201f5.js","a28433e856b3e149bac022df934eb94e"],["/static/js/manifest.69fbe521a6bc723a8ce1.js","c6b6fbf7902cd5325b5b1d43045db622"],["/static/js/vendor.7bb72363822163e0f3b3.js","38d1baa4e38eeab57826462846900d69"],["/static/manifest.json","a521180656694782bc69a54ee5900dfb"]];
var cacheName = 'sw-precache-v3-sw-cache-chapter02-appshell-' + (self.registration ? self.registration.scope : '');
```
## 总结
总结来说，App Shell 把站点内容划分为“变”和“不变”两个部分，再辅以 Service Worker 技术将“不变”的部分缓存起来，以达成快速加载页面的效果。
通过 App Shell 和 Service Worker，我们有办法让“不变”的部分快速展现，那么针对“变”的部分，我们有什么办法让它展现得更快呢，或者让它“看起来”更快？在这里我们再提出另一种方案，它虽然不能在实质上提升页面的加载速度，但可以让它在感官上更快，它就是下一节要介绍的骨架屏。
================================================
FILE: chapter02/4-app-skeleton.md
================================================
# 骨架屏
在前面的章节，我们说过，首屏速度对于用户留存率至关重要。
很多站点都会在完成基本功能后（或者同时）进行性能优化，常见的性能优化手段包括静态资源合并，压缩文件，使用 CDN，包括上一小节介绍的 App Shell 等，这些的确能够显著地缩短加载时间。但是我们想象一下，在首次打开时，主体内容渲染完成之前，页面基本上是空白的，这对于用户体验是非常不友好的。如果我们用能够快速渲染的静态图片/样式/色块进行占位，让用户对后续会渲染的内容有一定的预期，这要比白屏等待要好的多，这就是骨架屏。如上一节的结尾所述，它本质上并不提升页面的加载速度，却能提升感官体验，让网页“看起来”更快。
## 骨架屏长什么样
您可能没听说过骨架屏这个名字，但应该很早就在其他 App 上看到过，骨架屏常见的种类有列表、图片和两者的混合。
下面的图是[饿了么 Web 站点](https://h5.ele.me/msite/) 骨架屏的效果，这种效果是比较常见的类型，它使用各种形状的色块来模拟图片和文字，有些图标也会使用圆形色块。为了追求效果，还可以在色块表面添加动画效果，如波纹，看起来就像具有 loading 效果的骨架屏。
在图片居多的站点，使用低像素的图片进行占位也是一个不错的选择，图片配色及变化和原图相近即可，如果觉得生成低像素的图片成本较高，可以降级使用纯色色块代替，但色块的颜色最好和图片主体颜色相似，如果觉得这个成本还是很高，那么可以直接采用上面例子中统一颜色的色块。
骨架屏的精髓，并不是用什么来占位，而是无论什么内容占位，一定要保持渲染前和渲染后结构相似，不能差距太大，最好保持色块/图片间距一样，避免页面渲染后内容跳动。
## 骨架屏能用在哪里
现在的 Web 应用，从架构上来说分为前端渲染(CSR)和后端渲染(SSR)两种，骨架屏适用于前端渲染的页面，而后端渲染的页面渲染首屏时所有内容都已经存在了，因此无需骨架屏。但是，即使是后端渲染的页面有时也会存在前端渲染的区域，比如列表的加载，只要是用到 JavaScript 来渲染内容的地方，都可以选择性的使用骨架屏来占位。
由于近几年 Angular/React/Vue 的推出，前端渲染的站点越来越多，它们让开发复杂 Web App 变的很简单。它们的流行也大大提高了 App Shell 和骨架屏的普适性，大部分此类站点都可以采用这种模式。
## 在 Vue 项目中使用骨架屏
我们以 Vue 开发的单页应用为例，在其它框架上，实现思路是一致的。在这个示例中，为了方便调试，笔者将 Service Worker 的注册逻辑删除了。
开发者可以下载示例代码并启动，如下所示：
```bash
# 从 GitHub 下载代码到本地 pwa-book-demo 目录
$ git clone https://github.com/lavas-project/pwa-book-demo.git
# 进入到 chapter02/appskeleton-01 目录
$ cd chapter02/appskeleton-01
# 安装 npm 依赖
$ npm install
# 启动 chapter02 appskeleton-01 示例
$ npm run dev
```
为了方便调试，我们将 `src/main.js` 中 Vue 实例的挂载时间推迟了 2s，在这期间，我们能看到骨架屏的效果。
```javascript
// src/main.js
const app = new Vue({
router,
components: { App },
template: '
'
})
router.onReady(() => {
// 将 mount 时间延后 2s，便于查看效果
setTimeout(() => app.$mount('#app'), 2000)
})
```
然后，我们需要在 `index.html` 中添加骨架屏，如下：
```html
...
```
填写完成之后，刷新页面您能看到下图所示的骨架屏。
## 进阶优化：更快的展现骨架屏
在上面的例子中，为了让骨架屏尽早展现，我们需要做到以下两点：
1. 把骨架屏的 HTML 内联在 `index.html` 中，而不是用 JavaScript 来渲染
2. 骨架屏的 CSS 最好内联，保证骨架屏在最短的时间内渲染
可惜的是，尽管我们这么做了，也不一定能取得想要的结果，通过实际测试会发现骨架屏很难被用户看到，或者说它展示的时间不如预期的早。
### 现状分析
我们在上面的示例基础上来分析一下原因是什么。用 Chrome 调试工具中的 Performance 记录渲染流程，为了简单一些，我们可以将网络设置成 Slow 3G，会比较明显的发现骨架屏出现的时间非常短。
> 为了更接近生产环境，先将示例编译之后再调试。
```bash
# 在 chapter02/appskeleton-01 目录中
# 编译
$ npm run build
# 进入到编译后的 dist 目录
$ cd dist
# 安装静态文件调试服务
$ npm install -g edp
# 在 dist 目录中启动本地静态文件服务
$ edp ws start
```
打开 Chrome 浏览器访问 `http://localhost:8848`。下图是笔者用调试工具记录的页面渲染流程，发现页面第一次渲染是在 `app.*.css` 加载完成之后。
按照预想，骨架屏应该在 HTML 加载完成之后立刻渲染出来，也就是在浏览器获取外链资源的同时，这也是为什么我们把骨架屏的 HTML 和样式都内联的原因，然而事与愿违，浏览器并不买账。
### 浏览器做了什么
熟悉浏览器的开发者很快就能理解，这与浏览器的渲染顺序有关。
相信大家都整理过行李箱。在整理行李箱时，会根据每个行李的大小合理安排，大的和小的配合，填满一层再整理上面一层。如果突然有人跑来和你说电脑不用带了，要多带两件衣服，这时除了想打他之外，你还需要重新安排行李。在浏览器中，这个过程叫做重排（reflow），而那个馊主意就是新加载的样式文件。显而易见，重排的开销是很大的，需要尽力避免。
既然每个 CSS 文件都可能会触发重排和重绘，那索性等待 `` 中所有的外链样式文件加载完成之后再渲染，这个流程本身是没有问题的，却在骨架屏的应用中出了一些问题。
页面从加载到展现的大致顺序如下：
1. 加载 HTML 文件
2. 解析 DOM
3. 并行加载 CSS/JS 资源
4. 如果 `` 中存在外链的样式，则阻塞渲染等待样式文件加载并解析完成
5. 如果 `` 中存在外链的 script，则阻塞渲染等待 script 文件加载并执行完成
在 Vue 的项目编译完成之后，`` 标签中的结构如下，在 `` 标签中插入了一个外链的样式文件，导致骨架屏渲染推后。
```html
PWA Chapter02 Demo - App Skeleton
```
为了尽早展现骨架屏，我们将骨架屏渲染所需的样式和 HTML 内联，却被页面中其他的外链样式文件阻塞了渲染。拿上一节中的 Vue 示例来举例，由于浏览器解析完 DOM 之后是并行加载外链资源的，所以在样式文件加载完成之后，JavaScript 文件也基本已经加载完成，因此在骨架屏真的渲染出来之后没多久就被 JavaScript 渲染的真正内容取代，这就是为什么骨架屏出现非常靠后，效果大打折扣。
所以，我们需要告诉浏览器，请放心大胆的先渲染骨架屏。
### 避免样式文件的加载阻塞骨架屏的渲染
Webpack 编译的 Vue 项目，会在 `index.html` 的 `` 插入外链的样式文件，`
`，这无疑会阻塞骨架屏的渲染。浏览器还提供了预加载机制，使用方法非常简单，只需将 `rel="stylesheet"` 改为 `rel="preload"`，浏览器会在空闲的时候加载并缓存，之后再使用就不用重复加载。
这看似无关的技术，在骨架屏的应用里将起到很大的作用，因为**预加载的资源不会阻塞渲染**.
我们通过这种方式告诉浏览器，先不要管 `app.xxx.css`，直接渲染后续内容，在 `app.xxx.css` 文件加载完成之后，再将它重新设置为样式文件，如下代码所示：
```html
```
方法的核心是通过改变 `rel` 让浏览器重新认定这个 `
` 标签是样式文件，这样既不阻塞骨架屏的渲染，也能正常应用外链样式文件。
### 这样就完了吗？
如果不将 `
` 标签 `rel="stylesheet"` 改为 `rel="preload"`，浏览器会根据资源的书写顺序来顺序执行，即先应用外链样式，再执行外链 JavaScript 文件渲染主体内容。但是根据上面的步骤，我们使用预加载来加载样式文件，这样做的结果就是我们无法保证浏览器会先应用样式再运行 JavaScript 渲染内容，一旦 JavaScript 先执行并渲染出了内容，再应用外链样式，会导致页面重排和重绘，用户会先看到排版完全是乱的页面，再看到正常的页面，对用户体验是不小的伤害。
因此，我们还需要考虑到文件加载顺序的问题，在样式文件加载完成前，即使 JavaScript 已经渲染好了内容，也先不要替换掉骨架屏，等待样式文件加载完成后，再触发 JavaScript 进行挂载。
在 Vue 的项目中需要修改 `src/main.js` 和 `index.html` 文件。
```javascript
// src/main.js
const app = new Vue({
router,
components: { App },
template: '
'
})
/**
* 挂载 Vue 渲染好的 HTML 元素到 #app 中，替换掉骨架屏
*/
window.mount = function () {
app.$mount('#app')
}
```
```html
```
这样就好了吗？
还不够完善，如果样式文件在 JavaScript 文件之前加载，那么 `mount` 函数还没有声明，执行会出错，最终也导致主体内容没有渲染到页面上。还需要完善，增加一个标记告诉 JavaScript 样式是否加载完成，经过改造代码如下，同样还是 `src/main.js` 和 `index.html` 文件。
```javascript
// src/main.js
const app = new Vue({
router,
components: { App },
template: '
'
})
/**
* 挂载 Vue 渲染好的 HTML 元素到 #app 中，替换掉骨架屏
*/
window.mount = function () {
app.$mount('#app')
}
// 如果样式文件已经加载完成了，直接挂载
if (window.STYLE_READY) {
window.mount()
}
```
```html
```
考虑到浏览器不支持 JavaScript 的情况，那么还需要增加一个 `
`，允许我们在其中设置多个图片来源，就和 `
# 《PWA 应用实战》
欢迎走进 PWA 世界！！
## 简介
本书围绕着 PWA 以及周边技术，从概念入手，以实战的方式给读者讲述如何编写 PWA，以及如何编写体验最好、速度最快、安全的 PWA 站点。
本书主要从以下几个部分讲述 PWA。
- 设计与体验
- 基础技术
- Service Worker
- 离线与缓存
- 用户留存
- 安全
- 性能
## 关于作者
作者：**百度 Web 生态团队**
百度 Web 生态团队是 2017 年组建，旨在帮助国内 Web 的发展，提升 Web 的用户体验，目前已有多个产品，如 [LAVAS](https://lavas.baidu.com) 和 [MIP](https://www.mipengine.org)。
## 为什么写这本书
我们团队从成立到现在，已有 2 年，推出 LAVAS 和 MIP 也是我们的尝试之一，积极参与 Web 方向上的技术讨论，也经常去国内的技术会议上进行分享，虽不能说真给国内 Web 发展带来了多大的贡献，但我们至少做了很多尝试。
因此，我们希望将我们过去两年积累的 PWA 方面的经验写下来，不仅帮我们自己梳理知识结构，也希望这本书能帮助到正在读的您。
## 为什么开源
PWA 它还在不断进步，本书的内容随时需要更新，电子书对于我们来说，迭代起来很方便。
同时也欢迎对 Web 和 PWA 有浓厚兴趣的读者加入我们，一起来维护这本书，我们由衷感谢。
## 版权
本书为开源书，读者可以自由地分享。只要遵守惟下列条件：
- **署名** — 您必须给出适当的署名，提供指向本许可协议的链接，同时标明是否（对原始作品）作了修改。您可以用任何合理的方式来署名，但是不得以任何方式暗示许可人为您或您的使用背书。
- **非商业性使用** — 您不得将本作品用于商业目的。
- **禁止演绎** — 如您再混合、转换、或者基于该书的创作，您不可以分发修改作品。
- **禁止附加限制** — 您不得使用法律术语或采用技术措施限制其他人做许可协议允许的事情。
本书采用 [知识共享署名-非商业性使用 4.0 国际许可协议](https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode) 进行许可
## 最后
本书还在勘误阶段，可能会存在一定的问题，请您在分享的过程一定要注明来源，帮助所有读者溯源，让他们能够获得最新的修改内容版本。如果您在阅读的过程发现了书中的问题，欢迎提交 [Issue](https://github.com/lavas-project/pwa-book/issues) 反馈给我们，或者直接发送 [Pull Request](https://github.com/lavas-project/pwa-book/pulls) 帮助我们修正，感谢您对本书的支持和贡献！
================================================
FILE: SUMMARY.md
================================================
# Summary
* [HOME](README.md)
* [第1章 PWA 介绍](chapter01.md)
* [1.1 为什么会出现 PWA](chapter01/1-how-was-pwa-born.md)
* [1.2 什么是 PWA](chapter01/2-what-is-pwa.md)
* [1.3 PWA 的核心技术](chapter01/3-what-are-key-techs.md)
* [1.4 PWA 的发展](chapter01/4-how-is-pwa-going.md)
* [1.5 PWA 的未来](chapter01/5-the-future-of-pwa.md)
* [1.6 你的第一个 PWA](chapter01/6-your-first-pwa.md)
* [第2章 设计与体验](chapter02.md)
* [2.1 什么是好的用户体验](chapter02/1-what-is-good-ux.md)
* [2.2 设计与技术](chapter02/2-design-and-tech.md)
* [2.3 App Shell](chapter02/3-app-shell.md)
* [2.4 骨架屏](chapter02/4-app-skeleton.md)
* [2.5 响应式布局](chapter02/5-responsive-design.md)
* [第3章 基础技术简介](chapter03.md)
* [3.1 Promise](chapter03/1-promise.md)
* [3.2 Async 函数](chapter03/2-async-function.md)
* [3.3 Fetch API](chapter03/3-fetch-api.md)
* [3.4 Cache API](chapter03/4-cache-api.md)
* [3.5 IndexedDB](chapter03/5-indexeddb.md)
* [第4章 Service Worker](chapter04.md)
* [4.1 Service Worker 简介](chapter04/1-service-worker-introduction.md)
* [4.2 Service Worker 注册](chapter04/2-service-worker-register.md)
* [4.3 Service Worker 工作原理](chapter04/3-service-worker-dive.md)
* [4.4 Service Worker 调试](chapter04/4-service-worker-debug.md)
* [第5章 离线与缓存](chapter05.md)
* [5.1 资源请求的拦截代理](chapter05/1-fetch-event-management.md)
* [5.2 本地存储管理](chapter05/2-local-storage-management.md)
* [5.3 资源请求响应策略](chapter05/3-respond-strategy.md)
* [5.4 预缓存方案](chapter05/4-precache.md)
* [5.5 使用 Workbox](chapter05/5-workbox.md)
* [第6章 用户留存](chapter06.md)
* [6.1 Web 应用清单](chapter06/1-manifest-json.md)
* [6.2 凭证管理 API](chapter06/2-credentials-api.md)
* [6.3 桌面通知](chapter06/3-notification-api.md)
* [6.4 网络推送](chapter06/4-web-push-api.md)
* [6.5 Payment Request API](chapter06/5-payment-request-api.md)
* [第7章 安全](chapter07.md)
* [7.1 使用 HTTPS 保护站点安全](chapter07/1-https.md)
* [7.2 内容安全策略](chapter07/2-CSP.md)
* [7.3 同源策略](chapter07/3-policy.md)
* [7.4 典型的安全漏洞](chapter07/4-vulnerability.md)
* [第8章 性能](chapter08.md)
* [8.1 加载性能 ](chapter08/1-loading-performance.md)
* [8.2 渲染性能 ](chapter08/2-rendering-performance.md)
* [第9章 PWA 与搜索](chapter09.md)
* [9.1 搜索引擎收录](chapter09/1-search-engine-index.md)
* [9.2 PWA 与 AMP/MIP](chapter09/2-pwa-and-amp-and-mip.md)
* [9.3 全站 AMP/MIP](chapter09/3-whole-site-amp-and-mip.md)
* [9.4 AMP/MIP 预加载 PWA](chapter09/4-preload-pwa.md)
* [附录1 使用 Lighthouse 测评 PWA](appendix01.md)
* [1 使用 Lighthouse 测评 PWA](appendix01/1-lighthouse.md)
* [2 Lighthouse 评分指南](appendix01/2-lighthouse-score-guide.md)
* [3 Lighthouse 使用案例](appendix01/3-lighthouse-case.md)
* [感谢](thanks.md)
================================================
FILE: appendix01/1-lighthouse.md
================================================
## 使用 Lighthouse 测评 PWA
Lighthouse 是 Google Chrome 推出的一个开源自动化工具，能够对 PWA 多方面的效果指标进行评测，并给出最佳实践的建议以帮助开发者改进 PWA 的质量。它的使用方法也非常简单，我们只需要提供一个要测评的网址，它将针对此页面运行一系列的测试，然后生成一个有关页面性能的报告。通过报告我们就可以知道需要采取哪些措施来改进应用的性能和体验。
### 使用入门
针对不同的适用场景，我们可以通过多种方式来安装并使用 Lighthouse：
- Chrome 浏览器插件。Chrome 插件的形式提供了更加友好的用户界面，方便读取报告。
- Chrome DevTools。该工具集成在最新版本的 Chrome 浏览器中，无需安装即可使用。
- Lighthouse CLI 命令行工具。方便将 Lighthouse 集成到持续集成系统中。
- 编程的方式。我们也能通过 Node.js 模块引入 Lighthouse 工具包，以编程的形式来使用它。
下面我们依次介绍上述这几种使用方法。
### Chrome 插件
下载 Google Chrome 52 或更高版本，并安装 [Ligthouse Chrome 插件](https://chrome.google.com/webstore/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk)。打开需要进行测评的页面，并点击 Chrome 工具栏上的 Lighthouse 图标如下图：
如果在工具栏上没有看到此图标，它可能隐藏在 Chrome 的主菜单中。点击此图标后，我们会看到一个展开菜单，如下图
在 `Options` 选项里，可以选择需要的测评项，包括性能、无障碍访问性、最佳实践、SEO、PWA，默认情况下，选择全部即可。
点击 Generate report 按钮以针对当前打开的页面运行 Lighthouse 测试。
在完成测评后，Lighthouse 将打开一个新标签，并在页面的结果上显示一个报告。
在这里，我们就能看到关于 PWA, Performance, Accessibility, Best Practices 四个方面存在的问题以及相关建议。根据这些去优化你的站点吧！
### Chrome DevTools
在最新版本的 Chrome 浏览器中，Lighthouse 已经直接集成到了调试工具 DevTools 中了，因此不需要进行任何安装或下载。我们先打开需要进行测试的页面，打开 Chrome DevTools，选择 `Audits` 面板，就能看到 Lighthouse 工具的一些配置选项，选择需要的配置后，点击 `Run audits`，工具就会对当前页面进行性能的测评。
### 命令行工具（Lighthouse CLI）
上述两种工具提供了较为基础、快捷的使用方式，针对进阶的高级开发者，Lighthouse 的命令行工具更为合适。它提供了多种详细的使用参数，通过参数的配置，能够更灵活地进行测评并输出报告结果。此外，在一些自动化的持续集成场景中，命令行工具显得十分有用。
#### 安装
安装 [Node](https://nodejs.org/zh-cn/download/)，需要 Node 8 LTS(8.9) 及以上版本。
以全局方式安装：
```shell
npm install -g lighthouse
# or use yarn:
# yarn global add lighthouse
```
#### 运行 CLI
针对一个页面运行 `lighthouse` 命令，进行测评：
```shell
lighthouse https://www.example.com/
```
> 注意：
> CLI 相较于插件和 DevTools 存在一些尚未修复的问题，比如对 Ubuntu 系统支持不好，会抛 NO_FCP 的错误。对于某些网站支持不好，这些网站可能存在以下特征导致 NO_FCP 错误的发生：
> 1. 初始渲染的时候页面不包含文本，而只包含一个 spinner
> 2. 你的站点的启动和渲染主要内容在 5-10s 的延迟之后发生
> [点击](https://github.com/GoogleChrome/lighthouse/issues/6154)查看最新解决方案
默认情况下，运行报告将以 html 的格式输出在当前目录的 `./
接下来，开发者可以根据下面的步骤逐步开启 Web App Manifest 和 Service Worker，开始体验自己的第一个 PWA。
## 添加到主屏
根据前面的章节介绍，增加用户黏性最好的方式是把这个 PWA 放在用户的主屏上，它背后的技术就是 Web App Manifest，接下来，我们就来看看如何使用。
第一步，站点需要新增一个文件：`manifest.json`，这个文件中包含站点的名称、图标地址、入口地址、显示模式等信息，并且通过一个地址能够访问到该文件，在我们下载下来的代码中，这个文件在 `chapter01/public/` 目录下，启动调试服务器后，可以通过 `http://127.0.0.1:8088/manifest.json` 访问到。
```json
{
"name": "PWA Chapter01 Demo",
"short_name": "Chapter01 Demo",
"icons": [
{
"src": "assets/images/icons/icon_144x144.png",
"sizes": "144x144",
"type": "image/png"
},
{
"src": "assets/images/icons/icon_152x152.png",
"sizes": "152x152",
"type": "image/png"
},
{
"src": "assets/images/icons/icon_192x192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "assets/images/icons/icon_512x512.png",
"sizes": "256x256",
"type": "image/png"
}
],
"start_url": "/index.html",
"display": "standalone",
"background_color": "#fff",
"theme_color": "#1976d2"
}
```
第二步，在 HTML 页面中添加对 `manifest.json` 文件的引用，在示例中，打开 `chapter01/public/index.html` 文件，添加如下代码到 `` 中。
```html
```
第三步，在移动端浏览器 Chrome 中打开启动的地址，如果在同一个局域网内，可以通过电脑的 IP 地址访问，比如笔者的电脑的局域网 IP 是 `192.168.0.100`，那么就可以通过 `http://192.168.0.100:8088/` 访问。访问成功后，点击添加到桌面按钮，PWA 就会出现在主屏上，如下图所示。
点击 PWA 的图标，不仅具有启动画面，还具有完全沉浸式的体验，如下图所示。
Web App Manifest 的内容远不止这些，可以阅读本书的后续章节，会详细介绍。
> 如果添加到主屏始终不成功，可以阅读本书的第五章，相信会解决您的问题。
## 离线可用
离线可用依赖于 Service Worker 的应用，接下来来看看在示例代码中如何启用 Service Worker。
第一步，您需要一个 Service Worker 文件，在示例中，可以查看 `chapter01/public/sw.js` 文件，并且可以通过 `http://127.0.0.1:8088/sw.js` 访问到该文件，sw.js 文件具体的内容会在后续章节逐步讲解。
第二步，在 HTML 页面中注册 Service Worker。打开 `chapter01/public/index.html` 文件，找到下面的代码，并将注释打开。
```html
```
第三步，接下来可以通过打开电脑上的 Chrome 来验证是否注册成功，并且是否离线可用。
通过 Chrome 访问 `http://127.0.0.1:8088` 打开我们的第一个 PWA，并且打开调试工具，点击 `Application` 菜单栏，再点击调试工具左边的 Service Worker 选项，会看到 `sw.js` 的注册信息，如下图所示：
那么，我们检查一下是否真的离线可用，勾选上图中的 `Offline` 复选框，让 Chrome 在这个标签页下保持断网状态。
接下来，刷新页面，您会发现页面依然能正常渲染，这就是 PWA 的离线可用，可以利用 Service Worker 做很多事情，缓存页面框架和骨架屏，提升页面首屏速度，甚至可以缓存部分数据。Service Worker 将在本书的后续章节会重点讲述。
## 总结
以上就是您的第一个 PWA，麻雀虽小，五脏俱全，能被添加到主屏，能离线可用，短短的几行代码就在原站点的基础上实现了这两个功能，并且没有侵入性，代价也很小，它确实奉行渐进式的原则。
================================================
FILE: chapter01.md
================================================
# 什么是 PWA
随着移动互联网的发展，Native App 开始兴起，那么 Web App 落伍淘汰了吗？很显然答案是没有，它依然生机勃勃，和 Native App 互相依存，还衍生出很多 Native App 和 Web App 相结合的技术，比如 Hybrid App，React Native 等，Angular/ReactJS/Vue 也都是在这期间才发展起来的优秀的框架，可见，Web App 仍在不断进化，PWA（Progressive Web Apps）就是在这背景下诞生的。
本书第一章会着重介绍 PWA 的基础概念，让读者对 PWA 有个大致的了解，后续章节会再深入讲解。本章会探讨为什么会出现 PWA，PWA 的出现解决了哪些问题，然后再看 PWA 的主要技术，并且会结合实际的例子让读者能够创建一个简单的 PWA。
================================================
FILE: chapter02/1-what-is-good-ux.md
================================================
# 什么是好的用户体验
PWA 的核心是用户体验，它的核心技术（如 Service Worker，Web App Manifest 等）都是为了提升 Web App 用户体验，但“体验”其实是个很主观的感受，我们很难用一个或几个量化指标来轻易的衡量用户体验，判断优劣，甚至不同的人有不同的理解，不过体验好的站点都有一些共性，包括不限于下面列出来的一些特征。
* 首屏速度快
* 顺滑流畅的动画效果
* 有用户操作的反馈
* 比较简单的操作步骤
* 主体内容比较在最显眼的位置
* 整站体验一致
* 无障碍访问，不同的人群均可使用
用户体验的核心是用户，设计师需要站在用户的角度思考用户需要什么，在做设计的时候需要做充分的调研。移动设备上的用户目的性很强，需要在巴掌大小的屏幕上快速找到自己想要的内容。
很多公司都沉淀了自己的一套设计原则和方案，百度在 2018 年发布了《[百度移动搜索落地页体验白皮书 4.0](https://ziyuan.baidu.com/college/documentinfo?id=2492)》，这里面列出了很多体验上的指导原则。Google 也在开发者网站上列出了他们总结的 25 项设计原则，《[What Makes a Good Mobile Site?](https://developers.google.cn/web/fundamentals/design-and-ux/principles/)》。
笔者将他们整合了一下，并且加入了一些自己认为重要的设计原则，如下：
1. 主操作区域要放在显眼位置
2. 不要出现巨大的弹层盖住主要内容，比如下载条幅可以放在顶部并且添加关闭按钮
3. 推送的通知需要满足准确、准时和相关三个特征
4. 尽量减少用户的输入或者减小输入的代价，自动帮用户填写已知的数据，选择合适的 `input` 类型
5. 缩短不必要的流程，让整个转化流程更简洁
6. 响应式布局，让站点在不同尺寸的浏览器上都有好的体验
7. 图片清晰，且点击可放大查看更清晰的图片
8. 避免不必要的切换，让用户在一个浏览窗口内完成所有的操作
9. 如果需要申请设备权限，如定位、通知等，在申请前需要明确的告诉用户为什么需要这些设备权限
10. 可点击区域的宽度和高度不应小于 48px
11. 整站体验需要一致，页面框架、主色调等需要保持统一
好的设计原则远不止上面列出来的这些，好的设计不仅需要美观，还需要方便易用。
那么站在开发者的角度，哪些需要重点关注呢？
================================================
FILE: chapter02/2-design-and-tech.md
================================================
# 设计与技术
好的设计没有好的技术来实现同样无法达到最佳的用户体验。
设计与技术并不只是实现的关系，而是需要互相配合，再完美的设计如果不能实现，那也只是白费，而一些技术上的优化也需要设计给予配合才能更加完美。
上一节中，列出了很多设计原则，有些是比较容易实现的，但有些也比较复杂，复杂到需要很大的篇幅来描述。下面我们总结了几个比较重要的设计与技术相结合的问题。
## 首屏速度
首先是首屏速度，它对于站点的重要性不言而喻，特别是移动端，下图是页面加载时间与跳出率和会话的关系。
那么技术上如何提升首屏速度呢？首选我们会想到将 CSS 放在头部，JS 放在页面底部等技术手段，这些方法确实卓有成效，但是有没有更好的方法呢？
在这里就要讲到设计与技术相辅相成的一种 Web 的设计，那就是 App Shell，以及和 App Shell 配套使用的骨架屏（App Skeleton），本章后续会详细介绍。
## 响应式布局
移动设备种类越来越多，屏幕大小不一，有小到高宽不足 40 毫米的智能手表，也有高度接近 300 毫米的 iPad。尽管如此，大部分的 Web 站点都没有对尺寸不一的设备做过适配，导致在移动端体验很差，这时就凸显响应式布局的重要性。
响应式布局不是一个纯技术的问题，在设计之初就需要设计师考虑众多问题，例如在不同尺寸的设备上，字体大小设置多少，页面如何布局，主体内容放在哪里，叠起来的内容如何使用户更方便的找到，小尺寸屏幕如何展现列数较多的表格，等等。
而开发者需要考虑如何实现根据屏幕尺寸大小动态调整字体大小或者布局，其中涉及到的知识点很多，在本章后续小节中会详细介绍。
## 流畅的动画
动画是体验非常重要的一部分，站点展现速度再快，没有任何交互动画，也会显得没有生气，它赋予了站点“生命”。但是如果动画掉帧，造成卡顿，反而会让用户觉得站点体验很差，所以，我们需要的是流畅的动画。
动画的设计没有想象中的简单，过多的动画和没有动画体验同样糟糕，动画过多会让用户觉得烦躁，因此需要设计师在初期考虑到参与动画的元素、动画的类型、动画的持续时间等，而开发者需要考虑如何实现流畅的动画。在本章后续小节中同样会展开介绍。
================================================
FILE: chapter02/3-app-shell.md
================================================
# App Shell
在第一章中已经简单介绍过 App Shell，这个小节我们会更深入学习如何构建和使用 App Shell。它并不是一种新的技术或者 API，而是设计与技术相结合产生的一种整站设计方案，减少用户进入页面的等待时间，用户能够快速看到页面的主体结构，虽然这时主体内容没有渲染出来，但是给用户感官上的体验是这个页面渲染很快，那么来看一下什么是 App Shell。
## 什么是 App Shell
PWA 多数采用单页应用（Single Page Application）的方式编写，这样能减少页面跳转带来的开销，并且开发者可以在页面切换时增加过渡动画，避免出现加载时的白屏。那么在页面切换时页面上固定不动的内容就是 App Shell 的一部分。
应用从显示内容上可以粗略的划分为内容部分和外壳部分。App Shell 就是外壳部分，即页面的基本结构，如下图所示：
上面只是 App Shell 显示的部分，那么是谁去加载内容区域呢，是谁接管了页面的状态呢，是谁初始化页面的样式呢？
也是 App Shell，它不仅包括用户能看到的页面框架部分，还包括用户看不到的代码逻辑。因此，我们可以总结一下 App Shell 的定义，App Shell 是页面能够展现所需的最小资源集合，即支持用户界面所需的最小的 HTML、CSS 和 JavaScript 等静态资源集合。采用 App Shell 的站点，每个页面都会先加载 App Shell 的内容，再由 App Shell 根据当前页面 URL 渲染对应的主体内容。
上图给出了基本的 App Shell 例子，它包含头部导航，侧边栏等，对于一个应用来说它有一个相对稳定的结构。但是一个站点可以有多个 App Shell，以电商网站举例，不同品类的商品主题馆，颜色不同，甚至结构也会有一些区别，这就需要开发者灵活处理，可以分为多个 Shell，或者在一些页面去掉 Shell。
## 如何正确使用 App Shell
单独使用 App Shell 并不是一个很好的主意，对于速度要求比较高的站点来说，它会导致用户看到主要内容的时间延后，那么有没有办法呢？这个时候开发者会提到使用浏览器的 HTTP 缓存，这确实是一个不错的主意，但它也有一些很难解决的问题。
* 难以确定合适的 HTTP 缓存设置时间，也不适合更新比较频繁的站点
* HTTP 缓存只有在 URL 相等的情况下才能起作用，这不符合 PWA 每个页面有唯一 URL 的要求
那么有没有更好的缓存方案呢？在第一章中，我们提到了 Service Worker 可以拦截网络请求和操作本地缓存，这给了我们足够的想象空间，可以结合 App Shell 和 Service Worker 来解决缓存问题。
1. 使用 Service Worker 预缓存 App Shell 的静态资源
2. 用户访问 Web 站点时，通过 Service Worker 拦截请求
3. Service Worker 返回缓存中的 App Shell 给浏览器
4. App Shell 根据当前的 URL 再去请求对应的数据来渲染
这样可以解决上面提到的所有问题。下面是 App Shell 和 Service Worker 结合使用的收益。
* 第二次访问速度极快且稳定。由于 App Shell 的内容已经缓存在本地缓存中，用户第二次访问会在极短的时间内渲染出 App Shell
* 为用户节省流量。用户在后续的访问都不会再请求 App Shell 的内容，而是只请求主体内容，不用加载一些公用的静态文件。
* 具有 Native App 的用户体验。无论是第一次访问还是后续页面的切换，都具有唯一不变的区域，没有传统 Web 页面切换的白屏。
## App Shell 的案例
[https://lavas.baidu.com](https://lavas.baidu.com) 是百度 Web 生态团队开发的 Lavas 的官网。这是一个体验比较好的 PWA 站点，那么来分析一下这个站点是如何结合 Service Worker 和 App Shell 的。
下图右侧就是 Service Worker 缓存在 [Cache Storage](https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage) 中的 App Shell 内容，左侧顶上的 banner 就是 App Shell 的可见区域。整个页面的外壳部分被缓存起来，在下次访问时由 Service Worker 取出并直接返回，如果把网络断开再刷新页面，页面依然能够正常渲染。
经过我们前面的分析，App Shell 和 Service Worker 结合首屏展现速度会非常快，那么在这个案例中，首屏的性能到底如何呢，来看一下下面这张图，这张渲染性能的图是在 PC Chrome 上统计的。
从上图中，能看到大概在时间轴 200ms 的时候，已经渲染出了 App Shell。查看浏览器统计的详细 Event Log，上图中页面首次绘制是在 230ms，再减去上一个页面的销毁时间大概 80ms，实际上当前页面从开始发送请求到首屏渲染出来所花掉的时间是 **150ms**，对于用户来说，页面几乎是瞬间呈现，没有白屏时间。并且从上图中，也能看出渲染的顺序是先 App Shell，然后再渲染出主体内容，和我们预想的一样。
如果您觉得这个站点过于简单，无法体验 Service Worker 和 App Shell 结合的优势，下面列出了该团队提供的另一个较复杂的使用了 App Shell 模型的例子，也同样是体验非常良好的 PWA 站点。
[https://lavas.baidu.com/12306/](https://lavas.baidu.com/12306/)，这是百度 Web 生态团队开发的一个 demo，参考中国铁路在线售票系统 12306。
> 注意，这个站点只是 demo，不是 12306 官方的网站，不要输入密码等个人信息。
## 如何在 Vue 项目中使用 App Shell + Service Worker
第一章的例子也采用了 App Shell + Service Worker 的方式，但是没有采用任何框架辅助，在实际项目中，这样不借助任何框架编写 SPA 是比较少见的。在现代项目中，采用 Angular/React/Vue 来编写复杂 SPA 的项目占大多数，那么如何在这些框架中使用 App Shell 和 Service Worker 呢，下面我们用一个实际的例子来演示一下。
### 启动示例
和第一章的例子一样，您需要准备 Git，Node.js 和 npm 环境，准备完成后，可以通过下面的命令下载我们的示例，这个示例是根据 `vue-cli` 创建的很基本的 Webpack 模板，可以参考 npm 上的文档 [vue-cli 简介](https://www.npmjs.com/package/vue-cli)。
```bash
# 从 GitHub 下载代码到本地 pwa-book-demo 目录
$ git clone https://github.com/lavas-project/pwa-book-demo.git
# 进入到 chapter02/appshell 目录
$ cd chapter02/appshell
# 安装 npm 依赖
$ npm install
# 启动 chapter02 appshell 示例
$ npm run dev
```
在命令行中看到输出 `Your application is running here: http://localhost:8080` 后，代表服务已经启动成功，打开浏览器，访问 `http://localhost:8080`，能看到下图所示的页面。
这时，如果您打开 Chrome 调试工具，并定位到 Application 栏目，会发现没有注册 Service Worker，这是因为我们在开发模式下没有生成 `service-worker.js` 文件，根据我们的经验，在开发模式下启用 Service Worker 对开发调试会带来很大的影响，因为如果 Service Worker 写的不够完善，会导致开发中修改后的文件得不到及时的更新，没有经验的开发者会花较多的时间来排查，因此我们的 demo 只有在编译之后才会生成 `service-worker.js` 文件。
```bash
# 编译
$ npm run build
# 进入到编译后的 dist 目录
$ cd dist
# 安装静态文件调试服务
$ npm install -g edp
# 在 dist 目录中启动本地静态文件服务
$ edp ws start
```
在命令行输出了下面的文本后，即代表服务已经启动。
```
mockservice
edp INFO EDP WebServer start, http://xxx.xxx.xxx.xxx:8848
```
打开浏览器，输入 `http://localhost:8848`，能看到调试模式下相同的页面。不同的地方在于，这个时候已经安装了 Service Worker，打开 Chrome 调试工具，定位到 Application -> Service Worker，如下图所示。
点击 Chrome 调试工具左侧的 Cache -> Cache Storage，能看到有两个 Cache Storage 实例，其中一个以 `sw-precache-` 开头的实例里面预缓存了 App Shell 所需的静态文件，如下图。
### 示例解析
#### 哪些区域是 App Shell
在这个 Vue 的示例里，可见部分哪些是 App Shell 呢，我们可以查看 `src/App.vue` 文件。
```html
