(Измерения откликов запросов проводятся из России, рассматривается один типичный запрос: отель на семью из 3 человек на 4 дня в Праге. Таймлайны ответов смотрятся в Хроме. Интересует скорость отклика, богатство управления в интерфейсе.)
К ссылкам, принятым за основу (5 ссылок
www.booking.com
ostrovok.ru
www.onetwotrip.com/ru/#
www.doubletrip.com
www.kupibilet.ru
), можно добавить:
hotels.ru,и другие. На самом деле, таких сервисов — десятки, поскольку они придают популярности сайту и фирме-туроператору, содержащей такой сервис.
travel.ru,
iGlobe.ru,
www.otel.com,
Oktogo.ru,
transtour.ru,
hotelbook.ru
Сразу можно сказать, что сложность сервиса такого рода — не самая высокая, поэтому организация интерфейса по силам небольшой команде в 5-10 человек. Но наиболее продвинутые сервисы используют серверное кеширование и другие передовые решения, вследствие чего качество их находится на другом уровне по сравнению с конкурентами, малые команды такой подход «не потянут». Поэтому нас будут интересовать продвинутые подходы и то, «насколько безнадёжно» с ними конкурировать.
На зарубежных рынках также имеется очень богатый выбор сервисов, который следует в своё время пересмотреть, потому что решения могут оказаться более интересные, чем у российских разработчиков.
Европа-США:
Бронирование гостиниц:
www.hostelbookers.com
www.hostels.com
www.gomio.com
www.hrs.com
www.agoda.com
www.hotelclub.com
www.hotels.com
www.wotif.com
www.fastbooking.com
www.makemytrip.com/hotels
www.accorhotels.com
www.bookings-online.net
www.orbitz.com
www.hotelbook.com
www.trip.com
travel.yahoo.com
www.travelocity.com
Сравнение туров и рейсов:
www.skyscanner.net
www.expedia.co.uk
Поиск достопримечательностей и частных мелких отелей:
foursquare.com
www.blackbookmag.com/mobile
www.yelp.com
www.tripadvisor.com
Затем, не следует забывать цель, с которой мы будем делать обзор. Если сейчас вопрос состоит в фронтенд-движке у конкурентов, то исходная бизнес-задача может звучать как «найти лучшую стратегию продвижения своего сервиса среди конкурирующих», и тут может выйти на первый план не просто отработка запросов по отелям, а сервис типа сравнения отелей и мелких хозяйств, как это делает foursquare.com. Почему? Потому что среди сотни равных надо приобрести конкурентное преимущество. Дружественный поиск, отвечающий интересам посетителей — может быть одним из них.
Обзор выбранных 5 сайтов
Группа лидеров booking.com, ostrovok.ru известна огромными вложениями в инфраструктуру и команду разработчиков. Поэтому в их коде мы не видим решений быстрого проектирования и популярных библиотек. Роутинг при поиске организован не одностранично, а исходный код страницы показывает, что большое количество данных включено серверной стороной в страницу. Это обеспечивает быструю выдачу для любого браузера без необходимости повторять запросы к базам данных. В то же время, на их страницах присутствуют очень продвинутые многоплановые AJAX-запросы, вид которых нельзя однозначно отнести к какому-либо фреймворку. Этими запросами решается множество задач для подтягивания данных в страницу: запрос маршрутов, POI (Points of Interests) — гостиницы, отображение в сводной таблице и на карте, отрисовка фото апартаментов, фильтры отображения (клиентские или через новый запрос).
Для простоты, опишем анализ от простых сервисов к сложным.
http://www.kupibilet.ru
Сервис — несамостоятельный при поиске отелей, самостоятелен он лишь при поиске авиарейсов.
Поиск рейсов (в Прагу и обратно) занял 15 секунд запроса. Повторный поиск не кешировал первый точно такой же запрос и тоже занял более 15 секунд. Отрисовка — 0.5 с. Выполнен в виде POST-запроса на www.kupibilet.ru/search. Результат — сложный JSON, который заполнил результирующую таблицу (рейсы, дни, часы, пересадки и т.д.).
Стек технологий: jQuery, jQueryUI, плагины, Zingaya (онлайн-звонки), массив самописного кода, всё обфусцировано. MVC-фреймворков не замечено. Входная страница шаблонов для HTML не использует (генерирует код на сервере).
Выводы: запрос и обработку выполняет традиционно, построен сервис без современных технологий, примерно 2.5 года назад (jQuery 1.8.2). Шаблонизатор и MVC могли бы ускорить работу и разработку, а отсутствие jQueryUI — облегчило бы страницу.
Надо заметить, что запросы авиарейсов не требуют продвинутой архитектуры MVC — они выполняются традиционно, нажатием кнопки запроса. Пример действительно продвинутого подхода мог бы выглядеть как живая подача частей запросов и связывание данных «на лету» — уточнение страны, рейсов и т.д.. Но, насколько я знаю, ни один из сервисов сейчас не поддерживает такой подход, т.к. для этого требуется много серверных эвристических выборок из БД, а это тяжеловато для баз.
http://www.onetwotrip.com/ru
Поиск по рейсам. Post-запрос вида www.onetwotrip.com/_api/searching/startSync/?ad=1&cs=E&route=0104MOWPRG0504&_=1393342802726 занял 32 секунды, затем отрисовка хорошо выглядящего («вау») фронтенда — 3 секунды. Тормоза на бекенде могут говорить о более медленном бекенд-движке или его меньшей оптимальности, или о большем охвате баз (трудно судить). Состав фронтенда: jQuery 1.8.2, jquery.tmpl.min.js (непопулярный сейчас шаблонизатор, из-за медленности), ряд плагинов jQuery, данные упакованы в JS. MVC также отсутствует, но он и не требуется на этой странице. Но, видимо, понятна причина медленной отрисовки их весьма визуально хорошего результата: query.tmpl как медленный шаблонный движок в первую очередь и увлечение плагинами jQuery вообще.
Поиск по отелям у них — 300 мс на первый запрос, 5 сек на отработку каскадных запросов (карта, рисунки), 10 сек — вся отрисовка. Страница обновляется после поиска, подгружается много новых стилей и скриптов (40 файлов, без сжатия). Есть и jQueryUI.
Выводы.
Движок не оптимизирован на вывод страницы (не сжаты файлы), что помогает изучить его строение и использовать изобразительные средства у себя (много полезных имён библиотек); шаблоны лежат в главной. Дата создания — тоже 2.5 года назад. Одностраничность работает только на выводе авиарейсов, но в целом использованы более медленные решения, чем могли бы быть. Есть неоптимальная подгрузка рисунков комнат отелей — грузятся все, которые выше по скроллу, а не только те, которые во вьюпорте.
http://www.doubletrip.com/
Поиск рейсов — 35 секунд поиска и 15 секунд отрисовки. Формат отрисовки похож на onetwotrip.com. В отрисовке участвовали результаты 9 дополнительных аякс-запросов через jQuery. Технологии: Modernizr (совместимость новых CSS со старыми браузерами), все JS упакованы в файл весом 350К. (Устроено интересно, деобфусцировал, чтобы посмотреть дальше.) jQuery, jQueryUI версия 1.10.3, самая новая. Плагины типа работы с датами, календарём (такие у всех). Следов ключевых слов из MVC не найдено. Встречается упоминание Handlebars (шаблонизатора). Остальное построено на плагинах jQuery и ориентировано главным образом на отрисовку Вью-компонент. Напомню, что код обфусцирован, поэтому анализ затруднителен. Но супер-технологий здесь нет, не видно.
Поиск по отелям. Отрисовка — 5 секунд, запросы — 1 секунда. Строение вывода очень похоже на Островок, jQuery 1.8.2 и видно, что код собирали частично по другой технологии, но есть и непонятный сильно обфусцированный большой JS, как и в первом поиске. Скорее всего, это — все служебные коды для отрисовки таблиц для отелей и карты. Имеются большие массивы внедрённых инлайновых кодов, в которых, видимо, передаются данные Модели при загрузке страницы (типа 'singlepage_old': 'control', 'forced_test': 'test' и сотни других). Анализ лучше отложить на время после рассмотрения Островка (да там и дизайн форм схож.
Как и на Островке, применение фильтров не приводит к дозагрузке данных, фильтры работают с данными в странице. (В отличие от Booking.com.)
Выводы.
За кодом следят, миру не показывают, есть внешнее сходство с движком Островка. Выборка по отелям традиционно более быстрая, т.к. там меньше динамических данных в БД, чем по авиарейсам. Бекенд физически может отдать данные быстрее, поэтому остальное тратится на отрисовку. Нигде пока нет MVC-технологий, как можно дознаться, исходя из анализа запросов и кода. Основная сила везде — отрисовка с помощью jQuery и не слишком сложные аякс-запросы перед ними. Здесь повторный поиск по отелям происходит без смены страницы (обновление за 2 секунды). Код говорит о том, что это — клон Островка.
https://ostrovok.ru/
Просмотр кода говорит, что на примере doubletrip.com/ мы его уже анализировали. Не будем терять время на поиск различий. Но надо заметить, что поиск по рейсам в Островке позиционируется с сайтом kupibilet.ru, а в нём поиск организован иначе — не так, как на doubletrip.com/. Но и то, и другое уже проанализировали. На Островке видим просто иную комбинацию движков поиска (без вопросов о том, что — чьё).
http://www.booking.com/
Отели. Все запросы прошли за 400 мс и привели к перезагрузке страницы, 10 сек — отрисовка. Последующий запрос её не перезагружает, 3 сек — отрисовка. Повторный поиск со стартовой использует кеш браузера, поэтому новая отрисовка результатов поиска происходит также на 3 секунды, но время до перезагрузки (первый запрос) — 4 секунды.
Поиск авиарейсов отсутствует.
Анализ кода. Очень много кода и стилей в инлайне (в коде HTML). Что не слишком полохо, но, видимо, есть наследие старых техник разработки. Эту страницу надо сгененрировать на сервере, что однозначно дольше, чем если бы собрать её из статических компонент. Поэтому мы и ждём 4 секунды до начала загрузки этой страницы. Это многовато, хотя в данном случае мала вероятность, что пользователь куда-то убежит — перед этим он старательно вводил данные для поиска, а первая страница сделана хорошо и аккуратно.
jQuery 1.4.4 (2010 года основа), Dropdown/tooltip lib (Artur Burtsev), jquery-hashchange-plugin, accounting.js 2011 года, jquery-popunder, кроме того, очень много собственной обфускации, примерно 500-700 К JS. Шаблонизатор Handlebars v1.0.12 2011 года. jQuery UI 1.8.6, тоже старый.
Кстати, подгрузка данных на всех сайтах почти как по MVC есть в области подсказок рейсов и дат (виджеты календарей). Но все мы знаем, что подобные виджеты работают сами по себе, без MVC-основы под ними. Поэтому и здесь мы можем не рассчитывать встретить MVC-либы на клиенте сайта.
Выводы.
Код сделан не по лучшим практикам оптимизации. Лейаут не отрисовывается в начале загрузки. Пока эти 700 К кода в середине страницы не прогрузятся, страница не отрисуется. Сам объём HTML в данном случае — ещё 660К. Основу кода не обновляли с 2011 года, в архитектуре обновление, скорее всего, не заложено, в отличие от doubletrip.com/, где мы видели довольно новые версии компонентов. Стало быть, сайт не использует возможности технологий для получения преимуществ — они своё взяли другим. Например, они были первыми. С сайтом можно знакомиться как с примером некоторых неоптимальных решений, чтобы подумать о том, как не попасть в такое же положение в процессе разработок.
Общие выводы: ни один из рассмотренных сайтов не использует практики библиотек MVC для обмена данными с бекендом, если не считать исторически традиционного AJAX при повторных поисках на страницах отелей и авиарейсов. Часто видны неоптимальные решения и пристрастие к jQuery UI, которая нужна для календарей и подсказок, но тяжеловесна, и отъедает свою долю траффика (в рабочей конфигурации — 150-500 К кодов). Довольно грамотными кажутся клоны Островка, но построены они по тем же принципам, описанным в частных выводах по каждому сайту.
Мнение о конкурентной среде: Эта группа сервисов привлекает в реализации очень широкий слой предпринимателей. Наряду с топовым сервисами, на развитие которых привлекается буквально миллионы долларов и строение фронтендов которых сейчас рассмотрели, есть десятки попыток сделать аналоги и достичь некоторых смежных целей. Из-за наличия ряда открытых и часто бесплатных API для информирования о рейсах и отелях, сбор и публикация сведений оказывается выполнимой для мелкой фирмы задачей, которая может представить туриситическую фирму или портал в выгодном свете среди конкурентов. Но не стоит забывать и о топовых проектах, по которым наглядно видно сколько средств было вложено на тот интерфейс и юзабилити, которое мы у них видим, и сравнить класс начинающих игроков на этом поле.
Также, с точки зрения разработчика, можно увидеть, что организованы топ-сайты не по высшим меркам современных лучших практик, и здесь стартаперам можно надеяться на небольшой выигрыш в соревновании с теми, кто «брал не уменьем, а числом». Нельзя переоценивать значение архитектуры: в лидерах — не те, которые имеют красивый и современный код, а те, которые вложили больше денег в разработку. Понимание архитектуры у разработчиков, конечно, есть, но неотражение её в кодах говорит о том, что писать по высшим стандартам — не главное в успехе дела. (Что, впрочем, нисколько не открытие для бизнеса.)
