私のサイトは0.3秒でロードされます(使用したすべての速度最適化)
Google PageSpeed Insightsで完璧な100スコア。0.3秒のロード時間。このブログをとてつもなく速くするために実装したすべての最適化を紹介します。
私はページ速度にちょっと執着しています。
「レンダリング時間から0.02秒削れよう」というような意味ではありません。むしろ「即座であるべきなのに、なぜこれが3秒もロードにかかっているのか」という意味です。
高速なサイトは感じが良い。コンバージョンが良い。ランキングが良い。ただ良いのです。
だから、このブログを構築したとき、私はパフォーマンスに全力を注ぎました。そして結果はかなり良いです。
このサイトは0.3秒でロードされます。Google PageSpeed Insightsですべてのメトリクスで完璧な100スコアを記録します。自分で確認できます。apatero.comにアクセスして、PageSpeed Insightsで実行してください。
それを正確にどのように行ったかをお見せしましょう。
なぜ速度が重要か(簡潔版)
技術的なことに入る前に、なぜこれが重要かについて話しましょう。
Googleによると、モバイルユーザーの53パーセントは、ロードに3秒以上かかるサイトを放棄します。
それは、コンテンツを見る前に訪問者の半分以上が消えることです。
Core Web Vitalsはランキング要因です。他のすべてが等しい場合、遅いサイトは速いサイトよりも悪くランク付けされます。
高速なサイトはコンバージョンが良い。Amazonは、100msのレイテンシごとに売上の1パーセントを失うことを発見しました。それは本当のお金です。
そして正直なところ、高速なサイトは使用感が良いだけです。何かをクリックして即座に反応するとき、それは良い体験です。クリックして待って、機能しているかどうか疑問に思うとき、それはイライラします。
だから、はい、速度は重要です。
基盤:適切なフレームワークの選択
ここから始まります。
私はこのブログをAstroで構築しました。その決定だけで、WordPressと比較しておそらく40〜60パーセント優れたパフォーマンスを買いました。
AstroはデフォルトでゼロのJavaScriptを出荷します。すべてはビルド時にHTMLにレンダリングされます。クライアント側のハイドレーションなし。大規模なフレームワークバンドルなし。ただ高速な静的HTMLです。
このサイトの全体のバンドルサイズは約184KBです。それがすべてです。フレームワーク、コンポーネント、スタイリング、すべてです。
適切なテーマといくつかのプラグインを備えた典型的なWordPressサイト?簡単に1MBを超えます。時には複数のメガバイトです。
遅い基盤から最適化して抜け出すことはできません。高速なフレームワークで始めるか、上り坂の戦いをしています。
WordPressや他の重いプラットフォームに固定されている場合でも、パフォーマンスを改善できます。しかし、基盤を変更せずにこれらの数字に到達することは決してありません。
画像最適化:最大の勝利
画像は通常、どのサイトでも最大のパフォーマンスボトルネックです。
私はAVIFとWebP形式のサポートを実装しました。これらの最新の画像形式は、同じ視覚品質でJPEGより20〜50パーセント小さいです。
それは小さな違いではありません。それは、即座にロードされるページと人々を待たせるページの違いです。
今、私がすることは次のとおりです。
それをサポートするブラウザにAVIFを提供する(ほとんどの最新のブラウザがサポートします)。
AVIFをサポートしていないがWebPをサポートするブラウザにはWebPにフォールバックする。
古いブラウザにはJPEGにフォールバックする。
ブラウザは、処理できる最良の形式を自動的に選択します。ユーザーは常に機能する最小のファイルを取得します。
また、モバイルファーストのレスポンシブ画像も実装しました。ほとんどのトラフィックは電話から来ますよね?では、なぜモバイルユーザーにデスクトップサイズの画像を提供するのでしょうか?
今、テンプレートはデバイスに基づいて適切にサイズ設定された画像を自動的に提供します。320pxの幅の電話は320pxの幅の画像を取得します。1920pxのデスクトップは1920pxの画像を取得します。
これだけで、モバイルデバイスの画像帯域幅がおそらく60〜70パーセント削減されました。
Preconnect:サードパーティリソースの高速化
ブラウザが別のドメインから何かをロードする必要がある場合、オーバーヘッドがあります。
サーバーを見つけるためにDNSルックアップを実行する必要があります。次にTCP接続を確立します。次にHTTPSのTLSハンドシェイクを実行します。
そのすべてには時間がかかります。通常200〜400ミリ秒。
Preconnectは、そのすべての作業を事前に実行することでこれを解決します。
サイトが使用する任意のサードパーティリソースにpreconnectヒントを追加しました。Google Analytics、Google Fonts、何でも。
ブラウザが実際にこれらのリソースを必要とする時までに、接続はすでに確立されています。接続ダンスを待つ代わりに、リソースはすぐにロードされます。
これは小さな最適化ですが、積み重なります。すべてのミリ秒が重要です。
Speculation Rules API:即座のページナビゲーション
これは私のお気に入りの最適化の一つです。
Chrome 121以降はSpeculation Rules APIをサポートしています。ブラウザがクリックする前にページをプリフェッチできるようにします。
ブラウザはナビゲートする可能性が高い場所を予測し、バックグラウンドでそれらのページをロードします。実際にクリックすると、ページは即座に表示されます。魔法のように感じます。
私はこれをブログに実装しました。投稿を読んでいるとき、Chromeはすでに訪問する可能性のある次のページをロードしています。リンクをクリックするとそこにあります。ロードなし。待機なし。
これは最初のページロードには役立ちませんが、ブラウジング体験全体が劇的に速く感じられるようにします。
ページからページへの移動が即座に感じられます。それはユーザーが実際に気づくパフォーマンス向上の種類です。
LoAF API:実際のユーザーエクスペリエンスの監視
ここにほとんどの人がスキップするものがあります。実際にユーザーが経験することを監視すること。
私はLoAF API監視を追加しました。それはLong Animation Framesです。ページが作業をしすぎてぎこちないアニメーションや遅延したインタラクションを引き起こしているときを追跡します。
このデータはGoogle Analytics 4に送られるので、ユーザーがいつどこで速度低下を経験するかを正確に見ることができます。
ほとんどのパフォーマンス最適化は合成テストで行われます。Lighthouseを実行し、スコアを取得し、それに基づいて最適化します。
しかし、それは実際のユーザーエクスペリエンスではありません。実際のユーザーは遅いデバイス、貧弱な接続、多くのブラウザ拡張機能などを持っています。
LoAFは実際のユーザーに実際に何が起こっているかを教えてくれます。高いLoAF値が表示される場合、修正する必要がある問題があることがわかります。
これは、良いスコアを一度達成して完了と呼ぶことではなく、継続的な監視についてです。
クリティカルCSSと非同期ロード
CSSはレンダリングをブロックします。ブラウザは何かを表示する前に、すべてのCSSをダウンロードして解析する必要があります。
私はクリティカルCSSをインライン化します。上部のコンテンツをレンダリングするために必要な絶対最小限のスタイルがHTMLに直接入ります。その他すべては非同期にロードされます。
ユーザーはすぐにコンテンツを見ます。すべてのスタイリングがロードされる前にページは機能します。
JavaScriptも同じアプローチです。最初のレンダリングに重要でないJSは延期されるか、非同期にロードされます。
目標は、できるだけ早く画面に有用なものを表示することです。洗練は後で来ることができます。
静的サイト生成
このブログ全体はビルド時にプリレンダリングされます。
ページにアクセスすると、サーバー側のレンダリングはありません。データベースクエリなし。動的生成なし。
CDNから直接提供される静的HTMLだけです。
これは本質的に高速です。ページをリクエストするときに計算は発生していません。ただファイルを、あなたの近くのサーバーから提供しているだけです。
サイト全体のビルド時間は約8.5秒です。それは受け入れられます。特に、すべてのリクエストではなく、デプロイするときにのみ発生するためです。
静的生成はすべてに適しているわけではありません。リアルタイムデータやユーザー固有のコンテンツが必要な場合は、動的レンダリングが必要です。
しかし、ブログには?すべてのリクエストで変更されないコンテンツには?静的が進むべき道です。
CDNとエッジホスティング
ホストする場所は、構築方法とほぼ同じくらい重要です。
私はエッジホスティングを使用します。静的ファイルは世界中のサーバーに配布されます。訪問すると、最も近いサーバーからロードしています。
東京にいる場合、東京からロードしています。ロンドンにいる場合、ロンドンからロードしています。
これによりレイテンシが劇的に減少します。すべてのリクエストがどこかの単一のサーバーに行く代わりに、リクエストは最も近いエッジの場所に行きます。
グローバルな視聴者にとって、これは巨大です。米国でホストされ、アジアのユーザーに提供されるサイトは、アジアから提供されるサイトよりも常に遅くなります。
エッジホスティングはこれを修正します。どこにいても、誰もが高速なロード時間を得ます。
不必要なJavaScriptなし
ここに簡単なものがあります。何かにJavaScriptが必要ない場合、JavaScriptを使用しないでください。
非常に多くのサイトが、静的コンテンツを表示するためだけに何百キロバイトのJSを出荷しています。CSSであり得るアニメーション。HTMLであり得るインタラクション。
ほとんどのページにはほとんどゼロのJavaScriptを出荷します。ブログ投稿はHTMLとCSSだけです。Reactなし。Vueなし。フレームワークオーバーヘッドなし。
ページにインタラクティビティが必要な場合、そのコンポーネントにのみ追加します。残りは静的のままです。
これがAstroのアイランドアーキテクチャであり、コンテンツサイトには素晴らしいです。コンテンツの95パーセントは静的です。インタラクティブなビットのみがJavaScriptを取得します。
ほとんどのブログにはJSが全く必要ありません。ただ高速なHTMLとCSSです。
レイジーローディングとプログレッシブエンハンスメント
すべてがすぐにロードする必要はありません。
折り目の下の画像?レイジーロードされます。それらの近くにスクロールするとロードされます。
YouTubeビデオのようなサードパーティの埋め込み?実際に視聴したくなるまで、プレースホルダーでレイジーロードされます。
コメントセクション?インタラクションでロードされます。
最初のページロードは、実際に読んでいるコンテンツだけです。その他すべては必要になるまで待ちます。
これにより、必要なときに完全な機能を提供しながら、最初のロード時間を最小限に抑えます。
フォント最適化
Webフォントは別の一般的なパフォーマンスボトルネックです。
私はfont-display: swapを使用して、テキストがシステムフォントですぐに表示され、ロードされるとWebフォントに切り替わるようにします。
ユーザーはフォントを待つ代わりに即座にテキストを見ます。フォントが速くロードされる場合、スワップにほとんど気づきません。ロードが遅い場合でも、読み取り可能なコンテンツを取得します。
また、折り目の上で使用される重要なフォントをプリロードします。これらはより高い優先度でロードされるため、スワップがより速く発生します。
そして、実際に使用するフォントの太さだけをロードします。regularとboldしか使用しないのに、regular、medium、semi-bold、bold、extra-boldをロードすることはありません。
すべてのフォントの太さはダウンロードする別のファイルです。必要なものだけをロードします。
HTTP/2と最新のプロトコル
これはホスティング設定に関するものですが、重要です。
HTTP/2は多重化を許可します。複数のファイルを単一の接続で同時に転送できます。
HTTP/1.1では、ブラウザは一度にいくつかのファイルしかロードできませんでした。HTTP/2では、すべてが並行してロードされます。
また、圧縮が有効になっていることを確認します。最低でもGzip、可能であればBrotli。テキストアセットは転送前に圧縮されます。
HTML、CSS、JavaScriptは本当によく圧縮されます。多くの場合、ファイルサイズが70〜80パーセント削減されます。
これは通常、ホストによって処理されますが、実際に機能していることを確認してください。WebPageTestのようなツールを使用して、アセットが圧縮されているかどうかを確認します。
レンダリングブロックリソースの排除
<head>でロードされるすべての外部スタイルシートまたはスクリプトはレンダリングをブロックします。
これらのロードが完了するまで、ブラウザは何も表示できません。
レンダリングブロックリソースを最小限に抑えます。クリティカルCSSはインライン化されます。スクリプトは延期されるか、下部に移動されます。フォントはプリロードされます。
目標は、ブラウザができるだけ早くレンダリングを開始できるようにすることです。
レンダリングをブロックするすべてのリソースは、First Contentful PaintとLargest Contentful Paint時間に追加されます。
これらはCore Web Vitalsメトリクスです。SEOランキングに直接影響します。
速いほうが良い。そしてそれはブロッカーを排除することを意味します。
結果
では、これらすべてが何を得るのでしょうか?
このサイトは0.3秒でロードされます。接続と場所によってはさらに速いこともあります。
Google PageSpeed Insightsは、すべてのメトリクスで完璧な100スコアを示します。パフォーマンス、アクセシビリティ、ベストプラクティス、SEO。すべて100です。
これを自分で確認できます。apatero.comにアクセスして、PageSpeed Insightsで実行してください。スコアは公開されています。
Core Web Vitalsはすべて緑色です。Largest Contentful Paintは1秒未満。First Input Delayは10ミリ秒未満。Cumulative Layout Shiftは0.1未満。
これらは単なる虚栄心のメトリクスではありません。実際のユーザーエクスペリエンスとSEOパフォーマンスと相関しています。
高速なサイトはより良くランク付けされます。高速なサイトはより良くコンバージョンします。高速なサイトはより良く感じます。
実際に針を動かしたもの
すべての最適化が等しいわけではありません。いくつかは大きな影響を与えます。いくつかは限界的です。
私にとって最大の違いを生んだものは次のとおりです。
**Astroの選択。**これが勝利の50パーセントです。高速な基盤で始めることは、個々の最適化よりも重要です。
**画像最適化。**AVIF/WebP形式とレスポンシブ画像は、おそらく画像が多いページで1〜2秒を節約しました。
**静的生成。**サーバー側のレンダリングがないことは、処理遅延がないことを意味します。即座の応答。
**エッジホスティング。**近くの場所からの提供により、グローバルにレイテンシが100〜200ミリ秒削減されました。
**最小限のJavaScript。**不必要なコードを出荷しないことは無料のパフォーマンスです。
その他すべては洗練です。Preconnect、レイジーローディング、フォント最適化。それらはすべて役立ちますが、大きな勝利は基本から来ます。
最初に基盤を正しく取得します。次に詳細を最適化します。
あなたもこれができます
ここに問題があります。これのどれも魔法ではありません。これのどれも深い技術的専門知識を必要としません。
このAstroテンプレートを使用している場合、これらの最適化のほとんどはすでに組み込まれています。テンプレートを使用するだけで無料で取得できます。
別のプラットフォームにいる場合でも、これらの多くを実装できます。画像最適化はどこでも機能します。レイジーローディングはどこでも機能します。フォント最適化はどこでも機能します。
最大の勝利から始めます。画像を最適化します。JavaScriptを最小化します。より速いホスティングを選択します。
次にリストを下ります。Preconnectヒント。レイジーローディング。フォント最適化。レンダリングブロックの排除。
各最適化は他のものと複合します。ここで100ミリ秒を削り、そこで200ミリ秒を削り、突然2倍速くなります。
これは実際にSEOにとって重要ですか?
はい。間違いなくはい。
GoogleはCore Web Vitalsをランキング要因として使用します。高速なサイトはブーストを取得します。遅いサイトはペナルティを受けます。
それが唯一の要因ではありません。コンテンツの品質の方が重要です。関連性の方が重要です。権威の方が重要です。
しかし、他のすべてが等しい場合、より速いサイトがより高くランク付けされます。
私は自分のプロジェクトでそれを見てきました。ページ速度を改善し、ランキングが改善するのを見ます。それは劇的ではありませんが、測定可能です。
そして、たとえそれがランキング要因でなくても、ユーザーエクスペリエンスとコンバージョン率にとってそれは依然として重要でしょう。
高速なサイトはプロフェッショナルに感じます。信頼できると感じます。人々が居続けたいと思わせます。
遅いサイトは壊れているように感じます。人々を去らせます。
それはSEOに関係なくあなたのビジネスにとって重要です。
結論
完璧なPageSpeedスコアと1秒未満のロード時間を取得することは魔法ではありません。それは良い選択をして、既知の最適化を実装することです。
高速な基盤を選択します。画像を積極的に最適化します。JavaScriptを最小化します。エッジホスティングを使用します。レンダリングブロックリソースを排除します。
これらのことをすれば、あなたは速くなるでしょう。おそらく0.3秒の速さではありませんが、良いスコアを取得し、素晴らしい体験を提供するのに十分な速さです。
詳細は原則よりも重要ではありません。速く始めます。無駄がないままにします。必要なものだけをロードします。近くから提供します。
これらすべての最適化が実際に動作しているのを見たい場合は、このブログのコードをチェックしてください。オープンソースです。私が説明したすべてが実装されており、使用可能です。
または、apatero.comにアクセスして、PageSpeed Insightsで実行してください。スコアを自分で確認してください。
高速なサイトは可能です。それらを実現するために十分に気にかけることが必要なだけです。