If you’ve arrived here, I should imagine that by now you’re becoming increasingly infuriated with how slow Magento 2 runs whilst trying to get your e-commerce project completed. Your development site might be suffering such symptoms as the checkout taking an age to render and the admin being painfully slow. But not to worry, this happens to many of us developers when going into battle with Magento 2. In this post, I will give an overview of some of the tactics you can use to speed up the development process and in turn helping Magento 2 be somewhere near being a joy to work with. If that’s even a thing?
1. Get your environment right.
From what I’ve seen, development environments such as Mamp, Wamp, etc don’t really cut it when it comes to Magento 2 development and setting up a native Nginx or Apache server on a Mac is less than fun. From experience, I prefer to use a Vagrant box, but it can be any kind of contained system like that. It works well because I’m using a Linux machine, albeit a virtual one, and I can install extra software on there (more on that later) to help speed up the development of the site.
Now I cannot run through the setup of a Vagrant box for Magento 2 in this article, but I have created a gist file with a list of instructions at https://gist.github.com/andy-igoo/68818d1b1b1560b661be1e473a2aa2f7 to guide you through it. Any problems, leave a comment in the gist.
I develop on an Ubuntu machine, and so that the file I/O is quick enough to handle the huge amount of files Magento 2 uses, I use an NFS mount which is so much quicker than anything Virtualbox can offer you (as far as I’m aware).
(If you’ve tried Vagrant before and it was really so very slow, this may have been your issue so don’t be put off trying again but this time with NFS.)
I could not really say if NFS mounts are going to be a reasonable solution for Windows users. To use a mount in Vagrant on *nix machines, you need a line like this in your configuration for it to work out of the box:
config.vm.synced_folder “./”, VM_WEB_ROOT, :nfs => { :mount_options => [“dmode=777”, “fmode=666”] }, nfs_version: VM_NFS_VERSION, nfs_udp: false, :linux__nfs_options => [‘rw’,’no_subtree_check’,’all_squash’,’async’]
For Macs, replace that linux__nfs_options with bsd__nfs_options and you’re good to go and you can even have both configurations in there if your organisation is using both systems like ours. For Windows, however, the solution people seem to be running to is Vagrant WinNFSd (https://github.com/winnfsd/vagrant-winnfsd) but I have no personal experience of how well this works. Do let me know.
I prefer to use Nginx with a PHP-FPM version 7 or above for the web serving side of things. Using PHP 7 will make a big difference anyway if you’re still on version 5.6 (hopefully it’s at least that). To configure Nginx, you can take a look at Magento’s own Nginx configuration file (https://github.com/magento/magento2/blob/2.2-develop/nginx.conf.sample), copy and make adjustments from there.
Granted, it’s a mission to get this all working but it’s ultimately worth the extra effort; if you’re saving seconds on every refresh then you’re saving hours every month. Do use the extra resources above to help you.
2. Effectively manage caches (and other stuff) via zsh.
If you’ve come from Magento 1 development then you may have formed a habit of turning all the caches off for development so you can see changes immediately. However, for the most part, you don’t need them all off. I tend to have most of them switched on, bar the frontend stuff such as layout cache, block cache and full page cache, and I adjust for what I’m working on at the time. Configuration cache rarely needs clearing and the most caches can be left on if you’re not working on the database/collections side of things.
The trick to being quick is being able to dump or refresh the caches with little effort as we certainly don’t want to be logging in to the admin … (watch browser loading spinner on tab) … going to the wrong menu first, and then clicking on System > Cache Management > … … which finally loads so you can dump the cache from there; complete waste of life!
This is where the beauty of zsh comes into play. It has a pattern matching way of traversing history so you can do really cool nifty little things with it. Firstly, consider this: typing bin/magento (how you run Magento’s cli tool, think n98-magerun) isn’t all that quick to compared to say something like mg; which is what I use as an alias. So by editing your zsh profile and adding the alias mg, I can, with the pattern matching of zsh, just type mg and then start pressing the up arrow to go through my history of everything starting with mg! I get to my most common commands pretty quickly, and that’s not the end of it, oh no!
Magento’s CLI setup uses a module from the Symfony framework which goes by the adventurous name of, The Console Component. This means you can shorten what you type further for the commands that control Magento 2’s underbelly. Flushing the cache, for example, can be something like mg c:f and and mg setup:upgrade can be mg set:up. As long as The Console Component has enough information for each side of the ‘:’ it will find the command for you and run it; and of course if it doesn’t understand you, you will just need to put a few more characters in.
By the end of it, you’ve gone from typing bin/magento setup:static-content:deploy to mg s:s:d. Managing the cache now is a matter of typing mg c and then tapping the up arrow and hitting [Enter] when you see it. Within two or three attempts, the one I want usually appears. The advantage of having a Linux Vagrant box is I can just install it on the virtual machine and it just be another tool for Magento 2 development with only, really, history devoted to development of Magento 2 sites because it’s not my main system.
This animated gif may help you visualise what that means:
It’s not just caches you can quickly get done with zsh, it’s many things and that opens up all sorts of possibilities.
Bonus tip: make zsh extra awesome by installing “Oh my zsh”.
Coming back to my original example, we can leave most caches switched on and it not be a pain to manage them. If your IDE has the ability to contain a terminal shell, you don’t have to even go to another program. PHPStorm, my personal favourite IDE by far, has such a feature which works really well for me.
3. Use Redis as your caching strategy when developing with Magento 2.
When using Redis, the improvement is notable and the installation process is not too bad. Follow these set of instructions to the letter and you’re half way there: https://redis.io/topics/quickstart. Remember to install on your Vagrant / Docker etc if that’s what you’re using.
Then you can go ahead with enabling it for Magento. These are the official instructions http://devdocs.magento.com/guides/v2.2/config-guide/redis/redis-pg-cache.html and they’re easy enough just so long as you read it. Just watch the version number you’re looking at because I note there’s a change between 2.1 and 2.2.
For production servers you may want to get further advice or get knowledgeable about fine tuning the thing, but for using it locally the standard setup seems to be fine.
4. Use the Snowdog sass theme
It’s a strange but wonderful industry we work in because we’re a very cooperative community. Could you imagine McDoland’s giving out free recipes to Burger King and Wimpy!? Certainly not, and yet, here I am giving you the best I know about improving the speed of developing in Magento 2 (better productivity) and Snowdog shared code they developed so they could use Sass instead of Less, for free!
This means when working on the styling you can start the gulp watcher, edit your Sass (the watcher updates on save) and then use a plugin in your browser to refresh only the css. With this setup and a bit of skill, you’ll have the job done in no time! You will not have to refresh and make another request to Magento to re-render the page each time you want to see a change.
5. Learn the damn thing!
If you don’t know why you should take Magento 2 out of default mode or what the code generation is for, then you’re leaving yourself open to the kind of misconception that could see you coding your way in to a horrible corner and doing things like running the ‘di compile’ command without really needing to do so.
If you’re brand new to Magento 2, then it will help to firstly have an idea of dependency injection and some idea of the principles of good OOP designbefore embarking. For frontend developers, if you don’t know Knockout JSthen drop everything right now and complete the fairly fun tutorial before learning Magento 2, otherwise you may end up a miserable defeated soul.
Once you have all the prerequisites, I suggest going through (with version 2.1 only for now) Alan Storm’s series on Magento 2 is here, enjoy: https://alanstorm.com/category/magento-2/.
Important note on Alan’s series:
At the time of writing, the “Advanced Javascript” section is displayed first before the “Magento 2 for PHP MVC Developers” section which itself should actually be first, so do the second section first. The first section that’s displayed (advanced Javascript) is actually supposed to be the second part of the series; at some point they’ve become swapped around.
Silly Alan!
