Granted I’m only a couple hundred miles away from my datacenter for this test, but I am loading a fairly typical page of content here in 128ms. That’s pretty sick. We’re talking a tenth of a second for a full page load.
::
Some people really dislike my thoughts (or enthusiasm?) on the controversial topic of improving website performance.
::
I run Varnish here on the site, with Nginx as the backend. I’ve written before about my overall setup, and how to improve site performance, so I won’t go into it here.
Here I want to cover a subtlety of putting varnish in front of nginx (or any other web server, really) with respect to redirects. Redirects occur when the client makes a request to the server that cannot (or should not) be served in the manner asked, e.g. asking for /resource instead of /resource/. The trailing slash matters, as those to URLs look the same to humans but are not the same to the web server.
Web servers such as Apache and Nginx handle this naturally by sending clients a redirect for the latter when you ask for the former, i.e. you ask for /resource, you get sent back a redirect (HTTP code 301 or 301) saying that you should be asking for /resource/.
Simple enough. This all happens transparently to the client, as the initial request, the redirect response, and the second request happen so quickly that most people don’t even notice the turnaround.
But things can get a bit weird when you have two web daemons fielding requests, like when you have Varnish in front of Nginx. The problem is that the two daemons have to be listening on different ports. Varnish and Nginx can’t both be on the same exact IP address and port combination (TCP/IP stacks don’t like that), so you have to perform some sort of networking trickery to get them to work.
One common way of doing it is to have Varnish listen out front on port 80, and to have Nginx listen in back on 8080, or 81, or whatever. Then you tell Varnish what port Nginx is on and everything works great.
Until someone asks for /resource.
When that happens, Varnish asks Nginx for the resource and gets a redirect, only the redirect isn’t to a usable URL — it’s to the backend URL. So instead of being sent to site.com/resource/ like you would be if Varnish weren’t there, you get sent to site.com:8080/resource/, which your users shouldn’t be able to connect to (you do have a firewall on your server, right?).
But there’s a simple solution.
TL;DR: Have Varnish listen on 1.2.3.4:80 (your external IP), and have Nginx listen on localhost:80. This way both daemons are convinced they’re authoritative, so when Nginx responds with redirects the won’t be mangled with some alternative port in the URL that external users can’t reach.
Here’s what the localhost config looks like in Nginx:
server {
listen localhost:80;
server_name localhost;
...
Now all your redirects should look as if Nginx is sitting in front, and you should be good to go. Hope this helps.
[ Note: Don't try to handle this in Varnish itself; this is a backend issue and should be handled by properly situating your daemons, not by rewrite hand-waving on the acceleration server. ]
::
More than ever, the speed of your website is now affecting its perceived quality, and this is true of both users and search engines. Using the techniques below you will be able to get the most from limited server resources, typically allowing you to handle millions of requests per day from a relatively small VPS.
Use a Faster Web Server
You may have just set up your site and be using its default web server (most likely Apache). Apache is great, but it’s usually bloated to the point of being rather slow. Consider moving to a web server like Nginx or LightHTTPD that focuses on speed and simplicity rather than being able to do anything and everything. This site uses Nginx.
Implement a Cloud Proxy Service
Services like CloudFlare (used here) sit in front of your site and proxy all sorts of content for you, such as CSS, JavaScript, and images. Not only do they serve these things really quickly, but they also serve them from the closest location to the user, so you’ll see much faster load times from across the globe. In addition, this tier can provide minification, script optimization (e.g. Google Analytics), security, and a number of other services. This site uses CloudFlare.
Use an HTTP Accelerator
One of the most massive improvements you can make to your site is putting an accelerator in front of your main web daemon. Caches serve content by storing responses as static files and serving them directly out of memory. As a result, they can often respond in mere milliseconds. This site uses Varnish for that role, which I highly recommend.
Ensure Your Content Caching Settings Are Solid
You need to make sure you’re telling users’ browsers to cache the content you’re serving, so that subsequent requests to your site won’t require them to pull the CSS, images, etc. again. This will improve your site experience enormously. Give your CSS and other long-term items a significant expiration time. I handle all of my settings through <code>nginx</code> configuration combined with CloudFlare’s optimizations.
Put Your Images in CSS
If you’re serious about getting your site to pop you’ll want to reduce the number of images that get requested when your site is pulled. One way to do that is to simply remove images; another is to place your core images into data URLs served by CSS. This way, when a visitor loads your CSS (only once), the main images are now in cache and will display instantly everywhere else on your page.
Use a Content Delivery Network (CDN)
This is a lot like using a cloud-based caching server in that some of your content is coming from a distributed content provider, but it’s different in that you don’t have to put anything between you and your users. Most people store their images here so that they’re served from very fast, locally-placed servers (e.g. Amazon). Keep in mind that Cloud Proxy services such as CloudFlare give much of the same advantage, so you may want to do one or the other. I switched from S3 to CloudFlare.
Get Off of Shared Hosting
If you’re still on a shared host, get off it. Anyone serious about speed should either be on a VPS or a dedicated server. I use Linode, which I have found to be nothing less than excellent over the years.
Reduce the Number of Requests Required
Fundamentally, the game is simple: reduce the number of requests required to serve your page, and make each response come back quickly. You should consider everything here, including how many DNS lookups will be required, how many external scripts are called, etc. Remove as much as you can from your pages; start from scratch and add only what you absolutely must include.
Test, Test, Test
As you start implementing the techniques above you’ll want to see how they affect your site’s performance. You can use the tools located here to do that.
Enjoy
Once you’ve done these steps you should be enjoying some serious performance improvements. My site went from loading in ~2 seconds to loading in approximately ~250ms using these techniques.
Finally, if you have any other techniques that should be added here, do let me know, and don’t hesitate to ping me with questions or ideas.
::