JavaScript フレームワーク エコシステムへの準拠
入門のブログ投稿では、Google 検索、マップ、フォトなどの大規模なウェブ アプリケーションを開発、維持するためのフレームワークやツールを構築および使用する際に、Google が多くのことを学びました。ユーザー エクスペリエンスに悪影響を与える可能性のあるコードを記述しないようにデベロッパーを保護することで、フレームワークがパフォーマンスとアプリケーションの品質を向上させるうえで重要な役割を果たすことができることを証明しました。
Google 社内では、この手法を説明するために「適合性」という用語を使用しています。この記事では、このコンセプトを JavaScript フレームワーク エコシステムにオープンソース化する計画について説明します。
適合性とは
Google にとって、適合性は進化の 1 つでした。チームは、熟練した少数の管理者が大規模なコードレビューを行い、正確性の問題だけでなく、アプリの品質と保守性に大きな影響を与えたものを報告しました。成長を続けるアプリ デベロッパーのチームにこれを拡大するために、自動化され適用可能な方法でベスト プラクティスを体系化する適合性システムが開発されました。これにより、コード コントリビューターの数に関係なく、アプリの品質とコードベースの保守性に対する一貫した高い基準が保証されました。
適合性は、デベロッパーが十分な情報に基づいた対策を講じることを確保するシステムです。これにより、信頼性が構築され、予測可能な結果が得られます。チームの生産性を高め、チームが成長し、より多くの機能が同時に開発されるにつれ、スケーリングに不可欠になります。これにより、デベロッパーはプロダクトの機能の構築に集中できるようになり、パフォーマンス、ユーザー補助、セキュリティなどのさまざまな分野で細かな点や変化する状況から解放されます。適合性はいつでも無効にでき、チームがコミットすることを決めたものを適用できる範囲までカスタマイズできます。
適合性は厳格なデフォルトに基づいており、作成時に適用できる実用的なルールが提供されています。これは、次の 3 つの原則に分けられます。
1. 強力なデフォルト
適合性の基本の側面は、デベロッパーが使用するツールに強力なデフォルトを確実に設定することです。つまり、ソリューションはフレームワークに組み込まれているだけでなく、フレームワーク設計パターンにより、正しい処理を簡単に行い、アンチパターンに従うことが困難になります。フレームワークは、アプリケーションの設計とコード構造でデベロッパーをサポートします。
読み込みパフォーマンスのためには、すべてのリソース（フォント、CSS、JavaScript、画像など）を最適化する必要があります。これは、バイトのトリミング、ラウンド トリップの削減、最初のレンダリング、視覚的な準備、ユーザー操作に必要なものの分離といった複雑な課題です。たとえば、重要な CSS の抽出や、重要な画像の優先度の設定を行います。
2. 実行可能なルール
基本的な最適化を実施したとしても、デベロッパーは選択する必要があります。必要なデベロッパー入力の量に関しては、さまざまな最適化の可能性があります。
- 重要な CSS のインライン化など、デベロッパーによる入力を必要としないデフォルト。
- デベロッパーのオプトインを必須にする。たとえば、フレームワーク提供の画像コンポーネントを使用して、画像のサイズとスケーリングを行います。
- デベロッパーのオプトインとカスタマイズが必要です。たとえば、重要な画像にタグ付けして早い段階で読み込むなどです。
- 特定の機能ではないが、デベロッパーの判断を必要とするもの。たとえば、初期のレンダリングを遅らせるフォントや同期スクリプトの使用は避けます。
デベロッパーによる決定が必要な最適化は、アプリケーションのパフォーマンスにリスクをもたらします。機能が追加され、チームが拡大するにつれ、経験豊富なデベロッパーであっても、絶えず変化するベスト プラクティスに対応できず、時間を有効活用することもできません。適合性に関しては、デベロッパーが変更を続けている場合でも、アプリケーションが特定の基準を満たし続けるように、適切な実行可能なルールは強力なデフォルトと同様に重要です。
3.作成時間
開発ライフサイクルの早い段階でパフォーマンスの問題を見つけて排除することが重要です。コードを commit する前のオーサリング時間は、問題を検出して対処するのに理想的です。開発ライフサイクルで問題が発見されれば、対処が難しくなり、コストも高くなります。これは正確性の問題にも当てはまりますが、パフォーマンスの問題にも当てはまります。これらの問題の多くは、一度コードベースに commit されると遡って対処できないためです。
現在、ほとんどのパフォーマンス フィードバックは、ドキュメントや 1 回限りの監査によって帯域外になっているか、本番環境へのデプロイ後の指標の回帰によって表面化しています。これをオーサリング時に実現します
フレームワークの適合性
読み込みパフォーマンスのユーザー エクスペリエンスの水準を高く維持するには、次の質問に答える必要があります。
- 最適な読み込みとはどういうものですか？また、読み込みに悪影響を及ぼす可能性のある一般的な問題は何ですか？
- 開発者によるインプットを必要としない構築可能なソリューションは、次のうちどれですか。
- デベロッパーがこれらのソリューションを確実に使用し、最適に利用できるようにするには、どうすればよいでしょうか。
- 読み込みのパフォーマンスに影響を与えるために、デベロッパーが他に選択できることはどのようなものですか？
- 作成時点でこれらの選択（上記の 3 と 4）についてわかるコードパターンにはどのようなものがありますか。
- これらのコードパターンを評価するためにどのようなルールを策定できるか？ワークフローにシームレスに統合しながら、オーサリング時にデベロッパーに表示するには？
Google 社内にある適合性モデルをオープンソース フレームワークに導入するために、Google のチームは Next.js で大規模なテストを行ってきました。その改良されたビジョンと計画を公開できることを嬉しく思います。コードパターンを評価するための最適なルールセットは、静的コード分析と動的チェックを組み合わせる必要がある、ということに気づきました。これらのルールは、次のような複数のサーフェスに適用できます。
- ESLint
- TypeScript
- ユーザーの開発用サーバーでの動的チェック（DOM 作成後）
- モジュール バンドラ（webpack）
- CSS ツール（まだ試験運用中）
さまざまなツールを通じてルールを提供することで、ルールに一貫性を持たせることができますが、読み込みパフォーマンスに直接影響を与えるユーザー エクスペリエンスの問題も網羅できます。また、これらのルールはデベロッパーにさまざまなタイミングで提示される場合もあります。
- 開発用サーバーでのローカル開発中は、ブラウザとユーザーの IDE に警告が表示され、デベロッパーはコードを少し変更するように求められます。
- ビルド時に、未解決の問題はユーザーのターミナルに再表示されます。
簡単に言うと、チームは Core Web Vitals や読み込みパフォーマンスなど、重視する結果を選択し、すべてのコード コントリビューターが従うべき関連ルールセットを有効にします。
これは新しいプロジェクトでは非常に効果的ですが、大規模なコードベースをアップグレードして完全なルールセットに準拠するのは容易ではありません。Google には、ソースコードの個々の行、ディレクトリ全体、以前のコードベース、または積極的に開発されていないアプリの一部など、さまざまなレベルでオプトアウトするための広範なシステムがあります。Google は、オープンソース フレームワークを使用しているチームにこれを提供するための効果的な戦略を積極的に模索しています。
Next.js での適合性
ESLint は JavaScript デベロッパーの間で広く使用されています。Next.js アプリケーションの 50% 以上が、ビルド ワークフローの一部で ESLint を使用しています。Next.js v11 では、カスタム プラグインと共有可能な構成を含む、すぐに使える ESLint サポートが導入されました。これにより、開発中およびビルド時にフレームワーク固有の一般的な問題を簡単に捕捉できます。これにより、デベロッパーはオーサリング時に重大な問題を修正できます。たとえば、特定のコンポーネントがパフォーマンスを損なう可能性がある方法で使用されている（ページの HTML リンクがないを参照）場合や、使用されていない場合などがこれに該当します。または、特定のフォント、スタイルシート、スクリプトがページ上のリソースの読み込みに悪影響を及ぼす可能性がある場合に使用します。たとえば、同期スクリプトがありません。
ESLint に加えて、開発環境と本番環境の両方で統合された型チェックは、TypeScript をサポートする v9 以降の Next.js でサポートされています。フレームワークが提供する複数のコンポーネント（Image、Script、Link）は、HTML 要素（<img>、<script>、<a>）の拡張機能として作成されており、ウェブページにコンテンツを追加する際の効率が向上します。型チェックは、割り当てられたプロパティとオプションが、サポートされている値と型の許容範囲内にあることを確認することで、これらの機能を適切に使用できるようにします。例については、必要な画像の幅と高さをご覧ください。
トーストとオーバーレイによるエラーの表示
前述のように、適合性ルールは複数の領域に現れます。ユーザーのローカル開発環境内のブラウザで直接エラーを表示する方法として、トーストとオーバーレイが現在検討されています。
デベロッパーが使用する多くのエラーチェック ツールと監査ツール（Lighthouse、Chrome DevTools の [Issues] タブ）は受動的であり、情報を取得するにはなんらかのユーザー操作が必要です。デベロッパーが既存のツール内で直接エラーを発見した場合や、問題を解決するために実施すべき具体的かつ具体的なアクションを提示した場合、デベロッパーは対処する可能性が高くなります。
他のフレームワークの適合性
他のフレームワーク（Nuxt、Angular など）への拡張を目的として、まず Next.js で適合性を調査しています。ESLint と TypeScript は、すでに多くのフレームワークでさまざまな方法で使用されていますが、包括的なブラウザレベルのランタイム システムのコンセプトが積極的に検討されています。
おわりに
適合性は、ベスト プラクティスを単純なコードパターンとして体系化し、デベロッパーが実行可能なルールセットにしています。Aurora チームは読み込みパフォーマンスに重点を置いてきましたが、ユーザー補助やセキュリティなど、他のベスト プラクティスも同様に適用できます。
適合性ルールに従うと結果は予測可能なものとなり、ユーザー エクスペリエンスの基準を高くすると、技術スタック上に構築することの副作用になる可能性があります。適合性はチームの生産性を高め、時間の経過とともにチームとコードベースが拡大しても、アプリケーションの高品質な基準を確保します。