Web の画像まわりには、依然として偶発的な複雑さがあります。「最初はこれでいい」設定、そのうち効かなくなるサードパーティ、そしてインジェスション・変換・配信を一つのホットパスに溶かしたときのレイテンシの崖。
lazy-image を始めた筋
入り口は 圧縮 でした。拡張子ごとの違いは知っていても、エンコーダの選択とパラメータ次第では ストレージと転送量 に現実的な差が出る。利用者全員に画像工学を強いるのではなく、予測可能な核の中で圧縮を押し込むことが面白い。
その先に置いているのは エッジコンピュートでも動く画像処理エンジン です。アプリサーバの奥深くに閉じこもるツールではなく、トラフィックに近いところで意味を持つものにしたい。
lazy-image を Sharp のような万能ツール にすることは狙っていません。Pure Rust で圧縮と現代的なエンコーダに寄せ、V8 上の WASM へ続く筋を通す — Node における従来のネイティブ依存の負担を、構造から少しずつほぐすための賭けです。
分離はいまも有効
インジェスション / 変換 / 配信 は分離したまま最適化したほうがよい。三つを一つのリクエストパスに詰め込むと、レイテンシの尖りや競合を抱え込みます — 変換が Rust でも WASM でも同じです。
OSS にしている理由
自分のクラスタが少し楽になるのは副産物で、最適化された OSS を通じて世界の処理能力を少し効率化したいのが本心です。核が開いていて採用しやすければ、勝ちは自分の外側にも積み上がる。完成度をすべて語れる段階ではなくても、まだ方向を選べるうちに構造を共有したい — それが公開の意味です。