回到主页

模糊CDN和CMS之间的界限

Cloudflare最近宣布他们将推出一项名为“Cloudflare Workers”的新功能。它为任何使用Cloudflare作为CDN的人提供了编写任意JavaScript(基于标准Service Worker API)的能力,该JavaScript 在Cloudflare的边缘节点上运行。

用简单的英语,您将能够编写代码,通过Cloudflare CDN更改页面的内容,标题,外观,感觉和行为。您可以在不对服务器进行开发更改的情况下执行此操作,而无需集成到现有站点逻辑中。

如果您熟悉JavaScript,则只需登录Cloudflare,然后开始编写在服务器输出之上运行的逻辑。

为什么这有用?
作为SEO,我们经常处理需要技术改进或变更的站点。但是开发队列通常很慢,资源受限,网站平台也很复杂。改变或添加内容很难。

我们中的许多人已经习惯使用谷歌标签管理器等变通方法来实施搜索引擎优化变更 - 比如修复破坏的规范网址标签,或者向页面添加机器人指令 - 并希望谷歌尊重或理解我们混合时发送的冲突信号 -页面和基于JavaScript的规则。

但是,尽管Google声称能够抓取,索引和理解JavaScript内容和网站,但所有研究都 表明他们在纠正错误的过程中经常出错。

Cloudflare的声明非常重要,因为与标签管理平台不同,在将页面发送给用户之前,更改是在服务器端进行的 - Google只查看最终的,更改的代码和内容。浏览器中没有混乱的JavaScript,没有隐藏真实内容,也没有冲突的逻辑。

服务工作者在边缘
与其他CDN一样,Cloudflare在世界各地都有服务器。当用户在您的网站上请求URL时,他们会自动路由到最近的地理“边缘节点”,以便用户通过快速的本地连接访问该站点。这是非常标准的东西。

然而,新的是,您现在可以编写在这些边缘节点上运行的代码,从而可以根据页面的位置或使用您需要指定的任何逻辑对页面呈现给最终用户的方式进行细粒度控制。

通过完全控制CDN的响应,可以编写更改标题标签,更改规范URL,重定向用户,更改HTTP标头或添加全新功能的脚本; 您可以调整,更改,删除,构建或构建从服务器返回的内容中的任何内容。

值得注意的是,像AWS这样的其他平台已经在2017年7月推出了类似的东西。在边缘进行更改的概念并不是全新的,但AWS使用了不同的方法和技术堆栈。

具体而言,AWS要求用户在Node.js(一个通用的服务器端JavaScript框架)中编写函数,使用特定的专有方法来处理请求/响应。这带来了一些优点(比如能够使用一些Node.js库),但会将您锁定为一种非常具体的方法。

Cloudflare的解决方案基于Service Worker API(而不是Node.js),这可能看起来更像是面向未来的方法。

服务工作者是渐进式网络应用程序(PWA)的当前选择框架,管理结构化标记,以及随着谷歌(以及更广泛的网络)从支持传统网站转向拥抱更多类似应用程序的体验而使用新/新兴格式。这使得它成为学习,使用和潜在回收生态系统中其他地方的现有代码和解决方案的良好技能。

PWA看起来很可能是下一个(可能是当前的)重要的事情意味着服务工作者不会很快到达任何地方,但Node.js可能只是本月的当前风格。

亲自动手
Cloudflare 为您提供了一个沙箱,用于测试和可视化任何网站上的更改,但不清楚这是否是其启动营销的一部分,或者是长期存在的东西(或编辑器/部署系统本身的组件)。

这是很有用的,我很想探索它在实践中的样子。

我花了几分钟修改其公告页面上的一个脚本,在Distilled的主页上添加了“awesome”这个词(以令人愉悦的橙色)。你可以在这里查看代码。

虽然这是非常强大的,但它没有风险和弊端。首先,您需要具备一些敏锐的JavaScript技能来编写任何规则,并且您将不得不在没有任何外部支持框架库(如jQuery)的情况下执行此操作。

服务工作者也可能很复杂。例如,您的所有更改都是异步的; 它们同时并行运行。这使得事情快速闪电,但这意味着某些依赖于特定排序或依赖性的复杂逻辑可能难以编写和维护。

所有这些,还没有很好的WYSIWYG界面,指南或教程(除了StackOverflow上的一般JS或服务工作者问题)。你会坐在你的裤子旁边,花费大部分时间试图找出你的代码不起作用的原因。如果您需要向开发人员寻求帮助,那么您将回到我们最初的问题 - 他们很忙,他们有其他优先事项,而且您正在为资源而战。

元CMS不是玩具
随着我们越来越多地发现自己转向长期开发周期的解决方案,“无法修复”的问题以及解决技术挑战,我们很有可能将Google Tag Manager和Cloudflare Workers等解决方案视为可行的解决方案。

如果我们无法修复问题,我们可以使用临时解决方案对其进行修补,我们可以部署“更高的堆栈”(CMS之前的级别'),并且可能重新优先考虑并重新审视实际问题以后的日子。

您可以修复损坏的重定向。您可以迁移到HTTPS和HTTP / 2。您可以处理开发团队永远无法获得的所有那些次要模板错误。

但是,随着这种工作方式成为习惯,我们正在使用的解决方案(无论是Google跟踪代码管理器,Cloudflare还是我们自己的ODN)都具有“Meta CMS”的特征,这并不罕见; 系统越来越多地覆盖我们的模板,内容和页面逻辑,并使用类似CMS的逻辑来确定最终用户看到的内容。

随着时间的推移,我们建立了越来越多的规则和替代品,直到我们发现我们的网站和我们在每个平台上管理的内容之间的线条模糊不清。

这会产生一系列风险和挑战,例如:
底层代码更改或规则冲突时会发生什么?
如果您正在使用标记管理器或CDN在HTML代码和页面的“顶部”进行更改,那么当开发人员更改底层网站逻辑时会发生什么?

通常情况下,您定义的用于对更改进行分层的规则会导致潜在的灾难性后果。当你有多个规则与冲突的指令时,你如何管理哪些获胜?

你怎么知道什么做的?
在原始JavaScript中编写规则并不能让您轻松阅读,一目了然地了解正在改变的内容。

当您拥有大量规则或特别复杂的脚本时,您将需要一个日志记录或文档处理来提供有关所有移动部件如何工作和交互的人性化概述。

谁记录了什么在哪里?
如果出现冲突,或者您想要更新或进行新的更改,则需要在现有系统之上进行编辑或构建。但是,您如何知道哪些系统 - 您的CMS或您的元CMS - 正在控制您要修改的模板,内容和页面的哪些位?

你在多个地方都有规则和逻辑,这是令人头疼的问题。

当首席执行官问为什么他正在看的页面被打破时,你如何开始找出原因出错的原因和地点?

你如何进行质量保证和测试?
除非您的系统提供了一种简单的方法来预览更改,并允许您为QA,浏览器测试等类似的目的公开测试URL,否则您将拥有一个功能强大且质量控制很少的系统。目前,它看起来并不像Cloudflare支持这一点。

您如何管理访问和版本控制?
随着规则的变化,随着时间的推移而发展和分层,您需要一种管理版本控制,更改日志记录和访问/权限的方法。目前还不清楚Cloudflare目前是否会攻击这个问题,但其生态系统的其余部分通常缺乏这方面的能力。

你如何防止意外暴露/缓存/ PII等?
当您完全访问流入或流出服务器的每个数据时,您可以非常轻松地执行您可能不应该做的事情 - 甚至是偶然的。不小心存储,保存或公开私人用户信息,信用卡交易详情和其他敏感内容并不需要太多。

强大的力量带来了巨大的责任,只是写一些javascript可能会产生意想不到的后果。

一般来说,过分依赖您的CDN作为元CMS感觉就像一个冒险的解决方案。这对于解决问题很有帮助,但这会导致操作和组织问题。

但这并不是说它不是一个有用的工具。如果您已经使用Cloudflare,并且您遇到了复杂的挑战,您可以使用Cloudflare Workers作为一次性解决方案来解决,那么这是绕过问题并轻松获胜的好方法。

或者,如果您需要执行地理位置特定的内容,缓存或重定向逻辑(在最近的本地边缘节点与用户),那么这是一个非常好的工具 - 肯定有地理位置/法律限制内容的用例,这是完美的工具。

否则,尝试解决问题几乎总是会成为更好的解决方案。即使你的开发人员很慢,你最好还是从他们的源头解决潜在的问题,而不是修补顶层的(可能不稳定的)修复层。

有时,Cloudflare Workers将是一个优雅的解决方案 - 通常情况下,你应该尝试以老式的方式解决问题。

ODN作为元CMS
除此之外,规则可能有例外。

如果你可以拥有元CMS的所有优点,但有一些条款可以避免我发现的所有陷阱 - 访问和版本控制,直观的界面,安全的测试过程和文档 - 你可以解决所有的技术SEO一夜之间的挑战,他们会保持解决。

虽然我想强调我不是销售人员,但我们有一个解决方案。

我们的“ 优化交付网络 ”产品(简称蒸馏ODN)完成了所有这些工作,没有我们探索过的任何缺点。

我们构建并推广我们的平台作为SEO 分裂测试解决方案(并且它是衡量页面SEO变化大规模有效性的独特方式),但更有趣的是,它本质上是一个成熟的元CMS。

它的工作原理是对页面进行结构化更改,在对服务器的请求和将页面传递回用户之间。它可以执行Google跟踪代码管理器或Cloudflare可以对您的网页,标题,内容和响应行为执行的所有操作。

它具有友好的用户界面。它是企业级的,可扩展,安全,并且可以解决我们探索过的所有其他挑战。

我们的客户依靠ODN进行A / B测试他们的自然搜索流量和页面,但其中许多也使用该平台来修复内容。他们的营销团队可以登录,定义规则和条件,并解决开发团队通常需要几个月(有时是几年)才能解决的问题。

因此,虽然ODN仍然不是一个完美的解决方案 - 如果你需要一个元CMS,那么上游已经出现了问题 - 它至少是一种可行,成熟和复杂的方式绕过笨重的开发过程并提供快速,战术的胜利。

我预计未来一年左右我们会看到元CMS市场的更多变动,特别是因为现在这个领域有多个参与者(包括亚马逊!); 但他们的产品有多可行 - 如果他们没有可用的界面并解释组织/运营挑战 - 还有待观察。

所有文章
×

还剩一步!

确认邮件已发至你的邮箱。 请点击邮件中的确认链接,完成订阅。

好的