Композитный сайт и Ruby on Rails

С легкой руки маркетологов 1С Битрикс в рунете появился новый термин “композитный сайт”. Давайте попробуем разобраться, что вложено в это понятие и как можно достичь аналогичных результатов не используя платформу Битрикс. В нашем случае речь пойдет о Spree Commerce и Ruby платформе в целом. Никаких холиваров, разоблачений и прочего, просто небольшой анализ, что же из себя представляет технология “композитный сайт”.

Итак, как описывают технологию композитный сайт, её создатели из 1С Битрикс:

  • страница разделяется на две функциональных части: статическая и динамическая;
  • статическая часть кешируется и отображается практически мгновенно;
  • динамическая часть обновляется в фоновом режиме и кешируется на стороне пользователя.

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

Что можно можно отнести к динамическому контенту, несколько примеров:

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

Примеров на самом гораздо больше, но это вероятно самые простые и часто встречающиеся из них.

Суть технологии в том, что в шаблонах секций, из которых создаётся динамическая страница, размечаются зоны, в которых содержится динамический контент. При обращении пользователя к странице статическая часть страницы кешируется, из секций с динамическими данными уходят запросы к серверу за актуальными данными, реализация на JS (ajax). При повторном обращении пользователя сервер отдаёт созданный файл из кеша, а затем обновляется динамический контент.

Рассмотрим процедуру работы композитного сайта (мы не применяли этот термин ранее, но получается, что на практике использовали все эти методологии) на простом примере, на примере интернет магазина Простоаудио (http://prostoaudio.ru/), созданного на базе платформы 1R Commerce (это по сути форк Spree Commerce, с полноценной интеграцией с 1С, платформа создана нашей командой JetRuby Agency).

prostoaudio

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

  • Корзина;
  • Вход.

Давайте посмотрим как будет вести себя страница, без динамически обновляемых блоков, т.е. нет у нас отдельных запросов и для того что бы обновить любую информацию на странице потребуется полная перезагрузка страницы. Сервер получая запрос, собирая страницу для выдачи пользователю, выполняет следующие операции:

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

В таком классическом случае время от запроса и до получения пользователем страницы может достигать нескольких секунд, это зависит от контента страницы: числа и сложности серверного Ruby кода, формирующего страницу. В данном случае время формирования страницы около 500 ms. Из которых собственно отображение страницы занимает примерно 30 ms. Затем загружаются css стили, прочие файлы и реально вся страница видна пользователю примерно через 800 ms от момента отправки запроса на сервер.

Теперь рассмотрим поведение страницы при применении технологии композитный сайт или её аналогов без названия :), в народе именуются эти аналоги как оптимизация скорости загрузки страницы и включает в себя массу мероприятий для ускорения загрузки страницы, но не будем отвлекаться рассмотрим эти мероприятия применительно к Spree Commerce и Ruby on Rails в отдельной статье.

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

  • для динамических зон добавляется js код, который будет выполнять обновление;
  • высчитывается контрольная сумма страницы,
  • сохраняется в кеше, на жёстком диске сервера сформированный для первого пользователя html-код страницы.

Для второго и следующих посетителей действия будут следующими:

  • Пользователь запрашивает страницу.
  • На стороне сервера проверяются права пользователя на получение страницы, подключена ли страница к системе композитного кеша, наличие собственно файла кеша. Если все условия выполнены, то запускаются на исполнение следующие параллельные действия:
    • Сервер отдает пользователю сохранённый на html-код страницы из кеша.
    • JS код для динамических зон отправляет фоновый для пользователя запрос для актуализации данных.
    • Получив второй запрос веб-сервер в фоновом для пользователя режиме исполняет страницу.
    • В завершении выполнения страницы:
      • Пересчитывается контрольная сумма созданной страницы.
      • Обновляется страница в кеше, если контрольная сумма не совпадает.
      • Обрабатывается динамическая часть, без статики.
      • Собираются дополнительные данные (не обязательная процедура).
    • Загрузчику отдаётся контент (это может быть и JSON).
    • Загрузчик вставляет контент и выполняет JS код.

В итоге пользователь получает сохранённую страницу из кеша всего за 20 ms из которых собственно отображение страницы занимает 5 ms. Затем загружаются css стили, медиа контент (изображения, видео. аудио) и в результате страница полностью отображается за рекордные 300 ms. Данные актуализируются примерно через 600 ms, выполняется JS код, но визуально замена старых данных на актуальные, пользователь не замечает.

Как вы видите технология по факту не новая, но маркетингу 1С нужно отдать должное, свою функцию они выполняют на пять баллов. Можно утверждать, что подобной оптимизацией скорости загрузки занимались и будут заниматься все разработчики, независимо от используемого языка разработки (PHP, Ruby, Python), независимо от используемого фреймворка (Zend, Ruby on Rails, Django), независимо от используемой CMS (WordPress, OpenCart, Spree Commerce, Django CMS, 1С Битрикс). Цель общая — отдавать страницу пользователю как можно быстрее, путей и методов достижения этой цели достаточно много, их стоит комбинировать и выбирать оптимальные варианты под каждый конкретный проект.

У нашей команды JetRuby Agency накоплен большой опыт разработки веб проектов на базе фреймворка Ruby on Rails и вопросы оптимизации скорости загрузки страниц и скорости фоновой обработки данных возникали постоянно. Если вам требуется разработать композитный сайт на Ruby on Rails, то наша команда с удовольствием поделится своим опытом и знаниями для создания качественного продукта по вашим требованиям, при этом с большой долей вероятности у нас получится сэкономить вам бюджет и время.

Оставайтесь с нами, читайте наш блог. В дальнейшем мы посвятим как минимум одну статью, в которой рассмотрим некоторые варианты оптимизации скорости загрузки страницы проекта созданного на Ruby on Rails в чистом виде или же на базе Spree Commerce.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *