ページ負荷軽減対策

はじめに

多くの皆さんの協力のおかげでにじさんじ非公式wikiは日々成長を続けています。
その一方で、ページ分量の増大に伴い負荷も年々上がってきており、WIKIWIKIのサービス提供元より直々に改善要請を受けるケースも出てきました。
負荷の低減内容によってはページ表示時間の短縮・通信量削減など閲覧者にもメリットが生まれる可能性があります。編集に慣れてきたら負荷低減対策も検討してみてください。

公式情報

WIKIWIKIの公式サイトにも負荷の確認方法や負荷対策・高速化技術に関する情報が整備されてきています。併せてご確認ください。

• 負荷パネルについて - WIKIWIKI
• キャッシュについて - WIKIWIKI
• CDNについて - WIKIWIKI
• 快適なページ作りのためにできること - WIKIWIKI

負荷の種類

一口に負荷と言っても様々な種類が存在します。
wikiにアクセスした際、どのような処理が行われてどこに負荷が掛かるかを以下の表に示します。

①ページファイルの読み込み

サーバのストレージに保存されたページファイルをメモリ（RAM）に読み込む処理です。
ファイルサイズ（ページの分量）はもちろん、ストレージへのアクセス回数も負荷に影響します。

例えば、1000行のページとそれを100行ごとに10分割したページがあったとします。
前者をそのまま表示した場合と、10分割したページをincludeで結合して表示した場合で見え方は全く同じで合計サイズもほぼ同じですが、ページ分割されている分ストレージへのアクセス回数も増えるため、負荷としては後者の方が重くなります。さらにページ結合処理も加わるため、アクセス回数増加以外の観点からも負荷増となります。

「ページを分割してincludeすれば負荷が下がる」と思っている人もいるかもしれませんが、これは原理的に考えると逆効果になります。

②HTMLへの変換

ページ編集で記述した文をPCやスマホのブラウザの表示形式に変換する処理です。
ページ内でwikiの構文やプラグインを多用すると負荷が上がります。

実例：過去にFrontPageの負荷が高いとWIKIWIKI運営元より指摘が入ったことがあり（編集談義/自由討議 2023-01-18 (水) 18:27:31）、特に画像表示のために使用しているref系の変換処理で負荷が掛かっているとのことで調査したところ、FrontPageがincludeしている配信ページ ジャンプリストが原因とみられることがわかりました（refが1600回以上使用されている。現在は対象ページをリンク参照にすることで対策済み）。

③ページの送信

ページのサイズが大きい場合、サーバからの送信時に負荷が掛かります。

添付ファイルのサイズについて

過去に本wikiの画像転送量が問題となったことがありますが、WIKIWIKI運営元の直近の見解によればCDNを使用するようになっているため（編集談義/自由討議 2023-01-20 (金) 17:49:54）現在においては考慮する必要性は薄いとみられます。

④ページの表示

PCやスマホ等のWebブラウザでは、サーバから取得したページを表示するためにレンダリングという処理を行います。
ページの内容が複雑で長大であるほどレンダリングの負荷も上がります。
YouTubeやTwitterの埋め込みなどの外部サイトも負荷がかかる要因になります。

負荷の確認方法

サーバのパフォーマンス

ページ右上にあるタコメーターのアイコンと時間（ミリ秒）が表示されている領域をクリックするとサーバに掛かっている各種負荷を確認できます。(詳細)

ページ表示のパフォーマンス

上記の数値に問題が無くてもページの内容が多く複雑であれば表示に時間が掛かる場合があります（ecacheを使用しているページなど）。
パフォーマンスは以下のようなツールを用いて定量的に評価可能です。もしスコアが悪い場合は閲覧者にとって不快な遅延が生じている可能性があります。

• ブラウザの開発者ツール（最新のブラウザにはパフォーマンス評価機能が備わっている場合があります）
• Googleが公開しているPageSpeed Insights

負荷の軽減方法

【基本】ページを分割し、リンクに置き換える

ここでいう分割とはincludeプラグインを使用しない純粋な分割を指します。
ページの閲覧に支障が出るほど重くなっているページは往々にしてページ内の移動が大変なほど分量が多くなっているケースが多いです。
小手先の方法で負荷低減を試みるくらいであれば、思い切ってページを分けてしまった方が余計な手間が掛からない上に確実な効果が見込めます。
但し、過度に分割することで回遊性が悪化し味気ないページなってしまったり、検索機能などで影響を及ぼすこともあるので注意は必要です。
例：所属ライバーまとめ、月ノ美兎/詳しく知りたい

【上級者向け】lazy系プラグインを使用する

ページ内の一部のコンテンツの読み込みタイミングを遅らせることで負荷を低減するLazy Loading（遅延読み込み）という技術があります、
WIKIWIKIではfoldプラグイン、accordionプラグインのlazy版といえるlazy_foldプラグイン、lazy_accordionプラグインが用意されています。

快適なページ作りのためにできること - WIKIWIKIのページ末尾にこれらプラグインの使用方法が記載されていますが、以下の注意書きの通りそれなりの知識が必要となり、よく考えて使用する必要があります。

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

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

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

• lazy_fold、lazy_accordion内の分量が大して多くない場合はあまり効果が得られない。
• lazy系プラグインの内部で、contents系プラグインといったページの最上位で評価されるプラグインの使用は不可。
• 引数でユニークIDをしておかないと、include系プラグイン使用時に正しく表示されなくなる。
  プラグインの仕様上ユニークIDはオプション扱いだが、lazy系プラグインの使用を検討するレベルの分量があるページは大抵include系プラグインも導入していると考えられるため、ユニークIDは常に付与する癖をつけておいた方が良い。
• areaeditプラグインとの共存はユニークIDが付与されていてもバグが発生するため、現在の仕様では不可能であることに注意。

その一方で享受できるメリットも大きいです。先に説明したページ分割・リンク置き換えと比較した場合のメリットは以下の通りです。

• ページ遷移が不要なためユーザビリティが向上する。
• ページ全体の再読み込みが不要となるため、適切に使用すればリンク置き換えよりも負荷が低減する。

コンテンツを減らす

大量の画像埋め込み・表埋め込みなどは変換後のHTMLタグが長いため負荷が高くなりやすく、これらのコンテンツを削れば軽減することができます。
ただし、大幅なレイアウト変更や他の編集者との合意などを伴うことになるため、実行のハードルも高いとみられます。

ecacheプラグインを使用する

HTMLへの変換で出力されたファイルをサーバ上にキャッシュとして一次保存するプラグインです。
変換頻度を下げることができるのでアクセス数が多いページほど効果的です。
①②の負荷はこのプラグインを使用すればほぼ全てのケースで解決できます。ただし③④の負荷はecacheプラグインでは低減できません。
非推奨プラグインになりました。使用しないようにお願いします。

HTMLデータ量削減

2023年7月ごろからページ右上のタコメーターアイコンでHTML データ量を確認できるようになった。とともに、HTML データ量が1MB以上だとページ上部に下記のような警告表示が常に出るようになった。以下にHTML データ量を削減する方法などを記載する。

ご注意：コンテンツサイズは 1 MB 未満（できれば 500 KB 以下）に抑えていただけると、 サービス全体をより快適にご利用いただけます。大きくなりすぎていない場合は特に問題ありません。 内容が多くなってきた場合は、ページを分割して整理することもご検討ください。

HTMLデータ量が多いと何が悪いのか？

にじさんじwikiのデータ転送量が多くなる。データ転送量が多いと隔離サーバーに移されてページ表示されるまでが遅くなったり、最悪中の最悪のケースでは「転送量が多すぎて負担になっているのでにじさんじwiki閉鎖」という事態もありうる*1。

HTMLデータ量を減らすには

includeを減らしてリンクに置き換える

includeで他のページを取り込むと、取り込んだページがまるまる読み込まれるため、取り込み先のページのHTMLデータ量がそのまま取り込み元のページに加算される。つまり、includeすればするほどHTMLデータ量はどんどん多くなる。HTMLデータ量の警告が出ているケースで一番多いのが「いろんなページをincludeしすぎている」パターン。特にライバーページでは「詳しく知りたい」の子ページがたくさん作られ、それら全てをincludeしているためにHTMLデータ量が多くなっているパターンが非常に多い。
こういった場合に有効なのが、includeではなくリンクに置き換えること。こうすればリンク先のページをまるまる読み込むことなく、読みたい人だけがリンク先のページに飛ぶので、includeに比べてHTMLデータ量を劇的に減らせる。ただ、閲覧者の立場からすると、それまでそこにあったものがいきなり消滅してリンクになった、というように映るため、リンクへの誘導文をつけるのが親切かも。

過去のデータを別ページに移す

includeに次いで多いのが、過去のデータをページ分割せずそのままにしているためにHTMLデータ量が多くなっているケース。特にライバーページの「詳しく知りたい」「宣伝」「スケジュール」「動画一覧」でこのケースが多い。
過去のデータを見に来る閲覧者は全体からすればそれほど多くないので、過去のデータをページ分割してリンクに置き換えるのが有効。

画像を減らす

意外に思えるかもしれないが、画像を表示するためのHTMLデータ量は大きい。←こういうライバーの顔画像や←こういうロゴ画像を多用しすぎるとHTMLデータ量がかさむ原因になる（配信ページ ジャンプリストが典型例）。
とはいっても、画像を使わないようにするにはページ構成から考え直しになってしまうため、現実的な解決策ではないかもしれない。

アクセス数が少ないならそのままにしておく

そもそも何でHTMLデータ量を減らすのかといえば、にじさんじwikiのデータ転送量を減らすため。データ転送量＝HTMLデータ量×アクセス数 なので、アクセス数の多いページのHTMLデータ量を減らせば大きな効果が見込めるし、逆にアクセス数が少ないページのHTMLデータ量を減らしてもそれほど効果は見込めない。今日100に載っているようなページはもちろん要対処だが、アクセス数の少ないページであれば無理に削減しないことも一つの手である。
ページのアクセス数はメニューバーの一番下で確認できる。下のように表示され、「T.」が本日のアクセス数、[Y.」が前日のアクセス数である。「T.」は0:00からのアクセス数であるため、24時間分のアクセス数を反映している「Y.」を参考にするのがよいかも。