Prestashop Speed Optimization

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!

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!

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.

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.

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.

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.

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.

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.

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.

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 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

Cloudways

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.

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

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.

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 more experienced of you who might need real-time updates.

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.~~

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

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.