Theme Development Extremely Slow

[duffner]

Building a new theme within Magento 2 is extremely slow, with page load times exceeding 40 seconds when having to generate theme assets.

Preconditions

1. Vagrant Machine
2. PHP 7
3. Tried Client and Server side compilation of LESS files
4. JS and CSS Merge and Minify set to "No"

Steps to reproduce

1. Modify LESS File within current theme
2. Delete:

     ../pub/static/frontend/MyPackage/mytheme/en_US/css
     ../var/view_preprocessed/css',
     ../var/view_preprocessed/source'

3. Reload Desired Page in Browser
4. Inspect Network tab
5. mydomain.dev loads in approx ~10 seconds
6. print.css, styles-l.css, styles-m.css ~40+ seconds

Expected result

1. Generation of the page and assets should take less than 10 seconds

Actual result

This makes Magento 2 frontend development painful. While I feel that normally this would be a forum question, the reason it's a bug is for a few reasons: If there isn't a better way to do this, the speed is completely unacceptable, and two, if there is a better way to accomplish frontend styling there isn't documentation indicating otherwise which in itself is a bug.

[JTessmer]

This is actually a problem I've been experiencing as well. I've tried each of the available compilation methods, and the one that @duffner described above (deleting the cache files) seems to be the most efficient way to develop.

Yet it becomes incredibly frustrating when every 3-second CSS change requires somewhere in excess of 30 seconds' worth of waiting.

[ghost]

http://devdocs.magento.com/guides/v2.0/frontend-dev-guide/css-topics/css_debug.html

Makes it less painful.

[denchev]

If you are using a Vagrant and a mounted drive (specially on Windows) I'd recommend to put the Magento inside the virtual machine's disk space. The communication between Vagrant (guest) and host machine is extremely slow. I had the same issue with Docker. I moved the Magento files inside the container and I upload files from host to guest via PHPStorm sync functionality. The difference in speed is night and day.

[JTessmer]

@jupiter01 -- My experience with using the built-in Grunt as described in that article is that grunt watch often doesn't detect my file changes (and when it does, it may be 10-20 seconds after I've made them).

Likewise, the files created with grunt exec:<theme> don't seem to be correctly symlinking, so in order to see my changes, I have to run the following: grunt clean:<theme> && grunt exec:<theme> && grunt less:<theme> each time I make a change.

Since running grunt clean is effectively deleting the same files mentioned by @duffner above, I still run into the same 30+ second load time on page refresh. In which case I've found it to be more effective to simply delete those files directly rather than run it through the grunt process.

[duffner]

I agree with @JTessmer, as this is what has been necessary in order to work effectively. @denchev, I am using vagrant within a virtual box run on a mac, and virtual machines disk is mounted within as you recommended. This same vagrant instance runs a fresh Magento 1 instance with cache disabled in .75 - 1.00 seconds.

[slackerzz]

@duffner sadly this is the state of frontend workflow in M2 (for reference take a look at this issue #2104)
M2 frontend is a big, old, slow monster!
Those using grunt please note that there is a big problem #7231

[duffner]

@magento-admin, who is assigned to this ticket? This is a major issue and makes Magento 2 extremely custom themes almost impossible due to extensive build time.

[mfdj]

@duffner just curious but if you're using macOS I would watch out for using .dev that 10 seconds to connect sounds like something I've encountered https://github.com/mfdj/dot-local-and-dot-dev (probably has nothing to with magento).

[duffner]

Im lucky to have already solved that one a number of years back. I use grunt, less and custom theme generation as my custom functionality ontop of Magento 1. The only reason it's so slow is because of the dependency on PHP that Magento's build process has. I'd like to see Magento create a webinar or demo of proper front end development from the configuration and theme / project setup side.

[duffner]

And to others comments while I like gulp better at this point. Grunt works awesome, when it's used with an application respectful of it. @magento. When are you solving this!!!!!

[duffner]

What is the status of this issue.

Development speed for a front-end developer is unacceptable.

When is Magento planning to fix this?

[denchev]

I will say it again since nobody seems to care about my previous comment. The speed of Magento 2 is largely based on the file system I/O. If you are using any sort of virtual machine and synced folders. No matter Vagrant or Docker. Just don't! I went from more than 2 minutes load time to less than 200ms when I moved from fully synced VM host-guest machine to only-sync-the-theme-or-extension-and-not-the-other-40000-files.

The bottom line is: Magento is not slow. The OS and server setup has to be right.

[duffner]

@denchev, I do care. :) Can you please explain your configuration in more detail?

I'd love to learn a new way to do this... but I develop on a mac, the only alternative I have would be native NGNIX, PHP and MySQL on OSX.

I'd consider this solved if there was documentation to support a 200ms approach to getting grunt to compile less and see my changes immediately.

Additionally, I don't believe I have an IO problem... but I could be wrong.. Is there a way I could test my current configuration to prove your theory?

[denchev]

@duffner Grunt is slow even in good days. I'm using a SASS based theme for Magento 2 and it comes with it's own GULP tools. You should check this project https://github.com/SnowdogApps/magento2-theme-blank-sass. It is working pretty good.

[duffner]

@denchev, I understand Grunt is slow in comparison to GULP, however it's not Grunt's problem. It's the theme building itself.

Again while I agree your referenced theme maybe a solution. It's still a Magento core problem.

[csdougliss]

@duffner I would recommend you setup nginx, php and mysql using brew. It's not too difficult to do.

Just install PHP 7.0 and enable opcache in php.ini and your good to go.

I did run into an issue with a max file limit in OS X, but I solved that.

With regards to everybody else on Mac.. I'm using a 13" MacBook Pro with an SSD from late 2013. I was thinking of getting a new machine simply because M2 is so slow for development. It's not so bad when you use grunt etc, but if your changing layouts and html output then it still is quite slow.

Would anyone recommend a 13" or 15" 2016 model? I prefer the portability of the 13" over the 15" but I'm concerned the 13" is only a dual core.

I'm also thinking about getting a Dell XPS 15.

[denchev]

@duffner Have you read this article? https://magento.com/blog/technical/set-your-magento-2-development-environment-faster

[duffner]

@denchev, I have not

MacOS: The shared filesystem is not performant enough. Magento worked too slowly.

That is why we decided to use Unison (a file synchronization tool) to keep the local (inside Docker) web root directory in sync with files in the shared directory. It works quite well, although the initial synchronization takes a few minutes.

Is this what you were referring to?

[denchev]

@duffner More or less. The guys from Magento explained it better than me.

I think Magento is build for Linux and all other OS (Windows, MacOS) needs to find a way to work around it.

I use a virtual machine with Ubuntu. My Magento files are installed in the VM. Then I only expose the extension/theme files between host and guest machine. I have to keep another copy of Magento on my host machine just so my PHP Storm can work properly though.

[duffner]

@denchev, thanks for the explanation. I'll give your approach a try and I'll document my findings

[magento-engcom-team]

@duffner, thank you for your report.
This seems to be correct Magento behavior. Please refer to the Community Forums or the Magento Stack Exchange site for advice or general discussion about this.
Otherwise you may submit Pull Request with the suggested changes.