Paul Kinlan と申します。Chrome のデベロッパー リレーションズを担当しています。私は、プロダクト チームとエンジニアリング チームに実際のデベロッパーの視点を反映させ、デベロッパーの満足度を高めることを目標とするノーススター指標を設定することを任務とする、熱心なウェブ アドボケイトのチームと連携して仕事をしています。
Google は、「満足度」は追跡と改善が難しい、主観的な指標であることを認識しています。そのため、デベロッパーのニーズに重点を置きながら、インパクトを与える方法を常に改善しています。Google が重視している指針は、「デベロッパーが使い慣れたツールを活用する」ことです。Stack Overflow による最近の調査では、75% の開発者がフレームワークまたはなんらかの抽象化を使用していると報告しています。そこで、テクノロジー スタックについてすでに決定している、または制御できないデベロッパーに最適なサービスを提供するにはどうすればよいか、Google は考えていました。余分なオーバーヘッドを増やさずに生産性を高めるにはどうすればよいですか？
Chrome の小さなチームが Aurora というプロジェクトに取り組んでおり、ウェブ プラットフォームのサードパーティ抽象化（フレームワークやライブラリなど）を扱うことを目標としています。これらの抽象化にパフォーマンスの向上を直接もたらすことを目標としています。その負担をお客様（ウェブ デベロッパー）に負わせるのではなく、
Chrome Dev Insider 第 3 弾では、Project Aurora チームの Addy Osmani 氏、Kara Erickson 氏、Houssein Djirdeh 氏に、このプロジェクトへの取り組み方と今後の展望について詳しくお聞きしました。
内部情報: サードパーティ フレームワークの使用
このプロジェクトの始まりから説明しましょう。どのような経緯があったのでしょうか？
Addy: Aurora は、デベロッパーの現在の状況を把握し、デベロッパーが目指す目標の達成を支援するというシンプルなアイデアから始まりました。たとえば、デベロッパーが選択した一般的なテクノロジー スタックのパフォーマンスを改善する支援などです。多くのアプリ デベロッパーは、React、Vue、Angular または Next.js や Nuxt などのメタフレームワーク* を使用して構築しています（もちろん、他にも多くのフレームワークがあります）。Svelte、Lit、Preact、Astro です。など、さまざまな方法で使用できます。こうしたデベロッパーが（パフォーマンスなど）専門知識を深めることを期待するのではなく、デフォルトでこれらのスタックに多くのベスト プラクティスを組み込むことで、成功の道を歩むことができるようにします。こうすることで、ウェブ向けに作成するだけで、サイトの品質が向上します。
Aurora は、広く使用されているフレームワークとメタフレームワークをいくつか選択してパートナーと連携し、学んだこと（優れた画像コンポーネントの構築方法など）を文書化します。これにより、他のユーザーが Chrome フレームワーク ファンドを通じて他のフレームワークやツールを迅速にフォローし、スケーリングを試すことができます。ウェブ エクスペリエンスの品質はブラウザで改善できますが、（場合によっては）フレームワークでも改善できると Google は考えています。すべてのユーザーにとって質の高いウェブを実現するという Google の目標達成に役立てていただけると幸いです。
Kara: 詳しく説明すると、デベロッパー エクスペリエンスを改善することで、ウェブのパフォーマンスを向上させることを目的としています。パフォーマンスのベスト プラクティスを公開するだけでは不十分です。ベスト プラクティスは頻繁に変更され、企業が最新の状態を維持するのは困難です。パフォーマンスよりも優先される独自のビジネス上の優先事項がある。
デベロッパーがパフォーマンスに費やす時間が限られている場合、デベロッパーがパフォーマンスの高いアプリを簡単に（そして迅速に）構築できるようにするのが Google の考え方です。Google は、一般的なウェブ フレームワークと提携することで、上位レベルのコンポーネントやコンフォーマンス ワーニングなどを通じてデベロッパー エクスペリエンスを向上させる、適切な抽象化レイヤにいます。これらの一般的なツールを使用するすべてのデベロッパーが、これらのメリットを利用できます。理論上、推奨されるアドバイスが変更された場合、Google は内部でコンポーネントを更新できるため、デベロッパーは最新の状態を維持する必要がありません。
Houssein: 私はデベロッパー アドボケイトとして Google に入社し、数年後にソフトウェア エンジニアリングに転向しました。これまでの私の仕事の多くは、優れたユーザー エクスペリエンスを構築するためのさまざまな方法をウェブ デベロッパーに教えることでした。サイトのパフォーマンスとユーザビリティに影響する可能性のある一般的な問題について、デベロッパーに警告するため、同じガイダンスが繰り返し提供されました。Aurora プロジェクトの構想を始めた当初、Google は「デベロッパーが何をすべきかを指示しなくても、ツールチェーンがすべてを処理するような方向に進むことができるだろうか？」と考えました。
私の理解が正しければ、エンジニアは 6 人ですか？すべてのフレームワークやライブラリに対応することはできません。では、パートナーを選ぶにはどうすればよいでしょうか。どのような人たちですか。
Addy: ウェブは多くの点でワイルド ウェストのようなものです。フレームワーク、バンドルツール、ライブラリ、サードパーティは、ほぼ自由に選択できます。これにより、パフォーマンスの良し悪しに影響する複雑さが複数のレイヤに発生します。パフォーマンスを向上させる最善の方法の一つは、意見を述べることに抵抗のないレイヤを見つけて、意見を追加することです。
たとえば、ウェブ フレームワーク（Next.js、Nuxt.js、ある程度は Angular）は、手動で作成したソリューションよりも、より多くの意見やデフォルトを組み込むようにしています。これが、Google が彼らと連携する理由の一つです。このようなモデルでは、Core Web Vitals を改善するために、画像、フォント、スクリプトの読み込み方法のデフォルトを強化することが理にかなっています。
また、最新のベスト プラクティスが有効な場合や見直しが必要な場合を確認するうえでも有用です。また、最適化の問題を解決する方法についてエコシステム全体に情報提供することもできます。
Kara: 現実的には、人気も考慮する必要があります。ウェブに最大限の影響を与えるには、既存のデベロッパー コミュニティが大きいフレームワークやライブラリを使用するのが理想的です。これにより、より多くのデベロッパーとアプリにリーチできるようになります。しかし、人気だけで判断することはできません。最終的には、人気度、ライブラリの独自性、利用可能な機能セットの組み合わせによって決まります。
たとえば、人気度だけを重視する場合は、React、Vue、Angular の「ビッグ 3」が候補になります。ただし、Google では Next.js、Nuxt、Angular を最も使用しています。これは、React や Vue などのビュー ライブラリは主にレンダリングに重点を置いているため、必要なすべての機能を直接ビルドすることはできないためです。そのため、Google は、それらの上に構築された独自のメタフレームワーク（Next.js と Nuxt）とより緊密に連携しています。この抽象化レベルでは、組み込みコンポーネントを作成できます。また、サーバーが組み込まれているため、サーバーサイドの最適化を組み込むことができます。
Angular が深いパートナーシップのリストに含まれていますが、これはメタフレームワークではありません。Angular は非常に人気がありますが、React や Vue のような補完的なメタフレームワークがないため、特別なケースと言えます。そのため、Google は Angular の開発チームと直接連携し、可能であれば CLI を通じて機能を提供しています。
また、Gatsby などの他のプロジェクトと継続的な関係を築いており、デザインについては定期的に同期していますが、コードには積極的に貢献していません。
では、実際にはどのように機能するのでしょうか。この問題を解決するためにどのようなアプローチをとりましたか。
Kara: 実際には、緊密に連携しているフレームワークがいくつかあります。このフレームワークを使用してアプリをプロファイリングし、パフォーマンスに関する一般的な問題を特定します。その後、フレームワーク チームと連携して、これらの問題を解決する試験運用版の機能を設計し、OSS リポジトリに直接コードをコントリビュートして実装します。
パフォーマンスへの影響が予測どおりであることを検証することが非常に重要であるため、Google は外部企業と連携して本番環境でパフォーマンス テストも実施しています。結果が良好であれば、この機能を「安定」させ、デフォルトにする可能性があります。
このすべてが、説明されているほど簡単ではありません。これまでに直面した課題や学んだことを教えてください。
Houssein: 優先順位が競合する一般的なオープンソース リポジトリに貢献することは、Google が全力で取り組んでいる重要な取り組みの 1 つです。Google チームだからといって、必ずしも Google チームの機能が優先されるわけではありません。そのため、他のチームの邪魔にならないよう、新機能の提案とリリースの一般的なプロセスに沿って対応するよう努めています。Google は、Next.js、Nuxt、Angular のエコシステムで、協力的なメンテナーと連携できたことを幸運に思います。ウェブ エコシステムに関する Google の懸念に耳を傾け、さまざまな形で Google と連携していただけることを感謝しています。
Google が提携している多くのフレームワークでは、全体的なミッションは同じです。つまり、優れたデベロッパー エクスペリエンスを享受しながら、デベロッパーがすぐに使える優れたユーザー エクスペリエンスを実現する方法です。Google は、数百人、場合によっては数千人ものコミュニティ コントリビューターとフレームワークのメンテナンス担当者が、それぞれ相互に関連する異なるプロジェクトに取り組んでいることを認識しており、そのことを尊重しています。
Kara: また、パフォーマンスへの影響を検証し、データに基づいて対応するため、プロセスにはもう少し時間がかかります。未知の領域であるため、最適化をテストしてもうまくいかず、予定していた機能を構築できないこともあります。機能がうまくいったとしても、パフォーマンスを検証するための追加の手順に時間がかかり、タイムラインが延びてしまいます。
機能をテストする本番環境のパートナーを見つけることも難しい場合があります。前述のように、パートナーはビジネスであり、独自の優先事項があります。そのため、優先される既存のプロジェクトと新しい取り組みがうまく連携していない場合、新しい取り組みを組み込むのは難しい場合があります。また、支援に最も関心を持っている企業は、すでにパフォーマンス向上に時間と費用を投資している傾向があるため、Google のターゲット ユーザーではありません。Google は、パフォーマンスに投資できないコミュニティの広範なユーザーからフィードバックを収集しようとしていますが、そうしたユーザーは Google に連絡する可能性が一番低いのです。
では、どのような最適化に取り組んでいますか？
Houssein: 数千ものアプリケーションを分析した結果、パフォーマンスに関する最大の問題は、通常、フレームワーク自体ではなく、アプリケーション コードのアンチパターンが原因であることがわかりました。たとえば、不要に大きな画像を配信する、カスタム フォントを遅れて読み込む、サードパーティのリクエストを過度に取得してメインスレッドをブロックする、非同期コンテンツによってページ上の他の要素が移動する可能性があることを処理しないなどです。これらは、使用するツールに関係なく発生する可能性がある問題です。そこで、これらの問題を適切に処理しつつ、フレームワーク ツールに適した優れたデベロッパー エクスペリエンスを提供するデフォルトの最適化を組み込むことはできないかと考えました。
この考えに基づいて、以下をリリースしました。
- Next.js 画像コンポーネント。
- Next.js スクリプト コンポーネント。
- Next.js のビルドプロセスでのフォント自動インライン化。
- Angular 画像ディレクティブ。
- Next.js コンフォーム性 ESLint プラグイン: デベロッパーに実用的なガイダンスを提供します。
Google の取り組みは、他のフレームワークやツールが同様の最適化を実装するきっかけとなっています。これには以下のようなコンテンツが含まれますが、これらに限定されるものではありません。
- Nuxt イメージ モジュール
- Nuxt フォント指標のオーバーライド
- Nuxt スクリプト コンポーネント（進行中）
- Gatsby スクリプト コンポーネント
こうした選手たちとの仕事で得られた成果を教えてください。
Houssein: 多くのサイトで、Google がリリースした最適化によりパフォーマンスが向上しています。たとえば、Leboncoin は、Next.js の画像コンポーネントに切り替えた後、LCP を 2.4 秒から 1.7 秒に短縮しました。現在、テストや試験運用の段階にある機能は他にも多数あります。これらの機能から得られた知見や成果は、こちらで引き続き共有していきます。
最も人気のあるフレームワークやライブラリに重点を置いているとのことですが、Google が積極的に取り組んでいない他のフレームワークやライブラリも、この取り組みからメリットを得られるでしょうか？
Addy: Aurora が共同で行っているパフォーマンス最適化の多くは、どのフレームワークでも再現できます。たとえば、画像コンポーネントやスクリプト コンポーネントの開発では、既存のベスト プラクティスをコード化することがよくあります。Google では、このようなコンポーネントの作成方法と、各フレームワークでのコンポーネントの外観をドキュメント化しています。アイデアをコピーする際の参考にしてください。
1 つのエコシステム（React や Next.js など）から学んだことを他のエコシステムに適用することで、大きな成果を上げています。たとえば、新しい Angular Image ディレクティブ（Next.js Image コンポーネントの構築で得た知見に基づいて構築）や、Gatsby で細分化された JavaScript チャンキングのアプローチをリリースしています。
一方で、すべてのフレームワークで、コントリビューターが同様のパフォーマンス機能を構築したり、ユーザーにとって重要と思われる他の最適化に投資したりするための時間や資金が確保されているわけではありません。Chrome ウェブ フレームワーク ファンドは、JavaScript エコシステムにおけるパフォーマンス関連の作業を Google がスポンサーとして支援し、プロジェクトがコントリビューターに報酬を支払い、エコシステム内でパフォーマンス関連の作業をさらに拡大できるようにするものです。
今後のチームのロードマップについて教えてください。
Kara: 今後、多くのプロジェクトが予定されています。主な改善点は次のとおりです。
- フォント関連の CLS を削減する: ウェブフォントが読み込まれて代替フォントが置き換えられると、レイアウトがずれるのはよくあることです。Google は、フォント指標のオーバーライドと「size-adjust」プロパティを使用して、Next.js でフォント関連の CLS をデフォルトで削減する方法について検討しています。また、Nuxt チームともこの件について協議しており、来年にはさらに多くのフレームワークにこのアイデアを拡張する予定です。
- INP のデバッグ: Interaction to Next Paint（INP）指標がリリースされたため、Google はフレームワークと連携して、コミュニティの INP の問題の最も一般的な根本原因を調査し、修正案を提案しています。Google は Angular と緊密に連携してこの問題に取り組んでおり、近日中に結果をお知らせできる予定です。
- 一般的なサードパーティ スクリプトを最適化する: サードパーティ スクリプトを適切なタイミングで読み込むと、パフォーマンスに大きな悪影響を与える可能性があります。非常に一般的なサードパーティがいくつかあるため、これらのサードパーティ用にラッパーを提供して、フレームワークで最適に読み込まれ、メインスレッドをブロックしないようにできるかどうかを検討しています。この調査の開始点として、作成した Next.js スクリプト コンポーネントを使用しています。
デベロッパーはこちらのサイトで進捗状況を確認できます。
ニュース トピック
最後に、Google 内で進んでいるフレームワークに関する興味深い最新情報をいくつかご紹介します。
7 月に、Chrome チームはフレームワークとツール ファンドの最新の資金調達ラウンドで 50 万ドルを拠出することを発表しました。このファンドは、ウェブ上のパフォーマンス、ユーザー エクスペリエンス、デベロッパー エクスペリエンスの向上を目指すプロジェクトに重点を置いています。今後の資金提供では新しいプロジェクトが検討されますので、リクエストを送信してください。
もちろん、コミュニティでは素晴らしいことがたくさん起こっています。このエコシステムには、Deno の Fresh などの新しいフレームワークや、Svelte のオンボーディング チュートリアルなどの優れたエクスペリエンスが揃っています。これはブラウザ内デモであるだけでなく、Web Container API を使用してブラウザで Node.js をネイティブに実行します。良いものがたくさんあります。
エコシステムが統合され、ブラウザでできることの幅が広がり、デベロッパーがすべてのユーザーにとって便利なプロダクトを構築できるようになることを、心から楽しみにしています。ウェブ デベロッパーにとって、今はエキサイティングな時代です。
次回の情報通向け情報まで、Hwyl fawr（ウェールズ語で「良い一日を」）。
今回の Chrome Dev Insider について、ご意見をお聞かせください。フィードバックをお寄せください。