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

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を比較できます。

クエリ文字列がパフォーマンスの低下を引き起こす理由

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

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=...とともに着地します。CDNがこれらをキャッシュキーに含めている場合、有料トラフィックはオーガニックトラフィックよりも一貫して遅いレスポンスを受け取ります。
• 検索結果ページ: 短くて人気のあるクエリはキャッシュされる可能性があります。ロングテールや初めてのクエリはほとんどキャッシュされません。?q=nikeと?q=blue+trail+running+shoes+mens+size+11を比較すると、測定可能なLCPの違いがしばしば見られます。
• 重いフィルタの組み合わせ: 複数のアクティブなフィルタを持つEコマースのカテゴリページは、レンダリングコストが高く、めったにキャッシュされません。75パーセンタイルのLCPが高い場合、フィルタの組み合わせが原因である可能性が高いです。
• ページ1以降のページネーション: ページ2以降は通常、より遅く、よりリソースを消費します。また、それらはしばしば同じヒーロー画像やレイアウトを含みますが、前回の訪問からのキャッシュされたアセットの恩恵を受けません。

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

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

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

Query Stringディメンションは、CoreDashのPage & Navigationカテゴリに属し、URL、Pathname、およびNavigation Typeなどのディメンションと並んでいます。