Pinterestエンジニアリング

Pinterestの技術ブログ

パフォーマンスを改善する事で、ユーザー数の成長を促進する

Sam Meder、Vadim Antonov&Jeff Chang |Pinterestのエンジニア、グロース

2015年初頭、Pinterestのエンジニアは、モバイルウェブのホームランディングページのパフォーマンスを60%向上させ、モバイルでユーザー登録のコンバージョン率を40%向上させた実験を行いました。しかし、この実験は、内部のテンプレートレンダリングエンジンや共通リソース(JS、CSS)を使用せずに、事前にレンダリングされたHTMLページを提供すような、多くのショートカットを使用した綺麗ではない解決策でした。

この実験を実行するには、フロントエンドエンジン全体、すべてのページテンプレート、共通要素を書き直す必要がありました。これは膨大な手間がかかりましたが、達成するためには、サービスのシステムすべての進捗状況を追跡するための強力なメトリクスを構築する必要がありました。この記事では、Pinterestページのパフォーマンスをどのように改善したか、それが過去最大の増加となった2016年のユーザー獲得にどう繋がったのかについて説明します。

測定

最初のステップとして、改善したい指標を明確に定義して実装する必要がありました。 2015年の実験で使用された元のメトリックは、全体的なページ読み込み時間(PLT)でした。これは、ユーザーがURLを入力するか、URLをクリックした後にページ全体が表示

されるまでの時間として定義されていました。ブラウザのナビゲーションタイミングAPIに関して、navigationStartイベントとdomCompleteイベントの違いは次のとおりです。

・navigationStartイベントは、ブラウザのナビゲーションバーにURLを入力した後、ユーザーがリンクをクリックするかEnterキーを押したら発生します。

・domCompleteイベントは、ページ上のすべての処理が完了し、すべてのリソース(画像、CSS、JSなど)のダウンロードが完了すると発生します。ブラウザのタブスピンナーの回転を停止や、ページ上の追加のロジック(onLoad javascriptなど)などは後で実行します。

Copyright © 17 December 2012 World Wide Web Consortium, (MIT, ERCIM, Keio, Beihang)

このメトリックは良いスタートですが、パフォーマンスが反映されていないという大きな欠点があります。これは、ページの目に見える部分がページ全体よりもはるかに高速に読み込まれる可能性があるため、ユーザーにとって重要です。

ユーザーは待機時間を認識する

この問題を解決するために、別のメトリックのユーザ認識待ち時間(UPWT)を私たちは導入しました。それは、ユーザがURLを入力するか、URLをクリックしてから、レンダリングされるユーザが見ることのできるページの一部を表示するまでにかかる時間として定義されます。これは、イメージ読み込みイベントに基づくカスタムメトリックです。画面に表示されている画像と読み込みが完了したタイミングを追跡します。 UPWTはnavigationStartイベントで開始し、domLoadingイベントとdomCompleteイベントの間のどこかで終了します。

・domLoadingイベントは、ブラウザがドキュメント全体を受け取り、レンダリングを開始すると発生します。

Copyright © 17 December 2012 World Wide Web Consortium, (MIT, ERCIM, Keio, Beihang)

追加のメリットとして、同様のメトリックをモバイルアプリケーションに導入し、同じ方法で測定することができるかもしれません。

私たちは、主要なダッシュボードと実験フレームワークに、メトリック(PLTとUPWTの全体)といくつかの追加のパフォーマンス指標(サーバー側のパフォーマンスや詳細なブラウザ側のパフォーマンスなど)を統合しました。これにより、進捗状況を追跡し、どの改善がより大きな利益に結びつくかを迅速に把握することができます。

教訓:進捗状況を追跡し、大きな影響の変化に集中するための正しいメトリックを作成せよ。

最適化

最適化の機会は、フロントエンド、ネットワーク、バックエンドの3つの主要カテゴリに分けられます。

フロントエンド

ページの重さ(CSS / JS / Images / HTML)

総合的なテスト結果を見ることで、私たちのページにはロードに多くのバンド幅が必要であることがすぐに分かりました。これは、古いネットワークインフラストラクチャを持つ一部の国際市場では特に解決の難しい問題となります。これを解決するために、私たちは何を読み込むかについてもっと細かくなる道を切り開きました。以前は、サイト全体でCSSとJSを取得することがよくありました。今では、スクロールする前の最初から表示されているコンテンツをレンダリングするために必要なCSSとJSを取得し、最初のレンダリングの後に他のアセットを遅延ロードします。画像が要求されたかどうかをもう一度見て、必要な画像があるかどうか、最適なサイズを取得しているかどうかを確認しました。これら2つの最適化によって、1つのページを表示するのに必要なバイト数が60%削減されました。

レンダリング(React)

私たちがパフォーマンスに重点を置いたのは、自社製のフレームワークからReactへのサイト全体の移行と同時期でした。Pinterestの中で私たちのチームは、Reactのアーリーアダプタの1つであり、Reactのレンダリングモデルから大幅なパフォーマンス向上を実現しました。 Reactのフレームワークがあれば、無制限からDOMモデルを変更できるものから、Reactのshadow DOM、バッチ更新モデルにいたるまでかなりの利益が得られました。

アーリーフラッシュ/チャンク形式転送エンコーディング

ページがサーバー側でどのようにレンダリングされているかを調べることによって、クライアントとサーバー間のパスを最適化しました。これにより不要なバッファがなくなり、ブラウザが早期に<head>セクションを受け取るようになり、データの取得やサーバーサイドレンダリングと並行してフレームワークレベルのJS&CSSリソースを取得できるようになりました。レンダリングが終了する際にページの一部を送信するために、チャンク形式転送エンコーディングを既に使用していましたが、ページをレンダリングするサービスとエンドユーザーの間のインフラストラクチャに関しての批評は、レスポンスをストリームングするというよりむしろレスポンスをバッファするというところに現れました。バッファを無くしたことで、ブラウザにバイトを渡せるようになり、ページの読み込み時間を改善することができました。

トランスポート

CDN / DSA

私たちは両方の交通インフラを大幅に改善しました。私たちは、CDNセットアップで複数のキャッシング層を導入し、IPv6を有効にし、上位層のサービス(CDN)に切り替え、SSLエッジターミネーション(DSA)をグローバルに導入しました。

バックエンド

可能な限り並列化する

ページをレンダリングするには、一般的に異なるソースからの複数の異なるデータが必要です。私たちのためにこれは現在複数のAPI呼び出しに変換されています。これらの呼び出し間には自然なデータ依存グラフがあり、どの呼び出しを並列に行うことができ、データの依存関係のために順次呼び出す必要があるかを示しています。我々は、データフェッチの最適な並列化を自動化するGraphQLの採用に取り組んでいます。その間、不必要に連続しているコールを並列化するために現在のコールグラフを確認しています。

必要なものだけを返す

私たちは、私たちが要求するデータをUIに合わせて調整しました。しばしば、追加のフィールドでバックエンドサービスへの追加呼び出しが必要になることがありましたが、これによってネットワークの負荷と、サーバー側で不要なデータを取得すること減らすことができました。

可能な限りキャッシュする

「カーディナリティの低い」ページタイプ(つまり、ページ数が何十億ではなく数十万になる)のデータの「エッジ」キャッシングを拡張するために、私たちは時間を費やしました。キャッシングは、私たちが今後さらに調査していく予定の領域ですが、特定のページが多すぎて効果的にキャッシュされなければ、バックグラウンドでキャッシュのリフレッシュを実行する場合の「ヘッド」ページデータのキャッシュから、私たちは調査していきます。

パフォーマンスの向上による成長の最大化

パフォーマンスのためにWebページを書き換えるとき、新しいデザインを試さないことが重要です。より速く、異なるデザインページが元のページと比較される場合、変更後のコンバージョンがパフォーマンスの改善、またはデザインの改善によるものなのかどうかを知ることはできません。全く同じページを作成しましょう。また、パフォーマンスがウェブアプリに及ぼす影響を十分に理解するには、ウェブとモバイルのウェブと同様に、ページタイプ別に指標を分割する仕組みを備えた実験を設定する必要があります。

ページごとに異なるコンバージョンが発生し、パフォーマンスが向上してトラフィックが増加します。私たちは、すべてのページを集約すると全体的なコンバージョンがわずかに上がっていたことがわかりましたが、セグメントを調べると、モバイルウェブが実際にダウンし平均を下げている一方で、デスクトップのウェブコンバージョンが大幅に増加していることがわかりました。モバイルウェブのコンバージョンメトリックが低下し、同じような機能の中にいくつかの問題が発見された理由を、私たちは調査しました。

全体的なページの改善を最大化するには、小さなコンバージョン機能でも再実装するように十分注意することが重要です。私たちのオリジナルのページには、多くのこれらの小さなコンバージョン機能がありましたが、差異を見つけて修正していくうちに、コンバージョン率は引き続き上昇しました。ここでの大きな教訓は、ページごとに、また、Web /モバイルWebでページを分割し、利益の流入元を特定し、特定のセグメントの問題を検出することです。集計されたコンバージョン率の全体的な変化を見ると、これらの問題は隠されている可能性があります。

コンバージョン機能チェックリスト

・同じアップセルの仕組み

・ナビゲーションの仕組み(ポップアップ?新しいタブ?)

・サインアップとフォームの仕組み(フィールドバリデーションメッセージ、同じフィールドと認証ステップ)

・自動認証機能

・モバイルウェブとタブレットアプリのアップセル

・モバイルウェブのディープリンク

パフォーマンスリライトを行う為にしなくてはならないもう1つの重要なことは、すべての種類のページでSEO実験をすることです。 SEO実験の基本についての詳細は、前回の記事「実験によるSEOの解読」を参照してください。 SEOの実験では、ページの読み込み時間の改善がいかに実際に検索エンジンからのトラフィックを増やすかどうかがわかります。そして私たちの場合はそうでした。もしあなたのページがトラフィックが非常に多いページであれば、検索エンジンのランキングを向上させる多数の機能も実装している可能性もあるでしょう。SEO実験では、その一部の機能が適切に再実装されていない場合もわかります。画像サイズや、使用されるHTMLタグなどの細かいディテールも重要なので、すべての種類のページでこれを監視することが重要です。私たちは、SEOのトラフィックを同程度にするために食い違いを特定し修正するのに数週間かかりました。

SEO機能のチェックリスト

・主要なタグ(例:<h1>、hreflang、rel = canonical)

・同一の画像サイズ

・記述テキスト

・最初のページの読み込み時のコンテンツの量

主に学習したこと

・ほぼ同一のページを構築する、ページを再設計しない

・実験を異なるページタイプに分割し、ウェブとモバイルウェブを分割する

・SEOの実験も行う

・各セグメントを調べて、コンバージョン率やSEOを下げている可能性のある欠けている機能があるかどうかを確認する

結果と未来

パフォーマンスのためにページを再構築した結果、Pinnerの待機時間は40%短縮され、SEOトラフィックは15%増加し、登録へのコンバージョン率は15%増加しました。トラフィックとコンバージョン率の増加は倍数であるため、これはウェブとアプリの登録の観点で私たちにとって大きな勝利でした。 2016年において、これが私たちのチームの最大のユーザー獲得になりました。加えて、遅いインターネット接続を持つPinnerたちは、かなり良いUXを体験することができました。今回のプロジェクトが理由で、チームは今 新しいユーザーの獲得をするための最大のチャンスの1つとして、パフォーマンスを重要視しています。

参考文献

Other Pinterest Growth Engineering Blog Posts:

How we doubled sign ups from Pin landing pages

How we increased active Pinners with one simple trick

How to acquire mobile users through growth engineering

How holdout groups drive sustainable growth

Demystifying SEO with experiments

原文 : https://medium.com/@Pinterest_Engineering/driving-user-growth-with-performance-improvements-cfc50dafadd7#.cpd3l433w
Heap | Mobile and Web Analytics