How to configure the Performance page of PrestaShop 1.7

As you all know, the performance of your online store directly influences your conversion rate, so it is essential to make the right choices when configuring your PrestaShop store.

So I'm going to present you what I think is the best possible configuration for your online store.

Access to the configuration

To be able to set these performance elements for your online store, you just have to connect to your management space (backoffice) then click on the menu Advanced Settings >> Performances

Smarty cache management

PrestaShop integrates solutions to cache elements of the store and avoid having to recalculate the information at each visit and thus reduce the time of data processing to display them.

To summarize the idea, PrestaShop takes the code to be processed, generates a file that will be called afterwards without having to do its processing.

These are called static files and are less resource-intensive, leaving your hosting server free to do other tasks.

For those who do not know Smarty, it is what is called a template engine. It allows you to perform processing and display of data in the context of a development allowing to separate the generation of data to be processed from their display.

When your store is in production, it is preferable to do everything to increase the use of these static files and therefore we will obviously choose to block the generation of cache files for templates even if they are modified.

It is obvious that we prefer to leave the possibility of generating a new cache for the templates when the store is under development or when you want to apply changes to its design.

The cache is well activated and we will remember to keep the refresh of the cache when we update a data of the store like a product or a category.

The other settings are more technical and only concern big stores hosted on several different servers and therefore would require an in-depth analysis of the code and its usage, basically, those who need to change these settings won't need my article to know how to do it.

Debug mode

This section will allow you to identify the origin of a problem on your PrestaShop store and to correct it.

I have been offering for several years a tutorial to learn how to activate PrestaShop debug mode in order to fix the problems encountered and version 1.7 allows you to do it simply from the backoffice without having to go into the code of the files via FTP.

Nevertheless, it is always essential to know the manual procedure to intervene if the Performance page itself is no longer accessible due to a problem.

So, activating the debug mode is a recurring action for any store in development.

The other two parameters are only functional if the debug mode is activated, it's quite strange that there is no link between these fields to know this and above all, you won't find this information anywhere.

The deactivation of third-party modules makes it possible to quickly determine whether the problem is due to a new module that has been installed or to an incompatibility between several modules.

Disabling overloads allows you to know where to look if the error message disappears after enabling this option, because all overloads are stored on your hosting in /overrides.

Disable features

This section is a strange section in this backoffice configuration space since it allows you to disable native features present on PrestaShop.

Personally, I never touch it, because all these features make PrestaShop a complete tool to create an ecommerce store.

CCC (Concatenation, Compression and Caching)

This part is very important in the performance configuration on PrestaShop.

When your store is in production, you should logically leave all these options active.

A nuance can be made on this point.

Reducing the code and placing it in a single CSS or JS file consumes resources, and the advent of the HTTP/2 protocol to replace HTTP/1 means that the concern that existed with that protocol has disappeared about loading multiple files in parallel.

Apache optimizations in .htaccess are essential in all cases, but smartCache should be tested and analyzed to see if it is appropriate to enable them, because in rare cases it may be better not to enable them. But remember that if you have decided to use a CDN for media, you will need to enable smartCache options.

In any case, if your site is experiencing display or performance issues when the smartCache is active, it is a sign that your site has a problem that needs to be corrected.

Media servers

As previously announced, this option only works when the smartCache options are enabled.

Here, you will be able to configure domains or subdomains to call your static files as I talk about setting up a CDN on PrestaShop.

The old technique of subdomains to distribute static files does not seem to me to be adapted any more nowadays with the HTTP/2 protocol since it was mainly used to load more files in parallel and not to be limited by its hosting.

So either you go through a CDN like Cloudflare which will directly replace your host's DNS manager, or you go through a CDN on third party domains as presented in my article quoted above, this situation is still present, as it allows to integrate two different CDN methods.

Beware of the CDN proposed by your host

There are hosting companies that integrate CDNs to their hosting offer, like OVH offers on its shared offers.

I can't advise you enough to do a lot of tests, because in some cases it can block the changes made in your database. There are many testimonies on the official PrestaShop forum where disabling the OVH CDN option has corrected all the problems of using the store.

Server cache

The only configuration that must be used for the server cache option proposed by PrestaShop is to disable this option.

It never worked No matter what server cache system you use, it causes other customers' shopping carts to go back up, wrong customer accounts to be accessed, shopping carts to be modified without reason, and so on.

This option has never worked and to this day I have never seen any changes to make it work properly.

Conclusion

The configuration options on this page are essential and should be applied on any store in production to at least start wondering if the problem might be the type of hosting used.

I would never advise using any module to provide additional caching solutions, but rather the optimization of modules and templates, because if you apply this configuration and your store still has a performance issue, it may come from poor quality and badly developed modules or templates.