Chrome は Manifest V2 を静かに殺しました。ある日、Web ストアは MV2 の提出の受け付けを停止しました。インディー製品スタックの一部としてブラウザ拡張機能を構築している場合、その期限はすでに過ぎています。マニフェスト V3はもうオプションではありません。それは町で唯一のゲームです。

問題はMV3を採用するかどうかではありません。問題は、プラットフォームとの戦いをやめてプラットフォームと連携し始めるために、アーキテクチャをどのように再考するかです。その変化は、ほとんどのチュートリアルが認めているよりも大きいです。

MV3 が別のランタイムのように感じる理由

MV2 バックグラウンドスクリプトは、スリープしないサーバーのようなものだと考えてください。変数はそこに永続的に存在しました。タイマーは確実に時を刻みます。状態は常に暖かく準備ができていました。

MV3 ではこれを次のように置き換えます。サービスワーカー。 Service Worker は一時的に動作するように設計されています。 Chrome は、メモリ不足が発生するたびにそれらを終了し、次のイベントのために起動することができます。 2 つのタブのアクティブ化の間にワーカーが生きているという保証はありません。

これはバグではありません。それはデザインです。 Chrome は、悪意のある拡張機能の攻撃対象領域を減らすために、このトレードオフを行いました。そのトレードオフに同意するかどうかは重要ではありません。アーキテクチャはそれを考慮する必要があります。

より深い意味は、バックグラウンドスクリプト内の変数に保存したものはすべて致命的になるということです。外部永続層が必要です。クロム.ストレージは便利な API ではなく、唯一の信頼できる情報源になります。

ストレージの問題は思っているよりも大きい

chrome.storage.local の上限はデフォルトで 10MB です。設定を保存する単純な拡張機能の場合は、これで十分です。 API 応答をキャッシュしたり、ユーザーの行動を追跡したり、ドキュメントコンテンツを保存したりする拡張機能の場合、10 MB はすぐに消えてしまいます。

ほとんどの開発者が見落としている解決策は、インデックス付きDB。これはブラウザ内に存在し、ギガバイトのデータを処理し、トランザクションをサポートします。 Service Worker、ポップアップページ、コンテンツスクリプトからアクセスできます。ただし、古い Chrome バージョンでは、Service Worker による IndexedDB へのアクセスに信頼性のバグがありました。このルートに進む場合は、Chrome 102 以降をターゲットにしてください。

以下は、MV3 Service Worker で確実に動作する最小限の IndexedDB セットアップです。

// storage.js、SW、ポップアップ、およびコンテンツ スクリプトで動作します
const DB_NAME = 'MyExtensionDB';
const DB_VERSION = 1;

エクスポート関数 openDatabase() {
  return new Promise((解決、拒否) => {
    const req = IndexedDB.open(DB_NAME, DB_VERSION);

    req.onupgradeneeded = (イベント) => {
      const db = イベント.ターゲット.結果;
      if (!db.objectStoreNames.contains('cache')) {
        const store = db.createObjectStore('cache', { keyPath: 'key' });
        store.createIndex('タイムスタンプ', 'タイムスタンプ', {一意: false });
      }
    };

    req.onsuccess = (event) =>solve(event.target.result);
    req.onerror = (イベント) =>拒否(event.target.error);
  });
}

非同期関数のエクスポート saveRecord(key, data) {
  const db = await openDatabase();
  return new Promise((解決、拒否) => {
    const tx = db.transaction('キャッシュ', '読み取り書き込み');
    tx.objectStore('cache').put({ キー、データ、タイムスタンプ: Date.now() });
    tx.oncomplete = 解決;
    tx.onerror = 拒否;
  });
}

このパターンでは、クラッシュから無料で回復できます。 Chrome がセッション中に Service Worker を強制終了しても、データは残ります。 SW が再起動すると、IndexedDB から読み取り、正常に再開されます。

タイマーは以前のものではありません

Solo 開発者は、スケジュールに従って作業を実行する必要がある拡張機能を構築することがよくあります。コストトラッカー、リマインダーツール、または同期ユーティリティを思い浮かべてください。 MV2では、セット間隔バックグラウンドスクリプトに追加したまま忘れていました。

MV3 では、そのアプローチは崩れます。 Chrome は、次の間隔が起動する前に Service Worker を終了する場合があります。隙間ができてしまいます。見逃したアップデートが届きます。イライラしたユーザーがバグレポートを提出することになります。

交換品は、クロムアラーム。アラームは Service Worker の再起動後も持続します。 Chrome は、各アラームイベントを処理するために SW を起動します。制限は最低 1 分です。 5 秒ごとにアラームを鳴らすことはできません。

1 分未満の更新の場合、適切なパターンは分割アプローチです。ポップアップページは独自に実行されますセット間隔ポップアップページは表示されている間は安定したライフサイクルを持っているため、開いている間は。アラームは、ポップアップが閉じられたときの永続化を処理します。これは、リアルタイム表示の場合とバックグラウンドでの永続化の場合の両方をハッキングなしでカバーします。

不意を突かれるセキュリティ要件

MV3で引き締めたコンテンツセキュリティポリシー大幅。 MV2 で機能していた 2 つのパターンは、拡張機能のレビューを中断するか、実行時エラーを引き起こします。

リモートスクリプトの実行なし

拡張機能が CDN からスクリプトを取得して動的に実行した場合、それはなくなります。すべての JavaScript は、送信時に拡張機能にバンドルする必要があります。これは、外部 URL からグラフライブラリ、分析スクリプト、またはユーティリティコードをロードした拡張機能に影響します。

修正は簡単です。次のようなビルドツールを使用して、すべてをローカルにバンドルします。エスビルドまたはロールアップ。より小さく、より高速で、監査可能なバンドルが得られます。新しいストアへの送信がなければ、JS 更新をプッシュできなくなります。それに応じてリリース周期を計画してください。

innerHTML は責任です

MV3は禁止してないよ内部HTML完全に。ただし、ユーザーが提供したコンテンツまたは API が取得したコンテンツでこれを使用すると、レビュー担当者がフラグを立てる XSS ベクトルが作成されます。 CSP の厳格化により悪用は難しくなりますが、動的コンテンツに innerHTML の使用を完全に中止するのが正しい行動です。

DOM 作成メソッドに切り替えます。使用document.createElementそしてテキストコンテンツあなたが完全に管理していないデータについては。これにより、拡張機能の監査も容易になり、Web ストアのレビューが迅速化されます。

Solo 開発者が MV3 に実際にかかる費用

ここでのトレードオフについて正直に話しましょう。 MV3 への移行は無料ではありません。お支払い金額は次のとおりです。

さらに非同期コード:読み取られたすべての状態がストレージにヒットします。さらに await 呼び出しを作成します。エラー処理の追加。認識上のオーバーヘッドが増加します。
レビューサイクルが長くなる:CSP が厳格化すると、レビュー担当者の精査が厳しくなります。最初の MV3 提出には追加の時間を確保してください。
アラームの粒度の制限:最短 1 分では、特定の製品のアイデアが完全に無効になります。バックグラウンド価格チェッカー、リアルタイムトラッカー、ハートビート機能はすべて再設計する必要があります。
バンドル規律:リモートスクリプトがないということは、ビルドパイプラインが重要であることを意味します。まだ適切なバンドラーを持っていない場合は、適切なバンドラーが必要です。
IndexedDB の複雑さ:Promise ベースの API は冗長です。早めにラップするか、次のような薄いライブラリを使用してください十分に文書化されたストレージの抽象化参考パターン用。

さらに、強制的にどこでも非同期にするアプローチにより、テスト方法が変わります。同期状態読み取りに依存する単体テストは書き直す必要があります。これを移行の見積もりに織り込んでください。

MV3 があなたに与えるもの

制約には実際の利点があります。非同期優先モデルとは、拡張機能がデフォルトでブラウザの再起動とクラッシュを適切に処理することを意味します。 Chrome が更新されてもユーザーの状態は失われません。拡張機能はセッション間で予測どおりに動作します。

セキュリティの強化は信頼にもつながります。長年にわたるマルウェアの話を受けて、ユーザーは拡張機能に対する疑念を強めています。クリーンで監査可能なバンドルを備えた MV3 上に構築された拡張機能は、懐疑的なユーザーにも説明しやすくなります。拡張機能を公に宣伝する場合、その信頼シグナルが重要になります。あ無料のソーシャルメディア監査ツール拡張機能のマーケティングがプラットフォーム間で適切な信頼性シグナルを発信しているかどうかを評価するのに役立ちます。

さらに、強制バンドル規則により、多くの場合、より小さくて高速な拡張機能が生成されます。遅延読み込みは、意図的なコード分割に置き換えられます。制約の副作用としてパフォーマンスが向上します。

次の拡張機能ビルドの実践的な手順

新しい拡張機能を今すぐ開始する場合、または移行を計画している場合は、具体的なチェックリストを次に示します。

拡張機能に必要なすべての状態を監査します。 chrome.storage.local に何を入れるか、IndexedDB に何を入れるか、オンデマンドで何を派生できるかを決定します。
すべてのバックグラウンドの setInterval 呼び出しを chrome.alarms に置き換えます。 1 分未満のバックグラウンド更新が必要な機能を再設計します。
すべての依存関係をローカルにバンドルします。拡張コードの最初の行を記述する前に、esbuild または Rollup をセットアップします。
外部データを処理するすべてのファイルで、innerHTML の使用を DOM メソッドに置き換えます。
openDB ヘルパー関数を一度作成すれば、それをどこにでもインポートできます。すべてのモジュールで IndexedDB セットアップを書き直さないでください。
Service Worker の終了を明示的にテストします。 Chrome DevTools を使用して SW を手動で停止し、拡張機能が正しく回復することを確認します。

のweb.dev 学習リソースService Worker のライフサイクルを詳しく説明します。バックグラウンドロジックを構築する前にそのドキュメントを読んでおくと、後でデバッグする時間を節約できます。

MV3 ワークフローに適合するツール

拡張機能を構築する個人開発者は、あらゆる帽子をかぶっていることがよくあります。コードを記述し、UI を設計し、マーケティングを担当します。ツールチェーンをスリムに保つことが重要です。

ベータテスト中に拡張機能を共有するには、無料のQRコードジェネレーター追加の設定を行わずに、Chrome ウェブストアのリストにスキャン可能なリンクを作成できます。対面でのデモやカンファレンスブースに便利です。

拡張機能がスクリーンショットをキャプチャするか画像を処理する場合、AI背景除去ツールWeb ストアのリスト用にクリーンなプロモーションアセットを迅速に作成するのに役立ちます。

起動する前に、拡張機能のランディングページを実行します。無料のウェブサイトグレーダーオーガニック検索に悪影響を与える可能性のある SEO とパフォーマンスの問題を発見します。

拡張機能が何らかの方法でメディアファイルを処理する場合、形式がどのように機能するかを理解することが重要です。あ無料のビデオから MP3 コンバーターへブラウザベースのファイル処理パイプラインがどのように動作するかを考えるための良い参考資料となります。

拡張機能 UI のアクセシビリティも重要です。のA11Yプロジェクトには、ポップアップページとコンテンツスクリプトを誰でも使用できるようにするための実用的なチェックリストが含まれています。これは MV3 が直接取り組んでいない領域ですが、Web ストアのレビュー担当者はアクセシビリティの問題に気づいています。

インディーズ拡張機能ビルダーの結論

マニフェスト V3MV2 よりも構築が難しいプラットフォームです。非同期要件、ストレージ制限、タイマー制限により、実際の摩擦が生じます。ただし、この制約により、より回復力があり、より監査しやすいコードを求めることもできます。

最も苦労するのは、MV2 パターンを直接移植しようとする開発者です。成功する開発者は、新しい制約を設計のインプットとして受け入れ、アーキテクチャを最初から再考する開発者です。

トレードオフをする価値はあるでしょうか?ほとんどのインディーズ拡張プロジェクトでは、そうです。 Web ストアは依然として実行可能な流通チャネルです。ユーザーベースは膨大です。収益化のオプションは現実的です。今は別の方法で構築する必要があるだけです。

状態モデルから始めます。これを正しく行うと、MV3 拡張機能の残りの部分が所定の位置に収まります。誤解すると、ランダムなバグのように見える Service Worker 終了のエッジケースのデバッグに何週間も費やすことになります。

この投稿にはアフィリエイトリンクが含まれています。これらのリンクを通じて購入すると、追加費用なしで手数料が発生する場合があります。