We are showcasing this case study to give you a real taste of what can happen in everyday life. In the real world, things can get messed up. We want to help you deal with any issue like a pro!
And what a ride it has been! You might think that Windows will work just like any other web server.
Well, not the usual one!
Here are the initial test results for the site we worked on, abnfinest.co.uk:
Home page
Category page
Product page
It couldn’t get any worse than this, right? You would be amazed!
Now, let’s do the speed up process walkthrough!
First things first: check the debug profiling
We recommend to start with the debug profiling every time you feel the site is slow:
- check out slow modules (look at loading times)
- look at the admin area as well; you don’t want to end up with a slow back office
- look out for slow queries: if you spot anything above 100 ms it could mean you have database issues or there is a query somewhere that is not optimized
Optimizing PHP
There’s only so much you can do with PHP on Windows.
Since ABN Finest is running on Prestashop 1.6.1.9, we saw the opportunity of using PHP7.
The installation process is very straightforward, you just download it from here, add it to your Program Files and activate it from the IIS Manager.
You need to look for incompatibilities with installed modules. Turn on the mod dev and look for any warnings or errors.
Keep in mind that some store managers might not work on PHP7.
Using OPcache
Yes, you have to install the extension even if you are using PHP7. The opcode accelerator works ok on Windows.
User cache
Most of you might know it as the bottom section of the Performance tab.
First, we tried using APCu.
But, for it to work on IIS you have to limit the FastCGI maximum number of instances to 1.
FastCGI usually uses more than one process to deal with many visitors at the same time.
The tests revealed that limiting to only one instance would slow the site down considerably. Even with APCu running.
Very much unacceptable!
Second on the list: Memcache
Aside from the usual issues with Prestashop, in a lot of small to medium stores, it could slow down the site.
It did it for ABN Finest, and we had to drop this one too.
So no user cache then? Nope, the site is faster without them.
Cache module
We added a cache module to cut the server response to the bone. The non-checkout pages became 4-5 times faster.
People often ask us: I installed a cache module, but why can’t I see any improvements?
This might come as a surprise for you, but the cache module is not the answer to everything.
Most of you who are asking about it (I am looking at you right now), generally drop the homepage in Google PageSpeed Insights and see little to no improvement in scores.
The cache module is designed to give a faster response time and spectacular stability whenever there are a lot of visitors browsing the site.
That’s it.
Stop thinking that you will spend 100$ on a module and everything will be sunshine and rainbows!
You are on the right path; it just needs a little more effort!
The database
There were no significant issues with the database in this case.
We always make the following two tasks a part of the optimization process:
- mysqlcheck: to check and repair any errors
- mysqltuner: it’s a perl script that analyzes the database and offers advice on how to improve it (you will have to do the check for a few days)
Moving on from the server.
Frontend is the game
We talk about it a lot in our content, so we are just going to do a quick rundown:
- optimized the theme, modules and cms images
- manually minimized hardcoded JS scripts and CSS styles
- enabled gzip and added expiration dates
- on IIS there is no .htaccess or nginx.conf, you will have to edit an XML file called web.config
- we employed “async”-loading CSS
- loaded the external fonts locally
- moved all the CSS files before the JS ones
Tip: try to limit as much as possible the number of external scripts if you want a good front-end score.
CCC options
Very nice and straightforward, but how do we deal with the issues? With work!
Here are some common issues we encountered:
- CSS compression breaks the design because CSS rules are not paired accordingly
- moving JS to the bottom breaks scripts
- you can manually tag scripts that you don’t want at the bottom with
data-keepinline=“true”
- you can manually tag scripts that you don’t want at the bottom with
- HTML minimization breaks tracking scripts (ex.: removes CDATA tags from Tag Manager)
CDN
We usually recommend CDNs to those who have their visitors spread across the world.
On Prestashop, it’s useful because you can create up to three media servers to point at the CDN. And it’s ideal for serving cookieless content.
An average browser can load around 5 – 8 elements at the same time. If your site uses three sources, then it would be almost 3x faster.
Your pages will feel a lot snappier in the browser (you’ll know it when you’ll see it in action).
The one good thing built in IIS – OCSP stapling
What’ s this? A method that speeds up the https delivery.
Read more about it here.
We all know how the SSL drags the loading times down. OCSP takes the edge off.
For all of you Apache lovers out there, keep in mind that it’s only compatible with versions newer than 2.3.3
The final results
Home page
Category page
Product page
In your face IIS!
And one more thing …
Some of you using IIS might notice a slower server response time across all pages. It’s a delay of about one second.
If your site is already slow, it might not make a difference, but if you’ve done everything right this bug might keep you sleepless for a couple of nights.
So, if you are running into this issue, leave us a comment below, and we’ll give you the answer.
|
Listen to the audio transcription of this article
 |
