Prestashop Speed Optimization – How to make it insanely fast!

We are not going to list the benefits of a faster website because you probably know them.

Let’s dive right in, starting with the basic settings.

Prestashop Performance Options

CCC (Combine, Compress and Cache)

These options are, simply put, awesome! You have all of your CSS on a single line of code. Same goes for JS and HTML.

This way the size of the files is smaller, and every web page loads faster.

It’s one of the first things we noticed on Prestashop, and it’s one of the first reasons we fell in love with it.

Pay attention when moving JavaScript at the bottom!

It’s arguably the best place for it, but you should check that everything is working smooth after checking this option.

We encountered an issue with the Google Dynamic Retargeting script. It stopped working after moving inline JS at the bottom of the page.

Enough drama, let’s do a test!

Here are the scores for a regular product page. (Don’t worry about these awful numbers! We will work on improving them as we go through this article.)

Test scoreWithout CCCWith CCC
GTmetrix PageSpeed8294
GTmetrix Yslow9074
Google Pagespeed Mobile6466
Google Pagespeed Desktop7173
Pingdom Score8686

But, wait! Does this mean that the website is actually slower with CCC? Well, it could be.

It’s great that you have all the CSS/JS/HTML on single lines, but this is putting a strain on the server.

The page will be snappier, but it will take the server a little more to respond.

The best way to do the minimization is on the server side. Google had an excellent service called PageSpeed that was shut down in August 2015.

You can still install their modules on your server, though. Both Apache and Nginx plugins will do the job!

If you don’t feel 100% confident, you can try one of these alternatives provided on the KeyCDN blog.

Hanging on to the Prestashop CCC won’t be the end of the world.
We will find ways to avoid the possible loading issue.

Also useful

  • use Rijndael with mcrypt (it’s faster)
  • don’t waste time on PHP accelerators like Xcache or APC (not to be confused with APCu); you can use OPcache to speed up the PHP delivery

What not to do (Don’t sabotage yourself!)

  • do not activate the built-in filesystem cache
    • even though it might seem a good idea at first, the website will become slower as it adds more pages to the cache
  • do not use Prestashop stats modules
    • they fill up your database quite fast
    • you should rely on Google Analytics to do the stats for you
      • make sure you have a module that integrates the e-commerce data
  • don’t use too many files from external sources (fonts, CSS/JS files)
    • you don’t have control over them, and Prestashop can’t include them in the minify engine
  • don’t use too many external tracking scripts
    • if you want to hit 100/100 in Pagespeed test scores (from Google, GTmetrix or whatever), you will have to download every external script locally; even Google Analytics
      • even though Google does not recommend it, here is a way to update it every 12 hours
      • a unique alternative is a service called Segment; it connects all kinds of different tracking services in one place (all of your external scripts will be gone, the Segment API will send data to all of them)

Remember to check the speed indicators for every major page type (category, products, CMS, etc.). Most likely the listings and product pages receive the highest amount of traffic. These are key to not annoy your visitors.

Cache module

How important is a cache module?

Let’s take a look at this LoadImpact test for a Prestashop site without a cache module.

*simulating up to 25 users at the same time

Wow! The homepage loading time hasn’t dropped below four seconds 🙂

At least there was no downtime.

If the website had been on a shared hosting plan or even on a low-performance VPS, it would have crashed before reaching 25 users.

Here is how it looks with an active page cache module.

MAJOR difference! The loading time is way down under one second. Closer to 500 ms with 50 concurrent users present.

And the best part of it is that your server load will be almost non-existent. Serving cached pages to users requires minimal resources.

Here are three good options for Prestashop cache:

Try to stay away from the free modules. Caching is not something you want to save money on.

Advanced Tip: Warming up the cache

For the cache to be active on an individual page, someone has to visit it first.
That first person will not have the chance to experience the fast loading version.

It wouldn’t be the end of the world, but every visitor counts.
We are stating the following whenever we can get a chance: your primary goal is figuring out how to serve the customer better.

So, how can we serve the cached version right from the get go? We have to visit it ourselves. Well, not quite.

We create a cron job to simulate a visit to each page. The best time to do it is during the night when the traffic is at the lowest level.

First of all, you need a list of all the URLs of your site. What better one than the actual sitemap. We are using this module to do it for us.

Secondly, you need a bash script that goes through every page.
Here is the code we are using:


wget --quiet https://$URL/1_en_1_sitemap.xml --no-cache --output-document - | egrep -o "http(s?):\/\/$URL[^] \"\(\)\]*" | while read line; do
    time curl -A 'Cache Warmer' -s -L $line > /dev/null 2>&1
    echo $line

If you have more than one sitemap, make sure to include them in this script.

Last of all, you have to set up the cron jobs.
Here is the order:

  1. clear the cache from your module
  2. regenerate the sitemap
  3. run the cache warmer

You can run the first two from the Prestashop “Cron tasks manager” module if it’s easier for you.

The third step is one that will take some time. We recommend to do it at the server level.

We have this line in our crontab list:

45 02 * * * bash /home/admin/

Every night at 2:45 am we are running our script.

A server configuration from the future

Most people think that the bigger the server, the faster the website will be.

It’s a trap.

Whoever is telling you that, is either inexperienced or wants you to pay more for a server you don’t need.

So if not the size, then what? Yuuuup, the configuration.

Not your everyday database

We are not going to get into very technical details, just a few good to know practices.

Using Percona Server or MariaDB instead of the standard MySQL (now owned by Oracle) could bring better results.

Both are improved forks of MySQL, designed for better scalability, and both of them are using an enhanced storage engine called XtraDB.

We recommend this piece by Ian McGuinness if you want to dig deeper into the Percona vs. MariaDB vs. MySQL comparison.

Database optimization

If you are using a MyISAM database, the main tweak your database needs is the query cache.

Caching the queries is a good way to relieve some pressure of the server for Prestashop websites.

All you need to do is to add these three lines to my.cnf file and to restart the MySQL service.

Here are the most common settings:

query_cache_size = 134217728
query_cache_limit = 1048576
query_cache_type = 1

We have allocated 128MB of memory for the MySQL query cache with a query limit of 1MB.

If it seems too complicated, ask the hosting provider to help you.
It shouldn’t take more than 5 minutes.

You will notice the speed differences right away.

For InnoDB databases, the buffer pool size is the most important setting.

The best way to tweak the settings for any storage engine, is to use a simple tool like mysqltuner to obtain suggestions and apply them to your database.

You have to be very careful not to break anything, but you already know that.

Using Memcache or Redis

Think of Memcache as an extra layer between the website and its database.

Memcache (short for memory cache) stores data and objects in the server’s RAM memory.

This way you relieve a lot of pressure from the database.

Redis is a good alternative to Memcache. Some consider it a more powerful caching engine.

It’s a little bit more difficult to set up on Prestashop. Most likely you will need a custom module to be able to integrate it.

A more lightweight solution for user cache is APCu (not to be confused with APC). A bit tricky to install sometimes, but a solid solution for single-server sites.

Useful tips:

  • pay attention to the ps_connections table (it tends to fill up rapidly)
  • using a separate server/VPS for your MySQL could be a good idea if you have high amounts of traffic
  • optimize the database from time to time using the free Database Cleaner module (be careful not to delete your orders or catalog data)

The web server

The two most popular ones are Apache and Nginx.

Justin Ellingwood of DigitalOcean gives us some technical insight on them.

He recommends using both at the same time. This way you make use of Nginx speed and avoid its limitations using Apache.

We are seeing significant Prestashop improvements when moving from Apache to Nginx. The two of them seem to go along great!

The PHP version – Why does it matter?

Well, it’s important because of security and speed.

If you are reading this article, you are most likely interested in speed.
We bet security is not a bad thing to have either!

Old versions of PHP do not support newer functions your site might need, they are buggy and terribly slow.

You might enjoy reading this guy’s story to get some more insight and a short laugh.

What are the good PHP versions?

5.5 and 5.6 are very solid. Anything older than that will become obsolete shortly.

The new Magento (2.0) has dropped support for PHP versions lower than 5.5.22.

We guess Prestashop will soon follow.

The newest PHP (7) is supposed to be a be a breakthrough regarding speed.
It’s very much faster than any of the old versions.

But, to take advantage of its full capability, web apps should make use of its new functionalities.

Most open source platforms like WordPress, Prestashop, Magento, whatever are built for the older PHPs.

For great things to happen, every web app should improve their code for PHP 7.

A great alternative from Facebook

Yep, you read it right!

Facebook is not just a place to keep in touch with your friends; they also create open-source software.

As you might know, Facebook uses PHP (among others) as a programming language.

Being one of the most visited websites in the world, it needed a faster PHP. One that can serve more requests at once without using insane amounts of CPUs.

So they built HHVM (stands for Hip-Hop Virtual Machine).

Fundamentally, it takes PHP code and turns it into machine code.

The performance of Prestashop on HHVM is excellent. You can see for yourself in our test results at the end of the article.

HHVM is fast and can serve a lot of requests accurately, but it needs memory. So, if you have only 1GB of RAM on your host, you might consider increasing that.

The great thing is that you can always have PHP set up as a backup in case something happens.

Advanced trick: use a script that restarts the HHVM process each time it consumes a lot of memory.

Here is an example code to do it when it’s using more than 35% of RAM on a Ubuntu server:


used=$(expr $(free | grep "\-\/+" | sed -r 's/[^0-9]+/\t/g' | cut -f2) \* 100 / $(top -n 1 -b | grep "KiB Mem:" | sed -r 's/[^0-9]+/\t/g' | cut -f2))

if [ $used -gt $percentAllowed ]
        service hhvm restart

Varnish accelerator

Varnish is an amazing web application accelerator!

What makes it extremely fast is using the actual RAM memory for storing the HTML cache.

What we like most about it, is that Varnish seems to figure out on its own where are the most viewed pages on the website. Those are the ones that are the fastest.
It somehow prioritizes the most demanded content and makes it insanely fast.

Although it’s designed to work best for applications with a huge number of requests, it could work for small to medium websites.

But, Varnish brings the most value on high-traffic websites.

The main downside is that it’s not that easy to set up. Especially on Prestashop.

Since it transforms elements into static pieces, you have to be very careful not to cache dynamic objects on the page such as carts, wish lists, account blocks, checkout pages and so on.

Setting it up by yourself or using a managed service

At Canonicalized, we are huge Cloud Hosting fans. Simply because it’s easier to scale.

Also, you only pay for what you use. If there is one thing we hate more than wasting time, it’s wasting money.

So here are our recommended options.

DigitalOcean, Vultr or Linode for the more tech savvy

  • you can set everything up by yourself
  • from our point of view, they are very well priced
  • they are superbly scalable


  • it is a managed service that uses the big cloud hosting providers, just setting up everything for you
  • their stack is: Nginx, Varnish, Apache, Memcached, MySQL
  • you have an easy to use interface from where you can start/stop services, clear varnish cache, etc.
  • you can deploy your app within a few clicks (WordPress, Prestashop, Magento, Drupal, Joomla, etc.)
  • the downside is that you can’t mess around with the server config, which in some cases might not be that bad 🙂

We can say that these are the best fit for Prestashop from what we have encountered so far.

And as a bonus, they don’t empty your pockets as fast as other traditional services.

We are not listing any more hosting providers.

The point is to create a bigger picture of how to optimize the server and the Prestashop platform, not to compare hosting services.

Quick wins that provide great value

Setting up a CDN

  • it’s especially valuable for websites with visitors spread all across the world
  • the usual file types that should be on a CDN are images, videos, CSS, and JS (the largest files)
  • Amazon CloudFront is free in the first year of use; you can give it a try

Gzip and browser cache

Small fixes like gzip and expires headers are crucial for Google. PrestaShop usually provides this out of the box.

Some caching modules provide the browser cache functionality out of the box (see PageCache by JPresta).

Switch to an advanced layered nav module

Stores that use a lot of product filters will become slower as they grow.

There are some alternatives out there including the Ajax Filter by Presto Changeo. The advanced filtering systems are admirable because they are smarter at indexing product attributes.

Image optimization without losing quality

This is an oldie but goldie. Applicable for all kinds of websites.

Prestashop generates compressed product images out of the box, so there is not a lot of need to hustle on this.

But, theme images are often not optimized.

You might say that you don’t want to compress these images because you want your site to look crappy.

What if there is a way to compress images without losing any quality?

That’s what lossless compression is for. Free apps like ImageOptim (for Mac) or FileOptimizer (for Windows) are stunning at making image file sizes smaller.

If you’re into SaaS or if you feel these tools overloading your computer, is an impressive service.

As you can see in this comparison, can sometimes be better than it’s alternatives.

From what we have tested, ImageOptim knocks it out of the park most of the time.

The myth of non-blocking CSS

We are going a little bit beyond the basics here.

So what would be the benefit?

Well, loading CSS “asynchronously” could be useful because the actual HTML content starts loading earlier than usual.

Found a solution from the amazing Keith Clark on how to do it without using Javascript.

As an alternative, there is a pure JS solution available on Github.

I like Keith’s way better because it’s so smart! But, there are issues with some Android versions (older than 4.4). So it’s probably safer to use the JS way.

Here is a comparison video of three ways of loading CSS: plain old CSS (minified in the head section), “Async” only (through JS or Keith’s way) and inline CSS used for above the fold content + “Async” the rest of the CSS:

As you can see, the “Async” only version is the first one to start loading, but it’s the slowest overall.

Also, using the “Async” only version would lead to the “Prioritize visible content” error in Google Pagespeed insights. Google notices that the above the fold content doesn’t load the CSS right away.

To overcome this issue, you will have to take out the CSS used for the above the fold content and place it inline. It’s also called “critical CSS”.

The way that Google recommends it is to inline the critical CSS in the head of your pages and the rest of it through the loadCSS function.

It is the fastest one in our test, too.

There are several tools to help find the critical CSS quickly. For the entry-level people, there is this free tool that will do the job properly.

For the more experienced of you who might need real-time updates, there are two plugins (first and second) that can be used with Grunt or Gulp.

This is pretty much the only way to overcome the “Optimize CSS Delivery” warning in Google Pagespeed Insights. And possibly to get up to 100/100 on this test.

Some might argue that it’s a waste of time trying to get the Pagespeed score up to 100.

Well, every website is different, and every website owner is different. Blindly following Google’s guidelines may not always be the best thing to do.

But, if you have the time, and it doesn’t cause problems for your website or even slowing it down on several devices then you should go for it.

Download fonts locally

There is a nifty tool called localfont.

Update: localfont is no longer working, so we created a similar tool for you right here on Canonicalized. Speed ON friends!

You choose your preferred Google fonts, and you download them locally.

You also get the CSS declarations you need for this.

So instead of connecting to Google each time a page is loaded, you load them straight from your CSS.

2% jump in Google Pagespeed score just with this small tweak:

Here is a video tutorial on how to do it

Testing the performance of each tweak

We have performed these tests on an average Prestashop website with around 1000 active products and 50 categories.

Tested withPageSpeed DesktopPageSpeed MobilePingdom scoreGTmetrix PageSpeedGTmetrix YSlow
Common server7865669077
Optimized server8072849077
+ CCC8876879588
+ Cache module8977989493
+ The quick wins1001009997100
Tested withPageSpeed DesktopPageSpeed MobilePingdom scoreGTmetrix PageSpeedGTmetrix YSlow
Common server7863878978
Optimized server8374868879
+ CCC8882879391
+ Cache module9183969394
+ The quick wins1001009795100
Tested withPingdom timeLocal curlWPT first viewWPT repeat view
Common server5.73.351613.7
Optimized server2.60.74575.2
+ CCC2.370.34.33.3
+ Cache module1.
+ The quick wins1.20.1732.5
Tested withPingdom timeLocal curlWPT first viewWPT repeat view
Common server32.2108.6
Optimized server2.
+ CCC1.50.3643.1
+ Cache module1.
+ The quick wins0.

Case study: 3.5X Faster Prestashop website

The best way to learn is by doing. So we got our hands dirty and did a speed optimization for a real-life Prestashop site.

Not everything runs perfectly in the day-to-day life, so adapting to real situations is crucial for success.

Read about what we did, what were the results and what did the client say by accessing the link below.

How we improved the speed of by 3.5X

[Extra Case Study]

Optimized on IIS – Take that Bill Gates!

View Comments (43)

  • Thanks for writing this article. Finding good information on how to optimize Prestashop is hard.

    Question: What do you mean when you write "do not activate the built-in filesystem cache". Which built-in filesystem cache are you referring to? The [Smarty Cache -> File System] OR [Caching -> Use Cache: Yes -> Filesystem] in the bottom of the Prestashop Performance page in the Backoffice?

    Question 2: What is the ultimate performance setup according to you? I recently successfully activated PHP7 with OPcache on my Prestashop store and got great speed improvements, but I still can't hit that magic under 200ms server response time. Do I need a caching module or is it no point since I'm using the latest and greatest caching technology OPcache?

    Question 3: Is memcache obsolete if you are using OPcache?

    • Hey John,

      Thank you for appreciation! The lack of detailed information on Prestashop speed improvements is what led us to write this article.

      Your questions:
      1. Try to stay away from any filesystem cache that Prestashop provides. The Smarty Cache is sometimes useful, but you have to test it a lot to figure out if it has a negative or a positive impact.
      Usually, it will slow down the website.

      2. The ultimate stack for us right now is Nginx, Percona DB, HHVM, Memcache/Redis and maybe Varnish cache (if you can set it up so that it wouldn't cache the dynamic blocks).

      I try to stay away from PHP 7 for now because Prestashop is not coded to make use of its full potential at the moment. So HHVM is currently faster.

      You definitely need a caching module if you are targeting that response time. Prestashop will not be able to reach the maximum speed without Varnish or a caching module.

      3. OPcache is a code accelerator for PHP. Memcache is an entirely different thing. It acts as a buffer between the site and the database.

      Memcache serves cached queried data so that your MySQL won't be accessed each and every time a visitor does something on the website. It's very useful if your Prestashop is serving thousands of page views each day (or more).

    • Hey John,

      Thank you for appreciation! The lack of detailed information on Prestashop speed improvements is what led us to write this article.

      Your questions:
      1. Try to stay away from any filesystem cache that Prestashop provides. The Smarty Cache is sometimes useful, but you have to test it a lot to figure out if it has a negative or a positive impact.
      Usually, it will slow down the website.

      2. The ultimate stack for us right now is Nginx, Percona DB, HHVM, Memcache/Redis and maybe Varnish cache (if you can set it up so that it wouldn't cache the dynamic blocks).

      I try to stay away from PHP 7 for now because Prestashop is not coded to make use of its full potential at the moment. HHVM is currently faster.

      You definitely need a caching module if you are targeting that response time. Prestashop will not be able to reach the maximum speed without Varnish or a caching module.

      3. OPcache is a code accelerator for PHP. Memcache is an entirely different thing. It acts as a buffer between the site and the database.

      Memcache serves cached queried data so that your MySQL won't be accessed each and every time a visitor does something on the website. It's very useful if your Prestashop is serving thousands of page views each day (or more).

      • First off, thank you for the quick and elaborate answer. I really appreciate it.

        I'm using Siteground with their "GoGeek" top-tier shared server package as my host. They are using Nginx with Apache, MySQL and offers PHP7 with opcache as an alternative to older PHP versions. They have their own "Supercacher" which offers three levels of caching:

        1. Static caching (proprietary tech?)
        2. Dynamic caching (proprietary tech?) - does not support Prestashop
        3. Memcached

        They offer HHVM, but only on 4x more expensive "Cloud" accounts.

        They also let you use Google's PageSpeed module (mod_pagespeed) as an alternative, but when I tried that I had problems with adding new attributes/combinations in Prestashop.

        What would you recommend as the ultimate stack for what I have available for use?

        Also, in Prestashop's Performance page, what is the difference between:
        - Memcached via PHP::Memcache
        - Memcached via PHP::Memcached

        My host just calls it "Memcached". I've tried activating "Memcached via PHP::Memcached" in Prestashop but it didn't give me any significant speed boost but instead gave me problems with images when adding new products in the Prestashop backoffice.

        • Hey John,

          I am not familiar with the Siteground caching software, so I am not able to offer you any advice on that.
          What I can say is that a caching module for Prestashop will help. We dedicated a whole section to it in our article.

          HHVM doesn't seem like a must-have for you right now, mainly because it eats up a lot of the server's RAM memory.

          All that I can say is that you will need a cloud server at some point in time. Not necessarily from Siteground (take a look at our suggestions).
          When the traffic starts adding up, your server will demand more memory.

          It's probably the reason you are having difficulties with Memcache too. For a medium traffic Prestashop website, Memcache will need around 1 or 2 GB of RAM memory to run smoothly.

          mod_pagespeed is not an alternative to HHVM or Memcache. It's a discontinued service from Google to do the JS and CSS minimization at the server level.

          Lastly, let me explain the Memcache confusion. Memcached is the actual server module (or daemon) that is doing the object caching.

          In the Prestashop performance options, you see the available PHP options used to communicate with this daemon. They are quite similar.
          The PHP Memcached has a few more options than the PHP Memcache, but it's pretty hard to notice a significant difference.

          From what I figured out about your current hosting package, I would stay away from Memcache for now.

          If you are ready to move to a cloud server, but you don't have all the technical skills, I suggest you give Cloudways a shot. Remember that you will need at leat 2GB of RAM to see any difference at all.

          Keep in mind that Prestashop is not a presentation website or a blog. It's a complex eCommerce platform. It needs resources.

          All the best to you!

          • Thank you so much for the information. I'll probably invest in the JPresta Page Cache module and also try out Cloudflare CDN since my store will be targeted to more than one continent.

            By the way, do you know of any good way to find a front-end developer for Prestashop? I have a couple things (besides maximum performance) I want to have fixed/made before I launch my store.

            Again, thank you. I'll definitely follow your blog closely from now on.

          • The JPresta module is a good choice. We are using it ourselves whenever we get the chance.

            If you need help with Prestashop development, drop us an email through our contact page or use the live chat from the right side.
            We can offer a quote if you provide us the details.

            Thank you for your appreciation! We can only hope that we will manage to find the time to produce the most useful content possible.

  • 100/100 page speed score is irrelevant if your page(s) still load slowly. In your images you've got the site load time down to around 2 seconds - well you might call that fast but I certainly don't, sure it's faster than its other open source competitors [woocommerce, magento etc] (I assume) but being the best / fastest of a bad bunch is not the same as being the best or fast.

    Every platform currently available is terrible when it comes to performance, none of what you have done to speed things up should ever need to be done in the first place if the -original- developers/maintainers had a clue about performance and why it matters.

    • Hey Alex,

      We appreciate your thoughts!

      We agree that 100% scores are somewhat irrelevant. If you read the article carefully, you'll notice that we are pretty much on the same page on this. We even mentioned the WP Rocket article that pisses all over Google's scoring algorithm.
      But you won't be able to score 100/100 if your server response is slow. So not completely irrelevant !?

      "Best of the bunch" and "fastest" are definitely subjective definitions.
      I am going to point you again to the article.
      We are not stating anywhere that Prestashop is faster than Magento or Woocommerce. We just took the average Prestashop website and optimized everything we could think of.

      This article is not about comparing platforms! It's about helping people with speed issues improve their Prestashop performance.

      Could we have done more? Very possible!
      Would the results be considerably better? Doubt it!

      Also, the two seconds loading time in Webpagetest might not seem like a big deal. It's hard always to have consistent scores on this kind of tools.
      But if you check the curl time, it's 0.2 - 0.3 seconds. Now we would call that fast. And for a platform like Prestashop, we could even call it insanely fast!

      We agree that open-source platforms can sometimes be bloated. But this happened only because they are trying to satisfy a lot of feature requests.

      People want everything: features, speed and for it to be free.
      I know it's difficult to accept that every platform can become slow at some point. It's difficult to put in all the work we talked about in the article.

      Well, tough shit! The fact is that it happened! So are you going to do something about it, or are you going to complain in the comments?

      And one more thing ...
      I don't know how much of our content you have processed until now. But if you have, you would notice that we are not in the business of assuming anything.
      We are in the business of doing and testing stuff out!

      • Your curl time is ttfb (time to first byte) which is another meaningless metric as anyone can "fake" this by flushing early.

        Regarding your comment "Are you going to do something about it" - we already did. We built an ecommerce platform that does a complete page load in less than 750ms (30ms ttfb [but as mentioned this is meaningless]) with far more search accuracy, scalability and performance than everything you've mentioned in your article combined.

        • We're glad you are a doer! We need a lot more people like you!
          As far as the discussion goes, we are going to stop here, because we feel we have covered everything in the previous comment.
          Congrats on you platform! It sounds like something amazing!

  • Great write-up! I love how you guys actually try it out yourself and not speak in theory.

    I am doing a fresh Prestashop V1.7 install. Do you suggest we do your setup with PHP7? Would we run into a compatibility issue? Because in your 'Optimizing Prestashop on IIS' case study you mentioned, "Since ABN Finest is running on Prestashop, we saw the opportunity of using PHP7." Is it coded for PHP7 now?

    • Hey,

      Thanks for the love!

      We will always test stuff out! Hoping other people will start doing more of that too.
      We take a lot of things for granted nowadays, which makes us vulnerable.

      Prestashop 1.7 should work with PHP7. As a matter of fact, I just did a test, and it looks good:

      We performed our speed tests on a 1GB RAM memory server from Digitalocean. But if you want stuff like HHVM and Varnish, we would probably start with a 2GB - 4GB VPS.
      It depends a lot on how heavy the store will be (products, modules, features, etc.)

      • Boom! Canonicalized at it again with validating with test! :) There's a reason why your articles comes up on top in Google. Well-written content with data and case studies to validate it. Shows how knowledgeable you are.

        What are your thoughts on adding Cloudflare into your ultimate stack for security?

        • A. We don't feel a huge amount of comfort security wise when CloudFlare is in the mix. If your site has vulnerabilities, CloudFlare won't save the day

          B. There are appropriate stacks for every need. I think it depends on your skills and situation. We recommended that configuration to John because we felt it was right for him.

          Since you don't have a website right now, we don't have any specific ideas for you aside from the content.
          We try to keep it up to date as much as we can

          C. Already dropped it. I think you will have to do your tests to see :)

          • Check out this discussion:


            - "HHVM and PHP7 do the same thing. You can only use one or the other. If
            you use HHVM site won't load because of the eval's used throughout
            the code."

            - "If you use memcached it will slow your site to a crawl, that system has
            been broken in PrestaShop for years. Redis, there is a plugin, but there
            is only so much object caching you can do with a plugin. Varnish is not
            needed, especially if you are running nginx over top of apache, its
            your reverse proxy at that point."

            - "I would go with nginx, php7, maria, with opcache. Maybe use cloudflare
            for dns hosting, that is all. If you run that stack you can run http/2
            without using a custom config openssl library."

            - "Don't run server side minification, its an old technology, its not used
            any more, look at mod_pagespeed, they discontinued it. It ate up too
            many resources and slowed servers down to where it was pointless"

            Would love to hear your thoughts on what Dh42 (Prestashop Mod) had to comment about it.

        • Sorry for blocking your latest comment! We felt it doesn't bring value to our community, but confusion. We are trying to keep the information as clean as possible on the site.
          We don't want to share any opinions about discussions happening on the Prestashop forum. If we would want to be involved, we would post our answers there.
          Our last and final advice for you, is to focus more on doing. There's simply no other way of learning!

  • Very nice article, i just wondering about cache and cdn, is there any trouble like double caching problem?
    PHP 7.1
    - opcache
    - apcu
    - express cache module by xtendify
    - cdn by keycdn

    • Hey Dos, I don't think you'll have caching problems. PHP 7.1 will crush the site though. Prestashop is compatible with the latest 7.0

      • yes you right, I've tried cache and cdn no problem with that. I tried PHP 7.1.6 too and looks like no error, I use it on my live site. the only problem is APCu cache, always problem with the backend. I thought caching is just for frontend. any idea why APCu doens't works well with backend?

        • Yes, that happens quite frequently. Prestashop has some compatibilllity issues with APCu.
          You could fix them by hacking into the APC class, but the changes won't stick if you update the platform

  • Hello, I really liked the article, but I have one question:

    Can the methods mentioned here in this article be used also on Prestashop 1.7?

    • Hey Toni,
      Most optimization are aplicable to 1.7.
      Not only that, but a lot of these ideas can be used on other platforms as well

  • I was having trouble with random products taking a long time to load and then the website showed the 404 page. A simple solution after many months of frustration seems to have been disabling the Prestashop Smarty cache system and then clearing out the Smarty Cache folder. Now I need a proper caching module... Thanks for the great tips!

  • I found a great module named "Delivery Automation QR-code Module" on PrestaShop Addons which increase my werahause work speed using QR-codes.

  • Hello, I'm part of PrestaShop Core team.

    Can you help us to document how to get a performant shop in production in the official documentation?

    For instance, we are interested by the varnish configuration we may share publicly in the PrestaShop repository: don't you think?

    Are you available to talk about it?

    You can mail me at mickael[dot]andrieu[at]prestashop[dot]com.


  • hi

    can you help me to solve my problem in blocking time.
    My site has blocking time in waterfall and in too bad, how I can undrestand what is my problem?

  • Hello ,
    Thanks for the amazing work !

    i tried to execute the script to warming up the cache , it executed in "0 second" and nothing appear to be cached up
    the xml file is available and contained more than 2000 urls
    Any idea ?


  • Clap, Clap, Clap... great Article, a long time without an article.
    I had not read an article so professional and so good and without trying to sell anything, just provide me with very good technical information, which is so difficult to find beyond GitHub.

    Thank you Canonicalized.

  • Hello. A very good and complete article.
    Some doubts... If you use pagespeed, why are you going to use Prestashop's CCC capabilities? pagespeed applies gzip, and compression of CSS and Javascripts... so?

Related Post

This website uses cookies.