Question

运行jekyll --server时，将重建整个网站。在足够大的网站上，这需要非常长的时间。即使使用--auto标志，这应该可以防止整个站点的重建，但完成的时间相当长（对我来说是10秒以上，据报道在某些时间内会有几分钟）。编辑和预览单个页面时这很不方便。我希望减少时间。

有没有办法确定为什么Jekyll会像重建页面一样长时间？

或者，是否有建议编辑工作流程，允许与Jekyll进行短暂（呃）反馈循环？

Answer 1

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

核心思想是使用多个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至./main/_config.yml和./_drafts/_layouts至./main/_layouts的符号链接（Windows上可能存在类似功能，但我不能说话）。出于某种原因，jekyll不能很好地与一些符号链接的目录。例如，在我的安装中，我有一个根级别'css'目录，它不能用作sym链接。我必须在所有位置都有它的实际副本。
创建部署脚本。

当我准备部署时，我不会直接运行jekyll。我在'_main'目录中编写了一个调用jekyll的小脚本，将输出rsyncs到我的生产服务器，然后在完成后通知我。这不仅可以节省等待jekyll，还可以减少部署站点所需的步骤数。
构建其他脚本和工具。

从'_dev'和'_drafts'目录复制文件并不是什么大问题，但它是添加一些自动化的主要场所。例如，我有一个命令行脚本，将'_config.yml'文件和'_layouts'和'css'目录从'_dev'复制到'_drafts'和'_main'（必要时）。

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

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

Answer 2

这是Jekyll's issue tracker on Github中的经常性主题。不幸的是，这不是目标之一。例如：

只需搜索“编译”和“时间”字样，您就可以找到更多内容。它看起来有点难，因为链接断开的可能性很大。

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

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

P.S。：请在问题跟踪器上发布您的问题 - 有更多人抱怨，它更有可能得到修复。

缩短本地jekyll服务器的页面生成时间

2 个答案: