質問やフィードバックがありましたら、フォームからお願いします
本文は台湾華語で、ChatGPT で翻訳している記事なので、不確かな部分や間違いがあるかもしれません。ご了承ください
前書き
Web Vitalsは、Googleが提唱したプロジェクトで、主な目的はウェブサイトのパフォーマンスを定量化するためのさまざまなメトリクスを提供することです。以前、Google Chrome Developerチャンネルで台湾語を使ってCore Web Vitalsについての動画が紹介されており、非常に興味深い例が挙げられているので、ぜひ参考にしてください ↓
現在、多くのウェブサイトではWeb Vitalsを測定するプロセスが導入されており、定量的指標を通じて改善すべき点を見つけ出しています。開発者がWeb Vitalsを測定するために役立つツールも多く存在します。例えば:
- Lighthouse
- PageSpeed Insights
- CrUX
- Search Console
SentryのWeb Vitals統計機能
しかし、あまり知られていないのは、実はSentryも以前にWeb Vitalsの統計機能を提供していることです1。これにより、LCP、FP、CLSなどのWeb Vitalsの各指標を統計的に記録することができ、開発者はバックエンドで関連するグラフを見ることができ、さらには平均値も表示されるため、非常に便利です。
ただし、Sentryのデータは30日間しか保存されず、比較機能がないため、先週のメトリクスと今週のメトリクスを比較することができません。グラフはSentry上でのみ確認できるため、他のチームにとっては切り替えコストがかかります。開発者としては、このプロセスを自動化したくなるのが自然です。
調べてみると、SentryはAPI連携を提供しています(トークンがあれば)が、Web VitalsのAPIドキュメントは提供されていないようです。しかし、コンソールを開いてみると、グラフの生成もAPIを使って行われていることが分かりました。APIのエンドポイントとパラメーターをそのままコピーしてCURLで呼び出したところ、うまくいきました!どうやら、ただ文書には記載されていなかっただけのようです。
主要なAPIは二つあります:(ドキュメントがないため、パラメーターやパスが変更される可能性もあります)
/events-measurements-histogram/?...
/eventsv2
自動化プロセスの設計
データが手に入ったので、Slackに統合して定期的に追跡し、他のチームのメンバーとも簡単に共有できるようにします。詳細な情報が必要な場合は、Sentryのバックエンドで確認できます。全体のプロセスは以下の通りです:
Cronjobを使ってAPIを呼び出し(またはサーバーレスとして実装することも可能)、Sentryからデータを取得した後、アップロードしてレポートを生成します。
特に注意が必要なのは、クエリパラメーターに+
が存在する場合です。これを直接encodeURIComponent
に送ると、%2B
に変換され、Sentry側でエラーが発生します。そのため、+
を特別に取り出すか、エンコードされないように工夫する必要があります。
例えば、APIのクエリパラメーターは以下のようになります:field=percentile(measurements.fp%2C+0.75)&field=percentile(measurements.fcp%2C+0.75)&...
。呼び出し関数のように、返されるデータを定義することができます。例えば、percentile(measurements.fp,+0.75)
は75パーセンタイルのFPデータを返します(単位はミリ秒のはずです)。,
は%2C
にエンコードされていますが、+
の部分はエンコードされていないことがわかります。クエリパラメーターを作成する際にエラーがあった場合、この部分から手掛かりを得ることができます。
返されるデータ型は以下のようになります:
{
"path": "/my-page",
"data": [
{
"count": 10,
"bin": 2000
},
...
]
}
次は、.json
を生成してS3にアップロードするか、他のストレージに保存します。これで昨日(または以前のデータ)と比較できるようになり、レポートをSlackに送信することができます:
さらに、グラフを生成したい場合は、Node.jsでchart.jsやchartjs-node-canvasを使用して実装することができます。これにより、ブラウザ(canvas)を使用せずにグラフを描画できます。ただし、サーバー上に対応するフォントがインストールされていない場合、レイアウトが崩れたり、フォントが変わってしまう可能性があるため注意が必要です。
Cronjobの選択に関しては、現在多くの成熟したソリューションが存在します。ハードコーディングしてサーバーを立て、crontabに書き込むことも可能ですが、ここではdrone CIのcronjob機能を利用して実装しました。主な理由は、droneの設定ファイルが非常に便利で、社内に専用のdrone CIサーバーがあるため、外部サービスを安易に使用できないことから、最も簡単な方法としてdrone CIを統合し、設定を容易にすることです。
ただし、なぜかcronイベントがトリガーされるたびに、他のパイプラインも同時にトリガーされてしまうため、後に追加のブランチを開いて.yaml
を修正してAPIを呼び出す方法に変更しました:
steps:
- name: upload and report
image: byrnedo/alpine-curl
commands:
- curl -X POST YOUR_SERVER_ENDPOINT
これで自動化の実装が完了しました。現在、毎日レポートがSlackに送信されており、開発者にとっても変化やフィードバックをより簡単に確認できるようになりました。
Footnotes
この記事が役に立ったと思ったら、下のリンクからコーヒーを奢ってくれると嬉しいです ☕ 私の普通の一日が輝かしいものになります ✨
☕Buy me a coffee