博士

やあ、ロボ子。今日のITニュースはコンテンツブロッカーについてじゃ。

ロボ子

コンテンツブロッカーですか。広告をブロックするあれですね。

博士

そうじゃ。広告だけでなく、マルウェアやクリプトマイナー、トラッキングもブロックできる優れものなのじゃ。

ロボ子

それは便利ですね。記事によると、Safariでコンテンツブロッカーを使うと、ウェブサイトの動作が遅くなることがあるそうですが。

博士

そうなんじゃ。SafariはIMGノードが挿入される際にメインスレッドをブロックして、コンテンツブロッカーのルールをチェックするからの。

ロボ子

メインスレッドをブロックするんですか？

博士

そうじゃ。他のブラウザ、例えばChromeやFirefoxはバックグラウンドでチェックするから、Safariよりスムーズに動くのじゃ。

ロボ子

なるほど。コンテンツブロッカーのルール数が多いと、特に遅延が大きくなるんですね。

博士

その通り。記事にも「Safariでは、コンテンツブロッカーのルール数が多い場合、ウェブサイトの動作が遅くなる」とあるぞ。

ロボ子

500個の画像をDOMに挿入するデモアプリだと、ChromeやFirefoxでは数ミリ秒で終わる処理が、Safariでは1秒以上かかるんですね。それは結構な差ですね。

博士

じゃろ？　M1 Max CPUでも1230msかかるらしいぞ。これは由々しき事態じゃ。

ロボ子

ウェブサイトの読み込み時に小さな遅延が発生するだけでなく、多数の画像を一度に読み込むサイトでは、遅延が顕著になる可能性があるんですね。

博士

そうじゃ。サムネイルがたくさんあるサイトとかは特に影響を受けやすいじゃろうな。

ロボ子

何か回避策はあるんですか？

博士

記事によると、IntersectionObserverを使って、画像が画面に表示されるまで挿入しないようにする方法があるみたいじゃな。

ロボ子

IntersectionObserverですか。画面に表示されるタイミングを監視するAPIですね。

博士

その通り。賢いロボ子じゃ。でも、根本的な解決にはなってないからの、早くAppleに修正してほしいのじゃ。

ロボ子

そうですね。しかし、コンテンツブロッカーの仕組みも変わってきているんですね。以前はJavaScriptでリクエストを許可するかどうか判断していたのが、今はブラウザが拒否リストと照合するようになったんですね。

博士

そうじゃ。GoogleとAppleは、デナイリストAPIに移行したからの。拡張機能がスパイ行為をするリスクも減ったのは良いことじゃ。

ロボ子

確かに、セキュリティ面では改善されましたね。でも、Safariのパフォーマンス問題は早く解決してほしいです。

博士

ほんとじゃな。しかし、ウェブサイトが遅くなる原因が、まさかコンテンツブロッカーにあるとは、皮肉な話じゃな。

ロボ子

まるで、セキュリティのために導入したものが、逆にパフォーマンスを悪化させているようなものですね。

博士

そうそう。まるで、ダイエットのためにサラダばかり食べてたら、栄養失調で倒れちゃったみたいなもんじゃ。