ウェブに関する主な指標の最適化と Next.js への移行に重点を置いたプロジェクトでは、コンバージョン率が 5% 増加し、セッションあたりのページ数が 87% 増加しました。
QuintoAndar は、不動産向けのデジタル エンドツーエンド ソリューションを提供するブラジルの不動産テック企業です。今年は、アプリ内のコンテンツ ハブのパフォーマンス向上に重点を置いたプロジェクトを実施し、ユーザー トラフィックとコンバージョン指標の増加という好ましい結果を得ました。
46%
直帰率の低下
87%
セッションあたりのページ数の増加
5%
検証フェーズでのコンバージョンの増加
課題
このアプリには、4 万ページを超えるコンドミニアム コンテンツ ハブがあり、ユーザーは物件に関する情報の入手、共用部分の写真の確認、近隣地域の情報の確認、賃貸または売却のリスティングの検索を行うことができます。以下のページは QuintoAndar にとって非常に重要です。
- 検索エンジンの検索結果からアクセスするユーザーの数は着実に増加しており、オーガニック トラフィックの重要なソースとなっています。
- 他のページと比較して、中長期的なコンバージョン率が高い。
ただし、これらのページのパフォーマンスとユーザー エクスペリエンスには課題がありました。
- Core Web Vitals で測定されるパフォーマンスは最適化されておらず、ページの読み込みが遅い、ユーザー入力への応答が遅い、レイアウトが不安定であるという既知の問題がありました。
- アプリの他の部分よりも高い直帰率が予想されたにもかかわらず、高い直帰率でした。
- Google 検索のページ エクスペリエンスの更新(当時はまだリリースされていませんでした)では、ウェブに関する主な指標がランキング アルゴリズムに組み込まれるため、ページのパフォーマンスが検索結果の表示方法に影響する可能性があります。
同時に、Google は、Google 全体の他のプロジェクトで成果を上げることができるデベロッパー エクスペリエンスの機会を特定しました。
- コンドミニアム ページなど、トラフィックの多いすべてのページをレンダリングするサーバーサイド レンダリング ロジックは社内で作成されましたが、複雑になりすぎてメンテナンスや新入社員のオンボーディングに支障をきたしていました。
- コード分割など、アプリのパフォーマンスを高めるために不可欠な機能にも、カスタム設定とデベロッパーによる手動作業が必要でした。
- QuintoAndar には 30 を超える React ウェブ アプリケーションがあります。これらのアプリケーションにアップデートを配信し、ベスト プラクティスに沿ってメンテナンスすることは、困難な作業です。
アプローチ
コンバージョンの増加、SEO の向上、ユーザビリティの改善につながると考え、コンドミニアム コンテンツ ハブのパフォーマンス最適化プロジェクトを開始しました。この取り組みは、デベロッパー エクスペリエンスを改善する絶好の機会でもありました。
Next.js への移行
新しいバージョンのコンドミニアム ページは Next.js で実装されました。コンドミニアムのコンテンツ ハブはアプリの他の部分からほぼ独立しているため、新しいフレームワークを試すには適した候補でした。移行作業の規模を把握し、QuintoAndar の他の React アプリに影響を与えることなく、その機能がどのように役立つかを評価できます。
検索エンジンがページをクロールできるようにすることが必須要件でした。Next.js は、サーバーサイド レンダリングをすぐにサポートすることで、この要件を満たします。これにより、カスタム設定の必要がなくなります。ドキュメントがあれば、サーバー上でのデータ取得や新しいデベロッパーのオンボーディングなどのタスクを行う方法に関する知識を簡単に共有できます。サーバーサイド レンダリングは、First Contentful Paint(FCP)などのパフォーマンス指標を改善することも知られています。
このフレームワークには、自動コード分割やprefetchingなど、パフォーマンスに優れた他の機能も用意されています。既存の構造にはすでにこのような機能が用意されていましたが、デベロッパーに追加の作業が必要だったため、採用が進みませんでした。たとえば、ページレベルまたはコンポーネント レベルでのコード分割は手動で行う必要がありました。
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 プロパティを使用するなど、他にもオプションがあります。また、動的にレンダリングされるコンポーネントがレイアウト シフトを引き起こさないように、プレースホルダも作成しました。
変更の段階的なロールアウト
チームは、最適化されたバージョンのコンドミニアム ハブページがユーザー エクスペリエンスを向上させるかどうかを検証したいと考えました。これを実現するため、段階的なロールアウト戦略を採用しました。
- 最初のフェーズでは、新バージョンは手作業で選ばれた少数の URL に対して公開されたため、1 日に数百人のユーザーにしか表示されませんでした。
- 2 番目のフェーズでは、より多くのページに公開され、1 日に数千人のユーザーにリーチしました。
- 3 つ目のフェーズ(最終フェーズ)では、すべてのページに公開され、すべてのユーザーへのロールアウトが完了しました。
この期間中、エンジニアリング チームは、本番環境でページのパフォーマンスを継続的に測定し、改善に取り組んできました。また、チームは、新しいバージョンと以前のバージョンのビジネス指標を比較しました。この検証期間の結果は有望でした。
結果
チームは SpeedCurve を使用して、コンドミニアム ページに対してラボテストを継続的に実行しました。モバイル バージョンの結果は次のとおりです。
ラボの指標 | 前 | 変更後 | 差異 |
---|---|---|---|
Largest Contentful Paint(LCP) | 2.41 秒 | 1.48 秒 | -39% |
Time to Interactive(TTI) | 12.16 秒 | 7.48 秒 | -39% |
合計ブロック時間(TBT) | 1,124 ミリ秒 | 1,056 ミリ秒 | -4% |
Cumulative Layout Shift(CLS) | 0.0402 | 0.0093 | -77% |
また、実際のユーザーへの影響をチェックする必要がありました。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 への長期的な移行作業の最初の部分です。それ以降、マンションのページの作成に携わったチームは、デベロッパー エクスペリエンスの改善について肯定的なフィードバックを寄せています。新しいウェブアプリをブートストラップする必要があった他のチームは、すでに Next.js でブートストラップしています。Next.js は、メンテナンス作業を簡素化し、さまざまなアプリ間の共通基盤を確立すると考えています。
全体的に、コンドミニアム コンテンツ ハブは、ユーザー数と取引数の絶対数において継続的に成長しています。長期的な分析では、QuintoAndar の事業拡大や、ページ インデックスの改善などの SEO イニシアチブなど、これに貢献している要因は多数あります。このプロジェクトでは、ページのパフォーマンスも、コンバージョンにプラスの影響を与える可能性が高い要素の一つであることがわかりました。
ユーザーデータを詳しく調査し、このケーススタディに記載されているコンバージョン分析をすべて作成していただいた SEO チームのプロダクト マネージャーの Pedro Carmo 様に、特別な感謝を申し上げます。