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 site 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 generally 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 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 is not to make you choose a caching software. It is to understand what can be accelerated, what must remain calculated for each person, and how to verify that the site still works correctly after modifications.
This operation is useful: you modify a service in your administration, and the site knows how to present it. But if several people consult this service without it having changed, the server may 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 to it.
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 do not disappear just because Varnish responded to the request. The visitor's phone and connection also matter.
This is why I advise you to start by measuring the problem. Are you waiting for the server's first response, the images to load, or the moment you can actually use the page? These are different waits, which are not 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 does not 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 server caching.
The work therefore consists of identifying these journeys and protecting them. We don't disable session and cookie precautions 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 this is not a general permission to cache the entire page. You need to understand what varies, test the rules, and know how the site behaves when this separation does not work as planned.
For you, this means a test should not 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 order processing 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. These dependencies must be considered. Clearing only the modified page is not always enough; clearing everything with 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 administration. What you see with your account is not necessarily what another person receives.
This possibility concerns the content and durations that have been planned. It does not mean that an order can be processed without the application, nor that the entire site will continue to function after any failure. It also does not 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 links back to site 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 propose 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 verify that publications correctly update the responses. 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 is 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 is 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 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 is not to make you choose a caching software. It is to understand what can be accelerated, what must remain calculated for each person, and how to verify 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 is not necessarily a finished file sent as is.This operation is useful: you modify a service in your administration, and the site knows how to present it. But if several people consult this service without it having changed, the server may 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 to it.
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. This 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 do not disappear just because Varnish responded to the request. The visitor's phone and connection also matter.
This is why I advise you to start by measuring the problem. Are you waiting for the server's first response, the images to load, or the moment you can actually use the page? These are different waits, which are not 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 does not 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 server caching.
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 session and cookie precautions 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 this is not a general permission to cache the entire page. You need to understand what varies, test the rules, and know how the site behaves when this separation does not work as planned.
For you, this means a test should not 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 order processing 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 administration 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. These dependencies must be considered. Clearing only the modified page is not always enough; clearing everything with 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 administration. What you see with your account is not necessarily what another person receives.
A cache helps during an incident but does not 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 does not mean that an order can be processed without the application, nor that the entire site will continue to function after any failure. It also does not 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 links back to site 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 certain information seems not to update.From there, the work I propose 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 verify that publications correctly update the responses. 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 is 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 is 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.
