2013-02-01 8 views
11

jekyll --serverを実行すると、サイト全体が再構築されます。十分な大きさのサイトでは、これには非常に時間がかかります。 --autoフラグを設定しても、サイト全体の再生成を防ぐ必要がありますが、完了までの時間はかなり長くなります(私にとっては10秒以上、場合によっては数分で通知されます)。これは、1ページを編集してプレビューするときに不便です。私はその時間を短縮しようとしています。ローカルジーケルサーバーのページ生成時間を短縮

Jekyllがページを再構築するのにかかる時間が長い理由を判断する方法はありますか?

また、Jekyllとの短いフィードバックループを可能にするワークフローの編集に関する推奨事項がありますか?

+0

あなたは自分の最も最近のローカルの変更をプレビューするために短い建物の時間が必要な場合は明確でした(ローカルホストに、したがって、「プレビュービルドを」:必要なすべての記事を含みませんか)?または、1000sのポストを持つ展開ビルドが本当に必要な場合は、高速化する必要がありますか? – cboettig

+0

また、 '--auto'フラグは、変更中にjekyll' --server'が既に実行されている場合にのみ機能します。つまり、あなたのウェブサーバーで常に 'jekyll --server --auto'を実行していて、変更をそのサーバーにプッシュした場合です。 Jekyllは 'jekyll --server'へのその後の呼び出しの間にどのページが変更されたのかを追跡していません。 – cboettig

+0

も参照してください:https://github.com/jekyll/jekyll/issues/1855 –

答えて

3

これは、Jekyll's issue tracker on Githubの繰り返しの件名です。残念ながら、それは目的の一つではありません。たとえば:generate a site with about 60K posts, take forever

  • Make jekyll --auto specific
  • は言葉だけ "コンパイル" と "時間" を検索して、あなたはより多くを見つけることができるでしょう。見た目よりも少し難しいのは、リンクが壊れている可能性があるからです。あなたはLSIを使用している場合、それははるかに高速になり、それに関連した修正があったので

    また、最新バージョンを使用しています。

    私が唯一のアドバイスは、これらの投稿が本当に必要かどうかを知ることです(私が知っている、私は知っています)。対処するが、誰も始めたくない。

    P.Sは:課題追跡に問題を投稿してください - より多くの人々が不平を言うと、それは固定を取得することがはるかに可能です。

+0

誰かに世代を早くするための幸運や良いアイデアがありましたか? –

+0

私が知っているわけではありません。 – agarie

+0

私に戻ってくれてありがとう、私はそれを感謝する –

4

私はそれが完全なサイトの構築にかかる時間を解決することはできませんが、私は劇的に文書を起草し、レイアウト変更を行うスピードアップするための方法を作ってみました。これはすべて、編集のためにローカルマシン上で作業し、次に本番サーバーに展開することを前提としています。別のプロセスがある場合は、マイルが異なる場合があります。

基本的なアイデアは、それぞれが同じ出力場所を指し示す複数のジキルソースディレクトリを使用することです。私の場合、私は3つを使用します。レイアウト、デザイン、機能の変更(「_dev」と呼ばれる)とフルサイトの内容を含む最終的なもの(「_main」と呼ばれる)のためのものを作成し編集する(「_drafts」と呼ばれる)ためのものです。

トップレベルのディレクトリ構造は次のようになります。

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

各ジキルソースの_config.ymlファイルは、「HTML」ディレクトリにジキル生成された出力を指すようにフォローしてセットアップです:

destination: ../html 

'_drafts'と '_dev'ディレクトリには、 '_main'サイトのデザインと機能性を模倣するために必要なファイルの最小数が含まれています。私は仕事をしているうちにジキルが走っている2つのディレクトリですべての仕事をしています。私のローカルWebサーバーは、ローカルドメイン(例:http://jekyll-test/)を 'html'ディレクトリに向けるように設定されているので、変更を行っている間、何が起こっているのかを見ることができます。

編集が終わったら、新しく更新されたファイルを '_dev'または '_drafts'から '_main'の対応する場所にコピーします。ファイルが配置されたら、最後に '_main'でジキルを実行します。この方法では、サイトを実稼働環境に展開する前に、長いサイト生成時間を1回待つだけで済みます。私はしばらくこのアプローチを使用してきたし、それが大きな違いを見つける。

ワークフローを最適化するために、他のいくつかの方法があります:「_drafts」と同期して「_main」のデザインと機能性を保つために

  • 使用シンボリックリンクが。

    あなたは、MacやLinuxマシン上./main/_layouts./main/_config.yml./_drafts/_layouts./_drafts/_config.ymlを指すように設定シンボリックリンクされている場合は(同様の機能は、おそらくWindows上に存在するが、私はそれに話すことができません)。何らかの理由で、ジキルは記号的にリンクされたいくつかのディレクトリでうまく動作しません。たとえば、私のインストール時に、シンボリックリンクとして機能しないルートレベルの 'css'ディレクトリがあります。私はすべての場所に実際のコピーを持っていなければなりません。

  • デプロイメントスクリプトを作成します。

    私が展開する準備ができたら、私はjekyllを直接実行しません。私は '_main'ディレクトリにjekyllという小さなスクリプトを書き、プロダクションサーバに出力をrsyncして、完了したら通知します。これによりジキルを待つ必要がなくなるだけでなく、サイトを展開するのに必要なステップ数が減ります。

  • 追加のスクリプトとツールをビルドします。

    '_dev'と '_drafts'ディレクトリからファイルをコピーすることは大したことではありませんが、いくつかの自動化を追加するのが最も重要です。たとえば、 '_config.yml'ファイルと '_layouts'と 'css'ディレクトリを '_dev'から '_drafts'と '_main'(必要に応じて)にコピーするコマンドラインスクリプトがあります。

    ドケットの別のツールは、 '_drafts'から '_main'に投稿を移動するローカルWebアプリです。ファイルの動きを簡単にし、作成と公開の摩擦を軽減するものはどれもいいです。ローカルで実行

  • 使用LiveReload

    jekyll --autoはファイルで作業しながら、変更を自動的に生成するのに最適です。この自然なコンパニオンはLiveReloadというアプリです。ローカルの 'html'ディレクトリを監視し、コンテンツが変更されたときにブラウザの自動リロードを開始します。これは、テキストエディタの横にブラウザウィンドウを保持し、ファイルを保存するときに自動的に変更が行われることを確認できます。それは時々少し薄れですが、それを使用した後、あなたはそれなしでどのように住んでいたか分かりません。

+0

それはかなりきれいです。私はジキル人に次の「コンパイル時間を制限すべきです」という議論が起こったときに、このアイデアを検討するよう提案します。 :) – agarie

+0

良い解決策。 –

関連する問題