Улучшите время загрузки веб-страницы с помощью правильного метода визуализации. Поймите разницу между рендерингом на стороне клиента и на стороне сервера для оптимального взаимодействия с пользователем.
Быстрее время загрузки веб-страницы играет важную роль во взаимодействии с пользователем и поисковой системе поисковых систем, а скорость загрузки страницы является ключевым определяющим фактором для алгоритма Google.
Интерфейсный веб-разработчик должен решить, как лучше всего отобразить веб-сайт, чтобы он обеспечивал быструю работу и динамическое содержимое.
Два популярных метода рендеринга включают рендеринг на стороне клиента (CSR) и рендеринг на стороне сервера (SSR).
Все веб-сайты имеют разные требования, поэтому понимание разницы между воспроизведением на стороне клиента и сервером может помочь вам отобразить веб-сайт в соответствии с вашими бизнес-целями.
Google & amp; JavaScript
Google имеет обширную документацию о том, как он обрабатывает JavaScript, и сотрудники Google предлагают статистику и отвечают на вопросы о JavaScript регулярно в разных форматах – как официальные, так и неофициальные.
Например, в подкасте «Search Off The Record» говорилось, что Google отображает все страницы для поиска, включая содержащие много JavaScript.
Это вызвало значительный разговор на LinkedIn, и еще несколько выводов как из подкаста, так и из дальнейших обсуждений:
- Google не отслеживает, насколько дорого обходится воспроизведение конкретных страниц.
- Google воспроизводит все страницы, чтобы увидеть содержимое – независимо от того, использует ли он JavaScript или нет.
Этот разговор в целом помог развеять много мифов и ложных представлений о том, как Google может подойти к JavaScript и распределить ресурсы.
Полный комментарий Мартина Сплитта на LinkedIn об этом:
“Мы не’не отслеживаем “насколько дорогой для нас была эта страница?” что ли. Мы знаем, что значительная часть Интернета использует JavaScript для добавления, удаления и изменения содержимого веб-страниц. Нам просто нужно произвести визуализацию, чтобы увидеть все это. На самом деле не имеет значения, использует страница JavaScript или нет, потому что мы можем быть достаточно уверены, что увидим все содержимое только после того, как оно будет отображено.”
Мартин также подтвердил наличие очереди и потенциальную задержку между сканированием и индексированием, но не только потому, что что-то JavaScript или нет, и это не является “непрозрачным” Проблема заключается в том, что наличие JavaScript является основной причиной того, что URL-адреса не индексируются.
Общие практические советы по JavaScript
Перед тем, как мы начнем дискуссию на стороне клиента против сервера, важно, чтобы мы также придерживались общих лучших практик для любого из этих подходов к работе:
- Не блокируйте ресурсы JavaScript с помощью Robots.txt или правил сервера.
- Избегайте блокировки визуализации.
- Избегайте ввода JavaScript в DOM.
Что такое рендеринг на стороне клиента и как он работает?
Воспроизведение на стороне клиента — это относительно новый подход к воспроизведению веб-сайтов.
Он стал популярным, когда библиотеки JavaScript начали интегрировать его, с Angular и React.js, которые являются одними из лучших примеров библиотек, используемых для такого типа визуализации.
Это работает, воспроизводя JavaScript веб-сайта в вашем браузере, а не на сервере.
Сервер соответствует простым HTML-документом, содержащим файлы JS, вместо получения всего содержимого из HTML-документа.
Хотя начальное время загрузки немного медленное, последующие загрузки страниц будут быстрыми, поскольку они не зависят от другой HTML-страницы для каждого маршрута.
От управления логикой до получения данных с API, клиентские визуализированные сайты делают все “независимо.” Страница становится доступной после выполнения кода, поскольку каждая страница, которую посещает пользователь, и ее соответствующий URL создаются динамически.
Процесс CSR выглядит следующим образом:
- Пользователь вводит URL-адрес, который желает посетить, в адресную строку.
- Запрос данных посылается на сервер по указанному URL-адресу.
- При первом запросе клиента относительно сайта сервер доставляет статические файлы (CSS и HTML) в браузер клиента.
- Браузер клиента сначала загрузит содержимое HTML, а затем JavaScript. Эти HTML-файлы подключают JavaScript, начиная процесс загрузки, отображая пользователю символы загрузки, определенные разработчиком. На этом этапе веб-сайт еще не виден для пользователя.
- После загрузки JavaScript содержимое динамически генерируется в браузере клиента.
- Веб-контент становится видимым, когда клиент перемещается и взаимодействует с веб-сайтом.
Что такое рендеринг на стороне сервера и как он работает?
Визуализация на стороне сервера является более распространенной техникой отображения информации на экране. и отправляет полностью воспроизведенную HTML-страницу клиенту.
Каждый раз, когда пользователь посещает новую страницу на сайте, сервер повторяет весь процесс.
Вот как шаг за шагом происходит процесс SSR:
- Пользователь вводит URL-адрес, который желает посетить, в адресную строку.
- Сервер предоставляет готовый к воспроизведению HTML-ответ браузеру.
- Браузер отображает страницу (теперь доступную для просмотра) и загружает JavaScript.
- Браузер выполняет React, таким образом делая страницу взаимодействующей.
Какая разница между рендерингом на стороне клиента и на стороне сервера?
Основное отличие между этими двумя подходами визуализации заключается в алгоритмах их работы. CSR показывает пустую страницу перед загрузкой, тогда как SSR отображает полностью отрендерированную HTML-страницу во время первой загрузки.
Это дает преимущество скорости воспроизведения на стороне сервера перед воспроизведением на стороне клиента, поскольку браузеру не нужно обрабатывать большие файлы JavaScript. Содержимое часто становится видимым в течение нескольких миллисекунд.
Однако визуализация на стороне клиента является более дешевым вариантом для владельцев веб-сайтов.
Это снимает нагрузку на ваши серверы, передавая ответственность за рендеринг клиенту (боту или пользователю, пытающемуся просмотреть вашу страницу). Он также предлагает богатое взаимодействие с сайтом, обеспечивая быстрое взаимодействие с веб-сайтом после начальной загрузки.
С помощью CSR к серверу посылается меньше HTTP-запросов, в отличие от SSR, где каждая страница отображается с нуля, что приводит к более медленному переходу между страницами.
SSR также может выйти из строя под высокой нагрузкой на сервер, если сервер получает много одновременных запросов от разных пользователей. загрузки. Это может повлиять на SEO; сканеры могут не дождаться загрузки содержимого и выйти из сайта.
Этот двухэтапный подход повышает вероятность увидеть пустое содержимое на вашей странице из-за отсутствия содержимого JavaScript после первого сканирования и индексации HTML страницы. Помните, что в большинстве случаев CSR требует внешней библиотеки.
Когда использовать рендеринг на стороне сервера
Если вы хотите улучшить свою видимость в Google и получить высокий рейтинг на страницах результатов поисковой системы (SERP), визуализация на стороне сервера является выбором номер один.
Веб-сайты электронного обучения, онлайн-рынки и программы с простым пользовательским интерфейсом с меньшим количеством страниц, функций и динамических данных выиграют от этого типа воспроизведения.
Когда использовать визуализацию на стороне клиента
Воспроизведение на стороне клиента обычно сочетается с динамическими веб-приложениями, такими как социальные сети или онлайн-мессенджеры. Это потому, что эти программы’ информация постоянно меняется и должна работать с большими и динамическими данными, чтобы выполнять быстрые обновления в соответствии с требованиями пользователей.
Основное внимание здесь сосредоточено на насыщенном сайте со многими пользователями, предпочитая взаимодействие с пользователем, а не SEO.
Что лучше: рендеринг на стороне сервера или клиента?
Определяя, какой подход самый лучший, вам нужно не только учитывать ваши потребности в SEO, но и то, как веб-сайт работает для пользователей и обеспечивает ценность.
Подумайте о своем проекте и о том, как выбранное отображение повлияет на вашу позицию в результатах поиска и взаимодействия с пользователем вашего веб-сайта.
CSR лучше подходит для динамических веб-сайтов, тогда как SSR лучше всего подходит для статических веб-сайтов.
Частота обновления содержимого
Веб-сайты, содержащие очень динамичную информацию, такие как веб-сайты азартных игр или FOREX, обновляют свое содержимое ежесекундно, а это означает, что вы скорее всего выберете CSR вместо SSR в этом сценарии – или выберите использование CSR для конкретных целевых страниц, а не для всех страниц в зависимости от вашей стратегии привлечения пользователей.
SSR более эффективно, если содержимое вашего сайта не требует много взаимодействия с пользователем. Это положительно влияет на доступность, время загрузки страницы, SEO и поддержку социальных сетей.
С другой стороны, CSR отлично подходит для обеспечения экономически эффективного рендеринга для веб-приложений, и его легче создавать и поддерживать; это лучше для задержки первого ввода (FID).
Другим замечанием CSR является то, что мета-теги (описание, заголовок), канонические URL-адреса и теги Hreflang должны воспроизводиться на стороне сервера или представляться в исходном ответе HTML, чтобы сканеры могли их быстрее идентифицировать, а не только отображаться во время воспроизведения HTML.
Рассмотри платформы
Технология CSR, как правило, дороже в обслуживании, поскольку почасовая ставка для разработчиков, имеющих опыт работы с React.js или Node.js, обычно выше, чем для разработчиков PHP или WordPress.
Кроме того, доступно меньше готовых плагинов или готовых решений для фреймворков CSR по сравнению с большей экосистемой плагинов, к которой также имеют доступ пользователи WordPress.
Для тех, кто рассматривает безголовую настройку WordPress, например, с помощью Frontity, важно отметить, что вам нужно будет нанять как React.js-разработчиков, так и PHP-разработчиков.
Это потому, что безголовый WordPress полагается на React.js для интерфейса, но требует PHP для серверной части.
Важно помнить, что не все плагины WordPress совместимы с безголовыми настройками, что может ограничить функциональность или требовать дополнительной специальной разработки.
Функциональность веб-сайта & Назначение
Иногда вам не нужно выбирать между двумя, поскольку доступны гибридные решения. Как SSR, так и CSR можно реализовать на одном веб-сайте или веб-странице.
Например, на онлайн-рынке страницы с описанием продукта могут воспроизводиться на сервере, поскольку они статические и их нужно легко индексировать поисковыми системами.
Оставаясь на электронной коммерции, если у вас есть высокий уровень персонализации для пользователей на нескольких страницах, вы не сможете воспроизвести SSR содержимое для ботов, поэтому вам нужно будет определить определенную форму содержимого по умолчанию для Googlebot, которое сканирует без файлов cookie и без состояния.
Страницы, такие как учетные записи пользователей, не требуют рейтинга на страницах результатов поисковой системы (SERP), поэтому подход CRS может быть лучше для UX.
I CSR, и SSR являются популярными подходами к воспроизведению веб-сайтов. Вы и ваша команда должны принять это решение на начальном этапе разработки продукта.