サイトの読み込みを高速化する方法

特にNetologyのMethod LabのテクニカルディレクターであるNikolay Lavlinskyは、何も失うことなくサイトを高速化する方法について話しました。 この記事はブログコンテストに参加しています。



遅いサイトが悪いことは誰もが知っています。 サイトの速度が低下するため、日常のタスクを解決する際に深刻な問題が発生します。 時々それは単に迷惑です。 多くの場合、サイトのブレーキングは故障、つまりサービス拒否であり、人々はダウンロードを待って立ち去りません。 これは、たとえば、ページレンダリングの開始がクリック後8〜10秒で始まる場合など、サイトの根本的な阻害の場合に関連します。







サイトが比較的良好な状況（有線インターネットと最新のコンピューターで高速にロードする場合）でも、ダウンロードの遅延は視聴者の損失とコンバージョンの減少につながる可能性があります。 たとえば、Amazonは100ミリ秒（0.1秒）の遅延ごとに売上が1％減少することが判明した実験を実施しました。



しかし、今日のオンライン視聴者の半数以上がモバイルデバイスを使用してサイトにアクセスしています。 そのため、アクセスとプロセッサに低速のチャネルを使用してサイトをロードできます。



サイトの速度の問題の重要性の3番目の理由は技術的です。 原則として、低速なサイトではホスティングリソースの消費量が増加し、追加コストが発生します。 サーバー側のブレーキは、サイトのピーク負荷にシームレスに耐える能力を低下させます。



したがって、サイトの速度は、技術的および経済的な観点から対処する必要があります。 この記事では、ウェブサイトの高速化の技術的な側面に集中します。

サイトの速度：主要なコンポーネント

サイトの速度は、クライアントとサーバーの2つの側面に影響します。 現在、これらの各パーツは最終結果と同等です。 しかし、それぞれ独自の特徴があります。



サイトのページ読み込み時間の形成元を理解するために、このプロセスを段階的に分析します。 その結果、サーバーとクライアントの最適化の機能がどこにあるかを理解できます。



サイトを読み込む完全なプロセス（最初の訪問）は次のとおりです。

1. サイト名によるDNSクエリ。
2. IPを介したサーバーへの接続（TCP接続）。
3. HTTPS（TLS接続）を使用して安全な接続を確立します。
4. URLでHTMLページを要求し、サーバーを待ちます。 （HTTPリクエスト）
5. HTMLの読み込み。
6. ブラウザ側でHTMLドキュメントを解析し、ドキュメントリソースにリクエストのキューを作成します。
7. CSSスタイルの読み込みと解析。
8. JSコードをダウンロードして実行します。
9. ページレンダリングの開始、JSコードの実行。
10. Webフォントをダウンロードします。
11. 画像やその他のアイテムをダウンロードします。
12. ページのレンダリングの終了、保留中のJSコードの実行。

このプロセスでは、いくつかの位置は並行して発生し、いくつかは場所を変えるかもしれませんが、本質は同じままです。



サーバーの最適化では、第1段階から第4段階までを扱います。 手順5〜12はクライアントの最適化です。 これらの各段階で費やされる時間はサイトごとに異なるため、サイトのメトリックを取得し、問題の主な原因を特定する必要があります。 ここで、これらのメトリックを取得して解釈する方法の問題に移ります。

サイト速度測定

主な質問：何を測定する必要がありますか？ サイトの速度に関する多くの指標がありますが、それほど多くはありません。



まず、最初のバイトまでの時間（TTFB-最初のバイトまでの時間）は、ダウンロードプロセスの開始からサーバーからのデータの最初の部分の受信までの時間です。 これは、サーバー最適化の基本的なメトリックです。



第二に、これはページのレンダリングの開始です（レンダリングの開始、最初のペイント）。 メトリックは、ページが描画を開始するときにブラウザーの「白い画面」期間が終了するまでの時間を示します。



第三に、ページの主要な要素のロード（ロード時間）です。 これには、ページを操作するためのすべてのリソースの読み込みと解釈が含まれます。このマークの後、ページ読み込みインジケータの回転が停止します。



第4に、これはフルページロードです。ブラウザのメインアクティビティが終了するまでの時間で、メインおよび保留中のすべてのリソースがロードされます。



これらのコアメトリックは数秒で測定されます。 3番目と4番目のメトリックのトラフィック量を見積もることも役立ちます。 接続速度が起動時間に与える影響を評価するには、トラフィックを知る必要があります。



ここで、速度をテストする方法を理解する必要があります。 サイトの負荷速度のメトリックを評価するための多くのサービスとツールがあり、それぞれがタスクに適しています。



最も強力なツールの1つは、ブラウザーダッシュボードです。 Chromeで最も開発されたパネル機能。 [ネットワーク]タブでは、HTMLドキュメント自体を含むすべての要素の読み込み時間に関するメトリックを取得できます。 要素にカーソルを合わせると、リソースを取得する各段階で費やされる時間を確認できます。 ページの読み込みプロセスの全体像を評価するには、パフォーマンスタブを使用します。このタブでは、画像のデコード時までの詳細が表示されます。



詳細なしでサイトの速度を評価する必要がある場合、サイト監査（[監査]タブ）を開始すると便利です。Lighthouseプラグインを使用して実行されます。 レポートでは、モバイルデバイスの速度の推定値（両方ともポイントで積分されているため、メインメトリックス）と他のいくつかのレポートを取得します。



Webサービスの中で、 WebPagetestはプロフェッショナルな標準になりました。 このサービスは、指定された種類の接続で実際のブラウザにサイトをロードし、すべてのステージとメトリックに関する詳細なレポートを生成します。



クライアントの最適化をすばやく評価するには、Google PageSpeed Insightsサービスを使用できますが、ダウンロード時間に関する最も重要なメトリックのほとんどが含まれていないことに注意する必要があります。 最後に、実際のユーザーのサイトの読み込み時間を分析すると役立ちます。 Web分析システムYandex.MetricaおよびGoogle Analyticsには、このための特別なレポートがあります。



サイトの読み込み時間のガイドラインは次のとおりです。レンダリングの開始は約1秒、ページの読み込みは3〜5秒以内です。 このフレームワークでは、ユーザーはサイトの速度について文句を言うことはなく、読み込み時間はサイトの効果を制限しません。 これらの数値は、モバイル接続や古いデバイスの困難な状況であっても、実際のユーザーで正確に達成する必要があります。

サーバーの最適化

Webサイトの高速化自体に進みましょう。 サーバー側の最適化は、サイト開発者にとって最も理解可能で明白な手段です。 まず、サーバー部分はシステム管理者によって簡単に監視および制御されます。 第二に、サーバーの応答時間に重大な問題があるため、接続速度やデバイスに関係なく、すべての人がスローダウンを認識できます。



サーバー側のブレーキングの理由は非常に多様であるという事実にもかかわらず、見なければならない典型的な場所があります。

ホスティング（サーバーリソース）

これは、小さなサイトでブレーキをかける一番の理由です。 サイトの現在の負荷については、ホストリソースが十分ではありません（通常、これはCPUとディスクシステムの速度です）。 これらのリソースをすぐに増やすことができる場合は、試してみる価値があります。 場合によっては、問題は解決されます。 追加のリソースのコストが最適化作業のコストよりも高くなった場合、次の方法に進む必要があります。

DBMS（データベースサーバー）

ここで、問題の原因であるプログラムコードの低速化を解決するために、すでに進んでいます。 多くの場合、Webアプリケーションはデータベースのクエリに費やされます。 Webアプリケーションのタスクはデータを収集し、特定のテンプレートに従って変換することであるため、これは論理的です。



データベースからの応答が遅いという問題の解決策は、通常、2つの段階に分けられます。DBMSの調整と、クエリとデータスキームの最適化です。 DBMS（たとえば、MySQL）のチューニングは、チューニングが以前に行われていなかった場合、数回加速する可能性があります。 微調整により、10パーセント以内の効果が得られます。



クエリの最適化とデータスキーマは、スピードを上げるための抜本的な方法です。 この最適化により、数桁の加速が得られます。 サイトのプログラムコードに侵入することなくデータベースの構造の変更が発生する可能性がある場合、クエリの最適化にはそのような介入が必要になります。



遅いクエリを特定するには、かなり長い時間データベースの負荷に関する統計を収集する必要があります。 次に、ログの分析と最適化の候補の識別が実行されます。

CMSとプログラムコードの影響

サイトの速度はCMS（「エンジン」）のみに依存すると非常に広く信じられています。 ウェブサイトの所有者は、CMSを高速と低速に分割しようとすることがよくあります。 実際、これは完全に真実ではありません。



もちろん、サーバーの負荷は、使用されるCMSに含まれるコードに依存します。 ただし、ほとんどの一般的なシステムは最大速度に最適化しようとし、サイトの速度に関する致命的な問題はすべきではありません。



ただし、メインのCMSコードに加えて、サイトには、サイトの開発者による追加のモジュール（プラグイン）、拡張機能、および変更が含まれている場合があります。 そして、すでにこのコードはサイトの速度に悪影響を及ぼす可能性があります。



さらに、システムが他の目的で使用される場合、速度の問題が発生します。 たとえば、ブログシステムを使用してストアを作成します。 または、小規模サイト用のシステムを使用してポータルを開発します。

キャッシング

サーバーの速度を向上させるための最も強力で普遍的な手段は、伝統的にキャッシングです。 ここでは、ヘッダーのキャッシュではなく、サーバーのキャッシュについて説明します。 結果の計算（ページのアセンブリ、ブロック）に大量のリソースが必要な場合は、結果をキャッシュに入れて定期的に更新します。 アイデアは同時にシンプルで複雑です。キャッシングシステムはプログラミング言語、サイト管理システム、Webサーバーに組み込まれています。



通常、ページキャッシュにより、ページのレンダリング時間を数十ミリ秒に短縮できます。 当然、この場合、サーバーは簡単にピークトラフィックを経験します。 2つの問題があります。すべてをキャッシュできるわけではなく、キャッシュを正しく無効にする（リセットする）必要があります。 問題が解決した場合、サーバーアクセラレーションの効果的な手段としてキャッシュを推奨できます。

TCP、TLS、HTTP / 2の最適化

この部分では、サーバーの高速化を実現する微妙なネットワーク最適化を組み合わせました。 ここでの効果は、他の方法ほど広くはありませんが、チューニングによってのみ達成されます。つまり、無料です。



今日のTCPの調整は、10Gの接続を持つ大規模なプロジェクトとサーバーに必要です。覚えておくべき主なことは、ネットワークサブシステムが新しいLinuxカーネルのリリースで定期的に更新されるため、更新する価値があることです。 適切なTLS構成（HTTPS）を使用すると、高レベルのセキュリティを取得し、安全な接続の確立にかかる時間を最小限に抑えることができます。 Mozillaがリリースした優れた推奨事項。



HTTPプロトコルの新しいバージョン-HTTP / 2は、サイトの読み込みを高速化するように設計されています。 このプロトコルは最近登場し、現在積極的に使用されています（Webサイト間の共有の約20％）。 一般的に、HTTP / 2には実際にアクセラレーションメカニズムがあります。主なものは、ページの読み込み時間に対するネットワーク遅延の影響を減らすことです（リクエストの多重化）。 ただし、HTTP / 2による高速化は常に成功とはほど遠いため、このプロトコルに依存しないでください。

顧客の最適化

サーバーの最適化とは異なり、クライアントはユーザーのブラウザーで発生するすべてを対象としています。 このため、制御は複雑で（さまざまなデバイスやブラウザー）、最適化にはさまざまな分野があります。 ほとんどすべてのプロジェクトで使用できる最も効果的で普遍的な方法を見ていきます。

クリティカルパスの最適化：CSS、JS

クリティカルレンダリングパス-ブラウザーでページのレンダリングを開始するためのリソースのセット。 通常、このリストには、HTMLドキュメント自体、CSSスタイル、Webフォント、およびJSコードが含まれます。



スピードオプティマイザーとしてのタスクは、時間（ネットワーク遅延を考慮）とトラフィック（低速接続を考慮）の両方でこのパスを短縮することです。



クリティカルパスを決定する最も簡単な方法は、Chrome（開発者パネル）で監査を開始することです。Lighthouseプラグインは、低速接続を考慮して、構成と読み込み時間を決定します。



主な手法は、クリティカルパスを削減することです。不要な、または延期できるものはすべて削除します。 たとえば、ほとんどのJSコードは、ページがロードされるまで遅延できます。 これを行うには、HTMLドキュメントの最後にJSリソース呼び出しを配置するか、async属性を使用します。



CSSの遅延ロードの場合、JSを介して動的スタイルシートを使用できます（domContentLoadedイベントを待機した後）。

Webフォントの最適化

今日のWebフォントの接続は、設計のほぼ標準になっています。 残念ながら、これらはページのレンダリング速度に悪影響を及ぼします。 Webフォントは、テキストのレンダリングを開始する前に取得する必要がある追加リソースです。



多くの場合、フォントファイルへのポインターがCSSファイルに埋もれているという事実によって状況は悪化しますが、CSSファイルもすぐには来ません。 多くの開発者は、公開Webフォントサービス（たとえば、Google Fonts）の使用を好みます。これにより、さらに大きな遅延（追加の接続、CSSファイル）が発生します。



最適化ルールは、Webフォントトラフィックのサイズを縮小し、できるだけ早く取得することです。



トラフィックを削減するには、最新の形式を使用する必要があります。最新のブラウザにはWOFF2、互換性にはWOFFを使用します。 さらに、サイトで使用されている文字セット（ラテン語やキリル文字など）のみを含める必要があります。



新しい仕様リンクrel = "preload"とCSS font-displayプロパティを使用して、Webフォントの高速表示に影響を与えることができます。 プリロードにより、フォントファイルをできるだけ早くダウンロードする必要があることをブラウザに伝えることができます。また、font-displayは、ファイル遅延の場合にブラウザの動作を制御するための柔軟なオプションを提供します

画像の最適化

画像は、現代のサイトの重量の大部分を占めています。 もちろん、画像はページにとってCSSやJSコードのような重要なリソースではありません。 しかし、多くのサイトでは、画像がコンテンツの重要な部分を構成しています。オンラインストアの製品カードを覚えておいてください。



画像を最適化するための主な手法：サイズを縮小します。 これを行うには、正しい形式と圧縮ツールを使用します。

• 透明度とテキストを含む画像のPNG。
• 写真および複雑な画像のJPEG。
• ベクトルグラフィック用のSVG。

これらの形式に加えて、GoogleのWebPなどの新しい形式が開発されています。 この形式は、PNGおよびJPEGの使用領域をカバーできます-非可逆および可逆圧縮、透明度、さらにはアニメーションもサポートします。 これを使用するには、WebPで画像のコピーを作成し、それらをサポートするブラウザーに提供するだけで十分です。



PNGには、OptiPNG、PNGout、ectなど、サイズを縮小するために使用できる多くの最適化ツールがあります。 また、zopfliPNGを使用して、データ圧縮の内部最適化を実行できます。 そのようなソフトウェアの主なアイデアは、最適な圧縮パラメータを選択して、ファイルから余分なデータを削除することです。 ここで注意する必要があります：一部のユーティリティには、品質が低下するモードがありますが、これはあなたに適していない可能性があります（出力でまったく同じ画像を期待する場合）



JPEG最適化は、非可逆と可逆の2つのタイプに分けられます。 通常、Mozilla JPEGパッケージをお勧めします。このパッケージは、この形式での圧縮を改善するために特別に設計されています。 ロスレス最適化の場合は、jpegtranを使用して、損失あり-cjpegを使用できます。

キャッシングヘッダー

これは最も単純なクライアント最適化手法です。 その意味は、ブラウザがほとんど変更されないリソースをキャッシュすることです：画像、CSSおよびJSファイル、フォント、時にはHTML文書自体です。 その結果、各リソースはサーバーから一度だけ要求されます。



Nginxを使用している場合は、ディレクティブを追加するだけです：

add_header Cache-Control "max-age=31536000, immutable";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この時点から、ブラウザには最大1年間（ほぼ永久に）リソースをキャッシュする権利があります。 新しいパラメーター「不変」は、リソースが変更される予定がないことを示します。



もちろん、疑問が生じます。キャッシュされたリソースを変更する必要がある場合はどうでしょうか。 答えは簡単です。アドレス、URLを変更します。 たとえば、ファイル名にバージョンを追加できます。 HTMLドキュメントの場合、この方法も適用できますが、原則として、より短いキャッシュ時間が使用されます（たとえば、1分または1時間）。

データ圧縮

必須のプラクティスは、サーバーからブラウザに送信するときにテキストデータを圧縮することです。 ほとんどのWebサーバーには、gzip応答圧縮の実装があります。

ただし、単に圧縮をアクティブ化するだけでは十分ではありません。



第一に、圧縮率は調整可能であり、最大に近いはずです。



第二に、静的圧縮を使用できます。つまり、ファイルを事前に圧縮し、ディスクに保存します。 次に、Webサーバーは圧縮バージョンを検索し、すぐにそれを提供します第三に、より効率的な圧縮アルゴリズムを使用できます：zopfli（gzipと互換性あり）およびbrotli（新しい圧縮アルゴリズム）。 BrotliはHTTPSでのみ動作します。 これらのアルゴリズム（特にzopfli）は圧縮にコストがかかるため、静的バージョンでは間違いなく使用します。



ファイルの圧縮効果を最大化するために、ミニファイプロセスが事前に適用されます。不要な改行、スペース、その他の不要な文字のクリーニングです。 このプロセスは各形式に固有です。 また、サイト上の他のテキストデータの圧縮にも注意する必要があります。

CDNを使用する

ウェブサイトの高速化にCDN（コンテンツ配信ネットワーク）を使用することは、技術の本質に多くのマーケティングの殻を付けた、非常に公表された手段です。

理論：なぜ

もともと、CDNは、放送メディアサイトのインターネットチャネルをオフロードするように設計されていました。 たとえば、ライブビデオを視聴する場合、数千人の視聴者がサーバーの帯域幅に非常に大きな負荷をかけます。 さらに、クライアントとサーバー間の距離が長い場合に通信の中断のない品質を確保することは非常に困難です（遅延とネットワークの不安定性のため）。



この問題の解決策は、CDN、つまりクライアント（ビューアなど）が接続され、このネットワークのホストが既にサーバー（オリジン）に接続されている分散ネットワークを作成することでした。 同時に、サーバーへの接続数は1つ（数回）に削減され、ネットワークによるコンテンツのキャッシュによりCDNへの接続数は数百万に達する可能性がありました。



現在、ほとんどのCDNは、主にコンテンツからクライアント（サイト訪問者）までの距離を短くすることにより、サイトを加速する手段として位置付けています。

考えられる効果

CDNを使用してサイトを高速化するにはどうすればよいですか？



はい、ユーザーは原則として、ネットワーク上の最も近い（アクセス時間で）サーバーに実際に接続し、TCPおよびTLS接続を確立する高速プロセスを受け取ります。 さらに、コンテンツがCDNサーバー上にある場合、ユーザーはすぐにそれを受信できます。 したがって、独自のサーバーの負荷が軽減されます。



第二に、CDNはコンテンツを変更せずに配信できるだけでなく、その側で最適化してよりコンパクトな形式でレンダリングできます：画像の圧縮、テストへの圧縮の適用など。このような最適化により、ダウンロード時間を短縮できます。

CDNを使用することの欠点

通常の欠点は、利点が続くことです。オブジェクトがCDNノードのキャッシュにない場合があります。 たとえば、まだ要求されていないか、キャッシュできません（HTMLドキュメント）。 この場合、CDNとサーバーの間で追加の遅延が発生します。



CDNはサイトへのアクセスを高速化するように設計されているという事実にもかかわらず、ネットワークルートがCDNがない場合よりも最適でない場合があります。 特にロシアが優先市場ではないグローバルCDNに関連しています。



最後に、コンテンツ配信ネットワークは非常に複雑なシステムであり、他の場所と同様に、障害、不安定性、およびその他の問題が発生する可能性があります。 CDNを使用して、別のレベルの複雑さを追加します。

結果を修正します

良いサイト速度メトリックを達成できたとしましょう。 ユーザーとリソース所有者は満足しています。 これで、速度の問題を忘れることができますか？ もちろん違います。 サイトの品質を一定に保つには、常にサイトを維持し、監視を実施する必要があります。

加速サポート

ライブWebプロジェクトは定期的に更新され、一般的なテンプレート（デザインテーマ、インターフェイス）、およびコンテンツの両方で変更が発生します。 プログラムコード（クライアントとサーバーの両方）も積極的に変更されています。



各変更は、サイトの速度に影響を与える可能性があります。 この影響を制御するには、開発段階でサイトの速度を監視するための合成システムを導入する必要があります。 したがって、ユーザーが気づく前に速度の問題を把握できます。



受信コンテンツを最適化するには、最適化手順をコンテンツ管理システムに統合する必要があります。 まず、これは画像処理に関するものです。



サイトの高速化は非常にダイナミックな領域です。新しい標準が登場し、ブラウザのサポートが変化しています。 したがって、プロジェクトの技術、プロセス、使用されているソフトウェアを定期的に確認することが重要です。

ユーザーの実際の速度を監視する

理想的な実験室条件下での合成テストは、システムコードの変更を評価するのに非常に役立ちますが、それだけでは不十分です。 最終的に、私たちはサイトが実際のユーザーのために素早く動作することを望みます。 このようなデータを収集するために、ユーザー側で速度監視が行われます（RUM-実際のユーザー監視）。



RUMを整理するには、Web分析システム（Yandex.Metrica、Google Analytics）のいずれかを接続して、サイトの読み込み時間に関するレポートを表示します。 より詳細で正確なデータについては、専用の速度監視サービスを使用できます。

結論

ウェブサイト高速化業界は、ウェブ開発のかなり若い業界であり、積極的に発展しています。 オンラインビジネスのサイト速度の重要性はすでに明らかであり、競争の要因の1つになりつつあります。 そのため、サイトの速度を最適化し、この分野に投資する価値があります。



サイトの速度のトピックは広範であり、サーバーコードからコンテンツまで、Webアプリケーションの開発とサポートの多くの側面に影響を与えます。 これは、開発チームの関与なしに良い結果を得ることが不可能であることを意味します。



最も重要なこと：ユーザーについて覚えておいて、サイトのさまざまな使用条件を考慮に入れてください。 Webサイトの高速化は、プロジェクトのライフサイクル全体でさまざまな強度で行われるプロセスです。