Português
English
A freshly installed Magento is slow on purpose: it ships in developer mode, with caching off and nothing optimised, so that whoever is building the shop sees changes immediately. Making it fast means undoing that, in order. This is the order that pays best.
| None of this makes a small shared plan carry a large shop. It takes Magento out of the state it is born in, which is most of the available gain. If, once all of it is done, the panel is still heavy and the background jobs still behind, the problem has stopped being configuration and become resources: see VPS, Cloud or Dedicated. |
1. The scheduled task, which is the one everyone skips
Magento does half its work outside the visitor request: rebuilding indexes, recalculating prices, sending e-mail, clearing caches. All of that runs from a scheduled task. Without it, the shop raises no error at all: it simply gets slower and more out of date, and nobody can see why. Create the task following cron jobs, then confirm inside the Magento panel that it really is running.
2. Switch on the PHP accelerator
opcache keeps already compiled PHP in memory instead of recompiling it on every request. In an application with as many files as Magento, this is one of the largest gains available from a single click. On our accounts it arrives switched off: open Select PHP Version, go to the extensions and enable opcache.
| Measure before and measure after. Without a measurement, every change feels like it worked. See what to measure before you change plan. |
3. Leave developer mode
Magento has three modes. In developer it recompiles everything on every request; in production it serves files that are already prepared. The difference is large, and it is the second biggest source of slowness after the scheduled task.
| Switching modes is done from the Magento command line, and that needs SSH access. Some accounts have a shell and some do not. If yours does not, or you would rather not touch it, https://www.meu.mozout.co.mz/submitticket.php and we will make the change with you. Note too that on the command line the default php may not be the version you chose for the site: use the full path to the right one. |
4. Caches, indexes and content
| What | Why it counts |
| Every cache enabled | In Cache Management, nothing should be disabled. One cache left off after an old test session is enough to make the whole shop crawl. |
| Indexes on schedule | In Index Management, indexes should update on a schedule rather than on save. Saving a product then stops waiting for a full rebuild. |
| Merge and minify | In the developer settings, merging and minifying stylesheets and scripts cuts the number of requests per page sharply. |
| Images | Product photographs straight off the camera are almost always the heaviest thing on the page. Resize before uploading. |
| Old logs and reports | Magento log tables grow without end and slow the database down. There is an automatic cleanup in the configuration: switch it on. |
5. What lies outside Magento
After all of that, what is left is no longer Magento. A good part of the time a visitor feels is distance to the server and page weight. A content delivery network in front of the shop helps with both: we do not sell one, but customers of ours use the Cloudflare network, and the route is in Cloudflare, when it helps and how to switch it on. On where the machines are, see where our servers are.
And before changing anything, make sure you are not hitting the account ceilings: inodes, processes and memory. A shop that hits the process limit goes slow without a single error on screen.
|
Done all of this and the shop is still heavy? Send us the address and a time of day when it drags, and we will measure it. Open a support ticket |
|
SEE ALSO |
RECOMMENDED PRODUCT Web hosting with cPanel Domain and SSL included, daily backups and the panel you already know. from $10.00/mo See plans |
- 0 Users Found This Useful
