We have been working more and more on optimising e-commerce platforms, and over the last two or three years we have noticed a trend that used to be limited to the big brands: there finally seems to be a widespread concern with website performance.
For us, performance has been a battle for many years and, honestly, we never understood why it took so long to get the attention it deserves. Part of the reason may lie in the evolution of the market itself. Today, with platforms such as Squarespace or Shopify, it is relatively simple to launch a website with a professional design, and it has become harder for brands to stand out by looks alone.
When a visually appealing presence is easy to achieve, other factors start to carry weight. Loading speed, navigation experience, stability and the ability to handle traffic peaks have become elements that matter.
It was precisely at this point that a case came to us that shows the other side of the coin and illustrates how the pursuit of more performance can create serious problems.
We were contacted by a brand, which we can consider mid-sized, that had started receiving unusual complaints. Some logged-in customers were seeing information that did not belong to them: the names of other customers, carts with unexpected products and, in some cases, data related to purchases in progress.
We tried to run a quick diagnosis and find out whether this had ever happened before. The answer was no. We also asked whether the platform had recently been updated, and again we were told it had not.
Until one detail caught our attention: the website seemed to be routed through Cloudflare. We asked, and we were told it had been a recent change made by the person in charge of IT to deal with a spike of bots that had left the site out of action for a while. We instantly knew what we were dealing with. We had just never seen this problem happen so severely.
The scenario we found is more common than people think, but it is rare for it to reach this scale without being detected. To respond to the bot attack and try to speed the site up immediately, a global cache rule had been enabled on Cloudflare for the whole domain.
In practice, Cloudflare was doing exactly what it had been asked to do: store every response it received from the origin. The problem is that some of those responses contained personalised information.
The flow was similar to this:
There was no need to change anything on the website or redesign the infrastructure. We kept Cloudflare because the problem was confined to the caching strategy.
To fix it we implemented two simple measures:
The first measure was to replace the generic rule with more specific ones. We started checking for authentication and session cookies before allowing Cloudflare to serve content from its cache.
The logic we applied was similar to the following:
(http.request.uri.path matches "^/loja/.*" and (http.cookie contains "PHPSESSID" or http.cookie contains "client_session"))
Whenever those cookies were present, the request was sent straight to the server.
This way, anonymous visitors kept benefiting from the Cloudflare cache, while logged-in users started receiving content generated in real time.
We do not like to rely exclusively on rules configured in CDN dashboards, so we also adjusted the HTTP headers sent by our client's own server.
For public content, such as articles, institutional pages or a catalogue without personalisation, we used directives such as:
Cache-Control: public, max-age=3600, s-maxage=86400
For checkout, customer areas and other session-dependent pages, we set:
Cache-Control: private, no-cache, no-store, must-revalidate
This way, any intermediate proxy now receives clear instructions about what it can and cannot store. If they switch from Cloudflare to another provider tomorrow, this problem should not come back.
This case is a good example of how a change made with the right goal can end up creating a complex problem. A legitimate concern about the site suffering from a spike of bots led to a problem that could have had serious consequences for the brand.
We are not against caching content, quite the opposite. In many projects it is one of the best ways to gain performance, but it is important to understand what can be cached. A product page can be the same for thousands of visitors, whereas the cart, the customer account or a checkout cannot.
Can be cached
Must never be cached
That is why we firmly believe that, before making changes of this kind, the configuration should be reviewed by a team with experience in infrastructure, performance and security. Often, small changes to the way the CDN is configured are enough to solve a performance problem, but it is important to first understand the impact those changes may have.
In this case we were able to keep Cloudflare and the performance benefits we were after, without compromising the experience or the security of the users.
Want a review of your shop's configuration?
Do you know the difference between these two techniques that are part of a solid SEO strategy?
In 2026, BEC (Business Email Compromise) scams and highly sophisticated identity thefts have reached surgical levels of execution. Modern cybercriminals no longer just attempt to crash networks.
