00:03
はい、5月12日金曜日ですね。時間は朝9時になりました。昨日からまた急に気温が下がってきましたね。なんか寒くなってきたので、まだ体調管理気をつけていただければなと思います。
はい、おはようございます。ユメミのkeethこと桑原です。ではでは本日も朝活を始めていきたいと思います。
本日は、ついにゼルダの新作品ですね。新しい作品の発売になったということでおめでとうございます。
弊社の代表もですね、昨日ツイートしましたけど、今日のユメミはゼルダ休暇らしいです。
本当にゼルダやりたいからで休暇を取っているメンバーもいると思いますけど、まあまあ仕方ないですね。
大作の新作が出たって言うんだから、それは仕方ないなっていうのはありつつも、まあもちろんそのプロジェクトに指標がない程度とか、
オンスケだっていうところで休まれている方もいるかもしれないし、あれですけどね。まあそれはさておき。はい、じゃあ今日の朝活ですけど、
今日はですね、僕はあんまファイアフォックスを使わないんですけど、ファイアフォックスのブログが出てて、
CAST THE WORLDのターボチャージング、ファイアフォックスアクセシビリティ、パフォーマンス&メンテナビリティという記事が出たので、
まあなんかアクセシビリティとかメンテナビリティっていうのは興味関心のあるワードなので、早速読んで勉強していきたいなと思っております。
はい、ドナソンですね。おはようございます。ご参加いただきありがとうございます。今日も今からちょっと誰だらと読んでいこうと思っております。
それでじゃあ早速入っていきたいと思います。このブログ自体はですね、えっと2022年、去年の12月22日なのでちょっと古いんですけども、半年ぐらい前ですかね。
いかないぐらいなんですけど、はい、まあ読んでいこうと思います。じゃあ行きましょう。ファイアフォックスのアクセシビリティエンジンは、スクリーンリーダーなどの支援技術がウェブページのコンテンツにアクセスするために必要な情報を提供する役割というのを担っています。
過去数年間ファイアフォックスのアクセシビリティチームというのは、アクセシビリティエンジンの大規模な再設計に取り組んできました。
エンジンの速度とか信頼性、補助性を大幅に向上させたかったというのが拝見あります。私たちはこのプロジェクトをキャッシュザワールド、世界をキャッシュするというふうに読んでいます。
この投稿ではこのような大規模な取り組みを行った理由を説明し、新しいアーキテクチャがこれらの問題をどのように解決しているかというのを説明していきたいと思います。
まず最初はThe Need for Speedですね。速度への重要なところの話ですね。
このプロジェクトの最大の動機は、スクリーンリーダーやその他の支援技術を使用する際に、特にWindows上でファイアフォックスを高速化することです。
いくつかの数字を見るところから始めてみましょう。下の表はファイアフォックス、NVDA、スクリーンリーダーを使って様々なタスクを実行するのにかかる大よその時間をリアーキテクチャの前と後の両方で一応示しています。
表がバッと貼られていますけど、ざっくりと縦軸はbefore、no cacheとafterのwith cacheですね。
横軸にいくつかの項目がありますね。最初はですね、searchfoxでnscssframeconstructor.cpp
まあなんかよくわからないですけど、というものがあってそれを読み込んで、12,000行を超えるテーブルを含むものですね。
03:01
ようなものっていうのをまず横軸1つ目です。2つ目の軸は非常に大きなドキュメントであるwhatwasgのhtmlスペックを読み込んでみましょう。
3つ目はGmailの受信トレイからメッセージを開くというところが3つ目の軸です。
4つ目はGmailメッセージを閉じて受信トレイに戻ると。最後スラックのチャンネルを切り替えるみたいな軸ですね。
合計5つの軸でビフォーアフターの数字を見てみました。1つ目の軸の方は128セックですね。秒から6セックに短縮したと。
2つ目のwhatwasgのhtmlスペックページのローディングですけど、これが175セックから15セックまで下がったと。めちゃくちゃ速くなりましたね。
あとはGmailのメッセージを開くというのも200ミリ秒から100ミリ秒になったと。
Gmailメッセージを閉じてリターンというか、もう一回受信箱に戻るのが410ミリ秒から150ミリ秒。
最後スラックのチャンネル切り替えが620ミリ秒から330ミリ秒だと。
はい、だいぶ速くなりましたねこれ。 やっぱりキャッシュを使うというところで倍以上速くなっているというのはすごくいい話だなというところですね。
Gmailとか特にそうですよね。直前に開いていたインボックスは確かにキャッシュした方がいいですよね。
少し徘徊するのであればまさにキャッシュすると早いと思います。
これらの時間は使用するコンピューター以前にページを読み込んだことがあるかどうか、ネットワークの速度などによって大きく異なる法律です。
しかし相対的に比較することで新アーキテクチャによるパフォーマンスの向上というのもわかるはずです。
では、そもそもなぜこんなに遅かったんでしょうか。それを理解するためにはまずブラウザの歴史を少し見てみる必要があります。
ということで以下では簡潔かつシンプルにするため細かい部分は省略しながらちょっと言いたいと思います。
歴史のところですけどまずはじめに、もともと、昔々ブラウザは今よりずっとシンプルでした。
ブラウザは単一のオペレーティングシステムプロセスだったんですよ。
複数のタブやiフレームを使ったドキュメントがあったとしても全ては一つのプロセスの中で行われていたんです。
これはアクセシビリティツリーを使用してユーザーインターフェースとウェブコンテンツに関する情報を取得する支援技術にとって合理的に機能していました。
オペレーティングシステムのアクセシビリティAPIは他のアプリケーションでアクセシビリティツリーを公開し問い合わせるために既に使用されていました。
これらのAPIはウェブコンテンツの豊富なセマンティックスと複雑な構造を公開するために多少拡張する必要というのがありましたが、
ブラウザーは他のアプリケーションと基本的に同じ方法でAPIを使用しました。
例えば、ページ上の次の見出しをつけるなど支援技術はあるタスクを実行するために大量のクエリを実行する必要があるということがあります。
しかしプロセス間で大量のクエリを実行するとコンテキストスイッチ、データのコピーとシリアライズなどのオーバーヘッドが発生するため非常に遅くなることがあります。
これを高速化するためにいくつかの支援技術やオペレーティングシステムのフレームワークでは、
インプロセスコードと呼ばれるブラウザープロセスの内部で独自のコードを実行しています。
06:02
そんなことはしないですね。
こうすることで大規模なクエリのバッジを非常に高速に実行することができます。
特にWindowsのスクリーンリーダーはアクセシビリティツリー全体に問い合わせを行い、仮想バッファーと呼ばれるドキュメントの独自の表現を構築しています。
というのがまずはじめにというところですね。
いろんなものを端折っているとは思いますけども。
続いてマルチプロセスの話ですね。
ウェブが急速に利用され複雑化するにつれてセキュリティ侵害のリスクも高まってきました。
パフォーマンス、安定性、セキュリティを向上させるため、
ブラウザーは異なるウェブページを別々のプロセスに移動させるようになりました。
インターネットエクスプローラー8ではタブごとに異なるプロセスを使用していましたが、
ウェブページの描画、ページが読み込まれたのと同じプロセスで行われていました。
アクセシビリティツリーもその同じプロセスから公開され、
支援技術は依然としてそのプロセスにコードを注入することができました。
このため支援技術に変化はなく、コンテンツに直接高速でアクセスすることができました。
セキュリティをさらに向上させるために、
Chromeは基本設計の一部としてより厳格なアプローチを採用しました。
ウェブコンテンツのプロセスはサンドボックス化され、可能な限りアクセスできないようにして、
より多くの特権を必要とするタスクは厳密に制約された通信チャンネルを通じて他のプロセスに移情されました。
つまり、支援技術がアクセシビリティツリーを含むウェブコンテンツプロセスにアクセスすることはできず、
そのプロセスにコードを注入することもできなかったのです。
数年後、Firefoxも同様の設計を採用し、その結果アクセシビリティに同様の問題が発生しました。
まずは厳格と厳密性というか、セキュリティの方を重要視したという感じですね。
メルトダウンとスペクトラの攻撃の発見により、両ブラウザーはさらに進んでiフレームを独自のプロセスで分離するようになり、
アクセシビリティにとって状況はさらに複雑になっていってしまいましたよと。
はぁ、なるほどですね。そんな背景があったんですね。
ただ言われてみればそうだし、仕方ないですよね。タブごとにどうするのって話は全然出てくる話なのね、これは。
でもアクセシビリティツリーが結局そこに注入とか介入できなくなってきたというのはその通りなんだよなというので、結構大変ですよね、これは。
というところで、ではでは続いてChrome's Solutionですね。
ChromeというかChromiumですけど、がどのようにアプローチを取ったかというのは次の話です。
当初、Chromeはアクセシビリティの問い合わせをメインのUIプロセスで処理し、適切なWebコンテンツプロセスにリレーすることを実験的に行いました。
アクセシビリティAPIクエリというのは同期的であるため、各アクセシビリティクエリが完了してその結果を返すまでUIとWebコンテンツプロセス全体がブロックされました。
このため、特に上記のような大規模なクエリのバッジの場合、許容できないほど遅くなってしまいました。
また安定性や信頼性の面でも不明瞭な問題が発生しました。
うーん、今回の実験はちょっとうまくいかなかったって感じですね。
09:02
で、Chromeはこのアプローチをやめ、メインUIプロセス内の他のすべてのプロセスからアクセシビリティツリーをキャッシュするようにしました。
ほーん。
で、プロセス間で同期的にクエリを実行するのではなく、Chromeは各Webコンテンツプロセスから非同期的にアクセシビリティツリーをプッシュしています。
このため、ページの読み込みや更新時に若干の時間とプロセスパワーが必要になるほか、キャッシュのために余分なメモリを使用することになります。
その一方で、他のブラウザーで行っていたように支援技術がコンテンツに直接プロセス内で高速にアクセスできるということもその代わり意味をしています。
なのでアクセシビリティに対してのちゃんと口は作りましたよと、その代わりエネルギーを使うようになってしまったということですね。
一時期、Chromeが急に重くなったり、急にメモリ食うなっていうのはこういう話が多分裏にあったのかもしれないですね。
まあ、プロセスパワーが必要になるというのがまだこれも仕方ない話ですね。
で、続いてFirefoxソリューションテイク1ですね。
まず一つ目のソリューション、解決方法というところですけども。
まず一つ目ですね。FirefoxはChromeよりもずっと前に設計され、複数のサンドボックス化されたプロセスが必要となる複雑な世界よりもずっと前に設計されました。
つまり、複数のプロセスを使用するようにFirefoxを再設計することは何年もかかる大規模な仕事であり、多くのリソースを必要としたのです。
Firefoxも結局マルチプロセスに対応するとかっていうのは結構大変だったんですね。
毎日Firefoxに依存している何億人ものユーザーのためにFirefoxの信頼性を維持するために最新の注意を払う必要がありました。
Firefoxはメインプロセスにおいてツリー構造と各ノードの役割、ボタンとか見出しなどなどだけを含む非常に小さなキャッシュというのを構築しました。
それ以外のクエリは適切なウェブコンテンツプロセスに同期してリレーされていきました。
LinuxやMacでは大量のクエリが発生することはほとんどなく、仮想バッファーも使用されないため、ほとんどの場合これは許容範囲ないでした。
Macの人は全然問題なかったところですね。
しかしWindowsではChromeが発見したようにこれは完全に受け入れがたいものでした。
Accessibilityで使用されるWindowsの通信メカニズムcomというのがあるらしいですけど、こちらは再入力を許可しているため異常に遅いだけでなく非常に不安定だったんですよ。
Firefoxのマルチプロセス通信フレームワークというのはリエントリーを処理するよう設計されていませんでした。
そのためWindowsでは別のアプローチが必要でしたよと。
これはOSレベルの話になってくるので仕方ないですね。
Microsoftと連携して今後OSどうするかという話をするという選択肢もありましたが、Firefoxはブラウザーの話なのでブラウザーでやってねというところで別のアプローチを考えました。
Accessibilityチームはメインプロセスで全てのアクセシビリティツリーのフルキャッシュを実装することを検討しました。
しかしModularはマルチプロセスFirefoxをできるだけ早く出荷する必要がありました。
12:05
フルキャッシュを実装して正しく動作させるには正直時間がかかりすぎると考えられていたのです。
間違ってしまうと誤った情報が支援技術に伝わりすでにFirefoxに依存しているユーザーにとって悲惨なことになりかねない。
また先に述べたようにフルキャッシュには他にもデメリットがあるというところですね。
結局どういう結論を出したかという話が気になるんですけど。
その代わりにFirefoxはCOMの高度なそしてやや不明瞭な機能を使用して支援技術がコンテンツプロセス内のアクセシビリティツリーと通信することを可能にしました。
大量のクエリーによりパフォーマンスの問題を軽減するために各ノードに対して部分キャッシュが提供されました。
ノードへのクエリーには同期的なクロスプロセスを呼び出しが必要になりますけど
一つの情報を返すだけでなくキャッシュにはその一つのノードについてよく検索される他の情報が格納されます。
つまりそのノードに対するその後の問い合わせはキャッシュから回答されるため非常に高速でした。
これらは全てCOMの軽量クライアントサイドハンドラーというのを使用して行われました。
全てのノードのキャッシュは何かが変更されるたびに無効化されました。
素朴ではありますがこれにより情報が古くなるリスクを軽減することができました。
結果、たまにパワフルと言いますか単純な方法を使うというのは確かに良いかもしれません。
Firefox 5.7で最初にリリースされたとき支援技術によるパフォーマンスは大幅に後退してしまいました。
時間の経過とともにこのCOMハンドラーキャッシュを拡張することでこれを大幅に改善することができました。
最終的には現在のアーキテクチャでこれ以上速度を向上させることができない点に達してしまいました。
それはそれでいい話ですね。
支援技術以外のソフトウェアがアクセシビリティAPIを使用しているため
Windowsのタッチ、東アジアの入力方法、企業のSSOツールなどなど
東アジアというか大体日本だろうな
場合によっては障害のないユーザーにも影響が及ぶことがありましたと
さらにCOMは多くのWebアクセシビリティツリーの膨大な数のオブジェクトを処理するように設計されていないため
修正が困難あるいは不可能な深刻な安定性の問題というのが生じてしまいました。
このアーキテクチャの複雑さと異なるオペレーティングシステムで異なる実装が必要なことから
アクセシビリティエンジンは過度に複雑で維持が困難なものとなってしまいました。
これは私たちのチームの規模が小さいことを考えると特に重要なことです。
2019年と2020年にAndroidとMacの実装を刷新した際
まともなパフォーマンスを確保するために
より多くのオペレーティングシステム固有の調整を実装しなければならず
時間がかかりさらにコードが複雑化してしまいました。
これはフルキャッシュがあれば必要なかったことでしょう。
もちろんキャッシュのコードを維持することにはそれなりのコストがかかりますが
この作業は特定のオペレーティングシステムに関する個々のチームメンバーの専門知識に頼るのではなく
チーム全体でより簡単に分配することができます。
15:00
続いてEnter Cache the Worldですね。
本記事とかタイトルのCache the Worldの世界に行きます。
私たちの既存のアーキテクチャというのは数年間はうまく機能していました。
しかし問題が散積してきたため私たちはもう一度検討することにしました。
フルキャッシュの欠点は既存のアーキテクチャの問題点を遥かに上回るものであり
注意深く設計すればその欠点を軽減することができると判断したのです。
こうしてアクセシビリティエンジンを再構築するCache the Worldプロジェクトが誕生しました。
新しいアーキテクチャではChromeと同様にFirefoxは各Webコンテンツプロセスから
メインUIプロセスにアクセシビリティツリーを非同期にプッシュします。
支援技術がアクセシビリティツリーに問い合わせをすると
Firefoxのプロセス間で呼び出すことなくすべての問い合わせがCacheから回答されます。
ページが更新されるとコンテンツプロセスが非同期でCacheの更新をメインプロセスにプッシュします。
スピードの向上は予想を遥かに超えています。
旧アーキテクチャとは異なりCacheの更新方法とタイミングを完全に制御できるため
さらに改善する余地が多いに残っています。
コードのメンテナンスについてはこれが完全にリリースされれば
約2万行のコードを削除できるようになりますが
その大部分はオペレーティングシステム固有のものです。
いい話ですね。
2万行コード削除って結構デカいですね。
しかもオペレーティングシステム固有のものって言うんだから
正直に言うとニッチなものなので
いい話だなというところですね。
続いてThe Journey to the World of Cachingですね。
Cacheの世界へ向かう旅ですけど
Cacheを管理し様々な種類の変更に対して
Cacheを更新するために必要なコード以外に
このプロジェクトでは特筆すべきいくつかの主要な作業が必要でした。
まずFirefoxのデスクトップUIは
大部分がWeb技術、HTML、CSS、JavaScriptを使って書かれていますが
これはメインプロセスでレンダリングする必要があります。
このためにCacheは必要ないんですけど
Cacheのある実装とない実装の間で
できるだけ多くのコードを共有したいという風に考えました。
特にオペレーティングシステムに
固有のアクセシビリティAPIをサポートするコードのレイヤーがあり
これを完全に別個の2つのバージョンで管理することは望ましくありませんでした。
昔そんなことでもやってたんですね。
それだけOSに関するコードってのは結構特殊なものだったんですね。
そこで私たちは両方の実装、ローカルアクセシブルとリモートアクセシブルに共通する
インターフェースと機能を提供するベースのアクセシビリティクラスで
統一されたアクセシビリティツリーを作成しました。
他のコード、特にオペレーティングシステム固有のコードというのは
この統一されたツリーを使用するために適宜更新する必要がありました。
やろうとしていることとか描いている世界観というのは
結果的にはシンプルなことをやりたいんだけど
実際ソースコード自体を複雑化してしまってという歴史的な背景があって
結構エネルギーとか時間もかかったんでしょうね。
では第2位ですけど
Windows固有のアクセシビリティコードっていうのは
以前はコアアクセシビリティコードと結構絡み合ってしまいました。
18:03
Windowsの機能は独立したクラス階層ではなく
現在ローカルアクセシブルと呼ばれているもののサブクラスで実装されていました。
このためWindowsのコードでは
キャッシュされた別個の実装をサポートすることが不可能でした。
この問題を解決されるために
Windowsの実装を別のクラス階層、MSAAアクセシブルという風に分離しました。
第3位、テキストですね。
単語とか行、書式スペルミスなどなどというテキストへのアクセスを提供するコードは
Firefoxのレイアウトエンジンに直接問い合わせることができることに大きく依存していました。
これはテキストの個々の塊ではなく
テキストコンテナを扱うものであり
効率的なキャッシュには理想的ではありませんでした。
また非対称で一貫性のない結果を引き起こすバグというのも多くありました。
そこでテキストリーフレンジというテキスト範囲に基づく
全く新しい実装に置き換えました。
この実装でもレイアウトエンジンを使って線の境界を決定する必要があるのですが
個々のテキストの塊に対してこれを行うことができ
対称的で一貫性のある結果を得ることができます。
テキストリーフレンジというのはMacのテキストAPIに遥かに適しており
WindowsUIオートメーションのテキストパターンを実装する際には
より簡単に実装できるようになるでしょう。
また同様にレイアウトエンジンに大きく依存していたテーブルを扱うコードも
Cache to Table Accessibleという新しい実装に置き換えました。
第4にAndroidのアクセシビリティコードは大幅な再設計が必要でした。
Androidでは他のOSと異なりFirefoxのブラウザエンジンが
AndroidのUIとは別のスレッドで動作しています。
アクセシビリティの問い合わせはUIスレッドで行われるため
AndroidではアクセシビリティCacheへのスレッドセーフなアクセスを
提供する必要ともありました。
はいはいはいはい。
なるほどですね。
ラスト、ファイナリーでどこですけど
最後に画面描画と画面座標とヒットテスト
画面上の得点のポイントにあるノードを把握するために使用するものですね。
こちらは興味深い議題でした。
現代のウェブにおける画面配置というのは
スクロール、複数のレイヤー、フローティングコンテンツ、
トランスフォーム、再配置、変換、拡大縮小、回転、傾きなどなどを含み
非常に複雑になることがあります。
私たちは親に対する各ノードの座標とサイズをキャッシュし
スクロール位置とトランスフォームを個別にキャッシュしています。
ブラウザーでも位置をキャッシュしてるんですね。
へー。
それにアクセスできてJSで処理できるんだったら
これは結構ありがたい話ですね。
スクロール位置とトランスフォームを個別にキャッシュしていて
これによってコンテンツがスクロールしたり
移動したりする際のキャッシュの更新を最小限に抑えることもできます。
このデータを使って支援技術から要求があったときに
必要に応じて絶対座標を計算します。
ヒットテストではレイアウトエンジンを使用して
画面上に表示される要素を削除し
最上位レイヤーから最下位レイヤーにソートしていきます。
これはビューポートキャッシュと呼ばれる
21:00
各ノードのフラットリストとしてキャッシュをします。
支援技術が画面上の指定された点のノードを要求すると
そのリストを操作して
指定された点を含む最初のノードを返します。
へー。
ここでも結構いろんな興味深い話が出てるんですけど
結構個別の記事のリンクがペタペタ貼られてますね。
割となんかテクニカルなことだったり
いろんなことが背景にあるんでしょうけど
これ一個一個ちょっと記事読んでいきたいんですけど
まあさすがに時間ないし
あれなので興味ある人はこの後
これ記事ツイートしますので見てみてください。
続いてのセクションですね
How is Firefox Cache different to Chrome?
FirefoxのキャッシュはChromeのキャッシュと
どう違うんですかって話ですね。
ChromeとFirefoxのキャッシュって結構似てるんですけど
そしてそれに触発されていますと
お互いに触発しちゃってるんですね。
いくつかの興味深い違いがあります。
まずChromeはキャッシュを最新の状態に保つために
キャッシュの更新を送信する
キャッシュシリアライザーというのを備えています。
まずノードが変更されたことをシリアライザーに通知します。
具体的な変更点はシリアライザーにほとんど関係なく
ノード全体を再シリアライズするだけです。
全体再シリアライズ、まあ必要だとは思いますけど
これ結構コストかかるんじゃないですかね。
全ノードですもんね。
ページとか画面の情報量によってかなりコストと時間がかかる気がしますね。
シリアライザーはどのノードがすでに送信されたかを追跡しています。
ツリーを歩くとき遭遇した新しいノードをすべて送信し
すでに送信され変更されていないノードなどを無視します。
なるべくオーバーヘッドは避けるようにしたいところですね。
これに対してFirefoxは既存のアクセシビリティイベントと
特定のキャッシュ更新要求を使って送信すべき変更を決定します。
ノードが追加または削除されるとFirefoxはShowまたはHideというイベントを発生させます。
このイベントはサブ継ぎの挿入または削除に関する情報をメインプロセスに送信するために使用されます。
Webコンテンツプロセスはどのノードが送信されたかを特に追跡するわけではなく
ShowイベントとHideイベントの正しさに依存します。
ノードに対するその他の変更についてはFirefoxは可能な限り既存のイベントを使用してキャッシュの更新をトリガーしています。
イベントを持つことに意味がない場合は特定のキャッシュ更新をトリガーするコードが追加されました。
キャッシュの更新は変更された特定の情報のみを含みます。
また不正確なイベントは支援技術に問題を引き起こす傾向があるため関係なく修正するというのも必要があります。
第二にChromeは単語の境界に関する情報をキャッシュに含めています。
へー、なるほどね。
これに対してFirefoxは必要に応じて単語境界を計算することでメモリーを節約しキャッシュの更新の複雑さというのを軽減しています。
あ、そうなの?
単語に関する境界情報もキャッシュに含めちゃってるんだったらそっちの方が早いんじゃないかと思ったけど意外とそうじゃないんですかね。
メモリー節約っていうことをFirefoxは加味してそっちじゃなくて再計算するっていう選択肢にしたんですね。
計算する方がなんかメモリー使う気がしますけどね。
今ちょっと中身見てないからわかんないですけど。
24:01
これはメインプロセスでUI用のウェブコンテンツをレンダリングしているためメインプロセスとコンテンツプロセスの両方で単語境界を計算するコードにアクセスできるため実現ができましたと。
うーん。
ちょっとここだけ僕はちょっと分かってないですけどそんなことをやってるんですね。
まあでも単語の境界って英語だったら別にそれほど問題ないんですけど日本語みたいなマルチワイド文字とかだったりすると結構大変なんじゃないかなと思うので
日本語対応している方って結構苦労していると思います。特にChromeの方ですけど。
3つ目はヒットテストの実施方法というのは異なることです。
Firefoxがどのようにヒットテストを実装しているかは先に説明した通りです。
ChromeではViewportキャッシュを維持するのではなくまずツリー内にキャッシュされた座標だけを使用して応用その結果を取得します。
その後次のクエリーでより正確な結果を得るために画面上の近くのポイントに起動キリクエストを送信しても逆収します。
私たちはViewportキャッシュによってFirefoxの初期ヒットテストの精度が向上することを期待していますが、この戦略は時間をかけて改良する必要があるかもしれません。
うーん、わかりました。
ラストですねここで。
So when can I use this awesomeness?
この操作はいつ使えばいいんでしょうか?というご質問いただきましたがその通りです。
この新しいアーキテクチャはFirefox Nightlyで既に有効になっています。
これまでのところユーザーから非常にポジティブなフィードバックを受けています。
このまま順調にいけば2023年1月のFirefox110のベータ版でWindowsとLinuxのユーザー向けにこれを有効にする予定です。
その後Firefox111または112のリリースでWindowsとLinuxのユーザーに段階的にこれを展開する予定です。
Macでは特にテキストインタラクションでキャッシュの恩恵を十分に受けるためにまだ少し作業が必要ですが、Windowsの後すぐにMac向けにリリースしたいと考えています。
さあキャッシュされた世界を楽しんでください。
ということでこの記事は締められておりました。
はい、いかがだったでしょうかね。
結構歴史の話はすごく面白かったし、
僕は最後の方に出てきたChromeとFirefoxのキャッシュの違いというところもすごく興味深かったですね。
いろんな設計だったりいろんな戦略でやっているというところがすごく面白かったので、
キャッシュ周りというのはブラウザーのキャッシュの戦略というか具体的な行動まで読めるんだと読んでいきたいなと普通に思いましたね。
はい、というところで今日の朝活はここで終了したいと思います。
改めましてしゅうぜんさんとれのわさんとかつひろさんですね。
あと多分見えてないですけどすーさんですね。ご参加いただきありがとうございました。
明日も別の記事をゆるーく読んでいきたいと思いますけど、
明日はどうしようかな。久しぶりにJ3infoさんから情報を得るのもいいかなと思ったりしてますので、もし何を読むかわからないですけど。
また興味あれば明日も参加していただければと思います。
では金曜日ですね。週末ですのでしっかり今日も締めていただいて、ゆっくり土日休んでいただければなと思います。
それでは終了したいと思います。お疲れ様でした。
