diff options
Diffstat (limited to 'files/ru/web/performance/how_browsers_work/index.html')
| -rw-r--r-- | files/ru/web/performance/how_browsers_work/index.html | 22 |
1 files changed, 11 insertions, 11 deletions
diff --git a/files/ru/web/performance/how_browsers_work/index.html b/files/ru/web/performance/how_browsers_work/index.html index cda110effb..97c05dfae7 100644 --- a/files/ru/web/performance/how_browsers_work/index.html +++ b/files/ru/web/performance/how_browsers_work/index.html @@ -37,11 +37,11 @@ translation_of: Web/Performance/How_browsers_work <h3 id="DNS_запрос">DNS запрос</h3> -<p>Первый шаг навигации к странице - это поиск места, откуда нужно запрашивать данные. Если вы переходите на <code>https://example.com</code>, браузер грузит HTML-код страницы с IP-адреса <code>93.184.216.34</code>. Если вы никогда ранее не были на этом сайте, произойдет поиск DNS записи.</p> +<p>Первый шаг навигации к странице - это поиск места, откуда нужно запрашивать данные. Если вы переходите на <code>https://example.com</code>, браузер грузит HTML-код страницы с IP-адреса <code>93.184.216.34</code>. Если вы никогда ранее не были на этом сайте, произойдёт поиск DNS записи.</p> <p>Ваш браузер запрашивает DNS запись. Как правило, запрос содержит имя сервера, который должен быть преобразован в IP-адрес. Ответ на этот запрос какое-то время будет сохранён в кэше устройства, чтобы его можно было быстро получить при следующем запросе к тому же серверу.</p> -<p>DNS запрос обычно требуется совершить лишь единожды при загрузке страницы. Однако, DNS запросы должны быть выполнены для каждого уникального имени хоста, который запрашивается страницей. Скажем, если ваши шрифты, картинки, скрипты, реклама или счетчики аналитики находятся на разных доменах, DNS запрос будет осуществлен для каждого из них.</p> +<p>DNS запрос обычно требуется совершить лишь единожды при загрузке страницы. Однако, DNS запросы должны быть выполнены для каждого уникального имени хоста, который запрашивается страницей. Скажем, если ваши шрифты, картинки, скрипты, реклама или счётчики аналитики находятся на разных доменах, DNS запрос будет осуществлён для каждого из них.</p> <p><img alt="Mobile requests go first to the cell tower, then to a central phone company computer before being sent to the internet" src="https://mdn.mozillademos.org/files/16743/latency.jpg" style="height: 281px; width: 792px;"></p> @@ -93,7 +93,7 @@ translation_of: Web/Performance/How_browsers_work <p>Объём первого пакета данных - всегда 14KB. Это часть спецификации {{glossary('TCP slow start')}} - алгоритма, который балансирует скорость соединения. Такое правило позволяет постепенно, по мере необходимости, увеличивать размеры передаваемых данных, пока не будет определена максимальная ширина канала.</p> -<p>В алгоритме {{glossary('TCP slow start')}} каждый следующий отправленный сервером пакет увеличивается в размере в два раза. Например, размер второго пакета будет около 28КБ. Размер пакетов будет увеличиваться до тех пор, пока не достигнет какого-то порогового значения или не упрется в проблему переполнения.</p> +<p>В алгоритме {{glossary('TCP slow start')}} каждый следующий отправленный сервером пакет увеличивается в размере в два раза. Например, размер второго пакета будет около 28КБ. Размер пакетов будет увеличиваться до тех пор, пока не достигнет какого-то порогового значения или не упрётся в проблему переполнения.</p> <p><img alt="TCP slow start" src="https://mdn.mozillademos.org/files/16754/congestioncontrol.jpg" style="height: 412px; width: 729px;"></p> @@ -101,7 +101,7 @@ translation_of: Web/Performance/How_browsers_work <h3 id="Контроль_переполнения">Контроль переполнения</h3> -<p>Любое соединение имеет ограничения, связанные с аппаратной и сетевой системами. Если сервер отправит слишком много пакетов за раз - они могут быть отброшены. Для того, чтобы избежать таких проблем, браузер должен реагировать на получение пакетов и подтверждать, что он получает их. Такой ответ-подтверждение называется Aknowledgements (ACK). Если из-за ограничений соединения браузер не получит данных, то он не пошлёт подтверждений ACK. В этом случае, сервер зарегистрирует, что какие-то пакет не дошли и пошлёт их заново, что приведет к лишней работе сервера и дополнительной нагрузке сети.</p> +<p>Любое соединение имеет ограничения, связанные с аппаратной и сетевой системами. Если сервер отправит слишком много пакетов за раз - они могут быть отброшены. Для того, чтобы избежать таких проблем, браузер должен реагировать на получение пакетов и подтверждать, что он получает их. Такой ответ-подтверждение называется Aknowledgements (ACK). Если из-за ограничений соединения браузер не получит данных, то он не пошлёт подтверждений ACK. В этом случае, сервер зарегистрирует, что какие-то пакет не дошли и пошлёт их заново, что приведёт к лишней работе сервера и дополнительной нагрузке сети.</p> <h2 id="Парсинг">Парсинг</h2> @@ -121,11 +121,11 @@ translation_of: Web/Performance/How_browsers_work <p><img alt="The DOM tree for our sample code, showing all the nodes, including text nodes." src="https://mdn.mozillademos.org/files/16759/DOM.gif" style="height: 689px; width: 754px;"></p> -<p>Когда парсер находит неблокирующие ресурсы (например, изображения), браузер отправляет запрос на загрузку ресурсов, но сам продолжает обработку. Обработка может продолжаться когда обнаружена ссылка на CSS файл, но если обнаружен <code><script></code>, особенно если он без параметров <code>async</code> или <code>defer</code> - такой скрипт считается блокирующим и приостанавливает обработку HTML до завершения загрузки скрипта. Несмотря на то, что сканер предзагрузки (о нём ниже) браузера может находить и запрашивать такие скрипты заранее, сложные и объемные скрипты всё ещё могут стать причиной заметных задержек загрузки страницы.</p> +<p>Когда парсер находит неблокирующие ресурсы (например, изображения), браузер отправляет запрос на загрузку ресурсов, но сам продолжает обработку. Обработка может продолжаться когда обнаружена ссылка на CSS файл, но если обнаружен <code><script></code>, особенно если он без параметров <code>async</code> или <code>defer</code> - такой скрипт считается блокирующим и приостанавливает обработку HTML до завершения загрузки скрипта. Несмотря на то, что сканер предзагрузки (о нём ниже) браузера может находить и запрашивать такие скрипты заранее, сложные и объёмные скрипты всё ещё могут стать причиной заметных задержек загрузки страницы.</p> <h3 id="Сканер_предзагрузки">Сканер предзагрузки</h3> -<p>Построение дерева DOM занимает весь поток процесса. Так как это явно узкое место в производительности, был создан особый сканер предзагрузки. Он обрабатывает доступное содержимое документа и запрашивает высокоприоритетные ресурсы (CSS, JavaScript и шрифты). Благодаря этому сканеру нам не нужно ждать, пока парсер дойдет до конкретного места, где вызывается ресурс. Он запрашивает и получает эти данные заранее, в фоновом режиме, так что когда основной поток HTML-парсера доходит до запроса ресурса, высока вероятность, что ресурс уже запрошен или находится в процессе загрузки. Оптимизации, которые даёт этот сканер, уменьшают время блокирования рендера.</p> +<p>Построение дерева DOM занимает весь поток процесса. Так как это явно узкое место в производительности, был создан особый сканер предзагрузки. Он обрабатывает доступное содержимое документа и запрашивает высокоприоритетные ресурсы (CSS, JavaScript и шрифты). Благодаря этому сканеру нам не нужно ждать, пока парсер дойдёт до конкретного места, где вызывается ресурс. Он запрашивает и получает эти данные заранее, в фоновом режиме, так что когда основной поток HTML-парсера доходит до запроса ресурса, высока вероятность, что ресурс уже запрошен или находится в процессе загрузки. Оптимизации, которые даёт этот сканер, уменьшают время блокирования рендера.</p> <pre class="brush:html notranslate"><link rel="stylesheet" src="styles.css"/> <script src="myscript.js" <strong>async</strong>></script> @@ -141,7 +141,7 @@ translation_of: Web/Performance/How_browsers_work <h3 id="Построение_модели_стилей_CSSOM">Построение модели стилей CSSOM</h3> -<p>Второй шаг при прохождении критического пути рендеринга - это обработка CSS и построение CSSOM дерева. CSSOM (объектная модель CSS) похожа на DOM. И DOM, и CSSOM - это деревья. Они являются независимыми структурами данных. Браузер преобразует CSS файлы в карту стилей, которую он может понять и с которой может работать. Браузер считывает каждый набор правил в CSS, создает дерево узлов с родителями, детьми и соседями, основываясь на CSS селекторах.</p> +<p>Второй шаг при прохождении критического пути рендеринга - это обработка CSS и построение CSSOM дерева. CSSOM (объектная модель CSS) похожа на DOM. И DOM, и CSSOM - это деревья. Они являются независимыми структурами данных. Браузер преобразует CSS файлы в карту стилей, которую он может понять и с которой может работать. Браузер считывает каждый набор правил в CSS, создаёт дерево узлов с родителями, детьми и соседями, основываясь на CSS селекторах.</p> <p>Как и в HTML, браузер должен преобразовать полученные правила CSS во что-то, с чем он может работать. Таким образом, весь этот процесс - это повторение формирования DOM, только для CSS.</p> @@ -169,9 +169,9 @@ translation_of: Web/Performance/How_browsers_work <p>Третий шаг в критическом пути рендеринга - это комбинирование DOM и CSSOM в дерево рендеринга. Конструирование этого дерева начинается с прохода всего DOM-дерева от корня, с выявлением каждого видимого узла.</p> -<p>Элементы, которые не должны быть показаны, например, <code><head></code>, а так же их дети или любые элементы с <code>display:none</code>, такие как <code>script { display: none; }</code>, не будут включены в дерево рендера, так как они не должны быть отрисованы. Узлы с правилом <code>visibility: hidden</code> включены в дерево рендера, так как они все равно занимают своё место. Так как мы не указали никаких специальных правил для перезаписи стилей агента по умолчанию, узел <code>script</code> в примере выше также не будет включен в дерево рендера.</p> +<p>Элементы, которые не должны быть показаны, например, <code><head></code>, а так же их дети или любые элементы с <code>display:none</code>, такие как <code>script { display: none; }</code>, не будут включены в дерево рендера, так как они не должны быть отрисованы. Узлы с правилом <code>visibility: hidden</code> включены в дерево рендера, так как они все равно занимают своё место. Так как мы не указали никаких специальных правил для перезаписи стилей агента по умолчанию, узел <code>script</code> в примере выше также не будет включён в дерево рендера.</p> -<p>Каждый видимый узел имеет свои правила из CSSOM. Дерево рендера содержит все видимые узлы с их содержимым и вычисленными стилями. Стили определяются путем применения всех подходящих правил с использованием <a href="/en-US/docs/Web/CSS/Cascade">CSS каскада.</a></p> +<p>Каждый видимый узел имеет свои правила из CSSOM. Дерево рендера содержит все видимые узлы с их содержимым и вычисленными стилями. Стили определяются путём применения всех подходящих правил с использованием <a href="/en-US/docs/Web/CSS/Cascade">CSS каскада.</a></p> <h3 id="Компоновка_Layout">Компоновка (Layout)</h3> @@ -181,7 +181,7 @@ translation_of: Web/Performance/How_browsers_work <p>На веб-странице практически все элементы прямоугольны (box). Разные устройства и настройки подразумевают бесчисленное количество разных размеров видимой области. На начальной фазе браузер, учитывая размер видимой области, определяет какие размеры разных элементов должны быть на экране. Использует размер видимой области как базис, процесс начинает вычисление с элемента <code>body</code>, затем переходит к его потомкам, вычисляет размеры каждого элемента и резервирует место для тех элементов, размеры которых он ещё не знает (например, изображения).</p> -<p>Момент, когда позиция и размеры узлов вычислены, называется layout. Последующие вычисления позиций и размеров называются reflow. В нашем примере предполагаемый начальный layout происходит перед тем, как изображение получено. Так как мы не задавали размер изображения, в момент получения изображения произойдет reflow.</p> +<p>Момент, когда позиция и размеры узлов вычислены, называется layout. Последующие вычисления позиций и размеров называются reflow. В нашем примере предполагаемый начальный layout происходит перед тем, как изображение получено. Так как мы не задавали размер изображения, в момент получения изображения произойдёт reflow.</p> <h3 id="Отрисовка_Paint">Отрисовка (Paint)</h3> @@ -189,7 +189,7 @@ translation_of: Web/Performance/How_browsers_work <p>Чтобы обеспечить плавную прокрутку и анимацию, отрисовка каждого элемента занимает весь основной поток. Сюда включается вычисление стилей, повторное вычисление стилей и отрисовка. Все эти этапы должны выполняться не дольше 16.67 мс. (1000мс. / 60 кадров в секунду). При разрешении 2048х1536 экран iPad содержит 3.145.000 пикселей, которые должны быть отрисованы. Это много! Для того, чтобы сделать инициирующую и повторную отрисовки быстрее, можно разбить весь процесс на несколько слоёв. Когда это случается - становится необходима композиция.</p> -<p>Отрисовка может разбить элементы в дереве рендера на слои. Для того, чтобы ускорить их рендер, браузер может перенести отрисовку разных слоев на GPU (вместо основного потока CPU). Для переноса вычислений отрисовки на GPU вы можете использовать некоторые специальные HTML теги, например <code><a href="/en-US/docs/Web/HTML/Element/video"><video></a></code> и <code><a href="/en-US/docs/Web/HTML/Element/canvas"><canvas></a></code>; а также CSS-свойства <a href="/en-US/docs/Web/CSS/opacity"><code>opacity</code></a>, <code><a href="/en-US/docs/Web/CSS/transform">transform</a></code> и <code><a href="/en-US/docs/Web/CSS/will-change">will-change</a></code>. Узлы, созданные таким образом, будут отрисованы на их собственном слое, вместе с их потомками, если только потомки сами по себе не будут вынесены в отдельные слои.</p> +<p>Отрисовка может разбить элементы в дереве рендера на слои. Для того, чтобы ускорить их рендер, браузер может перенести отрисовку разных слоёв на GPU (вместо основного потока CPU). Для переноса вычислений отрисовки на GPU вы можете использовать некоторые специальные HTML теги, например <code><a href="/en-US/docs/Web/HTML/Element/video"><video></a></code> и <code><a href="/en-US/docs/Web/HTML/Element/canvas"><canvas></a></code>; а также CSS-свойства <a href="/en-US/docs/Web/CSS/opacity"><code>opacity</code></a>, <code><a href="/en-US/docs/Web/CSS/transform">transform</a></code> и <code><a href="/en-US/docs/Web/CSS/will-change">will-change</a></code>. Узлы, созданные таким образом, будут отрисованы на их собственном слое, вместе с их потомками, если только потомки сами по себе не будут вынесены в отдельные слои.</p> <p>Слои улучшают производительность. Но, с точки зрения управления памяти, они неэффективны. Поэтому старайтесь не использовать их там, где в нет необходимости.</p> |