QuintoAndar の事例: ページのパフォーマンスを向上させてコンバージョン率とセッションあたりの閲覧ページ数を改善

Core Web Vitals の最適化と Next.js への移行に焦点を当てたプロジェクトにより、コンバージョン率が 5% 向上し、セッションあたりの閲覧ページ数が 87% 増加しました。

Daniela Sayuri Yassuda

QuintoAndar は、不動産向けのデジタル エンドツーエンド ソリューションを提供するブラジルのプロップテック企業です。今年は、アプリ内のコンテンツ ハブのパフォーマンス向上に重点を置いたプロジェクトを実施し、ユーザー トラフィックとコンバージョン指標の増加という好ましい結果を得ることができました。

課題

このアプリには 40,000 ページを超えるコンドミニアムのコンテンツ ハブがあり、ユーザーはここで物件に関する情報を取得したり、共用エリアの写真を確認したり、近隣の情報を閲覧したり、賃貸や販売が可能な物件を検索したりできます。QuintoAndar にとって、これらのページは非常に重要です。

• オーガニック トラフィックの重要なソースであり、検索エンジンの結果からアクセスするユーザーの数は着実に増加しています。
• 他のページと比較して、中長期的なコンバージョン率が高い。

ただし、これらのページのパフォーマンスとユーザー エクスペリエンスには課題がありました。

• Core Web Vitals で測定したパフォーマンスは最適化されておらず、ページの読み込みが遅い、ユーザー入力に対する応答が遅い、レイアウトが不安定であるなどの問題が確認されています。
• アプリの他の部分よりも高いと予想していましたが、直帰率が高かったのです。
• 現時点ではまだリリースされていなかった Google 検索のページ エクスペリエンスの更新では、ランキング アルゴリズムに Core Web Vitals が追加されるため、ページ パフォーマンスが検索結果の表示方法に影響する可能性があります。

同時に、社内の他のプロジェクトでメリットを得られるような開発者体験の機会も特定しました。

• マンションのページを含むすべてのトラフィックの多いページをレンダリングするサーバーサイド レンダリング ロジックは社内で作成されており、複雑すぎて新規採用者の維持やオンボーディングが困難でした。
• また、コード分割のような優れたアプリ パフォーマンスを実現するために不可欠な機能でも、カスタム セットアップとデベロッパーの手作業が必要でした。
• QuintoAndar には、30 を超える React ウェブ アプリケーションがあります。こうしたアプリケーションの更新を提供し、ベスト プラクティスに従ってそれらを維持するのは、骨の折れる作業です。

アプローチ

Google は、ユーザー エクスペリエンスを改善するため、コンドミニアム コンテンツ ハブのパフォーマンス最適化プロジェクトを開始しました。この改善がコンバージョンの獲得、SEO、ユーザビリティの向上につながるからです。この取り組みは、デベロッパーのエクスペリエンスを向上させるのにもふさわしい機会でもあります。

Next.js への移行

新しいバージョンのマンションのページは Next.js で実装されました。このマンションのコンテンツ ハブは、アプリの他の部分からほぼ独立しているため、新しいフレームワークを試すのに適した候補と考えられました。QuintoAndar の他の React アプリに影響を与えることなく、移行作業の規模を把握し、この機能がどのように役立つかを評価できます。

検索エンジンがページをクロールできるようにすることは、厳格な要件でした。Next.js は、サーバーサイド レンダリングを追加設定なしでサポートすることでこの要件を満たし、カスタム セットアップの必要性を排除します。このドキュメントにより、サーバーでデータ取得などのタスクを行う方法や、新しいデベロッパーをオンボーディングする方法について、知識を共有しやすくなっています。サーバーサイド レンダリングは、First Contentful Paint（FCP）などのパフォーマンスの向上指標でも知られています。

このフレームワークには、自動コード分割やプリフェッチなど、パフォーマンスに優れたその他の機能もあります。既存の構造ではすでにこのような機能を提供していましたが、デベロッパーによる追加の作業が導入を停滞させていました。たとえば、ページレベルまたはコンポーネント レベルでのコード分割は手動で行う必要がありました。

JavaScript リソースの最適化

最初のステップは、使用されていないコードを削除することでした。各 JS バンドルの内容を示す Webpack Bundle Analyzer レポートを調べ、すべてのサードパーティ スクリプトを慎重に確認しました。その結果、このページで使用されていない一部のトラッキング ライブラリをクリーンアップしました。

さらに Google のチームはさらに踏み込んで、既存の機能のパフォーマンス コストを評価しました。たとえば、「いいね」ボタンは、大量の JS が必要でした。しかし、マンションのページでは、ボタン操作を行ったユーザーは 0.5% 未満でした。このボタンはアプリの他の部分でより頻繁に使用されていました。エンジニアリングとプロダクトの両方について議論した結果、この機能を削除することにしました。

他の JS 最適化は、Brotli による静的圧縮など、ビルド時に BrotliWebpackPlugin を使用して行われ、他のタイプの静的リソースにも適用されていました。当初、CDN による圧縮を利用していましたが、Brotli は gzip と比較して JS のサイズを 18% 削減しました。しかし、その後、ビルド時に Brotli 圧縮に切り替えることで、24% の削減を達成できました。

画像リソースの最適化

モバイル版では、スクロールせずに見える範囲の大部分をヒーロー画像が表示されます。また、ページの Largest Contentful Paint（LCP）でもあります。

以前は、レスポンシブ画像を提供するための srcset 属性と sizes 属性がすべての画像にすでに存在していました。また、Thumbor を使用してオンデマンドで画像のサイズを変更し、効率的にキャッシュに保存するように CDN を構成しました。

最近のモバイル デバイスは極めて高いピクセル密度のディスプレイを搭載しているため、ブラウザは画像の 3 倍または 4 倍のバージョンがある場合はそれを表示します。解像度が上がると、人間の目は違いを認識するのが難しくなりますが、ファイルサイズはそれに関係なく大きくなります。画像の最大解像度の上限を設定することで、ユーザー エクスペリエンスを損なうことなく画像サイズを改善できました。ヒーロー画像には、最大で 2 倍のバージョンを表示するように制限しました。これは、3 倍のバージョンより約 35% 小さく、4 倍のバージョンより 50% 小さくなります。

最後に、プリロード戦略を使用してできるだけ早くレポートをダウンロードして表示し、LCP 指標の改善を期待しています。

<link rel="preload" href="/img/450x450/892847321-143.0038687080606IMG20180420WA0037.jpg" as="image">

Next.js 組み込みの画像コンポーネントには、レスポンシブ サイズ変更や優先読み込みなど、こうした最適化の多くが含まれています。このプロジェクトでは、このコンポーネントを使用するために既存のイメージは移行しませんでしたが、新機能に導入する予定です。

レイアウト シフトの削減

このマンションのページには、Cumulative Layout Shift（CLS）に関する問題がいくつかありました。レイアウト シフトを担う要素はクライアント内でのみレンダリングされていました。たとえば、クライアント側でレンダリングされるコンポーネントでサーバーサイドのマークアップをハイドレートしたり、width 属性や height 属性が定義されていない画像などです。

これらの問題を解決するため、可能であれば、これらの要素の正確な寸法を設定するか、min-height を使用して推定値を設定します。aspect-ratio CSS プロパティを使用するなど、その他のオプションもあります。また、動的にレンダリングされるコンポーネントによってレイアウト シフトが発生しないように、プレースホルダを作成しました。

変更を段階的にロールアウトする

私たちのチームは、マンションのハブページの最適化されたバージョンによってユーザー エクスペリエンスが向上するかどうかを確認したいと考えていました。これを実現するために、Google は段階的なロールアウト戦略を採用しました。

1. 最初の段階では、厳選された数件の URL を対象に新しいバージョンを公開したため、1 日に数百人のユーザーしか閲覧できませんでした。
2. 第 2 フェーズでは、ページ数を増やし、1 日あたりのユーザー数は数千人に上りました。
3. 最後のフェーズである 3 では、これをすべてのページに公開し、すべてのユーザーにロールアウトを完了しました。

この期間中、エンジニアリング チームは本番環境でページ パフォーマンスを継続的に測定し、改善に取り組み続けました。さらに、新しいバージョンと以前のバージョンのビジネス指標を比較しました。この検証期間の結果は有望なものでした。

結果

チームは SpeedCurve を使用して、マンションのページに対してラボテストを継続的に実行しました。モバイル版での結果は次のとおりです。

実際のユーザーへの影響も確認しました。Instana のウェブサイト モニタリングで収集したフィールド データを使って、リリース前とリリース後の 1 か月間のデータを比較しました。モバイル ユーザーの 75 パーセンタイルを比較すると、LCP が 26%、FID が 72% 減少しました。

PageSpeed Insights では、過去 28 日間のフィールド データ レポートが提供されます。最もアクセスの多いマンションのページだけでも、モバイル ユーザー向けのレポートを作成するのに十分なデータがありました。2021 年 11 月現在、Core Web Vitals はすべて「良好」バケットに入っています。

段階的な導入中に、直帰率の低下が見られました。すべてのページのリリースが完了する頃には、Google アナリティクスでは直帰率が 46% 低下し、セッションあたりの閲覧ページ数が 87% 増加し、平均セッション継続時間が 49% 増加しました。直帰率の低下は有料検索ではさらに大きく、59% 低下しました。これは、クリック課金型（PPC）広告への投資については肯定的な兆候です。

ビジネス指標への影響については、ツアーの手配や不動産の賃貸や購入の申し込みなどの取引のコンバージョン率を分析しました。改良のロールアウトがまだ進行中だった Google のチームは、以前のバージョンと新しいバージョンで変換を比較しました。同じ週に、新しいバージョンを表示したページ群ではコンバージョン数が 5% 増加したのに対し、他のページでは同じ指標がわずかに減少しました。

おわりに

このプロジェクトは、フレームワークを使用しない React から Next.js への長期的な移行の取り組みの第 1 部です。その後、マンションのページを担当したチームは、開発者エクスペリエンスの向上について好意的なフィードバックを残しました。新しいウェブアプリをブートストラップする必要があった他のチームは、Next.js を使用してすでにそれを実現しています。Next.js は、メンテナンス作業を簡素化し、異なるアプリ間で共通の基盤を確立することを可能にします。

全体として、マンションのコンテンツ ハブはユーザー数とトランザクション数において継続的に成長しています。長期的な分析では、QuintoAndar の事業拡大や、ページのインデックス登録の改善などの SEO への取り組みなど、多くの要素がこれを要因にしています。このプロジェクトを通じて、ページのパフォーマンスも、コンバージョンにプラスの影響をもたらす大きな可能性を秘めた要素の 1 つであることがわかりました。

ユーザーデータについて深く掘り下げ、このケーススタディで見られるすべてのコンバージョン分析を作成してくれた SEO チームのプロダクト マネージャーである Pedro Carmo に深く感謝します。