Methods for decreasing the loading time of website?

What methods would I apply for decreasing the loading time of a website?

A page caching extension, optimise your images and website, better server, varnish etc etc. There's many possibility, maybe try looking deeper into what's wrong with your website first before spending time and money.

Firstly and foremost, OC needs static pagecache. This free one works great. Don't spend money: https://github.com/budgetneon/pagecache

If you need auto-clear pagecache on most object saves for that, like in a team "CI" environment, check this out: https://github.com/budgetneon/pagecache ... -109331235

Nextly, you should def tune the OC queries if on an older version (or maybe even new). Example is this blog article, specifically this comment (read the top part first) http://bloke.org/php/opencart-is-slow-w ... mment-3993

Now, should prob turn off heavy queries such as the category product count found in store settings. You can further annihilate it via this http://www.opencart.com/index.php?route ... n_id=10999

Then, tune your db dependent on your traffic. This is beyond the scope of a post, but look to /etc/my.cnf and read about how to tweak mysql caches, buffers, and RAM limits before using disk. It can help a bunch in big, heavy, or high traffic instances.

Followed by tuning up apache a bit. If you use cPanel, turn on piped logging to prevent httpd restarts. If you use anything, turn on keep-alive, adjust sockets/servers to handle your request/traffic load.

After all that is ironed out, you can squeeze more if you have access. Try things like running PHP via FastCGI using apache FPM handler. Or running apache with a different or more modern MPM like event. Try redis cache, especially for sessions if you arent on an SSD server [note: memcache store limit is too small]. Try xcache or zend opcache [not APC] for better parse level bypasses.

As a bonus, you can add things like a CDN...a good free one is Cloudflare.

Anyways, good luck!

The first thing to think about is, do you have the knowledge to attempt any of this yourself? Realise that messing up the database in ANY way will cause serious loss of data that may not be recoverable or may cost you even more than just getting someone in who knows what they are doing to begin with...

I would look at a few key things:

1. database table optimization
This is especially vital if you are running OpenCart 1.x, the tables are not optimized correctly and need indexes and other tweaks to speed them up.
We have an auto-tuning script which makes this effortless: https://webdesires.co.uk/opencart-plugins/

2. Is the server capable?
One of the most likely suspects of a slow website is the server itself, dont use cheap hosting with godaddy, 1&1 and fasthosts for a large store, you need capable hardware due to database requirements at least 4gb of ram, so that MySQL can be optimized. bare minimum 2gb.

3. MySQL Optimization
Very important part of speeding up an ecommerce site is making sure your MySQL is optimized to perform as well as possible, huge bottlenecks can be caused simply by not doing this, which cause serious speed issues with database driven sites.

4. Cache Plugin
Your site should have some sort of static cache for visitors that have not started a basket yet for all the pages of your site, there are many plugins and solutions for this/

5. ModPageSpeed
A broad solution to speeding up many areas of your system is to install and use ModPageSpeed, its very good at optimizing css,js and image delivery and our hosting supports this apache module on default.

https://webdesires.co.uk/website-hosting/opencart/

One more!

1. Cloudflare just enabled HTTP/2 recently, with a SPDY fallback to boot. Its a major difference in speed. Like major major major difference.

webdesires wrote: 2. Is the server capable?
One of the most likely suspects of a slow website is the server itself, dont use cheap hosting with godaddy, 1&1 and fasthosts for a large store, you need capable hardware due to database requirements at least 4gb of ram, so that MySQL can be optimized. bare minimum 2gb.

I will also add one more VPS requirement for large stores, SSD drive (or SSD proxy cached RAIDS like @ram-node). For anyone wondering why he is suggesting 2gb ram minimum: if you run a KVM vps the OS uses your allocated ram, if OpenVZ then you gain a bit of ram due to parent running the kernel. Either way, OS must make room for caches (like mySql) on top of ram used to keep itself running. If there is a standard spinner drive, ram used will be more. If you use SSD you can pass more of this cache to disk since its still way fast, swap works faster too if you even need it, less ram overhead in general. None of this matters of course on shared hosting as long as you can keep your memory burst footprint below 512mb and keep your CPU from constant use such as bots hitting sitemaps/shopping feeds (bursting CPU is normally allowed, however some amateur/greedy reseller hosts overpopulate and rely too much on Cloudlinux auto suspensions).

So what is the minimum amount of resource OC needs for a larg-ish store under load? In a triple domain multistore stack (~10,000 products, ~2k+ visits a day), OC runs at like 512mb ram under load on Cloudlinux6.6 KVM with standard spinner drive using budgetneon file caching + standard mysql caches. It absolutely screams, like instant pageloads. The only real CPU use comes from generating uncached sitemaps/feeds and the 3-4 people constantly working in Admin. Your server needs overhead for that, but not so much running the catalog side. Its absolutely feasible to run a large OC store on shared host, IF they are a quality provider and allow occasional CPU bursting for sustained 5-15 seconds or so and you do not overkill your entry processes due to long scripts assuming the host is using Cloudlinux

If anyone needs it for shopping around or wants to know what to expect, here is a 30 day snapshot of the OC account running on that KVM described above. Keep in mind our I/O is limited to 1280mb/s since its a spinner drive and CPU to 80% of serv capability for overall performance reasons. mind the entry processes too - long scripts (or abuse) can easily cause 500 errors if not mitigated with enough EP sockets. 20 (the CL default) is too low for most big stores under load. You can see here, the shear amount of requests causes the EP's to go above 20 quite often. This would normally cause all sorts of 500 errors of death on a cheapo host.

webdesires wrote: 3. MySQL Optimization
Very important part of speeding up an ecommerce site is making sure your MySQL is optimized to perform as well as possible, huge bottlenecks can be caused simply by not doing this, which cause serious speed issues with database driven sites.

Here is a starting /etc/my.cnf for a store on VPS as described above. This is assuming you have already optimized your db/indexes and have pagecaching in place.