私が取り組んでいるユーザースクリプトが Firefox では遅いのに、Chrome と Safari では燃える理由を理解しようとしています。私が特定した理由の 1 つは (唯一の理由ではないかもしれませんが)、ユーザースクリプトのファイル サイズが大きいことが大きな影響を与えていることです。スクリプトには 10 本の長さの文字列が含まれており、ファイル サイズは 3.8 MB です。文字列を削除すると、スクリプトは再び高速になります---基本的に、ファイルが読み込まれている間、ブラウザのすべてが停止します（典型的なユーザー入力操作の時点で）。
そのため、文字列を事前に圧縮してから、実行中に必要に応じて圧縮を解除すると役立つかもしれないと考えていました。ユーザースクリプト内でこれを行うための戦略を持っている人はいますか?
ここにいくつかのアイデアがありますが、すべてテストされていません:
Greasemonkey から Scriptish に切り替えます。一般的に、Scriptish の方がパフォーマンスが高くなります。
a) テキストを別々のテキスト ファイルに分割します。
b) これらのファイルをスクリプトのインストール元に配置します。圧縮する必要はありません。
c)@resourceディレクティブを使用して各ファイルをポイントします。ファイルごとに 1 つ。
d) コードでは、GM_getResourceText()Docを使用して、必要なときに必要なテキストだけを取得します。
テキストをファイルに分割し、独自の gzip 対応サーバー (ローカル マシンの場合もあります) でホストし、GM_xmlhttpRequestオンデマンドでファイルをフェッチするために使用します。
サーバーはファイルを自動的に gzip するか、事前に圧縮して数ミリ秒節約することができます。
圧縮された文字列をユーザースクリプトに保存する場合; これがパフォーマンスにどのように役立つかを理解するのは困難です。
テキストを圧縮すると、バイト数がたとえば 70% 削減される可能性がありますが、ユーザースクリプトにバイナリを含めることはできません。それをbase64でエンコードする必要があり、スクリプトは突然短くなくなりました。
次に、base64 でデコードし、使用ごとにjs を使用してデータを解凍する必要があります。これらの操作は両方とも、JS で時間とメモリを消費します。
スクリプトを維持したり、テキストを変更したりするのは、かなり面倒です。
おそらく負の利益のために多くの作業のようです。