最近我们团队把一个旧的Web系统迁移到了PWA（渐进式Web应用）架构整个迁移过程持续了两个多月遇到了很多坑也学到了很多东西最终迁移完成之后，系统的用户体验有了很大提升加载速度更快支持离线访问能添加到主屏幕像原生App一样使用。

今天想分享一下这次PWA迁移的实战经验包括为什么要做PWA迁移迁移的整体思路具体的实施步骤遇到的坑和解决方案以及，最终的效果和经验总结希望能给想做PWA迁移的团队一些参考。

一、为什么要做PWA迁移

先说说我们为什么要做PWA迁移我们的系统是一个面向C端用户的电商平台主要用户都是在手机端访问之前，我们有原生App（iOS和Android）也有移动端Web网站，但是存在一些问题。

问题1：移动端Web体验差加载慢：

最主要的问题是移动端Web体验差加载慢我们的旧系统是传统的多页面应用（MPA）每次页面跳转都要重新加载整个页面在移动网络环境下加载速度很慢特别是网络不好的时候，经常要等好几秒才能打开页面用户很容易流失，而且页面切换没有动画体验比较生硬和原生App差距很大。

问题2：无法离线访问网络不好时用不了：

第二个问题是无法离线访问用户在地铁电梯等网络不好的地方就完全用不了我们的系统而原生App能缓存数据离线也能看一些内容这导致很多用户更愿意用原生App而不是Web网站，但是原生App的开发和维护成本高更新也慢需要用户主动更新很多用户还不愿意下载App占手机空间，所以我们想找一个折中的方案既能有接近原生App的体验又能保持Web的优势（不用下载随时访问更新快）。

问题3：用户留存低没有推送能力：

第三个问题是用户留存低没有推送能力Web网站用户访问一次之后，就走了很难再次，触达用户而原生App能通过推送消息唤醒用户提升留存和活跃度我们之前，也想过用短信，或者微信推送，但是成本高效果也不好用户体验也差，所以想通过PWA的Web Push能力来实现推送提升用户留存。

问题4：PWA技术成熟Google大力推广：

另外2018年PWA技术已经比较成熟了Chrome等主流浏览器都支持Service WorkerWeb App ManifestWeb Push等PWA核心特性Google也在大力推广PWA提供了很多工具和最佳实践很多知名公司（比如Twitter阿里巴巴等等）都已经做了PWA迁移效果很好，所以我们觉得时机成熟了可以尝试把系统迁移到PWA架构。

综合以上原因我们决定做PWA迁移希望能提升移动端用户体验接近原生App的水平，同时保持Web的优势。

二、PWA的核心概念

在说迁移过程之前，先简单介绍一下PWA的核心概念和技术点方便大家理解后面的内容。

PWA（Progressive Web App渐进式Web应用）不是一个单一的技术而是，一系列Web技术的组合让Web应用能具有接近原生App的体验核心技术包括：

1. Service Worker：

Service Worker是PWA的核心它是一个运行在浏览器后台的脚本独立于网页能拦截和处理网络请求缓存资源实现离线访问和，快速加载Service Worker是PWA能实现离线访问和极速加载的关键。

2. Web App Manifest：

Web App Manifest是一个JSON文件描述了应用的名称图标主题色启动方式等等信息能让用户把Web应用添加到手机主屏幕像原生App一样启动有自己的图标和启动画面不用通过浏览器访问。

3. HTTPS：

PWA要求网站必须使用HTTPS因为Service Worker涉及拦截网络请求安全要求高必须在安全的环境下运行，所以迁移到PWA首先，要确保网站支持HTTPS。

4. 响应式设计：

PWA要求应用能适配各种屏幕尺寸在手机平板桌面等设备上都能正常显示和使用，所以响应式设计是基础。

5. Web Push：

Web Push能让Web应用像原生App一样给用户推送消息，即使用户没有打开网页也能收到推送能提升用户留存和活跃度。

6. 应用外壳架构（App Shell）：

App Shell是一种架构模式把应用的基础UI框架（导航栏底部栏等等）和内容分离基础UI框架提前缓存到本地每次加载只需要获取内容数据能大大提升加载速度和用户体验是PWA常用的架构模式。

三、迁移的整体思路

我们的旧系统是传统的多页面应用（MPA）后端用PHP渲染页面前端主要是jQuery+ 原生JS要迁移到PWA架构不是一个小工程我们经过讨论确定了整体的迁移思路。

思路1：渐进式迁移不重写：

最重要的思路是渐进式迁移不完全重写，因为我们的旧系统已经运行了几年功能复杂代码量大，如果完全重写风险太大周期也太长，所以我们决定采用渐进式迁移的方式在旧系统的基础上逐步加入PWA的特性先做最核心的功能验证效果，然后逐步完善这样风险小也能快速看到效果。

思路2：先做核心页面再逐步扩展：

我们没有一上来就把所有页面都改成PWA而是先选了几个核心页面（首页商品详情页购物车）做PWA迁移验证技术方案和效果等核心页面迁移完成效果验证通过之后，再逐步扩展到其他页面这样能控制风险也能快速验证方案的可行性。

思路3：保留旧系统新老并存灰度发布：

迁移过程中我们保留了旧系统新老系统并存通过灰度发布的方式先让一小部分用户使用新的PWA版本观察数据和反馈没问题之后，再逐步扩大范围直到全量发布这样，即使新系统有问题也只影响一小部分用户能快速回滚风险可控。

思路4：以用户体验为核心数据驱动：

整个迁移过程我们都以用户体验为核心用数据驱动决策，比如我们会监控页面加载时间跳出率转化率用户停留时间等等指标对比新老系统的数据看PWA迁移是否真的提升了用户体验和业务指标用数据说话而不是凭感觉。

四、具体实施步骤

下面详细说说我们的具体实施步骤。

步骤1：HTTPS改造：

第一步是HTTPS改造，因为PWA要求必须使用HTTPS我们的旧系统之前，虽然有HTTPS但是不是全站HTTPS有些页面还是HTTP而且证书也快过期了，所以我们首先，做了全站HTTPS改造申请了新的SSL证书配置了服务器把所有HTTP请求都301重定向到HTTPS确保全站都是HTTPS这是PWA的基础必须先做好。

HTTPS改造的过程中也遇到了一些问题，比如有些资源（图片脚本样式）还是用的HTTP链接导致混合内容问题浏览器会拦截，或者警告我们把所有资源链接都改成了相对路径，或者HTTPS链接解决了混合内容问题，另外HTTPS对性能有一定影响，因为TLS握手需要时间我们通过开启HTTP/2配置HSTS会话复用等方式优化了HTTPS的性能把影响降到最低。

步骤2：前端架构改造引入App Shell：

第二步是前端架构改造引入App Shell架构我们的旧系统是多页面应用每次页面跳转都要重新加载整个页面包括公共的UI部分（导航栏底部栏等等）效率很低我们把架构改成了App Shell模式把公共的UI框架抽离出来作为App Shell提前缓存到本地页面跳转的时候，不重新加载整个页面而是通过AJAX获取页面内容数据动态渲染内容区域这样页面切换更快也能实现页面切换动画体验更接近原生App。

这个改造工作量比较大，因为要把原来的多页面改成单页面应用（SPA）的模式我们用了Vue.js作为前端框架，因为它轻量易上手适合渐进式改造我们没有一下子把所有页面都改成Vue组件而是先把核心页面改成Vue组件其他页面暂时还是原来的方式通过iframe或者跳转的方式集成逐步迁移这样能控制工作量和风险。

步骤3：注册Service Worker实现资源缓存：

第三步是注册Service Worker实现资源缓存这是PWA的核心步骤我们写了一个Service Worker脚本注册到浏览器，然后通过Service Worker缓存应用的静态资源（JSCSS图片字体等等）和App Shell的HTML实现离线访问和快速加载。

我们采用了两种缓存策略：

  1. Cache First（缓存优先）：对于静态资源（JSCSS图片字体等等）和App Shell采用缓存优先策略先从缓存读取没有的话，再从网络获取，并且更新缓存这样静态资源加载非常快，而且能离线访问。
  2. Network First（网络优先）：对于动态数据接口采用网络优先策略先从网络获取最新数据网络失败的话，再从缓存读取上次的数据这样能保证数据的新鲜度，同时也能在离线时显示缓存的数据。

Service Worker的开发和调试比较麻烦，因为它运行在后台生命周期比较特殊我们用了Chrome DevTools的Application面板来调试Service Worker能查看缓存内容模拟离线更新Service Worker等等很方便，另外我们也用了Google的Workbox库来简化Service Worker的开发Workbox封装了常用的缓存策略和工具函数能大大简化Service Worker的代码提高开发效率推荐大家使用。

步骤4：添加Web App Manifest支持添加到主屏幕：

第四步是添加Web App Manifest支持添加到主屏幕我们创建了一个manifest.json文件配置了应用的名称短名称图标（多种尺寸）主题色背景色启动方式（standalone全屏模式像原生App一样）启动画面等等，然后在HTML的head里引用这个manifest文件这样浏览器就能识别这是一个PWA应用提示用户添加到主屏幕。

添加到主屏幕之后，用户点击图标启动应用会像原生App一样全屏显示没有浏览器的地址栏和工具栏体验非常接近原生App而且启动速度也很快，因为App Shell已经缓存到本地了这大大提升了用户体验也能提升用户留存，因为用户把应用放在主屏幕上更容易再次，打开。

步骤5：实现Web Push推送：

第五步是实现Web Push推送我们用了Web Push协议结合Service Worker实现推送功能用户首次访问的时候，会弹出授权提示问用户是否允许接收推送用户同意之后，我们会获取用户的推送订阅信息（endpointkeys等等）保存到后端服务器需要推送的时候，后端调用推送服务（浏览器厂商的推送服务）给用户发送推送消息用户的浏览器收到推送之后Service Worker会显示通知用户点击通知就能打开应用跳转到对应页面。

Web Push的实现相对复杂一些涉及前端授权和订阅后端推送服务Service Worker通知显示等等我们用了web-push这个Node.js库来简化后端推送的开发，另外需要注意不同浏览器的推送服务不一样（Chrome用FCMFirefox用Mozilla的推送服务等等）但是Web Push协议是标准的web-push库已经帮我们处理了这些差异不用自己适配比较方便。

不过Web Push在iOS Safari上还不支持（2018年的时候）只有AndroidChrome等浏览器支持，所以推送功能只能覆盖一部分用户，但是，即使这样也能提升不少用户留存和活跃度效果还是不错的。

步骤6：性能优化：

第六步是性能优化PWA的一个重要目标是提升加载速度和用户体验，所以我们做了很多性能优化工作包括：

  1. 代码分割和懒加载：把JS代码按页面分割按需加载减少首屏JS体积提升首屏加载速度。
  2. 资源压缩和合并：压缩JSCSS图片等等资源减少体积合并小文件减少请求数。
  3. 图片优化：用WebP格式替代JPG/PNG减少图片体积用响应式图片根据屏幕加载合适尺寸的图片。
  4. 预加载和预获取：对关键资源用preload预加载对用户可能访问的下一个页面资源用prefetch预获取提升后续页面加载速度。
  5. 缓存策略优化：优化Service Worker的缓存策略合理设置缓存时间和，更新机制既保证加载速度又保证数据新鲜度。

通过这些性能优化我们的首屏加载时间从原来的平均3-5秒降到了1秒以内（在，4G网络下）2G/3G网络下也能在2-3秒内加载完成提升非常明显。

步骤7：测试和兼容：

第七步是测试和兼容PWA涉及很多新技术不同浏览器的支持情况不一样，所以需要做充分的测试和兼容处理我们测试了主流的移动端浏览器（ChromeSafariFirefoxUCQQ微信等等）以及不同的操作系统（iOSAndroid）和不同的网络环境（WiFi4G3G2G离线）确保在各种环境下都能正常使用。

对于不支持PWA特性的浏览器（比如iOS Safari不支持Service Worker和Web Push2018年的时候）我们做了降级处理还是用原来的方式访问保证基本功能可用只是没有PWA的增强体验这样能保证所有用户都能正常使用系统，同时支持PWA的浏览器用户能享受更好的体验这也是"渐进式"的含义逐步增强不强制要求。

五、遇到的坑和解决方案

迁移过程中我们遇到了很多坑这里分享几个比较典型的坑和解决方案。

坑1：Service Worker缓存导致更新不及时：

这是最常见的坑Service Worker会缓存静态资源导致我们更新了代码之后，用户端还是用的旧的缓存看不到更新，而且Service Worker的更新机制比较特殊需要用户关闭所有标签页重新打开才能激活新的Service Worker很多用户不知道这个导致更新不及时甚至出现新旧版本冲突的问题。

解决方案：

  1. 给静态资源文件名加hash（比如app.abc123.js）这样内容变了文件名就变缓存自然就更新了。
  2. 在Service Worker里实现skipWaiting和clientsClaim让新的Service Worker安装后立即激活，并且接管所有页面不用等用户关闭标签页。
  3. 给用户提示有新版本让用户手动刷新页面更新到新版本我们做了一个更新提示弹窗检测到新的Service Worker安装后提示用户"有新版本点击刷新"用户点击后刷新页面更新到新版本用户体验比较好。
  4. 合理设置HTML页面的缓存时间不要缓存太久确保用户能及时获取最新的HTML从而加载最新的资源。

坑2：离线时数据同步问题：

第二个坑是离线时数据同步问题用户离线时可能会做一些操作（比如加入购物车提交订单等等）这些操作需要提交到后端，但是离线时网络不通提交不了等用户重新联网之后，需要把这些操作同步到后端这个离线数据同步的问题比较复杂处理不好会导致数据丢失，或者重复提交。

解决方案： 我们没有做复杂的离线数据同步，因为我们的系统是电商平台涉及交易数据一致性要求高离线操作的风险比较大，所以我们只做了离线浏览的功能用户离线时能查看缓存的商品信息等等，但是涉及提交数据的操作（加入购物车下单等等）离线时会提示用户"当前网络不可用请联网后重试"不允许离线提交这样避免了数据同步的复杂问题也保证了数据一致性对于大部分场景来说离线浏览已经足够了能满足用户在网络不好时查看商品的需求。

如果确实需要离线操作和数据同步可以用Background SyncAPI或者IndexDB本地存储操作队列联网后自动同步，但是这个比较复杂需要处理很多边界情况建议根据业务需求谨慎使用。

坑3：iOS Safari兼容性问题：

第三个坑是iOS Safari的兼容性问题2018年的时候iOS Safari对PWA的支持很有限不支持Service Worker（iOS 11.3之后，才开始支持，但是功能有限）不支持Web Push添加到主屏幕的体验也不好没有启动画面等等导致iOS用户的PWA体验比Android差很多。

解决方案： 我们做了降级处理iOS用户还是用原来的移动Web体验不启用Service Worker和Web Push但是还是支持基本的响应式设计和性能优化保证iOS用户也能正常使用系统只是没有PWA的增强体验，另外我们也关注iOS对PWA的支持进展等iOS支持更完善之后，再逐步给iOS用户开放PWA功能毕竟PWA是趋势苹果也在逐步支持只是进度慢一些。

坑4：性能监控和数据统计问题：

第四个坑是性能监控和数据统计问题PWA因为有Service Worker缓存和单页面应用的架构传统的页面PV统计方式不适用了，因为页面切换不刷新整个页面传统的统计代码只在首屏加载时执行一次后续页面切换不会重新执行导致PV统计不准，另外性能数据的采集也需要调整，因为PWA的加载过程和传统网页不一样。

解决方案： 我们改造了数据统计代码在前端路由切换的时候，手动触发PV统计上报确保每个页面的PV都能被统计到，另外我们用了Performance API和Service Worker的事件来采集性能数据，比如首屏加载时间资源缓存命中率等等能更准确地监控PWA的性能和用户体验通过这些数据我们能持续优化PWA的体验。

六、最终效果

经过两个多月的迁移和优化我们的PWA迁移项目终于全量上线了最终的效果非常不错数据提升很明显。

性能数据提升：

  • 首屏加载时间：从平均3.5秒降到1.2秒提升了约65%
  • 页面切换时间：从平均1.5秒降到200毫秒以内提升了约85%
  • 离线访问：支持用户在无网络时也能浏览缓存的商品内容
  • 跳出率：降低了约20%

业务数据提升：

  • 用户停留时间：增加了约30%
  • 转化率：提升了约15%
  • 用户留存：7日留存提升了约25%30日留存提升了约18%
  • 添加到主屏幕：约10%的用户把应用添加到了主屏幕这些用户的活跃度比普通用户高很多

用户反馈： 用户反馈也很好很多用户说现在网站打开速度快了很多用起来像App一样流畅离线也能看商品很方便添加到主屏幕之后，不用每次打开浏览器输入网址很方便整体用户体验提升很明显。

这些数据和反馈证明我们的PWA迁移是成功的达到了预期的目标也证明PWA确实能显著提升移动端Web的用户体验接近原生App的水平。

七、经验总结

最后总结一下这次PWA迁移的经验和教训给想做PWA迁移的团队一些建议。

经验1：渐进式迁移不要重写：

PWA迁移最好采用渐进式的方式不要一下子完全重写，因为重写风险大周期长容易失败渐进式迁移能控制风险快速验证效果逐步完善更稳妥我们这次就是采用渐进式迁移先核心页面再逐步扩展效果很好。

经验2：以用户体验和数据为核心：

PWA迁移的目标是提升用户体验，所以整个过程都要以用户体验为核心用数据驱动决策不要为了用技术而用技术要看技术是否真的提升了用户体验和业务指标用数据说话这样才能保证迁移的方向正确效果明显。

经验3：重视Service Worker的更新和缓存管理：

Service Worker是PWA的核心，但是也最容易出问题特别是缓存和更新的问题一定要重视提前设计好缓存策略和更新机制测试充分避免出现更新不及时，或者缓存错乱的问题影响用户体验推荐使用Workbox库能简化Service Worker的开发减少坑。

经验4：做好降级和兼容处理：

PWA的很多特性在不同浏览器上支持情况不一样特别是iOS Safari支持有限，所以一定要做好降级和兼容处理确保不支持PWA的浏览器用户也能正常使用系统只是没有增强体验不要，因为PWA迁移影响了部分用户的基本使用渐进式增强的思想很重要。

经验5：性能优化是持续的过程：

PWA迁移完成不是结束性能优化是一个持续的过程上线之后，要持续监控性能数据和用户体验发现问题及时优化不断提升用户体验不要以为迁移完成就一劳永逸了技术在发展用户需求也在变化需要持续优化和迭代。

八、写在最后

以上就是我们这次PWA迁移的实战经验分享包括为什么要做PWA迁移PWA的核心概念迁移的整体思路具体实施步骤遇到的坑和解决方案最终效果以及，经验总结希望能给想做PWA迁移的团队一些参考和启发。

PWA是Web发展的趋势它能让Web应用具有接近原生App的体验，同时保持Web的优势（不用下载随时访问更新快跨平台）随着浏览器对PWA的支持越来越完善PWA会越来越普及成为移动端Web开发的标准模式建议大家关注和学习PWA技术提升自己的技术能力也为未来的Web开发做好准备。

当然PWA也不是银弹不是所有系统都适合迁移到PWA要根据自己的业务需求用户场景技术栈等等因素综合考虑判断是，否适合做PWA迁移不要盲目跟风适合自己的才是最好的。

最后用一句话结束这篇文章："PWA不是终点而是Web体验升级的起点渐进式增强数据驱动持续优化就能让Web应用体验越来越好接近甚至超越原生App。"

愿大家都能用好PWA技术打造体验优秀的Web应用给用户带来更好的体验。