Вы устали от медленной загрузки сайтов? Ваша команда специалистов по поисковой оптимизации и технических специалистов постоянно спорит о том, какова правильная архитектура для скорости страницы? Что ж, мы тоже сделали это в Pickyourtrail, и мы также сузили решение для того же самого.
До того, как приложения JS были запущены в веб-мир, HTML возвращался в ответ на HTTP-вызов. Это было сделано путем рендеринга файла статического HTML-содержимого, а иногда и путем составления ответа с использованием серверных языков, таких как PHP, Python или Java, и более эффективного реагирования на них. Из-за этого сохранялись такие проблемы, как низкая скорость страницы и загрузка половины страницы. В основном эти случаи были побочным эффектом рендеринга на стороне клиента.
Как работает рендеринг на стороне клиента?
Хорошо, если вы являетесь суперновой с технической точки зрения, мы уверены, что вы знакомы с концепциями рендеринга. Для других вот ваше объяснение!
Рендеринг на стороне клиента - это когда HTML-документ вместе с JS-файлом будет отображать остальную часть веб-сайта с использованием браузеров. В современных веб-фреймворках, таких как React, браузер получал пустой документ со ссылками на java-скрипт, а затем начинался рендеринг, в результате чего загрузка страницы становилась непоследовательной. Начальная загрузка страницы будет медленной, и, поскольку скорость сети не является чем-то, на что мы можем рассчитывать, для каждой загрузки, которая будет завершена, требуется около двух циклов до конца сервера, прежде чем контент будет показан пользователю. Но. Следует иметь в виду, что после первой загрузки (более продолжительной) последующие загрузки будут очень быстрыми.
Дальнейшая разбивка:
Шаг 1. Браузер запрашивает страницу
Шаг 2. Браузер запрашивает наш JS
Шаг 3. Приложение React загружается, запрашивает данные у серверной части.
Шаг 4. Контент, отображаемый на экране
Первоначальный запрос сервера возвращает пустой HTML-файл до того, как внешние файлы будут извлечены для рендеринга. Из-за этого есть огромная вероятность того, что сканеры могут интерпретировать страницу как пустую. Кроме того, время ожидания для пользователей будет больше, поскольку им нужно ждать более длительный период времени для первоначального рендеринга.
Больше времени ожидания = пользователи теряют интерес и покидают страницу
Ужасно обнаруживать низкую среднюю продолжительность сеанса, верно?
Pickyourtrail, представляющий собой одностраничное приложение (SPA) - наша более ранняя реализация веб-сайта с приложением клиентского рендеринга (CSR) привела к медлительности и непоследовательности SEO. Кроме того, мета-заголовки и описание наших страниц не сканировались, а это означало, что наша страница отображалась неправильно.
Ранее в этом году Google опубликовал отчет, в котором они пришли к следующему выводу:
«Среднее время, необходимое для полной загрузки целевой мобильной страницы, составляет 22 секунды. Однако исследования также показывают, что 53% людей покидают мобильную страницу, если она загружается дольше 3 секунд ».
Как работает рендеринг на стороне сервера?
У нас есть интересы клиентов, такие как предпочтительные виды деятельности, зафиксированные с помощью машинного обучения и других необходимых вещей, таких как авиабилеты, отели, трансферы и мероприятия, интегрированные в продукт с использованием API. Наш сайт Pickyourtrail построен на React во внешнем интерфейсе с использованием концепции Node. Но мы не могли извлечь из этого максимальную пользу из-за проблем с медленной загрузкой страниц.
Поскольку «Результаты превыше причин» является одной из наших основных ценностей, мы рассмотрели сагу о медленных страницах в более широкой перспективе и выделили рендеринг на стороне сервера.
Решения Pickyourtrail для выявления узких мест в производительности
- Оптимизировать CSR, чтобы приложение отображалось достаточно быстро, чтобы сканеры могли сканировать фактическое содержимое.
- Для реализации SSR для первоначального рендеринга приложения и гидратации на стороне клиента для дальнейших взаимодействий.
После многочисленных обсуждений и A / B-тестов мы махнули зеленым флагом для рендеринга на стороне сервера (SSR).
Рендеринг на стороне сервера - это когда пользователь или сканер поисковой системы сначала запрашивает наш браузер, и начальный рендеринг запускается. Как только сервер получает запрос, он преобразует требуемый элемент (ы) в строку HTML, а затем назначает его в качестве ответа клиенту. Позже, если вы решите посетить отдельную страницу на веб-сайте, ваш браузер сделает еще один запрос для получения новой информации. Это будет происходить каждый раз, когда вы попадаете на страницу, в вашем браузере нет кешированной версии.
Опять же, если вы техническая сверхновая, читая это, вы можете перейти к следующему разделу. Для других, однако, вот как работает SSR -
- Браузер запрашивает страницу
- Сервер загружает React в память
- Сервер получает необходимые данные
- Сервер отображает приложение React
- Сервер отправляет сгенерированный HTML-код в браузер
- Сканер / пользователь просматривает контент
- Вызов файла JS
- Приложение React загружается, запрашивает данные с серверной части
- Приложение перерисовывает (гидратирует) на экране.
Какую пользу нам принесла реализация SSR?
- Более быстрое время загрузки для начального рендеринга страницы
- Полностью индексируемые HTML-страницы.
- Повышение производительности для наших клиентов
- Согласованность в показателях SEO
Лучшая новость заключается в том, что сканеры теперь будут видеть наш веб-сайт, как любой другой статический сайт в Интернете, и будут индексировать весь контент, отображаемый на сервере. Теперь пользователю не нужно ждать загрузки JS, и вместо этого он получает полностью отрисованный HTML.
Из полного рендеринга страницы только на 7-й секунде время ожидания сократилось до 4 секунд. Магия? Неее тек;)
Некоторые потенциальные подводные камни предлагаемого решения
Ага, здесь мы очень честны! С другой стороны трава не всегда зеленее: /
SSR дает ожидаемый прирост производительности, и это правда, что мы будем передавать контент нашим пользователям быстрее, чем при использовании традиционного приложения React. Загвоздка в том, что это не масштабируемый прирост производительности.
В запросе SSR сервер и клиент работают почти одинаково. Он загружает React, отображает приложение и выводит HTML. Кроме того, метод renderToString (), который React использует для преобразования кода JSX в HTML, является медленным и синхронным. Это подвергает сервер большей нагрузке, и первоначальный ответ от сервера придет позже, чем запланированный HTML - как в традиционном приложении React.
Вы должны быть особенно осторожны, так как приложение будет запускаться сначала в среде Node, где, например, window и document не определены. Вы должны воздержаться от их использования вне `componentDidMount` или без` if (typeof window! = ‘Undefined’) `
Но лучшая сторона сложностей, вызванных SSR, заключается в том, что их можно исправить с помощью таких инструментов, как Next.js.
Глазурь на торте? - Теперь мы не только ускорили загрузку страниц, но и прекратили нескончаемые дебаты между командами. Так что типичный для нас беспроигрышный случай;)
Хотите работать в команде, где вы сможете не только решать технические проблемы, но и мгновенно получать отзывы клиентов о вашем решении? Мы будем рады видеть вас на борту. Напишите письмо на адрес [email protected], и мы свяжемся с вами. Кроме того, для любителей путешествовать, ожидающих отправиться в путешествие, посетите Pickyourtrail и начните планировать свои счастливые каникулы!
