ローディングの最適化
登録情報とキャリアを保ち、起動・保存・日付進行の重複処理を整理。
測定結果
同じ独立セーブで変更前後を各３回計測。下表は中央値。起動時間には必要なゲーム状態の準備、現行画面の描画処理、最初の本保存を含む。
| 起動ケース | 変更前 | 変更後 | 短縮 |
|---|---|---|---|
| 新規キャリア | 4.63秒 | 3.42秒 | 26% |
| 保存済みキャリア | 2.02秒 | 1.34秒 | 34% |
| ２シーズン目 | 3.19秒 | 1.64秒 | 49% |
２シーズン目の翌日進行は1.45秒 → 1.12秒。スクリプトの読み込み量は20.38MB → 4.81MB（約76%削減）、読み込み本数は135 → 121。
以前の保存・再開改善の参考値は約1.42秒。今回、保存保持を確認する再開テストでは約0.95秒を記録した。上表はより重いキャリアを含む別条件での反復比較であり、すべてのキャリアに同じ待ち時間を保証するものではない。
Windows・Edgeの独立ブラウザー／ローカルHTTP／1280×900px。外部ネットワークは遮断し、ブラウザーキャッシュを無効にして比較。保存保持の再開テストは390px。端末の負荷やセーブの規模、画像のキャッシュ状況で体感時間は変わる。
整理した処理
- 必要な情報を読込完全なデータを圧縮配信
- ゲーム状態を準備クラブ照合・名簿検索を再利用
- 現行画面を描画１回の描画・メニュー位置はCSS
- 進行を保存本保存の確定済み内容を自動保存へ
- 22個の純粋なデータ定義を可逆圧縮。18.31MBを2.74MBへ縮小し、隣接したデータをまとめた。写真の参照先・プロフィール・能力・公式スタッツなどの項目は削除していない。動作スクリプトは元の実行順とファイル境界を保つ。
- キャリアを開く際に展開した各区画を再利用し、変更のない情報を再圧縮しない。保存時には内容全体を照合するため、同じオブジェクト内の変更も取りこぼさない。
- 自動・手動の復旧セーブには、本保存へ実際に書き込んだ文字列を再利用。メタ情報とメンバー表は切り離して保持し、未保存の編集で過去のセーブが変わらないようにした。より新しい試合チェックポイントがある場合は従来どおり統合する。
- 起動中のクラブ別名簿検索、正規化したクラブ名、国籍名の表示準備を再利用。移籍・ローンで所属が変われば名簿を更新する。
- 下部メニューをCSSで画面枠に合わせ、画面描画ごとの強制レイアウト計算を除去。既存の配置と見た目を維持した。
新規キャリアの開始時には、現在日までの他クラブの試合や状態を準備するため、再開より時間がかかる。試合や日次処理を省略して速度を上げる変更は行っていない。
検証と適用
９組の変更前後比較で、翌日進行後のキャリア全体が一致。編成、戦術、移籍・契約、育成、大会・結果の差異がないことを確認した。比較用の日時・乱数の固定はテスト内だけで使用している。
- 試合途中の時計・統計・交代・体力・戦術、未適用の下書き、同じ試合結果への継続、終了時の二重集計防止。
- 旧形式セーブの移行、完全バックアップとKIT画像の復元、保存失敗・容量不足・別タブ競合・破損データの復旧。
- 確定済み保存の再利用、メタ情報の独立性、最新チェックポイントの反映、復旧セーブの保持件数。
- 最初の描画が現行デザイン１回のみ、ファイル読み込み失敗と再試行、Club／Academyの下部メニュー配置を320〜1800pxで確認。
- 前回の公式写真の選定・参照経路、良好なクラブ写真とキャリアの保持。
プレイ中の実セーブには触れていない。アプリを再読み込みすると適用される。ブラウザーの保存データを削除する必要はない。
データの元ファイルは残している。改修後はscripts/build-touchline-styles.cjsでデータ配信・CSS・スクリプトの更新番号を再生成する。データと読み込み順の基準はassets/touchline-data-build.json。