ユーザースクリプトと実行時のメモリー/ JavaScript

ブラウザのメモリー消費

色々なJavaScriptツールを作って、ブラウザで開く色々な画面（特にアメーバブログが中心）で常駐させて使用していますが、当初から気になっていたブラウザのリソースをどの程度ユーザースクリプトが使うのかと言う問題について、AIに聞いてみました。

 

 

スクリプトツールの軽量化

その前に、スクリプトツールの軽量化、メモリーの消費を最大に抑える手法について質問していました。 私の場合は自分の作ったツールのテストの意味を込めているのですが、編集画面では20～30ほどのスクリプトを常駐動作させています。 この間、リスナー設定の適正化を行う中で、対象としたスクリプトの改善も行っていますが、例えば「Blog Table」の現在のバージョンは 2000行程度です。

 

 

ユーザースクリプトとしては少し重いかもと思っているのですが、公開されている有名なブラウザ拡張機能と比べると、こんなのは子供みたいな物です。（本質的には親戚です） しかし、軽量化の手法は知っているべきと思って聞いてみたのです。

 

手法としては、ショートカットや起動ボタンの設置までは常駐させるけれど、それで起動するツールの本体プログラムは、ボタンを押すまでパース（スクリプトとして展開する）をさせないで、ボタンを押してからパースする手法を採る様です。

 

その方法も何種かありますが、サイトのシステムなどは、ツール本体は外部ファイルとして置いておき、画面上のボタンで呼び込ませる様です。 これはサイトを作る側なので出来ることですが、ユーザースクリプトは、1個のツールに纏める必要があり、そうは行きません。 

 

その場合の手法は、ソースコードに本体のコードを「テキスト」として書き込んでおいて、ショートカットや起動ボタンで、初めてそれをパース（スクリプトとして解釈して実行状態にする）する方法です。 この様な手法は、ブラウザのメモリー消費を節約できますが、わざわざそうした手法を採るべき「重たいツール」は、どの程度のレベルのツールなのか、そこを先を聞いて見たのです。

 

 

実際の軽量化の適用は？

質問

必要時に初めてパースさせる方法は採用し易く、ツールを公開配布する上で理想的に思えます。 ただ、起動に時間がかかる？ 文字列であっても常駐時に読み込まれるが、通常とどの位の差があるのか？ といった疑問がわいてきます。どの程度の規模のツールで、軽量化が有効か、目安はありますか。

 

Google AI の回答

 

結論から言うと、1000行程度のスクリプトであれば、「文字列にする（遅延パース）」ことによるメモリ節約効果は、現代のPCやスマホにとっては極めて微小（誤差の範囲）です。むしろ、起動時のオーバーヘッド（一瞬の引っかかり）のデメリットが上回る可能性があります。

 

どのような基準で判断すべきか、メモリ、起動速度、実装のトレードオフ（目安）を整理しました。

 

1. メモリ消費のリアルな差（常駐時）

 

JavaScriptにおいて、「通常のコード」と「文字列」のメモリ消費量の差は以下のようになります。
  • 通常のコード（即パース）： テキストデータ（数万バイト） ＋ 構文木（AST）やコンパイル後の内部データ（数倍〜十数倍に膨らむ）

     

  • 文字列（遅延パース）： テキストデータ（文字数ぶんのバイト数）のみ

1000行（約30KB〜50KB）のスクリプトをそのまま読み込んだ場合、パースされても消費メモリは 1個あたり数百KB〜1MB程度 です。これを30個常駐させても 計20〜30MB 程度 であり、現代のブラウザ（タブ1つで数百MB〜1GB消費する）の中では、全体の数％にも満たない無視できる量です。

 

 

2. 起動時間の差（ボタンを押した瞬間）

 

new Function(文字列) を実行すると、ボタンを押した瞬間にブラウザが「今からこの文字列をJavaScriptとして解析して、機械語にコンパイルする」という処理を一から始めます。

  • 1000行程度： 現代のブラウザのJavaScriptエンジン（V8など）は爆速なので、1000行のパースにかかる時間は 数ミリ秒（体感不可能） です。

    　

  • 数万行〜大規模ライブラリ（jQueryやReactなど）： ボタンを押した瞬間に 数十ミリ秒〜100ミリ秒以上の遅延（プチフリーズ） が発生し、ユーザーが「ボタンの反応が悪い」と感じる原因になります。

 

パースを後にすべきかどうかの「目安」

 

これらを踏まえると、テクニックを導入すべきかどうかの基準は以下のようになります。

判定基準 　遅延パース不要 　遅延パースを推奨
行数 　数千行以下 　1万行以上（外部ライブラリを含む）
データ量 　データ定義が少ない 　データが数MBを超える
使用頻度 　ページを開くと毎回使う 　たまにしか使用しない
利便性　　 　開発デバックがしやすい 　開発デバッグが非常に難しい

 

結論：1000行のユーザースクリプトを30個程度常駐させた場合は？

 

20〜30個のツールが「すべて1000行程度」であれば、合計しても3万行以下です。 結論は、通常の書き方（最初からパースさせる）で問題ありません。

メモリを減らすために文字列化しても、浮くメモリは数メガバイト程度（ブラウザのタブを1つ閉じたり、広告ブロックを入れるほうが遥かにメモリが浮くレベル）です。一方で、開発時にエラーが起きたときのデバッグのしやすさ（シンタックスハイライト、エラーが出た正確な行数の表示）を失うデメリットの方が大きくなってしまいます。

 

❝

 

 

 

程度を見積もる

今回のAIとの問答で、ユーザースクリプトの立ち位置がおよそ判った様に思います。 メモリーやリソースといった掴み難い「量」は、それ故に平均的な状況の把握は必要と思います。

 

 

TgQPHd 開発デバックしやすいツール