本記事では Speculation Rules API を使ったプリレンダリングの性能評価を行うためのメトリクスについて紹介します。 はじめに ウェブページの読み込みは本質的に時間のかかる処理です。ウェブブラウザは HTML ファイルを解析することでページ表示に必要なリソースを特定・収集・処理し、それらを組み合わせてページの描画（レンダリング）を行います。 ページ読み込みを高速化するアプローチの一つとして投機実行が知られています。投機実行はページ読み込みに必要な処理をあらかじめ実行しておくことで、実際にページを描画するときの処理を減らします。ウェブブラウザにはこのような投機実行を行うための API が多数実装されています。若干情報が古くなっていますが「リソースの読み込みを助けるウェブブラウザ API の世界」という記事に投機実行のための API をまとめたので詳しくはそちらを見てください。

ウェブブラウザはネットワークから様々なリソースを集め、それらを処理して組み合わせてウェブページをレンダリングします。リソースが揃わないとレンダリングできないので、この一連の処理のどこかが遅れるとページの表示も遅くなります。レンダリングをすみやかに開始できるようにウェブブラウザはリソースの取得やその処理を最適化するための API を提供しています。本記事ではそれらを網羅的に紹介し、ウェブアプリの性能改善を図る上でどのようなブラウザ機能が使えるのかを知ってもらうことを目的としています。各機能の具体的な適用事例については他の記事に委ねます。 本記事の内容は記事公開時点での情報に基づいており、閲覧時点では既に古くなっている可能性があります。最新の正確な情報は一次情報源を参照してください。また特定のブラウザ実装について言及する場合は、断りがない限り Chrome を想定しています。誤りや補足、質問な

Message Passing での話題を契機に、色々な人が自身の Design Docs 観を共有していて、とても興味深く読ませてもらいました。普段「仕事を進める上で当たり前に必要なもの」として書いている自分に気づき、これを機に自分の Design Docs 観も言語化してみようと思ったのが本記事です。実践の一例を付け加えることが狙いであり、「Design Docs はかくあるべき」と主張するものではないです。 はじめに 「人によって思い浮かべる Design Docs 観が全然違う！多様で面白い！！」というのが話の出発点ですが、さすがに想定しているものが違いすぎると話が発散してしまうので、本記事では Design Docs を「ソフトウェアエンジニア (私) が何らかのプロジェクトやタスクを進める上で書く文書」としておきます。 次に私の立場を明確にしておきます。私はオープンソースのウェ

ウェブブラウザにおいてメインスレッドはとても重要なリソースです。なるべくメインスレッドを使える状態にしておくことが滑らかな UI/UX を実現する上で重要になります。しかし、実際には多くの処理が実装上の理由やブラウザ仕様の不足によりメインスレッドでしか動かせないため、メインスレッドは忙しくなりがちです。特にページロード時は JavaScript の実行やリソース読み込みなどでとても忙しくなります。 とあるページの perf プロファイル。メインスレッドでせわしなく処理が行われている様子が分かる。 これを解消するために、ブラウザの処理をメインスレッド以外 (off-the-main-thread) でも実行できるようにする試みが行われています。 1. Off-the-main-thread とは メインスレッド以外のスレッドに処理を委譲することを off-the-main-thread と呼

新卒のソフトウェアエンジニアとして Google に入社して丸 6 年が過ぎました。「若者は 3 年で辞める」という話があるけど、その二倍も働いていることになります。当時の気持ちを忘れないうちに今までの振り返りをしてみようと思います。 (2019/04/04 追記) 入社までの話を「新卒のソフトウェアエンジニアになるまで」という記事に書きました。 なお、すべて個人的な体験談であって会社の見解等を表しているわけではありません。 きっかけ Google を意識したきっかけは大学一年生の頃に読んだ梅田望夫さんの『ウェブ進化論』でした。多分同世代の多くの人がこの本に影響を受けたんじゃないかと思います。私も「これからネットの世界はどんどん変わっていくんだ！」と興奮し、その中心的な会社だった Google に憧れを持ったことを覚えています1 。 直接的なきっかけは修士一年生の頃。そろそろ就活に向けて動

これは Chromium Browser アドベントカレンダー 26 日目の記事です。穴が空いたときの代理投稿のために用意してあったのですが無事に使わずに済んだので 26 日目として公開します。 本記事では Chromium のソースコードを眺めていて見かけた珍百景を紹介します。実用性は皆無です。他に見つけたら随時追加します。 ちなみに Chromium のソースコードの読み方については本アドベントカレンダー 1 日目の記事で紹介しました。みなさんも珍百景を見つけたらこっそり教えてください :D 天気の良い日 天気が良い日は陽気な気分でコードを書けますよね。 Web Platform Tests で使用するサブドメインは自由に設定できるのですが、その一つが「天気の良い日」になっています。理由は不明。なぜかフランス語のサブドメインも設定されていて、そっちはどうやら「生徒」という意味らしいです

これは Chromium Browser アドベントカレンダーの一日目の記事です。初日ということで、本記事では Chromium のソースコードを読む上で役に立つであろう、プロジェクトのディレクトリ構成やファイル構成を紹介します。 (2018/04/09) “The Great Blink mv”1 プロジェクトによってついに WebKit ディレクトリが blink ディレクトリにリネームされました。それに伴い本記事の内容を更新しました。差分は以下の通りです。 third_party/WebKit/Source を third_party/blink/renderer に置換。 blink/ 内のファイル名の命名規約を Bar.{cpp,h} から bar.{cc,h} に置換。 置換に伴う説明文の修正。 (2017/12/01) ディレクトリ構成について追記しました。 Chromium