Magento 2 速度の最適化: デフォルトの機能で十分であることを調査が証明

序章

Statista によると、世界の携帯電話ユーザー数は 2019 年に 50 億人を超えると予想されています。その点で、Google はモバイル デバイスでのサイトの読み込み速度を最重要視しています。 このパラメーターは、間違いなく検索結果のランキングに影響を与えます。 さらに、サイトが入院患者のユーザーを失うことを回避できるようになるため、Web サイトの読み込み時間が速いとコンバージョンが増加します。

この記事の最初の部分では、標準的な手段を使用して Magento 2 ページの読み込み時間を短縮できるかどうかを調べて紹介し、最も重要なこととして、これらの手段がどれほど効果的かを定義します.

第 2 部では、サードパーティのソリューションとアプローチの有効性について考察します。

テスト環境

すべての測定はChrome Auditで行われ、「シミュレーション Fast 3G を使用するモバイル デバイスの場合」の制限があります。

レビューでは Docker コンテナに展開された Magento 2.3.1 を使用します。 これにより、リソースを分離できます。

完全に有効化された組み込みキャッシュを使用して、本番モードでパフォーマンスを測定します。

テストは、メイン、製品、カテゴリの 3 つのサイト ページで実施されます。 このページごとに、監査チェックを 3 回実行します。 平均的なテスト結果が選択されます。

負荷テストは実行しないため (ブラウザーのクライアント側でのページの読み込み時間については主にこの記事で説明します)、MySQL と PHP のバージョンは指定しません。 絶対的な結果ではありませんが、さまざまな構成間のパフォーマンスの違いが主な関心事です。

標準の Magento とサーバーの手段を使用してページの読み込み時間を短縮するにはどうすればよいですか?

とりわけ、これは、送信されるデータのサイズまたは要求の数を減らすことによって達成できます。 詳細な洞察については、以下をお読みください。

第1章 Magento のセットアップとサーバーの構成

Gzip

以下の表からわかるように、最初に行うべき最も重要なことは、Magento のセットアップとは関係ありませんが、サーバーで圧縮を有効にすることです。 データ量は、低速のモバイル ネットワークでの読み込み速度を決定する重要な要素です。 圧縮を有効にすると、サイトの表示がはるかに高速になります。 避けられない欠点には、サーバー側でのアンパックの結果としてのFirst CPU Idleパラメータの増加が含まれます。

Gzip なし:

Gzip が有効になっている場合:

Js と CSS を縮小する

送信されるデータのサイズをさらに縮小しようとするとどうなるでしょうか? まずはMinify JsとMinify CSSを有効にしましょう。 次に、比較を行います。

最適化に関連するすべての構成は、 Stores -> Configuration -> Developer にあります。

このタブは、開発者モードでのみ使用できます。 本番モードで、次のコマンドを使用して、最初に開発者モードに切り替えてください。

 > bin/magento deploy:mode:set developer

次に、開発者セクションを表示し、必要な構成変更を行い、キャッシュをクリアして、もう一度本番モードに切り替えることができます。

 > bin/magento deploy:mode:set production

その上で、静的コンテンツの展開が行われます。

接尾辞 min が js/css ファイルに追加されます。

本当にデータ量が減りました！ ホームページの場合、1.3Mb ではなく 1Mb が転送されました。

これでパラメータが 3 分の 1 改善されたと思うなら、それは間違いです。 状況は改善されましたが、大幅には改善されませんでした。

何度も実行しましたが、結果は安定していました。つまり、一定の改善があったにもかかわらず、送信データ量の減少に比例していませんでした。

Js のマージと CSS のマージ

ここで、さらなる改善は、データ ボリュームではなく、リクエスト数の減少に関連していると考えるのが論理的です。

試して、Merge Js と Merge CSS 構成を有効にしましょう。

Magento 自体がこの機能を時代遅れのものとして説明していることに注意してください。

「JS ファイルと CSS ファイルのマージなどの非推奨設定の使用はお勧めしません。これらの設定は、ページの HEAD セクションで同期的に読み込まれる JS 用にのみ設計されているためです。 この手法を使用すると、バンドルと requireJS ロジックが正しく機能しなくなる可能性があります。

それでも、やってみましょう。

リクエスト数の変化は目を見張るものではありませんね。

「First Contentful Paint」や「First Meaningful Paint」などのパラメータは改善されていますが、改善の余地は確かにあります。

JS バンドル

固定サイズに基づいて js ファイルがバンドルされる JS バンドル テクノロジを試してみましょう。 これにより、全体のデータ量を変更せずにリクエスト数を管理できます。

結果は圧倒的です。 問題は、組み込みの Magento メカニズムがすべてのサイトの js バンドルを収集することです。つまり、実質的にすべての js がすべてのページで収集されます。 これにより、ページボリュームが急激に増加します。

はい、特定の js ファイルをバンドルから除外できます (一部はデフォルトで除外されます)。 ただし、特定のページに対してそれを行うことはできません。

Magento は、本番モードでバンドル JS を有効にすることもお勧めしません。 利用可能な 2 番目のオプションのように見えますが、実際にはそうではありません。

高度な JS バンドル

Magento は Bundles JS の問題を認識していますが、独自に対処することは避けるよう提案しています。 公式ガイドには、現在のページに必要な js ファイルのみをバンドルする方法の例があります。 はい、これは構成のパラメーターを変更するよりも少し難しいです。 Advanced Bundle の場合、Nodejs、Require JS、Phantom JS を使用する必要があります。 もちろん、これは既製のソリューションではありません。 しかし、提供されたメカニズムをテストした後、理論的な観点から、高度なバンドルがページの読み込み時間を短縮する方法についてのアイデアが得られます.

提案されたメカニズムは、手動モードで機能し、フレームワークの内部ではなく外部で機能します。 特別なツールは、ページにロードされた js ファイルを分析し、それらをバンドル (一般的なバンドルまたはページ TYPE バンドルに固有のバンドル) に収集します。

最終的に、収集されたバンドルは require js で記述され、それによってページに読み込まれます。

各ページ タイプ (当然、バンドルが収集されたもの) で、特定のバンドルが読み込まれます。 これはホームページの例です。

リクエストの数を減らした後、余分なデータが読み込まれず、パフォーマンスが大幅に向上する必要があるように思われます…しかし、SEO の重要な First Contentful Paint と First Meaningful Paint の時間も同様に劇的に増加しました。 それは理にかなっている。 バンドル ファイルが読み込まれるまで、追跡は行われません。

________________

私たちは最善を尽くしたように見えますか？ 先に進み、現在のテクノロジーを試す時が来たと思います。

HTTP/2

Magento で Bundle JS を無効にし、サーバーで HTTP/2 を有効にします。
私たちの場合、それはただのnginxです。 私たちが行ったことは数行の変更です - 443 ポートの http2 サポートを追加しました。

 listen 80; listen 443 ssl http2; server_name md201.local; ssl_certificate /etc/nginx/ssl-certificates/md201.local/localhost.crt; ssl_certificate_key /etc/nginx/ssl-certificates/md201.local/localhost.key;

Chrome でテストするには、自己署名証明書を信頼されたルート認証局 (この場合は MacOS) に追加する必要があります。

HTTP/2 接続は次のようになります。

これにより、例外なくすべてのパラメーターが改善されました。 それはすべて、HTTP/2 テクノロジの機能にかかっています。

アクセスの遅延を減らして、ページの読み込み時間を短縮します。具体的には次のようにします。

• HTTP ヘッダーのデータ圧縮、
• サーバー側でのプチテクノロジーの使用、
• 搬送を依頼し、
• HTTP 1.0/1.1 プロトコルのヘッドオブライン ブロッキングの解決、
• 1 つの TCP 接続で多数の要求を多重化します。

HTTP/2 では、リクエストごとに TCP 接続が開かれないため、多数のリクエストが問題になることはありません。

HTTP/2 は、実際のブラウザーの大部分で最新バージョンの nginx と apache でサポートされています: https://caniuse.com/#search=http2

これに関して、次のような質問があるかもしれません: Advanced JS Bundle と HTTP/2 を組み合わせるとどうなるでしょうか?

理論的には、HTTP/2 には大きなバンドル js ファイルの読み込みに大きな利点がないため、ページの読み込み時間は短縮されません。 しかし、それを確実に知るために、チェックしてみましょう。

ご覧のとおり、HTTP/2 接続内で Advanced Bundle JS を使用しても速度は向上しません。

バンドルを微調整しようとすると、時間がかかります。 各 Magento またはサードパーティの拡張機能 (フロントエンドに JS を追加する) の更新後、および特定の js を接続する、または他の製品の js を使用しない新しい製品タイプを追加した後に、バンドルを再生成する必要があります。種類。 基本的に、考慮すべきニュアンスは他にもあります。 私の意見では、HTTP/2 を使用する可能性がある場合、Bundle JS に移行しても大きな結果は得られません。

速度を最適化する他の手段はありますか? ページの読み込み時間をさらに速くすることはできますか?

________________

JS コードをページの下部に移動します

正直なところ、サード パーティ ベンダーからのこの最適化手段を検討する予定でしたが、この記事の作成中に、Magento 2.3.2 がリリースされました。 この機能は新しいバージョンに追加されました (デフォルトでは無効になっています)。

有効にすると、一部の js ファイルが <head> セクションから </body> の最後に転送され、理論的にはサイトの視覚化の開始が高速化されます。

それが私たちが最初に持っていたものです：

有効にした後の結果は次のとおりです。

このようなテストを実行するには、Magento のバージョンを 2.3 に更新する必要がありました。 接続ファイルの数とサイズが変更されました。 したがって、テスト結果は大まかになる可能性があります。 Magento のバージョン自体が結果にどのように影響したかを理解するために、まずHTTP/2 + Minify JS/CSSの組み合わせで M2.3.1 と M2.3.2 のバージョンを比較しましたが、得られた結果はほぼ同等であり、測定の不確実性を超えていません。  

ご覧のとおり、 First Contentful PaintとFirst Meaningful Paintはすべてのケースで 10 ～ 15% 改善されています。

概説された Magento 速度最適化のすべての手段の中で、次のバリアントがリードしているようです。

Gzip + JS/CSS の最小化 + HTTP/2 + JS コードをページの下部に移動

それを出発点と考えて、さらに先に進みましょう。 以前は、JS/CSS だけに触れる構成で遊んでいました。 したがって、改善できる特定の側面があります。

Htmlを縮小する

セットアップは次の場所にあります。

ホームページの HTML 部分 — 前に 89 Kb、後は 88.7 Kb HTML 縮小 / サーバーで圧縮すると — 12.2 対 12.1 Kb。

カテゴリ ページの HTML 部分 - 前に 155 Kb、後は 100 Kb HTML 縮小 / サーバーで圧縮 - 15,2 Kb に対して 16,8。

製品ページの HTML 部分 — 前に 80 Kb、HTML 縮小後に 67 Kb / サーバー上で圧縮あり — 14.1 Kb に対して 15。

サーバー側で圧縮が使用されるため、1 ～ 2 Kb の違いは重要ではなく、監査の欠点の範囲内です。

第 2 章追加ツール

サードパーティの拡張機能: JS/CSS/HTML の縮小/マージ | バンドルJS

それまでの間、JS/CSS/HTML およびバンドル JS 用のサードパーティ ソリューションを利用してもあまり意味がありません。 追加の圧縮結果が得られたとしても、フロントエンドでのシェアは 1% に制限されます。 その見返りとして、システムに 1 つまたは複数の Magento 拡張機能が追加されます。 それらの存在とそのアルゴリズムの操作の事実は、追加のリソースを必要とするだけでなく、一般的なシステム障害のリスクを高めます. 潜在的な利益が関連するリスクを上回るかどうか確信が持てない場合は、使用を中止することをお勧めします。

圧縮とバンドルによって読み込み速度を大幅に向上させるサードパーティのソリューションをご存知の場合は、コメントで共有するか、 [email protected]まで直接お知らせください。 喜んで調査させていただきます 

それでは、デフォルトでは Magento で利用できない手段を使用して改善を試みましょう。

画像サイズを小さくする

Web での画像の使用は、常に品質と画像ファイル サイズの間の妥協です。

私たちの主な関心事は、品質を損なうことなく画像サイズを縮小することです。 まあ、デフォルトの Magento 機能を使用して、実際に画像サイズを小さくすることは可能です。 ただし、画像の品質は大幅に低下します。

Magento が構成に基づいて変換およびサイズ変更した標準画像のサイズを小さくしましょう。つまり、主に magento_root_directory/pub/media/catalog/product/cache にある画像に関心があります。

Magento の構成は次の場所にあります。

手始めに、jpegoptim ユーティリティを使用して手動で実行してみましょう。 Magento の高速化を目的とした複数のモジュール (有料のものを含む) は、このユーティリティによって強化されています。

画質を落とさない限り、キャッシュからの画像の結果はありません:

それには何か問題があるようです。 テスト目的で、実際にはページに表示されていない元の画像に適用しました。 重要ではありませんが、一定の結果を達成することができました。

自動化されたソリューションについてはどうですか?

次の無料の画像オプティマイザを試してみましょう: https://github.com/justbetter/magento2-image-optimizer。

拡張機能で使用される、提供されているすべてのユーティリティをインストールしました。

• JPEGオプティム
• 最適化
• pngquant 2
• SVGO
• ギフシクル

画像の圧縮設定はJPEGで80まで設定されています。 これは、デフォルトの Magento 設定に対応しています。 次に、すべてのメディアディレクトリの最適化を実行しました。

圧縮前のフルメディアディレクトリ サイズは 353 Mb、圧縮後は ― 340,1 Mb

media/catalog/product/cache ディレクトリのサイズは 194,7 Mb で、圧縮後も変化していません。

特に画像をサイトにアップロードする前に画像を準備していない場合は、このソリューションが便利で便利であることがわかりました。

ただし、製品ページとカテゴリ ページの全体的な画像サイズの縮小に関しては、大幅な改善は達成されていません。

おそらく、あなたの場合、他の画像形式が主に使用されています。 したがって、結果はさらに重要になる可能性があります。

Apple ブラウザーはこの形式をサポートしていないため、ここでは意図的に webp 画像形式の概要を説明しません: https://caniuse.com/#feat=webp.

____________________

よし、画像ファイルのサイズを大幅に減らすことができない場合は、可視領域のみをアップロードしてみましょう。

遅延読み込み画像

最初に見つけた無料のサードパーティ ソリューション、Magento 2 Lazy Loading を試してみましょう。

以前と同様に、製品、カテゴリ、およびホームページの監査を実施しました。

大きな変化は達成されていません。 変動は測定の不確かさの範囲内です。

これはおそらく、サンプル データ ページが非常に軽量であり、すべてのプライマリ イメージが可視領域に配置されているためです。

商品説明に画像はありません。 カテゴリには説明がまったくありません。
最も簡単な方法で、ページャーのカテゴリ ページの商品数 (読み込み画像の数を含む) を単純に増やしてみましょう。最初は 9 から 30 に、次に 48 に増やし、結果を一覧表示します。

結果は明らかです。 初期ロード時に非表示の Web サイト領域にある画像が (量とサイズで) 大きいほど、利点が大きくなります。 この機能は、最適化の観点からは確かに便利な機能ですが、使いやすさには一定の欠点があります。

_________________

最後の言葉の代わりに

標準の Magento 機能と、ページの読み込みパフォーマンスを最適化できるいくつかのサードパーティ ソリューションの両方について概説しました。

調査にもかかわらず、すべての Web サイトは独自のものであり、独自の特性を持っているため、確固たる結論を導き出すことは困難です。 したがって、あるサイトで機能するソリューションが他のサイトに影響を与えない可能性は常にある程度あります。

ただし、意味のある効果を持つ最も便利な機能は、デフォルトの Magento のGzip + Minify JS/CSS + HTTP/2 + Image Lazy Loadingです。

バンドル JS について

したがって、サードパーティの拡張機能開発者によるこのバンドルの高度なバージョンでは、パーソナライズされたサイトの微調整を追加しない限り、読み込み速度を大幅に向上させることはほとんどできません.

ロード時間の増加に役立つ可能性のある手段が他にもあるはずです。 ただし、それらの多くは万能のソリューションではありません。 たとえば、世界中のさまざまな国からのサイト訪問者と物理サーバー/サーバーの場所の相関関係も重要です。 サイトをサーバーに転送することは理にかなっています。サーバーからのデータ転送は、大部分のサイト ユーザーにとってより高速であり、静的ファイルには CDN を使用します。 サイト訪問者が主に 1 つの地域から来ている場合は、Varnish を使用して静的ファイルをキャッシュしてみてください: https://devdocs.magento.com/guides/v2.3/config-guide/varnish/config-varnish-magento.html#キャッシュ静的ファイル。

最終的に、状況を根本的に変え、サイトをモバイル デバイス上で最大限に高速化する手段は、AMP テクノロジーを使用することです。

PSアンプ

(https://amp.dev/about/websites)

ハンドヘルド デバイスの場合、ユーザーは Google SERP からサイトにアクセスするのではなく、Google サーバーに保存されているキャッシュ バージョンにアクセスします。 初期ロードは電光石火のように速くなります。 そのような Web サイトは、SERP で自然に稲妻で示されます。

このテクノロジは単純化されたものではなく、独自の amp js ライブラリのみを使用することを前提としています。 さらに、現在のテーマにまったく関係のない別のページのバージョンを作成する機会が得られます。

これは難しい選択になる可能性があります。 一方では、読み込み速度と変換の改善がすべてです。 もう 1 つは、AMP テクノロジが課す制限です。つまり、JS と HTML は AMP ライブラリからしか使用できません。 その結果、機能が制限されます。