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

ウェブに関する主な指標の最適化と Next.js への移行に重点を置いたプロジェクトでは、コンバージョン率が 5% 増加し、セッションあたりのページ数が 87% 増加しました。

Daniela Sayuri Yassuda

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

課題

このアプリには、4 万ページを超えるコンドミニアム コンテンツ ハブがあり、ユーザーは物件に関する情報の入手、共用部分の写真の確認、近隣地域の情報の確認、賃貸または売却のリスティングの検索を行うことができます。以下のページは QuintoAndar にとって非常に重要です。

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

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

• Core Web Vitals で測定されるパフォーマンスは最適化されておらず、ページの読み込みが遅い、ユーザー入力への応答が遅い、レイアウトが不安定であるという既知の問題がありました。
• アプリの他の部分よりは高くなると予想していたとしても、ユーザーの直帰率が高くなっていました。
• Google 検索のページ エクスペリエンスの更新（当時はまだリリースされていませんでした）では、ウェブに関する主な指標がランキング アルゴリズムに組み込まれるため、ページのパフォーマンスが検索結果の表示方法に影響する可能性があります。

同時に、Google は、Google 全体の他のプロジェクトで成果を上げることができるデベロッパー エクスペリエンスの機会を特定しました。

• コンドミニアム ページを含むトラフィックの多いすべてのページをレンダリングするサーバーサイド レンダリング ロジックは社内で作成されましたが、複雑になりすぎてメンテナンスや新入社員のオンボーディングに支障をきたしていました。
• コード分割など、アプリのパフォーマンスを高めるために不可欠な機能にも、カスタム設定とデベロッパーによる手動作業が必要でした。
• QuintoAndar には 30 を超える React ウェブ アプリケーションがあります。これらのアプリケーションにアップデートを配信し、ベスト プラクティスに沿ってメンテナンスすることは、困難な作業です。

アプローチ

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

Next.js への移行

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

検索エンジンがページをクロールできるようにすることが必須要件でした。Next.js はすぐに使用できるサーバーサイド レンダリングをサポートしているため、この要件を満たしています。また、カスタム設定が不要になります。このドキュメントがあれば、サーバーでのデータ取得などのタスクの実行方法や、新しいデベロッパーのオンボーディング方法に関する知識が、はるかに簡単に共有できます。サーバーサイド レンダリングでは、First Contentful Paint（FCP）などの指標のパフォーマンス向上も知られています。

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

JavaScript リソースの最適化

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

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

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

画像リソースの最適化

モバイル バージョンでは、スクロールせずに見える範囲のほとんどをヒーロー画像が占めています。これは、ページの Largest Contentful Paint（LCP）でもあります。

以前は、すべての画像に srcset 属性と sizes 属性が設定されており、レスポンシブ画像を提供することができました。また、Thumbor を使用してオンデマンドで画像のサイズを変更し、効率的にキャッシュするように CDN を設定しました。

最新のモバイル デバイスは、ピクセル密度が非常に高いディスプレイを搭載しています。つまり、可能な場合、ブラウザは画像の 3 倍または 4 倍のバージョンを表示します。解像度が上がると、人間の目では違いを認識しにくくなりますが、ファイルサイズは大きくなります。最大画像解像度の上限を設定することで、ユーザー エクスペリエンスを損なうことなく、画像サイズが改善されました。ヘッダー画像は、最大で 2x バージョンを配信するように制限しました。これは、3x バージョンより約 35%、4x バージョンより約 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 プロパティを使用するなど、他にもオプションがあります。また、動的にレンダリングされるコンポーネントがレイアウト シフトを引き起こさないように、プレースホルダも作成しました。

変更の段階的なロールアウト

チームは、最適化されたバージョンのコンドミニアム ハブページがユーザー エクスペリエンスを向上させるかどうかを検証したいと考えました。これを実現するため、段階的なロールアウト戦略を採用しました。

1. 最初のフェーズでは、新バージョンは手作業で選ばれた少数の URL に対して公開されたため、1 日に数百人のユーザーにしか表示されませんでした。
2. 2 番目のフェーズでは、より多くのページに公開され、1 日に数千人のユーザーに表示されました。
3. 最後の第 3 フェーズではすべてのページに対して公開を行い、全ユーザーを対象にリリースを完了しました。

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

結果

チームは SpeedCurve を使用して、マンションのページに対する検査試験を継続的に実施しました。モバイル版での結果は次のとおりです。

また、実際のユーザーへの影響をチェックする必要がありました。Instana Website Monitoring で収集したフィールド データを使用して、リリース前後 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 への長期的な移行作業の最初の部分です。それ以降、マンションのページの作成に携わったチームは、デベロッパー エクスペリエンスの改善について肯定的なフィードバックを寄せています。新しいウェブアプリをブートストラップしなければならなかった他のチームは、すでに Next.js でブートストラップしています。Next.js は、メンテナンス作業を簡素化し、さまざまなアプリ間の共通基盤を確立すると考えています。

全体的に、コンドミニアム コンテンツ ハブは、ユーザー数と取引数の絶対数において継続的に成長しています。長期的な分析では、QuintoAndar の事業の拡大や、ページのインデックス登録の改善といった SEO の取り組みなど、多くの要因がこのことに貢献しています。このプロジェクトでは、ページのパフォーマンスも、コンバージョンにプラスの影響を与える可能性が高い要素の一つであることがわかりました。

ユーザーデータを詳しく調査し、このケーススタディに記載されているコンバージョン分析をすべて作成していただいた SEO チームのプロダクト マネージャーの Pedro Carmo 様に、特別な感謝を申し上げます。