The Essential Varnish
Is your site slow? Understand how Varnish speeds up loading, learn about data privacy precautions, and discover the diagnostic work required for your project.
Sur cette page6 sections
You open your website to show a project to a client, and the page takes a while to appear. You first think of your connection. Then you try again on another phone, and the result remains the same. When you know your site, you usually wait a bit. The person discovering it doesn't necessarily have that patience.
The reflex is then to want more powerful hosting or a tool supposed to speed everything up. Varnish can be part of the answer, but not just because its name appears in a list of high-performance technologies. Its benefit is more specific: avoiding repeating certain processes when several visitors request the same public content.
The goal isn't to make you choose a caching software. It's to understand what can be accelerated, what must remain calculated for each person, and how to check that the site still works correctly after modifications.
This operation is useful: you modify a service in your admin area, and the site knows how to present it. But if several people consult this service without it having changed, the server can find itself manufacturing a very similar response several times.
Varnish sits in front of the application and can keep a public response to reuse it. This is what is called an HTTP cache. If the available response matches the request and remains usable according to the defined rules, it can be served without asking the application to rebuild everything. Otherwise, the request is passed on.
Imagine a project page that presents the same photos and text to all visitors. It can be beneficial to prepare this response once and then reuse it. There is, however, no reason to treat a client area like this public page. That is the whole difference between setting up a cache and correctly deciding what it is allowed to keep.
The Varnish documentation presents the rules that drive this operation. You don't need to learn their configuration language to use your site, but someone must understand them to operate it.
But a page can respond quickly and still be painful to use. Oversized photos, scripts that delay display, or a layout that shifts during loading don't disappear just because Varnish responded to the request. The visitor's phone and connection also matter.
That's why I advise you to start by measuring the problem. Are you waiting for the server's first response, the images loading, or the moment you can actually use the page? These are different waits, which aren't always corrected in the same place.
If server resources are insufficient, if a database query is abnormally costly, or if an image is several megabytes, these issues must be examined. Adding a cache doesn't exempt you from understanding why the site is working poorly. The documentation on Varnish performance also details the constraints of its own operation.
For the visitor, the expected result remains simple: access information, browse your services, and contact you without unnecessary waiting. The article on Core Web Vitals and site speed provides a complete perspective beyond the server cache.
The work therefore consists of identifying these journeys and protecting them. We don't disable precautions on sessions and cookies just to show a better cache hit rate. The documentation on caching conditions explains in particular the role of cookies and response headers.
A page can also mix public and personal information. Techniques exist to separate certain parts, but it's not a general permission to cache the whole page. You have to understand what varies, test the rules, and know how the site behaves when this separation doesn't work as expected.
For you, this means that a test shouldn't be limited to opening the homepage. You must also check the functions your business depends on: sending a form, logging in, modifying a basket, opening a booking. Speeding up the storefront by breaking the ordering process would not be progress.
We can define a retention period and remove responses from the cache when the relevant content changes. Varnish documents several cache invalidation mechanisms. The choice depends notably on how your site publishes its content and links its pages.
An added project might, for example, modify its own page, the list of projects, and a block displaying the latest projects. You have to think about these dependencies. Clearing only the modified page isn't always enough; clearing everything at every change can also remove much of the cache's benefit.
Before considering the installation complete, I advise you to make a real test modification, then check the result as a visitor, without being logged into the admin. What you see with your account isn't necessarily what another person receives.
This possibility concerns the content and durations that have been planned. It doesn't mean that an order can be processed without the application or that the entire site will continue to function after any failure. Nor does it transform Varnish into complete protection against denial-of-service attacks, which seek to make a service unavailable by overloading it.
It remains necessary to monitor the infrastructure, maintain components, and prepare backups. The question of caching thus joins that of website maintenance: who checks the operation, who intervenes if responses become incorrect, and who adapts the rules as the site evolves?
From there, the work I offer consists of looking at the pages and journeys involved, measuring where the wait is, then choosing an appropriate fix. If a cache is relevant, we must define what it can keep, test the personal parts, and check that publications update responses correctly. Then, we compare the operation before and after, instead of just settling for the presence of a new tool.
This approach can lead to using Varnish, reviewing its configuration if it's already present, or correcting another problem as a priority. The technical choice must serve your site, not the other way around. An additional component also requires maintenance; if it doesn't bring a useful benefit, there's no reason to add it just for its name.
If you don't know why your site is slow or if you want to overhaul its operation before it bothers your clients, we can start by discussing it.
The reflex is then to want more powerful hosting or a tool supposed to speed everything up. Varnish can be part of the answer, but not just because its name appears in a list of high-performance technologies. Its benefit is more specific: avoiding repeating certain processes when several visitors request the same public content.
The goal isn't to make you choose a caching software. It's to understand what can be accelerated, what must remain calculated for each person, and how to check that the site still works correctly after modifications.
Why does your server repeat the same work?
When a visitor opens a page, the site may need to retrieve information, compose the content, and prepare the response that the browser will display. On a manageable site, the page isn't necessarily a finished file sent as is.This operation is useful: you modify a service in your admin area, and the site knows how to present it. But if several people consult this service without it having changed, the server can find itself manufacturing a very similar response several times.
Varnish sits in front of the application and can keep a public response to reuse it. This is what is called an HTTP cache. If the available response matches the request and remains usable according to the defined rules, it can be served without asking the application to rebuild everything. Otherwise, the request is passed on.
Imagine a project page that presents the same photos and text to all visitors. It can be beneficial to prepare this response once and then reuse it. There is, however, no reason to treat a client area like this public page. That is the whole difference between setting up a cache and correctly deciding what it is allowed to keep.
The Varnish documentation presents the rules that drive this operation. You don't need to learn their configuration language to use your site, but someone must understand them to operate it.
Is this enough to make the site fast?
Not necessarily. If the wait mainly comes from the server preparing pages and these pages can be shared between visitors, a cache can reduce this work. It can also relieve the application when many people consult the same public content.But a page can respond quickly and still be painful to use. Oversized photos, scripts that delay display, or a layout that shifts during loading don't disappear just because Varnish responded to the request. The visitor's phone and connection also matter.
That's why I advise you to start by measuring the problem. Are you waiting for the server's first response, the images loading, or the moment you can actually use the page? These are different waits, which aren't always corrected in the same place.
If server resources are insufficient, if a database query is abnormally costly, or if an image is several megabytes, these issues must be examined. Adding a cache doesn't exempt you from understanding why the site is working poorly. The documentation on Varnish performance also details the constraints of its own operation.
For the visitor, the expected result remains simple: access information, browse your services, and contact you without unnecessary waiting. The article on Core Web Vitals and site speed provides a complete perspective beyond the server cache.
Your client's basket must not become the next one's
Not all site responses are public. A basket, an invoice, a booking area, or a page after login can depend on the person consulting. A bad cache rule can then cause more than just a display error: a response intended for one person could be given to another.The work therefore consists of identifying these journeys and protecting them. We don't disable precautions on sessions and cookies just to show a better cache hit rate. The documentation on caching conditions explains in particular the role of cookies and response headers.
A page can also mix public and personal information. Techniques exist to separate certain parts, but it's not a general permission to cache the whole page. You have to understand what varies, test the rules, and know how the site behaves when this separation doesn't work as expected.
For you, this means that a test shouldn't be limited to opening the homepage. You must also check the functions your business depends on: sending a form, logging in, modifying a basket, opening a booking. Speeding up the storefront by breaking the ordering process would not be progress.
And when you change a price or a service?
A cache keeps a response. You must therefore plan for what should happen when that response becomes old. Otherwise, you might correct information in your admin and find that a visitor still sees the previous version.We can define a retention period and remove responses from the cache when the relevant content changes. Varnish documents several cache invalidation mechanisms. The choice depends notably on how your site publishes its content and links its pages.
An added project might, for example, modify its own page, the list of projects, and a block displaying the latest projects. You have to think about these dependencies. Clearing only the modified page isn't always enough; clearing everything at every change can also remove much of the cache's benefit.
Before considering the installation complete, I advise you to make a real test modification, then check the result as a visitor, without being logged into the admin. What you see with your account isn't necessarily what another person receives.
A cache helps during an incident but doesn't replace security
Varnish can, depending on its configuration and the responses already available, temporarily serve an old version while the application responds poorly or is slow to rebuild content. The documentation calls this grace mode.This possibility concerns the content and durations that have been planned. It doesn't mean that an order can be processed without the application or that the entire site will continue to function after any failure. Nor does it transform Varnish into complete protection against denial-of-service attacks, which seek to make a service unavailable by overloading it.
It remains necessary to monitor the infrastructure, maintain components, and prepare backups. The question of caching thus joins that of website maintenance: who checks the operation, who intervenes if responses become incorrect, and who adapts the rules as the site evolves?
What I propose to look at with you
You don't need to come with a request to install Varnish. You can come with a much more concrete problem: pages take too long to open, the site slows down when you promote an offer, or some information doesn't seem to update.From there, the work I offer consists of looking at the pages and journeys involved, measuring where the wait is, then choosing an appropriate fix. If a cache is relevant, we must define what it can keep, test the personal parts, and check that publications update responses correctly. Then, we compare the operation before and after, instead of just settling for the presence of a new tool.
This approach can lead to using Varnish, reviewing its configuration if it's already present, or correcting another problem as a priority. The technical choice must serve your site, not the other way around. An additional component also requires maintenance; if it doesn't bring a useful benefit, there's no reason to add it just for its name.
If you don't know why your site is slow or if you want to overhaul its operation before it bothers your clients, we can start by discussing it.
