现在人们普遍认为web性能对业务至关重要。速度较慢的网站可能会影响电子商务商店的转化率，也可能会影响SaaS服务的注册率，并降低内容的读者群。在感恩节和黑色星期五前夕，电子商务网站转向Cloudflare这样的服务来帮助优化它们的性能，抵御购物季节的流量高峰。为了做好准备，一位电子商务客户于11月9日加入Cloudflare，也就是购物季前几周。他们不是通过我们的企业计划加入，而是通过在线订阅我们的商业计划书并将其名称服务器切换到我们这里来注册的自助客户。他们的网站运行的是Magento，这是一个非常慢的电子商务平台，里面有很多有趣的PHP，还有大量的XML软代码。运行版本1.9的平台有些过时（Magento在版本2.0和后续版本中被完全重写）。尽管有点过时的技术，这个电子商务网站对这个客户来说已经足够好了，并且已经做了很多年的工作。他们是第一个注意到一个有趣的技术问题的人，这个问题围绕着性能和安全性之间的矛盾。尽管他们是第一个强调这一问题的人，但在黑色星期五前夕，我们最终在Magento 1.8/1.9上看到了十几个客户有类似的问题。初始优化在注册Cloudflare之后，站点所有者试图进行一些更改，以确保他们的站点能够快速加载。网站开发人员已经确保了网站是通过HTTPS加载的，这样他们就能够确保他们的网站是通过新的HTTP/2协议加载的，并进行了一些更改，以确保他们的网站针对HTTP/2进行了优化（有关详细信息，请参阅我们针对Web开发人员的HTTP/2博客文章）。在Cloudflare，我们已采取措施确保建立安全TLS连接不会产生延迟开销，下面是我们使用的优化的不完整列表：TLS会话恢复OCSP装订快速椭圆曲线密码算法动态TLS记录大小此外，他们还启用了HTTP/2serverpush，以确保关键CSS/JS资产可以在客户机发出第一个请求时被推送到客户机。没有服务器推送，客户机必须下载HTML响应，解释它，然后计算出需要下载的资产。大图片是懒加载的，只在需要用户看到时才下载。此外，他们还启用了一个名为Polish的Cloudflare功能。启用此功能后，Cloudflare会动态计算出在WebP（Google开发的一种新的图像格式）中提供图像的速度更快，还是以不同的格式提供图像更快。这些优化确实改善了性能，但他们的网站仍然很慢。尊重TTFB在web性能方面，有一些不同的因素会影响响应时间—我粗略地将它们归纳为以下三类：连接和请求时间-在发送请求以供网站加载内容之前，需要执行以下操作：DNS查询、TCP握手以建立与web服务器的连接以及TLS握手以建立安全连接页面呈现-动态站点需要查询数据库、调用API、写入日志、呈现视图等，然后才能对客户端做出响应响应速度-从web服务器下载响应，在浏览器端呈现HTML并拉取HTML中链接的其他资源电子商务网站已采取步骤，通过启用HTTP/2和进行其他现场优化来提高其响应速度。他们还通过使用诸如Cloudflare这样的CDN服务来优化连接和响应时间，以便在优化TLS/TCP连接时提供快速DNS和减少延迟。然而，他们现在意识到，他们需要优化的关键步骤是网页呈现，这将发生在他们的网页服务器上。通过查看他们的站点如何加载的瀑布视图（类似于下面的一个），他们可以看到主要的约束。示例瀑布视图网站优化.com在初始请求中，您可以看到绿色的"Time to First Byte"视图花费了很长时间。很多浏览器都有查看瀑布图的工具，Google为Chrome提供了一些很好的文档来做这件事：开始分析Chrome DevTools中的网络性能。您还可以从站点速度测试工具（如网页测试.org.到第一个字节的时间本身是一个经常被误解的度量，通常不能归因于单个错误。例如，使用Cloudflare这样的CDN服务可能会使TTFB增加几毫秒，但这样做有利于整个加载时间。这可能是因为CDN正在添加额外的压缩功能以加快响应速度，或者仅仅是因为它必须建立回原始web服务器的连接（客户端看不到）。在某些情况下，调试TTFB是一个问题的原因非常重要。例如，在本例中，电子商务平台仅生成HTML响应就需要3秒以上的时间。在本例中，很明显约束是服务器端页面呈现。当web服务器生成动态内容时，它必须先查询数据库并执行逻辑，然后才能为请求提供服务。在大多数情况下（即产品页面），页面将与其他所有请求相同。只有当有人在他们的购物车里添加一些东西时，这个网站才会真正变得动态起来。启用基于Cookie的缓存在有人登录到Magento管理面板或向购物车添加内容之前，页面视图是匿名的，并且将以相同的方式提供给每个访问者。只有当匿名访问者登录或在购物车中添加内容时，他们才会看到一个动态的页面，而不是其他页面。因此，可以缓存这些匿名请求，这样原始服务器上的Magento就不需要不断地重新生成HTML。我们的商业计划中的Cloudflare用户可以在使用magnetic时使用我们的绕过Cookie缓存功能来缓存匿名页面视图。这就允许在我们的边缘缓存静态HTML，而不需要在请求之间重新生成它。这为访问者的前几次页面访问提供了巨大的性能提升，并允许他们在需要时与动态站点进行交互。此外，它有助于在发生流量高峰时降低源服务器的负载，为那些需要它来完成动态操作（如支付订单）的用户节省宝贵的服务器CPU时间。以下是如何使用页面规则功能在Cloudflare中配置的示例：上面的页面规则配置指示Cloudflare"缓存所有内容（包括HTML），但是当它看到包含任何cookie的请求时，会绕过缓存：external_no_Cache、PHPSESSID或adminhtml。最终的边缘缓存TTL设置只是指示Cloudflare将HTML文件保存在缓存中一个月，这是必需的，因为Magento默认使用头来阻止缓存。站点管理员将其站点配置为如下所示：在第一个请求中，用户是匿名的，并且他们的请求与其他请求没有区别——他们的页面可以从Cloudflare缓存中得到服务当客户向购物车中添加内容时，他们会通过POST请求来执行此操作—因为POST、PUT和DELETE等方法旨在更改资源，因此会绕过Cloudflare缓存在POST请求向购物车添加内容时，Magento将设置一个名为external_no_cache的cookie由于站点所有者已将Cloudflare配置为在我们看到包含外部"无"缓存cookie的请求时绕过缓存，因此所有后续请求都直接发送到源站这种行为可在以下简图中总结：站点管理员最初为了测试目的在子域上启用了这个配置，但是发现了一些奇怪的东西。当他们在测试站点上向购物车添加内容时，购物车将显示为空。如果他们再次尝试向购物车添加内容，则该项目将成功添加。该客户报告了另外一条有趣的信息——当他们试图使用Varnish在内部模拟这种基于cookie的缓存行为时，他们遇到了完全相同的问题。本质上，"添加到购物车"功能将失败，但仅限于第一个请求。这确实是一种奇怪的行为，客户联系了Cloudflare支持部门。调试客户来信时，我们的新加坡办事处正在结束下午的工作，最初由该办公室的一名支持工程师进行了会诊。支持代理评估了问题所在，并初步确定如果前端cookie丢失，则"添加到购物车"功能将失败。无论您在Magento上访问哪个页面，它都会尝试设置前端cookie，即使它没有添加外部的\u No \u缓存cookie当Cloudflare缓存静态内容时，默认行为是，如果文件将最终保存在缓存中，则会从服务器上剥离所有Cookie—这是一种安全保护措施，可防止客户意外缓存私有会话Cookie。当缓存的响应包含一个Set Cookie头时，这适用，但是当Cookie通过JavaScript设置时不适用，以便允许像Google Analytics这样的功能工作。他们发现我们的网络边缘的缓存逻辑运行良好，但不管出于什么原因，Magento会拒绝在没有有效前端cookie的情况下向购物车添加内容。为什么会这样？当新加坡把轮班工作交给伦敦时，负责处理这张罚单的支持工程师决定将这张罚单上报给我。这主要是因为，在去年年底，我已经拥有了这个特性的重新定价权（它向我们的自助式商业计划用户开放，而不是仅限于企业）。那是说，我没有碰过万磁林