なんだかんだでまだチューニングの余地があった。

前にCopilotに改修させてビルドが早くなった話をしたが、実はそれ以降も人力でちまちまチューニングをし続けている。

Pagesのビルド時間は課金されないのでそこにモチベーションはないのだが、校正フェーズでちまちま書き換えてはそのたびにビルドが走るので、そこを圧縮して執筆を軽くする目的でやっている。

何をやったか

基本的には「ポストプロセッサで処理の内容ごとにDOM要素をクエリしていたものを、セレクタを結合して1回のスキャンで全部まとめて取得して内部で分岐する」「複数回出力されるもの(サイドバーや各エントリのプレビュー、Atomフィード用エントリ、画像のメタデータなど)は全部一回計算したものをキャッシュに載せて使い回す」「配列の端のいくつかしかレンダリングしない項目は、Nunjucks側でのループ内で読み飛ばすのではなく配列の切り詰めを先にやる」など、最も愚直で基本的な「無駄の排除」をやった。

ちなみにこの間も機能強化をし続けていていろいろと処理は足されているし、もちろん記事数もぐっと増えている。

成果

こちらがCopilotによる改修直後、細かい改修のお知らせを出したときのビルドログ。

01:34:30.465	Executing user command: npx @11ty/eleventy
01:34:52.005	[11ty] Benchmark   2772ms  14%  1100× (Configuration) "cleanUp" Transform
01:34:52.007	[11ty] Copied 112 Wrote 1100 files in 20.46 seconds (18.6ms each, v3.1.2)
01:34:52.072	Finished
(略)
01:35:01.093	Uploading... (1251/1251)

ポストプロセッサ部分(cleanUp)は1100回実行で2772msなので、1回あたり2.52ミリ秒。ビルドコマンドの実行時間は、タイムスタンプベースで21.607秒。アーティファクト数が1251なので、1ファイルあたり17.27ミリ秒。

この頃は記事内で参照されていない画像もまとめてコピーしていたのと、mixiに貼っていた画像はmixiの解像度上限を迂回するために分割してあったのもあり、アーティファクト内には実際には使われない画像も含む11.5%くらいの画像ファイルがあったはずである。

さて、気になる現在。これは一つ前の記事を公開したときのビルドログ。

01:28:11.851	Executing user command: npx @11ty/eleventy
01:28:36.117	[11ty] Benchmark   3385ms  15%  1606× (Configuration) "cleanUp" Transform
01:28:36.119	[11ty] Copied 7 Wrote 1606 files in 23.21 seconds (14.5ms each, v3.1.2)
01:28:36.191	Finished
(略)
01:28:48.991	Uploading... (1756/1756)

ポストプロセッサは1回あたり2.11ミリ秒。ビルドは24.340秒で1アーティファクトあたりで13.86ミリ秒。

画像ファイルのコピーをポストプロセッサ内に移して、実際に使用されている画像しか転送しなくなったことと、mixiの記事の移行/分割画像の統合が完了したこともあって、アーティファクトに占める画像ファイル比は多分8.1%くらいに下がっているので、1アーティファクトあたりの短縮率はちょっと派手めに出ているはず。

I/O分がポストプロセッサの時間に載ってきたのに、それでもまだ以前より1実行が速いので、やはり愚直な最適化はきっちりやればかなり効果があるようだ。もっとも、一部の調整はコードの可読性を下げているし、記事数が多ければキャッシュがあふれるので、こういう個人ブログだからこそ実践できたという部分もあるだろう。

ところでこのビルドログのタイムスタンプを見ると、手元で記事の公開操作を行ってから実際にそれが本番環境で公開されるまでに、最終の確認・校正の時間がかなり長く取られていることがよくわかる……。やはりマイクロブログのような手軽さはなかなか出せない……。