Lycolog

Google ChromeでMeetをしていると動画が固まることがあるが、これを回避する方法。

単純にやるには設定→システム→グラフィックアクセラレーションが使用可能な場合は使用するをOFFにするだけでいいのだが、これをするとMeetで背景ぼかしやバーチャル背景が使えなくなる問題がある。

そこで今回はMeetで背景ぼかしやバーチャル背景が使える状態を維持したまま、フリーズを抑える方法を書いてゆく。

確認環境

• Windows 11 Pro 25H2 OSビルド26200.8246
• Google Chrome 147.0.7727.102

やり方

1. Chromeでchrome://flagsを開く
2. Accelerated 2D canvasをDisabledにする
3. GPU rasterizationをDisabledにする

ChromeからEdgeに乗り換えて一年半くらい経ったので、個人的にEdgeとChromeに思うところの比較をしてみた。これは別に優劣をつけるものではなく単なる感想。

Ad Block

Edgeには標準でAd Blockが導入されており、Chromeのようにサードパーティ製の胡散臭い拡張機能に依存する必要がない。

参考として個人的にはChromeの場合、uBlock Originを広告ブロッカーとして利用していた。これはAd Blockよりも強力だと思う。

ダウンロード結果の保持

Edgeではダウンロード結果を保持することができる。以下の画像の右側で「ダウンロード」と出ている垂直バーだ。

これが出ているとzipなどの書庫をダウンロードしたときに展開してフォルダに遷移がスムーズにできて便利だし、ダウンロード完了直後にアクション出来なかった場合も対応しやすいので非常に助かる。

Chromeにはこの機能がないのでダウンロードが完了した直後にクリックしようとしてもできないことがあるし、仮にできても展開先を開くには再表示しないとならず手間だ。ダウンロード中にクリックしておくとアクションの予約もできるが、上手く動かないことも多い。これは多分タイムアウトがかかってるのだと思う。

マウスジェスチャ

Edgeには標準でマウスジェスチャが導入されており、サードパーティ製の拡張機能に依存する必要がない。

ChromeのマウスジェスチャといえばcrxMouse Chrome™ Gesturesが有名だと思うが、この拡張機能は過去に公開停止されており、個人的にあまり信頼していない。

Edge標準のマウスジェスチャはcrxMouseと比べると貧弱だが、一般的なパターンと、必要最低限の割り当てができ、特定Webサイトでは機能しないようにするブロックリストもあるため、十分使える。何よりファーストパーティなので安心しやすい。

UIがころころ変わらない

Chromeはコンテキストメニューがスクロール方式になったり、ブックマークバーや各種メニューのボタンがある日突如、肥大化したり、ユーザーを使って大胆なABテストをしてくるので使いづらく感じることがしばしばあった。

Edgeを使っていて、このような破壊的変更を感じることはなく、全体的に落ち着いている印象だ。これは質実剛健なマイクロソフトと、柔軟に対応するGoogleとの会社文化の差としてみることもできそうだ。

クライアント領域の広さ

左がEdge、右がChromeの画面上部のUI部分だが、Edgeのほうが少しだけUIが狭い分、クライアント領域が広い。

Chrome Webストアから消えた拡張の維持

EdgeではChrome Webストアから拡張機能が消えても維持されるが、Chromeだと強制的に削除される。強制的に削除されると設定ごと吹き飛ぶため、Tampermonkeyのようにユーザー定義が大きな拡張はバックアップがないとマニュアルで再導入するのも厳しい。

但しEdgeであってもインストール元が消えているため、ブラウザの再インストール時には消えると思われる。

他端末とのタブ共有

Edgeを利用している他の端末が現在開いているタブを共有できる。これは最後に開いていた状態を持っているため、電源が落ちている端末のタブも見れる。

この機能は端末を多く持っている人ほど恩恵があるだろう。Chromeにも同様の機能があるようだが、内容は確認していない。

閉じたウィンドウを開き直す

Edgeでは誤ってウィンドウを閉じたときでも、閉じたウィンドウを復元できる機能がある。

最近閉じた項目にウィンドウが閉じた履歴が出るので、ここから復帰できる。

もちろん閉じたウィンドウの中身は展開でき、何を閉じたかも確認できる。

Chromeにもあるが、履歴に存在せずショートカットキーで出しづらいのと、何を閉じたのかが一目でわからないのが微妙に感じる。

垂直タブバー

Edgeには垂直タブバーがあり、多数のタブを開いているときに便利なケースがある。しかし個人的にはChromeのタブリストの方が必要な時にだけ画面上に被さるように出てくるため使いやすいと感じている。Edgeのは画面が狭くなるし、タブバーを開いている間は本来のタブが消えてしまうので操作性が悪い。

Edgeの垂直タブバー

垂直タブバーを表示すると元々のタブが消え操作性が変わってしまう上、能動的に非表示にしないと画面を占有して邪魔なので私はあまり好きではない。

タブバーを出す前	タブバーを出した後

Chromeの同等機能

Edgeと比べてUIに破壊的変化がなく、フォーカスを失えば勝手に消えるので便利だ。

設定同期

Edgeの設定同期には問題がある。それは設定の大半が同期されないことだ。Edgeにはマイクロソフトによるお節介機能が多くあり、これを無効化するための設定が多くあるのだが、これらは全く同期されない。無数に設定がある割に不親切だ。マイクロソフトの広告系の機能ならまだしも、マウスジェスチャすら同期されないのはいくら何でも酷いと思う。

一方でChromeは、設定画面にあるものであれば、ほとんどすべての設定が同期される。標準ダウンロード方式以外恐らくすべて同期されているのではなかろうか？

設定の単純さ

Edgeにはマイクロソフトの利益に繋がる広告機能や、Copilotなどの本質的にブラウザとして不要な機能が山のようにあり、これらの有効無効を切り替える設定が数多くある。これは多くの人間にとっては複雑なことだと思う。

一方でChromeの設定も多いとはいえ、Edgeと比べると単純だ。設定することもさほどないので導入が圧倒的に楽である。

ブラウザベンダーの広告

Edgeはひたすらマイクロソフトのサービスに誘導するように色々と邪魔くさく仕向けてくるが、Chromeではそんなことはない。

但しこの広告は設定で消す事ができるため、一度消してしまえば気になることはない。

最近さくらのレンタルサーバーでホスティングサイトが閲覧できないという声をしばしば見るし、私もよく遭遇するのでそれを解決する方法を紹介する。Microsoft EdgeとGoogle Chromeでの設定方法を紹介する。

Microsoft Edge

1. 設定を開く
2. Cookie とサイトのアクセス許可を開く
3. セキュリティで保護されていないコンテンツを開く
4. 「許可」にhttps://*を追加する

設定画面のURLとしてはedge://settings/content/insecureContentからいける。

2026-01-15追記

去年辺りからプライベートブラウズモードでは機能しなくなっているが、プライベートブラウズで有効化する方法は不明。

Google Chrome

1. 設定を開く
2. プライバシーとセキュリティを開く
3. サイトの設定を開く
4. 安全でないコンテンツを開く
5. 「安全でないコンテンツの表示を許可するサイト」にhttps://*を追加する

設定画面のURLとしてはchrome://settings/content/insecureContentからいける。

Node.jsとGoogle Chrome, Microsoft Edgeを用いて、try-catchとif文でエラー処理にかかる時間がどのくらい違うのかを調べた。

• 計測手法
• 計測結果
• 計測に使用したCPU
  • Intel Core i7 13700端末
    • Node.js v16.20.2
    • Node.js v18.19.1
    • Node.js v20.11.1
    • Microsoft Edge 121.0.2277.128
    • Google Chrome 122.0.6261.58
  • Intel Core i7 1265U端末
    • Node.js v16.20.2
    • Node.js v18.19.1
    • Node.js v20.11.1
    • Microsoft Edge 121.0.2277.128
    • Google Chrome 122.0.6261.58
  • AMD Ryzen 5 5600G端末
    • Node.js v16.20.2
    • Node.js v18.19.1
    • Node.js v20.11.1
    • Microsoft Edge 121.0.2277.128
    • Google Chrome 122.0.6261.57
• 全体サマリ表
• あとがき
• 参考

計測手法

次の4パターンを100万回実行した結果を記載している。

1. Result型としてエラーオブジェクトをreturnし、if文で判定する方式
2. Result型としてエラーインスタンスをreturnし、if文で判定する方式
3. エラーオブジェクトをthrowし、try-catchで判定する方式
4. エラーインスタンスをthrowし、try-catchで判定する方式

確認に使用したコード：https://gist.github.com/Lycolia/304bc9e825e821c2d582f3ef9f700817

計測結果

CPUによって処理速度がかなり変動するが、いずれの環境でも処理速度の速さは以下の通り。

1. Result型としてエラーオブジェクトをreturnし、if文で判定する方式
2. エラーオブジェクトをthrowし、try-catchで判定する方式
3. Result型としてエラーインスタンスをreturnし、if文で判定する方式
4. エラーインスタンスをthrowし、try-catchで判定する方式

計測に使用したCPU

Intel Core i7 13700端末

16C24T, 5.20GHz, L2 24.00MB, L3 30.00MB。ミドルタワーPC。

Node.js v16.20.2

処理環境

処理結果

Node.js v18.19.1

処理環境

処理結果

Node.js v20.11.1

処理環境

処理結果

Microsoft Edge 121.0.2277.128

処理環境

処理結果

Google Chrome 122.0.6261.58

処理環境

処理結果

Intel Core i7 1265U端末

10C12T, 4.80GHz, L2 6.50MB, L3 12.00MB。ノートPC。

Node.js v16.20.2

処理環境

処理結果

Node.js v18.19.1

処理環境

処理結果

Node.js v20.11.1

処理環境

処理結果

Microsoft Edge 121.0.2277.128

処理環境

処理結果

Google Chrome 122.0.6261.58

処理環境

処理結果

AMD Ryzen 5 5600G端末

6C12T, 3.90GHz, L2 3.00MB, L3 16.00MB。ミニタワーPC。

この端末はOSがUbuntuであるため、これまでのWindows環境との単純比較はできない。

Node.js v16.20.2

処理環境

処理結果

Node.js v18.19.1

処理環境

処理結果

Node.js v20.11.1

処理環境

処理結果

Microsoft Edge 121.0.2277.128

処理環境

処理結果

Google Chrome 122.0.6261.57

これだけバージョンが合わなかった。

処理環境

処理結果

全体サマリ表

凡例

1. Result型としてエラーオブジェクトをreturnし、if文で判定する方式
2. Result型としてエラーインスタンスをreturnし、if文で判定する方式
3. エラーオブジェクトをthrowし、try-catchで判定する方式
4. エラーインスタンスをthrowし、try-catchで判定する方式

CPUによってかなり差が出ているが、Intel CPUの13700と1265Uを比較した場合、例外を作らない1, 3のケースでは処理に大きな差がないが、例外を作る2, 4のケースでは有意な差が認められるので、モバイル向けとデスクトップ向けでCPUの処理効率に差があることがわかる。

AMD CPUと比較した場合、Node.js環境で例外を作らないケースではIntel CPUに大きく引けを取るが、ブラウザ上でのそれではパフォーマンスは高い。また例外を作るケースでもNode.js・ブラウザ共にIntel CPUと比較した場合のパフォーマンスが比較的よいという、面白い結果になっている。但しOSが違うことの影響もあるため、単純比較はできないが…。

あとがき

ひとまずtry-catchを使うと遅くなるということが確かめられたので良かったし、環境によって劇的遅くなるケースがあるというのは思わない収穫だった。

これを試そうと思った切欠はtry-catchが乱用されているコードを見てパフォーマンス劣化に繋がっているのではないかという疑問を抱いたからだ。try-catchでパフォーマンスの劣化が起きることは知識としても経験としても知っていたのだが、ちゃんとレポートしたことがなかったので今回まとめてみた。

try-catchの利用によりパフォーマンスの劣化が起きるというのは、古い時代にあった開発のお作法を知っている人であれば、それなりに常識だとは思うが、最近は知られていないか、知られていても意識していないことが少なくないと思われるので、今回記事にしてみた感じだ。

100万回の実行なので細かい話になるとは思うがパフォーマンスチューニングは細かいことの積み重ねでもあるので、むやみやたらに例外を使わないことは重要だと思う。そもそも例外は制御しづらいので、可能な限りif文で処理を書くことが望ましいだろう。

処理が遅延する原因としては二つあると考えていて、一つは例外生成時に顕著であることからスタックトレースの生成を初めとしたエラーオブジェクトの生成に時間がかかっているのと、もう一つはcatchでも遅延が出ることから、コールスタックから最寄りのcatchを辿るのに時間を取られていると思われる。今回の検証では特に出してないが、以前確認した時の記憶が確かであれば、catchに入らない限り、tryだけで顕著に処理が遅延することはなかったと思う。

あと、どうでもいいことだがconsole.log()で結果を出したときにEdgeだけObjectのKeyの順序が他と違ったので転記しているときに微妙に不便だった。何回やっても同じだったので恐らくEdgeだけキーをソートするアルゴリズムが違うのだと思う。まぁObjectとかHashとかMapとかDictionaryみたいなやつは順序が保証されないので別にいいっちゃいいんだけど、まさか実装によってソート方式が違うというのは思いもしなかった。

EdgeとChromeで処理結果が優位に違うのも、恐らくこれが原因なのだろう。分からないが多分JSのエンジンの実装が違う気がする。

それとLinuxのEdgeにはマウスジェスチャー機能がないという悲しいことも分かった。

参考

• Performance Effects of Exceptions in Java | Baeldung
• The Exceptional Performance of Lil' Exception

生のHTTPメッセージを見たい時に使える方法。devtoolsではフォーマットされたログしか見れないが、生のテキストを見たい時に使える。具体的には以下の画像のような奴だ。

よく忘れるのでメモとして残しておく

確認環境

やり方

chrome://net-internals/にアクセスするとログ収集ができるので、ログを集めたらイベントビューワで見ればよい。なおイベントビューワは外部サイトなので注意。

以前はブラウザ内で完結していて、リアルタイムに見れたはずだが、何故かできなくなっていた。

Edgeの場合はedge://net-internals/でもアクセスできるが、特にこだわりがなければ汎用性の高いchrome://net-internals/でよいと思う。