11

运行时jekyll --server，将重建整个站点。在足够大的网站上，这需要非常长的时间。即使使用--auto应该阻止整个站点重新生成的标志，完成的时间也相当长（对我来说 10 多秒，据报道在几分钟内）。这在编辑和预览单个页面时很不方便。我希望缩短那个时间。

有没有办法确定为什么 Jekyll 需要和重建页面一样长的时间？

或者，是否有关于编辑工作流的建议，允许使用 Jekyll 进行更短的反馈循环？

4

2 回答 2

4

我无法解决构建完整站点所需的时间，但我想出了一种方法来显着加快起草文档和更改布局的速度。所有这些都假设您在本地机器上工作以进行编辑，然后部署到生产服务器。如果您有不同的流程，您的里程可能会有所不同。

核心思想是使用多个 jekyll 源目录，每个目录都指向同一个输出位置。就我而言，我使用三个。一个用于起草和编辑帖子（称为“_drafts”），一个用于布局、设计和功能更改（称为“_dev”），最后一个包含整个站点的内容（称为“_main”）。

顶级目录结构如下所示：

./_drafts
./_dev
./_main
./html

每个 jekyll 源的 _config.yml 文件设置如下，将 jekyll 生成的输出指向“html”目录：

destination: ../html

“_drafts”和“_dev”目录包含使它们模仿“_main”站点的设计和功能所需的最少文件数。我在这两个目录中完成所有工作，jekyll 运行在任何正在处理的目录中。我的本地 Web 服务器设置为将本地域（例如http://jekyll-test/）指向“html”目录，因此我可以在进行更改时看到发生了什么。

完成编辑后，我将新更新的文件从“_dev”或“_drafts”复制到“_main”中的相应位置。文件准备好后，我会在“_main”中运行最后一次 jekyll。使用这种方法，您只需等待较长的站点生成时间，然后再将站点部署到生产环境。我已经使用这种方法一段时间了，发现它有很大的不同。

还有一些其他方法可以优化工作流程：

  • 使用符号链接来帮助保持“_drafts”和“_main”的设计和功能同步。

    如果你在 Mac 或 linux 机器上，设置符号链接指向和./_drafts/_config.yml指向（类似的功能可能存在于 Windows 上，但我不能说）。出于某种原因，jekyll 不适用于某些符号链接的目录。例如，在我的安装中，我有一个不能用作符号链接的根级“css”目录。我必须在所有位置都有它的实际副本。./main/_config.yml./_drafts/_layouts./main/_layouts

  • 创建部署脚本。

    当我准备好部署时，我不会直接运行 jekyll。我编写了一个小脚本，在“_main”目录中调用 jekyll，将输出同步到我的生产服务器，然后在完成时通知我。这不仅节省了在 jekyll 上等待的时间，还减少了部署站点所需的步骤。

  • 构建额外的脚本和工具。

    从“_dev”和“_drafts”目录复制文件没什么大不了的，但它是添加一些自动化的主要地方。例如，我有一个命令行脚本，它将“_config.yml”文件以及“_layouts”和“css”目录从“_dev”复制到“_drafts”和“_main”（根据需要）。

    案卷上的另一个工具是本地网络应用程序，它将帖子从“_drafts”移动到“_main”。任何使文件移动更容易并减少创建和发布的摩擦的东西都是好的。

  • 使用 LiveReload

    在本地运行，jekyll --auto非常适合在处理文件时自动生成更改。与之自然搭配的是名为LiveReload的应用程序。它监视您的本地“html”目录并在内容更改时触发浏览器的自动重新加载。这样做的目的是您可以将浏览器窗口保留在文本编辑器旁边，并在保存文件时自动查看更改。时不时会有点片状，但用了之后，你不知道没有它你是怎么活的。

于 2013-02-03T16:06:33.270 回答
3

这是Jekyll 在 Github 上的问题跟踪器中经常出现的主题。不幸的是，这不是目标之一。例如：

只需搜索“编译”和“时间”这两个词，您就能找到更多。它比看起来要难一些，因为存在链接断开的可能性。

此外，如果您使用的是 LSI，请使用最新版本，因为有一个与之相关的修复程序可以使其更快。

我对你的唯一建议是看看你是否真的需要所有这些帖子（我知道，我知道），因为这可能是你现在从问题跟踪器中得到的唯一答案——我们都想解决的问题，但是没有人想开始。

PS：请在问题跟踪器上发布您的问题——抱怨的人越多，解决问题的可能性就越大。

于 2013-02-03T12:15:07.573 回答