Understand Caching in WordPress, Part 1: The Basics

Greetings, WPMU readers! I come bearing a witch’s brew of news both bad and good. (Sorry…that’s just how I roll.)

The bad news: if you run WordPress, then sooner or later, you’ll have to understand caching. Caching is critical to site performance. And performance, as Siobhan noted, is critical to the success of your Web sites: if they bog down, both your direct traffic and your search engine rankings will suffer. But here’s the good news: caching’s not that bad! Caching only seems confusing because there are so many options available.

In the first of this two-part series, I’ll cover the basics of caching, why it’s important, and the (many) types of caching available on both your users’ computers and your Web server. I’ll even discuss a few non-caching performance optimizations that are included in the most popular WordPress caching plugins. In the next article, I’ll review the various plugins available for WordPress caching, and attempt to address the largest questions WPMU readers have asked us about optimizing their WordPress-powered Web sites.

What is Caching?

To understand caching better, let’s look at how data flows from your site to your users. WordPress has to shuttle a lot of data around between several computers, usually over long distances. The following diagram is a simplified rendition of how data flows between a Web browser and your WordPress Web site.

Here’s what happens when a user types in http://www.YourAwesomeWordPressWebsite.com/:

1. The user’s browser contacts your Web server. This user may be any physical distance from your Web server – either down the street at a coffee shop, or halfway around the world.
2. Your WordPress installation contacts the database where it’s installed (which is often hosted on a separate machine) to fetch your posts and other stored data.
3. The Web server compiles this data into an HTML page, and returns it to the user.

At a minimum, then, your Web site’s data must travel between three computers. What if we could speed up all this data transfer by taking some shortcuts? For example:

• What if the user’s Web browser didn’t re-request your banner image each time the user pressed F5, but instead kept that image on her local hard drive until you changed it?
• What if, instead of calling its MySQL database for every page request, WordPress kept the results of previous database requests around until you made a change to the database (such as posting a new article)?

That, my friends, is caching. Caching is reusing data from previous requests to speed up subsequent requests. In the example above, caching is used to minimize the amount of data that must flow between machines across the Internet. This results in fewer requests between machines, which translates into a speed boost for your Web site.

While caching can be used to minimize the flow of traffic between machines, this isn’t its only use. Caching can be employed whenever it would prevent your client’s Web browser or your Web server from performing any operation that is both (1) time-consuming and (2) redundant.

How Caching Can Help Your Site

A beginning user who installs a WordPress caching plug-in will be blown away by the number of caching options available. Before we dig into the mechanics of adding caching to your site, let’s review the various types of objects that can be cached on both the client (Web browser) and the server (WordPress/PHP).

Client-Side Caching

Every Web browser keeps a local cache of all of the HTML files, images, Cascading Stylesheet (CSS) and JavaScript files it has downloaded from a given Web site. Your WordPress site can take advantage of the client-side cache by establishing caching rules for its content. When cache controls are properly set on images and scripts, a Web browser will ask the server if the content has changed since it was last downloaded. If it hasn’t changed, the browser will use its locally cached copy, instead of retrieving the entire item.

This negotiation occurs unknown to the user using the Web’s protocol language, Hypertext Transfer Protocol (HTTP). We can observe this dance with an HTTP sniffing tool such as Eric Lawrence’s Fiddler for Windows. In the screenshot of Fiddler below, we see how the Web browser (Chrome) requests an image from my Web site using the HTTP If-Modified-Since header:

In this case, the image in this blog post hasn’t changed since I uploaded it, so my Web server responds with an HTTP 304 “Not Modified” status code:

Most images are static; they rarely change after an article is posted. Client-side caching of such static content greatly reduces site load times, and reduces the overall burden on your Web server.

Server-Side Caching

Server-side caching refers to the various types of caching performed by your WordPress server. A WordPress installation running a caching plugin can cache various kinds of data, including:

• HTML pages. WordPress stores your Web site’s pages in parts. When a page is requested, WordPress must combine the various parts of your template – your header, body content, footer, sidebar template, etc. – with the post data it retrieves from MySQL to create the full HTML page that is returned to the user. HTML page caching saves these constructed pages, serving them to multiple users.
• MySQL database query results. Instead of asking your MySQL database to return the same 10 posts 1,000 times, you can cache the result of a single query, and keep it on your Web server until you post a new article, update an existing article, or change your WordPress configuration options.
• Object caching. WordPress has an object caching API that caches certain programmatic objects it uses in memory. By default, this caching only lasts for the lifetime of a single request. As we’ll see in my next article, some WordPress caching plugins enhance and optimize this API by reusing objects between requests.
• PHP opcode caching. As mentioned above, all PHP pages must be compiled into code that a computer can execute. Opcode caching saves this compiled code between requests. Less compilation means less work for the server, faster server response times, and…oh, you know the rest.

Disk Caching vs. Memory Caching on the Server

Most WordPress caching plugins support caching all of this server-side data in one of two ways: on the disk, or in memory. Since accessing memory is orders of magnitude faster than accessing a hard drive, caching data in memory provides the biggest speed bump. However, most sites that are hosted on a shared server (i.e., most WordPress blogs with a basic account on a Web host) will need to use disk caching.

Other WordPress Speed Optimizations

There are other performance optimizations a WordPress-powered Web site can incorporate that fall outside of the realm of caching. Since most caching plugins support these optimizations, it’s important to understand what they are and how they work.

HTTP compression

All data sent over the HTTP protocol can be compressed on the server. This smaller data stream is then sent to the Web browser, which uncompresses and displays it. This reduces the number of bytes sent between your Web server and your users, resulting in decreased page load times. For more juicy details, see this post on WordPress performance optimization.

Script and Stylesheet Minimization

Every image or script on your Web site must be loaded through a separate HTTP request from your browser. If you have 10 Javascript (.js) files on your Web site, a browser must make 10 separate requests to retrieve them. Lame! Tools such as Minify can combine multiple Javascript and CSS files into a single monolithic file, reducing the number of requests for your scripts from 10 down to one.

To Be Continued…

Enough of the preliminaries! Now that we’ve reviewed the basics, we can put them into action. In our next instalment, we’ll review the most popular caching plugins for WordPress, and discuss how to configure them for various scenarios – shared servers, virtual private servers, dedicated hosts, and multisite configurations.

Tags:

• caching
• performance