Chrome のデベロッパー リレーションズ リードの Paul Kinlan と申します。私の仕事の一環として、デベロッパーの満足度向上を目標に掲げ、プロダクト チームやエンジニアリング チームに現実世界のデベロッパーの視点を取り入れるという、情熱に溢れたウェブ アドボケイト チームと連携しています。
Google は、「満足度」が追跡および改善すべき野心的かつ主観的な指標であると認識しており、デベロッパーのニーズを重視しながら、改善方法を繰り返し検討しています。私たちが実践すべき指針は、「デベロッパーのニーズに応える」です。Stack Overflow の最近の調査では、デベロッパーの 75% がフレームワークまたはなんらかの抽象化を使用していると報告しています。Google は、技術スタックについてすでに決定を行っているデベロッパーや、制御できないデベロッパーにサービスを提供するにはどうすればよいか、と自問してきました。オーバーヘッドを増やすことなく、生産性を向上させるにはどうすればよいですか？
Chrome の少人数のチームが Aurora というプロジェクトに取り組んでおり、フレームワークやライブラリなど、ウェブ プラットフォームのサードパーティ抽象化を利用することを目指しています。同社の目標は、顧客であるウェブ デベロッパーに負担をかけるのではなく、こうした抽象化によってパフォーマンス向上を直接実現することです。
第 3 回となる Chrome Dev Insider では、Project Aurora チームの Addy Osmani、Kara Erickson、Houssein Djirdeh に、このプロジェクトへの取り組みと今後の展望についてお話を伺いました。
情報通: サードパーティのフレームワークの使用
まず、このプロジェクトの発端から始めましょう。どうして生まれたのですか？
Addy: Aurora はまず、開発者が現状に立ち会って、目指す方向にたどり着けるようにサポートするというシンプルなアイデアからスタートしました。たとえば、同社が選択した人気の技術スタックを手助けしてパフォーマンスを改善するなどです。最近では、多くのアプリ デベロッパーが React、Vue、Angular、あるいは Next.js や Nuxt などのメタフレームワーク*（そしてもちろんその他多数）を使用して構築を行っています。Svelte、Lit、Preact、Astro。まだまだあります）。こうした開発者が（パフォーマンスなどで）熟練したエキスパートになることを期待するのではなく、これらのスタックにデフォルトでより多くのベスト プラクティスを組み込むことで、開発者が成功の場に落ち着くようにすることができます。このように、ウェブ向けに構築するだけで、サイトの品質が高まるという副作用が生じます。
Aurora は、広く使用されているいくつかのフレームワークとメタフレームワークをパートナーとして選び、Google が学んだこと（優れた画像コンポーネントの構築方法など）を記録することで、他のフレームワークが Chrome Framework Fund を通じて他のフレームワークやツールを利用してスケーリングを試せるようにしています。ブラウザを介してウェブ エクスペリエンスの質を向上させることは可能ですが、この目標はフレームワークを介して（場合により）達成できると考えています。すべての人にとってより質の高いウェブを実現するという Google の目標達成に、この取り組みがお役に立てば幸いです。
Kara: これをさらに拡張し、デベロッパー エクスペリエンスを改善することで、ウェブのパフォーマンスを向上させるというアイデアです。パフォーマンスのベスト プラクティスは公表するだけでは不十分です。頻繁に変更されるのに加え、企業が追い付くのは困難だからです。パフォーマンスよりも優先されるビジネス上の優先事項は、お客様によって異なります。
したがって、開発者がパフォーマンスに注力する時間が限られているなら、開発者がパフォーマンスの高いアプリを簡単に（かつ迅速に）開発できるようにしましょう。一般的なウェブ フレームワークと提携すれば、高レベルのコンポーネントや適合性警告などを通じてデベロッパー エクスペリエンスを向上させるための適切な抽象化レイヤが得られます。これらの一般的なツールを使用する人は誰でも、こうしたメリットを享受できます。理論的には、推奨するアドバイスが変更された場合、Google は内部でコンポーネントを更新できるため、デベロッパーは最新の状態を維持することについて心配する必要がなくなります。
Houssein: デベロッパー アドボケイトとして Google に入社した後、数年後にソフトウェア エンジニアリングの仕事に転職しました。これまでの仕事の多くは、優れたユーザー エクスペリエンスを構築するさまざまな方法をウェブ デベロッパーに教えることに携わっていました。サイトのパフォーマンスやユーザビリティに影響する可能性がある一般的な問題についてデベロッパーに警告するため、同じガイダンスのバリエーションを何度も提供しました。Aurora プロジェクトについて考え始めたとき、私たちは自問しました。「ツールチェーンがすべての処理してくれるので、開発者に何をすべきかを決して指示する必要がなくなるのか？」
では、エンジニアは 6 人ということになります。考えられるすべてのフレームワークやライブラリに対応することはできないでしょう。では、連携する相手をどのように選ぶのでしょうか。対象者は誰ですか？
アディ: ウェブはさまざまな点で、荒野の西部のようになっています。お好みのフレームワーク、バンドラ、ライブラリ、サードパーティを選択できます。これにより、何層もの複雑さが発生し、パフォーマンスの良し悪しを左右する可能性があります。パフォーマンスに変化をもたらす最善の方法の一つは、そうしたレイヤが独自の考えを持ち、より多くの意見を追加することに抵抗を感じないものを見つけることです。
たとえば、ウェブ フレームワーク（Next.js、Nuxt.js、ある程度の Angular など）は、手作業によるソリューションよりも多くの意見やデフォルトを盛り込もうとします。これが、YouTube がクリエイターと連携している理由の一つです。これらのモデルでは、Core Web Vitals を改善するために、画像、フォント、スクリプトの読み込み方法のデフォルトを強化することは理にかなっています。
また、最新のベスト プラクティスがどこで機能するか、または再考が必要な箇所を確認できる優れた方法にもなります。また、最適化の問題を解決する方法をエコシステム全体に知らせるのにも役立ちます。
Kara: 現実的には、人気度も考慮する必要があります。ウェブに可能な限り大きな影響を与えるためには、大規模なデベロッパー コミュニティが存在するフレームワークやライブラリを利用するのが理想的です。そこから、より多くのデベロッパーやより多くのアプリにリーチできます。人気が出るだけでは不十分です。最終的には、人気度、ライブラリの独自性、使用可能な機能セットの交差点になります。
たとえば、人気のみに着目すると、React、Vue、Angular が 3 つの大きなポイントとなります。ただし、Next.js、Nuxt、Angular を最もよく使用します。これは、React や Vue などのビュー ライブラリは主にレンダリングに重点を置いているため、必要なすべての機能を直接組み込むことは不可能です。そこで Google は、その上に構築された独自のメタ フレームワークである Next.js と Nuxt と緊密に連携しています。この抽象化レベルで、組み込みコンポーネントを作成できます。また、サーバーが組み込まれているため、サーバーサイドの最適化を含めることもできます。
Angular が深いパートナーシップのリストに入っていましたが、メタフレームワークではありません。Angular は非常に人気があるため、やや特殊なケースといえますが、React や Vue のように補完的なメタフレームワークはありません。Google は、Angular と直接連携し、可能であれば CLI を通じて機能を提供しています。
また、Gatsby のような他のプロジェクトと継続的な関係を築いていることは注目に値します。Gatsby では、設計に関してある程度定期的に意見が一致しているものの、積極的にはコードの投稿を行っていません。
では、これは実際にどのようなものでしょうか。この問題を解決するためにどのようなアプローチでしたか。
Kara: 実際には、密接に連携しているフレームワークがいくつかあります。少し時間をかけて、このフレームワークを使用してアプリをプロファイリングし、一般的なパフォーマンスの問題を把握します。その後、フレームワーク チームと協力して、これらの課題を解決するための試験運用版機能を設計し、実装のために OSS リポジトリに直接コードを提供します。
パフォーマンスへの影響が予測どおりであることを確認することは非常に重要です。そのため、外部企業と協力して本番環境でパフォーマンス テストを実施しています。テストの結果が良好な場合は、この機能が「安定」するのを支援し、デフォルトに設定することもできるでしょう。
すべてを口に出すほど簡単なことではありません。これまでにどのような課題や学びを得ましたか？
Houssein: Google ができる限り精通させようとしている重要なことの一つは、多くの優先順位が競合する人気のオープンソース リポジトリに貢献することです。Google のチームだからといって、必ずしも Google の機能が優先されるとは限りません。そのため、Google は新しい機能を提案し、リリースする一般的なプロセスに沿って対応できるよう最善を尽くしています。私たちは、Next.js、Nuxt、Angular エコシステムの受容的なメンテナンス担当者と連携できたことはとても幸運でした。ウェブ エコシステムに対する私たちの懸念に積極的に耳を傾けてくれて、さまざまな形で協力してくれたことに感謝しています。
Google が扱うフレームワークの多くでは、Google の全体的な使命は同じです。つまり、開発者はすぐにユーザー エクスペリエンスを改善し、優れた開発者エクスペリエンスを享受するにはどうすればよいのでしょうか。Google は、数千人とは言わないまでも数百人のコミュニティ貢献者やフレームワークのメンテナンス担当者が、互いに交差するさまざまなプロジェクトに取り組んでいることを認識し、尊重しています。
Kara: また、パフォーマンスへの影響を検証し、データに基づいて対処することを重視しているため、このプロセスにはもう少し時間がかかります。私たちは未知の領域にいるので、最適化を試してもうまくいかず、計画した機能を作成できないこともあります。たとえ機能に問題があったとしても、パフォーマンスを調査するためのこうした追加の手順には時間がかかり、スケジュールも長くなります。
また、機能をテストする製品版パートナーを見つけるのも簡単ではありません。前述したように、彼らは企業であり、独自の優先事項があります。そのため、優先すべき既存のプロジェクトとうまく連携していない場合、新しいイニシアチブに参加することは困難です。また、サポートに最も関心を寄せる企業は、すでにパフォーマンスへの投資に時間を費やしている傾向があるため、Google のターゲット オーディエンスではありません。YouTube では、パフォーマンスに投資できないにもかかわらず、YouTube に問い合わせをする可能性が最も低いコミュニティからフィードバックを収集するよう努めています。
では、これまでどのような最適化に注力してきましたか？
Houssein: 何千ものアプリケーションを分析した結果、最大のパフォーマンスの問題は、通常、フレームワーク自体ではなくアプリケーション コード内のアンチパターンに起因していることがわかりました。たとえば、不必要にサイズの大きい画像を送信する、カスタム フォントの読み込みが遅すぎる、メインスレッドをブロックするサードパーティ リクエストが多すぎる、非同期コンテンツがページ上で他の要素の変化を招きかねない処理をしすぎている、などです。これらはすべて、使用するツールに関係なく発生する可能性のある問題です。そこで、フレームワーク ツールに適した優れたデベロッパー エクスペリエンスを実現しながら、適切に対処できるようにデフォルトの最適化を組み込むことができるのではないかと考えました。
このような考えに基づき、Google は以下のプロダクトをリリースしました。
- Next.js 画像コンポーネント。
- Next.js スクリプト コンポーネント。
- Next.js のビルドプロセスでのフォントの自動インライン化。
- Angular 画像に関するディレクティブ。
- Next.js 準拠 ESLint プラグイン: デベロッパーに実用的なガイダンスを提供します。
この取り組みは、同様の最適化を実装するための他のフレームワークやツールにも影響を及ぼしています。これには以下のようなコンテンツが含まれますが、これらに限定されるものではありません。
- Nuxt イメージ モジュール
- Nuxt フォント指標のオーバーライド
- Nuxt スクリプト コンポーネント（進行中）
- Gatsby Script コンポーネント
これらの関係者の何人かに、あなたの仕事から得られた良い成果を教えてください。
Houssein: 多くのサイトで、最適化機能の導入によってパフォーマンスが向上しています。私のお気に入りの例の 1 つが Leboncoin です。Leboncoin は、Next.js の画像コンポーネントに切り替えた後、2.4 秒から 1.7 秒に LCP を短縮しました。現在、他にも多くの試験運用フェーズとテストフェーズがあります。これらのフェーズから得た教訓や成果については、こちらで引き続き共有していきます。
ご関心は特に人気の高いフレームワークであることはわかりますが、あなたが積極的に使用していない他のフレームワークやライブラリもメリットを得られる点はありますか？
追加: Aurora が共同で取り組んでいるパフォーマンス最適化の多くは、どのフレームワークでも再現できます。たとえば、画像コンポーネントやスクリプトコンポーネントの取り組みは、既存のベストプラクティスのセットを体系化したものになっていることが多いものです。このようなコンポーネントを構築する「方法」と、各フレームワークでコンポーネントがどのように表示されるかについて、文書化に努めています。アイデアをコピーするための出発点としてお役に立てば幸いです。
あるエコシステム（React や Next.js など）から学んだことを他のエコシステムにも導入することで、成功を収めています。たとえば、新しい Angular Image ディレクティブ（Next.js 画像コンポーネントの構築に関する Google の経験に基づいて構築）や Gatsby は、きめ細かい JavaScript チャンクへのアプローチを提供します。
同時に、すべてのフレームワークが同様のパフォーマンス機能を構築したり、ユーザーにとって重要と思われる最適化に投資したりするための帯域幅や資金を提供できるわけではないことも理解しています。Chrome Web Framework Fund は、Google が JavaScript エコシステムのパフォーマンスに関する取り組みを支援し、プロジェクトが貢献者に支払いを行い、パフォーマンスに関する取り組みをエコシステム内でさらに拡大できるようにするものです。
では、お客様のチームの今後のロードマップにはどのようなものがあるでしょうか？
Kara: 魅力的なプロジェクトがたくさんありますので、主な改善点は次のとおりです。
- フォント関連の CLS を削減: ウェブフォントが読み込まれて代替フォントを置き換えるときに、レイアウト シフトが生じることがよくあります。Next.js でフォント関連の CLS をデフォルトで削減するために、フォント指標のオーバーライドと「size-adjust」プロパティの使用を検討しています。また、この件については 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」はいかがでしたか？フィードバックをお寄せください。