快適なページ作りのためにできること

このページでは、WIKIを快適に使い続けるための
ちょっとした工夫やお願いごとをご紹介しています。

〜 少し長めですが、時間のあるときに読んでいただけると嬉しいです 〜

はじめに

WIKIWIKIは、誰でも手軽に使えるWIKIサービスとして、多くの方にご利用いただいています。 その裏側では、サーバーやネットワークなどのインフラが目に見えないところで稼働し、 できるだけ速くページが表示されるよう、日々最適化と調整が続けられています。

とはいえ、システムがどれほど頑張っても、無限にリソースを提供できるわけではありません。 ときには、裏側で働くサーバーたちも「ちょっと休ませて…」とつぶやきたくなることがあります。

このページでは、普段は見えにくい「システムへの負荷」の実態と、 それを抑えるために、ユーザーの皆さまにもご協力いただける工夫についてご案内しています。 サービスをこれからも快適に使い続けていただくために、ぜひご一読ください。

WIKIの“速さ”の裏側で起きていること

WIKIWIKIでは、ページを開いた瞬間に表示が始まるよう、キャッシュの活用、通信経路の短縮、 オーバースペック気味のサーバー、サーバー構成のチューニングなど、裏側ではさまざまな仕組みが支えています。

それらはすべて、「表示を待たされない体験」を実現するための工夫です。ユーザーが快適に感じることはもちろん重要ですが、 その快適さがどれだけの見えない努力によって成り立っているかは、普段なかなか意識されることはありません。

しかも、ページの最適化によって快適になると、今度は「もっと画像を増やそう」「もっと折りたたみに情報を詰め込もう」といった使い方が増え、 結果としてシステムへの負荷がさらに増していくことがあります。

たとえば、「パーキンソンの法則」や「ジェボンズのパラドックス」と呼ばれる現象があります。

パーキンソンの法則は、「仕事の量は、与えられた時間やリソースの限界まで膨らむ」というものです。 システムの性能を向上させれば、それに合わせてユーザーがより多くの情報を詰め込むようになり、リソースを使い切ってしまう傾向があります。

ジェボンズのパラドックスは、「ある資源の利用効率が上がると、かえってその資源の消費が増える」という逆説です。

表示の最適化によって軽く速くなったページでも、「もっと情報を載せられる」と思われて使い方が過剰になり、 結果としてサーバーの負荷は減らない、という構図が生まれるのです。

つまり、裏側の性能をいくら強化しても、それに応じて使い方が重たくなってしまえば、負荷は下がるどころかむしろ増えることがあります。

こうした背景をふまえ、サービスをより良く保つために、ご協力いただきたいことがあります。 小さな取り組みが、WIKI全体の安定性に大きな影響を与えます。

見えないアクセスがもたらす負荷

WIKIへのアクセスは、実際の閲覧者だけとは限りません。

たとえば、以下のようなさまざまなbotが日々自動的にページにアクセスしています。

• 検索エンジンのクローラー
  

  ページを検索結果に載せるため、自動で巡回して内容を取得します。

• SNSのリンクプレビュー生成
  

  SNSやチャットにWIKIのリンクが貼られたとき、カード型の表示を生成するためにアクセスします。

• AIによる情報収集
  

  最近では、AIがWeb上の情報を文脈把握や学習目的で収集するケースも増えてきました。

• コンテンツチェックの仕組み
  

  たとえば、WIKIに掲載されたコンテンツがアダルト的でないかを確認するような仕組みです。

このようなアクセスは、ユーザーからは見えませんが、実際にはサーバーにとってはすべて「処理すべきリクエスト」です。 たとえ誰も見ていないようなページでも、botの巡回によって一定の負荷がかかり続けているのです。

さらに、WIKIWIKIでは特定の時期になるとDDoS攻撃などの悪意あるアクセスも集中しやすく、これもシステムを守るためのリソースを圧迫します。

つまり、「誰も見ていないから負荷にならない」のではなく、「誰も見ていなくても負荷はかかる」というのが実際のところです。

見えないアクセスによる負荷も含め、全体として最適化していくためには、 ユーザー自身ができるだけ軽量で効率的なページ作りを心がけることが重要な一歩となります。

快適なページ作りのためにできること

WIKIをこれからも快適に使い続けていただくために、ユーザーの皆さまにご協力いただきたいことがあります。

WIKIのページは、実際の閲覧者だけでなく、検索クローラーやAIの巡回など、さまざまなシステムからも日々アクセスされています。 そのため、1ページ1ページの構成が、全体のサーバー負荷やパフォーマンスに少なからず影響を及ぼします。

ちょっとした工夫でも、サービス全体の安定性と表示の軽快さに大きく貢献することができます。 以下のポイントを参考に、効率的で軽量なページづくりを意識していただければ幸いです。

• ページを分割し、1ページあたりの情報量を適度に保つ
  

  あまりに長いページは、読み込み・描画・通信に大きな負担をかけます。 たとえばアイテム一覧、キャラクター紹介、用語集などのようにカテゴリごとに分けると、管理もしやすくなります。

• 画像は最適なサイズで、必要な分だけ
  

  画像はシステム側で自動的に遅延読み込みされますが、サイズが極端に大きかったり、掲載数が多すぎる場合は、 それでも読み込み時の負荷が大きくなります。

• MenuBarはコンパクトに
  

  MenuBarはすべてのページに共通して表示されるため、ここに多くの情報を載せすぎると、そのぶんすべてのページの読み込みが重くなってしまいます。 項目の追加や説明文の記載などを行う際は、本当に必要かどうかを見直し、簡潔で軽量な構成を意識してください。

• 折りたたみ（fold）の使い方に注意
  

  折りたたみ機能は、見た目上は情報を隠せますが、内部では折りたたまれた中身も最初から読み込まれています。 情報の整理には役立ちますが、ページ全体が重くなる要因にもなりうるため、多用は避けましょう。

• プラグインの使い方に注意
  

  本来の用途を超えて複雑な構造や重い処理を実行すると、表示が遅くなったり不具合の原因になります。 特に「ネストの多い構造」「件数の多いデータ処理」「他プラグインとの組み合わせ」などは慎重に設計してください。

さらに、編集時の運用面でも注意が必要です。

短時間に大量のページを更新する操作は、システムに非常に大きな負荷を与えます。 更新直後のページはキャッシュが無効となり、すべてのアクセスに対してリアルタイム処理が必要になるため、サーバーの負荷が一時的に急増します。

たとえば、同じ文言を修正するために数百ページを一斉に更新すると、キャッシュが効かず、各ページで処理が繰り返されます。

WIKIWIKIには「全ページ文字列置換」といった便利な機能も用意されていますが、これを頻繁に使うような運用は、結果的にシステムに大きな負荷をかけることになります。

こうした事態を避けるためにも、情報の一元管理やテンプレート化といった構成上の工夫が重要です。 構造的に「編集回数を減らす」設計は、将来的な保守・負荷の両面で大きな効果をもたらします。

それでも負荷が高まってしまうときは

ページを軽量に保つ工夫をしていても、どうしても表現したいデザインや構成上の理由で、負荷が高くなってしまうことがあります。 そんなときは、WIKIWIKIが用意している「負荷軽減用プラグイン」の活用もご検討ください。

なお、以下に紹介するプラグインは高機能である反面、使い方を誤るとシステム負荷を増大させる可能性があるため、 ページ負荷やプラグイン仕様の理解がある方の利用に限定しており、公開範囲も制限しています。

負荷軽減用プラグイン

• lazy_fold：折りたたみ処理の遅延実行

  lazy_fold：折りたたみ処理の遅延実行

  通常の fold プラグインでは、見えていない部分も最初から読み込まれます。 一方、lazy_fold は、開いたときに初めて中身を処理するため、中身の容量が大きい折りたたみが多数あるページでも、読み込み時の負荷を抑えることができます。

  主な負荷軽減：転送量、サーバー処理

  使い方と補足

  • 種別：ブロック型プラグイン（{{ ～ }} で囲んで使用）
  • 基本動作：通常の fold と同様に折りたたみ機能を提供します。
    既存の fold を lazy_fold に置き換えて使うことができます。
  • 非同期読み込み：展開されるまで中身を読み込まないため、初期通信量が抑えられます。
  • 軽量化：大きなデータを持つ折りたたみでも、ページ全体が重くなりにくくなります。
  • ダイナミックレンダリング対応：検索エンジンのクローラーには、fold と同様に展開済みのHTMLとして出力されます（SEOへの影響はありません）。

  書式：

  #lazy_fold(ラベル,,ユニークID){{
      折りたたみ内部のコンテンツ
  }}

  各引数の説明：

  • 第1引数：表示されるラベル（任意）
  • 第2引数：本プラグインでは未対応。open* などの展開オプションは使用できません。
    ただし、open* を含む形式で指定された場合は、通常の fold として処理されます（lazy_fold の機能は無効になります）。
    開いた状態で使用したい場合は fold をご利用ください。
  • 第3引数：ページ内で一意となる任意の ID文字列（推奨）
    同じページ内でデータの切り貼りや組み合わせを行うプラグイン（例：特定のデータを再利用する機能） を使用していない場合は省略できますが、データの正確性を確保するために指定を推奨します。

  ご注意：

  • ネスト（入れ子）構造での使用
    lazy_fold は fold と同様にネストに対応していますが、深い階層ではユーザーが展開しない可能性が高く、 結果として負荷軽減の効果が薄れることがあります。※ネストとは、折りたたみの中にさらに別の折りたたみを入れる構造を指します。
  • 内容が数行程度しかない場合の使用
    内容が短すぎると、通常の fold を使った方が処理が軽く、効率的な場合があります。 負荷状況や構成に応じて、適切に使い分けてください。
  • ページの最上位で評価されるプラグインの使用
    ページの最上位構造で処理されるように設計されているプラグインは、 lazy_fold のような遅延読み込みプラグインの内部では、初期表示時に処理されないため正しく動作しません。
• lazy_accordion：アコーディオン形式の折りたたみ処理の遅延実行

  lazy_accordion：アコーディオン形式の折りたたみ処理の遅延実行

  lazy_fold と同様に、開いたタイミングで初めて中身を読み込む遅延処理型の折りたたみプラグインです。 見出しのような大きめのタップ領域で表示されるため、スマートフォンでも操作しやすく、誤操作を防ぎやすいのが特長です。

  主な負荷軽減：転送量、サーバー処理

  使い方と補足

  • 種別：ブロック型プラグイン（{{ ～ }} で囲んで使用）
  • 基本動作：通常の accordion と同様に折りたたみ機能を提供します。
    既存の accordion を lazy_accordion に置き換えて使うことができます。
  • 非同期読み込み：展開されるまで中身を読み込まないため、初期通信量が抑えられます。
  • 軽量化：大きなデータを持つ折りたたみでも、ページ全体が重くなりにくくなります。
  • ダイナミックレンダリング対応：検索エンジンのクローラーには、accordion と同様に展開済みのHTMLとして出力されます（SEOへの影響はありません）。

  書式：

  #lazy_accordion(タイトル,*|**|***,open|close,ユニークID){{
      折りたたみ内部のコンテンツ
  }}

  各引数の説明：

  • 第1引数：表示されるタイトル（任意）
  • 第2引数：見出しのレベル
  • 第3引数：open → 開いておく | close → 閉じておく
    ただし、open 形式で指定された場合は、通常の accordion として処理されます（lazy_accordion の機能は無効になります）。
    開いた状態で使用したい場合は accordion をご利用ください。
  • 第4引数：ページ内で一意となる任意の ID文字列（推奨）
    同じページ内でデータの切り貼りや組み合わせを行うプラグイン（例：特定のデータを再利用する機能） を使用していない場合は省略できますが、データの正確性を確保するために指定を推奨します。

  ご注意：

  • ネスト（入れ子）構造での使用
    lazy_accordion は accordion と同様にネストに対応していますが、深い階層ではユーザーが展開しない可能性が高く、 結果として負荷軽減の効果が薄れることがあります。※ネストとは、折りたたみの中にさらに別の折りたたみを入れる構造を指します。
  • 内容が数行程度しかない場合の使用
    内容が短すぎると、通常の accordion を使った方が処理が軽く、効率的な場合があります。 負荷状況や構成に応じて、適切に使い分けてください。
  • ページの最上位で評価されるプラグインの使用
    ページの最上位構造で処理されるように設計されているプラグインは、 lazy_accordion のような遅延読み込みプラグインの内部では、初期表示時に処理されないため正しく動作しません。
• fcache：一部出力のキャッシュ化

  fcache：一部出力のキャッシュ化

  特定のプラグイン表示やデータ取得に時間がかかる場合、fcache を使うことで、 その部分だけ処理結果をキャッシュし、高速に表示できるようになります。

  主な負荷軽減：サーバー処理

  使い方と補足

  • 種別：ブロック型プラグイン（{{ ～ }} で囲んで使用）
  • 基本動作：一部のプラグイン出力をキャッシュし、再表示時の処理負荷を軽減します。
    ページを表示するたびに都度実行されるような処理の重いプラグインの結果を一時保存し、 同じ内容を再表示する際にはキャッシュ済みの結果をそのまま表示することで、サーバーの計算負荷を大きく下げることができます。
  • キャッシュ削除のタイミング：
    • 関連ページが更新された場合
    • WIKIの設定が更新された場合
    • システムのアップデートが行われた場合
    • サーバーのキャッシュ管理により、自動的に削除された場合
    ※TTL(経過時間で削除)の設定はできません。

  書式：

  #fcache{{
      高負荷の処理
  }}

  引数なし：

  ご注意：

  • ecache をご利用の方へ
    

    fcache は、かつて提供されていた非推奨プラグイン ecache の後継です。 現在 ecache を使用している場合も、内部的には fcache のエイリアスとして動作するため、 基本的に同様の効果が得られます。

    新しく導入する場合は、より安定性と保守性の高い fcache をご利用ください。

  • fcache の使用は限定的に
    

    現在、fcache を使用しなくても、ページ全体に対して fcache で囲んだようなキャッシュ（レスポンスキャッシュ）が適用されており、 通常のページ構成であれば十分な効果が得られています。

    fcache は、特定の処理が重い箇所をピンポイントでキャッシュ化したい場合などにご活用ください。 効果的に使うことで、部分的な表示速度の改善やサーバー負荷の軽減につながります。

    ただし、使い方を誤ると返って負荷がかかることがありますので、ページの負荷状況を「負荷パネル」で確認しながら調整してください。

  各種キャッシュの動作や仕組みについては、「キャッシュについて」のガイドもあわせてご参照ください。

  負荷パネルについて キャッシュについて

これらはすべて、ページ構造を変えずに負荷を軽減できる補助的な機能です。 使い方や注意点については、各プラグインの解説をご確認のうえ、無理のない範囲でご活用ください。

なお、WIKIのページごとの負荷状況については、目に見えないリソース消費の参考値が確認できる「負荷パネル」を用意しています。 ご自身のページがどの程度負荷をかけているか気になる場合は、以下のボタンから詳細をご確認ください。

負荷パネルについて キャッシュについて

負荷軽減用プラグインは「おまじない」ではありません

「とりあえず入れておけば軽くなる」というものではなく、使いどころを見極めて、適切な場所に使うことが大切です。

状況に合わない使い方をすると、かえって表示や処理が不安定になったり、期待した効果が得られなかったりすることもあります。

負荷軽減用プラグインとWIKI構成のヒント（FAQ）

• エラーが出て内容が表示されない場合や、別の内容がずれて表示されることがあります

  ページ内でいくつか折りたたみを使っていて、試しに fold を lazy_fold に置き換えてみたんですが、 開いても中身が出てこなかったり、なぜか別のところの内容が表示されたりして戸惑いました。特にエラーも出ないので何が悪いのか分からず…。 「no content for ○○」って表示されることもあって、どう直せばいいのか悩みました。

  多くの場合、 lazy_fold や lazy_accordion などの lazy系プラグイン で、 引数にID（第3,4引数）を指定していないことが原因です。lazy系プラグインは、展開時に初めて中身を読み込む「遅延読み込み方式」を採用しており、 それぞれの折りたたみをページ内で一意に識別するためにIDが必要です。IDが省略されていると、中身が表示されなかったり、別の内容と混在してしまうことがあります。

  対処方法：引数に、ページ内でユニークなIDを指定してください

  #lazy_fold(詳細はこちら,,example-id){{
  ここに表示される内容
  }}

  省略できるケース：

  同じページ内でデータの切り貼りや組み合わせを行うプラグイン（例：特定のデータを再利用する機能） を使用していない場合は省略できますが、 データの正確性を確保するために指定を推奨します。

• lazy系の中に目次（contents / contentsx）を入れると、目次が表示されません

  目次が長くなってきたので、lazy_fold の中に contents を入れてみたのですが、なぜか目次が表示されませんでした。

  contents や contentsx は、ページの最上位構造で処理されるように設計されており、 lazy_fold のような遅延読み込みプラグインの内部では正しく動作しません。これは fold とは違い、lazy 系は表示タイミングが後になるため、目次生成のタイミングとずれてしまうためです。

  なお、include を使って読み込んだ内容に contents が含まれていても、lazy_fold で囲んでいる場合は目次は表示されません。

  これは include の使い方によるものではなく、 contents が正しく表示されるには「ページの最上位で評価される」という条件を満たす必要があるためです。

  また、初期表示時に最上位で評価されることを前提としたプラグインは他にも存在します。 たとえば、ページ全体の構造をもとに採番を行うようなプラグインは、lazy_fold 内では正しく動作しない場合があります。

  折りたたみの中に配置する際は、このような仕様の影響を受ける可能性がある点にもご注意ください。