Put simply, Varnish is a “reverse proxy” – a piece of software that goes between the main server and the client. Basically what it does is caches content, so PHP (or whatever backend you’re using) doesn’t need to run for every single request – this makes perfect sense with static content. For sites like WordPress, filled with mostly static content, Varnish will work out of the box (minor configuration changes are required for small things).

Using Varnish with mixed-static and dynamic content is a little harder, though. Recently, we were hired to optimize a client’s website. This particular website was written on a particularly horribly-written framework (it looked like some proprietary framework – not something I want to dissect and analyze for performance). For an example of how awful this framework was, it took about 10 seconds (yes, seconds) for the server to render the index page. After doing as much optimization as possible without dissecting, I was able to cut the time down to about 2 seconds.

2 seconds is still an eternity.

So, I decided to use Varnish. With a big caveat: it only caches content if you aren’t logged in. Since the framework I was working with was intent on setting the PHPSESSID cookie on every page load, I couldn’t just tell Varnish to cache when that cookie was present. Instead, when the user logs in, a LOGIN cookie is set, and Varnish uses this cookie to determine whether to cache the content or not. Logged-in users still have the awful user experience of having to wait 2 seconds for each page to load, but at least people who are just coming to look around have a decent experience.

Here are the relevant sections of the VCL file that enables this logic: