BRAD: Welcome to Apply Filters, the podcast all about WordPress development. I’m your host, Brad Touesnard. And joining me, as usual, is my cohost, Pippin Williamson.

PIPPIN: Hi, everybody.

BRAD: This is Episode 16 and, in this episode, we’re going to talk a little bit about what we’ve been working on recently and some caching, lots of stuff about caching. So do you want to start us off, Pippin?

PIPPIN: Sure. Why don’t we start by mentioning our sponsorship for the episode? Sami from Foxnet Themes was kind enough to sponsor an episode. Sami does some really great work over at Foxnet-Themes.fl [sic]. If you just search Foxnet Themes in Google, you’ll find him. He’s got some great themes up for sale.

He also released a nice little blog article recently about his experience becoming a theme author for WordPress.com. WordPress.com tends to have some extra special requirements, things you can or can’t do, and so he went through some of those requirements really explaining how it wasn’t that hard to become an author on WordPress.com. So if that’s something that you’re interested in, definitely go check it out.

BRAD: Cool. So that’s Foxnet-Themes.fi, right?

PIPPIN: Oh, fi, sorry. That’s right.

BRAD: Yeah. I was like, it’s fl? When did that happen?

PIPPIN: I can’t read. So definitely thanks to Sami for sponsoring the episode and go check him out.

BRAD: Yep, you’re awesome, Sami.

PIPPIN: So, Brad — Brad, what have you been working on lately?

BRAD: So a little while ago I read this article from Theme Foundry about how they sped up their site using Nginx and SPDY and how they got their SSL rating up and stuff. And so it kind of prompted me to upgrade my SSL system. I’d been using this old server called Pound. It’s, I think, ancient. And Nginx is far superior. It’s kind of cutting my teeth on Nginx for the first time.

Anyway, I checked my SSL rating and mine was a C for DeliciousBrains.com, and that was largely because of the configuration of Pound. So I replaced Pound and did some tweaking to the Nginx configuration and managed to get my SSL rating up to A+, so that was pretty cool.

PIPPIN: That is cool.

BRAD: And one of the —

PIPPIN: That’s a whole level of the server side of things that I’ve never even dived into.

BRAD: Yeah. Yeah, yeah. It’s kind of — I find it fun, but some people hate servers. I think Brad Williams is on record: I wish I could run a website without servers, or something.

PIPPIN: I have mixed feelings. I love servers in terms of like getting in and understanding how they work and learning how to really fine-tune them and things like that is really awesome. But when it comes to my business or anything like that, I just want my server to run. I don’t want to touch it.

BRAD: Yeah, exactly. I think —

PIPPIN: That’s kind of like my mentality with Linux and things like OS X. When I just want to get work done, I just want my laptop to be there, run in OS X to just work. But when I really just want to go have fun and tinker around, I want my Linux box to go do whatever I want on it.

BRAD: Yeah.

PIPPIN: And if I want to rip the kernel out, I rip the kernel out.

BRAD: Yeah. I think I —

PIPPIN: That’s kind of how I feel about servers.

BRAD: Yeah. I’ve gotten more into performance and like tweaking stuff since I started running an ecommerce website because I’ve found a fair amount of research that suggests the speed of your website is directly related to your conversion rate. Meaning —

PIPPIN: Yeah, there are tons of studies that show that.

BRAD: Yeah, meaning: if you’re site is slow, people will buy less. Right?

PIPPIN: Yep.

BRAD: So that’s why I’ve kind of taken this to the next level, I guess, but also because I’m really interested in it. One of the coolest things I found out actually is that there’s this HTTP header that you can send back in your response. It’s called the Strict-Transport-Security header. And you just have to send that back, and basically it tells the browser that any future requests to your domain name should be over HTTPS. So the next time you type in https://DeliciousBrains.com, the browser will automatically detect, oh, I got that header last time saying it’s always HTTP for this domain, and it automatically switches it. So like there’s no redirect first, which is pretty cool. I had no idea about that until I dove into this.

PIPPIN: I feel like that can have a substantial performance impact in terms of the time it takes to load that initial page —

BRAD: Yeah.

PIPPIN: — just by removing that redirect from HTTP to HTTPS.

BRAD: Yeah, yeah, totally, totally.

PIPPIN: That’s pretty wicked.

BRAD: So what have you been working on?

PIPPIN: My last week or so have been doing a lot of development on Affiliate WP, which is the affiliate plugin I’ve been working on for the last two months or so. I finally got kind of over a hurdle and got to a point where I got the plugin is mostly functioning. I can actually start using it. If I wanted, I could throw in upon a live site and actually start using it. So now it’s doing a lot of the fine-tuning, the little fun pieces here and there.

But recently I’ve been doing two things. Number one, I’ve been testing it on a whole bunch of different hosting environments. One of the issues that a lot of affiliate plugins have, at least affiliate plugins that are built directly into WordPress, and this also goes for ecommerce plugs as well, is that when you put really aggressive caching in place on your site, which this also leads into our caching discussion here in a little bit, things tend to break and don’t work as well. So like, you may have a referral link that result in a successful conversion, but, for whatever reason, it doesn’t actually track the referral or doesn’t successfully track it.

What I’ve been doing is testing the plugin on all of the different managed WordPress hosts, which generally have more aggressive caching than say your standard shared host or some others.

BRAD: What are you using —

PIPPIN: What was that?

BRAD: What are you using for an endpoint to make that request track that conversion?

PIPPIN: It’s all in JavaScript.

BRAD: Yeah, I know. But you have a WordPress endpoint too, right, where the JavaScript is hitting some WordPress endpoint to make that —

PIPPIN: Just admin-ajax.

BRAD: Oh, so you are! That’s — okay, so then that’s really surprising to me that that would be aggressively cached because those should be off limits, right, those ajax?

PIPPIN: No, admin-ajax is usually really reliable.

BRAD: Yeah.

PIPPIN: But so what happens is the way that I’ve set it up is that when you — let’s say that you load a referral, a URL that has a referral in it. That will actually trigger an ajax request from the JavaScript to admin-ajax at which point that’s where all of your referral data gets stored.

BRAD: Right.

PIPPIN: And so I’ve been testing that on all the different managed WordPress hosts, as well as some others, because they tend to have things: more aggressive page caching, more aggressive object caching, et cetera. And to make sure that it still works. And so far it’s working really, really great, which makes me happy. And then the other part of that is building my integrations between Affiliate WP and all of the WordPress ecommerce plugins.

BRAD: Right.

PIPPIN: So out of the box, for example, like if you sell through Easy Digital Downloads, it’ll work for that. It’ll allow you to track those conversions. If you use WooCommerce, or you use WPCommerce, or use Shopp, JigoShop, or any of the ecommerce plugins, built in all of those integrations.

BRAD: Cool. Are you having fun with this project?

PIPPIN: I’m having lots of fun with it right now.

BRAD: Cool.

PIPPIN: My first two months working on it were not very fun because it was kind of just the idea I was going to build it, but I didn’t really have an architecture in mind. I hadn’t got to the point where I was starting to really actually see it come together. And, in the last week, I got to where it’s really actually coming together. It’s a functioning plugin. It has all these different features. And so now it’s definitely — I have to — a lot of times I have to tell myself not to work on it because I have to do other things.

BRAD: Cool. I forgot to mention one thing that I found out recently is that there’s — that you can actually get statistics on your WordPress.org plugin pages from —

PIPPIN: I’ve seen that.

BRAD: — from Google Webmaster Tools of all places. So the reason I’m getting

PIPPIN: Isn’t that tied to the Google+ profile?

BRAD: Yeah, yeah, so you — if you add your Google+ profile to your WordPress.org profile, it kind of links the two, and it basically confirms you as an author of those plugins on WordPress.org. And so Google Webmaster Tools then gives you, because you’ve said I own these pages or I’m the author of these pages, it then gives you access to how many impressions those pages get, which is really cool.

PIPPIN: So do you just add the plugin pages like you would add a normal site in Google Webmaster Tools?

BRAD: No. There’s a special process. I’ll link it up in the show notes. There’s a special process you need to go through to become a verified author of those WordPress.org pages.

PIPPIN: Right, because I’ve seen the process for adding them, like adding your Google+ profile.

BRAD: Yeah.

PIPPIN: But I mean like in terms of getting them into Google Webmaster, that’s the part I’m not familiar with.

BRAD: Oh, no, no, no. They just showed up. That’s why I was like what the heck is this.

PIPPIN: Oh, okay. So I’ve just never gotten my authorship set up correctly.

BRAD: Possibly. I mean the authorship should put your headshot next to your plugin pages and search results as well, right? That’s kind of why I did it initially and because it’s just cool to claim ownership within the Google search results, right?

PIPPIN: Yep, clearly I do not have it set up because I do not show up. But I do know what you’re talking about with the header.

BRAD: There’s —

PIPPIN: Otto wrote up a nice post on it.

BRAD: Yeah. There’s a tool that you can kind of submit a certain, you know, submit this page and it’ll show you if you’re a verified author on this or not because I’m not sure if it’s always going to show a headshot next to your search result.

PIPPIN: Right.

BRAD: Especially if you’re the one logged in and searching.

PIPPIN: Right.

BRAD: So, yeah, there are definitely some tools that you can use to get that done. We’ll link it up in the show notes.

PIPPIN: Have you found that those stats show anything useful or interesting?

BRAD: Yes, actually, because I — so I found that my Amazon plugin gets over double the number of impressions than my Migrate DB Pro or Migrate DB, the free version, the plugin.

PIPPIN: Wow! Why?

BRAD: I have no idea.

PIPPIN: I mean, to be honest, I would have thought Migrate DB would be higher.

BRAD: So did I. So did I. And I really don’t know how reliable these stats are.

PIPPIN: Sure. Take them with a grain of salt. But they are still definitely interesting to look at.

BRAD: Yeah, yeah. And I don’t know where they’re coming from, to be honest. Is this because WordPress.org has Google analytics stuck into their page, or is this search? Is this from Google search somehow tracking these stats?

PIPPIN: I suspected WordPress.org had something.

BRAD: Yeah. That’s probably what it is.

PIPPIN: (Indiscernible)

BRAD: I thought it was just a neat find because I had never seen this thing. To be clear, if you log into Google Webmaster Tools, and you’ve already verified authorship, there’s a labs link in the sidebar. And if you expand that, there’s an author stats link, and that’s where you find this, this gem.

PIPPIN: That’s pretty cool.

BRAD: Yeah.

PIPPIN: I’ll have to go check that out and see if I can get it set up.

BRAD: Yeah. Have you — how’s you’re A/B testing going that we were talking about last time?

PIPPIN: It’s going pretty good. I’m running a test right now based on the size of my checkout screen. So I’ve seen speculation or maybe proof that —

BRAD: Hard to tell with the Internet.

PIPPIN: Yeah. I’ve seen various articles that suggest that a skinnier checkout screen converts better than a wide one.

BRAD: Ah, interesting.

PIPPIN: So what I did is I set up an A/B test to take my checkout screen and, for 50% of the users, it gives them the standard width. On a desktop, the EDD checkout screen is like 960 pixels wide, I think. It’s the same width as the site.

BRAD: Sure.

PIPPIN: As a standard site page. And so then I set up a test so that 50% of people that go to the checkout screen get one that’s 600 pixels wide, so everything is much smaller. And I wanted to see if that made any difference whatsoever. And I don’t have enough data to be definitive yet. Simply since the checkout screen is not the most hit page on the site, like it’s not like the homepage where you can build up thousands of hits in a short period of time. It’s going to take a little bit longer to accumulate all of the data.

BRAD: Right.

PIPPIN: But so far the skinny version has given me a 24.3% improvement on conversion rates.

BRAD: That’s nuts!

PIPPIN: Isn’t that crazy?

BRAD: Yeah.

PIPPIN: That’s insane!

BRAD: Yeah. Try explaining that one to somebody.

PIPPIN: Honestly, I think it comes down, I mean, I like the statement about A/B testing that A/B testing makes the smartest people in the room look like idiots.

BRAD: Yeah.

PIPPIN: Because I think it’s really true. My only explanation is simply that a skinnier screen is to flow down without getting distracted.

BRAD: Sure. I could see that. Yeah.

PIPPIN: And, I mean, whether there’s any truth to that or not, I mean, that’s purely speculation for myself. I have nothing to back it up.

BRAD: So you heard it here, folks. Make all your websites phone width, even on desktop.

PIPPIN: I’d be really interested to know, does — assuming that this is a standard result that most people would see for checkout screens, does that apply to other parts of a website as well?

BRAD: Maybe.

PIPPIN: I have no idea.

BRAD: I betcha reading, it does, because I always prefer when it’s a nice, like, tight column versus —

PIPPIN: You don’t want to read a page that’s 2,400 pixels wide.

BRAD: Yeah, exactly. You’re like —

PIPPIN: You want to read a page that’s maybe 600 or 700.

BRAD: Well, I think, as you, like when you read one line, it’s like the sense of accomplishment, like instance sense of accomplishment.

PIPPIN: Sure.

BRAD: If it takes you, you know, three-quarters of a second to read a line because it’s like from one —

PIPPIN: You also have to take into account like the way that people who read really, really fast do.

BRAD: Right.

PIPPIN: I didn’t know this for a long time, but my dad actually showed this to me. He can read a page in like an amazing amount of time.

BRAD: Right.

PIPPIN: But it turns out it’s because the way that he reads, he reads with both eyes at once, and he literally just scans down the page. He doesn’t go left to right.

BRAD: Right.

PIPPIN: He reads an entire line at a time, and he goes down the line. So basically his eyes are focusing on two points of the page just going down the page.

BRAD: Right.

PIPPIN: Whereas most people when they read, read left to right. They’ll read a line, they move down, the read a line, the move down, et cetera. And so with a skinnier page, it’s much easier to go straight down without going side-to-side.

BRAD: Right. Yeah, you don’t want to be reading one line like that’s —

PIPPIN: That’s why reading on my phone is awesome.

BRAD: Yeah, yeah. I really enjoy it as well. It takes some getting used to, but I really enjoy it now.

PIPPIN: I can read an article so much faster on my phone than I can on my desktop.

BRAD: Yeah. I do most of my reading, like I send everything to Instapaper, and I read it on my phone later in the day. That’s the way I operate.

PIPPIN: Nice.

BRAD: Do you use that Instapaper or Readability or one of those things?

PIPPIN: I never have.

BRAD: Oh, yeah? Yeah.

PIPPIN: Nope, never have.

BRAD: Yeah. Well, it’s funny because I always see people, like they’ll be tweeting about an article that just came out. And I’m like, I don’t have time to read that thing yet. It’s in my Instapaper, you know.

PIPPIN: Nice.

BRAD: So —

PIPPIN: Have you been — I think you mentioned that you might have been doing some A/B testing as well. What did you find?

BRAD: Well, yeah! You challenged me last week. You challenged me to a dual.

PIPPIN: That’s right. Yeah. How did your results come out? Do you have something to share?

BRAD: Yeah, yeah, yeah. So, first of all, I went with Google Analytics instead of doing it the easy way. I chose the hardest way possible, which actually just turned out to be — it actually just turned out to be a lot of reading and sifting through Google’s docs, which are not very good. And trying to figure out how to — like what code to add to my site that will pull this off. And, you know, the code in the end was actually very little. And it was kind of nice to be able to write my own JavaScript to change the page according to which test it is, right?

PIPPIN: Sure.

BRAD: So I set up —

PIPPIN: (Indiscernible) the variable that you can use in your JavaScript, like this is version A, this is version B?

BRAD: Yeah, it’s actually a little simpler than that. Actually you just drop in this like you set up the experiment in Google Analytics, like you click through. And it gives you this experiment ID. And you drop that in, and then you call a function after you drop that ID in. And this all happens before your Google Analytics code. So you drop this ID in, and it includes this JavaScript. And then you make this call to this choose variation function, and it returns a zero. In my case it’d be a zero, one, or two.

PIPPIN: Sure.

BRAD: And that, depending on which one of those, then I change things on the page, right?

PIPPIN: Right. That makes sense.

BRAD: Like as an example, if zero came back, I would change nothing, right? That’s the original version of the page.

PIPPIN: That’s going to be — yeah, that’s going to be your default.

BRAD: And then if one came back, I would remove the links in the header. So if you clicked on the home link, like the icon, nothing would happen. It wouldn’t go to the homepage. It would do nothing. Then the other links were just completely removed from my navigation bar, so there were gone. And then if a two was returned, I would remove the header completely, so the header bar is gone. And so this is a little bit interesting because it was kind of an A/B/C test, right?

PIPPIN: Were you only doing this on your checkout screen?

BRAD: Yes.

PIPPIN: Okay.

BRAD: Yeah.

PIPPIN: So the idea is, do you, by removing distractions, do you convert better?

BRAD: Exactly. That’s the test that we’re testing here. And so what was interesting is that so far the removed header completely is actually performing worse, 8% worse actually than the original with —

PIPPIN: Interesting.

BRAD: — with the links. But the one with the removed links and the bar is still there, so the big thing with the bar is that the branding is still there. When the bar is completely gone, I don’t have any branding anymore, so I think my guess is that it’s people are losing confidence in the site. It looks almost broken maybe. That’s my guess. But anyway, removing the links has increased conversion 20%, so that’s —

PIPPIN: That’s impressive.

BRAD: Yeah! That’s pretty good, right? So I think I’ll be doing that going forward is removing those links. I’m going to keep the experiment running for a little while longer until Google tells me that a winner has been announced because apparently they have some threshold that I have to hit before they actually declare a winner.

PIPPIN: Sure.

BRAD: But, yeah, it’s pretty cool. I was pretty happy with the reporting and stuff in Google Analytics, and it was pretty easy to set up once I figured out how to do that. So I might write a blog post just showing people how to do it in Google Analytics.

PIPPIN: I would be intrigued to see it. But it sounds like once you have it set up, the actual, the ways that things are added or removed from the page and the way that you’re looking at results is very similar to what Optimizely does.

BRAD: It’s exactly the same, I think.

PIPPIN: It’s just —

BRAD: Yeah.

PIPPIN: I mean, with Optimizely, you can also write up any custom JavaScript you want.

BRAD: Yeah. Oh, really? I didn’t know that.

PIPPIN: Yeah.

BRAD: Oh, that’s cool.

PIPPIN: Yeah, they’ll give you — they can give you a panel that basically says write your JavaScript here that you want to run on this variation.

BRAD: Yeah.

PIPPIN: But then there’s also more of a visual editor where you can select elements and say just remove this one for me or remove this one. And then I assume they just write some JavaScript for you.

BRAD: Right. Huh! That’s interesting. I also — I kind of got addicted to this whole thing, this A/B testing. It’s pretty cool to see these results.

PIPPIN: It’s fascinating.

BRAD: Yeah. And so I’ve actually added another one in the meantime, and I just changed the message on the landing page for Migrate DB Pro to be a bit more engaging, and I’ve seen a little increase in conversions there.

PIPPIN: Well, I’ll be curious to see what happens for you. So like you change that message, and you’re seeing an increase. I did a similar experiment where I changed the wording of a button and, for the first two weeks, I saw a definite improvement. And then for like four weeks after that, it went straight downhill and it got substantially worse.

BRAD: That is so weird.

PIPPIN: Which, I mean, I have no explanation for whatsoever.

BRAD: I wonder if that is —

PIPPIN: I think it just goes to show that you have to accumulate enough data before you make a decision because —

BRAD: Right.

PIPPIN: — the only thing that can give you a definitive answer is enough data.

BRAD: Right. I think it also — I think you have to be careful what else is going on. And also, I don’t think I’m testing the right thing here. So right here I’ve changed. I’ve changed the wording on the landing page for Migrate DB Pro, and I’m testing conversions, which is way further down the funnel. Like they have to hit my pricing page and then click a button.

What I really should be testing, I think, is if they proceed, like does this affect my bounce rate? Do people stick around the page longer because I’ve changed this message?

PIPPIN: Right. What I did was I looked at engagement, engagement/click. So like did this message encourage the person to click on the button or the button next to it more so than the other message?

BRAD: Right.

PIPPIN: Because it’s really difficult to say the button on the homepage — I mean, it depends on where it is. You have to be careful about testing too far down. So just because you have something on the homepage that improved initial engagement does not mean that that’s going to improve conversation rates. I mean, it might, but that’s very difficult to test because there are too many variables in between.

BRAD: Right. And you also have to be careful like what other things you’re changing on the site in the meantime, right?

PIPPIN: That’s why you also have to be careful about running multiple tests at the same time.

BRAD: Yes. Yeah, that they don’t conflict.

PIPPIN: Because they might be conflicting or the message in A over here may be actually affecting the conversion rate of version B over here.

BRAD: Yeah. Yeah, I could see that. Crazy.

PIPPIN: Yeah, nuts. It’s pretty cool though.

BRAD: Should we get on to the —

PIPPIN: It’s fun stuff.

BRAD: Yeah, it is. It’s fun. Should we get on to the main course here?

PIPPIN: Yeah. Let’s jump into caching.

BRAD: All right. So why do we need to do caching in the first place? Who cares? Let’s just run our pages right off of the Web server.

PIPPIN: Hey, it makes things a lot easier.

BRAD: Way easier. Yeah.

PIPPIN: I mean, simply put, caching is for performance. If you get into anything that’s on a certain scale or complexity, you’re going to run into performance issues. And one of the ways that we improve that is caching.

BRAD: Yeah. Yeah, because —

PIPPIN: I mean, it obviously goes beyond that, but I think that’s a simple answer.

BRAD: Yeah, so as an example, so say when you request the homepage, your request goes through and hits the Web server, and the Web server then calls, prepares a query that blows through the database and takes like two seconds to run or something crazy. So then your page doesn’t come back for like, you know, maybe three or four seconds, which is a really long time in terms of serving a page request, right?

PIPPIN: Right.

BRAD: So there’s an example where you want to put caching in there somewhere, maybe even like in a couple places, right?

PIPPIN: Right, because if that page is then cached, depending on how it’s cached, maybe the first person that visits will generate the page, and then another person will come along and, since the page has been cached in such a way, that visitor never actually touches the database. They don’t ever do any of those queries or anything. They simply pull the page from cache and it’s loaded instantaneously.

BRAD: Exactly, yeah.

PIPPIN: That’s the more or less goal of it.

BRAD: Yeah. I mean, if it was that bad of a scenario that I just describe where it’s taking two seconds to run an SQL query.

PIPPIN: You probably have other problems on the site.

BRAD: You probably want to look at something. I mean, it’s possible though that that’s a query that you do want to run now and then. In that case, you might want to run it on a schedule and then cache it.

PIPPIN: Right. That’s where Cron is come in handy.

BRAD: Yeah, exactly.

PIPPIN: So what kind of — we’ve got several different kinds of caching. Do you want to walk us through some basic caching types?

BRAD: Yeah. Well, you have a full page cache, so that’s where the whole page is cached either as a static file on the server or more typically it’s stored in memory, so the whole page is served up right from memory.

PIPPIN: And when you say the whole page, I mean, you mean the text, the images, the HTML, everything that is on that page, every asset, every file, et cetera, right?

BRAD: No. I just mean the source code of that page.

PIPPIN: The source code.

BRAD: That’s page caching.

PIPPIN: Well, right, but —

BRAD: Yeah.

PIPPIN: Yeah, never mind. Never mind. Yeah, yeah, the source code, the source code of the page. Your assets are not necessarily going to be cached because they may be in an external location.

BRAD: Sure. Yeah. You may, you know, but you could. You could have your CSS and JS and stuff cached as well in memory if you want to serve those up faster.

PIPPIN: Right, but they are not explicitly going to be included in the page cache unless you have inline.

BRAD: Yeah, exactly, so that’s a good way, actually. Like say if you just have a single page for some reason, like a landing page that’s getting a ton of traffic. If you want to load that page really quickly, maybe you want to dump your CSS right into the page, like right inline. Instead of the page loading and then it having to make a second request to get that CSS, so that’s another way that you can kind of optimize things.

PIPPIN: Sure.

BRAD: But anyway, another type of caching would be application level or object cache it’s often called. And that’s where you store things in memory, so bits of data in memory that is kind of part of the page or part of something that has to do with the page. A typical example of that would be transients in WordPress, right? If you have object caching turned on using — I think there’s a few ways that you can turn that on. One is Mark Jaquith’s APC object cache plugin. Does W3 Total Cache do that as well? I think it does.

PIPPIN: Yes, it does.

BRAD: Yeah. And so, yeah, you can turn that on. And so instead of — so transients are stored in the database. But instead of WordPress having to go do an SQL query and run it against the database and get that data back and then finally do something with it, it stores it in memory, and so it’s super fast to access that data.

PIPPIN: The main example, another example would be on transients. But maybe one that people will see on more databases is basically anything in the WordPress Admin, like any of the list tables, whether it’s post, pages, users, et cetera. If the site has object caching enabled, when those pages are generated, those lists of users, those are coming out of object cache.

BRAD: Yeah.

PIPPIN: Not the pages, but the data that’s on the pages. So the list of users, all of the user objects, et cetera are coming out of object cache, assuming they’ve been cached.

BRAD: Yeah, exactly. And then I guess, well, there’s actually kind of two — there’s actually two kind of variations of object cache as well. There’s the kind that persists between page requests, and then there’s the kind that only persists per request. So an example of that would be, that I found out recently, is the get_plugins function. That actually crawls through your WordPress plugins directory, opens up the PHP files and tries to find which ones are actually plugin files.

That function actually checks each one of those files. And it stores that in memory for that request. But for future calls to that function, it grabs it from memory. So it doesn’t have to do all that work again, which is actually a lot of work. So be careful when you’re calling get_plugins function because if you’re calling it at every request, it’s probably not a good idea.

PIPPIN: No.

BRAD: And what’s the — there’s another type. Pippin, do you want to cover that?

PIPPIN: Database caching?

BRAD: Yeah.

PIPPIN: To be honest, so this is something that this is where my knowledge of caching starts to dwindle a little bit.

BRAD: Yeah.

PIPPIN: Database caching is pretty similar to object caching, right?

BRAD: You know what, I don’t have a lot of experience with database caching either, to be honest. I just —

PIPPIN: I’ve always kind of assumed database caching is like caching your queries and anything that you run to the database.

BRAD: Yeah.

PIPPIN: It’s either — or it could — no. Sorry. I know what it is.

BRAD: I think MySQL does some fancy stuff on its own like caching common queries, right, so it doesn’t have to do so much work for the same query over and over again. I think it kind of handles everything. I’ve kind of just taken it for granted, I think.

PIPPIN: Right. Well, I think you can — I mean, it’s very possible that I’m completely dead wrong on this, so if somebody who is listening knows, that would be awesome to be corrected. But I think the difference between database and object caching — so object caching is going to cache your query. So that query is never even going to hit the database, for example.

BRAD: Mm-hmm.

PIPPIN: With database caching, you will hit the database, but you’re hitting a cached version of the database or of that table.

BRAD: Right.

PIPPIN: So for example, if we do a user query, and we return ten users, with object caching you’re going to cache the results of that query. With database caching, you’re going to cache where those results come from.

BRAD: Okay. I don’t know.

PIPPIN: I think. My basis for that is simply experience. It has nothing to do with any reading or anything I’ve ever done. But for example, let’s say you’ve got database caching enabled, and you run a query to the server.

BRAD: Yep.

PIPPIN: And then you modify the database, and you run that query again. Your modification may not show.

BRAD: Oh, really? Huh. I don’t think I’ve ever experienced that.

PIPPIN: That’s why it’s kind of — it can be a real pain in the rear for like ecommerce plugins because we’ll do a query to the database looking for something, I mean whatever it is you’re looking for. Maybe you’re trying to confirm a payment, complete an order. And then you run it again, and even though it is actually successful, it didn’t think it was because it came back with cache data.

BRAD: Right. Huh. Interesting. So what’s — so I think some people might be confused about like the difference between a content delivery network, CDN, and caching because they’re both often lumped together in terms of —

PIPPIN: But they are very different things.

BRAD: Yeah. Increasing performance, you know, it’s kind of they’re all kind of lumped together. Do you want to kind of take us through that?

PIPPIN: Sure. A CDN is — okay. Let’s step back for a second. Let’s say that you have files on your server, image files, CSS, JavaScript, et cetera. When a page is requested, those files are delivered. They’re loaded to the Web browser, and they’re loaded from your server. So the rate at which they can be loaded can be dependent upon your server performance.

BRAD: Mm-hmm.

PIPPIN: The idea of a CDN, a content delivery network, is taking all of those assets, those resources, and taking them away from your server. So instead of putting the strain on your server and having your — let’s just, to be extreme, let’s say instead of having your slow server serve those files to the browser, let’s have a really fast server serve them instead. So an example that people are probably familiar with, there’s a lot of reference to say, hey, let’s have Google deliver jQuery instead of WordPress.

BRAD: Right.

PIPPIN: Instead of our local server because Google is much faster. That’s exactly what this is. I mean, that’s simply saying let’s use Google’s CDN for this version of this library. A CDN is saying let’s take all of our images, all of our JavaScript files, all of our CSS, all of these static assets, and let’s put them onto their servers that are much faster and being used only to deliver these files.

BRAD: Yeah, exactly. And I guess the other part of it is the delivery network part is really that it can be delivered from a location that’s close to you. So say you’re visiting Australia, and you try to load your site there. Well, it’s going to try; the content delivery network is going to try to serve you assets from its Australian data center to try to speed things up.

PIPPIN: Right. Make things faster.

BRAD: And make things faster. But, you know, I’ve heard various reports about whether that actually works or not.

PIPPIN: I think it’s going to be a case-by-case basis.

BRAD: Yeah.

PIPPIN: If you have a really fast server, a CDN may not do anything for you. If you’re on a crappy little shared host, a CDN might be your savior.

BRAD: Yeah. I think —

PIPPIN: It can vary a lot.

BRAD: Yeah. I think the big thing with CDNs is like if you have rich media files like if you’re serving MP3s and video files or any big stuff like that, CSNs, I think, are going to save you big time —

PIPPIN: Right.

BRAD: — and speed things up for those people that are in Australia or wherever else. So what are the other plugins that or what are some of the plugins for WordPress that can help with caching then?

PIPPIN: I think there are three main ones. There’s WP Super Cache. There’s WP Total Cache. And then there’s APC from Mark Jaquith. The first two are, I’m going to — this is not necessarily entirely correct, but they’re kind of end-user plugins in a way. They’re plugins that are designed to just be put on your site to give you a performance boost.

BRAD: Mm-hmm.

PIPPIN: The APC one from Mark Jaquith is more of a — I kind of want to say it’s a developer’s tool. It’s not a plugin that you’re just going to put on your site to improve your performance. It is a plugin that you’re going to put on your site so that you, as the developer, or other plugins can make use of it.

BRAD: Right, right. So how does — so what does W3 — are you familiar with W3 Total Cache?

PIPPIN: Yeah, I’ve used it a lot actually.

BRAD: Okay.

PIPPIN: W3 Total Cache, it does a whole lot of different things. It is a beast to configure.

BRAD: It’s a kitchen sink plugin, is it?

PIPPIN: It is very much a kitchen sink plugin. I mean, it does everything from page caching to object caching and database caching to CDNs to more. And WP Super Cache is much simpler in that it does not have nearly as many options to configure, and it works a little differently. WP Super Cache generates static HTML files of your pages.

BRAD: Right.

PIPPIN: And I don’t think WP Super Cache does anything with database or object caching.

BRAD: Right.

PIPPIN: Now, I mean, we could talk forever on the different things that W3 Total Cache or WP Super Cache would allow you to do, and as well as problems that they can raise.

BRAD: Right.

PIPPIN: But I want to be very clear from my personal standpoint. I personally don’t; I really don’t like cached plugins.

BRAD: Right.

PIPPIN: I feel like cache plugins are like patching a hole that should have been repaired.

BRAD: Right.

PIPPIN: Kind of. Like caching is server side stuff.

BRAD: Yeah.

PIPPIN: And so if you are in a position where you have the ability to configure caching on your server, whether that’s because you’re on a managed WordPress host, you have your own dedicated server, please do it on the server side.

BRAD: Right.

PIPPIN: I’m sure there are people that will disagree.

BRAD: Yeah.

PIPPIN: I’m not convinced that a plugin like W3 Total Cache or Super Cache will ever get you the kind of caching that a true server side configuration will.

BRAD: Right. So the APC plugin from Mark Jaquith, APC Object Cache, it’s called, that’s an easy one that you can just drop in to the must-use directory or whatever. I guess you drop it into your content directory, the root of your content directory. And then it becomes a must-use plugin.

PIPPIN: Right.

BRAD: And then that supposedly boosts your — I mean, it uses the object cache that’s built into PHP.

PIPPIN: So WordPress has a built-in API called the WP Object Cache. If you’re not familiar with it, I suggest dumping that into Google and go find it on the Codex. And the WP Object Cache is used all throughout WordPress to cache, when able, things like user queries, post queries, things like that. And so the APC Object Cache basically modifies the way that Object Cache stores data.

BRAD: Right.

PIPPIN: I can’t say too much more because that’s kind of where my knowledge with it goes away.

BRAD: No, I mean that’s just, that’s exactly right. And, I mean, if you don’t have the Object Cache plugin configured, then you don’t get that benefit, right?

PIPPIN: Right.

BRAD: Yeah.

PIPPIN: One of the crazy things with the WP Object Cache API, which has some very simple functions to use like, for example, if you do a query, and you want to store those results into the object cache, you can run WP Object Cache like WP_Cache_add or WP_Cache_set, and if your server doesn’t have cache enabled, it’ll take it, but it won’t actually cache it.

BRAD: Yeah, it’ll just ignore it basically, right?

PIPPIN: It totally ignores it. But it is actually — it’s kind of cool because it means that, as a developer in your plugins, you can utilize the WP Object Cache as your main method of storing your complex operations into a cache and WordPress will automatically store that into cache in whatever way is available to it or whatever way it’s been told to.

BRAD: Right. I should clarify. I just said it doesn’t do anything, but actually it will do things for one request. So within the same request, like I just mentioned about the get —

PIPPIN: Oh, right.

BRAD: The get_plugins call, that uses the WP Object Cache to make sure that it doesn’t do everything again if get_plugins is called a second time in the same request.

PIPPIN: Right. For example, let’s say in the header of your site you call — to go off of your same example —

BRAD: Sure.

PIPPIN: You call get_plugins because you want to list all of the plugins that you run on this site for the public to view.

BRAD: Mm-hmm.

PIPPIN: It seems silly, but whatever, something like that. And then in the footer, you want to do the same thing. With the WP Object Cache, if you did not have persistent caching enabled, that second time it called get_plugins, it would pull from the cache from that request. But then if you reloaded the page, it would need to do it again.

BRAD: That’s right. Yep. Yeah, exactly. I guess the other thing we just should probably mention is Varnish, which is like the super trendy page, full-page caching server. For example, I have Varnish running in front of my Apache MySQL on DeliciousBrains.com. I just run Varnish in front of that, and I have it configured to serve stuff right out of the cache, right out of the page cache for most of the URLs, but not things like /myaccount or /checkout, and any request to those pages goes right through to Apache MySQL.

PIPPIN: Yeah.

BRAD: And that’s what you were saying earlier, right, Pippin? You prefer that kind of solution over using a plugin.

PIPPIN: Absolutely.

BRAD: Yeah.

PIPPIN: Absolutely.

BRAD: Varnish is crazy too because I’ve been —

PIPPIN: Varnish is insane.

BRAD: I’ve been hacked or — hacker newsed, I guess or, you know, listed on the front page of Hacker News this year, and Varnish just doesn’t even break a sweat. Like it just servers that blog post page like no problem.

PIPPIN: Has no problem whatsoever.

BRAD: No. And that’s —

PIPPIN: Varnish is used by a lot of — I think most or all of the managed WordPress hosts use Varnish.

BRAD: Yeah, yeah. They run —

PIPPIN: I know WP Engine does.

BRAD: They don’t usually run Apache MySQL like I’m doing, but, you know, I’m old school and I’m still learning about Nginx, so I haven’t gotten that far yet.

PIPPIN: Continuing on with the idea that all of this caching stuff is really server side details, I want to give an example. I feel like I know server side stuff reasonably well. I can set up a server. I could install a box. I could get all my stuff running. For the last three years, I have been the person that maintained and ran and set up a server for a company.

BRAD: Mm-hmm.

PIPPIN: And this is a company that’s been very, very successful, and they have a huge, highly traffic site. And I always thought I kind of knew what I was doing with things like setting up all the caching and different options.

We had a lot of server trouble. It was struggling a lot. Once a week or every other week or so, the server would go down because it just got hit too hard. Or it would just be super sluggish.

About three months ago, the company decided to hire a dedicated server guy part-time that really knew all of this inside and out, and on a server that has fewer resources than anything I ever worked on, he has made the site ten times faster and more reliable simply by knowing how to set up Varnish, how to set up Nginx, how to set up all of those different layers that you will never achieve with something like W3 Total Cache.

BRAD: Right.

PIPPIN: And so if that’s something that is important in terms of overall performance, and you really need to do it, investing in the resources, whether it’s a dedicated server person to do it or whatever. It is amazing. I’m just in awe of what this guy does.

BRAD: Right. I actually —

PIPPIN: I thought I knew what I was doing.

BRAD: I have a similar story. Actually, I hired someone off of Odesk to set me up on Amazon EC2 because I didn’t really know the Amazon stuff like it’s kind of its own thing, the Amazon way of doing things. And so I didn’t really know what I was doing there, so I got him to do it. And then I kind of just kind of reverse engineered what he had done to try to figure it out.

And I actually learned a lot that way. So that’s another way you can do it. Yeah, Odesk is a good place to find sys admins, I guess you would call them.

PIPPIN: Sure. Yeah.

BRAD: Anyways, we should probably —

PIPPIN: Pretty crazy stuff.

BRAD: It is crazy stuff. I love it. I love it. I love this stuff. Should we wrap up, I guess?

PIPPIN: Yeah, I think I was just going to throw one more thing out. There’s a lot of stuff that you need to take into account and consideration when you’re developing plugins that can be impacted by caching. I mean, just for example, ecommerce is huge when it comes to caching like problems with caching plugins and caching systems.

But there are a lot of different things that you can do, so if you have any questions about, oh, how do I resolve this kind of issue with a caching plugin, or how do I take this scenario into account, let us know. Post questions to the episode. More than happy to help out. It’s something that we both faced quite a bit.

BRAD: I’ve got a perfect tagline for caching. It’s damned if you do, damned if you don’t. Right?

PIPPIN: That’s pretty good. One other small note: Brad and I will both be speaking at WordCamp Miami, which I think has a couple of tickets left. They may have already sold out. But if you want to come by and say hi, WordCamp Miami is an awesome time. It’s a great place. It’s one of my favorite WordCamps, and it should be a good time.

BRAD: Yeah, I’m really looking forward to it. Can’t wait.

PIPPIN: Yeah, it’ll be great. Cool. Well, thanks, everyone, for listening, and catch you next time.

BRAD: Thanks, everybody.