Интернет-магазин и скорость переключения страниц
Разбираемся как организовать переключение страницы в 0,1 секунды и вызывать ВАУ у покупателей.
Цели были заданы в прошлой статье и прежде чем начать писать код, нужно выбрать инструменты, продумать архитектуру будущего магазина, чтобы он соответствовал нашим целям.
Чтобы обеспечить генерацию страницы в 0,1 секунды, генерация страницы на сервере нам не подходит. Ожидание ответа сервера будет слишком долгим. Пока браузер определить ip адрес сервера, отправит заголовки запроса и дождется отклика, пройдет очень много времени.
Чтобы обеспечить быстрое отображение, нужно действовать по этапно, в первую очередь загрузить простой html файл микро-размера с подключенными библиотеками и стилями, затем будут загружаться библиотеки и код конкретной страницы, а затем и список товаров. Кажется что много шагов и займет это кучу времени, по факту же при каждом шаге пользователь будет видеть каки-то интерфейсные элементы и будет создаваться впечатление быстрой загрузки.
Первая загрузка будет отнимать значительное время, т.к. модули будут тянуться с интернета. Но загрузив этот самый стартовый html, js библиотеки и код страниц, а также загрузив часть товаров, которые нужно отобразить на странице, страница будет отображаться молниеносно.
Само собой при генерации страницы на сервере можно добиться также неплохих скоростей, используя кэш страницы, переданной ранее, но как только измениться состав данных страницы, например поменялась цена, то страницу придется ждать новую.
Реактивная же страница загружает страницу из кэша браузера, отображая ранее полученный список товаров, параллельно уточняя у сервера, есть ли новые данные с последнего запроса, если нет, то ничего и не произойдет. Если есть несколько новых товаров, то тут несколько вариантов, если критично, то можно как в ВК отобразить небольшой всплывающее сообщение о том что можно получить актуальные данные и по нажатию обновить список товаров, либо же если это позволительно в этом типе товаров, отобразить обновленный список в следующий просмотр списка товаров или например при смене фильтра.
Давайте еще поговорим о формате передачи данных и их существенное различие. При генерации страницы на сервере у нас есть вариант только с http/https, который подразумевает передачу большого объема заголовков, которые парой и не нужны каждый раз, отсюда большие задержки. В реактивном же исполнении вариантов больше, мы подключимся к серверу по сокету, т.е. обеспечим такое непрерывное соединение, по которому сайт будет общаться с сервером в режиме реального времени.
Давайте рассмотрим на примере этот подписной формат общения подробнее. Клиент имея предыдущий список товаров, помнит дату обновления этого списка и подключившись к серверу один раз при запуске сайта, подписывается на изменения списка товаров от даты последнего изменения, соответсвенно если такие изменения по ходу работы сайта появятся они тут же будут доставлены в браузер. Причем речь только об изменении, изменилось название одного товара, придет только новое название и именно этого товара, сайт запомнит дату обновления, далее алгоритм повторяется. И само собой речь о той самой обработке в режиме реального времени которую мы привыкли видеть в мессенджерах, т.к. принцип обмена аналогичен.
С точки зрения стека технологий, знакомый мне NodeJS позволяет организовать такой формат общения сайта и сервера. С точки зрения хранения кэша товаров буду использовать каскад серверов с Redis или MongoDB. Такой формат общения сайта с севером обеспечит нам 1000 RPS (хитов в секунду) при меньших затратах и не затрагивая архитектуру вашего текущего магазина.
Комментарий недоступен