SEO和渐进式Web应用程序：展望未来

SEO的从业者一直不信任JavaScript。

部分原因是基于经验；搜索引擎发现、抓取和准确索引内容的能力一直以来都非常依赖JavaScript。但这也是一种习惯，源于对所有形式的JavaScript的普遍警惕，这种警惕不是基于理解或经验。这表现为对传统搜索引擎优化技术的依赖，而这些技术已经不相关很多年了，并且坚信擅长技术搜索引擎优化并不需要了解现代web开发。

搜索引擎优化作为一个营销领域的技术知识差距不断扩大，使许多搜索引擎优化难以解决我们的新问题，它们还使搜索引擎优化从业者面临被甩在后面的风险，因为我们中的太多人拒绝探索——更不用说接受——诸如Progressive Web Apps（PWA）、现代JavaScript框架和其他日益被视为网络未来的技术。

在本文中，我将重新审视PWA。除了探索对搜索引擎优化和可用性的影响外，我将展示一些您可能从未听说过的现代框架和构建工具，并提出如果我们要将自己置于网络技术前沿，我们需要适应的方法。

1.总结：PWA、SPA和Service Workers

渐进式Web应用程序本质上是提供类似于原生应用程序的用户体验的网站。推送通知等功能可以轻松地重新吸引受众，而用户可以将他们最喜欢的网站添加到主屏幕上，而无需像应用程序商店那样的复杂功能。PWA可以在离线或低质量网络上运行，它们允许在移动设备上获得顶级的全屏体验，这更接近原生iOS和Android应用程序提供的体验。

最重要的是，PWAs做到了这一点，同时保留了——甚至增强了——网络的基本开放性和可访问性。顾名思义，它们是_渐进_的和_响应灵敏的_，旨在为每个用户运行，无论他们选择的浏览器或设备如何。它们也可以自动保持最新状态，并且——正如我们将看到的——像传统网站一样是_可发现_和_链接的_。最后，这不是全部：现有网站可以部署这些技术的有限子集（使用简单的service worker），并立即开始收获收益。 该规范仍然相当年轻，自然有一些领域需要工作，但这并不能阻止它们成为十年来网络能力的最大进步之一。PWA的采用正在迅速增长，组织正在发现它们可以影响的无数现实世界的商业目标。

您可以在谷歌Developers上阅读更多关于PWA的功能和要求的信息，但使PWA成为可能的两个关键技术是：

• App Shell架构：通常使用JavaScript框架(如React或Angular)来实现，这指的是一种构建单页面应用(spa)的方法，它将逻辑与实际内容分离开来。可以把应用程序外壳看作应用程序运行所需的最小HTML、CSS和JS;一个可以缓存的UI框架。
• Service Workers：浏览器在后台运行的特殊脚本，独立于页面。它本质上充当代理，以编程方式拦截和处理来自页面的网络请求。

请注意，这些技术并不相互排斥；单页应用程序模型（2010年与AngularJS一起成熟）显然比Service Workers和PWA早一段时间。正如我们将看到的，完全可以创建一个不是作为单页应用程序构建的PWA。然而，为了本文的目的，我们将专注于开发现代PWA的“典型”方法，探索选择加入使用上述两种技术的快速增长的组织团队所面临的搜索引擎优化影响和机会。

我们将从应用程序外壳架构和单页应用程序模型的渲染含义开始。

2.应用程序外壳架构

URL

简而言之，应用程序外壳架构涉及积极缓存静态资产（用户界面和功能的最小值），然后使用JavaScript动态加载实际内容。大多数现代JavaScript SPA框架都鼓励采用类似的方法，以这种方式分离逻辑和内容对速度和可用性都有利。交互感觉是即时的，就像原生应用程序上的互动一样，数据使用可能非常经济。 _归功于_[_https://developers.google.com/web/fundamentals/architecture/app-shell_](https://developers.google.com/web/fundamentals/architecture/app-shell)

正如我在介绍中提到的，严重依赖客户端JavaScript对搜索引擎优化来说是一个问题。从历史上看，其中许多问题的核心是，虽然搜索爬虫需要唯一的URL来发现和索引内容，但单页应用程序_不需要更改_应用程序或网站每种状态的_URL_（因此“单页”一词）。依赖片段标识符（不是作为HTTP请求的一部分发送的）在不重新加载页面的情况下动态操作内容是搜索引擎优化的主要头疼问题。传统解决方案涉及用所谓的散列取代散列（#!）和_escaped_fragment_参数，这是一个早已不建议使用的hack，我们今天不会讨论它。

多亏了HTML5历史API和pushState方法，我们现在有了更好的解决方案。浏览器的URL栏可以使用JavaScript进行更改，而无需重新加载页面，从而使其与应用程序或网站的状态保持同步，并允许用户有效使用浏览器的“返回”按钮。虽然此解决方案不是灵丹妙药——您的服务器必须配置为通过将应用程序加载到正确的初始状态来响应对这些深层URL的请求——但它确实为我们提供了解决SP中URL问题的工具。

SEO今天面临的更大问题实际上更容易理解：渲染内容，即_何时__以及如何_完成。

渲染内容

请注意，当我在这里提到渲染时，我指的是构建HTML的过程。我们专注于实际_内容_如何进入浏览器，而不是向屏幕绘制像素的过程。

在网络的早期，这方面的事情就更简单了。服务器通常会返回渲染页面所需的所有HTML。然而，如今，许多使用单页应用程序框架的网站仅从服务器提供最低限度的HTML，并将繁重的工作委托给客户端（无论是用户还是机器人）。鉴于网络的规模，这需要_大量的_时间和计算资源，正如谷歌在2018年的I/O会议上明确指出的那样，这对搜索引擎提出了一个重大问题：

“在谷歌搜索中呈现JavaScript驱动的网站将推迟到谷歌机器人拥有处理该内容的资源后。”

在较大的站点上，第二波索引有时会延迟几天。除此之外，您可能会遇到大量问题，因为规范标签和元数据等关键信息被完全丢失。我强烈建议观看谷歌关于这一主题的精彩演讲的视频，以了解现代搜索爬虫面临的一些挑战。

谷歌是为数不多的渲染JavaScript的搜索引擎之一。此外，它使用网络渲染服务来做到这一点，直到最近，该服务还基于Chrome 41（2015年发布）。显然，这不仅具有单页应用程序的影响，JavaScript SEO更广泛的主题目前是一个迷人的领域。

为了本文的目的，这里的关键要点是，在2019年，您不能依赖搜索引擎来准确抓取和渲染依赖JavaScript的Web应用程序。如果您的内容呈现在客户端，谷歌爬行将是资源密集型的，您的网站在搜索中将表现不佳。无论您听到什么相反的话，如果自然搜索是您网站的宝贵渠道，您需要为服务器端渲染做出准备。

但服务器端渲染是一个经常被误解的概念......

“实施服务器端渲染”

这是一个常见的搜索引擎优化审计建议，我经常听到它像是一个自成一体、易于操作的解决方案一样。充其量，这是对一项巨大技术事业的过度简化，最糟糕的是，这是对相关网站可能/必要/有益的误解。服务器端渲染是许多可能设置_的结果_，可以通过许多不同的方式实现；然而，最终，我们关心的是让服务器返回静态HTML。

那么，我们有什么选择？让我们稍微分析一下服务器端渲染内容的概念，并探索我们的选项。以下是谷歌在上述I/O会议上概述的高级别方法：

• 动态渲染——在这里，普通浏览器获得“标准”Web应用程序，该应用程序需要客户端渲染，而机器人（如谷歌机器人和社交媒体服务）则提供静态快照。这涉及在服务器基础设施中添加额外的步骤，即获取Web应用程序、呈现内容，然后根据机器人的用户代理（即UA嗅探）。从历史上看，这是通过PhantomJS这样的服务完成的（现在已弃用，不再开发），而今天Puppeteer（无头Chrome）可以执行类似的功能。主要优势是，它通常可以连接到您现有的基础设施中。

• 混合渲染——这是谷歌的长期推荐，绝对是更新网站构建的方式。简而言之，每个人——机器人和人类——都会将初始视图作为完全渲染的静态HTML使用。Crawlers可以继续以这种方式请求URL，每次都会获得静态内容，而在普通浏览器上，JavaScript在初始页面加载后接管。从理论上讲，这是一个很好的解决方案，_在_速度和可用性方面也有很多其他优势；稍后会有更多相关报道

后者更简洁，不涉及UA嗅探，是谷歌的长期推荐。还需要澄清的是，“混合渲染”不是一个单一的解决方案——它是许多可能的方法的结果，使静态预渲染内容在服务器端可用。让我们来分析一下实现这种结果的几种方式。

同构/通用应用程序

这是您可能实现“混合渲染”设置的一种方式。同构应用程序使用在服务器和客户端上同时运行的JavaScript。由于Node.js的出现，Node.js除其他外，它允许开发人员编写可以在后端和浏览器中运行代码。

通常，您将把框架（React、Angular Universal等）配置为在节点服务器上运行，在将部分或全部HTML发送到客户端之前对其进行预渲染。因此，您的服务器必须配置为通过为适当的页面渲染HTML来响应深层URL。在普通浏览器中，这是客户端应用程序无缝接管的点。服务器为初始视图提供的静态HTML由浏览器“补水”（绝妙的术语），将其重新转换为单个页面应用程序，并使用JavaScript执行后续导航事件。

如果做得好，这个设置可能很棒，因为它提供了客户端渲染的可用性优势、服务器端渲染的SEO优势和快速的首次油漆（即使随着JS的启动，Time to Interactive经常受到补水的负面影响）。出于对任务过于简化的担忧，我不会在这里进行太多细节，但关键是，虽然同构JavaScript/真正的服务器端渲染可能是一个强大的解决方案，但设置起来往往非常复杂。

那么，还有什么其他选择？如果您无法证明完全同构设置的时间或费用是合理的，或者它只是对您试图实现的目标来说太过分了，您是否还有其他方法可以在不破坏搜索引擎优化的情况下收获单页应用程序模型和混合渲染设置的好处？

预渲染（Prerendering）/JAMstack

在服务器端渲染可用内容并不一定意味着_渲染过程本身_需要在服务器上发生。我们需要的只是渲染的HTML就在那里，准备好为客户端服务；渲染过程本身可以在您喜欢的任何地方发生。使用JAMstack方法，将内容渲染为HTML是构建过程的一部分。

我作为快速入门，该术语代表_JavaScript、API_和_标记_，它描述了一种在没有服务器端软件的情况下构建复杂网站的方法。从前端组件部件组装站点的过程——传统站点可能使用WordPress和PHP完成的任务——作为构建过程的一部分执行，而交互性则使用JavaScript和API在客户端处理。 可以这样想：所有内容都位于_Git存储库中。内容存储为纯文本标记文件（可通过无头CMS或其他基于API的解决方案编辑），页面模板和汇编逻辑以Go、JavaScript、Ruby或您首选网站生成器碰巧使用的任何语言编写。在托管到任何地方_之前，您的网站可以在任何计算机上使用适当的命令行工具集构建到静态HTML中。由此产生的一组易于缓存的静态文件通常可以安全地托管在CDN上，几乎不需要任何东西。

老实说，我认为静态网站生成器——或者说是支撑它们的原则和技术——才是未来的趋势。关于这点，我很有可能是错的，但对于那些使用现代基于npm的自动化软件(如Gulp或Webpack)来编写CSS或JavaScript的人来说，这种方法的强大和灵活性应该是显而易见的。我希望任何人在一个真实的项目中测试专业网络主机Netlify提供的深度Git集成，但仍然认为JAMstack方法是一种时尚。

JAMstack设置对我们讨论单页应用程序和预渲染的意义应该相当明显。如果我们的静态站点生成器可以根据用Liquid或Handlebars编写的模板组装HTML，为什么它不能使用JavaScript做同样的的事情呢？

有新一代的静态站点发生器就是这样做的。这些程序通常由React或Vue.js提供支持，允许开发人员使用尖端的JavaScript框架构建网站，并可以轻松配置为为每个页面输出SEO友好的静态HTML（或“路由”）。每个HTML文件都是_完全呈现的内容_，可供人类和机器人使用，并作为完整客户端应用程序（即单页应用程序）的切入点。这是谷歌所谓的“混合渲染”的完美执行，尽管预渲染过程的精确性使其有别于同构设置。

一个很好的例子是GatsbyJS，它内置在React和GraphQL中。我不会太详细，但我鼓励每个读过这篇文章的人查看他们的主页和出色的文档。这是一个支持良好的工具，具有合理的学习曲线，活跃的社区，基于插件的可扩展架构，与许多CMS的丰富集成，并允许开发人员在不破坏SEO的情况下使用React等现代框架。还有基于VueJS的Gridsome和React Static——你猜对了——使用React。

企业级对这些平台的采用似乎即将增长；GatsbyJS被耐克用于他们的Just Do It活动，Airbnb用于他们的工程网站airbnb.io，Braun甚至将其用于为主要电子商务网站提供动力。最后，我们在SEOmonitor的朋友用它来支持他们的新网站。

但目前单页应用程序和JavaScript渲染已经足够了。是时候探索支撑PWA的两种关键技术中的第二种了。_答应_你将一直陪着我到最后（哈哈，书呆子笑话），因为是时候探索Service Workers了。

3.Service Workers

首先，我应该澄清，我们正在探索的两项技术——SPA和Service Workers——并不相互排斥。是的，它们共同支撑着我们通常所说的渐进式Web应用程序，但也有可能有一个不是SPA的PWA。您还可以将Service Workers集成到传统的静态网站（即没有任何客户端渲染内容的网站）中，我相信在不久的将来，我们将看到这种情况会发生更多。最后，Service Workers与Web App Manifest等其他技术一起运营。

然而，归根结底，是Service Workers使PWA最令人兴奋的功能成为可能。它们是网络平台历史上最重要的变化之一，每个工作涉及构建、维护或审计网站的人_都需要_了解这套强大的新技术。如果您像我一样，过去几年来一直热切地查看Jake Archibald的“Service Workers就绪”页面，并随着浏览器供应商的采用量的增加，您就会知道现在是时候开始与Service Workers一起构建了。 我们将探索它们是什么，它们可以做什么，如何实现它们，以及对搜索引擎优化有什么影响。

Service Workers可以做什么？

Service Workers是一种特殊的JavaScript文件，在主浏览器线程之外运行。它位于浏览器和网络之间，其功能包括：

• 拦截网络请求，并决定如何以编程方式处理它们。工作人员可能会像往常一样去网络，或者它可能只依赖缓存。它甚至可以从各种来源_捏造全新的反应_。这包括构建HTML。
• 在Service Workers安装期间预加载文件。对于SPA，这通常包括我们之前讨论的“应用程序外壳”，而简单的静态网站可能会选择_预加载所有HTML、CSS和JavaScript_，以确保离线时基本功能得到维护。
• 处理推送通知，类似于本机应用程序。这意味着网站可以获得用户的许可来发送通知，然后依靠Service Workers接收消息并执行消息_，即使浏览器关闭_。
• 执行后台同步，将网络操作推迟到连接改善后。这可能是网络邮件服务或照片上传设施的“开箱”。不再有“请求失败，请稍后再试”——Service Workers将在适当的时候为您处理。

这类功能的好处不仅仅是明显的可用性特权。除了推动在网络上采用HTTPS（所有主要浏览器只会在安全协议上注册Service Workers外），Service Workers在速度和性能方面也具有变革性。它们支持谷歌的PRPL模式等新方法和想法，因为我们可以最大限度地提高缓存效率，并最大限度地减少对网络的依赖。这样，Service Workers将在让未来十亿网络用户快速访问网络方面发挥关键作用。

所以，是的，他们是绝对强大的。

实施Service Workers

与其在这里写一篇糟糕的基本教程，不如链接到一些关键资源。毕竟，你最有资格知道你对Service Workers的理解有多深。

MDN文档是进一步了解Service Workers及其能力的好地方。如果您已经对Web开发的基础知识有信心，并享受_边干边学_的方法，我强烈建议您完成谷歌的PWA培训课程。它包括一个关于Service Workers的整个实践练习，这是熟悉基础知识的好方法。如果ES6和承诺还不是JavaScript曲目的一部分，请准备一场火的洗礼。 要理解的关键是——一旦你开始尝试，你很快就会意识到——服务工作者将难以置信的控制权交给了开发人员。与以前解决连接性难题的尝试（如命运多舛的AppCache）不同，Service Workers不会在您的工作中强制实施任何特定模式；它们是一套工具，供您编写自己的解决方案来解决您面临的问题。

其后果之一是它们可能非常复杂。注册和安装Service Workers不是一个简单的练习，任何试图通过从StackExchange复制粘贴将Service Workers拼凑在一起的尝试都注定要失败（说真的，不要这样做）。您的网站没有现成的Service Workers——如果您想编写合适的worker，您需要了解网站的基础设施、架构和使用模式。曾经是网络开发专家的Ben叔叔说得最好：权力越大，责任越大。

最后一件事：你可能会惊讶于你访问的网站有多少已经在使用Service Workers。前往Chrome中的chrome://serviceworker-internals/或Firefox中的about

#workers查看列表。

Service Workers和搜索引擎优化

就搜索引擎优化的影响而言，Service Workers最相关的可能是他们使用Fetch API劫持请求和修改或伪造响应的能力。您在“查看源”甚至“网络”选项卡中看到的不一定表示从服务器返回的内容。它可能是一个缓存响应或由Service Workers从各种不同来源构建的东西。 _来源：_[_https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API_](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)

以下是一个实际例子：

• 前往GatsbyJS主页
• 点击“文档”页面的链接。
• 右键单击-查看来源

没有内容，对吗？只是一些内联脚本和样式以及空的HTML元素——React内置的经典客户端JavaScript应用程序。即使您打开“网络”选项卡并刷新页面，“预览”和“响应”选项卡也会讲述相同的故事。实际内容仅显示在元素检查器中，因为DOM正在使用JavaScript组装。

现在为同一URL（[https://www.gatsbyjs.org/docs/](https://www.gatsbyjs.org/docs/)）运行curl请求，或使用Screaming Frog获取页面。所有内容都在那里，以及适当的标题标签、口号以及您可能期望从页面渲染服务器端获得的所有内容。这也是像Googlebot这样的爬虫会看到的。

这是因为网站使用混合渲染，安装在浏览器中的Service Workers正在处理后续导航事件。它不需要从服务器获取文档页面的原始HTML，因为客户端应用程序已经在启动和运行——因此，View Source向您显示Service Workers返回了应用程序的内容，而不是网络返回的内容。此外，由于Service Workers有效地使用了缓存，这些页面可以在您离线时重新加载。

您可以使用“网络”选项卡轻松识别哪些回复来自Service Workers——请注意下面的“来自ServiceWorker”行。 在“应用程序”选项卡上，您可以看到在当前页面上运行的Service Workers及其创建的各种缓存。您可以禁用或绕过worker，并测试它可能正在使用的任何更高级的功能。学习如何使用这些工具是一项非常有价值的练习；我不会在这里详细介绍，但我建议学习谷歌关于调试Service Workers的Web基础知识教程。 在这篇文章中，我有意识地努力将代码片段保持在最低限度。我举了一个例子，说明了一个简单的Service Workers如何使用Fetch API处理请求，以及我们获得的控制程度： 结果： 我希望这个（非常简化和非生产就绪）的例子能说明一个关键点，即我们对如何处理资源请求拥有极其精细的控制。在上面的示例中，我们选择了简单的_尝试缓存优先、回退到网络、回退到自定义页面_模式，但可能性是无穷无尽的。开发者可以根据主机名、目录、文件类型、请求方法、缓存新鲜度和加载等自由规定如何处理请求。响应——包括整个页面——可以由Service Workers伪造。Jake Archibald在他的Offline Cookbook中探索了一些常见的方法和途径。

现在是时候了解Service Workers的能力了。现代技术搜索引擎优化所需的技能集与Web开发人员的技能集有相当程度的重叠，今天，深入了解所有主要浏览器中的开发工具——包括Service Workers调试——应被视为先决条件。

4.总结

SEO需要适应

直到最近，如果不理解PWAs和Service Worker带来的后果和机会，人们很容易避免处罚。

这些都是与搜索营销相关的尖端功能，而前面提到的许多seo人员对JavaScript的谨慎态度并没有鼓励试验。但是PWAs正在迅速成为一种规范，如果不了解它们如何运作的机制，很快就不可能有效地工作。作为一名技术搜索引擎优化(或搜索引擎优化工程师，借用Mike King的另一个术语)，你应该让自己处于这种范式转变发展的最前沿。对网站开发一无所知的技术搜索引擎优化已经过时了，我相信在搜索营销的技术和内容驱动方面进一步分化并不是一件坏事。专业!！

在得知开发团队正在为新网站构建采用新的JavaScript框架后，seo往往会报以一定程度的冷嘲热讽。我当然会开玩笑说，开发人员被最新的技术或框架所吸引，以及JavaScript开发世界似乎发展得如此之快，从外部开始，抽象和自动化层层被添加到其中——通常看起来像开发堆栈的倾斜塔。但值得花时间了解_为什么_选择框架，么时候可能开始在生产中使用技术，以及这些决定将如何影响SEO。

例如，与其批评页面应用程序框架的404处理或内部链接，不如能够提供基于了解其实际工作方式的有意义的建议。正如Jono Alderson在关于搜索引擎优化民主化的演讲中所指出的，与在特别的基础上反复解决相同的问题相比，对开源项目的贡献在传播对SEO的欣赏和认识方面更有价值。

除了搜索引擎优化

最后我想提到的一件事是：PWAs是一套非常具有变革意义的技术，其影响显然远远超出了搜索引擎优化。数字营销的其他领域也受到了直接影响，在我看来，最有趣的一个领域就是分析。

如果您的网站在离线时部分或全部功能正常，您是否调整了分析设置以考虑这一点？如果推送通知订阅是您网站的KPI，您是否将此跟踪为目标？记住Service Workers无法访问窗口对象，因此无法使用“normal”跟踪代码跟踪这些事件。相反，有必要将您的Service Workers配置为使用测量协议构建命中率，必要时对其进行排队，并将其直接发送到Google Analytics服务器。