モバイル検索を2回高速化する方法。 ヤンデックス講義

電話では、多くの場合、Webページはデスクトップよりも長く読み込まれます。 開発者のIvan Khvatovが、バックログの理由と対処方法について話します。 講義はいくつかの部分で構成されています：最初-モバイルデバイスでのページ読み込みの主要な段階について、2番目-読み込みを高速化するために使用する技術について、3番目-異なる速度にレイアウトを適合させる方法について。


-みなさん、こんにちは。私の名前はIvan Khvatovです。検索インフラストラクチャで働いています。 最近、検索結果の高速化に取り組んでいます。 レイアウト、バックエンドチーム、トラフィック配信を担当しています。 今日は、モバイル検索をどのように高速化したか、どのテクニックを使用したか、成功したか失敗したかを説明します。 それらは私たちだけのものではありません。 何か、多分あなたはそれを自分で試すことができます。 障害、障害から学んだこと、接続速度に応じてレイアウトを調整する方法について説明します。

RuNetのデスクトップとモバイルのスライスでの出力の最初のレンダリングの時間を見ると、モバイルは接続速度に応じて1.5〜2倍遅れていることがわかります。



速度がユーザーの幸福に直接影響することは周知の事実です。 ユーザーは、高速サービスを使用して、問題を迅速に解決することを好みます。 一部の問題では、ユーザーはモバイルインターネットから、少なくともデスクトップとしては高速でなくても動作することを期待しています。 したがって、私たちは最近、モバイルインターネットの最適化に真剣に取り組んでいます。

理由を理解するために、モバイルWebの機能を見てみましょう。



モバイルインターネットは、ほぼ100％ワイヤレス（セルラーまたはWi-Fi）です。 接続には、遅延、1つのパケットがサーバーに到達して戻ってくるまでの時間、pingコマンドなどの特性があります。 および-チャネル幅：接続がスキップする単位時間あたりのデータ量。

これらの特性は、モバイルインターネット、Wi-Fi、およびセルラーネットワークでは非常に劣っています。 大きな遅れ。 チャネル幅が非常に狭いネットワーク技術があります。 しかし、さらに悪いことに、これらの特性は、さまざまな条件、タワーの荷重、タワーまでの距離、トンネルに運転したかどうかによっては不安定です。 また、オペレーティングシステムの従来のアルゴリズムは、これらの特性が安定するように調整、調整され、不安定な特性では接続速度が大幅に低下していました。

2番目の特徴は鉄です。 電話は、急速な成長にもかかわらず、プロセッサ、メモリ、フラッシュの点でまだデスクトップに遅れをとっています。 キャッシュからリソースを取得したとしても、デスクトップよりもはるかに遅くなります。



これらの機能はページの読み込みにどのように影響しますか？ ブラウザがリクエストを行い、ページをレンダリングしようとするとどうなりますか？ 何らかのネットワークアクティビティがあり、接続が確立されます。 サーバーで接続が受信され、サーバーがそれを処理します。しばらく時間がかかります。 その後、トラフィックが配信されます。 次のステップ-ブラウザーは応答を解析し、出力を描画します。



電話での高速接続と低速接続のコンテキストでこれらのステージが互いに相対的にどのように見えるかを見ると、高速ネットワークでは、ページを表示する際のボトルネックは、正確にページの解析とレンダリングです。

これとは別に、安全な接続のセットアップにもかなりの時間がかかることに注意してください。これはレッドゾーンです。

3Gネットワ​​ークの場合、接続の確立にほとんどの時間がネットワーク部分に費やされます。 また、安全な接続の設定も際立っています。 ユーザーに見えるホワイトページが少なくなるようにモバイルを最適化する場合は、接続の確立に注意を払い、安全な接続のセットアップに別途注意を払う必要があります。



接続はどうなりますか？ 最悪のシナリオでは、ブラウザはDNSを解決し、IPアドレスを取得し、別のネットワーク入力を行い、TCP接続を確立してから、安全な接続を確立します。 彼と一緒に、原則として、もう少し複雑です。 少なくとも、2つの要求を行う必要があります。 これについては、2つのネットワークエントリで詳しく説明します。 そしてリクエストをお願いします。

その結果、最初のデータを取得するために、5つのネットワークエントリを実行する必要があります。 ロシアの実際のモバイルインターネットを見てみましょう。これは、1つのネットワークエントリに相当します。



原則として、Runetのユーザーの50％がレイテンシで問題なく動作していることがわかります。77ミリ秒、5つのネットワークエントリ、ユーザーは実際にはこの瞬間に気付きません。 しかし、ユーザーの待ち時間の2番目の部分は大幅に増加しています。 そして、すでに最も遅い10個の1つのネットワークエントリでは、ほぼ2秒です。 つまり、Yandexユーザーの10％は、ほぼ10秒で完全な接続が確立されると予想します。これは非常に長い時間です。

なぜこのようなテール、なぜレイテンシーが増大しているのですか？



2つの理由。 まず、ネットワークテクノロジー、2Gおよび3Gを見ると、ネットワークテクノロジーのタイプ、レイテンシーの中央値によって、テクノロジーではなくパスポートがありませんが、実際の数値であるレイテンシーは非常に悪いです。 Wi-Fiと4Gでは、すべてが多かれ少なかれ正常です。 しかし、微妙な違いがあります。



過負荷、不安定な信号、物理的な干渉。 次に簡単な例を示します。電話、Yandexから待ち時間を削除し、pingコマンドを実行して、それが何であるかを確認します。 典型的な状況では0.5秒が1つのネットワークエントリであることがわかります。 この時点でチャネルのロードを開始し、ページをダウンロードするだけで、レイテンシーはほぼ10倍、最大6秒になります。 この時点で、チャンネルがロードされたときに、レンダリングに必要ないくつかのブロッキング呼び出しを開始し、ユーザーがそれらを待つことはないことは明らかです。 5つのネットワークエントリ、25秒、誰もそんなに待たない。

それをどうしますか？ 最適化しましょう。



いくつかのアプローチがあります。 最も簡単で効果的なのは、原則として、接続を確立しないことです。 それから重要なポイント-私たちはリダイレクトを見て、私たちもそれらをしないようにします。 さらに、安全な接続のインストール、そこで何ができるかを詳しく調べます。



どうすれば接続できますか？ これは一見シンプルな瞬間です。 キープアライブがサーバーで構成されていることがわかります。 しかし、微妙な違いがあります。 アプリケーションが悪いネットワークに配置されると、多くの場合、タイムアウトによって接続が切断され始めます。 通常の状態では、これに気付きません。遅いネットワークではこれが問題になり、接続がタイムアウトになり、ブラウザーで接続を再作成する必要があります。 したがって、アプリケーションレベルのタイムアウトを分析し、正しく構成します。

2つ目は事前接続です。 この接続が必要になる前に接続を行います。 時間が来て、ユーザーがページを要求すると、すでに接続の準備ができているので、長く待つ必要はありません。

事前接続は標準のディレクティブであり、HTMLで直接指定でき、ブラウザはそれを理解します。 大多数。

Yandexでは、リクエストの処理方法を分析し、検索のヒントを表示するサービスを見つけました。 私たちは、仕事の最初の段階で、既成のつながりがない場合、コールドコネクションを通じてこれを行うことに気付きました。 アーキテクチャをわずかに変更し、別のサービスからの接続を再利用するようにしました。このサービスのインプレッション数はほぼ5％増加しました。



リダイレクト。 これは速度の面で大きな悪です。 最初に、ブラウザは接続を確立するすべての段階を経て、ユーザーは待機し、サーバーは彼がそこに来なかったと言い、反対に行きます。 そして、ブラウザーは接続を再作成し、これらすべてのステップを実行します。

これで何ができますか？ ログを分析し、リダイレクトの場所を確認し、アプリケーション内のサイトのリンクを変更して、常に直接の訪問が行われるようにします。

ログの2番目の機能は、HTTPからHTTPSへのリダイレクトが多数あったことです。 ユーザーはHTTPに切り替え、HTTPSにリダイレクトし、再び待機し、安全な接続を確立します。

これを防ぐために、HSTSテクノロジーがあります。サーバーの応答で、サイトがHTTPS経由でのみ機能することを一度言うことができます。次回HTTP経由で呼び出すと、ブラウザーは自動的に内部リダイレクトを行い、すぐにHTTPSを要求します。



TLS、安全な接続の確立。 セキュリティの観点からではなく、速度の観点からそのようなスキームを見てみましょう。 TLSはどのようにインストールされますか？ 2つの段階。 最初の段階で、クライアントとサーバーは暗号化設定を交換し、どのアルゴリズムを使用するかを決定します。 2番目の、より詳細な情報、データの暗号化方法に関するキー。

2つのネットワークエントリがあることに加えて、クライアントとサーバーは計算にある程度のプロセッサ時間を費やします。 これも悪いですし、遅いです。

ここで何ができますか？ TLSセッションチケットには多かれ少なかれ標準的な最適化がありますが、その本質は何ですか？ 接続がすべての段階を完全に通過した後、サーバーはクライアントにチケットを渡し、次に接続を確立するときにこのチケットを持って来て、セッションを復元するように言います。 すべてがうまく機能します。1つのネットワークエントリを保存し、次に複雑な暗号化を行いません。

しかし、微妙な違いがあります。 セキュリティ上の理由から、これらのチケットを長期間保存することはできません。 ブラウザはしばしばメモリを使い果たされ、これらのキーを失い、次回は2段階でこれを通過しなければなりません。

したがって、TLS False Startと呼ばれる2番目の最適化が助けになります。

_{^{（ リンク -編集）}}

また、1つのネットワークエントリが削減されます。 全体の要点は、スキームを見ると、サーバーから最初に応答を受け取ったときに、ユーザーへのすべてのキーを暗号化してサーバーに送信するためのすべてのデータがあることです。 接続はハーフオープン状態で発生します。

原則として、何も干渉しません。この手法はTLS False Startと呼ばれ、クライアントがサーバーから最初のデータを受信すると、すぐにそれらを暗号化し、接続セットアップとともに要求を送信します。

しかし、ニュアンスがあります。 これはインターネットであるため、TLSサーバーには多くの実装がありますが、一部の実装はこれを破ります。 IEブラウザは、このような最適化をデフォルトで有効にしようとしましたが、一部のサイトが単に機能しないという問題がありました。 彼らは壊れたサイトなどのリストを維持しました。

他のブラウザは他の方法で行った。 彼らはデフォルトでこの最適化をオフにしましたが、TLSサーバーがどのように構成されているかについて、他の機能を見てください。 最新の暗号化アルゴリズムを使用し、サーバーからの最初の応答で理解するALPN拡張機能をサポートしている場合、この最適化が含まれており、すべて問題ありません。

HTTPSサービスを設定する方法の詳細については、 Habréのセキュリティサービスの投稿をご覧ください。すべてが揃っています。

TLS False Start最適化をオンにした後、チケットは長時間オンになり、モバイルでの安全な接続の確立を平均13％加速しました。 彼女はとても効果的です。



次は？ すべての変更を展開しましたが、セキュリティで保護された接続のセットアップにはまだ時間がかかります。 私たちは考え始めました。2つのヘッドシートがあるという事実に加えて、それらは修正されているように見えましたが、まだ多くのデータが送信されています。 サーバーからクライアントに転送されるこのデータ量をトリミングする方法を考えました。

下位互換性のためにチェーン内に証明書があることがわかりましたが、現在では必要ありませんが、削除されました。 そして、彼らはOCSPステープリングに注目しました-これは証明書の失効を確認するために発明された技術であり、証明書が失効した場合、ブラウザは安全な接続を確立し、何らかの方法で警告します。

しかし、時間が経つと、業界は現在、通常の証明書ではデフォルトでOCSPがセキュリティに役立たないと見なされる段階にあるため、ほとんどの人はOCSPを使用せず、バックグラウンドで定期的に更新される失効した証明書のリストを維持しています。

OSCPをオフにし、証明書をカットし、実験を開始して、TLSハンドシェイクがさらに7％加速されることを確認しました。 この最適化を本番環境に残すことにしました。 Operaの接続設定が低下し、OCSP応答が確認されましたが、しばらくすると、ブラウザーのキャッシュがウォームアップすると、OSCP応答がそこにキャッシュされます。 yandex.ruの証明書が取り消されているかどうかを確認します。 呼び出されない場合、応答はしばらくキャッシュされ、次回はそのような循環はありません。

このキャッシュが入力されると、Operaで接続がより速く確立され始めたことに気付きました。 少しのセキュリティも失わないため、この機能をオフにし、データサイズを削減し、チャネル幅がボトルネックである低速ネットワークの場合、高速化を実現しました。

接続を確立し、コンテンツをダウンロードしました。 サーバーがリクエストを受信しました。この場合、それは検索リクエストであり、検索はすぐには機能しません。 多くのサーバー、多くのネットワークエントリ、ランキングがあり、すべて時間がかかります。私たちは積極的に取り組んでおり、最適化も行っていますが、それでもなお。 どうすればこの状況を克服できますか？

検索矢印がありますが、これは検索結果に依存しません。 検索結果を受信する前でも、この検索矢印のユーザーへの送信を開始できます。 HTTPにChunked-Encodingを配置し、検索矢印を送信します。 まず、ユーザーは自分のページが読み込まれていることを確認します。ユーザーは白い画面を見ているだけではありません。 第二に、私たちも加速しています。 この検索矢印を渡すと、TCP接続がウォームアップされ、次に検索結果の準備ができたときに、より速く到着します。 さらに、この検索矢印は何かをJavaScriptにロードし、接続を引き継ぐことができます。



検索結果を取得し、アップロードします。 以下は、データを可能な限り圧縮するために必要な簡単な最適化です。したがって、Brotli、Zopfliを使用します。 Brotli-可能な場合。 Zopfliでの画像のフルバック、画像の最適化、ブラウザがWebPできる場合は、それを使用します。 SVGに対応-SVGを使用します。

HTMLを受け取ったらすぐに出力を整理できるように、外部リソース（つまり、インラインスタイル）をすべてHTMLでブロックしないようにしてください。

そして、別の機能は、静的をウォームアップしようとすることです。 たとえば、ユーザーがサービス、メインページにアクセスし、接続がアイドル状態の場合、検索結果で使用されるリソースをアップロードできます。 また、ユーザーがクエリを入力し、検索結果に切り替えた後、彼はすでにホットキャッシュを持っているため、リソースをアップロードする必要はありません。



WebPについては別に注意したい。 最適化は非常に単純であるように思えますが、オンにして動作しますが、非常に大きな利益をもたらします。 素晴らしい加速。

マップサービスでWebPをオンにして写真で検索すると、完全に読み込まれた結果の数が20％増加していることがわかりました。 ユーザーは、ページが完全にロードされるのを待ち始めました。 トラフィックを14％削減しました。

マイナスのうち、ハッシュヒットが減少しました。 サーバーを追加し、この問題を解決しました。

ここでの主なことは、やりすぎないことです。HTMLを刺したり、刺したりしたときに、すべてを減らして、次のような状況になりました。 最適化することは可能でしたが、同時に、オンライン実験を行ったときに、レンダリングが遅くなっていることに気付きました。 遅いネットワークのユーザーに対しては、それらを高速化し、改善し、ページの読み込みを改善しましたが、ネットワークがボトルネックではなかった場合、速度が低下したことに気付きました。

この状況に対処する方法を考え、次の結論に達しました。接続速度に応じて出力を変更し、何らかの形で適応させる必要があります。 どうやってやるの？ さらに進んで、低速ネットワークのユーザー向けに特別なライトバージョンの問題を作成するという結論に達しました。 これを行うには、サーバー側から接続速度を決定する方法を学ぶ必要があります。

第二に、あらゆるネットワーク、あらゆるデバイスで動作するスーパーレイアウトを作成します。 サーバーの接続速度を決定する方法を学習する方法はいくつかあります。 LinuxカーネルのデータであるTCP_INFOデータを使用し、TLS接続のインストール時間を確認します。クライアントが非常に賢く、クライアント自身が悪いネットワークにいることを伝えた場合、このデータを使用します。



TCP_INFOデータをnginxで直接使用し、1行のコードで構成を有効にすると、速度指標がバックエンドに届くのは素晴らしいことです。



SSL、パケットを送信し、ユーザーからパケットを受信する時間を測定します。 この間隔は、1つのネットワーク発生の時間と見なされます。



接続速度を決定するために、これらすべての要因を使用します。



さらなるレイアウト。 レイアウトについては、このレイアウトのメイン開発者からHabréに別の投稿があります。 あなたがフロントエンドを愛し、好きなら、あなたは読むことができます-それはそこで非常に興味深いです。 要するに、サイズに関しては非常に切り捨てられていますが、目に見える違いはありません。 訓練を受けていない人は、完全なレイアウトと軽いレイアウトを区別しません。 結果やそのようなものがないかもしれないことは明らかです。 同じテクニック、インラインCSSを使用し、サイズを縮小し、非常に小さな検索矢印を作成し、Ajaxを拒否し、非常に軽いJSを使用して、最も遅いデバイスがすばやくレンダリングできるようにします。

Yandexで実験を開始した後、検索インプレッションの数、検索結果のダウンロード数が2.2％増加したことがわかりました。 これは非常に大きな結果です。 これは、低速ネットワークで問題を解決できるユーザーが2.2％増えたことを意味します。



1年ごとのレンダリングレンダリングのグラフを見てみましょう。 10月までに正規化されます。 スケジュールは絶えず成長している、つまり、最適化が絶えず導入されていることがわかります。Yandexの多くのチームがこれに取り組んでいます。 ただし、3つの段階があります。最初は簡単な検索結果を実装したばかりで、最初は包含、2番目は低速接続を決定するアルゴリズムを改善し、3番目はTLS接続の最適化を実装しました。 ご覧のとおり、1年で最初のレンダリングをほぼ2倍に高速化することができました。

私にはすべてがあります。 これらの最適化が役立つことを願っています。 さまざまなサイトが同じ最適化に対して異なる動作をするため、それらをテストする必要があります。メトリックを収集し、すべてがどのように機能するかを確認する必要があります。 ありがとう