Что такое пререндер
Перейти к содержимому

Что такое пререндер

  • автор:

Rendering или визуализация

rss youtube канал vk twitter

Rendering (отрисовка или визуализация) — это процесс создания (просчет) кадра или некоего изображения при помощи определенных программ.

Сейчас под словом «рендер» понимают любой просчет картинки, будь то просчет сцены в 3д пакетах или кодирование видео в монтажных программах. Русификаторы усилено переводят это слово как «визуализация», но оно достаточно громоздкое, для каждодневного использования, поэтому в обиход вошло слово именно «рендер»

Пример построения 3D модели

Rendering чайника

Так же понятие рендеринг делиться по категориям.

Пре-рендеринг («пререндер») — это достаточно долгий и медленный процесс визуализации, служащий обычно для просчета сцены в оперативную память, который позволяет оценить вид кадра (сцены), до финального рендера.

Финальный рендер — как говорит нам название, это завершающий финальный рендер, который в итоге предоставляем нам видео или растровую картинку.

Смотрите также:

  • Анимация и отрисовка линий с помощью Sketch&Toons
  • Пиксель
  • After Effects error:(-1610153453)
  • Шаблоны модуля вывода в АЕ
  • Организация работы с проектом в АЕ

Похожие статьи:

  • ISO
  • Векторное изображение
  • Растровое изображение
  • Цифровой и оптический зум
  • Макросъемка

Не пропустите:

  • Технология CUDA
  • Что такое Time lapse?
  • Slow motion, замедления, рапид.
  • Matte painting
  • High Dynamic Range Imaging (HDRI или HDR)

У Вас недостаточно прав для добавления комментариев.
Регистрируемся,а потом можно будет писать.

Пререндеринг или Серверный рендеринг?

Привет, Хабр! Все знают что для того, чтобы ваш сайт увидели поисковые роботы вам нужен SSR. Но единственное ли это решение? Всегда ли он нужен? Есть ли другие варианты роботам увидеть контент? Что мы можем выиграть от альтернатив?

В этой статье рассмотрим альтернативное решение для SSR, а именно Динамический рендеринг (он же Пререндеринг).

* SSR имеется ввиду с регидрацией.

Какую проблему мы решаем?

Есть два способа генерации контента веб сайта:

  • Серверный — генерируется программой на стороне сервера. Для генерации такого контента на стороне сервера должна работать ваша программа.
  • Клиентский — генерируется скриптом на стороне браузера. Для генерации такого контента на стороне сервера программа не нужна, достаточно сервера статики.

На самом деле есть еще 4 смешанных варианта, но о них позже.

Оба метода имеют свои плюсы и минусы. Большой минус серверного рендеринга заключается в том что веб сайт получается «не живой». В нем мало интерактивных элементов, переход по страницам крайне неприятен и занимает много времени. Но такой контент видят поисковые роботы. Большой минус клиентского рендеринга это отсутствие видимости для роботов. Роботы такой контент просто не видят. Только недавно Гугл и Яндекс научились видеть такой контент, но скорость такой индексации оставляет желать лучшего. Но зато такой веб сайт «живой». В нем много интерактивных элементов и переходы по страницам мгновенны для пользователя.

SSR является компромиссным вариантом и объединяет в себе подходы серверного и клиентского рендеринга. Он с начало рендерит страницу на сервере, потом оживляет ее при рендеринге на клиенте. Таким образом поисковые роботы видят контент, а клиенты получают живой и интерактивный сайт.

Но помимо плюсов у данного подхода есть и минусы. И далее мы сравним плюсы и минусы подходов Пререндеринга и SSR.

Что такое Пререндеринг?

Если SSR является компромиссным вариантом выдающий одинаковый результат для пользователей и роботов, то пререндеринг это бескомпромиссный вариант. Который позволяет выдать роботам и клиентам лучшее решение независимо друг от друга. Роботы получают контент для индексации при помощи серверного рендеринга, а клиенты живой сайт при помощи клиентского рендеринга.

Для пререндера вам понадобится вспомогательная программа работающая на стороне сервера независимо от вашего веб сайта. На стороне прокси сервера вашего сайта делается настройка, которая разделяет пути следования клиентов и поисковых роботов. Клиентам отдается статичный сайт с клиентским рендерингом. Роботы отправляются на программу пререндеринга. Программа пререндеринга открывает сайт, дожидается его загрузки и отправляет результат открытого сайта поисковому роботу. Фактически это то же самое чем занимаются пререндеры поисковых роботов, только мы это реализуем на своей стороне, чтобы помочь роботам лучше индексировать контент своего сайта.

Детальнее про пререндеринг можно почитать в документации гугла. Я для обзора буду рассматривать микросервис пререндеринга от компании МТС который называется BotView. Так же есть сервис prerender.io который предоставляет услуги пререндеринга и открытый контейнер для пререндеринга. Но его мы рассматривать не будем так как он менее стабильный, менее быстрый и менее функциональный чем BotView.

Как настроить пререндер?

Чтобы настроить пререндер, необходимо сделать два простых шага. Во-первых, запустить контейнер с микросервисом пререндеринга.

docker run -d --restart always -p 3000:3000 mtsrus/botview

Во-вторых, на прокси сервере необходимо настроить разделение путей для реальных клиентов и поисковых роботов. Чтобы реальным клиентам отдавались статичные файлы, а поисковые роботы перенаправлялись на пререндер.

location / < set $prerender 0; # all popular bots if ($http_user_agent ~* "googlebot|facebookexternalhit|twitterbot|telegrambot|yahoo|bingbot|baiduspider|yandex|yeti|yodaobot|gigabot|ia_archiver|developers\.google\.com") < set $prerender 1; ># bot with escape fragments if ($args ~ "_escaped_fragment_") < set $prerender 1; ># prerender microservice if ($http_user_agent ~ "Prerender") < set $prerender 0; ># static files if ($uri ~ \.[a-zA-Z0-9]+$) < set $prerender 0; >if ($prerender = 1) < rewrite (.*) /render/$scheme://$host$1?prerender break; proxy_pass http://localhost:3000; >if ($prerender = 0) < proxy_pass http://localhost:8080; >>

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

Как будем сравнивать?

Для сравнения возьмем две популярные технологии разработки сайтов. Сайт реализованный как статичные файлы и сайт реализованный на Next.js с SSR. И пройдемся по наиболее интересным вопросам использования.

Стоимость хостинга

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

Когда вы хостите сайт как программу с SSR, то на сервере вам понадобится много ресурсов для вашей программы. Потому что теперь для рендеринга сайта будут использоваться серверные ресурсы и много. Понадобится много процессора, много памяти, много сети. Кроме того вырастет нагрузка на сеть, ведь отрендереную серверную страницу нельзя кэшировать. Но самое забавное, что клиент все равно будет рендерить, то же самое. Переложив рендеринг на сервер вы не на чем не сэкономили, вы лишь заплатили за поддержку поисковых роботов.

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

Но на самом деле у SSR тоже есть козыри. Например, если брать фреймворк Next.js то он может работать не только как SSR решение, но и как SSG, и как SSG + SSR решение. Таким образом страницы могут генерироваться как статичные на этапе сборки или в рантайме по интервалу с новыми данными. Таким образом фреймворк позволяет снизить нагрузку на сервер и клиентам выдавать кэшированные данные.

Но за пререндер на сервере тоже надо платить? Да. Но робот приходит на страницу 1 раз в 2 недели. Это гораздо меньше чем обычно клиентов приходят на вашу страницу.

Надежность

Когда вы хостите сайт как статичные сайты то ваш сайт фактически бессмертен. Это самый простой вид хостинга, его невозможно ни взломать ни сломать. В худшем случае произойдет DDOS и у вас откажет сетевое оборудование, но сайт продолжит работать.

Когда вы хостите сайт как серверную программу то у вас появляется множество проблем по поддержанию работоспособности данной программы. Что бы она не зависла, не сломалась, нагрузка находилась в пределах нормы, что бы программу нельзя было взломать и захватить сервер. Скорее всего вам придется подключить мониторинг и метрики. Кроме того большое количество клиентов могут заставить вашу программу потреблять больше ресурсов чем есть на сервере и тогда программа сломается.

Стоимость разработки

Когда вы разрабатываете для SSR вам необходимо разрабатывать сразу под две платформы Браузер и NodeJS. Эти платформы имеют разное API. В частности на стороне NodeJS отсутствуют такие объекты как window, location, screen и многие другие. Из-за чего часто приходиться выкручиваться создавая логику без использования этих объектов или вовсе оставляя заглушку для обработки на стороне клиента. Например частенько при разработке под SSR нужно знать размер экрана пользователя, но вы его никак не можете знать на стороне сервера, поэтому вы рендерите заглушку, потом код передается на клиент где уже происходит более полноценный расчет логики и перерендеринг уже с реальными данными. Все эти нюансы увеличивают стоимость разработки.

Когда вы разрабатываете под Пререндер вы разрабатываете только под браузер. Где есть все необходимое для написания логики.

Поддержка технологий

Когда вы используете SSR вы сильно ограничены в используемых технологиях. Next.js только два месяца назад научился безболезненно работать с динамическими данными. В других фреймворках работать с динамическими данными все еще проблемно или невозможно вовсе. На стороне SSR вы не можете использовать множество браузерных фич, таких как Веб компоненты, Микрофронтенды, Фреймворки и пр.

Пререндеринг выполняется в полноценном браузере, поэтому вам доступны все те технологии которые есть браузере без ограничений. Вы не ограничены в библиотеках и фреймворках. Вы можете использовать его для чего угодно, включая JQuery, AngularJS, Angular, Vue, SolidJS и др.

Хайп и комьюнити

SSR в настоящий момент является основным и рекомендуемым Гуглом. По данному подходу можно найти огромное количество статей и документации. Все современные фреймворки обладают функцией рендеринга через SSR.

Пререндер удел интузиастов. Он перестал быть основным инструментом поставки контента поисковым роботам, так же перестал быть рекомендованным инструментом Гугл.

Функциональность

Когда вы разрабатываете с SSR вам приходиться хостить на сервере программу. При таком подходе у вас появляется возможность разместить в программе не только клиентский код, но и API, и код бекенда. Таким образом вы можете принимать запросы от клиента, делать рассылки и исполнять любую необходимую бизнес логику. Фактически вы превращаетесь в фуллстек разработчика.

Когда вы хостите сайт как набор статичных файлов, то кроме отображения статичных файлов в браузере вы не можете делать ничего.

Какое из решений является костылем?

Оба. Единственная задача для которой они существуют это сделать контент видимым для поисковых роботов, реальным клиентам они не нужны. Если ваш контент не должны индексировать роботы, то вы можете не использовать эти решения совсем.

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

Что выбрать вам?

Решать вам. Я выбираю в зависимости от задачи проекта.

Свои личные проекты я реализую как статичные сайты с пререндером. Потому что так стоимость хостинга значительно ниже и не надо заморачиваться с надежностью.

На работе решение выбирается в зависимости от задачи. Где то это статика с пререндером, где то это фулстек проект на Next.js. Но в подавляющем большинстве это все же Next.js с SSG + SSR.

С другой стороны если ваш фреймворк не поддерживает SSR, например это JQuery или старый Angular, то Пререндер это ваш единственный вариант, при котором контент будет доступен поисковым роботам.

Что такое рендер?

Этот вопрос часто ставит профессиональных визуализаторов в ступор, оставляя заинтересованного новичка без ответа. Максимум, что может выдавить практик: «рендер — это результат процесса рендеринга». Однако если вы ведёте диалог с визуализатором-преподавателем, то вас ждёт полноценная лекция, вот как сейчас.

169 показов

2K открытий

Оптимизации можно научиться, изучая технические тонкости на наших курсах, все самые актуальные инструменты и приёмы мы собрали для вас в удобную библиотеку знаний, а недостаток опыта компенсируют наши кураторы. Визуализация не так сложна, если осваивать её не в гордом одиночестве, а в команде! Если у тебя уже сейчас есть что спросить — для тебя всегда открыты комментарии, вместе мы быстрее найдём ответы на любые вопросы.

Поисковая оптимизация сайтов, использующих SPA-приложения

Директор SEO-отдела агентства «Двигус» Денис Логанов и руководитель группы разработки проектов «Ситилинк» Константин Осипов — об инструментах, которые помогут индексировать в поисковых системах AJAX-сайты.

22K открытий

При создании новых высоконагруженных веб-сервисов и сайтов разработчики стремятся использовать современные технологии. В силу этого всё большую популярность набирают различные JavaScript-фреймворки и библиотеки (Angular, React, Vue, Inferno и прочие), которые, безусловно, помогают создавать SPA (Single Page Application) приложения с лучшим на сегодня опытом взаимодействия, позволяют разрабатывать легко масштабируемые, удобные в поддержке веб-приложения.

Но у SPA-приложений имеется один существенный недостаток, сейчас поисковые роботы всё ещё плохо индексируют сайты, контент на которых рендерится с помощью JavaScript.

Поисковые боты были изначально разработаны для обхода статичных HTML-страниц и не умели интерпретировать JavaScript-код. Это означает, что части страницы, загруженные через AJAX, оставались невидимы для поисковых роботов, так как передача данных осуществляется после загрузки станицы. AngularJS и вовсе полностью охватывает асинхронную модель, и именно это создаёт проблемы для поисковых ботов.

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

Если не выполнить процедуру правильной подготовки проекта к индексации поисковыми системами, то значительная часть страниц сайта не попадает в индекс, а также контент на самих страницах будет лишь частично распознаваться поисковиками. Следовательно, такая проблема будет явно влиять на ранжирование ресурса и его динамику по SEO-продвижению.

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

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