【问题标题】:Less compiling slow with Grunt使用 Grunt 减少编译速度
【发布时间】:2015-05-28 11:23:50
【问题描述】:

我想转到 Grunt 来执行我的 LESS 编译。

我的 LESS 文件被分成大约 117 个文件。我总共有大约 170 个导入,因为代码在我的项目的管理和成员区域之间共享。

我使用的是LiveReload,它在大约 500 - 700 毫秒内编译 LESS。浏览器实时重新加载后,总共需要大约 2 秒才能看到结果。

Grunt 编译需要 1.8 秒,所以一旦浏览器实时重新加载,总共大约需要 4 秒。

Grunt 明显变慢了。

我在配备 i7 CPU、SSD 和 16GB RAM 的 iMac 上进行测试。我在本地运行 Grunt,而不是在 VM 内。

我的问题是这样的:

  1. 是否所有 LESS 导入和文件都会减慢速度?
  2. 一般来说 Grunt 是不是比较慢?

我的 package.json 文件:

{
  "name": "Test Package",
  "version": "1.0.0",
  "devDependencies": {
    "grunt": "~0.4.5",
    "grunt-contrib-less": "*"
  },
  "dependencies": {
    "time-grunt": "*"
  }
}

还有我的 Gruntfile.js:

module.exports = function(grunt) {

  // Measures the time each task takes
  require('time-grunt')(grunt);

  // Project configuration.
  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
    less: {
      all: {
            files: {
              "css/style.css": "less/style.less",
              "css/admin/style.css": "less/admin/style.less",
              "css/admin/spectrum/spectrum.css": "less/plugins/spectrum/spectrum.less"
            },
          }
        }
  });

  // Load the plugins
  grunt.loadNpmTasks('grunt-contrib-less');

  // Default task(s).
  grunt.registerTask('default', ['less']);

};

关于如何格式化我的代码以加快编译速度的任何建议?或者这是目前这个库的限制?

【问题讨论】:

    标签: performance gruntjs grunt-contrib-less


    【解决方案1】:

    我猜 500-700ms 编译 170 个文件是相当合理的。

    此答案并未为您提供功能齐全的 gruntfile,但您应该能够采纳这些建议并改进您的工作流程。

    第一件事:有必要一次编译所有文件吗? 您可能希望将 less 任务分成 2 个部分而不是 all:一个用于管理员区域,一个用于成员区域(假设您没有在同时)。比如:

    less: {
            members: {
                options: {
                    compress: true //maybe
                },
                files: {
                    "app/members.css": "members.less"
                }
            },
            admin: {
                options: {
                    compress: true //maybe
                },
                files: {
                    "app/admin.css": "admin.less"
                }
            },
        }
    

    当然,您可以根据您的项目结构进一步划分这些部分。

    然后你创建 2 个或更多 grunt 任务来选择性地编译:

    grunt.registerTask('a', ['less:admin']); //let's call it 'a' - from admin
    grunt.registerTask('m', ['less:members']); // 'm' for members
    

    然后根据需要编译的内容运行grunt agrunt m。 这应该会加快整体编译时间。

    不过,我使用了不同的方法:

    • 我使用 watch 任务来查找修改后的 .less 文件
    • 在观看 .less 文件更改时,我只进行编译,进行 liveReload。在 watch config 我有这个部分:

      less: {
              options: {
                  livereload: false
              },
              files: 'blah-blah.less', //use your paths here
              tasks: ['less:dev'] //less:members or less:admin in your case
            }
      
    • 一旦 less 编译完成,我们就有一个更新的 .css 文件,它会再次触发对 css 文件的监视。同样,在 watch config 我有这个部分:

      css: {
              files: ['blah-blah.css'], //the .css file resulted from compilation
              options: {
                  livereload: true, //this is the most important
                  spawn: false //you may also need this
              },
          }
      
    • 我有一个 grunt watch 任务,它在我指定的文件夹中查找更改。像这样的:

      grunt.registerTask('watch', ['other tasks', 'connect', 'watch']); 
      

      请注意,我也使用 connect 来运行一个小型 http 服务器,但这里可能不是这样。

    现在,发生了什么:

    • 在开始开发之前,我会运行 grunt watch。它启动服务器并查找 .less 文件上的文件更改
    • 每当 .less 文件发生更改时,它都会被编译并更新 .css 文件。请注意,浏览器尚未刷新
    • 当 .css 文件发生更改时,浏览器会刷新但不加载整个 html,只应用生成的样式表。

    因此,如果您立即对任何 .less 文件进行更改,您将在浏览器中看到它的反映无需重新加载整个页面,这也为您节省了其他时间。

    这样,当您想要编译 .less 文件时,您还可以避免 2 秒的 grunt 编译时间,因为 grunt 已经在运行。

    在我的情况下,编译也很慢,但我使用了 timer-grunt(就像你一样),发现大部分浪费的时间是在加载依赖项上,所以我使用了 jit-grunt 按需加载它们,但这是另一回事。你可以在这个thread看到它。

    现在,回到你的问题:

    1. 是否所有 LESS 导入和文件都会减慢速度?

    取决于有多少文件,它们有多大,如果你完全编译它们。如果您将它们分成几个较小的任务,我认为情况并非如此。

    1. 一般来说 Grunt 是不是比较慢?

    在这种情况下,我猜您没有使用最佳工作流程。 Grunt 的速度与吞咽是另一场争论,也许是在喝几杯啤酒的时候。顺便说一句,这个并没有你想象的那么有限;)

    无论如何,如果您按照上述步骤进行操作,我认为您的速度会大大提高。

    希望这对其他人也有帮助!

    如果有人有不同的意见或其他策略,请分享。我总是渴望改进我的工作流程。

    【讨论】:

      猜你喜欢
      • 2014-01-07
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-11-04
      • 2022-08-17
      • 1970-01-01
      • 2016-10-08
      • 1970-01-01
      相关资源
      最近更新 更多