path: root/files/ru/web/performance/how_browsers_work/index.html

---
title: Как работают браузеры
slug: Web/Performance/How_browsers_work
tags:
  - Browsers
  - DNS Lookup
  - SSL/TLS Handshake
  - TCP handshake
  - Критический путь рендеринга
  - Навигация
  - Производительность
  - загрузка страницы
  - композиция
  - отрисовка
  - рендеринг
translation_of: Web/Performance/How_browsers_work
---
<p>Пользователи хотят использовать приложения, в которых загрузка контента происходит быстро, а взаимодействие - плавно. Разработчик должен стараться оптимизировать своё приложение как минимум по этим двум показателям.</p>

<p><span class="seoSummary">Чтобы понять, как улучшить производительность и ощущаемую пользователем производительность (User Perceived Performance, UPP), вам необходимо понимать, как работают браузеры.</span></p>

<h2 id="Обзор">Обзор</h2>

<p>Быстрые приложения дают лучшие ощущения. Пользователи ожидают, что приложение будет грузиться быстро, а взаимодействие с ним будет плавным.</p>

<p>Две главных проблемы в производительности - это проблема скорости сети и проблема однопоточности браузеров.</p>

<p>Сетевые задержи - это главная проблема, которую нужно преодолеть при достижении быстрой загрузки. Чтобы ускорить загрузку разработчик должен посылать запрошенные данные как можно быстрее или, на худой конец, сделать вид, что они отправляются очень быстро. Сетевые задержки - это время, которое требуется для передачи данных от источника к браузеру. Производительность здесь - это то, что делает загрузку страницу как можно более скорой.</p>

<p>В большинстве своём браузеры рассматриваются как однопоточные приложения. Чтобы достичь плавности взаимодействия, разработчик должен обеспечивать производительность во всём, начиная от плавного скроллинга, до быстрой реакции на нажатие экрана. Время рендера - это ключевое понятие. Разработчик должен обеспечить такую работу приложения, чтобы все его задачи могли быть выполнены достаточно быстро. В таком случае процессор будет свободен для обработки пользовательского ввода. Для решения проблемы однопоточности вы должны понять природу браузеров и научиться разгружать основной поток процесса там, где это возможно и допустимо.</p>

<h2 id="Навигация">Навигация</h2>

<p>Навигация - это первый этап при загрузке приложения. Он происходит каждый раз, когда пользователь запрашивает страницу, вводя URL в адресную строку браузера, нажимает на ссылку, отправляет заполненные поля формы и выполняет некоторые другие действия.</p>

<p>Одна из задач разработчика - сократить время, которое требуется приложению, чтобы этап навигации завершился. В идеальных условиях это обычно не занимает много времени, но задержки сети и ширина канала - препятствия, которые приводят к задержкам загрузки приложения.</p>

<h3 id="DNS_запрос">DNS запрос</h3>

<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><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>

<p>Это может быть проблемой с точки зрения производительности, особенно для мобильных сетей. Когда пользователь находится в мобильной сети, каждый DNS запрос должен пройти от мобильного устройства до сотовой вышки, а уже оттуда дойти до авторитетного DNS-сервера. Расстояние и помехи между телефоном, вышкой и сервером имён могут значительно увеличить задержку.</p>

<h3 id="TCP_Рукопожатие_Handshake">TCP Рукопожатие (Handshake)</h3>

<p>В тот момент, когда IP адрес становится известен, браузер начинает установку соединения к серверу с помощью рукопожатия {{glossary('TCP handshake','TCP three-way handshake')}}. Этот механизм спроектирован так, чтобы два устройства, пытающиеся установить связь, могли обменяться параметрами соединения, прежде чем приступать к передаче данных. Чаще всего - через защищённое соединение {{glossary('HTTPS')}}.</p>

<p>Трёхэтапное рукопожатие TCP - это техника, очень часто упоминаемая как "SYN-SYN-ACK" (<code>SYN, SYN-ACK, ACK</code>, если быть точнее), т.к. при установке соединения передаются 3 сообщения. Это означает, что прежде чем установится соединение, браузер должен обменяться ещё тремя сообщениями с сервером.</p>

<h3 id="TLS_Переговоры_Negotiation">TLS Переговоры (Negotiation)</h3>

<p>Для установки безопасных соединений с использованием HTTPS требуется ещё одно рукопожатие. На этот раз - {{glossary('TLS')}} переговоры. На этом шаге определяется, какой шифр будет использоваться для шифрования соединения, удостоверяется надёжность сервера и устанавливается безопасное соединение. Этот шаг также требует несколько дополнительных сообщений, которыми должны обменяться сервер и браузер, прежде чем данные будут посланы.</p>

<p><img alt="The DNS lookup, the TCP handshake, and 5 steps of the TLS handshake including clienthello, serverhello and certificate, clientkey and finished for both server and client." src="https://mdn.mozillademos.org/files/16746/ssl.jpg" style="height: 412px; width: 729px;"></p>

<p>И хотя обеспечение безопасности соединения снижает скорость загруки приложения, безопасное соединение стоит затрат на него, так как в этом случае данные не могут быть дешифрованы третьим лицом.</p>

<p>После обмена восемью сообщениями, браузер, наконец, достигает всех условий, чтобы сделать запрос.</p>

<h2 id="Ответ_на_запрос">Ответ на запрос</h2>

<p>Как только мы установили соединение с веб-сервером, браузер отправляет инициирующий <a href="/en-US/docs/Web/HTTP/Methods">HTTP <code>GET</code> запрос</a> от имени пользователя. Чаще всего запрашивается HTML файл. В момент, когда сервер получает запрос, он начинает ответ с посылки заголовков ответа и содержимым HTML-файла.</p>

<pre class="brush: html notranslate">&lt;!doctype HTML&gt;
&lt;html&gt;
 &lt;head&gt;
  &lt;meta charset="UTF-8"/&gt;
  &lt;title&gt;My simple page&lt;/title&gt;
  &lt;link rel="stylesheet" src="styles.css"/&gt;
  &lt;script src="myscript.js"&gt;&lt;/script&gt;
&lt;/head&gt;
&lt;body&gt;
  &lt;h1 class="heading"&gt;My Page&lt;/h1&gt;
  &lt;p&gt;A paragraph with a &lt;a href="https://example.com/about"&gt;link&lt;/a&gt;&lt;/p&gt;
  &lt;div&gt;
    &lt;img src="myimage.jpg" alt="image description"/&gt;
  &lt;/div&gt;
  &lt;script src="anotherscript.js"&gt;&lt;/script&gt;
&lt;/body&gt;
&lt;/html&gt;</pre>

<p>Этот ответ содержит в себе первый байт полученных данных. Время до первого байта ({{glossary('Time to First Byte')}}, TTFB) - это время между моментом когда пользователь отправил запрос, скажем, нажав на ссылку, и моментом получения первого пакета данных HTML. Первый пакет обычно содержит 14КБ данных.</p>

<p>В примере выше ответ значительно меньше, чем 14КБ; скрипты и стили, перечисленные в ответе, не будут запрошены, пока браузер не обработает ответ. Процесс обработки ответа - парсинг - мы обсудим отдельно.</p>

<h3 id="TCP_медленный_старт_правило_14kb">TCP медленный старт / правило 14kb</h3>

<p>Объём первого пакета данных - всегда 14KB. Это часть спецификации {{glossary('TCP slow start')}} - алгоритма, который балансирует скорость соединения. Такое правило позволяет постепенно, по мере необходимости, увеличивать размеры передаваемых данных, пока не будет определена максимальная ширина канала.</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>

<p>Если вы когда-то слышали о правиле 14КБ, то должны понимать, что оптимизация производительности загрузки должна учитывать ограничения этого начального запроса. Медленный старт TCP позволяет плавно ускорять передачу данных так, чтобы избежать проблемы переполнения, когда много данных ожидают отправки, но не отправляются из-за ограничений ширины канала.</p>

<h3 id="Контроль_переполнения">Контроль переполнения</h3>

<p>Любое соединение имеет ограничения, связанные с аппаратной и сетевой системами. Если сервер отправит слишком много пакетов за раз - они могут быть отброшены. Для того, чтобы избежать таких проблем, браузер должен реагировать на получение пакетов и подтверждать, что он получает их. Такой ответ-подтверждение называется Aknowledgements (ACK). Если из-за ограничений соединения браузер не получит данных, то он не пошлёт подтверждений ACK. В этом случае, сервер зарегистрирует, что какие-то пакет не дошли и пошлёт их заново, что приведет к лишней работе сервера и дополнительной нагрузке сети.</p>

<h2 id="Парсинг">Парсинг</h2>

<p>Как только браузер получает первый кусочек данных, он сразу начинает обрабатывать получаемую информацию. Эта обработка называется "Парсинг" ({{glossary('speculative parsing', 'Parsing')}}). Во время парсинга получаемые данные преобразуются в {{glossary('DOM')}} и {{glossary('CSSOM')}}, которые напрямую участвуют в отрисовке.</p>

<p>DOM (Объектная модель документа) - это внутреннее представление разметки HTML. Браузер предоставляет доступ к манипуляции объектами этой модели через разные JavaScript API.</p>

<p>Даже если ответ на запрос больше 14КБ, браузер все равно начинает парсинг данных и пытается отрисовать страницу с теми данными, которые уже доступны. Именно поэтому при оптимизации производительности очень важно включать в инициирующий 14КБ ответ все необходимые для рендера данные - так браузер сможет быстрее начать формирование страницы. Однако, прежде чем что-либо появится на экране, HTML, CSS и JavaScript должны быть обработаны.</p>

<h3 id="Построение_дерева_объектной_модели_документа">Построение дерева объектной модели документа</h3>

<p>Мы уже рассказывали о пяти шагах в <a href="/ru/docs/Web/Performance/Critical_rendering_path">критическом пути рендеринга</a>.</p>

<p>Первый шаг - это обработка разметки HTML и построение дерева DOM. Обработка HTML включает в себя токенизацию и построение дерева. HTML-токены состоят из тегов старта и финиша, а также атрибутов. Если документ сформирован правильно, его обработка прямолинейна и быстра. Парсер (обработчик) преобразует входящие токены в документ и строит дерево документа.</p>

<p>Объектная модель документа (DOM) описывает содержимое документа. Элемент <code><a href="/en-US/docs/Web/HTML/Element/html">&lt;html&gt;</a></code> - это первый тег и корневой элемент дерева документа. Дерево отражает связи и иерархию между разными тегами. Теги, вложенные в другие теги являются детьми. Чем больше существует узлов в дереве, тем сложнее это дерево построить.</p>

<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>&lt;script&gt;</code>, особенно если он без параметров <code>async</code> или <code>defer</code> - такой скрипт считается блокирующим и приостанавливает обработку HTML до завершения загрузки скрипта. Несмотря на то, что сканер предзагрузки (о нём ниже) браузера может находить и запрашивать такие скрипты заранее, сложные и объемные скрипты всё ещё могут стать причиной заметных задержек загрузки страницы.</p>

<h3 id="Сканер_предзагрузки">Сканер предзагрузки</h3>

<p>Построение дерева DOM занимает весь поток процесса. Так как это явно узкое место в производительности, был создан особый сканер предзагрузки. Он обрабатывает доступное содержимое документа и запрашивает высокоприоритетные ресурсы (CSS, JavaScript и шрифты). Благодаря этому сканеру нам не нужно ждать, пока парсер дойдет до конкретного места, где вызывается ресурс. Он запрашивает и получает эти данные заранее, в фоновом режиме, так что когда основной поток HTML-парсера доходит до запроса ресурса, высока вероятность, что ресурс уже запрошен или находится в процессе загрузки. Оптимизации, которые даёт этот сканер, уменьшают время блокирования рендера.</p>

<pre class="brush:html notranslate">&lt;link rel="stylesheet" src="styles.css"/&gt;
&lt;script src="myscript.js" <strong>async</strong>&gt;&lt;/script&gt;
&lt;img src="myimage.jpg" alt="image description"/&gt;
&lt;script src="anotherscript.js" <strong>async</strong>&gt;&lt;/script&gt;
</pre>

<p>В примере выше основной поток обрабатывает HTML и CSS. В то же время, сканер предзагрузки находит скрипты и изображение и начинает их загрузку. Чтобы сделать скрипт неблокирующим, добавьте атрибут <code>async</code> или, в случае, если порядок загрузки скриптов не важен, атрибут <code>defer</code>.</p>

<div class="blockIndicator note">
<p>Ожидание получения CSS не блокирует парсинг HTML, но он блокирует JavaScript, потому что JavaScript часто используется для выборки узлов документа по CSS-селекторам.</p>
</div>

<h3 id="Построение_модели_стилей_CSSOM">Построение модели стилей CSSOM</h3>

<p>Второй шаг при прохождении критического пути рендеринга - это обработка CSS и построение CSSOM дерева. CSSOM (объектная модель CSS) похожа на DOM. И DOM, и CSSOM - это деревья. Они являются независимыми структурами данных. Браузер преобразует CSS файлы в карту стилей, которую он может понять и с которой может работать. Браузер считывает каждый набор правил в CSS, создает дерево узлов с родителями, детьми и соседями, основываясь на CSS селекторах.</p>

<p>Как и в HTML, браузер должен преобразовать полученные правила CSS во что-то, с чем он может работать. Таким образом, весь этот процесс - это повторение формирования DOM, только для CSS.</p>

<p>CSSOM дерево включает в себя стили пользовательского агента - это стили, которые браузер вставляет по умолчанию. Браузер начинает построение модели с наиболее общих правил для каждого узла, постепенно применяя более специфичные правила. Другими словами, он применяет правила каскадно. Отсюда и название CSS - Cascading Style Sheets.</p>

<p>Построение CSSOM происходит очень быстро и не отображается отдельным цветом в средствах разработчика. Оно настолько быстрое, что чаще всего включается в показатель "Повторное вычисление стилей (Recalculate Styles)" в средствах разработчика. Этот показатель показывает общее время обработки стилей - обработку CSS, построение CSSOM и рекурсивное вычисление стилей. С точки зрения оптимизации производительности здесь нечего делать, так как построение CSSOM, в целом, занимает даже меньше времени, чем DNS запрос.</p>

<h3 id="Остальные_процессы">Остальные процессы</h3>

<h4 id="Компиляция_JavaScript">Компиляция JavaScript</h4>

<p>Как CSS обработан и CSSOM создан, другие ресурсы, например, JavaScript-файлы, продолжают загружаться (спасибо сканеру предзагрузки). JavaScript по окончании загрузки должен быть интерпретирован, скомпилирован, обработан и исполнен. Скрипты преобразовываются в абстрактное синтаксическое дерево (AST). Некоторые браузеры берут {{glossary('Abstract Syntax Tree')}} и передают его в интерпретатор, который преобразует дерево в байт-код. Байткод исполняется в основном потоке. Весь этот процесс называется компиляцией.</p>

<h4 id="Построение_дерева_доступности">Построение дерева доступности</h4>

<p>Браузер также строит дерево <a href="/en-US/docs/Learn/Accessibility">доступности</a>, которое используется устройствами-помощниками для понимания и интерпретирования контента. Объектная модель доступности (accessibility object model, AOM) - это семантическая версия DOM. Браузер обновляет AOM в тот же момент, когда обновляется DOM. В то же время, дерево доступности не может быть изменено вспомогательными технологиями.</p>

<p>Пока модель AOM не построена, содержимое страницы недоступно для <a href="/en-US/docs/Web/Accessibility/ARIA/ARIA_Screen_Reader_Implementors_Guide">голосовых помощников и считывателей экрана</a>.</p>

<h2 id="Рендеринг">Рендеринг</h2>

<p>Этапы рендеринга включают в себя стилизацию, компоновку (layout), отрисовку (paint) и, в некоторых случаях, композицию (composition). CSSOM и DOM деревья, созданные на предыдущем этапе комбинируются в дерево рендера, которое затем используется для расчёта положения каждого видимого элемента. После этого элементы будут отрисованы на экране. В некоторых случаях содержимое может быть вынесено на отдельные слои и совмещено (composition) - такой подход увеличивает производительность, позволяя отрисовывать содержимое экрана на графическом процессоре вместо ЦПУ. Это освобождает основной поток.</p>

<h3 id="Стилизация">Стилизация</h3>

<p>Третий шаг в критическом пути рендеринга - это комбинирование DOM и CSSOM в дерево рендеринга. Конструирование этого дерева начинается с прохода всего DOM-дерева от корня, с выявлением каждого видимого узла.</p>

<p>Элементы, которые не должны быть показаны, например, <code>&lt;head&gt;</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>

<h3 id="Компоновка_Layout">Компоновка (Layout)</h3>

<p>Четвёртый шаг на критическом пути рендеринга - это запуск компоновки (layout) элементов дерева рендера. На этом шаге вычисляется геометрия каждого узла, то есть ширина, высота, положение элементов. Reflow (перекомпоновка) - это любой последующий процесс определения размеров и позиции для любой из частей целого документа.</p>

<p>Как только дерево рендера построено - начинается layout. Дерево несёт в себе информацию о том, какие узлы должны быть отрисованы (даже если они невидимы), и какие стили должны быть применены, но в дереве нет никакой информации о размерах и позиции элементов. Чтобы определить эти значения, браузер начинает обход дерева.</p>

<p>На веб-странице практически все элементы прямоугольны (box). Разные устройства и настройки подразумевают бесчисленное количество разных размеров видимой области. На начальной фазе браузер, учитывая размер видимой области, определяет какие размеры разных элементов должны быть на экране. Использует размер видимой области как базис, процесс начинает вычисление с элемента <code>body</code>, затем переходит к его потомкам, вычисляет размеры каждого элемента и резервирует место для тех элементов, размеры которых он ещё не знает (например, изображения).</p>

<p>Момент, когда позиция и размеры узлов вычислены, называется layout. Последующие вычисления позиций и размеров называются reflow. В нашем примере предполагаемый начальный layout происходит перед тем, как изображение получено. Так как мы не задавали размер изображения, в момент получения изображения произойдет reflow.</p>

<h3 id="Отрисовка_Paint">Отрисовка (Paint)</h3>

<p>Последний шаг критического пути рендеринга - это отрисовка каждого отдельного узла на экране. Момент, когда это происходит впервые, называется <a href="/en-US/docs/Glossary/first_meaningful_paint">first meaningful paint</a> (первая значащая отрисовка). Во время фазы отрисовки или растеризации, браузер конвертирует каждый контейнер box в настоящие пиксели на экране (напомним, что данные контейнеров формируются на этапе layout). Отрисовка подразумевает рисование каждой визуальной частицы элемента на экране (текст, цвета, границы, тени) и рисование заменяемых элементов (картинки, кнопки). Браузер должен выполнять это быстро.</p>

<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">&lt;video&gt;</a></code> и <code><a href="/en-US/docs/Web/HTML/Element/canvas">&lt;canvas&gt;</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>

<h3 id="Композиция_Compositing">Композиция (Compositing)</h3>

<p>Когда разделы документа отрисованы на разных слоях, а один слой находится над другим или перекрывает его, становится необходима композиция. Этот шаг позволяет браузеру гарантировать, что каждый слой отрисован на экране в правильном порядке, а содержимое отображается корректно.</p>

<p>При догрузке ранее запрошенных ресурсов (например, изображений) может потребоваться перерассчитать размеры и положение элементов относительно друг друга. Этот перерасчёт - reflow - запускает перерисовку (repaint) и перекомпозицию (re-composite). Если мы заранее определили размер изображения, перерасчёт не будет необходим и в этом случае только тот слой, который должен быть перерисован - будет перерисован. Но если мы не определили размер изображения заранее, то браузер, после получения ответа от сервера, будет вынужден отмотать процесс рендеринга обратно к шагу компоновки (layout) и начать процесс отрисовки ещё раз.</p>

<h2 id="Интерактивность">Интерактивность</h2>

<p>Можно было бы подумать, что как только основной поток завершает отрисовку страницы - "всё готово". Это не всегда так. Если среди загружаемых ресурсов есть JavaScript, загрузка которого была корректно отложена, а запуск которого происходит только после события <code><a href="/en-US/docs/Web/API/GlobalEventHandlers/onload">onload</a></code>, основной поток начинает обработку скриптов. Во время этой обработки браузер не может обрабатывать события прокрутки, нажатий и др.</p>

<p>{{glossary('Time to Interactive')}} (TTI, время до интерактивности) - это показатель того, как много времени проходит между самым первым сетевым запросом и моментом, когда страница становится интерактивной. В хронологии этот этап следует сразу за {{glossary('First Contentful Paint')}}. Интерактивностью называется показатель того, что страница отреагировала на действие пользователя за время в 50мс. Если процессор занят обработкой, компиляцией и выполнением JavaScript, то браузер не может отреагировать достаточно быстро, а значит страница считается не интерактивной.</p>

<p>В нашем примере, даже несмотря на то, что изображение загрузилось быстро, скрипт <code>anotherscript.js</code>, размер которого достигает 2МБ, загружается долго. В этом случае пользователь увидит страницу очень быстро, но не будет способен взаимодействовать с ней, пока скрипт не будет загружен, обработан и исполнен. Это плохая практика. Старайтесь избегать полной загрузки процесса.</p>

<p><img alt="The main thread is occupied by the downloading, parsing and execution of a  javascript file - over a fast connection" src="https://mdn.mozillademos.org/files/16760/visa_network.png" style="height: 699px; width: 1200px;"></p>

<p>В примере выше загрузка содержимого DOM заняла около 1.5 секунд. Все это время основной поток процесса был полностью загружен и не был способен обработать пользовательский ввод.</p>

<h2 id="См._также">См. также:</h2>

<ul>
 <li><a href="/ru/docs/Web/Performance">Производительность Web</a></li>
</ul>