Magento site speed is an extremely important factor for your business. It is a ranking factor and a factor that influences bounce rates and conversions, as well as users’ intentions to visit the site in the future.
Website performance factors
To succeed in making your Magento store faster, you can use several methods, which can be divided into three general categories:
- Server upgrade
- Code optimization
- Caching
Each of these variants has its pros and cons.
Server upgrade can boost a site’s performance in no time while relatively small costs are required. In reality in some cases the results will be less impressive than you expect. Usually, it is connected with some messy extensions; their performance suffers from code issues, not of the server resources.
I’ve met shops, where code issues lead to checkout failure every other time, whereas 3072M were allocated for the memory_limit [sic]. In this case server upgrade won’t help the situation at all, maybe it’ll only postpone checkout failure for a few seconds.
Code optimization can really help some fundamental issues, but usually its costs can be rather significant. Of course, we aren’t talking about a trivial problem or bug here.
Various caching methods will certainly accelerate many operations, also providing multiple acceleration for requesting static pages. Or even dynamic ones as long as ‘hole punch’ support is used. This technology is called ESI block, dynamic blocks, etc.
I will develop the caching topic in this article and do hope this information will be helpful for store owners.
Magento cache types
One can single out several Magento caching types:
- MySQL query cache
- PHP opcode cache
- Magento cache
- application-side full page cache
- server-side full page cache
Now we’ll run through each of the caching types.
MySQL query cache
This Magento caching type saves results of the database query executions. MySQL query cache can improve certain apps performance, where reading data prevails over adding or updating it. You can meet lots of recommendations for using this cache type and even increasing its size. From my experience, this tactic may negatively influence database performance on many modern configurations. The thing is, MySQL query cache poorly scales on multicore architectures and leads to slow query execution. You can learn more details on possible issues here.
PHP opcode cache
We have already mentioned this Magento cache type in one of our previous articles. As of today, the most popular tools here are APC, Xcache, Zend Opcache, and eAccelerator. If you are using PHP 5.5.x, I recommend stick to Zend Opcache; if you use PHP 5.3/5.4, it’s better to go for APC 3.1.13. Note: forget about previous APC versions, because they had lots of bugs and performance issues.
Using PHP opcode cache lets you reduce the time PHP interpreter needs to perform file search, reading, and conversion to opcode, which is executed by the PHP interpreter directly.
The one point you should remember about is flushing opcode cache after changing server code. To do that, just reboot Apache web server (if you use mod_php) or Fast CGI manager. Another variant is to use specific scripts for managing opcode cache condition. To control APC, use apc.php script from the APC distribution kit. It also should be noted that there are cases, when PHP opcode cache application is useless; among these are using sphp, cgi, or cli. Why? Opcode cache generation is executed on start, but in these modes the interpreter ends the task after the query is processed, and the cache state is lost.
Magento cache
This Magento cache type contains configuration processing results (meaning assembling fragmented xml files into one file), assembling layouts, HTML blocks, etc. This caching system allows to avoid repetitive operations upon condition that you didn’t change anything influencing these cache parts.
We recommend using Magento cache in all cases except for staging projects or developer hosts so that you avoid irrelevant cache display while coding.
Application-side full page cache
This cache type is different from Magento cache because it contains the entire page HTML code. It gives even more boost for query processing and shows the result to the user without generating the page.
Using full page cache can give you impressive results, around several dozens of milliseconds per query. It’s important to know the difference between query processing time and page loading time, as the latter can be significantly bigger and also depends on page design, JS/CSS/image volume, and other files.
This method is good for static pages caching, but you may face difficulties with dynamic content. For example, the shopping cart page must change when items are added, deleted or changed. Also, as the user is browsing through the shop, the ‘recently viewed’ block content should change. If your cache solution processes these cases incorrectly, you’ll see irrelevant page data, which is, of course, unwanted.
To solve this, cache tools with dynamic block support were designed. They put a special marker into the page HTML code, which is later on replaced by the relevant dynamic block content.
Thus, application-side full page cache is perfect in terms of data relevancy and minimal server load balance.
If you see that full page cache is the solution you need for your Magento store, feel free to have a look at our Full Page Cache extension.
Server-side full page cache
Here is the difference from application-side FPC: server-side FPC caches HTML code on the server, which Magento passes the query processing results to. I feel it’s important to point out that, in this case, the server has Magento integration to track cache relevancy and control dynamic blocks.
The most famous guy from this family is Varnish, which works with various integration modules, e.g. Nexcess Turpentine. If there are no dynamic blocks updating, the query is fully processed by Varnish, not bothering Magento itself. For instance, this scheme is used for CMS pages. Now, if the page contains dynamic blocks, then Varnish requests Magento to get the relevant dynamic block content, or the block will be replaced with AJAX code, which will be requesting the necessary content from the browser’s side.
Here the query processing speed depends on the integration module performance. In other words, you can have better results with application-side FPC than with the server-side one, if you choose certain integration modules. See the results of the Varnish on Nexcess Turpentine test here.
Finally, is Full Page Cache going to help me?
Here’s the fact you should know: FPC boosts the process of HTML code generation for the page which is requested and which the cache is enabled for. In other words, ‘time to first byte’ is reduced.
However, full page cache can’t boost server connection process, sending response to a client stage and page sources loading (JS, CSS, pictures, fonts), and least of all loading data from third-party servers as Facebook, Google Plus, and Twitter. The latter are often a reason for low pages performance. Thus, if you decide to place social media widgets or buttons on your Magento store, always keep in mind that they may influence overall site’s performance as well.
If you want to see the difference that can be brought to your store by FPC, you need to measure ‘time to first byte’ for your pages. Use webpagetest.org for that. Go to the tool, enter your page URL, choose the Test Location and choose Native Connection (No Traffic Shaping) variant for Connection option. If your site is secured by HTTP authorization, go to Auth tab and fill in the necessary info. Now, press START TEST. It should look like this:
After the test has been completed, you’ll see the results page:
To get the ‘time to first byte’ number, go to Waterfall for First View and look for the request that works with page HTML code generation. For our example it’s the first request of the waterfall. It may be different for your test, if you have example.com → www.example.com or http://example.com → https://example.com redirects.
We can see that the full request time is 135 milliseconds, and ‘time to first byte’ is 89 milliseconds. The full page loading time is 1.212 seconds. Let’s suppose that FPC gives the result in 14 milliseconds, then we will have request processing time reduced by 75 milliseconds, but the big picture of the general page loading time will slightly change; the improvements will be around 7% of speed.
Why doesn’t Amasty FPC work with Varnish?
We have heard this question many times. Well… These are different sides of the same coin. Do you really need to see heads and tails both at the same time? Hey, it is hardly possible to imagine why you would need that.
FPC and Varnish are two different tools that basically do the same, so you have to choose only one, and the decision is yours. Our part is to design a tool that helps your business and is made with care and expertise to deliver the best results.
What we are saying here: don’t even attempt to use Amasty FPC and Varnish on the same Magento installation simultaneously, as you’ll get more harm than good. The same goes for using several various FPC types on the same Magento installation simultaneously – this idea is as bad as the previous one.
Now, that’s a wrap for today. Would love to answer any questions on the subject!
