This post is not about code level performance. This post is about is how to make any platform appear fast. It doesn't matter what platform you have on the back-end, the way to make your site fast is to make sure users rarely actually hit it.

Step 1: Use the Browser Cache

For repeat visitors to your site, this is a must. Every page and asset on your site should have HTTP headers that will instruct the browser to keep that asset cached locally for some period of time. Even after the cache has expired the browser will be smart enough to only send a "do I need this yet?" request instead of fetching the whole asset again. Here is a good introduction to browser caching and CDNs, which is the next step. While you're at it, make sure you are using GZIP compression and HTTP Keep-Alive too. Here is an Apache specific article on Keep-Alive and Compression. For the Nginx people here's a Nginx tuning article that discusses Keep-Alive and Compression.

Keep in mind though that the browser cache only helps your repeat visitors. Hopefully you have those. There have been lots of studies on the impact of poor performance on visitors likelihood to keep browsing or shopping and you can't rely on them ever getting to a repeat page view if the performance of the first page view is terrible.

Step 2: Use a CDN

We've known for years that static content should be served from a separate, faster, more cacheable location. This technology is called a Content Distribution Network. There are many CDN providers out there but Akamai and Amazon CloudFront are the two I have experience using. CDNs have gotten very sophisticated in allowing you to cache dynamic content as well.

The way CDN's work is you configure an "origin" server and use DNS to point your website (or a subdomain) at the CDN. When a user requests your site, or an asset on your site, they are actually requesting it from a server on the CDNs network. That CDN server will then apply your caching rules and see if they already have a copy of the asset. If they have it already and it's not stale then they will serve it to the end user. If it is stale or they don't have it yet, the CDN server will request it from your origin server and cache it on the CDN as well as deliver it to your user.

The users that benefit are the 2nd and 3rd and so-on who get the asset directly from the CDN instead of having to go to your origin server. This approach is great for having international presences without having to have servers in data centers around the globe. But keep in mind it's only the NEXT visitor who benefits from your CDN. If your site is low-traffic, or if your caching rules specify short cache durations, you'll increase the number of hits to your origin server and reduce the effectiveness of your CDN. The responsiveness of your origin is the next step.

Step 3: Use a HTTP Proxy Cache

For the first time a user hits your site you can't rely on the browser cache or a CDN. But you might be able to benefit from a front-end proxy cache. I have used Varnish for this. You'll want to find a configuration that is specific to your platform and proxy cache. I usually roll my own custom configuration but here is a Varnish configuration for Drupal 7 provided by the wonderful folks at Four Kitchens. I have also heard of Nginx being used a proxy cache by itself but have not tried it.

The local cache acts similar to a CDN so it might seem redundant, but your CDN has hundreds of servers while your proxy cache will act as the cache for just your one site. You could skip the CDN for some content and rely on your local proxy cache, especially if your site is low-traffic or only gets traffic from one geographic region. Just like with the CDN you need to balance your cache-durations with the traffic you get. Even if most requests are not cached so your proxy just passes the request through to your back-end, the proxy will protect you (but not entirely) from surges in traffic to the same page on your site.

Step 4: Configure your Platform's Cache

Drupal has caching built in. Wordpress has several plugins for caching. If you are rolling your own site your framework probably has a caching mechanism. I know Laravel does. If not, you may want to roll your own as well. The slowest part of your site is going to be requests to the database or file i/o. So the goal of platform level cache is to avoid as many of these hits as you can.

Step 5: Website Performance is Front-End Performance

I'll write a whole separate post on page-structure at some point, but this post would not be complete without mentioning it. If your site is taking 3+ seconds to render your platform is probably less than 10% of that. Before you start fine-tuning your Drupal or Wordpress code to have fewer database requests, look at the front-end structure of your site using a tool like Webpagetest.

Lastly: Look at your Platform

Eventually, or maybe just for that first request, a user is going to get through all your caching and your site is going to have to wake up and generate a page. That too could be a series of posts by itself and is beyond the scope of this post. If your site is well-trafficked and you've gone through steps 1-3 it should be rare that someone makes it to this point. This doesn't mean you can not-worry about the performance of the platform at all, but it does mean you can worry about it a little less.

Caveats and Considerations

The more static your site is the more benefit you can get from caching. If you have a very dynamic site you may not be able to cache as aggressively as a content-rich site could.

User Authentication

You'll need to consider your content creators and other authenticated users. If you have user generated content they are going to need a way to view the content they submit or edit. User authentication will likely bust your cache allowing authenticated users to skip through the caching layers. That can be both beneficial and detrimental depending on how you configure your caching.

Propagating Site Updates

If you cache the assets on your site, such as CSS, JavaScript, and Images, for an aggressively long time then when you need to make changes to those files you'll need a mechanism for clearing or busting the caches. Clearing the CDN or Proxy is easy enough, but you're not going to have a way to clear your users' browser cache. Fortunately, browser caches are limited in size and act in a first-in-first-out way so it's unlikely to affect the masses. Your options here are to version your assets and rename them or keep the cache-time relatively small. I prefer the first option but it requires some forethought in your site design.

I have a newsletter...

Many of my posts end up in Digital Ambit's monthly newsletter. It is the best way to keep up with what Dagny and I are doing in the business world. I appreciate your support and will only send you things we think are valuable.