Web Performance Optimization: Make Your Site Fast — cod-ai.com

3年前、私はクライアントがホームページの読み込みに8.2秒かかったために年間230万ドルの収益を失うのを目撃しました。私はサラ・チェンで、過去12年間、意欲的なスタートアップからフォーチュン500企業まで、さまざまな企業でパフォーマンスエンジニアとして働いてきました。その特定のクライアント—アウトドア用品を販売する中規模のeコマース会社—は、美しいデザイン、魅力的なコピー、広範な製品カタログに多大な投資をしていました。しかし、彼らは最も重要な指標である「スピード」を無視していました。

ようやく彼らを納得させてサイトの監査を行ったとき、ホームページにだけで47枚の最適化されていない画像があり、それぞれ平均3.2MBでした。彼らのJavaScriptバンドルは非圧縮で1.8MBもあり、サードパーティのトラッキングスクリプトがページがインタラクティブになる前に23回の個別ネットワークリクエストを行っていました。モバイルデバイスでの離脱率は68%でした。包括的なパフォーマンス最適化戦略を実施した後、読み込み時間は1.4秒に短縮され、離脱率は31%に下がり、コンバージョンは127%増加しました。これが私がウェブパフォーマンスに夢中になった瞬間です。

ほとんどの開発者が理解していないことがあります。それは、パフォーマンスは最後に追加する機能ではないということです。パフォーマンスは、あなたが下すすべての技術的決定を形作る根本的な制約です。私は、迅速なウェブサイトを構築するために使用する正確な戦略、ツール、およびメンタルモデルを共有します—3G接続でも2秒未満で読み込むウェブサイト、訪問者を顧客に変えるウェブサイト、Googleのアルゴリズムがスピードを評価するため検索結果で高くランキングするウェブサイトのことです。

パフォーマンスが実際に重要な理由（明白なことを超えて）

誰もが遅いサイトは良くないことを知っています。しかし、あなたを夜も眠れぬ状態にすべき数字を示しましょう。過去5年間に340以上のクライアントプロジェクトから収集したデータによれば、ページロード時間が100ms遅れるごとにコンバージョン率が0.7%低下することがわかっています。年間収益が1000万ドルのサイトでは、100msごとに70000ドルを失っています。2秒ではなく5秒で読み込まれるサイトは、約210万ドルを失っています。

しかし、影響は収益を超えて深いです。Googleのコアウェブバイタルは今やランキング要因です。これらの指標を満たさないサイト—Largest Contentful Paint (LCP)、First Input Delay (FID)、Cumulative Layout Shift (CLS)—は、検索結果で体系的に優先度を下げられています。私は、サイトのパフォーマンスが大幅に低下した後、オーガニックトラフィックが35-40%減少するのを見たことがあります。

人間のコストもあります。遅い接続を使用しているユーザー—多くの場合、発展途上国や地方の地域に住んでいます—は、膨れ上がったウェブサイトによって不釣り合いに影響を受けます。あなたのサイトが単純な製品ページを表示するために5MBのJavaScriptを必要とする場合、あなたは実際には数百万人の潜在的な顧客を排除しているのです。私は、国際的な拡大に失敗したクライアントと一緒に働いたことがあり、主に彼らのサイトがターゲット市場で一般的な2Gおよび3G接続では使用できなかったためです。

パフォーマンスは尊重に関することでもあります。あなたが送信するすべての不要なキロバイトは、ユーザーの生活から盗まれた時間です。それは彼らの電話のバッテリーが drained されることです。それは彼らの制限されたプランから消費されるデータです。私がサイトを最適化する時、私は単に指標を改善しているのではなく、訪問することを選んだ人々への尊重を示しているのです。

パフォーマンスの測定：実際に重要な指標

何かを最適化する前に、それを正しく測定する必要があります。多くの開発者は間違った指標に執着しています。ページの総読み込み時間はほとんど意味がありません—重要なのは、ユーザーが実際にあなたのコンテンツとインタラクトできる時です。私がすべてのプロジェクトで厳格に追跡している指標はこちらです。

"パフォーマンスは最後に追加する機能ではありません。 それはあなたが下すすべての技術的決定を形作る根本的な制約です。"

Largest Contentful Paint (LCP)は、最大のコンテンツ要素が表示される時点を測定します。Googleは2.5秒未満を推奨しています。私の経験では、LCPが1.8秒未満のサイトは、はるかに良好なエンゲージメントを示します。英雄画像、ビデオ埋め込み、大きなテキストブロックが通常LCP要素です。これらの最適化を最優先すべきです。

First Input Delay (FID)は、ユーザーがあなたのページと初めてインタラクトしてから、ブラウザが実際に応答できるまでの時間を測定します。Googleはこれを100ms未満に望んでいます。私は50ms未満を目指しています。長時間実行されるJavaScriptがほとんどの元凶です。もしあなたのメインスレッドが巨大なバンドルの解析と実行でブロックされている場合、ユーザーはクリックやスクロールしようとしたときにその苛立たしい遅延を経験します。

Cumulative Layout Shift (CLS)は、視覚的安定性を測定します。ボタンをクリックしようとしたら、広告が読み込まれてすべてが下に移動し、間違ったものをクリックしてしまったことがありますか？それがレイアウトシフトであり、非常に苛立たしいです。Googleはスコアを0.1未満に望んでいます。私はCLSスコアが0.5を超えるサイトを見たことがあります—それは閾値の5倍悪いです。修正は通常、画像や広告に明示的な寸法を設定し、既存のコンテンツの上に新しいコンテンツを挿入するのを避けることを含みます。

コアウェブバイタルを超えて、私はTime to First Byte (TTFB)を追跡しています。これは600ms未満であるべきです。これはサーバー応答時間を測定し、しばしば見過ごされます。私はまたTotal Blocking Time (TBT)を監視しています。これはメインスレッドがブロックされている時間を定量化します。モバイルデバイスの場合、私は200ms未満のTBTを目指しています。

実際のユーザーモニタリング（RUM）ツールを使用して、実際のユーザーが経験することを確認してください。SpeedCurveやCloudflareの分析を使うと良いです。Lighthouseからのラボデータは開発に有用ですが、実世界の多様な条件—遅いネットワーク、性能の悪いデバイス、ブラウザー拡張、プロダクションでのパフォーマンスに影響を与えるすべてのもの—を捉えられません。

画像最適化：取り組みやすい部分

画像は通常、ページの総重量の50-70%を占めます。私は画像がペイロードの92%を占めるサイトの監査を行ったことがあります。ここは劇的な改善を行う最も簡単な場所ですが、一貫して無視されています。私の画像最適化ワークフローを紹介します。

まず、正しいフォーマットを選びます。写真には、JPEGフォールバック付きのWebPを使用します。WebPは同等の品質でJPEGよりも25-35%優れた圧縮を提供します。透過性のある画像には、WebPまたはPNGを使用します。シンプルなグラフィックやロゴには、SVGが通常最適です—解像度に依存せず、ラスタフォーマットよりも小さいことが多いです。私は45KBのPNGロゴを3KBのSVGに置き換えたことが何度もあります。

次に、積極的に圧縮します。ほとんどの画像は、ほとんど感知できない損失で60-80%の品質に圧縮できます。私はSquooshやImageOptimのようなツールを使用して、各画像に最適な圧縮レベルを見つけています。100%の品質で3.2MBだった英雄画像は、75%の品質で180KBになるかもしれません—これは視覚的な違いが最小限で94%の削減です。

3番目に、srcsetおよびsizes属性を使用してレスポンシブ画像を実装します。375pxのスクリーンを持つモバイルデバイスに2400pxの幅の画像を送信しないでください。私は通常、各画像の4-5サイズを生成します：400px、800px、1200px、1600px、2400px。ブラウザはデバイスの画面幅とピクセル密度に基づいて適切なサイズを自動的に選択します。

4番目に、フォールドの下にある画像を遅延読み込みします。ユーザーが決して見ないかもしれない画像を読み込む理由はありません。私は優れたブラウザサポートを持つネイティブなloading="lazy"属性を使用します。フォールドの上の画像については、loading="eager"を使用するか、属性を完全に省略します。画像が多いサイトでは、遅延読み込みによって初期ページの重量が60-70%減少するのを見てきました。