Home About Blog

If I go live with the default Varnish VCL, what benefits do I get for my website?

#1

When I create my section.io application with Varnish selected as a proxy, what does Varnish provide out of the box before I add my own config?

#2

It depends.

Since Varnish has very safe defaults, a lot of the time, nothing will be cached.

That’s because in HTTP, cookies indicate that there’s some personalized activity taking place. Because your cookies are included in the HTTP request, varnish cannot be certain that the request can be shared across users. So, it defaults to a case that says: "This HTTP request has cookies, and that means something special to the server that I don't understand. We expect that the server is going to send some content unique to the user, so let's not even try to cache it".

Server side cookies

This happens a lot because a lot of web application frameworks overzealously set session cookies. For example, with PHP, Java, ASP.Net web development frameworks, the server is configured by default to immediately create a user session and send the session cookie.

That’s ok for HTML documents sometimes, and it is a very safe default that means the programmer doesn’t need to think about when to start and stop server-side sessions. However, then the next HTTP requests for static files like JavaScript, CSS and images also contain the cookie. Varnish cannot determine that these files are shareable/cacheable so all these requests bypass the cache as well.

Client side cookies

Also, there are many JavaScript frameworks that set cookies. For example. Google Analytics sets cookies on your users that are included on every HTTP request. These cookies are irrelevant to the server, but because they pass through Varnish no caching occurs by default

A few solutions

  1. Write VCL to strip the cookies out of requests.
  2. Change your application to issue session cookies when they are needed
  3. Control your cookie scope

Some legacy issues

Before HTTP/2 it was common to use cookie-free domains to minimize request size. These domains like images.site.com were popular and tried to control the cookie scope so that images would transfer faster.

Now, with HTTP/2 we want everything to be on the same domain to leverage HTTP/2’s multiplexing capabilities.