OpenCart Community

I've recently been able to get back to trying to migrate to OpenCart. I started this project in the spring, but was short staffed during the summer so had to put everything on hold. My current store has been on Yahoo for 13 years now, and that's obviously not the place to be anymore. Anyway, I just wanted to post about some of the simple things that have made a HUGE difference in speed with OpenCart. I've got over 7,000 product pages and many categories.

I kicked up a CentOS 7 server on DigitalOcean for $5 a month. Nothing fancy, standard install. Apache 2.4.6 / MariaDB. 5.5.64 / PHP 5.4 with OpenCart 7
It's nice to have it on a small space, then open up a whole mess of pages at once to see what happens. Of course I'll move it to a bigger space once it goes live.

I use this to test page speed overall
https://developers.google.com/speed/pagespeed/insights/
Out of the box, the problem was clearly TTFB

First big gain was with Apache, you'll want to use it's compression by adding in this to the Apache config Second big gain was upgrading PHP to 7.2 which is probably because opcache is installed by default in 7.2 I have not tested PHP 5.4 with opcache, and so far everything seems to be good with 7.2 so I don't think I'll go back.

Next was changing the DNS to cloudflare to use their CDN. This didn't make a huge difference, but it was simple. I also like that they can do something if the site goes under attack.

I also changed the database tables from myisam to innodb and played around with some indexes. It helped a little.

Hope this helps someone else.

Try this one:
10 ways to speed up the Opencart 3 – website speed optimization
https://webocreation.com/blog/10-ways-t ... imization/

Thanks for the tips. A lot of that I already am doing or are actually built into Journal 3 (which I know is unpopular in this forum.) It seemed the best gains were from Apache compression and the PHP upgrade though, that really cut the TTFB down a lot. Other things have helped, but not by the same margins.

Well, Journal is not unpopular around here, but it's a commercial Theme,
and it's also the most stolen Extension as well. And it really makes no sense,
to support Crooks and Thiefs, that's why most honest People will not support
such Elements around here. Noboby should, because they don't deserve it,
they only come here, to take, but never give anything back anyway.

I paid for it. It's only $55. I hope you're not implying I'm a crook. I'm ok with being called crazy, but I'm not a criminal.

Well, I did NOT mean you, it was a 'global' statement only, trying to
explain, why Journal is NOT a matter of discussion on this Forum.
It's not even published in the OC Extension Section, why then should
anyone care about it here ...

Well, probably should care about it since it's one of the most popular extensions. Usually a good idea to listen to your customers. I mean imagine if it's functionality was part of the base code.

Well, if Journal would be built-in, among a few other popular Mods,
there would be no after-market for Themes and other Mods, it's as
easy as that ...

But OpenCart is not a Social Network, consisting out of a couple of Fellows,
trying to secure their place in heaven, but just another Business-Model, and
that's the reason, why free OC only comes as a 'basic' Construction.

And Journal is not only a Theme Extension, it's a widely different Software,
just using parts of the default OC Code. It's about 1'700 Files, with 54 MegaByte
of CUSTOM Code and Images, added to a Stock OC, containing about 4090 Files
in an OC 3, just to visualize, how much foreign Files are added.

Compared to just about 100 Files, used by a 'regular' fully equipped Custom
Theme, consisting out of a Theme Directory with about 3 main Subdirectories.
No wonder, most standard extensions won't work ...

Good Luck!
Ernie

I hear ya. As it currently is, the OC web site can't even feature nice web sites that use their code which should be simple. And I know how that goes, you get so trapped in looking at code you forget about what you're really doing. I just hope someone at the core code level breaks the daily cycle and wakes up to the core mission. I really believe OC could beat out Shopify if it got its head of out of the geek realm and stared at business for a while. Until then, coders will beat each other up around here which is a shame. Pissing contests are a waste of time. If everyone who works on OC could play nice together, it'd be unstoppable.

I just hope someone at the core code level breaks the daily cycle

Well, there is only one, who makes decisions... But everybody is free, to
do it in his/her own way, if one is willing and able to.
Good Luck!
Ernie

upgrading to mariadb 10+ will add more speed as wel.
run mysql tuner and optimze my.ini will do some good as well

Also running PHP-FPM is probably one of the biggest improvements I have seen. If not running PHP-FPM definitely look into it, speed increase is pretty significant when properly setup and compared to other PHP handlers.

So a few months and many orders into OC now, working well too! Thank you!
I recently installed redis although it really didn't do much for speed. I'm guessing that MariaDB was already working well, so redis didn't have much to do.
I am currently trying out Varnish. First I installed the open source version, but it didn't do anything out of the box probably because of the cookies OC sets. Then I stumbled into this extension and installed it on a little dev server earlier today - it reduced TTFB down to a quarter of the time!
https://www.opencart.com/index.php?rout ... n_id=38433
I'll experiment with it for a bit on the little dev server before moving it to production, but so far it's impressive.

there are 2 types of responses from your OC site:
1) static assets like css,js,images
2) dynamic html & data

to reduce response times:
overall:
1) get a faster webserver
2) get a faster network
3) get faster dns service
4) use http/2
5) use php 7
6) optimize your code and database
7) reduce external dependencies

for static assets:
1) reduce the amount of static assets needed
2) reduce their individual size
3) set proper browser caching headers
4) use a cdn to reduce latency (only on first time asset load)

for dynamic html & data:
1) reduce the html source send
2) use component internal caching (cachable components which are used to make up the html)
3) no external caching solution will work here, including cdn, in fact it will slow you down a little.

There is no external caching which can reduce your TTFB for dynamic content.
And since the browser will not know which static assets to get without having the dynamic content, in which they are referenced, first (unless you push static assets), that is the most important TTFB.

Sure, dynamic content can't be cached - but - crawlers and first time visit page loads aren't usually dynamic driven pages yet. You might want to give it a try, it's interesting. Currently doing load tests on the dev server as I type this.

crawlers and first time visit page loads aren't usually dynamic driven pages yet

Crawlers are irrelevant in this discussion and the rest is nonsense.

You are one strange dude. Glad you don't need care about googlebot or your new visitors. Humored that "this discussion" is all about you. Have a good day sir, this forum kills me.