重新设计SitePoint：缓存和速度

One of the objectives for developers of the new SitePoint website was to make it fast. Really fast.

新SitePoint网站的开发人员的目标之一是使其快速发展。 真快。

Before we dive into what we did, I want to show you where we’re coming from:

在深入了解我们所做的事情之前，我想向您展示我们的来源：

• Time to first byte: ~3 seconds
  到第一个字节的时间：〜3秒
• Document complete: 6-9 seconds
  文件完成：6-9秒
• HTTP Requests: 100+ (first time), 35+ (repeat)
  HTTP请求：100+(首次)，35 +(重复)

As you can see, this is pretty bad. As a developer, it just hurts to see those numbers. We want to create world-class code and 100+ requests for one page just isn’t.

如您所见，这非常糟糕。 作为开发人员，看到这些数字只会很痛。 我们想要创建世界一流的代码，而并非要为一页创建100多个请求。

But, is speed just something we developers care about or does it actually matter for your business?

但是，速度仅仅是我们开发人员所关心的事情，还是对您的业务真正重要？

A lot has been written on this topic, and the uniform conclusion is that loading time affects your bottom line. Another one is that page speed is one of the factors in Google’s search engine ranking.

关于该主题的文章很多，统一的结论是加载时间会影响您的利润 。 另一个是页面速度是Google搜索引擎排名中的因素之一。

If you’re still not convinced, a faster backend lets you serve more traffic with the same infrastructure, saving you money. Finally, an increase in load time as been proven to lead to an increase in pageviews per visit.

如果您仍然不相信，那么更快的后端可以让您使用相同的基础架构来提供更多流量，从而节省资金。 最后，事实证明，加载时间的增加会导致每次访问的综合浏览量增加 。

So, what exactly factors into a speed-up in load time? When we think about how fast a website is, we’re most likely talking about various aspects of speed. I think it’s good to ask two questions and answer them separately even if they correlate somewhat:

那么，究竟什么因素会导致加载时间加快呢？ 当我们考虑一个网站的速度时，我们很可能在谈论速度的各个方面。 我认为最好提出两个问题并分别回答，即使它们之间存在一定的相关性：

• How many requests can we handle (how fast is the backend)?
  我们可以处理多少个请求(后端有多快)？
• How fast does the website feel (how fast is it perceived by the user)?
  网站的感觉有多快(用户感觉到有多快)？

We’ll look at each of these questions, and then see how we answer them here at SitePoint.

我们将研究每个问题，然后在SitePoint上查看如何回答。

我们可以处理多少个请求？ (How many requests can we handle?)

This greatly depends on how long one request takes when it comes in, and how many of the incoming requests we have to actually process instead of serving cached versions. At SitePoint, we’re in the lucky position to serve relatively static content, which is the same for all our visitors. This allows us to cache most of the responses, meaning most requests never hit our app.

这在很大程度上取决于一个请求进入时需要花费多长时间，以及我们必须实际处理而不是提供缓存版本的传入请求数量。 在SitePoint，我们很幸运能够提供相对静态的内容，这对我们所有的访客都是一样的。 这使我们可以缓存大多数响应，这意味着大多数请求从未命中我们的应用程序。

Instead, our proxy serves in front of the website serve the response. If you check your network traffic in the browser, you’ll see most pages are served with a 304 Not modified header.

相反，我们的代理服务器在网站前面提供响应。 如果您在浏览器中检查网络流量，则会看到大多数页面都带有304 Not modified标头。

Speeding up the time it takes to generate a response is trickier, as we can’t change the internals of WordPress. However, using plugins such as W3 Total Cache, we can cache some of the more expensive parts, for example making use of the WordPress Object Cache.

加快生成响应所需的时间比较棘手，因为我们无法更改WordPress的内部结构。 但是，使用W3 Total Cache这样的插件，我们可以缓存一些更昂贵的部件，例如，利用WordPress Object Cache 。

网站的速度有多快？ (How fast does the website feel?)

Besides the time needed for the response to come in, we also need to address the following:

除了响应所需的时间外，我们还需要解决以下问题：

• How long does it take until the browser starts rendering?
  浏览器开始渲染需要多长时间？
• How long does it take until the site is ready to be used?
  网站准备就绪需要花费多长时间？
• How long does it take until the browser finished loading?
  浏览器完成加载需要多长时间？

Technically speaking, we want to keep the time until the DOMContentLoaded event is fired at a minimum. Quite often, a website will feel much faster without having to change any backend code when you just reduce the time to DOMContentLoaded.

从技术上讲，我们希望保留时间，直到最小触发DOMContentLoaded事件为止。 通常，仅减少DOMContentLoaded的时间，而无需更改任何后端代码的网站就会感觉更快。

Before telling you how we do this here at SitePoint, I want to recap some general rules when it comes to frontend performance:

在向您介绍如何在SitePoint上执行此操作之前，我想回顾一下有关前端性能的一些一般规则：

• Make as few HTTP requests as possible (combine your assets)
  发出尽可能少的HTTP请求(合并您的资产)
• Download as little as you have to (minify everything and serve it gzipped)
  只需下载就可以下载(最小化所有内容并以压缩文件形式提供)
• Cache everything as aggressively as possible
  尽可能快地缓存所有内容
• Include JavaScript at the bottom
  在底部包括JavaScript

To achieve this, we generated three files during our build process:

为此，我们在构建过程中生成了三个文件：

• Stylesheet
  样式表

• JavaScript that needs to go into the head (which is barely anything)

  JavaScript的需要进入head (这是什么勉强)

• JavaScript that can go just before the closing body tag

  可以在结束body标签之前使用JavaScript

All of those files are minified. Now, to be able to cache them as long as possible without having to worry about invalidation, we include the md5 hash of the content into the filename, like so: styles-3ed1dd875e184c186ecdce24235a714d.css. With that in place, we cache each particular file for a very long time using the Expires header (Etag would work equally well).

所有这些文件都被缩小了。 现在，为了能够尽可能长地缓存它们而不必担心无效，我们将内容的md5哈希包含到文件名中，例如： styles-3ed1dd875e184c186ecdce24235a714d.css 。 设置好之后，我们使用Expires标头将每个特定文件缓存了很长时间( Etag也会同样有效)。

If you’re using frameworks like Rails or Symfony2 to build your website, you get all of this for free. SitePoint however is running WordPress, which unfortunately does not have any support for this out of the box. There are a couple of plugins, but in the end, we decided to not use any of them.

如果您使用Rails或Symfony2之类的框架来构建网站，则可以免费获得所有这些信息。 但是，SitePoint正在运行WordPress，但不幸的是，WordPress对此没有任何支持。 有一对夫妇 的 插件 ，但最终，我们决定不使用其中任何一个。

Instead, we process our assets during build using Grunt. The reason for this is that it’s impossible to have reliable asset processing from within WordPress on a multi-server setup without a shared storage, which we don’t use anymore.

相反，我们在构建期间使用Grunt处理资产。 原因是无法在没有共享存储的情况下在多服务器设置上的WordPress内部进行可靠的资产处理， 而我们不再使用共享存储。

结果 (Results)

With all that in place, we’ve got quite a responsive website, serving a huge amount of traffic quite easily. Let’s see what this looks like in numbers:

有了这些，我们有了一个响应Swift的网站，可以轻松地提供大量流量。 让我们看一下数字的样子：

• Time to first byte: ~1 second
  到第一个字节的时间：〜1秒
• Document complete: 1-2 seconds
  文件完成：1-2秒
• HTTP Requests: ~20 (first time), ~7 (repeat)
  HTTP请求：〜20(第一次)，〜7(重复)

For the homepage, a typical page load will fire the DOMContentLoaded event under two seconds, with it being around one second for cached responses. Of course, these times will vary depending on your location and whether the internal cache of the page you access has been primed.

对于主页，典型的页面加载将在两秒钟内触发DOMContentLoaded事件，对于缓存的响应，该事件大约为一秒钟。 当然，这些时间会有所不同，具体取决于您的位置以及您访问的页面的内部缓存是否已准备好。

Overall, coming from 6-9 seconds and 100 requests, this is an amazing achievement which we hope you enjoy every time you point your browser to www.sitepoint.com.

总体而言，这是6到9秒和100个请求，这是一个了不起的成就，我们希望您每次将浏览器指向www.sitepoint.com时都喜欢。

翻译自: https://www.sitepoint.com/redesigning-sitepoint-caching-speed/