Компания
408,21
рейтинг
13 августа 2012 в 15:07

Разное → Эксперимент со страницей результатов поиска

Страница результатов поиска — одна из самых популярных страниц Яндекса. Её загружают около 130 миллионов раз в день. Это при среднем размере страницы в 25КБ дает нам 3ТБ трафика в сутки.

Несмотря на кажущуюся простоту, за тем, из чего состоит эта страница, — огромная работа большого количества людей и много сложных технологий.

Развивая интерфейсы, обычно мы идём по эволюционному пути, меняем страницу поэтапно. Проверяем наши решения, внедряя их на небольшой процент пользователей, — проводим эксперименты. Нас уже не устраивают небольшие изменения: хотим развивать продукт, построив новую технологическую платформу, на которой в будущем будем реализовывать свои проекты.



Сегодня мы начинаем эксперимент с новой страницей результатов поиска. И для этого мы выбрали нашу площадку для тестирования поиска по мировому интернету — yandex.com. Первое, на что вы обратите внимание, когда увидите новую страницу — это отличие ее дизайна от текущей версии страницы результатов поиска на yandex.ru. Но этот эксперимент в первую очередь не про дизайн, а про реализацию значительных технологических изменений. Разумеется, над дизайном мы тоже работаем и планируем проверять новые решения, но построение нового начинается с качественного фундамента. Хотим рассказать, как именно мы его строили: какие решения принимали и какие использовали технологии.

Разработка шаблонов
Ещё до того, как появились первые картинки-макеты, нам нужно было определиться с подходом к разработке. Варианта было два: сверстать статическую страницу и порезать её потом на шаблоны или разрабатывать сразу на реальных данных и писать реальные шаблоны.

В общем случае, особенно если вёрсткой и разработкой шаблонов занимается одна команда, второй подход предпочтительнее. Он обеспечивает готовность проекта к релизу (или хотя бы к тестированию) в любой момент времени. То есть уже в самом начале разработки возникает «сырой», но уже функционирующий прототип проекта, который можно «потрогать». В итоге именно этот вариант мы и выбрали.

Сильно сократить время на разработку и тестирование первого прототипа помог наш механизм сборки проектов, основанный на методологии БЭМ (Блок-Элемент-Модификатор). Он позволяет подключать внешние библиотеки блоков, так что существенную часть интерфейса мы собрали из готовых блоков, которые уже есть на других сервисах Яндекса и лежат в разных внутренних git- и svn-репозиториях.

JavaScript везде
Под капотом у новой версии страницы результатов поиска — JavaScript-шаблоны. Они работают быстрее, чем шаблонизатор для языка Perl TT2, который мы использовали раньше, и писать их удобнее и проще. Сейчас на JS написаны два уровня шаблонизации, клиентские скрипты, утилиты и технологии сборки, демон-сборщик.

В настоящий момент для сжатия JS- и CSS-кода используется YUICompressor, который требует Java на сервере, поэтому в перспективе мы хотим перейти на JS-обфускаторы UglifyJS и CSSO — они работают быстрее и менее требовательны к ресурсам.

Использование одного языка на всех технологических уровнях, начиная c браузера и заканчивая утилитами сборки, сильно упрощает жизнь многим участникам процесса. Разработчики могут конфигурировать (а при желании и дописывать) инструменты для сборки, одинаково легко пишут код для клиента и сервера. Уже не требуется глубокое знание большого количества разных технологий, достаточно хорошо знать базовые: HTML, CSS, JS. Благодаря этому стало проще подключать новых людей в команду: JavaScript знают все фронтенд-разработчики в Яндексе, а серверную специфику можно освоить очень быстро.

AJAX, History API
Довольно давно стало «модно» использовать технику AJAX для обновления данных на странице без полной перезагрузки. Плюсы этой техники достаточно очевидны: не требуется каждый раз при обновлении данных грузить полностью всю страницу (разметку, стили, скрипты, картинки), инициализировать скрипты. Это сильно ускоряет процесс доставки новых данных до пользователя. Разница по скорости загрузки на медленных каналах — радикальная.

Однако, прекрасно понимая все плюсы AJAX, мы не спешили применять этот подход в Яндекс.Поиске. Мы хотели предложить нашим пользователям не просто технологию, а целостный продукт с переработанным интерфейсом. Поэтому новая версия страницы результатов поиска потребует повсеместного применения AJAX и History API.

(Подробно о нашей реализации мы рассказывали 2 июня 2012 года в Минске на Я.Субботнике)

CSS
Изначально у нас не было цели использовать возможности CSS3 полностью, но почти все они оказались необходимы для решений наших задач. Стрелочки меню на трансформах, тени у блоков, псевдоселекторы first-child/last-child вместо классов-модификаторов — все это есть в новом интерфейсе. При этом для старых браузеров предусмотрена деградация: вместо теней — простые однопиксельные контуры, вместо стрелочек в меню — обычные прямоугольники, svg-градиенты в IE9 и сплошная заливка фона для IE8 и старше.

Ещё одним из важных решений было использование абсолютных единиц измерения для указания размеров шрифта. Практически на всех наших сервисах сейчас используется указание размеров в относительных процентах или тегах <em>, но в новом проекте мы решили отказаться от них в пользу пикселей. Аргументов у этого решения несколько. Во-первых, доля браузеров, которые не умеют масштабировать шрифты в пикселях, исчезающе мала. Во-вторых, размеры в абсолютных единицах исключают влияние контекста, а вёрстка абсолютно независимыми блоками — один из основных принципов БЭМ-методологии. Ну и в-третьих, страница результатов поиска должна нормально работать на тач-устройствах. Разрешение экрана на них часто заранее известно и строго фиксировано, а меняться может только его ориентация.

Деплой
Почти все наши проекты хранят свои статические файлы на статическом кластере — yandex.st. Это несколько десятков машин, расположенных в разных городах и странах, которые умеют очень быстро отдавать данные.
Причин для использования статического кластера несколько:
— не нужно генерировать файлы перед отправкой — всё уже готово и лежит на диске;
— для передачи готовых файлов достаточно лёгкого веб-сервера;
— не требуется высокая производительность машин;
— статика кэшируется навсегда, а инвалидация осуществляется либо изменением версии пакета, либо изменением хэш-суммы;
— на домен yandex.st не отправляются куки сервиса, это уменьшает объём трафика;
— «сквозные» файлы (использующиеся на нескольких сервисах, например jquery.min.js или логотип Яндекса) не нужно загружать каждый раз при переходе с сервиса на сервис.

Чтобы положить файлы сервиса на статический кластер, нужно собрать deb-пакет. Пакет собирается либо вручную, либо специальным скриптом. После сборки нового пакета заявка на выкладку отправляется в Кондуктор — наш внутренний инструмент, позволяющий без участия людей выложить пакет на сотни машин. Это очень важно, учитывая количество сервисов Яндекса и частоту их обновления.

Статический кластер — очень сложная система, которая решает множество задач оптимизации скорости работы браузера у клиента и доставки файлов пользователю. При этом пользоваться им очень просто: чтобы завести новый проект в Кондукторе, достаточно заполнить небольшую форму-заявку и получить подтверждение от ответственного администратора, после этого разработчик сервиса сам полностью контролирует процесс выкладки. Время на подготовку статики нового сервиса к деплою сокращается буквально до пары часов одного специалиста, а новая версия пакета выкладывается и развертывается за несколько секунд.

Обновление страницы результатов поиска будет продолжаться: как на yandex.com, так и на других версиях Яндекса – от турецкого до российского. У нас в планах много экспериментов, в том числе и с интерфейсами.

Михаил Трошев,
Руководитель группы разработки поисковых интерфейсов
Автор: @Zalina
Яндекс
рейтинг 408,21

Комментарии (32)

  • 0
    Потестим.
  • +1
    который требует Java на сервере, поэтому в перспективе мы хотим перейти на JS-обфускаторы UglifyJS и CSSO — они работают быстрее и менее требовательны к ресурсам.

    А какой-нибудь холиварчик по поводу того, что «JAVA очень быстрая» ожидается? :)
    • 0
      тут скорее не ява медленная, а yui компрессор ужасный тормоз. в большом проекте заменив его на другие, «менее продвинутые» компрессоры, написанные не важно на чём(ruby/js/php) можно сократить время сбори ассетов на порядок.
      • 0
        CSSO — гораздо более продвинутый компрессор :)
        • 0
          Мы сравнивали степень сжатия разными обфускаторами и увидели, что CSSO и Uglify жмут код лучше, но после gzip практически никакой разницы (на уровне десятых долей процента).
          Поэтому основной причиной отказа от YUICompressor была не степень сжатия, а время компрессии, т.к. мы хотим сократить время сборки статики до уровня риал-тайма.
          • 0
            А Google Closure Compiler жмет еще лучше чем Uglify, правда он тоже на Java :[
            А почему realtime? Зачем?
            • +1
              Чтобы не запускать сборку руками.

              Мы сейчас пишем bem-сервер, который будет подниматься над исходниками, проксировать http-запросы и собирать нужное по запросу. То есть будет как раньше: сохранил код — обновил страницу — увидел результат.

              Код выложен на Гитхабе: github.com/bem/bem-tools/blob/master/lib/server/server.js
              • 0
                Медленнее же чем статику просто так отдавать
                • 0
                  bem server это инструмент для разработки, в продакшен выкладывается полностью статическая версия собранная через bem make
                  • 0
                    Понял. Интересно, спасибо!
  • 0
    А как будет выглядеть выдача директа в данном варианте выдачи?
  • +1
    Мне нравится новая выдача с крупными иконками популярных сервисов. Вообще жаль что в статье нет ничего про юзабилити, надеюсь будет еще)

    Многие вещи пока опущены:
    Например Show more — это сколько там more? 3 страницы или 33 тыс. страниц.
    В search on Google, Bing можно смело добавлять Twitter и Facebook
    А еще расширенный поиск канул в Лету(
  • 0
    YUICompressor раньше умел обрабатывать за 1 вызов только 1 css/js файл. При 100 вызовах для обработки 100 файлов это медленно. Мы использовали костыль — склейка файлов (через специальный разделитель) в один, оптимизация и расклейка обратно. Это увеличивало скорость на порядок. Сейчас YUICompressor умеет обрабатывать по несколько файлов за 1 вызов. В настоящее время оптимизацию можно делать на той же серверной js платформе и не разводить зоопарк, т.к. его содержать дороже. Скорее всего NodeJS это делает не медленнее Java :-)
    • +1
      Мы тоже при сборке генерируем список файлов для обфускации, а потом один раз запускаем YUICompressor.
    • +1
      до того, как YUICompressor научился обрабатывать по несколько файлов за однин вызов мы делали этот патч сами во внутренней версии YUICompressor иначе было совсем не приемлемо медленно

      про скорость Node.js и Java вы правы ;-)
  • 0
    А вы используете slim или haml или в шаблонах неудобный SGML?
  • +2
    Очень странный интерфейс, зачем-то убрали фав-иконки — ради них во многом поиском яндекса и пользовался, разница выдаче с гуглом часто не так важна, как скорость ориентации в списке, фав-иконки позволяли очень быстро находить сайты в листе.

    Теперь это какие-то разношерстные логотипы справа, только для очень ограниченного списка популярных сайтов.

    В итоге мы имеем какой-то недоработанный гугл (по интерфейсу).
    • +4
      Спасибо за отзыв, над интерфейсом мы ещё работаем. История про фавиконки не закончилась, мы знаем как они важны и будем дорабатывать.
    • +1
      Поддержу насчет интерфейса. Очень нелепо, на мой взгляд, выглядит плашка слева. Как-то сиротливо сама по себе болтается. Ну и решение с разделением фона выдачи и страницы не очень удачно, как мне кажется. Если на русском Яндексе страница смотрится хотя бы как единое целое, то здесь вы здорово подчеркнули пустоту вокруг, а особенно справа.
  • 0
    При переходе из поиска по картинкам на поиск по видио сайт не отзывается. Например www.yandex.com/video/yandsearch?text=habrahabr
    • +1
      Спасибо, уже починили, скоро выкатим фикс.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    В Google Chrome в шапке глючек на странице результата поиска
    image
    • 0
      Спасибо, мы уже исправили этот баг, в ближайшем обновлении выкатится фикс.
  • 0
    Открыл в планшете — очень понравилось! Единственное, в opera mini (12.00/Android) поисковая строка на серпе ведет себя некрасиво: уезжает наверх вместе с выдачей, а потом иногда там и остается, а иногда неожиданно появляется снова.

    Открыл на десктопе — скучно и безлико. Почему-то напомнило сайты-заглушки на припаркованных доменах вида «komercant.ru — это наилучный источник информации по теме». Без номера
    • +2
      не дописал:

      по номерам результатов в выдаче скучаю почему-то.
  • +3
    Может быть я консерватор, но совсем непонравилось.
    Ощущение что зашел на какую-то альтависту с включенным АДблок.
    Русскоязычная версия нравится значительно больше.
    • 0
      Согласен. Может на планшете и удобно(не пробовал), но на 27" мониторе просто страх.
  • +2
    Результаты не пронумерованы. Ощущение вместо выдачи показана только реклама.
  • –1
    А звук на видео специально такой тихий, чтобы никто не услышал?
  • 0
    Зачем выдумывать новое непривычное оформление? Понятно же, что пользователям не понравится, и они не заметят технологических улучшений — они будут судить по дизайну в первую очередь.

    Почему не получается «посадить» на новые технологии существующий дизайн (что на yandex.ru)? Он вам не нравится и вы хотите прийти к чему-то новому? Просто не верится, что из-за сложности реализации.

    Как по мне, так текущее состояние рано оценивать. Вы себе статистику подпортите.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное