チームに加わり、サイトを高速化します

サイトの取引規模によって異なります。Loop Earplugsの事例では、モバイルの表示速度が約800ms高速化し、購入のコンバージョン率が7%向上しました。7%の改善を無条件でお約束することはできませんが、RUMで各修正が指標に与えた影響を、アナリティクスでそれが売上に与えた影響を確認できます。どちらのデータも把握可能です。

わずかに影響します。Core Web Vitalsはランキング要因の1つですが、影響度は大きくありません。最も重要なのは関連性の高いコンテンツであり、表示速度は競合ページと内容が拮抗している場合の決定打にすぎません。より大きな成果はクリックの後に現れます。高速なサイトは訪問者の離脱を減らし、残ったユーザーのコンバージョン率を高めます。これはGoogleの検索順位が上がるかどうかにかかわらず、売上に直結します。

自前の開発チームを持ち、一定規模のトラフィックがあり、表示速度が売上に影響する企業向けです。主にEコマース、クリック時の動作が遅いSaaSアプリ、広告を多く掲載するメディアサイトが該当します。自社に開発者がおらず、制作会社などの支援もない場合は、詳細監査や単発の修正から始める方が適しています。

保証はいたしません。サイトを見る前からスコアを保証する業者がいれば、それは当てずっぽうにすぎません。私が目指すのは、売上に直結するページで、75パーセンタイル基準でのCore Web Vitals合格を達成することです。それこそがGoogleの計測対象であり、訪問者が実際に体感する基準です。

多くの制作会社は幅広い業務を手がけており、パフォーマンスはその項目の1つにすぎません。一方、私はパフォーマンス改善だけを専門にしています。Next.jsのハイドレーション、メディアサイトに散らばる大量のサードパーティスクリプト、読み込み時にレイアウトを崩す広告など、難易度の高い課題がチェックリストに載っていることはまずありません。誰にでも得意分野があります。これが私の専門です。

はい、コンサルティングに含まれています。すでに導入済みのRUMで、どの要素やスクリプトが遅延の原因かを特定できるのであれば、そちらをそのまま活用することも可能です。

ほぼすべてに対応しています。Next.js、Nuxt、Magento、Salesforce Commerce Cloud、Shopify、WordPress、あるいは2012年に作られたPHPサイトでも問題ありません。ブラウザにとって、何を使ってページが生成されたかは関係ありません。そして、私が作業する場所はブラウザです。Shopifyのようなプラットフォーム自体は変更できなくても、テーマや導入したアプリ、追加スクリプトは自由に改修できますし、問題の大半はそこにあります。

そのスコアはLighthouseによる数値です。低スペックなスマートフォンをシミュレートした1回のlab dataにすぎません。Googleが重視するのはfield data、つまり実際の訪問者が体験する75パーセンタイルの数値であり、私が対象とするのもそれです。改善を進めればLighthouseのスコアも自然と上がりますが、その数値を追いかけることはしません。スコアが95点でもCore Web Vitalsに不合格のサイトはありますし、その逆も珍しくありません。

ユーザーがクリックした際にmain threadで何が実行されているかを特定します。Long Animation Frames (LoAF) APIを使えば、どのスクリプトのどの関数が負荷になっているかを特定できます。あとはその処理を分割するか、実行のタイミングをずらすか、あるいは完全に削除します。

ほぼありません。大半の場合、原因はいくつかの重いコンポーネント、スクリプトの読み込み順、あるいはページのハイドレーション処理にあります。これらをピンポイントで修正する方が、全面刷新よりもはるかにコストを抑えられ、成果が出るのも圧倒的に早いです。

RUMを導入していない場合や、お使いのツールではどの要素やスクリプトがボトルネックなのか分からない場合は、CoreDashを導入します。まさにこの課題のために設計されたツールです。LCP、INP、CLSの発生ごとに、原因となった要素、スクリプト、リソースを具体的に特定します。Googleの28日間の移動平均が更新されるのを待つことなく、修正が実際の訪問者に与えた影響を翌日には確認できます。計測するURLの数やデータの保持期間にも上限はありません。

はい、問題ありません。外部の制作会社や開発会社ともスムーズに連携できます。制作会社が実装を行い、私が問題を特定して優先順位を決め、すべての修正を検証します。社内チームと進める場合と流れは同じです。制作会社の方ですか？ その場合は代理店・制作会社との連携方法をご覧ください。

お使いの管理システムに登録されたチケット形式の調査結果、本番環境に反映された修正、CI/CDパイプラインへのパフォーマンスバジェットの導入、RUMデータの監視とアラート、そして仕組みを理解した開発者です。

2つの方法があります。1つは、デプロイパイプライン内のパフォーマンスバジェットです。レイアウトシフトを増やしたりmain threadをブロックしたりするビルドを、本番公開前に検知します。もう1つは、RUMデータのアラートです。パフォーマンスの低下を検知してお知らせします。CoreDashは毎時間チェックを行いますが、十分なデータが集まって確実な場合にのみアラートを上げるため、誤検知に振り回される心配はありません。それでも、Search Consoleに反映される数週間前には問題を把握できます。

監査は、何が問題でどの順番で修正すべきかを提示します。コンサルティングは、それが修正されるまで現場に伴走します。

自社のチームに引き継ぎます。また、月額1,500ユーロ（月1日程度の稼働）からのリテイナーも利用可能です。私がRUMデータを監視し、速度低下を検知してお知らせしたうえで、四半期ごとに次の改善方針を決めます。

リポジトリへのアクセス権（GitHub、GitLabなど）、ステージング環境、アナリティクスのアカウントです。何週間もオンボーディング会議を重ねる必要はありません。アクセス権が揃えばすぐに着手し、通常5営業日以内に最初の調査結果を提出します。

1週間から6ヶ月ほどです。問題の深刻さと、チームのリリース速度によって決まります。多くの場合、予想よりも早く完了します。担当した案件の60%は1ヶ月以内に完了しています。正確な期間は、着手前に提示するスコープに記載します。

デプロイ後、1日以内にはRUMデータに変化が現れます。数値に統計的な意味を持たせるには一定の訪問数が必要なため、アクセス数の多いページほど早く変化を確認できます。いずれの場合でも、GoogleのCrUXレポートに反映される数週間前には改善結果を把握できます。

はい、可能です。タグを削除するのではなく、読み込みの方法とタイミングを見直します。広告のビューアビリティ基準を満たしつつ、main threadをブロックせず、レイアウトをガタつかせないように実装できます。DPG Media、Aleteia、Who What Wearも、広告収益を維持したままCore Web Vitalsに合格しています。