2016 年 11 月 9 日，星期三
作为网络领域最激动人心的新创想之一，渐进式 Web 应用 (PWA) 充分利用了最新技术，能够让用户同时享受移动网站和本机应用的精华。不过，要想真正达到这种效果，务必要构建可编入索引且可链接的渐进式 Web 应用。本文提供的每条建议都是现有可编入索引性方面的最佳实践，无论您要构建渐进式 Web 应用还是简单的静态网站。不过，我们整理了这些最佳实践以提供核对清单来指导您：
确保您的内容可供抓取
为什么？以前，网站总是在服务器上生成或呈现其 HTML，因为这是确保您的内容可直接链接的最简单方法。如今，Web 应用使客户端呈现这种概念大受欢迎，原因是系统会在用户浏览时动态更新网页上的内容，而无需重新加载网页。
时下最新的方法采用的是混合呈现技术：当用户直接浏览某个网址时，系统会使用服务器端呈现；而对于网页初始加载完成后的后续浏览和异步请求，系统则会使用客户端呈现。
我们的示例服务器端 PWA 展示了仅采用服务器端呈现的情况；而示例混合 PWA 则展示了结合使用这两种方式的情况。
如果您还不熟悉服务器端呈现和客户端呈现这两个术语，请查看关于以下主题的文章：客户端和服务器端呈现及通过 react 和 node.js 实现服务器端呈现。
最佳实践：
使用服务器端呈现或混合呈现，以便用户通过其网络请求的初始负载就能看到目标内容。
务必确保您的网址可单独访问：
https://www.example.com/product/25/
以上网址应以深层链接的形式指向特定资源。
如果您无法为您的渐进式 Web 应用支持服务器端呈现或混合呈现，并且您决定使用客户端呈现，我们建议您使用 Google Search Console 的“Google 抓取工具”来验证您的内容成功对我们的搜索抓取工具呈现。
请勿将访问深层链接的用户重定向回 Web 应用的首页。
此外，还应当避免向用户显示错误网页（而应提供深层链接）。
提供简洁网址
为什么？片段标识符（#user/24601/ 或 #!user/24601/）是一种让浏览器获取服务器中的新内容的有效解决方法，它采用的是 AJAX 技术，因此无需重新加载网页。这种设计称为客户端呈现。
不过，片段标识符语法不支持某些网络工具、框架和协议（如 Facebook 的开放图谱协议）。
借助 History API，我们可以更新不含片段标识符的网址，同时仍能够异步提取资源，从而避免网页重新加载，这是一种两全其美的方案。AJAX 抓取机制（包括其 #!/ 转义的片段网址）在一段时间里确实大行其道，但现在我们已不再推荐使用这种方式。
我们的示例混合 PWA 和客户端 PWA 展示了使用 History API 的情况。
最佳实践：
提供不包含片段标识符（# 或 #!）的简洁网址，例如：
https://www.example.com/product/25/
如果使用客户端呈现或混合呈现，务必要利用 History API 支持浏览器导航。
避免以下做法：
使用 #! 网址结构来创建唯一网址（不建议这样做）：
https://www.example.com/#!product/25/
这是 History API 出现之前的解决办法。它被视为一种与纯粹的 # 网址结构不同的结构。
不支持使用没有带 ! 符号的 # 网址结构：
https://www.example.com/#product/25/
这种网址结构已经是网络领域的一种概念，涉及通过深层链接指向特定网页上的内容。
指定规范网址
为什么？当多个网址（无论是否来自相同网域）指向相同的内容时，要避免编入索引的过程中出现混乱，最好的方法是将某个网页标记为规范网页，作为内容相同的其他所有网页的引荐目标。
最佳实践：
在提供同样内容的所有网页上添加以下标记：
<link rel="canonical" href="https://www.example.com/your-url/" />
如果您要支持 Accelerated Mobile Pages (AMP)，请务必正确使用其对应的 rel="amphtml" 指令。
避免以下做法：
故意使多个网址指向的内容重复，不使用 rel="canonical" link 元素。
例如，rel="canonical" link 元素可利用跟踪参数减少网址的歧义。
避免您的网页之间出现相互冲突的规范引荐。
采用适应多种设备的设计
为什么？无论用户使用哪种设备浏览您的网站，务必确保您的所有用户都能获得尽可能好的体验。
建议您的网站采用自适应设计 - 网站的字体、外边距、内边距、按钮和常规设计须能够根据屏幕分辨率和设备视口动态调整。
将小图片放大以支持桌面设备或平板电脑设备的做法会导致用户体验变得糟糕。反之，超高分辨率的图片在手机上需要很长时间才能下载完成，这可能会影响移动设备上的滚动操作性能。
详细了解 PWA 用户体验。
最佳实践：
使用 srcset 属性针对不同密度的屏幕获取不同的分辨率图片，以免下载的图片超出设备屏幕能够显示的尺寸。
无论设备大小如何，调整您的字体大小和行高以确保文字清晰可辨。以类似方式确保合理调整元素的内边距和外边距。
使用 Chrome 开发者工具的“设备模式”功能和移动设备适合性测试工具来测试各种屏幕分辨率。
确保向用户显示的内容与向 Google 显示的内容相同。如果您使用重定向或用户代理检测（又称为浏览器嗅探或动态提供内容）来针对不同设备更改网站的设计，请务必确保内容本身保持相同。
使用 Search Console 中的“Google 抓取工具”，验证 Google 提取的内容与用户看到的内容是否一致。
出于易用性方面的考虑，请避免使用固定大小的字体。
采取迭代式开发
为什么？向 Web 应用增添功能时，最安全的途径之一就是以迭代的方式进行更改。如果您每次增加一项功能，就可以观察每项更改所带来的影响。
此外，许多开发者还倾向于将渐进式 Web 应用看作一举彻底整改其移动网站的良机 - 在隔离的环境中开发新的 Web 应用，一切准备就绪后取代现有的移动网站。
在开发功能时，尝试以迭代的方式将要做的更改分为多个独立的部分。例如，如果您打算从服务器端呈现转为使用混合呈现，则可以将这项更改作为一个单独的迭代目标进行处理，而不是与其他功能结合在一起进行处理。
这两种方法各有利弊。由于过渡是一个持续的过程，因此对于实现搜索索引编制便利性而言，采用迭代开发可降低其复杂程度。不过，如果并非是全新的开发项目，迭代开发不仅可能会导致开发进程较为缓慢，还可能使得整改效果缺乏创新性。
无论是哪一种情况，最敏感的方面就是要密切注意您的规范网址和您网站的 robots.txt 配置。
最佳实践：
逐项增加新功能，以渐进的方式对您的网站进行迭代开发。
例如，如果您的网站尚不支持 HTTPS，则可从迁移到安全网站着手。
避免以下做法：
如果您已在隔离的环境中开发了渐进式 Web 应用，则应避免在不检查 rel-canonical 链接和 robots.txt 设置是否正确的情况下启动该应用。
确保您的 rel-canonical 链接指向实际网站，并且 robots.txt 配置允许抓取工具抓取您的新网站。
在您的网站发布之前，阻止抓取工具将处于开发中的网站编入索引是合情合理的；但在发布之后，请记得取消阻止抓取工具访问您的新网站。
采用渐进增强的方式
为什么？请务必尽可能先检测浏览器功能，然后再决定是否使用。对于您认为支持特定功能的浏览器，进行功能检测也好过测试浏览器。
在过去，通过测试用户使用的是哪种浏览器来决定启用或停用功能是普遍的无奈之举。不过，随着浏览器的功能不断完善，我们强烈反对再采用这种方法。
Service Worker 是一种相对新颖的技术，在追求进步的过程中避免影响兼容性，这一点非常重要；在何时使用渐进增强方面，它是一个不错的示例。
最佳实践：
在注册 Service Worker 之前，检查其 API 的可用性：
if ('serviceWorker' in navigator) {
...
对您网站的所有功能分别使用各种 API 检测方法。
请勿使用浏览器的用户代理启用或停用 Web 应用中的功能。请务必检查功能的 API 是否可用，如果不可用，则优雅降级。
在未针对多种浏览器进行测试的情况下，请勿更新或发布您的网站！查看有关您网站的分析数据，了解哪些浏览器在您的用户群中最受欢迎。
使用 Search Console 进行测试
为什么？了解 Google 搜索如何查看您网站的内容非常重要。您可以使用 Search Console 来抓取您网站中的个别网址，然后利用“抓取 > Google 抓取工具”功能了解 Google 搜索如何查看这些网址。如果该选项处于选中状态，Search Console 会处理您的 JavaScript 并呈现网页；否则，网页上会仅显示原始 HTML 响应。
此外，Google Search Console 还会通过多种方式分析您网页上的内容，包括检测是否存在结构化数据、复合信息卡、站内链接和 Accelerated Mobile Pages。
最佳实践：
使用 Search Console 监控您的网站并探索其功能（包括“Google 抓取工具”）。
通过 Search Console 中的抓取 > 站点地图提供站点地图。这样做可有效确保 Google 搜索发现您网站的所有网页。
使用 Schema.org 结构化数据添加注解
为什么？Schema.org 结构化数据是一种灵活的词汇，用于将您网页上最重要的部分汇总为计算机可处理的数据。这可以是简单地将某个网页泛泛地描述为 NewsArticle，也可以是尽可能详细地说明某个巡演乐队的演出地点、乐队名称、场馆和票务供应商，还可以是总结某个食谱的配料和做法。
此类元数据不一定适用于您的 Web 应用中的每个网页，因此建议您酌情使用。Google 会在网页呈现后提取该数据。
此类元数据具有多种类型，包括 NewsArticle、Recipe 和 Product 等。您还可以在此处探索所有受支持的数据类型。
避免使用与您网页的实际内容不符的数据类型。例如，请勿对您所出售的 T 恤使用 Recipe，而要使用 Product。
使用开放图谱与 Twitter 卡片添加注解
为什么？除了 Schema.org 元数据之外，增加对 Facebook 开放图谱协议和 Twitter 复合信息卡的支持也会有所助益。
当有用户在这些社交网络上分享您的内容时，这样的元数据格式有助于提升用户体验。
如果您的现有网站或 Web 应用要利用这些格式，请务必也在您的渐进式 Web 应用中添加这些格式，以实现最理想的病毒式营销。
如果您的现有网站支持这些格式，请记得添加这些格式。
针对多种浏览器进行测试
为什么？从用户角度而言，确保网站行为在所有浏览器之间保持一致的重要性是毋庸置疑的。虽然用户体验可能会根据不同的屏幕尺寸有所变化，但我们都希望移动网站在大小相近的设备（无论是 iPhone 还是 Android 手机）上具有相同的行为。
由于世界各地的用户使用的浏览器种类繁多，因此网络信息获取看似杂乱无序，但正是这种多样性和竞争局面促使网络平台不断创新。值得庆幸的是，如今的网络标准日趋成熟，开发者可以利用新型工具信心十足地构建内容丰富且与各种浏览器兼容的网站。
最佳实践：
使用 BrowserStack.com、Browserling.com 或 BrowserShots.org 等跨浏览器测试工具确保您的 PWA 与各种浏览器兼容。
衡量网页加载性能
为什么？网站加载的速度越快，用户体验就越好。 针对网页速度进行优化已经成为网络开发领域众所周知的重点，但有时在开发网站的新版本时，开发者却没有优先进行必要的优化。
当开发渐进式 Web 应用时，我们建议您先衡量网页加载性能（速度）并进行优化，然后再发布网站，以获得最佳结果。
最佳实践：
使用 PageSpeed Insights 和 Web Page Test 等工具衡量您网站的网页加载性能。虽然 Googlebot 在呈现过程中比较耐心，但研究结果显示，如果网页的加载时间超过 3 秒，40% 的用户会选择离开。
您可详细了解我们的网页性能建议以及点击此处了解关键呈现路径。
避免将优化放到发布之后进行。如果您的网站在迁移到全新渐进式 Web 应用之前可以快速加载内容，那么千万不要在优化方面出现退步的情况。
我们希望上述必读指南对您有所帮助，并能够正确指导您开发方便编入索引的渐进式 Web 应用。
当您着手开始开发工作时，请务必参阅我们提供的有关索引编制便利性方面的示例渐进式 Web 应用，这些示例展示了客户端呈现、服务器端呈现和混合呈现。和往常一样，如果您有任何问题，请访问网站站长论坛与我们联系。