Magento TTFB を改善するための 5 つの重要なヒント

公開: 2019-01-08

これは、Vasili Nikolaev によるゲスト投稿です。

最初のバイトまでの時間 (TTFB) は、Web サイトの最も重要な速度指標の 1 つです。 これは、ユーザーが Magento ストアの URL を入力してからの経過時間と、わずか 1 バイトであっても応答を受け取る時間を示します (したがって、「最初のバイトまでの時間」という名前が付けられています)。

最初のバイトまでの時間、人間 (彼らは待つのが好きではない) と検索エンジン ロボット (Google は遅い Web サイトを嫌い、それらを低くランク付けします。メイジワークス)。

しかし同時に、Google のトーキング ヘッドの 1 人である John Mueller から、Google がランキングに TTFB を使用していないという説得力のある証拠があります。

マジェント 2 TTFB | MageWorx ブログ

したがって、SEO のために TTFB に執着しすぎるのではなく、ユーザー エクスペリエンスと店舗のパフォーマンスに重点を置くことをお勧めします。

TTFB がページ全体の読み込み (「最後のバイトまでの時間」と呼ばれる) よりも重要なのはなぜですか? 最初のバイトを読み込むのが早ければ早いほど、ユーザーはより速くコンテンツを読み始めるからです。 ページ上のすべての画像をすぐに見ることができないことは問題ではありません。 Web サーバーが残りのコンテンツの読み込みでビジー状態になっている間に、ユーザーに何かを提供することがより重要です。

目次

  • 1. ボトルネックを理解して解消する
    • 良いTTFBとは?
  • 2. より適切なデータベース エンジンに移行する
  • 3.サーバーのセットアップを現在のトラフィックのニーズに合わせる
  • 4. より良いキャッシング ソリューションをセットアップする
  • 5. 役に立たない拡張機能を取り除く
  • おまけのヒント: ストアと顧客のログ設定を微調整する
  • パフォーマンスのための絶え間ない戦い

1. ボトルネックを理解して解消する

良いTTFBとは?

マジェント 2 TTFB | MageWorx ブログ
Google は、200 ミリ秒未満の TTFB が目標であると述べています。 200 ミリ秒未満の場合、検索エンジンはあなたを最高にランク付けします。 この値を超えると、Google はウェブサイトにペナルティを課します。 600 ミリ秒以上は、Google 独自の TTFB テストにさえ合格できないことを意味します。

TTFB に影響を与える要因はたくさんあります。 順不同:

  • Web サーバーの構成とリソース、
  • ネームサーバーの解決速度、
  • ページ上のコード実行時間、
  • 実装されたバックエンド キャッシング ソリューション、
  • ネットワーク推測。

サードパーティ サービスまたは Google TTFB テストを使用して、TTFB 値を確認します。 ここで結果を人気のあるウェブサイトや競合他社と比較して、モバイル ユーザーにとってストアがどのようにロードされるかについて独自の視点を得ることができます。

マジェント 2 TTFB | MageWorx ブログ もう 1 つの優れた診断ツールは、 Magento 2 Profilerです。 これを使用すると、すべてのページ リクエストを小さなブロックに簡単に分割して、すばやく視覚化および分析できます。

この表では、2 つの重要な値である Time と Count に特に注意してください。 時間は自明です。 これは、ユーザー リクエストとサーバー レスポンスの間の実際の遅延です。 Cnt 行は、この項目が出力を作成する前に呼び出された回数に対応します。

データベース クエリを分析するには、データベース プロファイラーを Magento 2 デフォルト プロファイラーと組み合わせて使用​​する価値があります。

マジェント 2 TTFB | MageWorx ブログ これが最初に行う必要があるステップです。Magento Profiler を有効にして、TTFB で最大の問題を抱えているページを調べます。 デフォルトのプロファイラーを使用できますが、Profiler SQL をセットアップすることをお勧めします。 これは無料で、セッションごとのクエリ数の便利な概要を提供します。

プロファイラーはすべてのリクエストを小さなパーツにスライスするので、どのセクションが足を引っ張っているかをすぐに確認できます。

2. より適切なデータベース エンジンに移行する

Magento 2 ストア データベースは、効率が悪い、遅い、または Magento の処理に最適ではないストレージ エンジンを使用している場合、パフォーマンスの最大のボトルネックになる可能性があります。

何でこれが大切ですか? MySQL 用のさまざまなストレージ エンジンには十分な選択肢があります。 MySQL の公式ドキュメントでサポートされているソリューションは少なくとも 10 ありますが、実際にはさらに多くのソリューションがあります。

デフォルトの MyISAM MySQL エンジンで Magento を使用できますが、ストレージ エンジンである MariaDB Ari や Percona XtraDB エンジンなどの代替データベース エンジンを使用すると、ストアをより安定させ、デフォルト設定よりも (場合によっては) 高速にすることができます。

たとえば、 Ariaエンジンは、Magento がストレージ エンジンに大量の一時テーブルの使用を強制する場合に、よりスマートなアプローチを使用します。

Perconaは MySQL のもう 1 つのフォークであり、データベース クエリを高速化するために多くのパフォーマンス調整を長年にわたって統合してきました。 MyISAMと比較して、多くの並列クエリではるかに高速に動作し、トランザクション処理に特化しています。

データベースを最適化するための最善の推奨事項は、ニーズを慎重に検討し、最適なエンジンを選択することですが、すべての人に役立つヒントがいくつかあります。

  • ストア検索にデフォルトの MySQL を使用しないでください。 Elasticsearch をインストールして、Web サイトのすべての検索クエリを高速化します。
  • 最適なデータベース エンジンを選択してください。

3.サーバーのセットアップを現在のトラフィックのニーズに合わせる

インフラストラクチャを安売りするのは得策ではありません。 時間が経つにつれて、着実に成長するビジネスは、より多くの顧客、より多くのトランザクション、およびより多くの注文を目にするようになります。 そのため、セットアップを 80% のキャパシティに維持して、ランダムな使用スパイクやイベントによって生成された通行量に合わせて調整することは健全です. この 20% は、あらゆる状況で適切なレベルのパフォーマンスを維持するのに大いに役立ちます。

信頼できるホスティング チームが、スムーズに運用するために必要なシステム要件を教えてくれます。 ただし、一定期間にわたって急速に成長した場合は、アップグレードのロードマップを概説するのは自分の責任になります。

Magento ストアには、システム要件に大きく影響するいくつかの重要なポイントがあります。

  • 店舗規模(店舗閲覧数)、
  • カタログ内のカテゴリと SKU (属性と属性セットを含む)、
  • 平均トラフィック数 (平均ページビューと過去のピーク)、
  • 1 日あたりのトランザクション (デジタル ダウンロード、支払い、および同様の操作)。

一般に、平均トラフィックは、必要な CPU パワーの量に直接影響します。 そのため、最適な CPU セットアップを見つけたら、RAM を CPU 要件に合わせて、バランスの取れた Web サーバー プロファイルを作成します。

データベースのストレージ サイズは、現在の RAM に依存するため、現在のすべてのニーズをカバーするのに十分な量を選択する必要があります。 息抜きスペースとしてパフォーマンスクッションも作りましょう。 目標は、偶発的なトラフィック スパイクに対処するために、少なくとも 20 ~ 25% の予備の CPU と RAM を常に確保することです。

4. より良いキャッシング ソリューションをセットアップする

ウェブサイトのキャッシングは、フライド ポテトの発明の次善策です。 サーバー キャッシュにより、Web サイトのスナップ性が向上し、はるかに高速に感じられます。 キャッシュは、頻繁に使用されるデータを SSD またはハード ドライブから RAM に移動することによって機能します。

HDD は最大 200 MB/秒、SSD は最大 3200 のデータをシーケンシャルに読み取ることができますが、DRAM モジュールは最大 20 GB/秒まで進むことができます。 これにより、x10 または少なくとも 1 桁の差が得られます。

RedisVarnishはどちらも、Magento ストアで最も人気のあるアップグレードの 1 つです。 これは、Magento 2 に推奨されるキャッシュ オプションです。どちらのソリューションも、Magento 1 でうまく機能します。

Varnish は設定が難しいツールですが、正しく設定すると 100 ~ 200 ミリ秒で TTFB 値が得られます。 フルページ キャッシュ構成の場合、TTFB は 250 ミリ秒以内の範囲になります。

Varnish のもう 1 つの明確な利点は、より多くの Web ページで機能することです。 FPC は多くの動的コンテンツを含むページでは機能しませんが、Varnish はこれらの困難なユース ケースでも優れたパフォーマンスを提供します。

5. 役に立たない拡張機能を取り除く

正直なところ、未使用の拡張機能を無効にすることは、どの Magento 2 ストアでも最大のヒントですが、見過ごされがちです。 Web サイトで実行されるすべての拡張機能は、リソースの一部を使い果たします。 設定が不十分な場合、TTFB の速度が低下する可能性もあります。

注意: サーバーは、フィードバックをユーザーに送信する前に、このコードを実行する必要があります。

拡張機能リストをクリーンアップすると、Magento も高速化されます。 いずれも無効にできない場合でも、Magento ストアとサードパーティの拡張機能の両方を最新の状態に保ち、サイトのパフォーマンスを確実に向上させるバグ修正と最適化の恩恵を受けてください。

おまけのヒント: ストアと顧客のログ設定を微調整する

Magento の顧客ログをオフにしてください。 これにより、データベース クエリに費やす時間を短縮できます。 顧客のログ記録は比較的マイナーなアクティビティであるため、大きな影響はありません。 パフォーマンスの向上は、現在店舗を訪れている顧客の数によって異なります。

ストア ログをオフにすることはお勧めしません。 これは、Magento のトラブルシューティングに役立つ貴重なツールです。 ただし、ストア ログにサーバー時間を費やす代わりに、それらを Papertrail などのサードパーティ サービスに移動できます。

パフォーマンスのための絶え間ない戦い

同じ Magento ストアは 2 つとありません。 ストアフロントのスピードを最適化するには、それぞれがさまざまな課題に直面します。 これは、多くの複雑なサードパーティの拡張機能、大規模なデータベース、および複数のストアを持つ、古い (そしてより大きな) Magento Web サイトに特に当てはまります。

このパフォーマンスの戦いに「勝つ」ことは決してできませんが、私たちの共通の目標は、Magento ストアをすべての e コマース Web サイトの中でスピード、ユーザー エクスペリエンス、およびセキュリティにおいてクラス最高にすることです。


著者について

Vasili Nikolaev は、店主の生活を少し楽にするための最も効果的なヒントを掘り起こすために、常に宝探しを続けています。 彼にとって困難な問題に対する優れた解決策を見つけることほど満足できるものはありません。