ワードプレス

WordPress HTTP/2のパフォーマンス：自動的に速くならない理由

ワードプレス HTTP/2 しかし、古い最適化や間違ったサーバー設定は、しばしばその効果を鈍らせる。多重化、ヘッダー圧縮、サーバープッシュがどのような効果をもたらすのか、そしてなぜそのような効果が顕著なのかを説明する。 パフォーマンス 適切なWordPressとサーバー設定のみが付属しています。.

中心点

多重化 は多くの接続を置き換え、並列にファイルをロードする。.
連結と過剰な最小化は、HTTP/2ではしばしば障害となる。.
サーバー・プッシュ 具体的に設定され、測定された場合にのみ役立つ。.
TLSハンドシェイク コストがかかるが、優れたサーバー設定がこれを補う。.
シーディーエヌ とクリーンな資産は、純粋なプロトコルの変更よりも明らかに優れている。.

HTTP/2でWordPressは何が変わるのか

私は以下の利点を活用している。 多重化, HTTP/2は、1つのTCPコネクション上で多数の小さなCSS、JS、画像ファイルを並列にロードします。HTTP/2は、HPACKヘッダー圧縮によってオーバーヘッドを削減し、バイナリ形式でデータを送信するため、エラーを最小限に抑え、パケットをより効率的にします。これにより、多くの接続を開く必要がなくなり、ブラウザの待ち時間とCPU負荷が軽減されます。HTTP/1.1との違いを理解したい場合は、比較を見てください。多重化とHTTP/1.1の比較そして、それに基づいて資産戦略を立案する。. サーバー・プッシュ も初期リソースのトリガーになり得るが、私は的を絞って使い、効果を測定している。.

HTTP/2が自動的に高速化しない理由

ファイルの強力なマージといったHTTP/1.xの古いトリックは、HTTP/2ではしばしばパフォーマンスを悪化させる。 ファースト・ペイント. .多くのテーマは、すべてを1つの大きなファイルにバンドルしているため、ブラウザのレンダリング開始が遅くなってしまいます。テストでは、最大85 %という劇的な向上が見られますが、これはサーバー、アセット、キャッシュが連動している場合に限られます。無駄のないサイトや弱いサーバーでは、効果は小さく、0.5秒しか表示されないこともあります。 時間対インタラクティブ-利益。間違ったプラグインをロードしたり、非圧縮画像を使用したり、遅いデータベースクエリを使用したりすると、HTTP/2はあなたの速度を低下させます。.

HTTP/1.xの典型的な最適化により、処理速度が低下している。

大げさな表現は避ける連結, なぜなら、大きなJSファイルは、細かい粒度のパースやキャッシュをブロックしてしまうからです。モジュールは、ページが本当に必要とするものだけを別々に配信するほうがいい。HTTP/2はすでに圧縮によって多くのバイトを節約しているため、過剰な最小化はあまり意味がない。ドメイン・シャーディングは、多重化された単一接続が最高の利用率を提供するので、テストにかけるべきだ。また、WebPのような最新のフォーマットとHTTP/2を併用することで、より効率的にリクエストとバイトを処理できるため、古いCSSスプライトを再検討している。 キャッシュ・ヒット率 を向上させる。.

サーバーの設定とTLS: 先手を打つ方法

HTTP/2はHTTPSを必要とするので、最適化する。 TLS 1.3, ALPNを有効にし、OCSPステープリングでハンドシェイクを短くする。Gzipの代わりにBrotliを使い、Keep-Aliveを調整し、NginxやApacheをh2パラメータできれいにセットアップする。PHP-FPMの設定が弱かったり、ワーカーが少なすぎたりすると、最初のバイトが流れるまでに時間がかかる。サーバーレベルでのキャッシュ - FastCGI、Object Cache、OpCache - は、バックエンドの負荷を著しく軽減します。これらのステップは、どのプロトコルのオプションよりも効果があり、認識される負荷を安定させることがよくあります。 応答時間.

HTTP/2下でのWordPressの資産戦略

wp_enqueueでスタイルとスクリプトをモジュール方式でロードし、次のように設定します。 持ち越す または、クリティカルでないJSファイルにはasyncを使用します。アバブ・ザ・フォールド用のクリティカルなCSSは、最初のコンテントフル・ペイントを短縮し、残りのCSSは後でロードする。モンスター・バンドルの代わりに、コンポーネントを賢く分割して、キャッシュと並列化が有効になるようにしている。画像は最新のフォーマットと適切な品質で最適化し、遅延ローディングでスタートページの無駄を省きます。オーバーヘッドを減らすために、私は試行錯誤を重ねた次のようなヒントを使用しています。 HTTPリクエストを減らす, そのため、HTTP/2の長所を明かすことなく ペイロード 小さい。

サーバー・プッシュのターゲット利用

私は、すべてのサイトが本当にすぐに必要とするファイル、例えば小さな クリティカルCSS-ファイルや重要なプリロードスクリプトをプッシュしません。大きな画像やめったに使わないモジュールは、帯域幅を圧迫し、キャッシュを混乱させる可能性があるので、プッシュしない。WordPressでは、リンクヘッダや適切なプラグインを使ってPushをリンクしますが、ブラウザの読み込みが十分速いかどうかはとにかくチェックします。ウェブツールを使って、プッシュがLCPを改善するのか、プリロードヘッダーで十分なのかを測定する。主要な数値が停滞している場合は、プッシュを再びオフにし、LCPを維持する。 パイプライン 無料だ。

CDN、キャッシュ、レイテンシー - 何が本当に重要か

静的アセットを シーディーエヌ HTTP/2をサポートし、ユーザーの近くに存在する。より短いパスはRTTを減らし、エッジキャッシュはオリジンの負荷を減らす。賢明なキャッシュコントロールヘッダー、ETags、ハッシュ化されたファイル名により、私はクリーンな再検証の決定を行う。DNSルックアップを最小限に抑え、不必要なCORSプリフライトを防ぎます。WordPress用のクリーンなオブジェクトキャッシュとともに、HTTP/2の効果は顕著に増大し、HTTP/2を強化する。 ローディング時間.

優先順位付けとリソースのヒントを的確に利用する

HTTP/2はサーバー側でストリームが流れる順番を決めるが、私はブラウザに明確なシグナルを与える。私は プリロード クリティカルなCSSとLCPイメージのために、, プリコネクト やむを得ない第三者のドメインと dns-プリフェッチ だけ注意してください。フォントには次のものを使っている。 フォント表示：スワップ プリロードは、見えないテキストのフラッシュを避けるために役立ちます。WordPress 6.x以降では、属性 フェッチプライオリティ 重要なリソースを優先し、重要でないリソースを削減する。.

私はここで2つのルールに従っている：即座にレンダリングされるものだけをプリロードすることと、優先順位付けが効果的かどうかを測定することだ。広すぎるプリロードは、特にモバイルネットワークではパイプラインを詰まらせる。.

// LCP-Bild priorisieren und nicht lazy-loaden
add_filter('wp_get_attachment_image_attributes', function ($attr, $attachment, $size) {
    if (is_front_page() && !empty($attr['class']) && strpos($attr['class'], 'hero') !== false) {
        $attr['fetchpriority'] = 'high';
        $attr['decoding'] = 'async';
        $attr['loading'] = 'eager';
    }
    return $attr;
}, 10, 3);

// Preconnect/Preload-Hints gezielt setzen
add_filter('wp_resource_hints', function ($hints, $relation_type) {
    if ('preconnect' === $relation_type) {
        $hints[] = 'https://cdn.example.com';
    }
    return array_unique($hints);
}, 10, 2);

スタイルについては、HTMLのたびに新たに転送される大きなインライン・ブロックの代わりに、小さなアウトソースされたCSSファイル（簡単にキャッシュできる）を使っている。ファイルをあらかじめロードしておき、残りのCSSチャンクは非同期でリロードさせる。 エフシーピー そして LCP は小さく、HTTP/2の長所を尊重している。.

WordPress資産の実際：クリーンな分割、スマートな読み込み

スクリプトを依存関係とともにモジュール方式で登録し、実行は 持ち越す/非同期。サードパーティのスクリプト、アナリティクス、マップは非同期で実行され、レンダリングに重要な要素は無駄がありません。.

// ハンドルに応じて defer/async を設定する
add_filter('script_loader_tag', function ($tag, $handle, $src) { }.
    $async = ['analytics', 'maps']；
    $defer = ['theme-vendor', 'theme-main']；

    if (in_array($handle, $async, true)) {
        return str_replace('<script ', '<script async ', $tag)；
    }
    if (in_array($handle, $defer, true)) { { return str_place('<script ', '<script async ', $tag'); }.
        return str_replace('<script ', '<script defer ', $tag)；
    }
    return $tag；
}, 10, 3);

// 非対象ページで余計なプラグインアセットを切断する
add_action('wp_enqueue_scripts', function () { )
    if (!is_page('contact')){
        wp_dequeue_script('contact-form-7')；
        wp_dequeue_style('contact-form-7')；
    }
}, 100);

私は、大きなJSバンドルを意味のある塊（ヘッダー、フッター、コンポーネント）に分割し、ツリーシェイク可能なビルドを使用している。HTTP/2では、依存関係が明確でキャッシュが機能する限り、複数の小さなファイルを配信しても問題ない。CSSについては、テンプレート／コンポーネントごとにモジュール化されたファイルに頼っている。こうすることで、デバッグが容易になり、再利用が効率的になる。.

フォントは最小限にしています。カット数は少なく、可変フォントは本当に必要な場合のみです。画像の幅と高さには細心の注意を払っている。 CLS WordPressのレスポンシブ画像は、適切なものを使用しましょう。 ソースセット-デバイスが必要以上のバイトをロードしないようにする。.

今日のサーバープッシュ：プリロードとアーリーヒント

多くのブラウザが HTTP/2サーバープッシュ そのため、私は一貫してプリロード・ヘッダーを供給し、利用可能な場合はそれを使用している。そのため、私は一貫してプリロード・ヘッダーを提供し、利用可能な場合はそれを使用している、, 103 初期のヒント, 最終的なレスポンスの前に、重要なリソースをアナウンスする。これはより安定的に機能し、キャッシュとの衝突も少ない。.

# Nginxの例: HTTP/2、TLS 1.3、Brotli、アーリーヒント
サーバ
    listen 443 ssl http2；
    ssl_protocols TLSv1.3；
    ssl_early_data on；
    add_header Link "; rel=preload; as=style" always；

    brotli on；
    brotli_comp_level 5；
    brotli_types text/css application/javascript application/json image/svg+xml；
}

私は、ブラウザがとにかく動くものや、レイトレンダリングとみなされるものはプッシュしない。ターゲットを絞ったプッシュ（または早めのヒント）をしても、次のような測定可能なゲインが得られない場合は、プッシュしない。 LCP 私はそれを再び削除し、優先順位付けはブラウザに任せた。.

バックエンドのパフォーマンス：PHP-FPM、オブジェクトキャッシュ、データベース

HTTP/2は遅いバックエンドを隠さない。私は ピーエッチピーエフピーエム クリーン（pmダイナミック、有意義 pm.max_children, スワップなし）、アクティブにする オプキャッシュ 十分なメモリを持つA 永続オブジェクトキャッシュ (Redis/Memcached)を使うことで、定期的なリクエストがほとんどデータベースにヒットしないようにしている。データベースでは、wp_postmetaとwp_optionsのインデックスに注意を払い、オートロードのバラストを減らし、cronジョブを整理しています。.

; PHP-FPM (抜粋)
pm = 動的
pm.max_children = 20
pm.max_requests = 500
リクエスト終了タイムアウト = 60s

私は定期的に負荷がかかった状態でTTFBをチェックしています。最初のバイトに時間がかかりすぎる場合は、PHPワーカーが少なすぎるか、キャッシュヒットがないか、WPクエリが遅いことが原因であることが多い。クエリ分析、オートロードオプション>>1-2MB、ブレーキがかかっていないREST/admin-ajaxコールが典型的なブレーキです。APIレスポンスがほとんど変更されない場合は、積極的にキャッシュしています。.

Eコマースと動的ページ：落とし穴のないキャッシュ

ショップ（例：WooCommerce）の場合は、フルページキャッシュに加えて、次のような方法で作業しています。 戦略を変える 関連するクッキーについて。私は買い物カゴとチェックアウトのページをキャッシュから除外し、不要な場所ではカートのフラグメントを非アクティブにします。一方、商品リストとCMSページは、エッジで非常にうまくキャッシュすることができます。HTTP/2は、HTMLがキャッシュからすぐに来る間に、多くの小さなアセットを並行して配信します。.

私はフラグメント・キャッシング（ESIまたはサーバーサイド・パーシャル）を使って、静的なページに動的なブロックを組み込んでいます。これにより、パーソナライズを失うことなくTTFBを低く保つことができます。国や通貨の変更については、短いキャッシュキーとコンパクトな HTML を使って、キャッシュされるバリアントの数が爆発的に増えないようにしています。.

CDNユニット：合体、ホスト名、ヘッダー

実益がないのであれば、追加のホスト名は避ける。HTTP/2では、ブラウザは コネクションのマージ (証明書、IP、TLSパラメーターが一致する場合、コネクション合体） - TCPとTLSのセットアップ回数を最小限に抑えることができます。私は不変そして 有効期限切れ をCache-Controlに追加することで、クライアントがキャッシュからアセットをより長く取得し、新鮮さを保てるようになります。.

EdgeとOriginでは、二重エンコーディングがないように、一貫したBrotli圧縮に注意しています。欠落可変-ヘッダーオン Accept-Encoding あるいは過剰なCORSポリシーは、プリフライト・リクエストを生成し、HTTP/2の強みを打ち消す可能性がある。.

測定戦略：ラボとフィールド、主要数値を正確に読み取る

そのほか TTFB、FCP、LCP 私は観察する CLS (レイアウトシフト）と インピー (インタラクションの待ち時間）。CLS/INPの悪い値は、プロトコルではなく、アセット、フォント、JSの負荷を示していることが多い。私は常にスロットリングでモバイルを測定し、コールドキャッシュとウォームキャッシュを比較し、テスト条件を再現可能なものにしています。.

Waterfallsを読みました：CSSを早期に開始し、大きなJSをブロックする。
DevToolsで優先順位をチェックしています：プリロードは尊重されているか、fetchpriorityは有効か？
私はオリジンとエッジのヒットレートを区別している：短いHTMLレスポンスと多くの小さなアセットは、HTTP/2の下では問題ない-両方のキャッシュが整っていれば。.

代表的な測定値とその意味

私がTTFB、FCP、LCPを注視しているのは、これらの比率が現実を反映しているからだ。知覚を反映させる。HTTP/2は小さなファイルをいくつも読み込むので、純粋な „requests down “ターゲットは結果を歪める。どのリソースがレンダリングをブロックし、どのリソースが遅れてロードされるのか？再現可能な測定環境（コールドキャッシュとウォームキャッシュ、モバイルとデスクトップ）がなければ、数値はすぐに間違った方向に向かいます。これらのサンプル値は、典型的な効果を示しており、より細かいチューニングの出発点として役立っている。 透明性:

キーパーソン	切り替え前	HTTP/2 + チューニング後
TTFB	450ミリ秒	280ミリ秒
エフシーピー	1,8 s	1,2 s
LCP	3,2 s	2,3 s
お問い合わせ	92	104（より良い並列化）
転送データ	1,9 MB	1.6 MB

HTTP/2の限界とHTTP/3の展望

のHTTP/2ヘッドオブライン・ブロッキングを忘れているわけではない。 TCP-レベルは完全には防げない。これは、プロトコルが並列化されているにもかかわらず、パケットロスで困難なネットワーク上で物事を遅くする可能性があります。QUICを持つHTTP/3は、UDPに依存し、ストリームを別々に扱うため、この問題を回避できる。より深く比較したいのであれば、以下の私の概要を読んでほしい。 HTTP/3とHTTP/2の比較そして、アップグレードが理にかなっているかどうかをチェックする。多くのサイトにとって、HTTP/2はすでに強力な利益をもたらしている。 クイック オープン

ホスト選び：私が気をつけていること

私は次のことに注意を払っている。 ホスティング WordPressでは、クリーンなHTTP/2の実装、TLS 1.3、Brotli、高速NVMeストレージが必要です。優れたプロバイダーは、最適化されたPHPワーカー、オブジェクトキャッシュ、エッジ機能を提供する。比較では、WordPressを最適化したプラットフォームは、レイテンシーとTTFBを低く抑えられるため、明らかに優位に立つことが多い。テスト勝者の概要では、HTTP/2を強力にサポートするwebhoster.deが、WordPressプロトコルの速度で良好な結果を示しています。この短い表は、コアを要約し、私が明確な決定を下すことを容易にします。 チョイス:

ホスティングプロバイダー	HTTP/2のサポート	ワードプレスの最適化	場所
webhoster.de	完全	素晴らしい	1

簡単にまとめると

HTTP/2は強力な基盤だと私は見ているが、スピードは巧みな技術によってのみ生み出されるものだ。 優先順位モジュール化されたアセット、優れたキャッシュ、クリーンなTLSとサーバー設定。私は古いHTTP/1.xのトリックを整理し、分割、プリロード、考慮されたプッシュに置き換えます。適切なCDN、最適化された画像、信頼性の高いキャッシュヘッダにより、FCPやLCPなどの主要な数値が大幅に向上します。HTTP/2、TLS 1.3、Brotliを備えた堅牢なホストは、TTFBの短縮と安定したレスポンスタイムを実現します。このようにWordPressを整列させると、次のような効果が得られます。 ワードプレスhttp2のパフォーマンス 単なる新しいプロトコルラインではなく、真の利点がある。.