Jon Brown と一緒に WordPress サイトのパフォーマンスをテストして解釈する方法 — Do Go Chasing Waterfalls
公開: 2018-03-01ビーバービルダー製品が 25% オフ!セールは終了です...もっと詳しく!
WP Engine の友人たちは最近、Beaver Builder で構築された美しい新しいホームページを公開しました。私たちはこのページへのリンクを Beaver Builders Facebook グループで共有しましたが、ページの全体的な読み込み時間が非常に長いと何人かの人々が指摘しました。私たちの良き友人であり、並外れた WordPress 開発者である Jon Brown が、素晴らしい説明をして助けてくれました。
ここでの会話を簡単に言い換えてみましょう。
心配している Beaver Builder: XYZ テスト ツールを使用してページの読み込みテストを行ったところ、読み込みにほぼ 10 秒かかりました。
Jon:速度とパフォーマンスは設計上の選択であり、販売変換にとって重要ですが、それが他のより価値のあるツールとのトレードオフではないという意味ではありません。
ウォーターフォールを理解せずに、文字のグレードや合計ロード時間を確認している人をよく見かけます。非常に単純なサイトを見ている場合を除いて、これはあなたを迷わせるでしょう...
これらのテストツールのグレードは非常に大雑把で、多くの現実を無視しています。彼らは、広告、トラッキングスクリプト、その他必然的にリダイレクトが機能するものについては、リダイレクトを避けるべきだと言うでしょう。彼らはしばしば HTTP/2 を無視し、リクエストを減らし、重要ではない、あるいは害を及ぼす可能性さえあるアセットを連結することを推奨します。速度インデックスやスクロールせずに見える部分のレンダリングには焦点を当てていません…
実際のページ読み込みは 1.5 秒未満です
私はジョンに、パフォーマンスのテーマについてもう少し質問してもいいかと尋ねたところ、彼は非常に快く同意してくれました。これらは私 (ロビー) の質問とジョンの答えです。
ああ、Jon は 9seeds というカスタム開発ショップを経営しているので、WordPress ウェブサイトのパフォーマンスを微調整するために彼を雇うことができると言いましたね。
ウェブサイトのパフォーマンスを評価するツールはたくさんあります。これらの多くは、わかりやすい成績評価を含むレポートを提供します。ただし、これらのレターグレードは非常に率直なツールであり、すべての As を取得できれば良いのですが、ストレートな As が表示されない場合は、特に洞察力がありませんし、ましてや役に立ちません。私が役に立つと思う唯一の文字グレードは画像圧縮です。これは簡単に修正できます。オプティマイザを通して画像を実行してください。
素人や初心者の開発者が文字に目がくらんでしまうのをよく見かけます。フロントエンド Web のパフォーマンスには多くの要素が関係しますが、実際には「ウォーターフォール」に注目する必要があります。これは、すべての HTTP リクエスト、開始時と完了時を示す単なるグラフです。これらを生成するには WebPageTest.org を使用します。
「ウォーターフォール」は、ロードに時間がかかりすぎている、または他のもののロードを妨げている特定のアセットが何であるかを「確認」する場所です。
最後に、ストレート A には、デザインの選択 (スライダーの削除など) や、サイト所有者にとって A を取得するよりも価値のあるサードパーティの資産 (Google Analytics、HotJar など) の削除が必要になる場合があることを認識してください。すべてのサイトが A を取得できるわけではありません。痛みを伴う犠牲を払わずに真っ直ぐになります。
個人的には、これらを行う上で WebPageTest.org ほど優れていて柔軟なものを見つけたことがありません。ただし、私は過去に GTMetrix、Pingdom、Google Page Speed なども使用したことがありますが、それらはまったく問題ありません。 Lighthouse のような新しいもののいくつかは、プログレッシブ Web アプリ (WordPress サイトの 99% ではありません) にとって非常に優れています。ただし、私は人々にツールを切り替えるように言っているわけではありません。自分が知っていて理解しているツールを使用してください。どのツールも知らない場合は、WPT を無料で使用して学習するのが最適です。レターグレードを超えて、そのレターグレードの原因を理解し始めてください。
ほとんどのサイトが HTTPS ではなく HTTP であり、Web サーバーがすべて HTTP/1.1 プロトコルを使用していた頃、Web サーバーは非常に多くのアセットしか並行して送信できませんでした。各アセット (画像、スクリプト、スタイルシート) は個別に送信され、それぞれに独自のオーバーヘッドがあり、処理速度が低下しました。可能なすべてを連結することで HTTP リクエストの数が減り、パフォーマンスが大幅に向上しました。
ここ数年、あらゆる場所で HTTPS への動きが大きく進み、Web サーバーは新しい HTTP/2 プロトコルのサポートを開始しました。 HTTP/2 には、プリフェッチやプリロードなどの大きな利点があるだけでなく、これらの小さなアセットをすべて並行して送信できるため、それらを連結する必要がありません。実際、各小さなアセットを個別にキャッシュできるようにするためには、そうしないほうがよい場合もあります。
これは、Web サーバーが HTTP/2 をサポートしている場合にのみ有効であり、サイトが HTTPS である場合にのみ可能であることに留意することが重要です。
とはいえ、私たちが最近取り組んでいるすべてのサイトは HTTPS であり、HTTP/2 対応サーバー上で実行されているため、アセットの連結についてはもう考えていない段階にあり、もちろんそれを見逃すことはありません。
最も大きな点は、デザインの変更や管理していないサードパーティの資産の削除などの痛みを伴う譲歩をせずに、すべてのサイトが正しくなることができるということです。ただし、Speed Index と呼ばれるものを調べ始める必要があるため、それはまったく問題ありません。 WPT にはこれについて詳しく書かれていますが、基本的には「アバブ・ザ・フォールド」がユーザーによって完全に読み込まれていると認識されるタイミングを考慮しています。ページが完全に完成しているかどうかではなく、ユーザー エクスペリエンスのスピードが重要です。これは WP Engine の新しいフロント ページ デザインに関するもので、速度指数は素晴らしかったです。遅延スクリプトの読み込みと完了に時間がかかっていました。
私が長年にわたって頼りにしているツール:
プラグイン:
ジョン、パフォーマンスに対するより現代的なアプローチについて説明するために時間を割いていただきありがとうございます。ジョンの代理店である9seedsに最後の力を貸したいと思いました。カスタム WordPress 開発に関するサポートをお探しの場合は、大声でお知らせください。
WP ロケットのリンクにダッシュがありません。