検索結果ページの実験

検索結果ページは、最も人気のあるYandexページの1つです。 1日に約1億3,000万回ダウンロードされます。 これにより、平均ページサイズは25 KBとなり、1日あたり3 TBのトラフィックが得られます。



見かけの単純さにもかかわらず、このページの構成の背後には、多数の人々と多くの洗練された技術の巨大な仕事があります。



インターフェースの開発では、通常、進化の道をたどり、段階的にページを変更します。 ソリューションを確認し、ごく一部のユーザーにソリューションを紹介します-実験を実施します。 私たちはもはや小さな変化に満足していません。将来、プロジェクトを実装する新しい技術プラットフォームを構築して製品を開発したいと考えています。







今日、検索結果の新しいページで実験を開始しています。 このために、世界のインターネットでの検索をテストするためのサイトyandex.comを選択しました 。 新しいページが表示されたときに最初に気付くのは、そのデザインとyandex.ruの現在のバージョンの検索結果ページの違いです。 しかし、この実験は主に設計に関するものではなく、重要な技術変化の実装に関するものです。 もちろん、新しいソリューションの設計とテストの計画にも取り組んでいますが、新しいソリューションの構築は品質の基礎から始まります。 どのように構築したか、どのような決定が下され、どの技術が使用されたかを正確に伝えたいと思います。



テンプレート開発

最初のモックアップが登場する前でも、開発アプローチを決定する必要がありました。 2つの選択肢がありました。静的ページをレイアウトしてからテンプレートにカットするか、実際のデータをすぐに開発して実際のテンプレートを作成するかです。



一般的な場合、特に1つのチームがレイア​​ウトとテンプレートの開発に関与している場合、2番目のアプローチが望ましいです。 これにより、プロジェクトがいつでもリリース（または少なくともテスト）の準備ができていることが保証されます。 つまり、開発の最初の段階で、プロジェクトの「未加工」であるが既に機能しているプロトタイプが発生し、これに「触れる」ことができます。 結果として、これは私たちが選択したオプションです。



BEM（ Block-Element-Modifier ）手法に基づくプロジェクトアセンブリメカニズムにより、最初のプロトタイプの開発とテストにかかる時間が大幅に短縮されました。 これにより、外部ブロックライブラリを接続できるため、既に他のYandexサービスにあり、異なる内部gitおよびsvnリポジトリにある既製のブロックからインターフェイスの大部分を組み立てました。



JavaScriptはどこにでもあります

内部では、検索結果ページの新しいバージョンにはJavaScriptテンプレートがあります。 これらは、以前に使用したPerl TT2言語のテンプレートエンジンよりも速く動作し、それらを記述する方が便利で簡単です。 現在、JSには、クライアントスクリプト、ユーティリティ、ビルドテクノロジー、デーモンコレクターという2つのレベルの標準化が記述されています。



現在、YUICompressorはJSおよびCSSコードを圧縮するために使用されますが、これにはサーバー上のJavaが必要です。将来的にUglifyJSおよびCSSO JS難読化ツールに切り替えたいと思います。



ブラウザーからアセンブリユーティリティまで、すべての技術レベルで1つの言語を使用することで、プロセスの多くの参加者の生活が大幅に簡素化されます。 開発者は、アセンブリ用のツールを構成（およびオプションで追加）することができ、クライアントおよびサーバー用のコードを簡単に作成できます。 多数の異なるテクノロジーについての深い知識はもはや必要ありません。HTML、CSS、JSなどの基本的なテクノロジーを知っていれば十分です。 これにより、新しい人々をチームに簡単につなぐことができるようになりました。Yandexのすべてのフロントエンド開発者はJavaScriptを知っており、サーバーの仕様は非常に迅速に習得できます。



AJAX、History API

かなり前に、AJAX技術を使用して完全な再起動なしでページのデータを更新することが「流行」になりました。 この手法の利点は非常に明白です。データを更新し、スクリプトを初期化するたびにページ全体（マークアップ、スタイル、スクリプト、画像）を読み込む必要はありません。 これにより、新しいデータをユーザーに配信するプロセスが大幅に高速化されます。 低速チャンネルでのダウンロード速度の違いは非常に大きなものです。



ただし、AJAXのすべての利点を完全に理解しているため、Yandex.Searchでこのアプローチを適用するのは急いでいませんでした。 ユーザーにテクノロジーだけでなく、再設計されたインターフェイスを備えた完全な製品を提供したかったのです。 そのため、検索結果ページの新しいバージョンでは、AJAXとHistory APIを広く使用する必要があります。



（2012年6月2日、Y。Subbotnikのミンスクでの実装について詳しく説明しました ）



CSS

当初、CSS3のすべての機能を使用するという目標はありませんでしたが、問題の解決にはそれらのほとんどすべてが必要でした。 変形クラスのメニュー矢印、モディファイヤクラスの代わりに、最初の子/最後の子の擬似セレクター-これはすべて新しいインターフェイスにあります。 同時に、古いブラウザーでは、影の代わりに、メニューの矢印の代わりに単純な単一ピクセルのアウトライン、通常の長方形、IE9のsvgグラデーション、IE8以前の背景の塗りつぶしが低下します。



もう1つの重要な決定は、フォントサイズを示すために絶対測定単位を使用することでした。 現在、ほぼすべてのサービスで相対パーセンテージまたは<em>タグでサイズの表示を使用していますが、新しいプロジェクトではピクセルを優先してサイズを放棄することにしました。 この決定にはいくつかの議論があります。 第一に、ピクセル単位でフォントを拡大縮小できないブラウザーの割合は、ごくわずかです。 第二に、絶対単位のサイズはコンテキストの影響を排除し、完全に独立したブロックを含むレイアウトはBEM方法論の基本原則の1つです。 そして第三に、検索結果ページはタッチデバイスで正常に機能するはずです。 それらの画面解像度はしばしば事前に知られており、厳密に固定されており、向きのみが変更できます。



展開する

ほとんどすべてのプロジェクトは、静的ファイルを静的クラスターyandex.stに保存します。 これらは、さまざまな都市や国にある数十台の車であり、非常に迅速にデータを提供できます。

静的クラスターを使用する理由はいくつかあります。

-送信する前にファイルを生成する必要はありません-すべての準備が完了し、ディスク上にあります。

-既製のファイルを転送するには、軽量のWebサーバーで十分です。

-高い機械生産性は必要ありません。

-静的変数は永久にキャッシュされ、無効化はパッケージのバージョンを変更するか、ハッシュ量を変更することにより実行されます。

-サービスCookieはyandex.stドメインに送信されません。これにより、トラフィック量が減少します。

-「スルー」ファイル（複数のサービス、たとえばjquery.min.jsまたはYandexロゴで使用）は、サービスからサービスに切り替えるたびにダウンロードする必要はありません。



サービスファイルを静的クラスターに配置するには、debパッケージをビルドする必要があります。 パッケージは手動で、または特別なスクリプトを使用してビルドされます。 新しいパッケージを組み立てた後、計算のアプリケーションがConductorに送信されます。これは、ユーザーが参加しなくても数百台のマシンにパッケージを配置できる社内ツールです。 Yandexサービスの数とその更新頻度を考えると、これは非常に重要です。



静的クラスターは、クライアントでブラウザーの速度を最適化し、ユーザーにファイルを配信するという多くのタスクを解決する非常に複雑なシステムです。 同時に、それを使用するのは非常に簡単です。コンダクターで新しいプロジェクトを開始するには、短い申請書に記入し、責任ある管理者から確認を受け取ります。その後、サービス開発者自身が計算プロセスを完全に制御します。 展開のために新しいサービスの統計を準備する時間は、文字通り1人のスペシャリストの数時間に短縮され、パッケージの新しいバージョンは数秒でレイアウトおよび展開されます。



検索結果ページの更新は続行されます：yandex.comとYandexの他のバージョンの両方-トルコ語からロシア語まで。 インターフェイスを含む多くの実験の計画があります。



ミハイル・トロシェフ 、

検索インターフェイス開発チームリーダー