Posted:
Июл 24, 2023
Comments:
0 Comments

Рендеринг сайта что это: Рендеринг веб сайтов 101 / Хабр

Содержание

Рендеринг веб сайтов 101 / Хабр

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

Как устроен браузер?


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

User Interface — это все что видит пользователь: адресная строка, кнопки вперед/назад, меню, закладки — за исключением области где отображается сайт.

Browser Engine отвечает за взаимодействие между User Interface и Rendering Engine. Например клик по кнопке назад должен сказать компоненте RE что нужно отрисовать предыдущее состояние.

Rendering Engine отвечает за отображение веб-страницы. В зависимости от типа файла, эта компонента может парсить и рендерить как HTML/XML и CSS, так и PDF .

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

JS Engine место где парсится и исполняется js код.

UI Backend используется чтобы рисовать стандартные компоненты типа чекбоксов, инпутов, кнопок.

Data Persistence отвечает за хранение локальных данных, например в куках, SessionStorage, indexDB и так далее.

Далее узнаем как рассмотренные компоненты браузера взаимодействуют между собой и разберем подробнее, что происходит внутри Rendering Engine. Другими словами …

Как браузер переводит html в пиксели на экране?


Итак, с помощью компонента Network браузер начал получать html-файл чанками обычно по 8кб, что дальше? А далее идет процесс парсинга (спецификация процесса) и рендеринга этого файла в компоненте, как вы уже догадались — Rendering Engine.

Важно! Для повышения юзабилити, браузер не дожидается пока загрузится и распарсится весь html. Вместо этого браузер сразу пытается отобразить пользователю страницу (далее рассмотрим как).


Сам процесс парсинга выглядит так:

Результатом парсинга является DOM дерево. Возьмем к примеру такой html:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8">
    <title>Web Rendering</title>
    <link rel="stylesheet" href="styles.css">
  </head>
  <body>
    <div>
      <div>
        <h2>Hey</h2>
      </div>
      <div>
        <p>
          Lorem <span>ipsum</span>.
        </p>
      </div>
      <footer>
        Contact me
      </footer>
    </div>
    <script src="./code.js"></script>
  </body>
</html>

DOM дерево такого html файла будет выглядеть так:

По мере того как браузер парсит html файл, он встречает теги содержащие ссылки на сторонние ресурсы ( <link>, <script>, <img> и так далее) — по мере их обнаружения происходит запрос за этими ресурсами.  

Таким образом, отправив запрос по адресу прописанному в атрибуте href тега <link rel=»stylessheet»> и получив файл css стилей, браузер парсит этот файл и строит так называемый CSS Object Model — CSSOM.

Представим что у нас есть такой файл стилей:

body {
  font-size: 14px;
}
.wrapper {
  width: 960px;
  margin: 0 auto;
}
.wrapper .header h2 {
  font-size: 26px;
}
.wrapper p {
  color: red;
}
footer {
  padding: 20px 0;
}

Из которого получим такой CSSOM:

Attention: тут построено дерево из стилей нашего css-файла. Кроме того, также есть user agent’s styles — дефолтные стили браузера и инлайновые стили — прописанные в html тегах.


Подробнее об алгоритме парсинга css стилей можно прочитать в спецификации.

Теперь у нас есть DOM и CSSOM - первый отвечает на вопрос «что?», второй на вопрос «как?». Если думаете, что следующим этапом является соединение DOM и CSSOM’а, то вы совершенно правы! DOM + CSSOM = Render Tree.

Render Tree — это дерево видимых (!) элементов построенных в том порядке, в котором они должны рендериться на странице. Обратите внимание, что элементы имеющие css правило display: none или другие, отрицательно влияющие на отображение — не будут находится в render tree.

Браузер строит Render Tree чтобы точно определить что ему нужно отрисовать и в каком порядке. Построение Render дерева происходит примерно так: начиная с рутового элемента (html), парсер проходит по всем видимым элементам (пропуская link, script, meta, скрытые через css элементы) и для каждого видимого элемента находит соответствующее css правило из CSSOM.

В движке firefox’a элементы Render Tree называются фреймами (frames). Webkit использует термин renderer или render object. Render object знает как разместить себя на странице, а так же содержит информацию о своих дочерних элементах. И для самых любознательных, если заглянуть в исходники webkit’a — можно найти класс который так и называется — RenderObject.

Продолжая наш пример мы получим такой Render Tree:

На данный момент мы имеем в некотором состоянии Render Tree — дерево содержащее информацию о том что и как нужно отрисовать. Теперь браузер должен понять на каком месте и с какими размерами будет отображаться элемент. Процесс вычисления позиции и размеров называется Layout.

Layout — это рекурсивный процесс определения положения и размеров элементов из Render Tree. Он начинается от корневого Render Object, которым является , и проходит рекурсивно вниз по части или всей иерархии дерева высчитывая геометрические размеры дочерних render object’ов. Корневой элемент имеет позицию (0,0) и его размеры равны размерам видимой части окна, то есть размеру viewport’a.

В Html используется поточная модель компоновки (flow based layout), другими словами геометрические размеры элементов в некоторых случаях можно рассчитать за один проход (если элементы, встречающиеся в потоке позже, не влияют на позицию и размеры уже пройденных элементов).

Layout может быть глобальный, когда требуется рассчитать положение render object’ов всего дерева, и инкрементальный, когда требуется рассчитать только часть дерева. Глобальный layout происходит, например, при изменении размеров шрифта или при событии resize’a. Инкрементальный layout происходит только для render object’ов, помеченных как «dirty».

Пара слов о «системе грязных битов (dirty bit system)». Эта система используется браузерами для оптимизации процесса, чтобы не пересчитывать весь layout. При добавлении нового или изменении существующего render object — он сам и его дочерние элементы помечаются флагом «dirty». Если render object не изменяется, но его дочерние элементы были изменены или добавлены, то этот render object помечается как «children are dirty».


К концу процесса layout каждый render object имеет свое положение и размеры.

Подводя промежуточный итог: браузер знает что, как и где рисовать. Следовательно — осталось только нарисовать. Этот процесс, как ни странно, называется Paint.

Paint — этап, где пиксель монитора заполняется цветом указанным в свойствах render object’а и белый экран превращается в картину задуманную автором (разработчиком). На всем пути рендеринга  —  это самый дорогой процесс (не то чтобы предыдущее дешевые).

Также, как и процесс layout, отрисовка (paint) может быть глобальной — дерево перерисовывается полностью, и инкрементальной — дерево перерисовывается частично. Для частичного перерисовывания render object помечает свой rectangle как невалидный. Операционная система расценивает эту область как требующую перерисовки и вызывает событие paint. При этом браузер умеет объединять области, чтобы выполнить разом перерисовку для всех мест, где это необходимо.

Определение размеров и положения элементов дерева (layout) и перерисовка (paint) являются дорогостоящими процессами. Они выполняются на уровне CPU. Разрабатывая динамические веб приложения, в которых эти процессы будут запускаться очень часто — мы никогда не достигнем плавных анимаций.


Значит, должно быть что-то, что помогло бы создавать сайты с богатой анимацией, при этом не нагружая CPU и рисуя каждый кадр менее чем за 16,6мс (60 fps). Действительно, браузер выполняет еще один этап, который помогает оптимизировать динамику сайтов — Composite (композиция). 

Перед композицией, все нарисованные элементы находятся на одном слое (memory layer). То есть, изменение параметров (например, геометрических размеров или положения) одних элементов повлекут перерасчет параметров соседних элементов. Но если распределить элементы на композиционные слои — изменение параметров элемента вызовут перерасчет только на определенном слое, не затрагивая при этом элементы на других слоях. Таким образом, этот процесс является самым дешевым по производительности, поэтому нужно стараться вносить изменения вызывающие только composite.

Резюмируя вышесказанное, получаем такой процесс рендеринга веб страницы:

TLDR;

Браузер получает html файл, парсит его и строит DOM. Встречая css стили, браузер их подгружает, парсит, строит CSSOM и объединяет вместе с DOM’ом — получаем Render Tree. Осталось выяснить где расположить элементы из Render Tree — этим занимается задача layout. После расположения элементов, можно начать рисовать их — это задача paint, этап на котором заполняются пиксели экрана.

Динамика


Что происходит когда изменяется css свойство? Или, например, добавляется новый dom узел? В случае изменения css свойств все зависит от изменяемого свойства. Есть только два свойства которые вызывают задачу composite — это opacity и transform. Только эти два свойства являются самыми дешевыми для анимации. К примеру, изменение background вызовет задачу paint (затем composite), а изменение display вызовет сначала layout, далее paint, после чего composite. Список задач, которые вызываются изменениями стилей можно посмотреть на csstriggers.com. 

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

Подводя итог, мы рассмотрели из каких компонентов состоит браузер, как они взаимодействуют друг с другом и как Rendering Engine рисует страницу пользователю.

Посмотреть вышеописанное можно в devtools’ах хрома, но чтобы не выходить за рамки названия статьи — на этом пока все.

Источники

  1. https://blog.algolia.com/performant-web-animations/

  2. https://www.zeolearn.com/magazine/components-of-web-browsers

  3. https://www.html5rocks.com/ru/tutorials/internals/howbrowserswork

  4. https://blog.sessionstack.com/how-javascript-works-the-rendering-engine-and-tips-to-optimize-its-

    performance-7b95553baeda

  5. https://developers.google.com/web/fundamentals/performance/rendering

как и для чего поисковые системы визуально отображают веб-страницы

Рубрика: Теория и статистика | Время на чтение: 7 мин.

Как поисковые системы рендерят страницы в интернете? Почему и когда они это делают? На эти и другие вопросы вы найдёте ответы в этом посте.

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

  • обнаруживает веб-страницу с помощью Sitemap или краулинга, и затем посещает её с целью индексации;
  • собирает весь контент на странице;
  • начинает ранжировать документ по запросам.

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

Оглавление

В чём разница между индексированием и рендерингом?

По сути, разница между индексированием и рендерингом может быть проиллюстрирована этими двумя изображениями:

Это один и тот же контент. Просто на первом изображении он просматривается в режиме индексирования (HTML), а на втором – в режиме рендеринга (Google Chrome).

Почему это имеет значение?

Теперь вы можете спросить себя: «Почему это важно?». Хорошим примером для ответа на такой вопрос выступает JavaScript. До недавнего времени поисковые системы изначально рендерили страницы без учёта JavaScript.

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

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

  • Скрыт ли контент под спойлером?
  • Перенасыщен ли контент рекламой?
  • Контент, находящийся в конце кода, отображается в верхней части страницы или вообще в навигации?
  • С какой скоростью загружается страница?

На все эти и многие другие вопросы находятся ответы во время рендеринга, и они важны для правильного понимания страницы и того, как она должна оцениваться.

Когда происходит рендеринг?

Рендеринг происходит после индексации. Конкретные сроки нигде не прописаны, но, по словам Барри Шварца из Google, это может занять несколько недель.

SEO-специалисты периодически задают вопросы о рендеринге представителям компании. Вот, например, сентябрьский диалог с Джоном Мюллером:

Они активно над этим работают. Ох уж этот старый добрый Дядя Женя. 🙂

Бинг работает по-другому, но, по словам менеджера проекта по ранжированию веб-сайтов и качеству Фредерика Дабута, сроки примерно такие же:

Таким образом, короткий ответ – «после индексации», а временная шкала является переменной. По сути это означает, что поисковые системы будут пытаться понять содержание и контекст страницы до того, как начнут её ранжировать.

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

  • что те или иные элементы страницы делают;
  • где они расположены;
  • насколько они важны для пользователя.

Но подтверждают или опровергают эти предположения роботы только после рендеринга.

Проблема рендеринга

По сути, поисковые системы отправляют на сайт краулер, который рендерит страницу так же, как это делает браузер. В качестве примера возьмём Google.

У Googlebot есть компонент Web Rendering Service (WRS). Он был обновлён в мае 2019 года. До этого Служба Веб-Рендеринга использовала Chrome версии 41. Это было прекрасно для совместимости, но ужасно для сайтов, применяющих такие функции, как в современный JavaScript.

В мае 2019 года Служба Веб-Рендеринга была обновлена до «вечнозелёной». Это означает, что она использует самую последнюю версию Chrome для рендеринга. Теперь, когда страница вашего сайта рендерится роботом Google, она отображается более или менее так, как вы видите её в браузере.

Прекрасная новость, да? Теперь, единственное, что вам нужно сделать для тестов – открыть браузер. Если сайт выглядит в Хроме нормально, то всё «ок», верно? Ведь Google будет доволен?

А вот и нет!

И тот же Бинг недалеко ушёл от Гугла. Хотя всё же чуть лучше справляется с рендерингом (что интересно).

Если у вас самый простой сайт с предсказуемым HTML-кодом и минимальным присутствием динамического контента, то вам действительно не о чем беспокоиться. Как было и в случае со старой WRS.

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

До тех пор, пока не закончится рендеринг страницы, поисковая система не будет знать, что на ней находится. На сайте с простым HTML поисковик может упустить немного контекста, но в целом он сразу видит весь контент. На сайте, построенном с помощью чего-то сложного, вроде JavaScript, робот не понимает контент до самого конца работы WRS.

А как мы с вами узнали до этого, на рендеринг может уйти неделя. И теперь эта неделя становится намного критичнее. Именно поэтому Мюллер и написал, что они работают над сокращением времени обработки.

Пока они этого не сделают, JavaScript-разработчикам придётся полагаться на предварительный рендеринг (создание статической версии каждой страницы для поисковых систем), что совсем не идеально.

Что делает служба веб-рендеринга (WRS)?

Во-первых, давайте рассмотрим, где и как Служба Веб-Рендеринга получает свои инструкции.

Вот базовый жизненный цикл рендеринга:

  1. Страница обнаруживается с помощью карты сайта, краулера и т.п.
  2. Страница добавляется в список документов, которые необходимо просканировать на сайте, когда это позволит краулинговый бюджет.
  3. Контент страницы сканируется и индексируется.
  4. Страница добавляется в список документов, которые необходимо отрендерить на сайте, когда это позволит рендеринговый бюджет.
  5. Страница рендерится.

Критическим элементом процесса является очередь рендеринга. О ней мало кто говорит. Гугл-бот может попасть на страницу за несколько недель до рендеринга. На протяжении этого периода некоторые элементы контента (сайты на JavaScript) или контекста (все сайты) могут отсутствовать.

Когда страница попадает в топ очереди рендеринга, поисковая система посылает на неё то, что называют «безголовым браузером» (headless browser). Это веб-браузер без графического интерфейса пользователя.

Безголовый браузер рендерит страницу для поисковой системы, чтобы понять, что и где отображается. Если всё проходит хорошо, отрендеренная версия будет выглядеть для робота Googlebot так же, как и для браузеров с графическим интерфейсом. В противном случае страница, скорее всего, опирается на неподдерживаемую функцию, например, запрос разрешения пользователя (user permission request).

Подведём итог

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

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

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

Источник информации: www.searchenginejournal.com

  • Об авторе
  • Недавние публикации

SEO-aspirant

SEO-специалист в Блог SEO-аспиранта

Меня зовут Виктор, я – автор этого блога. Занимаюсь интернет-маркетингом (SEO, SMM, CPA) профессионально с 2008 года.

SEO-aspirant недавно публиковал (посмотреть все)

ПОНРАВИЛСЯ ПОСТ? ПОДЕЛИСЬ ССЫЛКОЙ С ДРУЗЬЯМИ!

СТАТЬИ ИЗ РУБРИКИ:

  • Суровая правда о заработке в интернете от Стивена Блэка
  • Google обновил избранные сниппеты
  • Hreflang атрибут: 7 базовых вопросов, которые вы всегда хотели задать
  • Вечнозелёный контент – что это такое и зачем он нужен
  • Санкции за ссылки – ручной фильтр Google из-за неестественных бэков [исследование SEMrush]
  • Потеря кликов в арбитраже трафика [руководство]
  • Google Chrome начинает блокировать тяжёлую рекламу
  • Как найти и исправить 404 ошибки для увеличения трафика на сайт
  • 3 лучших WordPress плагина для Google Analytics
  • Google больше не учитывает десктопную версию сайта при ранжировании

Тематика: SEM, Переводы

Дата публикации: 09. 06.2020

(некоторые ответы перед публикацией проверяются модератором)

Акронимы рендеринга в Интернете

В веб-разработке так много аббревиатур и инициализмов, что за ними трудно уследить. Влияет ли SSR на мой CWV? Сколько методов HTTP требуется для создания REST API? Использует ли SPA CSR? Помогите, мне нужна сердечно-легочная реанимация!

Не волнуйся, я здесь для тебя. Давайте разберем аббревиатуры и инициализмы рендеринга в Интернете, чтобы вы могли получить столь необходимый R&R.

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

Рендеринг — это процесс создания HTML-разметки для отображения веб-страниц в браузере. Как, и самое главное, , где происходит процесс рендеринга, может оказать значительное влияние на взаимодействие с пользователем, производительность сайта и поисковую оптимизацию (SEO).

Типы рендеринга

Давайте рассмотрим различные типы рендеринга, доступные сегодня в современной сети, и какие типы сайтов, страниц и данных они лучше всего подходят.

Статический рендеринг

На заре Интернета все веб-сайты были статическими — коллекциями рукописных HTML-файлов, хранившихся на серверах, скорее всего загружаемых через FTP-клиенты (о, ностальгия!), и предоставлявшихся непосредственно пользователям в их веб-браузеры. Статический рендеринг по-прежнему является отличным вариантом для использования сегодня и особенно подходит для сайтов, обслуживающих один HTML-файл, например, одну целевую страницу с контентом. Серверные вычисления не требуются, поэтому ваша страница будет загружаться быстро. И один файл HTML очень легко разместить на Netlify, либо подключив репозиторий Git, либо загрузив через Netlify Drop. 🫳🎤 Вот один, который я сделал ранее.

Рендеринг на стороне сервера (SSR)

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

  1. Введите веб-адрес в браузере
  2. Отправить запрос
  3. Этот запрос отправляется на сервер в фиксированном месте, где сервер обрабатывает запрос, создает веб-страницу в режиме реального времени и отправляет ее обратно в браузер в виде HTML-документа.

SSR по-прежнему является наиболее распространенным методом рендеринга в Интернете на сегодняшний день, поскольку он используется по умолчанию для сред приложений, таких как WordPress, и больших монолитных технологических стеков. Исторически для SSR требовался постоянно работающий управляемый сервер, что часто сопряжено с нежелательными накладными расходами с точки зрения обслуживания, масштабирования и безопасности. К счастью, современные интерфейсные JavaScript-фреймворки, такие как Astro, Next.js, Remix, Nuxt и Gatsby, теперь предоставляют параметры конфигурации для использования SSR через современные платформы веб-разработки, такие как Netlify, с использованием бессерверных функций под капотом.

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

Недостатком SSR является потенциально большая задержка. Серверы обычно существуют в фиксированных географических местоположениях. Чем дальше первоначальный запрос от исходного сервера, тем больше времени потребуется для прохождения запроса туда и обратно в браузер. А если ваш сайт просматривается на смартфоне через соединение 3G или 4G, запрос может занять еще больше времени.

Рендеринг на стороне клиента (CSR)

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

CSR становилась все более популярной с массовым распространением JavaScript в браузерах в конце 1990-х годов. Его место в качестве основного компонента в веб-экосистеме еще больше укрепилось с развитием технологий внешнего интерфейса одностраничных приложений (SPA), таких как React, Angular и Vue. Как и SSR, CSR лучше всего подходит для динамически обновляемых данных, но имеет некоторые недостатки.

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

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

Генерация статического сайта (SSG)

Генерация статического сайта (SSG) — это процесс предварительного создания HTML-страниц заранее, чтобы они были готовы к немедленному обслуживанию ваших пользователей без необходимости SSR или CSR. В середине 2010-х годов возросла популярность инструментов для создания статических сайтов, таких как Jekyll, которые позволяли разработчикам создавать любое количество статических HTML-файлов из шаблонов в процессе сборки. Больше не нужно вручную создавать трудоемкие отдельные HTML-файлы, чтобы воспользоваться преимуществами статического рендеринга — ура!

И вместе с этим появилась возможность обслуживать ваш сайт из сети доставки контента (CDN), такой как CDN Netlify, которая обслуживает ваши статические файлы и ресурсы с ближайшего узла сервера к запросу, что делает ваш сайт действительно, действительно быстро. Более того, учитывая, что страницы вашего веб-сайта предварительно сгенерированы в виде полных HTML-файлов, содержащих реальный контент, вы получите больше очков SEO.

Сегодня в веб-экосистеме существуют сотни генераторов статических сайтов, которые позволяют создавать статические сайты с использованием (скорее всего) любой из языков программирования, которые вы пожелаете, включая JavaScript, Go, Ruby, Python, PHP и Rust. Ознакомьтесь с огромным списком генераторов статических сайтов на Jamstack.org.

SSG — это метод рендеринга, который лучше всего подходит для контентных сайтов и страниц, которые не часто меняются. Блоги, портфолио, сайты документации и информационный контент — все это отличные варианты использования SSG. Чтобы обновить контент, инициируйте перестройку вашего сайта, и вновь созданные ресурсы будут готовы к работе из CDN после завершения процесса сборки.

Инкрементная статическая регенерация (ISR)

Инкрементная статическая регенерация (ISR) — это собственная реализация Next. js шаблона кэширования, который называется Stale While Revalidate (SWR). Это позволяет регенерировать отдельных статически отображаемых страниц, которые были изменены, а не перестраивать весь сайт с нуля. С помощью SWR вы можете публиковать изменения на определенной странице — например, с помощью триггера веб-перехватчика в CMS — без запуска полной перестройки сайта, что приводит к более быстрому обновлению сайта.

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

Имейте в виду, что при использовании SWR/ISR некоторые посетители вашего веб-сайта могут увидеть устаревшее содержимое, поскольку обновленная страница перестраивается на сервере и кэшируется. Вы не захотите использовать SWR для страниц, отображающих данные, которые должны быть точными и актуальными, например данные о ценах. Вы также можете создать резервную страницу для обслуживания, если вы используете SWR/ISR для создания новых страниц, просто чтобы убедиться, что ваш сайт не выглядит сломанным и не обслуживает 404.

Распределенный постоянный рендеринг (DPR) )

Распределенный постоянный рендеринг (DPR) — это удобный метод рендеринга, предоставляемый Netlify для использования на очень больших сайтах, чтобы значительно сократить время сборки. Вместо того, чтобы заранее создавать весь сайт с помощью SSG, вы можете выбрать предварительное статическое создание только самых популярных и/или важных страниц и улучшить стратегию рендеринга с помощью DPR.

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

Netlify поддерживает DPR и SWR за счет использования сборщиков по запросу — бессерверных функций, используемых для создания веб-контента по мере необходимости, который автоматически кэшируется в CDN Netlify Edge.

Edge Side Rendering (ESR)

Вот где все становится по-настоящему захватывающим. Помните модель CDN, о которой мы говорили, когда статические страницы и ресурсы доставляются пользователям с ближайшего географического расположения сервера? Edge Side Rendering (ESR) использует возможности CDN для доставки SSR как можно ближе к пользователям, предоставляя преимущества традиционной SSR, такие как персонализация и динамические данные, с повышенной скоростью для всех во всем мире. ESR можно реализовать для всего сайта, отдельных страниц или даже отдельных частей страниц.

ESR на Netlify предоставляется функциями Netlify Edge — бессерверными функциями, выполняемыми на границе — которые могут перехватывать HTTP-запрос и изменять HTTP-ответ до того, как он будет отправлен в браузер. Это означает, что вы можете использовать ESR для  улучшения ваших статических сайтов и страниц во время запроса . Когда вы предварительно создаете как можно больше с помощью SSG и используете Edge Functions для изменения страниц, когда вам нужно, вы сохраняете скорость статического рендеринга с возможностью динамически обновлять свои страницы, когда вам это нужно. ESR отлично подходит для персонализации, локализации, интернационализации и т. д., предоставляя своего рода сверхмощную SSR, где бы ни находились посетители вашего сайта по всему миру.

Подведение итогов

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

Удачной визуализации! ПОГОВОРИМ ПОЗЖЕ.

Рендеринг (Веб-разработка): Определение — Seobility Wiki

 Share 

Содержание

  • 1 Что такое рендеринг?
  • 2 Как браузеры отображают веб-страницы
  • 3 Динамическая визуализация
  • 4 Скорость рендеринга страницы
  • 5 Важность рендеринга для SEO
  • 6 Каталожные номера
  • 7 Ссылки по теме
  • 8 Аналогичные изделия

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

Рендеринг — это процесс, используемый в веб-разработке, который превращает код веб-сайта в интерактивные страницы, которые пользователи видят при посещении веб-сайта. Этот термин обычно относится к использованию кодов HTML, CSS и JavaScript. Процесс завершается механизмом рендеринга, программным обеспечением, используемым веб-браузером для рендеринга веб-страницы. Из-за тесной связи с веб-браузерами механизмы рендеринга обычно называют браузерными движками.

Как браузеры отображают веб-страницы

Веб-браузеры отображают веб-страницы в следующей последовательности:

Создает DOM и CSSOM из необработанного кода

  • При загрузке веб-страницы веб-сервер отправляет папку с файлами, содержащими код HTML, CSS и JavaScript, в веб-браузер пользователя.
  • Движок браузера преобразует эти данные (байты) в символы (код HTML).
  • Он разбирает символы на токены [1] , которые далее разбираются на узлы [2] .
  • Механизм браузера связывает узлы в древовидную структуру, известную как объектная модель документа (DOM). DOM — это JavaScript-представление HTML.
  • Одновременно браузер преобразует код CSS в объектную модель CSS (CSSOM) с помощью аналогичного процесса.

Изображение рендеринга HTML с сайта developer.google.com

Использует дерево визуализации для создания веб-страницы конечного пользователя

  • Движок браузера объединяет DOM и CSSOM для создания древовидной структуры, называемой Render Tree. Дерево рендеринга содержит информацию о стилях и содержимом, необходимую браузерам для заполнения веб-страницы для просмотра зрителями, расчета макета для каждого видимого элемента веб-страницы и отображения их на экране для просмотра конечным пользователем.
  • Следующим шагом является операция компоновки. Используя Render Tree, движок браузера вычисляет положение каждого видимого элемента веб-страницы.
  • Наконец, механизм браузера добавляет или рисует элементы на экране для просмотра конечными пользователями. Теперь веб-страница отрендерена.

Динамический рендеринг

JavaScript — популярный выбор для рендеринга веб-страниц, поскольку он используется для создания интуитивно понятного пользовательского интерфейса. Тем не менее, многие боты поисковых систем с трудом обрабатывают JavaScript 9.0156 [3] . Следовательно, веб-сайты, которые используют JavaScript для размещения большей части своего контента и навигации, рискуют остаться невидимыми для поискового робота. Динамический рендеринг решает эту проблему путем рендеринга веб-страницы, как описано выше, для пользователя-человека, а также рендеринга статического HTML для робота поисковой системы для сканирования и индексирования.

Скорость рендеринга страницы

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

Низкая скорость рендеринга страниц увеличивает показатель отказов и снижает конверсию. В одном исследовании Google время загрузки сеансов с отказом было на 2,5 секунды меньше, чем у сеансов без возврата [4] .

Изображение показателя отказов по времени загрузки сайта с сайта thinkwithgoogle.com

Из-за того, что скорость рендеринга страницы влияет на взаимодействие с пользователем, Google сделал скорость страницы официальным фактором ранжирования в 2010 году.

Важность рендеринга для SEO

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

Таким образом, для многих веб-сайтов (например, интернет-магазинов) создание веб-сайта преимущественно на JavaScript может обеспечить наиболее удобный и эстетически привлекательный интерфейс. Однако боты поисковых систем могут с трудом сканировать эти веб-сайты, что негативно влияет на рейтинг поисковых систем и органический трафик. С другой стороны, страницы, которые отображаются медленно, негативно влияют как на взаимодействие с пользователем, так и на рейтинг в поисковых системах.

Принимая во внимание эти факты, веб-разработчики должны уделять особое внимание требованиям к ботам и людям, чтобы максимизировать производительность SEO.

Ссылки

  1. ↑ Анатомия компилятора Дата обращения 11 декабря 2020 г.
  2. ↑ Технопедия Node. Проверено 27 мая 2022 г.
  3. ↑ Внедрение динамического рендеринга Google Search Central.

    This entry was posted in Популярное