ページ負荷軽減対策

はじめに

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

負荷の種類

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

処理をする場所	処理の流れ	負荷が掛かる場所	対策例
サーバ （WIKIWIKI）	① ページファイルの読み込み	サーバのストレージ	includeプラグインの削減 ecacheプラグインの使用
	② HTMLへの変換	サーバのCPU・メモリ
	③ ページの送信	Webサーバ（サーバのCPU・メモリ）・ルータ等	画像の削減・サイズ縮小
クライアント （PC・スマホ等）	④ ページの表示	クライアントのCPU・メモリ	ページ分量の削減 YouTubeの埋め込み等の削減

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

サーバのストレージに保存されたページファイルをメモリ（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プラグインを使用しない純粋な分割を指します。
ページの閲覧に支障が出るほど重くなっているページは往々にしてページ内の移動が大変なほど分量が多くなっているケースが多いです。
小手先の方法で負荷低減を試みるくらいであれば、思い切ってページを分けてしまった方が余計な手間が掛からない上に確実な効果が見込めます。
例：所属ライバーまとめ、月ノ美兎/詳しく知りたい

ecacheプラグインを使用する

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

コンテンツを減らす

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

HTMLデータ量削減

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

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.」を参考にするのがよいかも。