ブラウザでPythonを動かす学習アプリと、COOP/COEP を入れなかった理由

01 — 前提

サーバーが無くても動くこと

このアプリは、通信が不安定な場所での利用を想定しています。 コードを実行するたびにサーバーへ送る作りでは、回線が切れた瞬間に学習が止まります。 そこで Python の実行を WebAssembly でブラウザ内に持ち込み、一度読み込めばオフラインでも動く形にしました。

代償として初回の読み込みは重くなります。それでも 一度きりの重さと、毎回の通信を比べたとき、想定している環境では前者のほうが現実的だと判断しました。

02 — トレードオフ

cross-origin isolation を有効にすると何が起きるか

WebAssembly でスレッドを使う経路を有効にするには SharedArrayBuffer が必要です。 そしてこれを使うには、サーバーから COOP と COEP の2つのヘッダを返して、 ページを cross-origin isolation の状態にしなければなりません。

ここに落とし穴があります。この状態にすると、 明示的な許可ヘッダ（CORP）を返さない外部リソースが、すべて読み込めなくなります。 画像もスクリプトも広告も同じで、相手側がヘッダを付けてくれない限りどうにもなりません。

03 — 判断

速度より、続けられることを取った

結論として、COOP と COEP は設定しませんでした。 理由は、このアプリを無料で公開し続けるための広告が読み込めなくなるからです。 実行はスレッドを使わない経路にフォールバックしますが、 学習用の短いコードを動かす用途では体感できるほどの差にはなりませんでした。

重要なのは、これが「速いほうが正しい」という話ではないことです。個人開発では、 続けられる形に収まっているかどうかが技術的な最適解より優先することがあります。 同じ選択をする人が後で迷わないように、設定ファイルにこの判断の理由をコメントとして残しました。 設定を消した理由はコードに残らないので、書いておかないと必ず「なぜ無いのか」で揉めます。

このアプリについてはVisual Coding Lab の紹介ページにまとめています。