2018年に、Googleは、ページの速度がデスクトップとモバイルの両方の検索結果のランキングに影響を与えると述べました。しかし、ページ速度の影響を受けるのは順位だけではありません。調査によると、3秒のページの読み込み時間は13%の直帰率につながり、ページ速度は検索結果だけでなくユーザーエクスペリエンスにも関係していることを示しています。
では、Web サイトの動作が遅い場合はどうすればよいでしょうか。Web サイトのパフォーマンスを向上させるのは簡単なことではありません。そのため、多くの企業は検索結果での順位を確保するために、わずかな最適化を行うだけです。
当社がどのようにしてパフォーマンス評価 30 から 99 に移行したか、また、(当社の成果を非常に誇りに思うだけでなく) 業界で最速の Web サイトの 1 つを所有することがなぜ献身的な価値があるのかを、以下でご確認ください。
卒業式：その障害と解決の必要性
ウェブサイトを刷新することで、次の 3 つの主な目標を達成することに重点を置きました。
- 迅速なページ読み込み、改善された UX、一流のコンテンツを通じてコンバージョン率を高めます。
- SEO を強化し、検索エンジンでの可視性を高めます。
- 新しいプロジェクトや顧客レビューを紹介することで、ブランドイメージを強化します。
これらの目標に基づいて、統合する必要のある機能を決定することができました。目標を実現するために考案した重要な機能は次のとおりです。
- 当社のサービス、分野、テクノロジー、ケーススタディを紹介するための、印象的な外観を持つ斬新な構造の Web ページです。
- 検索機能、タグ、カテゴリを備えた強化されたブログ投稿ページ。
- 便利なコミュニケーションのための「お問い合わせ」および代替フォーム。
- さまざまなサードパーティ統合: Google タグ マネージャー、Cookiebot、Hubspot など。
全体として、私たちの目標は安全な静的 Web サイトを構築することでした。そのため、この目標にシームレスに適合する React フレームワークである GatsbyJS を選択しました。
なぜギャツビーなのかとあなたは尋ねますか？ ギャッツビー GatsbyJS の優れた点は、コンパイル時にあらかじめ構築された HTML、CSS、JavaScript を調和させることで、Web 開発をスムーズで迅速なプロセスに変える能力にあります。React で構築された GatsbyJS により、React エコシステムの拡張機能を活用して、個別のテンプレートとコンポーネントを作成できるようになりました。
刷新されたウェブサイトで注意を払う必要があったもう一つの側面は、APIバックエンドでした。私たちの好みは @ストラピオープンソースのコンテンツ管理システムです。このシステムにより、データ構造をカスタマイズし、テキスト、画像、動画などのさまざまなコンテンツ形式を管理するための API 機能を拡張できるだけでなく、ユーザーフレンドリーな管理パネルと、すべてをゼロから開発する必要がなくなる補足機能により、時間とリソースを大幅に節約できました。
最後に、サーバー リクエストには GraphQL を利用しました。GatsbyJS とシームレスに互換性があるため、クエリ形式を定義し、必要なフィールドと関係のみを指定できるようになりました。これにより、余分なデータが回避され、ページの読み込み時間が短縮されました。
技術の融合により、最適なウェブサイトの安定性とセキュリティを実現できました。
完成すると、新しい Web サイトが完成し、ランキングが上がり、デザインも一新されました。最初はそうでしたが、その後、状況は徐々に悪化し始めました。新しいページの追加、さまざまな変更、サードパーティ ソフトウェアの統合により、コードベースが急激に増加し、Web ページ速度を分析するツールである Google の Lighthouse でのパフォーマンス評価が大幅に低下しました。
ライトハウスは、改善活動を開始する前に当社のウェブサイトの所有状況をスコア付けします
スコアがこのように低下すると、Google は有利な位置にはならないでしょう。さらに、有利になったとしても、ユーザーは読み込みが完了するまで待つことに耐えられないでしょう。
エリクソンの調査 モバイル デバイスでページの読み込みが遅れることによって引き起こされるストレスは、ホラー映画を見ているのと同じようなものであることが示されています。パフォーマンスの点では、1 秒ごとに決定的な違いが生じます。この困難を理解した私たちは、すぐにサイトのパフォーマンスの改善に着手しました。
ウェブサイトの効率を計画的に向上させる
パフォーマンスを大幅に向上させるために、Web サイトを悩ませている主な問題を精査し、それぞれの問題を修正する取り組みを開始しました。以下では、主要な課題をどのように克服したかを説明します。
1. ネットワーク接続設定の高速化を2倍に
Gメトリクスウェブサイトの読み込みパターンを描写するツールである は、接続時間が長くなる原因となっている外部ドメインのリソースを特定するのに役立ちました。
紫色のタイミングは、ドメイン ネーム サーバーがドメイン名の IP アドレスの要求を受信するまでの時間を示し、薄緑色はサーバーの接続時間を示します。これらの間隔は長かったため、サーバー接続時間を抑制することで短縮しました。
ウェブサイトの高速化のために、さまざまな技術的強化を実施しました。最初は、HTMLを活用したリソースヒントを導入しました。 <link> 属性。これらのヒントにより、リソース要求がサーバーに転送される前に、ブラウザが積極的に接続を確立できるようになります。外部ドメインのリソースの場合、DNS プリフェッチと事前接続のヒントを組み込み、指定されたドメインとの接続を開始するように事前にブラウザに指示します。そのため、ブラウザが外部ドメインのリソースを必要とする場合、事前設定がすでに完了しているため、リソースは迅速に読み込まれます。
スクリプトやスタイルシートなどの内部ファイルに関しては、「プリロード」と「プリフェッチ」のヒントを採用しました。これらのヒントにより、ユーザーがサイトのページをナビゲートするときに、重要なリソースがローカル キャッシュから取得され、リモート サーバーから取得する必要がなくなり、プロセスが迅速化されます。
これらの最適化により、*Largest Contentful Paint が 2.9 秒から 0.8 秒に短縮され、*First Contentful Paint が 1 秒から 0.6 秒に短縮され、ブラウザはリソースの読み込みを高速化できるようになりました。
*LCP、必須ウェブバイタル測定 ユーザーがページの読み込みを開始してから、最も目立つ画像がビューポートに表示されるまでの時間を定量化します。
*FCP は、ユーザーがページに最初にアクセスしてからコンテンツが画面に表示されるまでの間隔を表します。
高速テキストレンダリングによるフォント読み込みの強化
当社のプラットフォームでは、パーソナライズされたフォントと公開フォントを組み合わせて使用しています。Googleの公開フォント「Manrope」をホストしています。 フォントソース フォントを取得するための最も迅速な方法を表すコレクションです。
しかし、テキストが HTML ファイルから取得されているにもかかわらず、フォント パッケージの読み込みに遅延が発生しました。テキストとフォントの読み込みの不一致を回避するために、当初の戦略では、優先 Web フォントが完全に読み込まれるまで、隠れたフォールバック フォントを表示しました。この方法は効果的でしたが、LCP メトリックが長くなったため、迅速なテキスト レンダリングを優先して戦略を調整する必要がありました。
ワークフローは次のとおりです。まず、ブラウザは指定されたフォント ファミリ内でアクセス可能なフォントを識別し、テキストのレンダリングに展開します。その後、元のフォントを読み込むと、ブラウザは最初のフォントを必要なフォントにシームレスに置き換えます。この戦略は、フォント サイズの変更により予期しないテキストの移動が発生するリスクはあるものの、最も高速なフォント読み込み方法です。レイアウト シフトを軽減し、累積レイアウト シフト (CLS、ページ読み込み中の予期しない要素の移動を追跡するためのゲージ) を改良するために、次のものを実装しました。 CSS フォント モジュール レベル 5、次のような属性を含む仕様群 サイズ調整, 降下オーバーライド、 そして 行間オーバーライドコンテンツの変更を回避するのに役立ちました。
CSSフォントモジュールレベル5は完璧に機能し、レイアウトに影響を与えずにフォントの変更を保証しました。
その結果、First Contentful Paint、Largest Contentful Paint、Cumulative Layout Shift の 3 つの指標が強化されました。特に、CLS は 0.143 秒から 0 秒に短縮されました。
写真や動画の読み込みの強化
私たちが直面したもう 1 つのパフォーマンス上の課題は、ネットワーク ペイロードが膨大だったことです。Web サイトの監査により、品質を損なわずに画像や動画のサイズを縮小して、読み込みプロセスを効率化する必要があることがわかりました。
イエローラボツール 評価によると、すべてのファイル形式の中で、動画と画像は当社のウェブサイトに大きな負担をかけていることがわかりました。
当社の Web サイトは、ベクター画像 (Scalable Vector Graphics (SVG) 形式) とラスター画像 (PNG および JPG 形式) の 2 つの画像バリエーションで構成されています。category ごとに異なる最適化手法が採用されています。
3.1 ベクター画像の強化
ベクター画像は一般的に軽量ですが、各画像を読み込むために新しいHTTPリクエストが必要になり、パフォーマンスが低下するという問題が浮上しました。これに対処するために、インラインSVGを採用し、画像をHTMLに直接埋め込むことを選択しました。これは、 'gatsby-plugin-react-svg' プロセスを効率化する Gatsby フレームワーク内のプラグインです。
3.2 ラスター画像の強化
PNG および JPG 画像の読み込みを高速化するために、これらの画像を最新の .webP 形式に移行し、品質の低下を最小限に抑えながら優れた圧縮を実現しました。同様に、ビデオを .mp4 から .webM に変換し、圧縮と品質の向上を実現しました。.webP および .webM が主要形式として採用されましたが、古いバージョンのブラウザとの互換性の問題が予想されました。この問題を軽減するために、.webP および .webM をサポートしていないブラウザ向けに、.png、.jpg、.mp4 形式へのフォールバックが維持されました。
さらに、画像の表示にはさまざまなデバイスでの最適化が必要でした。モバイル、タブレット、ラップトップ、4Kモニターなど、さまざまなデバイスでは異なる画像サイズが求められました。モバイルと4Kモニターの両方に同じ画像をアップロードすると、Webサイトの読み込み時間が長くなります。対策として、アダプティブグラフィックスを実装し、コードにさまざまな画像オプションを埋め込んで、ブラウザがウィンドウサイズ、画面解像度、ネットワーク速度などの要素に基づいて最適な画像を選択できるようにしました。 'ギャツビー背景画像' そして 'ギャツビーイメージ' さまざまなデバイスに合わせて複数の画像バリエーションを作成しました。 ネットワークタブ 下のスナップショットでは、ページ表示モードを切り替える場所に「デバイス ツールバーの切り替え」が表示されています。
ここでは、さまざまなデバイスで画像の読み込みを改良するためにデバイスツールバーを有効にしました。
ここで表示されているのは、サイズを縮小してさまざまなデバイス向けに最適化された同じファイルです。
3.3 舞台裏画像の遅延読み込み
最後に、ぼかし画像効果と組み合わせた遅延読み込みを実装し、ユーザーが閲覧した場合にのみ画像が読み込まれるようにすることで、限られたユーザー体験を豊かにしました。
料金表やインターネット接続の遅さなど。
これは、ビジュアルコンテンツの遅延読み込み機能がどのように動作するかの例です。
懸命な努力が報われ、品質を損なうことなく、Web サイト上の画像のサイズを大幅に縮小することができました。
改善後、Yellow Lab Tools は、予想通り、動画が依然としてページの大きな部分を占めているものの、ビジュアルの負荷は大幅に軽減されたことを明らかにしました (紫色の部分)
機能強化により、ユーザー エクスペリエンスと CLS や LCP などのゲージが大幅に強化されました。Gatsby エコシステム内のビジュアル最適化拡張機能のみを利用することで、パフォーマンスを向上させるプロセスが容易になりました。
4. キャッシュの合理化
ウェブサーバーがウェブページの複製を保存する方法であるキャッシュは、ウェブサイトの作成時に当初は考慮されていなかったことを認めなければなりません。効果的なキャッシュはウェブサイトを高速化し、サーバーの負荷を軽減できるため、これは間違いなく見逃された可能性でした。私たちはキャッシュの最適化に追いつくことを決意しましたが、さまざまな特定の障害に遭遇しました。
私たちの目標は、リソースを毎回ダウンロードするのではなく、次回の訪問に備えて保存しておくことで、リソースの読み込みを高速化することでした。これを実現するために、HTTP ヘッダーで「cache-control」属性を使用し、ファイルがキャッシュ内に保持される期間を設定しました。しかし、別の問題が浮上しました。Web サイトのコンテンツやデザインに変更を加えても、ブラウザが古い保存コピーを使い続けるため、変更がすぐには反映されませんでした。
どのように対処したのでしょうか? ファイルの名称にハッシュを追加し、ファイルの編集ごとに更新しました。このアプローチにより、変更を簡単に行いながら、長期間キャッシュにファイルを保存することができました。その結果、First Contentful Paint (FCP) メトリックが高から中程度に移行しました。
現在、私たちはブラウザ キャッシュと呼ばれる別のキャッシュ形式を検討しています。サーバー キャッシュは永続的なサーバー接続を必要とし、応答を読み込むために帯域幅を消費しますが、ブラウザ キャッシュを使用すると、ユーザーはネットワーク接続なしで Web ページにアクセスできます。ただし、制約もあります。ユーザーのデバイスのストレージ容量が不足している場合、ブラウザは新しいコンテンツに対応するために古いデータを消去する可能性があります。
より理解を深めるために、サーバー側キャッシュとクライアント側キャッシュがどのように機能するかを並べてみます。
5. 大量のJavaScriptコレクションの削除
バンドルは基本的に、JavaScript、CSS、その他のプロパティなどのファイルで構成され、より効果的な配布のために 1 つのファイルに統合されます。Web サイトの複雑さが増すにつれて、バンドルのサイズが常に大きくなり、Web サイトの重量が重くなりました。問題のあるセグメントを特定して削除するのに適切な時期でした。
問題のあるバンドルを認識して修正するための便利なツールがいくつかあります。そのうちの1つは、 束感恐怖症は、NPM パッケージがバンドル サイズにどの程度寄与しているかについての洞察を提供し、過度に大きなファイルのコンパイルを回避するのに役立ちます。 輸入コストVSCode拡張機能であるは、インポートされたパッケージの「コスト」を計算し、十分な情報に基づいた決定を下すのに役立ちます。最適化戦略の一環として、広く使用されている「classnames」パッケージをより効率的なものに置き換えるなど、重いJSライブラリを置き換えました。 'clsx'、当社のウェブサイトの要件に合わせてカスタマイズされた、より高速で小型のドロップイン代替品です。
その後、 Webpack バンドル アナライザー プラグインでは、バンドル内の問題のある領域を特定しました。
バンドルアナライザーは、クライアントの位置情報と点滅するドットの付いた地図という最も重要なバンドルを発表しました。
これらのファイルの集合体を分析するために、コード分割と遅延読み込みを利用して、大きなバンドルを小さなコンポーネントに分割しました。Webpack の統合されたコード分割機能により、インポート コマンドを、ファイルを直接インポートするのではなく、ファイル パスに誘導する関数に変更することができました。これにより、ファイルが読み込まれるという誓約に似た約束が生成されます。コード内に同様の構造が現れると、この約束が守られ、ファイルが読み込まれます。
必須ではないビュー、HTML、JS については、動的インポートを利用して、Web ページの初期サイズを縮小しました。ここでの「動的」とは、Web サイトが特定の条件に基づいて補足ファイルを読み込むかどうかを決定し、ユーザー エクスペリエンスを妨げないことを意味します。
これが私たちの最適化の結果です。孤立した大規模なバンドルのない洗練された読み込みプロセスです。
大きなバンドルを小さなセグメントに分割した後、ページを効果的に軽量化し、すべての大規模なファイル コレクションを削除しました。
6. コード圧縮によるHTMLとCSSの圧縮
コード圧縮は、私たちのアプローチに革命をもたらしました。コードを圧縮し、不要なスペースを省くことで、ファイル サイズの縮小、ダウンロードの迅速化、帯域幅の使用量の最小化を実現しました。現在、私たちのサーバーは、ウェブサイト ファイルを gzip 形式で配布しており、速度が向上し、FCP や FID (最初のクリックからブラウザーの応答までの遅延を測定する指標である First Input Delay) などの重要な指標が、準最適から中程度のパフォーマンス レベルに大幅に向上しています。
7. コード品質の向上とメモリリークの解決
詳しく調査してみると、コードベース内に巧妙なメモリ リークがいくつかあることがわかりました。この問題は、不要になったオブジェクトがメモリ内に残り、環境が混雑してしまうことに起因していました。
これを修正するために、2 つのアプローチを実装しました。イベント リスナーが 1 回だけ必要な場合は、{only: true} パラメーターを選択しました。このパラメーターは、リスナーがトリガーされた後に自動的に削除されることを保証し、メモリ関連の複雑さを軽減します。さらに、removeEventListener() メソッドを使用して、イベント リスナーを明示的に削除するようにしました。この手順は、要素を削除する前、またはリスナーが古くなった後に実行されました。このようなアクションにより、要素と関数間のシームレスな切断が促進され、メモリ リークが回避されました。
addEventListener に関して考慮すべきもう 1 つの点は、{passive: true} パラメータを組み込むことです。この調整は、スクロール操作に有益であり、インターフェースの中断を防ぎ、ユーザー エクスペリエンスの向上に貢献することが証明されています。
useEffect(() => { setScrolled(document.documentElement.scrollTop > 50); window.addEventListener('scroll', handleScroll, {passive: true }); return () => { document.body.style.overflowY = 'scroll'; window.removeEventListener('scroll', handleScroll); }; }, []);
パフォーマンス向上がウェブサイトに与える影響
率直に言うと、当初の状況は最適とは言えませんでした。読み込み時間が遅く、サーバーに負荷がかかり、ユーザー エクスペリエンスが著しく損なわれていました。しかし、貴重な洞察と最適化戦略を武器に、私たちはタスクに専念し、素晴らしい成果を上げました。結果に満足できたでしょうか? 間違いなく満足です。
ページスピードインサイト 大幅な改善点を強調した賞賛に値する成績表を提示してくれました
1か月にわたるパフォーマンス評価では、目覚ましい進歩が示されました。すべての指標が、当初の目標と比較して大幅な改善を示しました。
これらの変革は、数え切れないほどの時間と日数を費やした努力なしには達成できなかったでしょう。しかし、私たちの成功に大きく貢献したもう 1 つの要因は、適切なツールの活用でした。特定のツールは、私たちの取り組みの時間を節約しただけでなく、感謝に値するものでした。
パフォーマンス向上のためのツール: PageSpeed Insights と Lighthouse
パフォーマンス評価と強化の分野では、2 つの Google ユーティリティが際立っています。 ページスピードインサイト そして 灯台これらのツールは、Web ページのさまざまな側面を精査して、その速度、ユーザー エクスペリエンス、全体的なパフォーマンスに関する洞察を提供します。これらが総合的に評価する指標は次のとおりです。
- 最大のコンテンツペイント (LCP) – 表示領域内の最大のコンテンツ要素 (画像やテキスト ブロックなど) がユーザーに表示されるまでの時間を測定します。
- ファースト コンテンツ ペイント (FCP) – ブラウザがテキストや画像などの最初のコンテンツをレンダリングするのにかかる時間を測定します。
- 最初の入力遅延 (FID) – ユーザーの主な操作 (ボタンのクリックなど) と、そのアクションに対するブラウザの応答との間の遅延を評価します。
- 累積レイアウトシフト (CLS) – ページの存続期間中に発生したすべての個別のレイアウト シフト スコアの合計を集計します。レイアウト シフトは、ページ上の表示要素が予期せず移動したときに発生します。
- 次のペイントへのインタラクション (INP) – ブラウザがページ上の視覚コンテンツを更新してユーザーの操作（クリックやタップなど）に反応するまでの時間を計算します。
- 最初のバイトまでの時間 (TTFB) – リクエスト後にブラウザがサーバーから最初のデータ バイトを受信するまでの期間を決定します。
- 合計ブロック時間 (TBT) – ブラウザのプライマリ スレッドが妨害され、ユーザー入力に応答できない合計期間を定量化します。
- TTI (対話時間) – ページが完全にインタラクティブになるまでの時間、つまり必要なリソースがすべて読み込まれ、ページがユーザー入力に即座に応答するまでの時間を評価します。
- FID (最初の入力遅延) – ユーザーの最初のインタラクションと、そのインタラクションに対するブラウザの反応との間の遅延を精査します。
これらのツールのいずれかを活用して、Web サイトのパフォーマンスに関する洞察を得ることができます。Lighthouse はより柔軟で詳細な洞察を提供し、PageSpeed Insights は個々のページのパフォーマンスの監視に重点を置いています。
これら 2 つはよく利用されていますが、弊社からの唯一の推奨事項ではありません。パフォーマンス最適化の取り組みで非常に役立つ可能性のある追加のリソースをいくつか紹介します。
包括的な調査のための補助ツール
GTメトリックス: ページを監査するだけでなく、読み込みをわかりやすい形式で視覚化し、パフォーマンスの向上を具体的に示す強力なツールです。
イエローラボツール: 多数の指標を分類して評価する洞察力に富んだダッシュボード。問題を特定するだけでなく、最適化のための詳細な提案も提供します。
これらのツールは、パフォーマンスの向上と優れたユーザー エクスペリエンスの提供に役立つ指針として機能しています。Web サイトのパフォーマンスの向上に取り組む際には、これらのツールを念頭に置いてください。
結論
ビジネスがウェブサイトに依存している場合、そのパフォーマンスを無視することは許されません。この側面により、Google 検索結果の最前線に躍り出ることも、逆に、より高速で優れたエクスペリエンスを提供するウェブサイトにユーザーを移行させることもできます。このような窮地を回避するために、私たちはウェブサイトの変貌の物語を共有しました。
常に改善の余地があるため、最適なパフォーマンスを追求する私たちの旅は続きます。最近、GatsbyJS にいくつかの課題が見られ、NextJS への移行を検討しています。ただし、この検討については別の記事で独自に議論する必要があります。
2つのビジネスが同じではないのと同様に、サイトのパフォーマンスを向上させるための普遍的な青写真は存在しません。シナリオはそれぞれ異なり、状況に応じて特定の課題に対処するためのカスタマイズされたアプローチが必要です。簡単な作業ではありませんが、私たちは喜んでお手伝いします。ウェブサイトのパフォーマンスを向上させたい場合は、お気軽にお問い合わせください。 お問い合わせください、私たちがあなたのために何ができるかを検討します。
`
EN 
ZH 
ZH_CN 
JA 
KO