前言

这段时间接手了一个小项目，负责前端的页面。页面加载速度异常的慢，使用工具一分析，发现一个叫TTFB的参数，所占用的时间最长。于是各种搜索页面想优化它。于是发现了一篇博文。
原文地址：CDNs Won’t Improve Your SEO(unless…)
本文就是该篇文章的大致翻译，建议读原文。

翻译

如果一直在SEO博客圈咆哮，你可能已经注意到关于测试 impact of pagespeed metrics(规则) on SEO performance的研究，这篇研究的作者是Zoompf’s CEO Mark Isham，首次发表在MOZ社区。他的目的是，通过分析影响SEO性能的具体因素来阐明google关于“网页速度”的定义。

为了完成他们的目标，研究者观察了100,000份网页和2,000次搜索查询，调研google rankings和超过40多种相关的性能规则之间的关系。他们最终得到的结果出乎意料。数据显示前端规则对google引擎的索引结果没有直接的影响。

实际上，唯一的性能因子貌似是网页的Time to First Byte(TTFB).

“The back-end performance of a website directly impacts search engine ranking… Website owners should explore ways to improve their TTFB”.

TTFB的好处并不是第一次提及，在此篇报告之前，TTFB的价值已经被多位行业的专家提出，其中包括Ilya Grigorik，谷歌的“Make the Web Fast ”团队提倡者，写到：

“It’s not only the time that matters, but also what’s in those first few bytes Of course it doesn’t matter if you flush your ‘200 OK’ after 1ms vs 1s…. But if you know what you’re doing and craft the response right, then it can make a huge difference”.

那么这一切对于CDN用户意味着什么呢？Mark Isham’s 研究结论中这样建议的：

“Website owners should explore ways to improve their TTFB. This includes using CDNs…”

不幸的是这不是一个正确的答案，至少不是一个完整的答案。事实上，10分之9的CDNs会导致延迟，这不是一个可以推广解决的方案。为了搞明白为什么上面的方案不能推广，如果真要做CDNs优化的话，如何利用它来提高你的TTFB，我想和你介绍导致TTFB延迟的最主要的原因——动态HTML处理的时间。

动态HTML如何影响TTFB

简而言之，TTFB是作为客户端接收服务器响应首字节的时间。所以，为了弄清楚什么影响服务器的响应，我们可能需要知道，我的服务器首先会发送什么资源给客户端呢？

很显然响应头是第一个发送的。然而，正如Ilya所说，接收响应头对于涉及浏览器解析的部分没有任何意义——这只是一个统计数据。（就像是炫耀自己有多少货一样，具体的不知道是什么）

再向后看，第一个有意义的响应经常是网页HTML的内容部分，它的渲染时间由以下两部分组成：

• Processing(Waiting)time 在web服务器上生成动态HTML所产生的时间
• Network(Receiving)time 编译的HTML到达浏览器的时间
  
  HTML的Network time不是顺序的，因为他们通常是一些比较轻量级的资源。然而，HTML的Processing time动态生成网页的时间却是尤其的长——它显著的影响着TTFB以及整体的性能。

如下图的统计数据（来自一个内部统计），我们在CSD上采样了1亿次请求。我们可以明显看到，HTML资源的平均加载时间是图片加载时间的10倍，是js文件加载的4倍。

这个结果是非常合理的。在现今广泛的高速访问的基础设施下，传输时间不再减慢浏览器打开网页速度，而是生成网页的计算时间。换句话说，时间花费在web服务器编译HTML的内容上，这个时间是在它已经准备好发送之后。

从用户的角度来看，这是一个空的页面显示的延迟——单一事件影响用户体验不仅仅是其他相关的影响因素。

谷歌使用它来设计UX-focused 算法就不那么惊奇了。TTFB的另一个术语就是，你能多快的准备好渲染HTML？在高速通讯的网络通信时代，内容分发不再是瓶颈。

CDNs如何提高SEO

动态生成内容和CDNs没什么紧密的关系。毕竟，Processing time是99%的问题。基于CDN代理分发也不能提供一个有效的解决方案。

实际上，CDNs，严重的依赖缓存头信息，可能会导致弊大于利，因为他们实际上增加了整个的加载时间——在原始服务器和浏览器之间增加了额外的连接点。

在现在CDNs中引入了多种压缩方法，这些压缩方案队医上述的问题也是无效的。然而，它可以通过交付严格的内容打包信息进一步减少networking time，它们对于Processing time也是没有任何作用的。

到目前为止，最好的方式是，CDN被用来提高通过智能缓存动态HTML的交付上，从而消除处理原始服务器的需求。

想象以下情形，如果你正在使用任何类型数据库驱动的CMS，你的主页需要为每个用户一次又一次的生成页面。你所有的博客也是一样，你的联系页面，你的“About us”等等，又有多少页面实际上更新呢，或者它们的更新频率又是多少呢？对这些页面的HTML部分进行分类，他们是属于静态的部分，让他们直接从CDN上进行交付，这样没有服务器的处理从最近的地点获取信息更容易也更加的TTFB友好？

这也是现在我们在Incapsula’s Advanced Caching feature中所做的事情，使用自主学习算法来动态缓存“典型的不可缓存的”已呈现的内容。

通过监测使用模式和变化来动态的生成内容，Incapsula’s算法自动识别低利用率的缓存机会。包括’stale’(过时的)动态生成HTML。一旦这样一个对象被确定了，它缓存的副本仍然保留在我们缓存的网络中。即使本质上是动态的，内容也是从最近的数据中心以0处理时间的结果被送达。

不用说这种方式可以有效的提高TTFB以及速度，宽度等相关的指标。它唯一的缺点是可能会影响内容的新鲜度，这种缺点通过工作在场景背后连续的验证算法解决。反复的比较缓存副本和原始版本，来确保新鲜度。

使用Incapsula CDN管理TTFB和新鲜度

直到最近关于动态缓存内容的Incapsula’s方法才运行在自动驾驶上。然而，我们newly introduced CDN settings确保用户能够调整他们的缓存策略，提供了一些额外的方法，都是绝对值得一提的：

• Purge Cache
  这个最新增加的功能目的是通过移除与我们预先设置的验证周期的依赖来清除所有的缓存对像，内容和自动验证机制。点击鼠标缓存副本即被删除，为所有最新更新的内容或动态生成的内容保持即时新鲜度。
• Cache Everything
  这是基于学习算法版本中最受争议的方法。该功能可用即缓存所有可用的对象，不管他们的类型和功能。明显的缺点是对新鲜度产生重大的影响。尽管如此，如果你运行的是一个静态的博客，可以开发一个程序在每次更新后手动清除缓存，这可能是一次选择方案。
• Always Cache(by resource)
  在缓存一切模式上有一个更多选择的版本。是一个可以手动微调缓存指令的工具。如果你仅仅想缓存某一特殊页面的HTML部分而不影响页面的其他部分来提高TTFB，你可以使用这种方式。
• Async Validation
  这个方式控制自动验证周期。启用这个选型确保所有用户总是会从缓存中提高TTFB。然而，在每个缓存周期中，用户有可能访问过时的副本，因为缓存在他访问的过程中将异步的进行更新。
• Override “Vary:User-Agent”headers
  “Vart:User-Agent”将防止缓存。然而，这些headers经常被滥用，他们经常出现在没有真正目的服务的网页上。启用该选项，将允许Incapsula来重写这些指令，来提高你的TTFB和用户体验以及搜索引擎排名。