What version of OpenCart do you use?

VoteShow Results

OpenCart Optimization Tips

Justin V. | Sunday, 16 October 2011

I recently stumbled on a post about optimizing a site for a sudden spike of traffic. Try as I might, I can't find it to link to it here. However, it got me thinking about optimizing this site a bit. It's often just little things that can be adding the milliseconds to your page load time, and low hanging fruit is something I find very tasty. While my results aren't necessarily much to boast about, here is what I found:


To test where the waiting time was coming from, I started with Firebug. YSlow showed me a few issues, such as a large number of CSS and JS includes on my pages, no CSS sprites, and no Content Delivery Network (CDN). However, I wasn't about to sprite all my images, and I also wasn't about to pull all my CSS and JS into a single file each. These kinda need to be separate as they are mainly different libraries like jQuery and jQueryUI. Pulling them all into one is too much effort for now, so I stayed away from that.

One thing I did discover, was that my assets were being returned much more quickly than the requested page. This is no great achievement, all it means is that I didn't have ridiculously large images. Good to know, but next I needed to figure out why the page was rendering so slowly. I figured it was probably something to do with DB queries, so I headed over to the PHP to check it out. I started by running a bunch of microtime() calls in index.php, to segment the setup and actual execution of the controller being called. I found that the setup of all the classes and config was the smaller portion of the time cost. The call to the controller itself was slow. Still no surprises.

I had a look at the controller being called. I was testing on my home page, so it was the common/home controller. This is a fairly simple file. It doesn't do much other than set the page title and meta description, call in its children (modules, etc), and render its template. I only have the slideshow module, latest products, and SeoTags modules running on my homepage, and I could already pretty much see the extent of the damage done by the slideshow module, so I looked closer at the code of the other two. I added caching to the SeoTags module, which didn't change much. It shaved a few millis off the time. It was the latest products module that gave me the best gain. I added caching to the getProduct function in the catalog/product model, and immediately - with only 6 products being pulled in to my home page - improved page speed by 50%. That's impressive.


I am not sure if OpenCart has neglected caching somewhat in recent versions, or if there's a method to the way it's happening, but there are many DB queries that simply do not cache at all. Adding caching to DB queries was the first low hanging fruit I discovered, and it gave me great results. On product pages, the getProduct function caching saved me about 66% of my page load time, cutting it down from around 600ms to 200ms. It is important to make sure the cache files are deleted at the right time - ie: when a review is added, a product updated, etc - but I think it is worth caching anywhere possible. Particularly with shared hosts, where DBs are a common bottleneck, caching may just give you some great performance improvements.

Caching may not be ideal if you have a large inventory. The OpenCart caching mechanism stores DB queries as files, meaning each unique query is a new file on your webserver. HostJars has less than 30 products, and won't be hitting 50 any time soon. We also don't have any distinct customer groups and only support a single language and store. This means we will have at most 30 cached product query files, which won't get out of hand. If we had thousands of products, multi store or language and many customer groups, I'd think twice about caching. After thinking twice, I'd probably still do it!.

Anything else?

The next thing I think would be helpful, would be caching at the module level. Caching a whole module, rather than executing its controller and rendering it each time would be a reasonable saving, particularly on pages with many modules enabled. OpenCart doesn't support caching of whole controller outputs as easily as DB queries, so this change may require a little more effort in the meantime. I think it may yield significant improvements.

If you've made any performance gains on your OpenCart store, with these or other methods, I'd be keen to hear about them. Just leave a comment below.


Test test test :) This is a test comment

I made a small shop in my website www.dejangroup.ir and tried your comments.
Opencart Developer

You can also use this script. http://www.opencart.com/index.php?route=extension/extension/info&token=25212c929aebd68f736332c55833fb93&extension_id=24742

I am unable to cycle images in slideshow,using default slideshow,after switching to last image ,slidebar cycle go to first image in reverse direction fastly,but i want to make it like- after getting last image it should go directly to first image.

Great article! However, real store speed can't be reached without both optimization and critical pages caching (PHP is slow by its own). I have created OpenCart Lightning extension that optimizes and caches the store from top to bottom. Many people that used Nitro and IPS say Lightning makes real difference. Here is demo site with 20000 products - http://demo.devs.mx/lightning/ BTW, its free to try - http://lightning.devs.mx/

The biggest difference we've found is either disabling, or caching, the count of products that are in each category. It's fairly simple using opencart's inbuilt cache. Here's a write up with cut-and-paste code to insert: http://octurbo.com/caching-opencarts-category-counts/ Also, while it can be something of a crutch if you don't address other issues, a page cache offers not just better response times, but offloads a ton of processing for people that are viewing the site without being logged in (or having something in the cart, etc). It needs an admin interface, but we have a basic page cache put together that performs very well. Open source: http://octurbo.com/a-page-cache-for-opencart/

I use Total Import Pro and I import 15000 products today. Now I am waiting my web site to be good. Image caching gets it very very slow, I am not sure I live that problem always or any other ways for more images in DATA folder. I am not sure problem is because of caching images?? I really can not my web site now. On my VPS, all other web site is ok and fast. But this one is not good now. I just wait, but really do not know waiting for what?? :) Can you advice me?

You don't quite explain how you implemented caching. Be good to get a step by step guide.
Justin V.

Wow nice, that's an impressive saving. I'm not sure if URLs are limited to 255 characters though, the RFC and this stack overflow page indicate otherwise: http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url. However, I'd say you weren't using SEO keywords very well if you came up with a URL in OpenCart longer than 255, so it's a reasonable restriction. Nice work, I'll keep an eye on that in future.

Some good ideas there - working on a few Something I've just done that has decrease latency quite alot was alter the url_alias database slightly so I could add an index. Originally `query` and `keyword` were varchar(255) - index keys cannot be more that 1000 bytes, but ((255*3)*2) = 1530 - so I couldn;t put a relational index on these. Seeing as `keyword` is part of the URL, and a URL has a maximum length of 255 char, it seems stupid having it set to varchar(255) - especially seeing as this will prevent an index. So I now have: `query` = varchar(50) `keyword` varchar(100) and this has enabled me to put an index on [`query`,`keyword`] knocking a good second off my latency.
Justin V.

Hi OpenCartFan, This is a great idea. These pages should be searchable as well as product pages. This is not a simple change though, it requires changes on multiple levels in OpenCart. First you need to change the search query to include also the information and other pages, then you need to change the display pages to show them in a meaningful way. You'll have products (with pictures and prices) mixed with info pages (no pictures or prices), so these will need to be displayed some way clever. We're looking at adding this functionality to our Search improved module because we'd like to make our blog posts searchable on this site.

I have 1.5.1 installed, and the search option only uses product input. I want the search option to search threw catagorie/description product/description and information pages. Is there a simple change in the code to make this possible ?. How to do that. I hope you can help me !. Thanks !

Caching to file is better than nothing, but it's not great. Using things like memcache, or APC/xcache (in single-instance environments) are much faster, and remove the 'age management' overhead that you need to handle when using file-based caching.
Justin V.

Thanks, I appreciate your thoughts. It seems that disk usage is a small cost these days, so the trade-off between disk usage and processing time is weighted towards optimizing time. It wasn't that long ago that I held the assumption that DBs were faster than disk. I am constantly finding my sites bottlenecked by queries.

I feel like this is a decent article. I feel like caching is a balancing act between disk usage and processing time. One of the big issues is deciding what needs to be cached on a page. For example, if you have a product page with a review banner at the top that displays a different user's comment and rating on that product each time the page is loaded, you know you can't cache the whole page entirely. Caching parts of a page is fairly ideal since you're not using your DBMS as much for getting information that doesn't change on a regular basis. And like you said, when that information changes, the cache has to be updated. Anyway I hope I didn't rehash it in this comment, but I found it to be a neat article.

Write a comment

Your Name:

Your Comment: Note: HTML is not translated!

Enter the code in the box below

Phone Us: (408) 675-5884

Powered By OpenCart
HostJars © 2018