今月のLadybird — 2026年8月

This Month in Ladybird — August 2026

皆さん、こんにちは！ 8月、LadybirdはTwitchでのビデオ再生、YouTubeでのより多くのビデオフォーマット対応、CSSスクロールスナップ、DevToolsでのJavaScriptデバッグ、一時停止・再開可能なダウンロード、セッション復元などを獲得しました。また、エンジンのパフォーマンスが一時的な注目から持続的な焦点へと移行し、新しいスタイルエンジン、レイアウトキャッシュ、メインスレッド外でのCSSアニメーション実行が行われました。JavaScript値に格納されるセルポインタのケーシングを追加し、CSSの解析とペイントパイプラインをRustに移行しました。

Ladybirdは、オープンウェブを信じる企業や個人の寛大な支援によって完全に資金提供されています。今月、以下の新しいスポンサーを歓迎できることを嬉しく思います。

• Arnav Guleria 様（5,000ドル）

現在プロジェクトを支援してくださっている皆様は、スポンサーページでご覧いただけます。皆様に感謝いたします。スポンサーにご興味のある方は、お問い合わせください。

Twitchでのビデオ再生、およびYouTubeでのより多くのフォーマット

Media Source Extensionsの実装は、フラグメント化されたMP4、およびAVC (H.264)、HEVC (H.265)、AV1、AACコーデックのサポートを獲得し、サポートクエリは現在の機能を正しく伝えるようになりました（#11251）。これにより、TwitchやPlexを含む、より多くのサイトでアダプティブビットレートビデオを再生できるようになりました。YouTubeは、すべてのビデオがWebM形式のVP9/Opusで利用可能であるため、Ladybirdでは以前から動作していましたが、一部の古い/人気のないビデオはAVC形式でのみ複数の品質レベルを提供しており、より高い品質（特に8K）はAV1形式で提供されることがよくあります。

再生に関するバグも修正しました。YouTubeのビデオカードプレビューにマウスカーソルを合わせた際のクラッシュ（#10992）、preload="none"を使用するプレーヤーのハング（#11454）、HLS.jsベースのプレーヤーの再生開始の問題（#11480）を修正しました。

［動画］

CSS scroll snap

Scroll snapが実装されました（#10944）。scroll-snap-type、scroll-snap-align、scroll-snap-stopが利用可能です。ホイール、キーボード、スクロールバーのドラッグ、タッチパッドのフリング、プログラムによるscrollTo()すべてがスナップし、レイアウト変更時にコンテンツも再スナップします。（scrollIntoView()はまだスナップしません。）カルーセルやフルページスクローラーはこの機能に基づいています。

［動画］

DevToolsでのJavaScriptデバッグ

LadybirdでJavaScriptをデバッグできるようになりました。ブレークポイントの設定、コードのステップ実行、ウォッチ式の評価（#11128）が可能で、これはJavaScriptエンジンの新しいブレークポイントサポート（#10936）に基づいています。WasmデバッグとDOMミューテーションブレークポイントはまだ欠けていますが、コアワークフローは機能します。（以前と同様に、Firefox DevToolsフロントエンドは、独自のものを構築するまでの暫定的な対応です。）

［画像: Ladybirdがデバッガで一時停止し、Firefox DevToolsフロントエンドにブレークポイント、コールスタック、ウォッチ式が表示されている］

ダウンロードの一時停止と再開

サーバーが対応していれば、ダウンロードを一時停止・再開できるようになり、ブラウザの再起動後も継続できるようになりました（#10932）。また、可能な場合は4つ以上の並列接続でダウンロードします。

［画像: アクティブなダウンロードの進捗、速度、接続数、一時停止ボタンが表示されているダウンロードUI］ ［画像: 同じダウンロードが一時停止され、再開ボタンが表示されている］

セッション復元

Ctrl+Shift+Tで閉じたタブを再度開くと、URLだけでなく、タブの完全なセッション履歴（戻る/進むの状態を含む）が復元され、ブラウザの再起動後も保持されるようになりました（#11178）。「タブを複製」もセッション履歴を複製するようになりました（#11286）。フォーム送信データは、慎重な処理が必要なため、まだ永続化していません。

ブラウザUI

• mailto:リンク がメールクライアントを開くようになり、その他の外部URLスキームでは、危険なスキームや再帰的な起動に対する保護措置とともに、確認プロンプトが表示されるようになりました（#10846）。
• JavaScriptダイアログがブラウザ全体をブロックしなくなりました：alert()、confirm()、prompt()は、モーダルなシステムダイアログではなく、Qt UIでページ内オーバーレイとして表示されるようになったため、while (true) alert("lol")のようなコードでブラウザがロックされることがなくなります。タブを切り替えたり、タブを閉じたりできます（#11264）。
• クラッシュリカバリは、セッション履歴に偽のページを挿入しなくなりました。クラッシュ画面が表示され、実際の履歴エントリは保持されます。リロードすると、クラッシュで中断された場所から再開できます（#11402）。
• URLバーにlocalhost:8000または127.0.0.1と入力すると、失敗する代わりにhttp経由でナビゲートするようになりました（#11007）。
• Waylandの修正：オムニボックスが所定の位置に留まるようになりました（#10862）、タブキーでのフォーカス移動が正しくページフォーカスを切り替えるようになりました（#10868）、ウィンドウ外にドラッグしたスクロールバーのドラッグ操作でマウスリリースがドロップされなくなりました（これはLinux全体で修正されました、#11343）。

サイト互換性ルール

一部のサイトは、User-Agentスニッフィングに基づいてLadybirdに壊れたコンテンツを提供していました。これに対し、ブラウザにサイトごとのポリシーをハードコーディングするのではなく、実行時にロードされる宣言的なサイト互換性ルールで対応するようになりました（#11327）。ルールはプレーンなJSON形式なので、誰でもどのサイトに対して何を行っているかを確認できます。最初のユーザーは nytimes.com と cnn.com で、どちらもUser-Agent文字列から「Ladybird」を隠すことで正しくレンダリングされるようになりました（#11333）。

より良く動作するようになったサイト

• chatgpt.com：ログイン後のページでのクラッシュと3つのレイアウト修正（#11398）。
• vscode.dev：新しいファイルを開いた数秒後にクラッシュしていました。ヒットテストが間違った要素からpointer-eventsを読み取っており、VS Codeの空のエディタヒントがそれをトリガーしていました（#11342）。
• icloud.com：ページの1KB以上後で文字コードを宣言するサイトが、文字化けしなくなりました（#11219）。
• strava.com：2つの別々の修正により、アクティビティマップの読み込み時間がそれぞれ約半分になりました（#11133, #11114）。svg.getScreenCTM()が実装されたため、チャートのポップアップがマウスカーソルを追従するようになりました（#11177）。また、メモリ不足でクラッシュしていたアクティビティページが、使用メモリ量を17.8GiBから61MiBに削減しました（#11055）。
• outlook.comとWord：Outlookのクラッシュが修正され、Wordへのサインインが機能するようになりました（#11216）。
• milliondollarhomepage.comとxkcd：<area>イメージマップリンクがクリック可能になりました（#10863）。

CSS

• 3Dトランスフォーム：transform-style: flat境界でのフラット化（#11009）、backface-visibility（#10960）、BSPツリーを使用した交差する3D平面の正しい深度ソート（#11045）など、3Dレンダリングの大きな欠落部分を埋める一連の修正が行われました。深度ソートは、純粋なCSS 3Dトランスフォームで構築されたDOOMレンダラーであるcssDOOMでテストされ、壁が正しい順序で描画され、サーフェスがちらつかなくなりました（#11466）。
• overflow-wrap：長い単語がコンテナからはみ出す代わりに、グリフ境界で緊急ブレークするようになりました（RTLテキストはまだ緊急ブレークしません）（#11416）。Google翻訳で顕著に改善されました。
• 右から左へのスクロールコンテナが正しい方向にスクロールするようになりました。以前は一部のRTLコンテンツに到達できませんでした（#11023）。
• テキスト装飾が、装飾ボックスの色、太さ、フォントジオメトリから描画されるようになり、BBC Weatherでの無条件の下線が修正されました（#10744）。

LadybirdでのcssDOOMの最初のレベルを駆け足で見てみましょう。

［動画］

そして、overflow-wrapの前後のGoogle翻訳です。

パフォーマンスを真剣に捉える

ブラウザベンチマークをマスターに対して継続的に実行し、結果をlinegodown.lolで追跡しています。8月中のSpeedometer 2スコアは約47から約64へ、Speedometer 3は約2.5から約3.9へ、StyleBenchは約3.5から約83へと上昇しました。これらは成熟したエンジンと比較するとまだ控えめな数値ですが、進歩は本物です。

［画像: Linux上でのLadybird 2026年8月のベンチマークスコアの3つのチャート：Speedometer 2は47から64へ上昇、Speedometer 3は2.5から3.9へ上昇、StyleBenchは3.5から83へ上昇］

この推進力の一部は体系的です。個々の操作を他のブラウザと比較してベンチマークし、著しく遅いものを見つけ、その原因を追跡します。Chromiumの100倍遅いDOM操作は、通常、深い理由で100倍遅いわけではありません。何かが単に間違っており、それを見つけることが実際のページを助けます。この1ヶ月で、そのような比率の多くが1桁削減されました。canvas fillStyleの解析はChromiumの約90倍遅かったものから約2倍に（#11300）、replaceChildren()は13倍から4倍未満に（#11306）、リストの挿入と削除は120倍以上から20倍未満になりました（#11389）。

JavaScriptエンジンも、プロパティアクセス（#11175）、スプレッド（#11383）、Promiseコンビネータ（#11374）、JSON.stringify（現在ベンチマークでV8の約15%以内です、#11329）のために一連の高速パスを獲得しました。最も満足のいく修正は、一時的にスパースになった配列が、遅いハッシュテーブルストレージに永遠に留まっていたことです。30行のコード追加で、Minecraft4kのFPSが10.2から14.5に向上しました（#11423）。

新しいスタイルエンジン

セレクタマッチング、スタイル無効化、カスケード、計算済みスタイル保持を新しいエンジンに置き換えました（#11088）。スタイル作業は、変更された可能性のあるものだけでなく、変更されたものに比例するようにしたいと考えています。

歴史的に、何かが変更されると、ブラウザエンジンは変更が影響を与える可能性のあるすべてをマークし、それらをすべて再マッチングおよび再カスケードしていました。最新のエンジンは、無効化セットやスタイル共有などの技術でそのセットを絞り込みますが、パターンは同じであり、メニューを開くだけで数十個の要素のスタイルを変更するために数千個の要素が無効化されることがあります。新しいエンジンは、DOMミューテーション、状態変更、CSSOM編集を型付きデルタのストリームとして扱い、各デルタをそれに依存するセレクタにルーティングし、出力が変更されない限り停止します。データベースの用語で言えば、セレクタは常駐クエリであり、計算済みスタイルはインクリメンタルに更新されるマテリアライズドビューです。

正確性が難しい部分です。プレーンでキャッシュフリーの評価器が参照実装として機能し、すべての高速パスがそれにチェックされます。エンジンの入力ストリームは、実際のブラウジングセッションから記録して決定論的に再生することもできます。開発中、実際のサイトの録画を再生し、それぞれ数百万のイベントを処理し、出力のずれをすべて失敗と見なしました。

多くのワークロードでは、新しいエンジンはまだそのアプローチよりも遅く、多くのチューニングが必要です。しかし、この種のインクリメンタルな再スタイリングを正確に測定するStyleBenchでは、主要なエンジンと同じ範囲にいます。これは、2026年8月末のM3 MacBook Proでの結果です。

［画像: 2026年8月末のM3 MacBook ProでのStyleBenchスコアの棒グラフ：Firefox 232.8、Safari 129.5、Ladybird 116.3、Chrome 103.8］

Firefoxは依然として大きく先行しています。しかし、このエンジンはまだ1ヶ月のものであり、最適化の余地はたくさんあります。:^)

レイアウト結果のキャッシュ

今月まで、ほぼすべての変更で、ビューポートから下までドキュメント全体を再レイアウトする必要がありました。position: absoluteやSVGの周りではいくつかのケースで部分的な再レイアウトがありましたが、それだけでした。完全な再レイアウトは、若いエンジンで正確性を保つための簡単な方法ですが、大きなページでは毎回同じ結果を生成する多くの作業を繰り返します。

レイアウト結果は、入力制約に基づいてキャッシュされ、再利用されるようになりました（#11113）。フォーマットコンテキストの実行は、親が渡すすべて（コンテキストのタイプ、サイジング制約、ルートの状態）をキーとしています。サブツリーに変更がない場合、実行全体がキャッシュから再生され、ネストされた実行も含まれます。フラグメントオフセットは包含ブロックに対する相対的なものであるため、キャッシュされたサブツリーは新しい位置で再生できます。シャドウモードは、キャッシュヒットごとに実際のレイアウトを再実行し、ずれがあればパニックを起こします。

残りの作業は、キャッシュヒットの可能性を高めることに費やされました。キャッシュは元々すべてのブロック軸入力をキーとしていたため、親要素がその高さを解決すると、下のすべてのキャッシュされた結果が破棄されました。これは、ほとんどのコンテンツがそれらの値を見ないにもかかわらず発生します。ネストされたflexページでは、1つのリーフが1回のレイアウトで29回測定されることがありました。現在、ボックスがそれらの入力を実際に観察したかどうかを記録し、観察しなかったものを無視するようにしました（#11346）。また、DOMミューテーションは、インクリメンタルに更新されたツリーとゼロから再構築されたツリーを比較するテストに裏打ちされ、レイアウトサブツリー全体の再構築を停止しました（#11126）。

新しいスタイルエンジンと合わせて、これらの作業が上記のベンチマークの進歩の大部分をもたらしました。

CSSアニメーションをメインスレッド外で実行

実行中のCSSアニメーションは、アニメーションのタイムライン全体がキーフレームからわかっているにもかかわらず、スタイル再計算、ペイント状態の再構築、新しい表示リストの記録のために、60Hzでメインスレッドをウェイクアップさせていました。これはJavaScriptと同じスレッドを競合していました。

現在、対象となる不透明度とトランスフォームのアニメーションは、解決されたキーフレーム、タイミング、イージングとして一度記述され、コンポジタに渡され、コンポジタは独自のvsyncでそれらを進行させます（#11470）。アニメーション実行中はメインスレッドは関与しません。スクリプトがgetComputedStyle、currentTime、またはplayState経由でアニメーションについて問い合わせると、オンデマンドでサンプリングされるため、回答は決して古くなりません。有限アニメーションは、終了時にanimationendを発火させるためのウェイクアップタイマーが1つだけ設定されます。

メインスレッドがJavaScriptの実行で忙しい間もアニメーションはスムーズに保たれ、アニメーションが多いページは消費電力を抑えるはずです。キーフレーム内のカスタムプロパティも正しくアニメーションするようになりました（#11477）。

LibWebのRustへの移行拡大

7月のニュースレターでは、スタイルとレイアウトのRustへの移行について取り上げました。8月には、さらにいくつかの部分がRustによって単独で所有されるようになりました。

• CSS解析が移行されました（#11318, #11334, #11240, #11360）。各文法ファミリーはA/Bモードの背後に配置され、RustとC++の両方のパーサーを実行して、全テストスイートでシリアライズされた出力を比較しました。C++は、不一致がゼロになった時点で削除されました。また、置き換えたC++よりも高速であることが判明しました。
• 計算済みスタイルの格納と計算はRustが所有するようになりました。完全なスタイル更新は、C++へのコールバックなしでRustパイプライン内に留まるようになりました（#11155）。
• ペイントパイプライン（表示リストの記録とヒットテストを含む）が移植され（#11222）、古いC++のペイント可能オブジェクトは削除されました（#11273）。
• 文字列は、両言語間で単一の表現を共有するようになり、テキストがコピーなしで境界を越えられるようになりました（#11278）。

専用のWebAssemblyコンパイラサービス

Wasmコンパイルは既にページプロセス外で実行されていましたが、各ページプロセスは独自のコンパイラをフォークしており、そのフォークがサンドボックス制限と衝突していました。多くのシステムでは、サイレントにインタープリタにフォールバックしていました。ブラウザプロセスは、独自の最小限のサンドボックスを持つ単一のWasmCompilerサービスを起動するようになり、ページプロセスはIPC経由でそれに到達し、フォーク権限を完全に失います（#11133）。これによりサンドボックスが強化され、同時に高速化されました。これが、Stravaマップがコールド訪問時に約半分の時間で読み込まれる理由です。

JavaScript値のケーシング

先月、ArrayBufferの内容とWasmメモリをケーシングしました。今月は、NaNボクシングされたJavaScript値に格納されるセルポインタのケーシングを追加しました。これにより、破損した値がどこを指せるかが制限されます。JavaScriptヒープ全体を完全にケーシングするわけではありません。以前は、GCヒープ内の1つのNaNボクシングされた値を破損させるだけで、エンジンを任意のプロセスメモリに指させることができました。現在、すべてのGCヒープブロックは単一の予約領域に格納され、セルペイロードはオフセットとして格納され、デコード時にマスクされるため、偽の値は領域内にしか着地できません（#11086, #11316）。

インタープリタの生成コードでは、ケージベースはCPUレジスタにピン留めされているため、そこでアンボクシングするのはマスクと加算であり、メモリロードは発生しません。新しく生成されたバイトコードも読み取り専用マッピングに格納されるようになったため、ヒープ破損で命令ストリームを直接書き換えることはできなくなりました。

ネットワーク

• 不完全な証明書チェーンがLinux上のサイトを壊さなくなりました。他のブラウザが行うように、不足している中間証明書を取得し、チェーンは信頼されたルートに検証される必要があります（#10661）。
• 恒久的なリダイレクトがキャッシュされるようになりました。これにより、301リダイレクトを行うサイトを再訪問する際に、リダイレクトのラウンドトリップが節約されます（#11460）。
• リロードが実際に再検証するようになりました。以前は、キャッシュされたページをリロードしても、サーバーがダウンしていても、サーバーにまったく接続されませんでした。これを調査したところ、HTML仕様のバグも発見しました（#11004, whatwg/html#12760）。

Web Platform Tests (WPT)

当社のWPTスコアは、今月2,079,020から2,088,677に増加し、9,657のサブテストが増加しました。参考までに、7月の増加は108でした。

最大の増加は、ナビゲーション、iframe、srcdocドキュメントを介したリファラーの伝播をカバーする約2,500のリファラーポリシーサブテストから来ました。これらは月末に合格し始め、現在、そのスイートの99%に合格しています。残りは、今月の機能作業を反映しています。3Dトランスフォーム、スクロールスナップ、Media Source Extensionsがすべて差分に表示されています。

その他の注目すべき変更

• WebGLがWindowsで動作するようになりました。ANGLEのDirect3D 11バックエンド経由です。以前は完全にコンパイルアウトされていました（#11312）。
• JPEG XLデコーディングがjxl-rsに切り替わりました。これは、ChromeとFirefoxがJPEG XLサポートを発表するために採用しているRustデコーダーです（#11386）。
• 非表示およびオクルードされたウィンドウは作業を停止します。ラスタライズなし、スムーズスクロールのティックなし、表示できないページのフレームプレゼンテーションなし（#11365）。メインスレッド外のアニメーションと合わせて、バッテリー寿命の向上に役立つはずです。
• セッション履歴とナビゲーションがブラウザプロセスに移行しました（#11116, #11270）。これはサイト分離の前提条件です。
• DOMがJavaScriptラッパーから分離されました（#9973）。DOMノードは、スクリプトが実際に触れるまでJavaScriptオブジェクト状態を持たなくなり、メモリ使用量を削減しました。また、同じDOMが「ワールド」ごとに個別のラッパーを持つことを可能にし、これはブラウザ拡張機能のコンテンツスクリプトが必要とする分離であり、拡張機能サポートへの一歩となります。
• システムフォントは一度だけ検出され、ヘルパープロセスに読み取り専用カタログとして渡されるため、これらのプロセスはフォントディレクトリへのサンドボックスアクセスを必要としなくなりました（#11465）。
• コンテキストメニューまたはミドルクリックによる貼り付けがpasteイベントを発火するようになりました。これにより、貼り付けられたコードをフィールドに分割する検証コードフォームが、どのように貼り付けても機能するようになりました（#11020）。

アルファ版への道

最初のアルファ版は2026年に開始すると述べており、その計画は依然として有効です。開始前に残っている作業は、ほとんどがエンジン作業ではありません。ターミナルからの起動を必要としないクラッシュレポート、macOSおよびLinux向けの署名済みインストール可能ビルド、アルファユーザーが改善を迅速に受け取れるようにする自動更新メカニズム、簡単な初回実行エクスペリエンス（自動更新されるEasyListのようなオプションのアドブロックフィルタリストを含む）、およびダウンロード場所です。アルファ版開始時にエンジンが完成しているわけではありません。それがアルファ版の目的です！

8月は以上です。お読みいただきありがとうございました。来月お会いしましょう！