アストラエ・オラティオ(Astrae Oratio)／BlueArchive_team_fandom

やや処理時間掛かっているのはきっと行数が多いせい(1000行〜ある)。
(例外：誕生日リマインダーの呼び出しだけはコストのある処理)

• 原神WikiのMenuBarがほぼ同じ行数。

• 一部はまとめて子ページに移す必要がありそうです。

• ページ下部に溜めまくった私のコラムなんかは個別ページに格納してよいかも。
  ブルアカ(フェミニズム)って文言だけは魔除け代わりにメニューへ置いておきたい vs 中身の列挙は子ページで十分
• 子ページを網羅する場所⇨ショーウィンドーと役割切り替える的な……

現在の重さ

許容可能な範囲……と言い張れるギリギリの水準。
(ややあやしい)

• サ開前には改善しないと絶対重くなりすぎる。
  (年間30キャラ追加/NPCさらに追加へ耐えられる設計ではない)

重い原因

1. キャラ・クランデータベース読み込み処理(FrontPage/moduleのincludex呼び出し)
   • キャラ・クラン・旧作キャラで3回呼んでいる。たぶん重さの大半ここだと思います。(未検証)
2. イラスト・PVアーカイブ(？)
   • 遅延読み込みプラグイン(lazy_fold)を用いているため、そこまで重くないかも。
3. レイアウト用の装飾あれこれ
   実処理への影響不明。
   • それぞれ切り出した検証用ページ作って正確な負荷の原因を試すのがよさそう？

キャラ・クランデータベース呼び出し処理が負荷の中心。
↓

• ①キャラの顔一覧を並べる上で避けようのないコスト
• ②設計由来の避けられるコスト
  • 要切り分け。

↓
とりあえずの軽量化：最新以外のビジュアル/PVを専用のアーカイブページに置くように変更。
↓

1. &iconプラグインを用いたキャラサムネイル読み込みに変更。
2. クランサムネイルも同様に変更。
   (ついでにサイズ2/3まで縮小)
   • FrontPage専用のデータベースを増やしました。(更新の手間が2倍！)
     表示速度のための犠牲。

鳴潮Wiki

データベース形式の非採用(キャラアイコン手動並べ)、48x48サイズのwebp形式。

• このWikiのキャラバナー(250x335サイズ,png形式)よりずっと軽量。
  • ただしこのWikiキャラバナーは30%縮小で表示しており、実サイズは約75x100。
    拡大時の画質と引き換えに余分な負荷が生じている気がする。
    ↓を使ったら負荷が減るかも？

原神Wiki

同様に手作業。&iconプラグインって機能(かなり内部処理寄り？)を使っているようです。

• 技術的にはcssスプライトという機能だそう。
  (頻用かつ常にセットで読み込む画像グループを内部で一枚にまとめる⇨ファイルアクセスを最小化する？)

⇨データベースそのものは維持しつつ(各ページで用いるメリットが大きいので)、FrontPageのキャラ追加は手作業化した方がよいかも？
[要検証：画像サイズが悪いのかデータベース形式が悪いのか]

クロノアークWiki

重い物を何も置かないことで軽さを実現している？

トリッカルWiki

裏の処理にキャラデータベースを採用しているWiki。(私が真似たのはここ)

• たしかに相対的重めグループ。