Core/Dashディメンション: Query String

ページネーションされた結果からUTMタグ付きのランディングページまで、URLパラメータが実際のユーザーのパフォーマンスデータに与える影響を確認できます。

無料トライアル

Trusted by market leaders · Client results

aleteiaharvardmy work featured on web.devworkivaperionvpnebaymonarchsaturnsnvdpg mediafotocasakpnmarktplaatserasmusmcnestleloopearplugshappyhorizonadevintawhowhatwearcomparenina care

Query Stringディメンションの計測対象

Query Stringディメンションは、ページ訪問時にURLに存在する完全なクエリ文字列ごとにCore Web Vitalsデータをグループ化します。これには、?以降のすべてが含まれます。たとえば、utm_source=googleのようなトラッキングパラメータ、page=2のようなページネーション、sort=priceのようなソート順、q=running+shoesのような検索クエリ、A/Bテストのパターン、フィルターの組み合わせなどです。

多くのパフォーマンス監視ツールは、クエリ文字列を除去するか、単一のURLグループに集約します。CoreDashはこれらをそのまま保持するため、同じページテンプレート、同じユーザー、同じ期間において、/products?sort=priceと/products?sort=popularityのLCP、INP、CLSを比較できます。

coredash query string table

クエリ文字列がパフォーマンス悪化の原因となる理由

クエリパラメータは、原因不明のパフォーマンスのばらつきを引き起こす最も一般的な要因の一つです。重要である理由は以下の通りです。

CDNのキャッシュ挙動

デフォルトでは、ほとんどのCDNは異なるクエリ文字列を持つURLを個別のキャッシュエントリとして扱います。/search?q=boots と /search?q=sandals は、2つの異なるキャッシュキーになります。検索結果ページで1時間あたり数百のユニークなクエリが発生する場合、それらのリクエストはキャッシュからほとんど配信されません。すべての訪問者が、キャッシュのないコールド状態でオリジンサーバーにアクセスすることになります。

一部のCDNでは、キャッシュキー内で特定のパラメータ（UTMタグなど）を無視できますが、この設定は見落とされがちです。キャッシュキーに utm_source=email が含まれていると、メールキャンペーンのランディングページのキャッシュヒット率はほぼゼロになり、すべての受信者がキャッシュされたレスポンスではなく、完全なサーバーレンダリングを受けることになります。これはよくある測定可能なLCPの急増原因です。

サーバーサイドレンダリングのコスト

フィルターやソートのパラメータは、ページ内で最も負荷の高いデータベースクエリを発生させることがよくあります。通常の /products の商品一覧は完全にキャッシュされている可能性があります。しかし、同じページでも /products?color=red&size=M&brand=Nike&sort=price-asc では、複雑なクエリや異なるレスポンス形式、さらには完全な再レンダリングが必要になる場合があります。フィルター結果を効率的にキャッシュできないページでは、Time to First Byteが増加し、それに伴ってLCPも増加します。

ページネーションも、常に問題となる要素です。一覧の1ページ目は、デフォルトの表示であり積極的にキャッシュされるため、通常は高速です。しかし、10ページ目や50ページ目はキャッシュされることがほとんどなく、生成に時間がかかる上に、テストすらされていないことが多々あります。CoreDashはこれらの違いを直接可視化するため、推測に頼る必要はありません。

パラメータによって引き起こされるクライアントサイドの挙動

一部のクエリパラメータはサーバーのレスポンスを変更しませんが、読み込み時に実行されるJavaScriptの動作を変化させます。A/Bテストのパターンパラメータ、アフィリエイト追跡コード、紹介トークンなどは、スクリプトによって頻繁に読み取られます。これらのスクリプトは、異なるUIフローを初期化したり、追加のネットワークリクエストを発生させたり、テスト設定の待機中にレンダリングを遅延させたりします。これらのパラメータは、測定可能なINPコストを増加させ、パターンが初期ペイント後に表示コンテンツを変更する場合は、場合によってはレイアウトシフトを引き起こすことがあります。

調査すべき一般的なパターン

  • 有料トラフィックにおけるUTMパラメータ: 広告からの訪問者は、多くの場合 ?utm_source=google&utm_medium=cpc&utm_campaign=... のようなURLでアクセスします。CDNがこれらをキャッシュキーに含めている場合、有料トラフィックのレスポンスはオーガニックトラフィックよりも一貫して遅くなります。
  • 検索結果ページ: 短く一般的なクエリはキャッシュされる可能性がありますが、ロングテールクエリや新規クエリはほとんどキャッシュされません。?q=nike と ?q=blue+trail+running+shoes+mens+size+11 を比較すると、多くの場合、測定可能なLCPの差が現れます。
  • 複雑なフィルターの組み合わせ: 複数のフィルターが適用されたEコマースのカテゴリページは、レンダリングの負荷が高く、キャッシュされることも稀です。75パーセンタイルのLCPが高い場合、フィルターの組み合わせが原因である可能性が高くなります。
  • 2ページ目以降のページネーション: 2ページ目以降は通常、動作が遅く、より多くのリソースを消費します。また、同じヒーロー画像やレイアウトを含んでいることが多いですが、以前の訪問によるキャッシュされたアセットの恩恵を受けられません。

CoreDashでの本ディメンションの使用方法

任意のCoreDashレポートのディメンション選択ツールから Query String を選択します。テーブルには、ユニークなクエリ文字列ごとにLCP、INP、CLS、および訪問数が表示されます。LCPでソートして最も遅いパラメータの組み合わせを特定するか、訪問数でソートして最もトラフィックの多いパターンを特定します。

このディメンションを URL ディメンションと組み合わせることで、クエリ文字列 of the patterns... を比較する前に、分析対象を単一のページテンプレートに絞り込むことができます。この組み合わせにより、パフォーマンスの問題がページ自体にあるのか、それとも特定のパラメータパターンにあるのかを簡単に確認できます。

Query Stringディメンションは、CoreDashの Page & Navigation カテゴリに属しており、URL、Pathname、Navigation Typeなどのディメンションと同じカテゴリに分類されます。