渐进式 Web 应用程序 (PWA)是使用 Web 技术为移动和桌面设备构建的可安装应用程序(它们旨在在任何标准平台上工作)。即使在不稳定的网络条件下,PWA 也非常可靠。
最有趣的是:任何技术堆栈中构建的 Web 应用程序都可以转换为渐进式 Web 应用程序!
Progressive Web App 的优点包括:
- 类似应用程序的外观、感觉和功能(添加到主屏幕、推送通知)
- 离线可访问性
- 没有更新问题(自动更新)
- 在任何设备上轻松安装
- 搜索引擎优化
- 加载时间短
- 更好的性能
- 跨平台
- 数据使用率低
- 反应灵敏
满足渐进式 Web 应用程序可安装性的所有核心标准(包括支持离线模式)的 Web 应用程序可以从浏览器安装在设备上。
在本文中,对 PWA 中的离线检测究竟是如何工作的有一个公平的解释。
- 即使在离线模式下,应用程序也必须继续工作只是意味着,即使用户无法访问其设备的网络,屏幕上也不会出现 Google Dino runner (T-Rex Game)。即使没有网络连接,用户也可以浏览应用程序并查看内容。
- 为了使 PWA 可安装,首先要验证 Web 应用程序是否包含具有fetch事件处理程序的 Service Worker。当我们加载 Web 应用程序时,会发起一个 fetch 请求来获取索引页面,然后在浏览器上呈现它。在这里,我们有一个 Service Worker 作为 App 和 Server 之间的代理。 Service Worker只是一个在后台运行的 javascript 文件。它也被称为 PWA 的核心。它与主浏览器的线程分开运行。因此,没有与服务工作者的网页/用户交互。
- 现在,我们将启用 Web 应用程序离线加载内容而不是加载默认错误页面的能力。
- 为此,我们会将资产本地存储在缓存存储中(在检查页面后,导航到应用程序部分以查看缓存存储),以便我们可以在需要时随时访问它们,即在离线模式下。
- 有不同类型的缓存可以控制 Web 应用程序的资源和资产的存储,其中之一是浏览器缓存。
- 浏览器缓存(自动工作):它通过缓存 CSS 文件、图像等资源来加速网站,这样我们就不必在每次加载网页时下载它们。这里唯一的问题是,我们无法控制在缓存中存储什么和不存储什么!因此,最好禁用浏览器缓存。
- 我们正在使用另一个缓存,我们可以使用 Service Workers 和常规 Javascript 来控制它。我们可以控制和管理哪些资源应该存储在缓存中,以提高 Web 应用程序的性能。稍后我们可以在需要时(即离线)检索它们。
- 最初,缓存是空的。第一个 Service Worker 被加载,它请求服务器获取 Web 应用程序请求的一些核心资产。资产包括图像、CSS 样式文件、javascript 文件等。然后服务工作者返回所有这些资产并将它们也存储到缓存中,因为它们将来可能会有用!这称为预缓存。所有这些缓存资产都存储在本地。
- 如果我们失去网络连接,Service Worker 仍然会向服务器发出请求以获取资源,但它永远不会到达服务器端。现在,可以使用预缓存资产在没有网络连接的情况下获取资源。
- Service Worker 将中断这些向服务器发出的 fetch 请求(简单来说,Service Worker 告诉 fetch 请求没有可用的网络连接,因此无需再去服务器获取资源!)。 Service Worker 本身会查看预先缓存的资产并将资源返回给 Web 浏览器。
- 这使用户即使在离线模式下也可以浏览应用程序,并且也能够查看内容/资源!
注意:从 21 年 8 月开始的离线检测更新
- 这是之前遵循的验证检查(并将仅遵循到2021 年 8 月!)。如果您已经构建了任何渐进式 Web 应用程序,您现在会在通过 Lighthouse 审计(生成报告)后注意到 Chrome 89 中的警告。自 2021 年 3 月开始发出警告。
- 从 2021 年年中开始,将引入某些新检查,因为:
- Chrome 无法检查 Web 应用程序的正确离线行为,因为无法通过 Service Worker 检查 HTTP 请求的状态。
- 当我们检查 web app 的离线模式兼容性时,chrome 只检查 service worker 是否有 fetch 事件处理程序,但不仅如此。
- 应检查 fetch 事件处理程序在离线模式下是否返回有效资源并带有 HTTP 200(成功状态代码)。
- 如果您已经以正确的方式实现了离线模式,则无需再进行任何更改。
- 否则,如果您的 fetch 处理程序工作不正常,并且它没有通过 HTTP 请求返回 200 的响应状态代码,则应使用最新的要求标准更新该应用程序。