5.6 フロントエンドエンジニアリング

概要と動機

フロントエンドエンジニアリングとは、ソフトウェアのクライアント側の層を築く規律です。ブラウザやデバイスで動き、デザイン、コンテンツ、データを動くインターフェースに変えるコード。フレームワークとアーキテクチャの選択、レンダリングの戦略、状態管理、パフォーマンス、そして現実世界の途方もなく多様なブラウザ、デバイス、ネットワーク条件にわたるレジリエンスに及びます。フロントエンドは、上流のすべての仕事(UX、デザイン、コンテンツ、アクセシビリティ、国際化)がユーザーにうまく届くか、崩れ去るかが決まる場所です。

大きなチームにとって、フロントエンドは独特に難しい。組織が制御しない環境にさらされているからです。ユーザーのブラウザ、デバイス、接続、設定は大きく異なり、プラットフォーム(ウェブ)は絶えず進化しています。規模では、アーキテクチャの選択が複合します。今日選ばれたフレームワークは、採用、パフォーマンス、保守性を何年も制約し、バンドルサイズとレンダリングについての何千もの小さな決定が、ユーザーが実際に得る体験に積み上がります。共有の標準、コンポーネントライブラリ、パフォーマンスの予算、アーキテクチャのパターンが、多くの独立したチームが、遅く、一貫せず、脆い全体を作るのを防ぎます。

企業と政府にとっての関連性は切実です。企業は長寿命のアプリケーションを保守し、新奇さよりフレームワークの寿命と保守性が重要で、多くのチームが相互運用しなければなりません。政府は、古いデバイス、遅いあるいは従量制の接続、支援技術を使う人々を含む、公衆全体に仕えます。それは、パフォーマンス、プログレッシブエンハンスメント、レジリエンスを、任意の磨き上げではなく、全員に機能するサービスと、最も恵まれない人々を排除するサービスの違いにします。最新のスマートフォンと速い接続でしか機能しない政府のサービスは、使命に失敗しています。

主要原則

フロントエンドは制御できない環境で動きます。変動と失敗に備えて設計します。
長寿命のシステムには、退屈で持続する技術を選びます。保守性と採用のために最適化します。
パフォーマンスは機能であり、多くのユーザーにとって、アクセスの前提条件です。
プログレッシブエンハンスメント。まず動く中核の体験を届け、それから拡張を重ねます。
送るコードを減らします。最も速く最も信頼できるコードは、出荷しないコードです。
レンダリングの戦略を、流行ではなく、コンテンツの種類とユーザーのニーズに合わせます。
レジリエンス。物事が間違ったとき、インターフェースは壊れるのではなく、穏やかに劣化するべきです。
標準とプラットフォームの機能はフレームワークより長生きします。プラットフォームに頼ります。

推奨事項

流行ではなく、寿命と適合でフレームワークを選ぶ

流行っているものではなく、問題、チーム、保守の期間、採用市場に基づいて、フロントエンドの技術を選びます。長寿命の企業と政府のシステムでは、大きな人材プール、安定したリリースの実践、明確なアップグレードの経路を持つ、成熟してよくサポートされた技術を好みます。フレームワークの変動の総コストを量ってください。書き直しは高価でリスクが高い。フレームワークの入れ替わりを生き延びる投資になるよう、ウェブ標準に頼るアプローチを好み、アプリケーションが一つのライブラリのライフサイクルの人質にならないよう、フレームワーク固有のコードを境界の背後に隔離します。

レンダリングの戦略をニーズに合わせる

主なレンダリングの戦略は、それぞれ異なるコンテンツに合います。サーバーサイドレンダリング(SSR)は、速い最初の描画と良いSEO(検索エンジン最適化)を生み、クライアントのJavaScriptなしに機能し、コンテンツの多い公開ページに合います。静的サイト生成(SSG)は、ビルド時に事前に描画して最大の速度とキャッシュ性を得て、あまり変わらないコンテンツに理想的です。クライアントサイドレンダリング(CSR)は、認証の背後の、高度に対話的でアプリのような体験に合います。ストリーミングと漸進的なハイドレーションは、ページを段階的に送り有効化し、ユーザーが早くコンテンツを見て使えるようにします。多くの大きなシステムは、グローバルに一つを選ぶのではなく、ルートごとにこれらを混ぜます。状態を意図して管理します。サーバーの状態、URLの状態、ローカルなUIの状態を区別し、すべてを一つの重いグローバルストアに過度に集中させるのを避けます。

パフォーマンスを予算化され測定される規律として扱う

パフォーマンス予算(バンドルサイズ、リクエスト数、主要な指標への明示的な上限)を採用し、CIで徹底して、回帰がビルドを失敗させるようにします。速いマシンでのラボテストだけでなく、実際のデバイスとネットワークからのリアルユーザーモニタリングで、Core Web Vitals(読み込み、対話性、視覚的な安定性)を追跡します。JavaScriptを積極的に減らします。コード分割と遅延読み込みで、ユーザーがあるビューに必要なものだけをダウンロードするようにし、重要でない作業を先送りし、重いライブラリよりプラットフォームの機能を好みます。画像とフォントを最適化し、効果的にキャッシュし、代表的な低価格のデバイスと遅い接続で測定します。

プログレッシブエンハンスメントとレジリエンスで築く

セマンティックHTMLとJavaScriptが最小限あるいはなしで動く基準線から始め、それから有能なクライアント向けに拡張します。これにより、スクリプトの読み込みが失敗したり、デバイスが古かったり、ネットワークが不安定だったりしても、中核のタスクが可能であり続けます。それはエッジケースではなく、よくある現実です。エラーを穏やかに扱います。空白の画面や無限のスピナーではなく、読み込み、空、エラー、オフラインの状態に役立つ表示を出します。人々が頼るサービスには、断続的な接続でもアプリが使い続けられ、接続が戻ったときに同期するよう、オフラインファーストの技法を検討します。

ブラウザ、デバイス、支援技術をまたぐ互換性を確保する

チーム自身のマシンではなく、実際の分析に基づき、ユーザーが実際に持つブラウザ、デバイス、支援技術にわたってテストします。最新のプラットフォームの機能があらゆる所で利用できると想定せず、プログレッシブエンハンスメントと機能検出を使います。一つのコードベースがスマートフォンからデスクトップまで仕えるよう、レスポンシブに築きます(デザインシステムの章を参照)。アクセシビリティと国際化を、後のパスとしてではなく、最初からフロントエンドのアーキテクチャに統合します。

フロントエンドを共有のインフラストラクチャとして統治する

チームが一貫して生産的であるよう、共有のコンポーネントライブラリ、リンター、フォーマッター、ビルドのツールを提供します。アーキテクチャのガイドライン(アプリケーションの構造化、状態の管理、バンドルの分割)と、CIで徹底されるパフォーマンス予算を確立します。非常に大きなフロントエンドでは、チームが独立してデプロイできるモジュール型あるいはマイクロフロントエンドのアーキテクチャを検討しますが、追加の複雑さとパフォーマンスのコストは無料ではないので、慎重に量ってください。

トレードオフ: 長所と短所

決定	長所	短所
人気のある成熟したフレームワーク	大きな人材プール、安定、サポートあり	レガシーの重みを抱えうる。最新の機能の採用が遅い
最新のフレームワーク	現代的な機能、パフォーマンスの利得	変動のリスク、小さな人材プール、不確かな寿命
SSR / SSG	速い最初の描画、SEO、JSなしで機能	サーバーあるいはビルドの複雑さ、キャッシュの課題
CSR(SPA)	豊かな対話性、アプリのような感触	遅い初回の読み込み、JS依存、SEOとレジリエンスのコスト
重いクライアントのJavaScript	豊かな機能	低価格のデバイスでの貧しいパフォーマンス、脆い
プログレッシブエンハンスメント	レジリエントでインクルーシブ、どこでも機能する	動く基準線を定義するデザインの労力が増える
マイクロフロントエンド	チームの独立したデプロイ、スケール	複雑さ、重複した依存関係、パフォーマンスのオーバーヘッド

繰り返されるトレードオフは、豊かさと開発者の利便性対、到達範囲、パフォーマンス、レジリエンスです。重いクライアントサイドのアプローチは、速いマシンで築いてデモするのは楽しいですが、弱いデバイスとネットワークのユーザーを排除します。企業、特に政府の読者には、パフォーマンス、プログレッシブエンハンスメント、持続性に天秤を傾けてください。ユーザーを排除するコストは高く、しばしば交渉の余地がないからです。

チームで議論すべき問い

アプリケーションが一つのライブラリのライフサイクルの人質にならないよう、フレームワーク固有のコードをどう隔離しますか。 長寿命の企業と政府のシステムでは、フレームワークの変動が避けられる最大の費用です。書き直しは高価でリスクが高く、今日流行しているライブラリは、採用と保守を何年も制約します。ウェブ標準に頼り、フレームワーク固有のコードを明確な境界の背後に置けば、ビジネスロジックとコンテンツは、次のフレームワークの入れ替わりを生き延びます。その継ぎ目がどこにあり、新しいエンジニアがプラットフォームのコードとフレームワークのコードを見分けられるかを決めてください。前回のフレームワーク移行のコスト、あるいは迫っている移行のコストの見積もりを持ち込んでください。中核のロジックが一つのライブラリのAPIに溶接されているなら、フレームワークの選択を擁護する前に、その結合を値付けしてください。
レンダリングの戦略をルートごとに合わせていますか。それとも、プロダクト全体に一つの戦略を強いていますか。 サーバーサイドレンダリングは、公開コンテンツに速い最初の描画を与え、クライアントのJavaScriptなしに機能し、静的生成は、あまり変わらないページの速度を最大化し、クライアントレンダリングは、ログインの背後の対話的でアプリのような面に合います。グローバルに一つを強いると、公開ページを重いJavaScriptで遅くするか、単純なコンテンツページを過剰に設計するかのどちらかです。これは政府にとって到達範囲の問題です。大きなバンドルが読み込まれた後でしか機能しないサービスは、古いデバイスや遅い接続のユーザーを排除するからです。主要なルートを持ち込み、それぞれに今日実際に使っている戦略のラベルを付けてください。公開されたページが内容を表示するのにJavaScriptを必要とするなら、それが意図した選択なのか、偶然なのかを決めてください。
状態管理はどれだけ規律があり、すべてを一つの重いグローバルストアに過度に集中させていませんか。 サーバーの状態、URLの状態、ローカルなUIの状態を区別しておくことは、大きなフロントエンドを遅く脆くする、結合と再描画の嵐を防ぎますが、誘惑的な既定は、すべてを一つのグローバルストアに投げ込むことです。これは規模で複合します。多くのチームが一つの共有ストアに触れると、隠れた依存関係と予測不能なパフォーマンスを生むからです。各種類の状態がどこに属し、何がグローバルストアに属さないかに合意してください。本来より多く再描画するコンポーネントを持ち込み、なぜかをたどってください。答えが肥大した中央のストアなら、結合が固まる前に境界を決めてください。
パフォーマンス予算は何で、CIでビルドを失敗させるもので、ユーザーが実際に持つデバイスで測定されていますか。 誰も徹底しない予算は願いで、チームの速いノートパソコンだけで測定された予算は、存在しないユーザーを描写しています。大きな組織では、予算は、数十のチームが共有の面に機能を加えるにつれて、バンドルサイズとCore Web Vitalsを抑える唯一の仕組みです。どの単一のレビュアーも、あらゆる回帰を目で捉えられないからです。相反する圧力はデリバリーの速度です。数キロバイトでの固いビルドの失敗は、それが防ぐ離脱を値付けするまで、妨害的に感じられます。現在の予算、低価格のデバイスと遅い接続からのリアルユーザーモニタリングのデータ、回帰がすり抜けたリリースの一覧を持ち込んでください。古いスマートフォンと従量制のデータの人々を含む公衆全体に仕えることが使命の政府では、予算を中央値ではなく最も遅い10パーセントのユーザーに結びつけ、CIのゲートを交渉の余地のないものにしてください。
どのサービスがクライアントのJavaScriptなしで動き続けなければならず、その経路を実際にテストしましたか。 プログレッシブエンハンスメントは、主張するのは易しく、静かに壊すのも易しい。拡張された経路は開発者が毎日使うもので、基準線はテストされずに腐るからです。これを意図して決めることは、規模で重要です。一つのプラットフォームに出荷する多くのチームが、共有の標準が別のことを言わない限り、スクリプトが常に読み込まれると想定し、一つの強い依存関係が、バンドルが失敗する人にとって中核のタスクを壊しうるからです。トレードオフは本物です。動くJavaScriptなしの基準線は、デザインの労力がかかり、対話性の築き方を制約します。重要なユーザージャーニー、それぞれをスクリプトを無効あるいは失敗させて読み込むテスト、現場でスクリプトの読み込みが実際にどれだけ頻繁に失敗するかの証拠を持ち込んでください。公共サービスでは、一つのスクリプトがタイムアウトすると崩れる給付や税のフォームは、劣化した体験ではなく、法的義務を完了できない市民なので、基準線を、あれば良いものではなく、コンプライアンスの要件として扱ってください。
マイクロフロントエンドはいつ本当にその複雑さに見合い、チームが手を伸ばす前に、誰が決めますか。 チームの独立したデプロイは魅力的ですが、マイクロフロントエンドは、分散システムの複雑さ、重複した依存関係、ユーザーが読み込みの遅さで払うパフォーマンスの税を伴います。共有の決定点がなければ、野心的なチームは、規模がコストを正当化するずっと前に、組織上の都合で採用し、プロダクト全体がそのオーバーヘッドを引き継ぎます。相反する考慮は自律です。一つの共有のコードベースに出荷するチームは互いをブロックしえ、本当の規模では、その結合がそれ自体の高価な問題です。その面に触れるチームの数、今日実際に経験しているデプロイの競合、分割が導入するペイロードの重複の測定された見積もりを持ち込んでください。アーキテクチャの決定が多くのチームを何年も拘束し、監査と引き継ぎを生き延びなければならない企業と政府のプラットフォームでは、各チームが孤立して決めるのではなく、明示的で文書化された閾値と、その移行を承認する所有者を要求してください。

セクター別の視点

スタートアップ。 すべてのサインアップが重要なとき、速度と到達範囲の両方が重要なので、公開ページに重いシングルページアプリを使うのは控えてください。マーケティングとサインアップのフローをサーバーでレンダリングし、初期の顧客が使う中価格帯のスマートフォンとまだらなデータでも速く読み込まれるようにし、クライアントサイドの対話性は、ログインの背後のアプリのために取っておきます。不注意な依存関係が静かにページを肥大させないよう、CIに単純なバンドルサイズの予算を一つ設定し、採用が増えても小さなコードベースを保守できるよう、ウェブ標準に頼ってください。

小規模事業者。 フロントエンドの専門家がおらず予算も厳しいので、オーダーメイドのものより、よくサポートされた主流のフレームワークやホスト型のサイトビルダーを好み、大きな人材プールから採用し、保守を人員配置するのではなく買えるようにします。選択を持続性として枠づけてください。最も安い選択肢は、二年後に書き直しを強いられないものです。速くモバイルに優しいページとアクセシブルなマークアップを最初から求めてください。遅い、あるいは壊れたチェックアウトは、失う余裕のない顧客を失わせるからです。

大企業。 問題は多くのチームにわたる一貫性です。共有のコンポーネントライブラリ、合意されたアーキテクチャのパターン、リンターとビルドのツール、どのチームも全体を静かに退行させられないようCIで徹底されるパフォーマンス予算。新奇さではなく、寿命と採用のためにフレームワークを選び、次の移行を生き延びるようフレームワーク固有のコードを境界の背後に隔離し、面ごとにレンダリングの戦略を合わせます。リアルユーザーモニタリング、ガバナンス、各アーキテクチャの選択がなぜなされたかの監査可能な記録を備えた共有のインフラストラクチャとして、フロントエンドを管理します。

政府。 古いデバイス、遅いあるいは従量制の接続、支援技術を使う人々を含む公衆全体に仕えるので、プログレッシブエンハンスメントとパフォーマンスは、磨き上げではなく義務です。市民向けのサービスには、動くJavaScriptなしの基準線を固いルールにし、ページを中央値ではなく最も遅いユーザーに合わせて予算化し、スクリプトが失敗しても中核のタスクを完了可能に保ちます。調達と透明性が適用されます。単一ベンダーへのロックインを避ける、持続的で標準寄りの技術を好み、アクセシビリティとパフォーマンスの要件を契約に文書化し、デモ用のデバイスだけでなく、最も恵まれないユーザーにサービスが機能することを示せるようにしてください。

事例

スタートアップ。 シードステージのスタートアップは、マーケティングサイトとサインアップのフローを重いシングルページアプリとして築く誘惑に駆られましたが、対象の顧客は、まだらなモバイルデータの中価格帯のスマートフォンを使う買い物客でした。二人の創業者は代わりに公開ページをサーバーでレンダリングし、JavaScriptが走る前に速く読み込まれて機能するようにし、クライアントサイドの対話性はログインの背後のアプリのために取っておきました。不注意な依存関係が静かにページを肥大させないよう、CIに単純なバンドルサイズの予算を設定しました。引き締まった速い初回の読み込みは、サインアップを測定可能に改善し、ウェブ標準に頼ったことで、採用が増えても小さなコードベースを保守しやすく保てました。

大企業。 金融サービス企業は、成熟したフレームワーク、共有のコンポーネントライブラリ、CIで徹底されるパフォーマンス予算に標準化することで、広がった社内と顧客向けのアプリケーション群をモダナイズしました。レンダリングの戦略は面ごとに選ばれました。公開のマーケティングとコンテンツには、サーバーでレンダリングされるキャッシュ可能なページ、対話的なダッシュボードにはログインの背後のクライアントレンダリングのアプリケーション。バンドルの予算とリアルユーザーモニタリングが、リリース前に回帰を捉え、会社の多くのチームにわたって読み込み時間を速く保ち、以前は高価な書き直しを強いていたフレームワークの変動のリスクを減らしました。

政府。 国のデジタルサービスのチームは、プログレッシブエンハンスメントを固いルールとして、市民向けのサービスを築きました。すべてのサービスはまずセマンティックHTMLとサーバーレンダリングで機能し、JavaScriptは拡張するだけです。これにより、サービスが、古いスマートフォン、遅い地方の接続、支援技術、政府が排除できない人々の上で機能することが保証されます。パフォーマンス予算がページを軽く保ち、低価格のデバイスで速くし、穏やかな劣化により、失敗したスクリプトが誰かの給付申請の完了をブロックすることは決してありません。その結果は、速く、レジリエントで、アクセシブルで、公衆全体が使えるサービスです。

ビジネスケース: 動機、ROI、TCO

フロントエンドエンジニアリングの選択は、収益、到達範囲、コストを駆動します。パフォーマンスは、コンバージョン、エンゲージメント、タスクの完了に直接結びついています。より速い体験は測定可能に遅いものを上回り、弱いデバイスのユーザーにとって、パフォーマンスはサービスを使うか離脱するかの境目です。プログレッシブエンハンスメントとクロスデバイスのサポートは対象のオーディエンスを広げ、それは政府にとっては使命であり、企業にとっては市場シェアです。健全なフレームワークとアーキテクチャの選択は、フロントエンドエンジニアリングで避けられる最大の費用である、書き直しの頻度とコストを減らします。

TCOでは、採用のコストは、パフォーマンス予算とテストの規律、プログレッシブエンハンスメントの労力、共有ツールとコンポーネントライブラリへの投資です。採用しないコストは、ユーザーと収益を失う遅い体験、低価格のデバイスと支援技術のユーザーの排除(政府では法的な露出を伴う)、現場で壊れる脆いアプリケーション、流行を追うことに駆動される高価なフレームワークの変動と書き直しで払われます。フロントエンドの問題は、単一の項目ではなく、拡散した離脱とサポートの負荷として表面化するので、投資不足になりやすいのです。

リーダーシップに論拠を示すには、Core Web Vitalsと読み込み時間をコンバージョンと完了のファネルに結びつけ、重いクライアントサイドのアプローチが排除するユーザーを定量化し、過去あるいは迫っている書き直しのコストを、持続的で標準寄りのアーキテクチャの安定性と対比して値付けします。パフォーマンス予算とプログレッシブエンハンスメントを、リスクの低減と到達範囲の拡大として枠づけてください。

アンチパターンと落とし穴

フレームワークを追う: 最新のライブラリで書き直し、ユーザーの利益なしに変動を招くこと。
JavaScriptだけの体験: 大きなバンドルが読み込まれて実行されるまで何も機能せず、多くのユーザーを排除すること。
速いデバイスだけでのテスト: チームの最上位のノートパソコンが、本当のユーザー体験を隠すこと。
バンドルサイズの無視: ページがあらゆる所で遅くなるまで、依存関係が際限なく増えること。
パフォーマンス予算がない: リリースごとに回帰が静かに積み上がること。
空白の画面の失敗: 読み込み、空、エラー、オフラインの状態がなく、失敗したリクエストでページが壊れること。
過度に集中したグローバルな状態: すべてが一つのストアにあり、結合と再描画の嵐を生むこと。
早すぎるマイクロフロントエンド: 正当化する規模なしに、分散システムの複雑さと重複したペイロードを抱えること。
アーキテクチャでのアクセシビリティとi18nの無視: 後から高いコストで後付けすること。

成熟度モデル

レベル1: 開始。 共有の標準なしに、チームごとにその場しのぎで築かれたフロントエンド。重いクライアントサイドのコード、パフォーマンス予算なし、チーム自身のデバイスでしかテストされません。フレームワークの選択は好みや流行で行われ、失敗したスクリプトはユーザーを空白の画面の前に取り残しえます。

レベル2: 発展。 共有のツールとコンポーネントライブラリを採用するチームもありますが、実践は組織全体で一貫しません。パフォーマンスは予算化も徹底もされず、ときどき測定されます。レンダリングの戦略はコンテンツの種類にかかわらず、しばしば一様で、クロスデバイスのテストは限られて手作業です。

レベル3: 標準化。 フレームワークとアーキテクチャは寿命のために意図して選ばれ、その選択は文書化され、組織全体で徹底されています。レンダリングの戦略は面ごとに合わせられ、プログレッシブエンハンスメントと穏やかな劣化が標準で、共有のコンポーネントライブラリ、リンター、ビルドのツールがすべてのチームに適用されます。ブラウザをまたぐ互換性、アクセシビリティ、国際化は、後付けではなく組み込まれています。

レベル4: 管理。 フロントエンドが、データで測定され、制御されています。パフォーマンス予算がCIで徹底されて回帰がビルドを失敗させ、Core Web Vitalsは、明示的なベースラインに対して、実際の低価格のデバイスと遅い接続からのリアルユーザーモニタリングで追跡されます。バンドルサイズ、エラーとオフラインの状態のカバレッジ、最も遅い接続で仕えられるユーザーの割合が報告され、レビューされるので、決定は意見ではなく証拠に基づきます。

レベル5: オーケストレーション。 パフォーマンス、レジリエンス、到達範囲が、継続的に改善され、組織全体でビジネスの成果に結びついています。フロントエンドは耐久性のためにウェブ標準に頼り、移行が安くなるようフレームワークの依存関係を隔離し、デバイス、プラットフォーム、リアルユーザーのデータが変わるにつれて、アーキテクチャを適応的に進化させます。公衆全体とすべてのデバイスが第一級で、フロントエンドの実践は、別個の関心事として扱われるのではなく、デザイン、アクセシビリティ、プロダクトの計画と統合されています。

議論のためのアイデア

フレームワークの移行がそのコストとリスクに見合うかを、どう決めますか。
どのCore Web Vitalsとバンドルの予算が、ビルドを失敗させる固い閾値であるべきですか。
プログレッシブエンハンスメントが不可欠なのはどこで、クライアントサイドのアプリが許容されるのはどこですか。
多くの自律的なチームにわたって、フロントエンドのアーキテクチャをどう一貫させますか。
マイクロフロントエンドが本当にその複雑さに見合うのはいつですか。
実機と遅いネットワークのテストを、パイプラインにどう組み込むべきですか。

要点

フロントエンドは制御できない環境で動きます。変動と失敗に備えて設計します。
長寿命のシステムには、持続的でよくサポートされた技術を選び、ウェブ標準に頼ります。
レンダリングの戦略(SSR、SSG、CSR、ストリーミング)を、コンテンツとニーズに合わせ、しばしばルートごとに混ぜます。
パフォーマンスを、リアルユーザーのデータでCIで徹底される、予算化され測定される規律として扱います。
中核の体験があらゆる所で機能するよう、プログレッシブエンハンスメントで築きます。
JavaScriptを減らして出荷します。コード分割、遅延読み込みを行い、プラットフォームの機能を好みます。
特に政府にとって、パフォーマンスとレジリエンスは、公平なアクセスの前提条件です。

参考文献とさらなる読み物

Jeremy Keith, Resilient Web Design
Aaron Gustafson, Adaptive Web Design (progressive enhancement)
Steve Souders, High Performance Web Sites
Ilya Grigorik, High Performance Browser Networking
Addy Osmani, writings on performance, code-splitting, and the cost of JavaScript
Google, Web Vitals and web.dev performance guidance
MDN Web Docs, web platform and progressive enhancement references
Alex Russell, essays on the cost of JavaScript and device diversity
UK Government Digital Service, progressive enhancement and frontend guidance
WHATWG HTML Living Standard and W3C web platform specifications