Jekyll / Octopressやその他の静的なブログエンジンは、重いオンラインマガジンに適した選択肢でしょうか？
（免責事項：この質問はスーパーユーザーに尋ねるべきだと思ったが、それは適切な場所ではなかったようだ。これがより適切であることを願っている。）
私は、静的なブログエンジンを設定し、私が持っているいくつかのブログのコンテンツをそこに移行するためのいくつかのオプションを調査しています。これらのエンジンのパフォーマンスをテストしたいのですが、ジキルとオクトプレスの素晴らしいことを聞いたことがあります。
これらの種類のエンジンが重いサイトに適しているのではないかと思います1日あたりの訪問数（1か月あたり100万ユニークな開始仮想番号を付けましょう）。
WordPressはあらゆる面で多くの可能性を秘めた素晴らしいCMSですが、ブログ/雑誌の特定の部分が静的な振る舞いをするW3 Total Cacheなどのキャッシュプラグインがありますが、他の部分やとりわけ常にMySQLにアクセスする必要があるため、ブログに問題が生じる可能性があります。
静的なブログエンジンがデータベースを必要としないことを考えると、すべての記事が静的なWebページになる雑誌を公開するにそれらのいずれかを適応させようとするのは夢中になるのではないかと思いますそして、たとえばDisqusに基づいたコメントがあります。このアイデアに技術的な問題はありますか？
私の考えを思い出して、これらは長所と短所になります。
長所
- 静的なものすべて（コメント、Disqusを除く）
- データベースへのアクセスなし、おそらくロード/応答時間の改善
短所
非常に注目度の高い/トラフィックの多いサイトが、JekyllやOctopressなどの静的サイトジェネレーターに切り替わりました。ただし、静的サイトにはパフォーマンス、展開、およびセキュリティの利点がありますが、多くの欠点もあります。今日のWeb上のほとんどのサイトが動的であり、ほとんどのCMSが静的なサイトジェネレーターではない理由があります。
考慮する必要がある主な欠点は次のとおりです。
サイト生成時間
無料のランチなどはありません。静的サイトジェネレーターは、従来のCMSが行うページ生成と処理を取り除きません。彼らは単にこのタスクを別の時間/場所にそらすだけです。同じ作業を行う必要がありますが、その作業を数百または数千のリクエストに分割する代わりに、ジェネレーターはすべてを一度に行います。これにより、訪問者の貴重なミリ秒を節約できますが、実際にはサイトの生成時間を増やす可能性があります。
サイトが大きくなるにつれて（または既にかなりのページがあるサイトを変換している場合）、レイアウトの変更（ナビゲーション、見出し、フッター、サイドバーコンテンツなど）、タグの生成などの生成時間アーカイブページなどはますます時間がかかり始めます。 このウェブマスターの彼のスイッチのアカウント を読んでから自分で突進することを強くお勧めします。
したがって、タイムリーな更新に依存する大規模なサイトがある場合、タグ、関連する投稿、アーカイブページなどの機能を削除する必要がある場合があるため、作成するたびにサイトを生成するのに1時間かかりません役職。
幸いなことに、コンテンツの更新の遅延時間がサイトに影響を与えない場合は、コンテンツ作成者が投稿を更新キューに単に送信し、更新スクリプトがバックグラウンドでサイト生成を無人で処理するようなプロセスを自動化できます。投稿が掲載されるまでにまだ1時間かかる場合がありますが、時間を無駄にすることはありません。
静的サイトの機能は非常に限られています
非静的コンポーネントをサイトに埋め込むことができますが、これにより静的サイトを実行することの多くの利点がなくなり、複数の場所からサイトを管理する必要があります。また、組み込みのSaaSサービスを介して提供できない機能もあります。ライブコンテンツ管理、JSフリー+検索エンジンに優しいコメント、ユーザー管理など.
ファセット検索、ダイナミックナビゲーションなどのその他の機能（例最も人気のある投稿、最近のページ、コミュニティのタグ付けなど）、Webサービス（SOAP/XML-RPC）、セッション管理などは実装が非常に難しくなります。基本的に、基本的なブログを超えてサイトを拡張したくないことを確認する必要があります。
ただし、幸いなことに、ほとんどのブログサイトは静的なサイトにコア機能を実装できます。そのため、欠点は他のタイプのサイトほど深刻ではありません（例：コミュニティサイトまたはメンバーシップサイト、eコマースストアなど）。コストとメリットを比較するだけです。ここには正解も不正解もありません。サイトの要件と同じくらい個人的な好みに依存します。
ただし、静的サイトジェネレーターに切り替える主な動機がパフォーマンスである場合は、まず次のような他のオプションを検討する必要があります。
- 静的アセットをnginxなどの軽量Webサーバー+ cookielessドメインにオフロードする
- フルページキャッシュを使用する（ページの最初のリクエスト後は、基本的に静的ページを持つようになります）
- dBリクエストが頻繁に発生しないようにクエリをキャッシュする
- クライアント側のキャッシュを使用する
- リソースを統合してHTTPリクエストを最小限に抑える
- 並行ダウンロードの増加
動的サイトを正しくセットアップすると、コメント、トラックバックなどの目的で多数のサードパーティJS埋め込みを使用する静的サイトよりも読み込みが速くなる可能性があります。したがって、johnがコメントで提案しているように、サイトのベンチマークを行い、実際のパフォーマンスのボトルネックがどこにあるかを見つけます。リンクされたJSとサードパーティの依存関係をさらに追加する静的サイトに切り替えるよりも、CDNまたはCSS/JSを統合すると、サイトのパフォーマンスが向上する可能性があります。
わかりません。適切なキャッシングを行っている場合、あなたが言うように常にDBにクエリする必要があるのは何ですか？それはあなたが使用する必要があるものですか？はいの場合、静的サイトで使用する必要はありませんか？
1か月あたり100万ユニークは、1分あたり24ユニークのようです。それは、中距離のVPSであっても重負荷ではありません。特にものをキャッシュしている場合。そして、nginxのようなものをいつでも使用して、静的な部分（画像など）の提供をより効率的にすることができます。