Rails 4 assets:precompile very slow all time

Rails
1

Hi, If I good understand, Rails 4 compile only changed assets ? Like
gem turbo-sprockets-rails3 ? In this case, I don’t understand why launch
2
times ‘rake assets:precompile’, take same time (~10min). Result a very
slow
deploy…

2

Any idea ? Just tell me if I understand the process

Le mardi 22 octobre 2013 10:20:34 UTC+2, [email protected] a crit :

3

same trouble, any ideas?

пятница, 25 октября 2013 г., 12:02:25 UTC+6 пользователь
[email protected]
написал:

4

On Tuesday, October 22, 2013 4:20:34 AM UTC-4, [email protected] wrote:

Hi, If I good understand, Rails 4 compile only changed assets ? Like
gem turbo-sprockets-rails3 ? In this case, I don’t understand why launch 2
times ‘rake assets:precompile’, take same time (~10min). Result a very slow
deploy…

Yes, in theory, that’s the way it works. There are a number of things
that
could be going on.

Your long compile time could be a number of issues. I would start with
the
easiest which is corrupted caches. Run the following:

rake assets:clean assets:clobber

This wipes everything out. Now run rake assets:precompile. This will
be a
long one since everything is being compiled. After that, you should be
able to make a change and only the changed asset will be recompiled.

If you’re still having long run times, you may need to clean things up.
There are several suggestions I could make:

  1. I only include images in the asset pipeline that get used on every
    page
    or the majority of pages such as a logo, background for a header, etc.
    Images that only get used on one page I keep in public/images and refer
    to
    them statically. The reason for this is that every image in the
    app/assets/images directory gets fingerprinted and copied to
    /public/assets. The only advantage to this is that the images are
    pre-loaded in the browser. However, it pre-loads them on every page,
    regardless of whether that page uses the images or not. To me, this is
    a
    lot of overhead and for images that I use only on one page or in one
    area I
    don’t run through the pipeline.

  2. Watch your filenames. Don’t name a stylesheet mystylesheet.css.scss
    if,
    in fact, the file only contains only CSS and no SASS code in it. It
    will
    unnecessarily get pre-processed when no pre-processing is required.
    Same
    goes for erb & coffee.

  3. This is a personal belief, a lot of developers would disagree, but I
    don’t ever use require_tree or require_directory in the manifest.
    First,
    with stylesheets, order is important so I need to require stylesheets in
    the right order and second, I want to be sure that only stylesheets and
    javascript I specifically require are included.

  4. You may have issues with your deployment tool. Capistrano, at one
    point, was touching every asset causing the pipeline to completely
    recompile regardless of whether changes had been made or not. I believe
    this was fixed, but I’m not positive.

Beyond this, I’m open for other’s comments. Hopefully, some of these
suggestions will help improve your times.

5

On Jun 9, 2014, at 1:58 PM, mike2r wrote:

  1. You may have issues with your deployment tool. Capistrano, at one point, was
    touching every asset causing the pipeline to completely recompile regardless of
    whether changes had been made or not. I believe this was fixed, but I’m not
    positive.

Beyond this, I’m open for other’s comments. Hopefully, some of these
suggestions will help improve your times.

I went through a phase on one server where my compile times would go up
and up until I restarted the server, then they would be blinding fast
again for a while, then get steadily worse. I don’t remember changing
anything, but the behavior went away. Might have been an update to
nodejs from regular apt-get updates that did that. Which JavaScript
engine are you running on your server?

Walter