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.
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.)
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.
- 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
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.
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:
#!/bin/bash URL='yoursite.com' 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 done
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:
- clear the cache from your module
- regenerate the sitemap
- 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/warmcache.sh
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.
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.
- 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:
#!/bin/bash percentAllowed=35 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 ] then service hhvm restart fi
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 Could Hosting fans. Simply because it’s easily scalable.
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?
If you’re into SaaS or if you feel these tools overloading your computer, Kraken.io is an impressive service.
As you can see in this comparison, Kraken.io 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.
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.
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.
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.
[Extra Case Study]
Listen to the audio transcription of this article