diff options
Diffstat (limited to 'files/ru/web/performance')
12 files changed, 67 insertions, 67 deletions
diff --git a/files/ru/web/performance/animation_performance_and_frame_rate/index.html b/files/ru/web/performance/animation_performance_and_frame_rate/index.html index 9b9121b742..8ccf7fb88d 100644 --- a/files/ru/web/performance/animation_performance_and_frame_rate/index.html +++ b/files/ru/web/performance/animation_performance_and_frame_rate/index.html @@ -13,7 +13,7 @@ original_slug: Web/Performance/Производительность_анимац --- <p>Анимация в Вебе может быть сделана с помощью {{domxref('SVGAnimationElement', 'SVG')}}, {{domxref('window.requestAnimationFrame','JavaScript')}}, включая {{htmlelement('canvas')}} и {{domxref('WebGL_API', 'WebGL')}}, CSS {{cssxref('animation')}}, {{htmlelement('video')}}, анимированных GIF и даже с помощью анимированных PNG и других типов изображений. Производительность CSS анимации может отличаться от одного CSS-свойства к другому, а попытка анимировать некоторые "дорогие" CSS-свойства может привести к зависаниям ({{glossary('jank')}}), даже несмотря на то, что браузер борется за то, чтобы смягчить частоту смены кадров {{glossary('frame rate')}}.</p> -<p>Для анимированных медиа, таких как видео и GIF, основная проблема производительности - это размер файлов. Скачивание больших по объему файлов не может не повлиять на производительность системы или на то, как эту систему воспринимает пользователь. </p> +<p>Для анимированных медиа, таких как видео и GIF, основная проблема производительности - это размер файлов. Скачивание больших по объёму файлов не может не повлиять на производительность системы или на то, как эту систему воспринимает пользователь. </p> <p>Анимации, основанные на коде, будь то CSS, SVG, <canvas>, webGL или другие JavaScript анимации, могут нести проблемы производительности сами в себе, даже если файлы этого кода скачиваются быстро. Такие анимации могут потреблять всё время CPU и приводить к зависаниям.</p> @@ -25,12 +25,12 @@ original_slug: Web/Performance/Производительность_анимац <p>Графики <a href="/en-US/docs/Tools/Performance/Frame_rate">frame rate</a> и <a href="/en-US/docs/Tools/Performance/Waterfall">waterfall</a> из встроенных инструментов браузера дают информацию о том, как браузер выполняет работу по анимации. Используя эти инструменты, вы можете измерить fps приложения и диагностировать узкие места, в которых fps уменьшается.</p> -<p>С помощью <a href="/en-US/docs/Web/Guide/CSS/Using_CSS_animations">CSS анимации</a> вы указываете <a href="/en-US/docs/Web/CSS/@keyframes">ключевые кадры (keyframes)</a>, каждый из которых использует определенные CSS свойства, чтобы определить внешний вид элемента в конкретный (ключевой) момент анимации. Браузер создает анимации с помощью плавных переходов от одного ключевого кадра к следующему.</p> +<p>С помощью <a href="/en-US/docs/Web/Guide/CSS/Using_CSS_animations">CSS анимации</a> вы указываете <a href="/en-US/docs/Web/CSS/@keyframes">ключевые кадры (keyframes)</a>, каждый из которых использует определённые CSS свойства, чтобы определить внешний вид элемента в конкретный (ключевой) момент анимации. Браузер создаёт анимации с помощью плавных переходов от одного ключевого кадра к следующему.</p> <p>Если сравнивать анимацию с помощью JavaScript и CSS, вы увидите, что CSS-анимации проще создать. Более того, CSS-анимации гарантируют лучшую производительность, так как они автоматически делегируют некоторые задачи браузеру. Например, в случае CSS браузер сам решает, когда нужно отрендерить кадр, а когда пропустить кадр, если это необходимо. </p> <p><br> - Однако, стоимость изменения разных CSS свойств варьируется. Общепринято, что 60 кадров в секунду - это достаточная частота, чтобы анимация выглядела мягкой и плавной. Несложный подсчет говорит, что при частоте 60 кадров в секунду, браузер имеет лишь 16.7 миллисекунд, чтобы выполнить все скрипты, пересчитать стили, скомпоновать слои и отрисовать новый кадр. Отсюда следует, что медленные скрипты и анимация дорогих CSS свойств может может привести к <a href="/en-US/docs/Glossary/Jank">зависаниям</a>, так как браузер все еще будет пытаться вычислить все 60 кадров.</p> + Однако, стоимость изменения разных CSS свойств варьируется. Общепринято, что 60 кадров в секунду - это достаточная частота, чтобы анимация выглядела мягкой и плавной. Несложный подсчёт говорит, что при частоте 60 кадров в секунду, браузер имеет лишь 16.7 миллисекунд, чтобы выполнить все скрипты, пересчитать стили, скомпоновать слои и отрисовать новый кадр. Отсюда следует, что медленные скрипты и анимация дорогих CSS свойств может может привести к <a href="/en-US/docs/Glossary/Jank">зависаниям</a>, так как браузер все ещё будет пытаться вычислить все 60 кадров.</p> <p>Стоит заметить, что 60 кадров в секунду - это стандартная частота обновления экрана. Существуют экраны с гораздо большим FPS. Например, экраны игровых ноутбуков или iPad Pro 2018 имеют частоту смены кадров, равную 120 fps и выше. Для таких устройств производители браузеров ограничивают частоту 60-ю кадрами в секунду, но с помощью некоторых опций этот лимит можно убрать. И в этом случае, на формирование каждого кадра устройство будет отводить лишь 8.6 миллисекунд.</p> @@ -42,7 +42,7 @@ original_slug: Web/Performance/Производительность_анимац <ol> <li><strong>Recalculate Style</strong>: когда любое CSS свойство для элемента изменяется, браузер должен заново вычислить результирующий набор свойств.</li> - <li><strong>Layout</strong>: затем браузер использует вычисленные стили для того, чтобы понять позицию и геометрию элементов - как измененного, так и рядом лежащих. Эта операция называется "layout", но иногда её так же называют "reflow".</li> + <li><strong>Layout</strong>: затем браузер использует вычисленные стили для того, чтобы понять позицию и геометрию элементов - как изменённого, так и рядом лежащих. Эта операция называется "layout", но иногда её так же называют "reflow".</li> <li><strong>Paint</strong>: наконец, браузер должен перерисовать элементы на экране. Но этот этап не обязательно должен быть простым, как на изображении. Страница может быть разделена на слои, каждый из которых перерисовывается независимо, а только после этого они комбинируются в процессе, который называется композицией "Composition".</li> </ol> @@ -100,7 +100,7 @@ original_slug: Web/Performance/Производительность_анимац <h2 id="Пример_margin_против_transform">Пример: margin против transform</h2> -<p>В этом разделе мы увидим, как инструмент <a href="/en-US/docs/Tools/Performance/Waterfall">Waterfall</a> может указать на разницу между анимацией. ёё <code><a href="/en-US/docs/Web/CSS/margin">margin</a></code> и <code><a href="/en-US/docs/Web/CSS/transform">transform</a></code>.</p> +<p>В этом разделе мы увидим, как инструмент <a href="/en-US/docs/Tools/Performance/Waterfall">Waterfall</a> может указать на разницу между анимацией. её <code><a href="/en-US/docs/Web/CSS/margin">margin</a></code> и <code><a href="/en-US/docs/Web/CSS/transform">transform</a></code>.</p> <p>Задумка этого сценария не в том, чтобы убедить вас, что анимация через <code>margin</code> - это всегда плохая идея. Сценарий нужен, чтобы продемонстрировать, как инструменты могут помочь вам понять работу браузера и как вы можете применить эти знания для оптимизации.</p> @@ -116,7 +116,7 @@ original_slug: Web/Performance/Производительность_анимац <h3 id="Анимация_свойства_margin">Анимация свойства margin</h3> -<p>Оставим включенной опцию "Use margin" и начнём анимацию. В это же время откроем "Performance tool" и нажмем кнопку "записать" (make a recording). Нам понадобится лишь пара секунд записи.</p> +<p>Оставим включённой опцию "Use margin" и начнём анимацию. В это же время откроем "Performance tool" и нажмём кнопку "записать" (make a recording). Нам понадобится лишь пара секунд записи.</p> <p>Откройте первую запись. Точное содержимое, которое вы увидите, зависит от вашего устройства, системной нагрузки и окружения, но, в целом это должно выглядеть так:</p> @@ -128,7 +128,7 @@ original_slug: Web/Performance/Производительность_анимац <p><img alt="" src="https://mdn.mozillademos.org/files/10857/margin-timeline-overview.png" style="display: block; height: 58px; margin-left: auto; margin-right: auto; width: 800px;"></p> -<p>Сейчас здесь показаны ужатые этапы рендеринга <a href="/en-US/docs/Tools/Performance/Waterfall">Waterfall</a>. Как видите, большая часть графика заполнена зеленым цветом - это говорит нам о том, что <a href="/en-US/docs/Tools/Performance/Timeline#timeline-color-coding">мы тратим много ресурсов на отрисовывание</a>.</p> +<p>Сейчас здесь показаны ужатые этапы рендеринга <a href="/en-US/docs/Tools/Performance/Waterfall">Waterfall</a>. Как видите, большая часть графика заполнена зелёным цветом - это говорит нам о том, что <a href="/en-US/docs/Tools/Performance/Timeline#timeline-color-coding">мы тратим много ресурсов на отрисовывание</a>.</p> <h4 id="Частота_кадров_Frame_Rate">Частота кадров (Frame Rate)</h4> @@ -158,7 +158,7 @@ original_slug: Web/Performance/Производительность_анимац <p><img alt="" src="https://mdn.mozillademos.org/files/10869/transform-timeline-overview.png" style="display: block; height: 57px; margin-left: auto; margin-right: auto; width: 800px;"></p> -<p>В сравнении с <a href="/en-US/docs/Tools/Performance/Scenarios/Animating_CSS_properties#Waterfall_overview">версией, которая использует margin</a>, мы видим намного меньше зеленого, но намного больше фиолетового цвета. Это говорит о том, что вместо paint мы теперь тратим ресурсы на этапы <a href="/en-US/docs/Tools/Performance/Waterfall#timeline-color-coding">layout или style recalculation</a>.</p> +<p>В сравнении с <a href="/en-US/docs/Tools/Performance/Scenarios/Animating_CSS_properties#Waterfall_overview">версией, которая использует margin</a>, мы видим намного меньше зелёного, но намного больше фиолетового цвета. Это говорит о том, что вместо paint мы теперь тратим ресурсы на этапы <a href="/en-US/docs/Tools/Performance/Waterfall#timeline-color-coding">layout или style recalculation</a>.</p> <h4 id="Частота_кадров_Frame_Rate_2">Частота кадров (Frame Rate)</h4> diff --git a/files/ru/web/performance/critical_rendering_path/index.html b/files/ru/web/performance/critical_rendering_path/index.html index ba9788828d..ee91e0e4c8 100644 --- a/files/ru/web/performance/critical_rendering_path/index.html +++ b/files/ru/web/performance/critical_rendering_path/index.html @@ -7,7 +7,7 @@ translation_of: Web/Performance/Critical_rendering_path --- <p><span class="seoSummary">Критические этапы рендеринга (Critical Rendering Path) - это последовательность шагов, которые выполняет браузер, когда преобразуется HTML, CSS и JavaScript в пиксели, которые вы видите на экране. Оптимизация этих шагов улучшает производительность рендера. Эти этапы включают в себя работу с <a href="/en-US/docs/Web/API/Document_Object_Model">Document Object Model </a>(DOM), <a href="/en-US/docs/Web/API/CSS_Object_Model">CSS Object Model </a>(CSSOM), деревом рендера (render tree) и компоновкой объектов (layout)</span></p> -<p>Объектная модель документа DOM создается в тот момент, когда браузер парсит HTML. Этот HTML может запрашивать JavaScript, который может модифицировать DOM. HTML может запросить стили, которые участвуют в создании CSS Object Model. Движок браузера комбинирует эти две объектные модели, чтобы создать дерево рендера (render tree). Компоновка (layout) определяет размеры и позицию каждого элемента на странице. Как только компоновка определена - пиксели отрисовываются на экране.</p> +<p>Объектная модель документа DOM создаётся в тот момент, когда браузер парсит HTML. Этот HTML может запрашивать JavaScript, который может модифицировать DOM. HTML может запросить стили, которые участвуют в создании CSS Object Model. Движок браузера комбинирует эти две объектные модели, чтобы создать дерево рендера (render tree). Компоновка (layout) определяет размеры и позицию каждого элемента на странице. Как только компоновка определена - пиксели отрисовываются на экране.</p> <p>Оптимизация критических этапов рендеринга улучшает время до первого рендера. Понимание и оптимизация этих этапов чрезвычайно важны для того, чтобы рендерить приложение с нужной частотой кадров (60 кадров в секунду, fps) и предоставить пользователю удобный, плавный интерфейс.</p> @@ -15,21 +15,21 @@ translation_of: Web/Performance/Critical_rendering_path <p>Производительность Web-приложений включает в себя запросы к серверу, получение ответов, загрузку, парсинг и выполнение скриптов, рендеринг, компоновку и отрисовку пикселей. </p> -<p>Загрузка веб-страницы или приложения начинается с запроса HTML. Сервер возвращает HTML заголовке (headers) и некоторые данные. Браузер начинает парсить полученный ответ HTML, преобразуя полученные байты в DOM-дерево. Браузер создает новый запрос каждый раз, когда он находит ссылки на внешние ресурсы, будь то файлы стилей, скриптов или ссылки на изображения. Некоторые запросы являются блокирующими. Это означает, что пока такие запросы выполняются - другие запросы приостанавливается. Браузер продолжает парсить HTML и создавать DOM до тех пор, пока запрос на получение HTML не подходит к концу. После завершения парсинга DOM, браузер конструирует CSS модель. Как только эти модели сформированы, браузер строит дерево рендера (render tree), в котором вычисляет стили для каждого видимого элемента страницы. После формирования дерева происходит компоновка (layout), которая определяет положение и размеры элементов этого дерева. Как только этап завершён - страница рендерится. Или "отрисовывается" (paint) на экране.</p> +<p>Загрузка веб-страницы или приложения начинается с запроса HTML. Сервер возвращает HTML заголовке (headers) и некоторые данные. Браузер начинает парсить полученный ответ HTML, преобразуя полученные байты в DOM-дерево. Браузер создаёт новый запрос каждый раз, когда он находит ссылки на внешние ресурсы, будь то файлы стилей, скриптов или ссылки на изображения. Некоторые запросы являются блокирующими. Это означает, что пока такие запросы выполняются - другие запросы приостанавливается. Браузер продолжает парсить HTML и создавать DOM до тех пор, пока запрос на получение HTML не подходит к концу. После завершения парсинга DOM, браузер конструирует CSS модель. Как только эти модели сформированы, браузер строит дерево рендера (render tree), в котором вычисляет стили для каждого видимого элемента страницы. После формирования дерева происходит компоновка (layout), которая определяет положение и размеры элементов этого дерева. Как только этап завершён - страница рендерится. Или "отрисовывается" (paint) на экране.</p> <h3 id="Document_Object_Model">Document Object Model</h3> <p>Построение DOM инкрементально. Ответ в виде HTML превращается в токены, которые превращаются в узлы (nodes), которые формируют DOM дерево. Простейший узел начинается с startTag-токена и заканчивается токеном endTag. Узлы содержат всю необходимую информацию об HTML элементе, соответствующем этому узлу. Узлы (nodes) связаны с Render Tree с помощью иерархии токенов: если какой-то набор startTag и endTag-токенов появляется между уже существующим набором токенов, мы получаем узел (node) внутри узла (node), то есть получаем иерархию дерева DOM.</p> -<p>Чем больше количество узлов (node) имеет приложение, тем дольше происходит формирование DOM tree, а значит дольше происходит обработка критических этапов рендеринга. Измеряйте! Несколько лишних узлов (node) не сделают погоды, но <a href="https://en.wiktionary.org/wiki/divitis">divitis</a> обязательно приведет к подвисаниям.</p> +<p>Чем больше количество узлов (node) имеет приложение, тем дольше происходит формирование DOM tree, а значит дольше происходит обработка критических этапов рендеринга. Измеряйте! Несколько лишних узлов (node) не сделают погоды, но <a href="https://en.wiktionary.org/wiki/divitis">divitis</a> обязательно приведёт к подвисаниям.</p> <h3 id="CSS_Object_Model">CSS Object Model</h3> -<p>DOM несет в себе всё содержимое страницы. CSSOM содержит все стили страницы, то есть данные о том, как стилизовать DOM. CSSOM похож на DOM, но всё же отличается. Если формирование DOM инкрементально, CSSOM - нет. CSS блокирует рендер: браузер блокирует рендеринг страницы до тех пор, пока не получит и не обработает все CSS-правила. CSS блокирует рендеринг, потому что правила могут быть перезаписаны, а значит, необходимо дождаться построения CSSOM, чтобы убедиться в отсутствии дополнительных переопределений.</p> +<p>DOM несёт в себе всё содержимое страницы. CSSOM содержит все стили страницы, то есть данные о том, как стилизовать DOM. CSSOM похож на DOM, но всё же отличается. Если формирование DOM инкрементально, CSSOM - нет. CSS блокирует рендер: браузер блокирует рендеринг страницы до тех пор, пока не получит и не обработает все CSS-правила. CSS блокирует рендеринг, потому что правила могут быть перезаписаны, а значит, необходимо дождаться построения CSSOM, чтобы убедиться в отсутствии дополнительных переопределений.</p> -<p>У CSS имеются свои правила валидации токенов. Помните, что C в CSS означает "Cascade". CSS правила ниспадают каскадом. Иными словами, когда парсер преобразует токены в узлы (nodes), вложенные узлы наследуют стили от родительских. Инкрементальная обработка недоступна для CSS, потому что набор следующих правил может перезаписать предыдущие. Объектная модель CSS (CSSOM) строится по мере парсинга CSS, но она не может быть использована для построения дерева рендера (render tree), потому что может оказаться так, что следующий набор правил может сделать какой-либо из узлов дерева невидимым на экране. Это может привести к лишнему вызову компоновки и перерасчета стилей.</p> +<p>У CSS имеются свои правила валидации токенов. Помните, что C в CSS означает "Cascade". CSS правила ниспадают каскадом. Иными словами, когда парсер преобразует токены в узлы (nodes), вложенные узлы наследуют стили от родительских. Инкрементальная обработка недоступна для CSS, потому что набор следующих правил может перезаписать предыдущие. Объектная модель CSS (CSSOM) строится по мере парсинга CSS, но она не может быть использована для построения дерева рендера (render tree), потому что может оказаться так, что следующий набор правил может сделать какой-либо из узлов дерева невидимым на экране. Это может привести к лишнему вызову компоновки и перерасчёта стилей.</p> -<p>Говоря о производительности селекторов (selector), наименее специфичные селекторы срабатывают быстрее. Например, <code>.foo {}</code> сработает быстрее <code>.bar .foo {}</code>. В первом случае, условно, понадобится одна операция, чтобы найти элемент <code>.foo</code>, во втором случае, сначала будут найдены все <code>.foo</code>, а<strong> </strong>потом<strong> браузер пройдет вверх</strong> по дереву в поисках родительского элемента <code>.bar</code>. Более специфичные селекторы требуют от браузера большего количества работы, но эти проблемы, вероятно, не стоят их оптимизации.</p> +<p>Говоря о производительности селекторов (selector), наименее специфичные селекторы срабатывают быстрее. Например, <code>.foo {}</code> сработает быстрее <code>.bar .foo {}</code>. В первом случае, условно, понадобится одна операция, чтобы найти элемент <code>.foo</code>, во втором случае, сначала будут найдены все <code>.foo</code>, а<strong> </strong>потом<strong> браузер пройдёт вверх</strong> по дереву в поисках родительского элемента <code>.bar</code>. Более специфичные селекторы требуют от браузера большего количества работы, но эти проблемы, вероятно, не стоят их оптимизации.</p> <p>Если вы измерите время, требуемое на парсинг CSS, вы будете удивлены тем, как быстро работают браузеры. Более специфичные правила более затратны, потому что требуют обхода большего числа узлов в DOM дереве, но эта дороговизна обходится довольно дёшево, особенно в сравнении с другими узкими местами производительности. <u>Сначала измеряйте. Потом оптимизируйте, если это действительно необходимо.</u> Вероятно, специфичность селекторов не то, что действительно затормаживает ваше приложение. Когда дело доходит до оптимизации CSS, улучшение производительность селекторов ускоряет рендеринг лишь на микросекунды. Существуют другие <a href="/en-US/docs/Learn/Performance/CSS_performance">пути оптимизации CSS</a>, такие как унификация, разделение CSS-файлов на разные файлы на основе media-queries.</p> @@ -43,17 +43,17 @@ translation_of: Web/Performance/Critical_rendering_path <p>В тот момент, когда дерево рендера (render tree) построено, становится возможным этап компоновки (layout). Компоновка зависит от размеров экрана. Этот этап определяет, где и как на странице будут спозиционированы элементы и каковы связи между элементами.</p> -<p>Что насчет ширины элемента? Блочные элемент по определению имеют ширину в 100% от ширины их родителя. Элемент с шириной в 50% будет иметь ширину в два раза меньше родительской. Если не указано иного, элемент body имеет ширину 100%, то есть 100% ширины родителя - видимой области viewport (окна документа).</p> +<p>Что насчёт ширины элемента? Блочные элемент по определению имеют ширину в 100% от ширины их родителя. Элемент с шириной в 50% будет иметь ширину в два раза меньше родительской. Если не указано иного, элемент body имеет ширину 100%, то есть 100% ширины родителя - видимой области viewport (окна документа).</p> <p>Мета тэг viewport, который вы можете указать в Head страницы, определяет ширину видимой области и влияет на компоновку. Без этого тэга браузеры используют ширину "по умолчанию", которая обычно составляет 960px. В браузерах, открывающихся по умолчанию в полноэкранном режиме, например, в браузере телефона, установка тега <code><meta name="viewport" content="width=device-width"></code> установит ширину видимой области в 100% от ширины экрана устройства, вместо того, чтобы использовать ширину по умолчанию. Эта ширина (<code>device-width)</code> изменяется каждый раз, когда пользователь поворачивает телефон. Это приводит к запуску этапа компоновки. Равно как и при изменении размеров окна в обычном браузере.</p> -<p>На производительность компоновки (layout) непосредственно влияет DOM - чем больше узлов (nodes) в вашем документе, тем больше времени понадобится на перерасчет позиций и размеров всех элементов. Компоновка может стать узким местом, ведущим к зависаниям, особенно если выполняет одновременно со скроллом или другой анимацией. И хотя задержка 20мс при загрузке или переориентации экрана может быть приемлемой, это все равно может привести к подвисаниям при анимации и скролле. Каждый раз, когда дерево рендера (render tree) модифицируется, например, из-за добавления узла (node), его модификации или при изменении стилей box-модели, запускается компоновка.</p> +<p>На производительность компоновки (layout) непосредственно влияет DOM - чем больше узлов (nodes) в вашем документе, тем больше времени понадобится на перерасчёт позиций и размеров всех элементов. Компоновка может стать узким местом, ведущим к зависаниям, особенно если выполняет одновременно со скроллом или другой анимацией. И хотя задержка 20мс при загрузке или переориентации экрана может быть приемлемой, это все равно может привести к подвисаниям при анимации и скролле. Каждый раз, когда дерево рендера (render tree) модифицируется, например, из-за добавления узла (node), его модификации или при изменении стилей box-модели, запускается компоновка.</p> <p>Для уменьшения частоты и продолжительности этого этапа, группируйте обновления экрана и избегайте анимации свойств, связанных с box-моделью элементов.</p> <h3 id="Отрисовка_Paint">Отрисовка (Paint)</h3> -<p>Последний этап в нашем списке - отрисовка (paint) пикселей на экране. Когда дерево рендера (render tree) создано, компоновка (layout) произошла, пиксели могут быть отрисованы. При первичной загрузке документа (onload) весь экран будет отрисован. После этого только необходимые к обновлению части экрана будут перерисовываться, так как браузер старается оптимизировать процесс отрисовки, избегая ненужной работы. Так, если у вас в документе есть два элемента, перерисовываться будет только тот, который вы изменили. Время отрисовки зависит от того, какой тип обновления применился к дереву рендера (render tree). И хотя отрисовка - это очень быстрый процесс, и он, вероятно, слабо влияет на производительность, очень важно помнить, что оба этапа - компоновка (layout) и отрисовка (paint) должны работать сообща и укладываться в частоту обновления кадров. Каждое CSS-свойство, применяемое к любому узлу (node) увеличивает время отрисовки, но полное удаление стиля, способное сэкономить вам 0.001мс, вряд ли даст вам желаемый результат, но зато с легкостью ухудшит пользовательский опыт. <strong>Помните - сначала нужно измерять, а потом оптимизировать только необходимое!</strong></p> +<p>Последний этап в нашем списке - отрисовка (paint) пикселей на экране. Когда дерево рендера (render tree) создано, компоновка (layout) произошла, пиксели могут быть отрисованы. При первичной загрузке документа (onload) весь экран будет отрисован. После этого только необходимые к обновлению части экрана будут перерисовываться, так как браузер старается оптимизировать процесс отрисовки, избегая ненужной работы. Так, если у вас в документе есть два элемента, перерисовываться будет только тот, который вы изменили. Время отрисовки зависит от того, какой тип обновления применился к дереву рендера (render tree). И хотя отрисовка - это очень быстрый процесс, и он, вероятно, слабо влияет на производительность, очень важно помнить, что оба этапа - компоновка (layout) и отрисовка (paint) должны работать сообща и укладываться в частоту обновления кадров. Каждое CSS-свойство, применяемое к любому узлу (node) увеличивает время отрисовки, но полное удаление стиля, способное сэкономить вам 0.001мс, вряд ли даст вам желаемый результат, но зато с лёгкостью ухудшит пользовательский опыт. <strong>Помните - сначала нужно измерять, а потом оптимизировать только необходимое!</strong></p> <h2 id="Оптимизация_CRP">Оптимизация CRP</h2> diff --git a/files/ru/web/performance/css_javascript_animation_performance/index.html b/files/ru/web/performance/css_javascript_animation_performance/index.html index b6dbb2bedf..8996f5f957 100644 --- a/files/ru/web/performance/css_javascript_animation_performance/index.html +++ b/files/ru/web/performance/css_javascript_animation_performance/index.html @@ -25,7 +25,7 @@ translation_of: Web/Performance/CSS_JavaScript_animation_performance <h2 id="requestAnimationFrame">requestAnimationFrame</h2> -<p>API {{domxref("Window.requestAnimationFrame","requestAnimationFrame()")}} предоставляет эффективный способ создания анимаций в JavaScript. Функция (callback), которую вы передаете в этот метод, будет вызываться перед каждой следующей отрисовкой нового фрейма. Главное отличие от {{domxref("WindowTimers.setTimeout","setTimeout()")}}/{{domxref("WindowTimers.setInterval","setInterval()")}} в том, что здесь вам не нужно указывать время, через которое функция запустится. <code>requestAnimationFrame()</code> работает гораздо эффективнее, учитывая частоту кадров и производительность системы. Разработчики могут создавать анимацию, просто изменяя стили элемента каждый раз, когда происходит подготовка нового кадра (или когда обновляется полотно Canvas или в других случаях).</p> +<p>API {{domxref("Window.requestAnimationFrame","requestAnimationFrame()")}} предоставляет эффективный способ создания анимаций в JavaScript. Функция (callback), которую вы передаёте в этот метод, будет вызываться перед каждой следующей отрисовкой нового фрейма. Главное отличие от {{domxref("WindowTimers.setTimeout","setTimeout()")}}/{{domxref("WindowTimers.setInterval","setInterval()")}} в том, что здесь вам не нужно указывать время, через которое функция запустится. <code>requestAnimationFrame()</code> работает гораздо эффективнее, учитывая частоту кадров и производительность системы. Разработчики могут создавать анимацию, просто изменяя стили элемента каждый раз, когда происходит подготовка нового кадра (или когда обновляется полотно Canvas или в других случаях).</p> <div class="note"> <p><strong>Заметка</strong>: Подобно CSS transition и animation, <code>requestAnimationFrame()</code> приостанавливает работу, когда текущий таб переводится в фоновый режим (например, при смене фокуса)</p> @@ -38,7 +38,7 @@ translation_of: Web/Performance/CSS_JavaScript_animation_performance <p>По факту, в большинстве случаев, производительность анимаций CSS практически идентична анимациям на JavaScript. По крайней мере в Firefox. Авторы некоторых JavaScript библиотек для анимации, например GSAP или Velocity.JS, даже берутся утверждать, что их решения могут работать быстрее, чем аналогичные решения на CSS. Такое возможно, потому что CSS transitions/animations просто заново вычисляют стили элементов в основном потоке процессора сразу перед тем, как срабатывает событие repaint, что примерно то же самое, что вычислять стили заново с помощью <code>requestAnimationFrame()</code>. Если обе анимации выполняются в одном потоке, то разницы в производительности не будет.</p> -<p>В следующей секции мы пройдемся по тестам производительности, используя Firefox, чтобы увидеть, какие методы анимации работают эффективнее.</p> +<p>В следующей секции мы пройдёмся по тестам производительности, используя Firefox, чтобы увидеть, какие методы анимации работают эффективнее.</p> <h3 id="Включение_измерения_частоты_кадров_FPS">Включение измерения частоты кадров FPS</h3> diff --git a/files/ru/web/performance/dns-prefetch/index.html b/files/ru/web/performance/dns-prefetch/index.html index d6575dcf2a..2db1d62980 100644 --- a/files/ru/web/performance/dns-prefetch/index.html +++ b/files/ru/web/performance/dns-prefetch/index.html @@ -13,7 +13,7 @@ translation_of: Web/Performance/dns-prefetch <p>Бывают случаи, когда в вашем приложении используются ссылки на домены, отличные от основного домена приложения. Например, внутри вашего приложения на "a.com" есть ссылка на домен "b.org". Для того, чтобы пройти по этой ссылке, пользовательский клиент должен сначала выяснить, какой адрес в интернете соответствует доменному имени "b.org". Этот процесс называется <code>DNS resolution.</code> И хотя механизмы кеширования DNS помогают сократить время запросов, DNS Resolution заметно влияет на время ожидания запроса из-за того, что первый клиентский запрос уходит сначала на DNS сервера и дожидается ответа от них. Для приложений, которые открывают соединения ко многим сторонним доменам, влияние DNS Resolution может сильно уменьшить производительность загрузки.</p> -<p><code>dns-prefetch</code> помогает разработчикам замаскировать ожидание DNS resolution. <a href="/en-US/docs/Web/HTML/Element/link">HTML <code><link></code> элемент</a> предлагает подобный функционал с помощью атрибута <a href="/en-US/docs/Web/HTML/Attributes/rel"><code>rel</code></a>, значение которого может содержать <code>dns-prefetch</code>. В этом случае, предзагрузка DNS произойдет для домена, указанного в атрибуте <a href="/en-US/docs/Web/HTML/Attributes">href</a>:</p> +<p><code>dns-prefetch</code> помогает разработчикам замаскировать ожидание DNS resolution. <a href="/en-US/docs/Web/HTML/Element/link">HTML <code><link></code> элемент</a> предлагает подобный функционал с помощью атрибута <a href="/en-US/docs/Web/HTML/Attributes/rel"><code>rel</code></a>, значение которого может содержать <code>dns-prefetch</code>. В этом случае, предзагрузка DNS произойдёт для домена, указанного в атрибуте <a href="/en-US/docs/Web/HTML/Attributes">href</a>:</p> <h2 id="Синтаксис">Синтаксис</h2> @@ -44,7 +44,7 @@ translation_of: Web/Performance/dns-prefetch <pre class="brush: unix notranslate">Link: <https://fonts.gstatic.com/>; rel=dns-prefetch</pre> -<p><strong>В третьих, </strong> хорошей практикой считается использование <code>dns-prefetch</code> в паре с <code>preconnect</code>. В то время, как <code>dns-prefetch</code> срабатывает только при DNS поиске, <code>preconnect</code> устанавливает соединение к нужному серверу. Этот процесс включает в себя DNS resolution, установку TCP соединения и установление безопасного соединения (<a href="/en-US/docs/Glossary/TLS">TLS</a> рукопожатие), если оно доступно. Комбинирование этих двух инструкций дает возможность ещё больше сократить время ожидания для кросс-доменных запросов. Вы можете использовать их вместе таким образом:</p> +<p><strong>В третьих, </strong> хорошей практикой считается использование <code>dns-prefetch</code> в паре с <code>preconnect</code>. В то время, как <code>dns-prefetch</code> срабатывает только при DNS поиске, <code>preconnect</code> устанавливает соединение к нужному серверу. Этот процесс включает в себя DNS resolution, установку TCP соединения и установление безопасного соединения (<a href="/en-US/docs/Glossary/TLS">TLS</a> рукопожатие), если оно доступно. Комбинирование этих двух инструкций даёт возможность ещё больше сократить время ожидания для кросс-доменных запросов. Вы можете использовать их вместе таким образом:</p> <pre class="brush: html notranslate"><link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin> <link rel="dns-prefetch" href="https://fonts.gstatic.com/"> diff --git a/files/ru/web/performance/fundamentals/index.html b/files/ru/web/performance/fundamentals/index.html index b7e7d891c0..704ebee8a2 100644 --- a/files/ru/web/performance/fundamentals/index.html +++ b/files/ru/web/performance/fundamentals/index.html @@ -19,7 +19,7 @@ original_slug: Web/Performance/Основы <p>Ощущаемая пользователем "производительность" - это единственная производительность, которая имеет значение. Пользователи взаимодействуют с системой с помощью ввода каких-то данных: прикосновений, движения и речи. В ответ, они получают реакцию, основанную на зрительном, тактильном или слуховом аппаратах. Производительность - это качество того, как система реагирует на действия пользователя.</p> -<p>При прочих равных, код, оптимизированный для каких-то иных целей, кроме ощущаемой пользователем производительности (здесь и дальше UPP, user-perceived performance) всегда проигрывает коду, который оптимизирован для UPP. Упрощенно говоря, пользователи предпочитают отзывчивое и плавное приложение, которое обрабатывает 1,000 транзакций к базе данных в секунду грубому неотзывчивому приложению, которое обрабатывает 100,000,000 запросов в секунду. Конечно, это не означает, что другие метрики становятся ненужным, но первой вашей целью должна быть UPP.</p> +<p>При прочих равных, код, оптимизированный для каких-то иных целей, кроме ощущаемой пользователем производительности (здесь и дальше UPP, user-perceived performance) всегда проигрывает коду, который оптимизирован для UPP. Упрощённо говоря, пользователи предпочитают отзывчивое и плавное приложение, которое обрабатывает 1,000 транзакций к базе данных в секунду грубому неотзывчивому приложению, которое обрабатывает 100,000,000 запросов в секунду. Конечно, это не означает, что другие метрики становятся ненужным, но первой вашей целью должна быть UPP.</p> <p>Следующие разделы укажут и объяснят некоторые метрики производительности:</p> @@ -55,7 +55,7 @@ original_slug: Web/Performance/Основы <p>Последний показатель, который нужно упомянуть - это потребление энергии. Подобно использованию памяти, пользователь чувствует потребление памяти опосредованно, отмечая время, через которое устройство начинает изменять воспринимаемую пользователем производительность (UPP). Для минимизации отрицательных эффектов использования энергии, мы должны делать систему экономной.</p> -<p>Для примера, вспомните, как работают мобильные устройства: вы можете включить режим энергосбережения, когда отключаются другие системы. Но есть и более жесткий режим, который включается автоматически, когда заряд уменьшается до 5% - система включает троттлинг процессора, замедляя выполнение всех инструкций.</p> +<p>Для примера, вспомните, как работают мобильные устройства: вы можете включить режим энергосбережения, когда отключаются другие системы. Но есть и более жёсткий режим, который включается автоматически, когда заряд уменьшается до 5% - система включает троттлинг процессора, замедляя выполнение всех инструкций.</p> <p>Всю оставшуюся часть статьи мы будем обсуждать производительность в свете этих показателей.</p> @@ -72,7 +72,7 @@ original_slug: Web/Performance/Основы <p>Элемент Холст (<code>canvas</code>) предоставляет прямой доступ к пиксельному буферу, где разработчик может рисовать.Это даёт разработчику возможность контролировать каждый пиксель во время рендеринга, точно контролировать частоту кадров; но тогда разработчик должен иметь в виду работу с большим количеством разрешений экранов и ориентаций; RTL языками и т.д. Разработчики, работающие напрямую с холстами, используют либо знакомое 2D API, либо API WebGL, достаточно "близкий к железу" и по большей части придерживающийся OpenGL ES 2.0.</p> <div class="note"> -<p><strong>Заметка: </strong>Firefox OS оптимизирована для работы с приложениями, основанными на Web технологиях: <a href="/en-US/docs/Web/HTML">HTML</a>, <a href="/en-US/docs/Web/CSS">CSS</a>, <a href="/en-US/docs/Web/JavaScript">JavaScript</a> и т.д. За исключением некоторых базовых служб операционной системы, весь код Firefox OS пришел из Web приложений и движка Gecko. Даже оконный менеджер операционной системы написан на HTML, CSS и JavaScript. В связи с тем, что ядро операционной системы написано на этих технологиях, было критически важно соблюсти производительность этих технологий. В Firefox OS не может быть какого-то "запасного выхода". И это очень полезно для разработчиков, потому что теперь сторонние приложения могут использовать все преимущества оптимизации операционной системы. Не существует какого-то "магического зелья производительности", доступного только для предустановленных приложений.</p> +<p><strong>Заметка: </strong>Firefox OS оптимизирована для работы с приложениями, основанными на Web технологиях: <a href="/en-US/docs/Web/HTML">HTML</a>, <a href="/en-US/docs/Web/CSS">CSS</a>, <a href="/en-US/docs/Web/JavaScript">JavaScript</a> и т.д. За исключением некоторых базовых служб операционной системы, весь код Firefox OS пришёл из Web приложений и движка Gecko. Даже оконный менеджер операционной системы написан на HTML, CSS и JavaScript. В связи с тем, что ядро операционной системы написано на этих технологиях, было критически важно соблюсти производительность этих технологий. В Firefox OS не может быть какого-то "запасного выхода". И это очень полезно для разработчиков, потому что теперь сторонние приложения могут использовать все преимущества оптимизации операционной системы. Не существует какого-то "магического зелья производительности", доступного только для предустановленных приложений.</p> <p>См. <a href="/en-US/docs/Archive/B2G_OS/Firefox_OS_apps/Performance/Firefox_OS_performance_testing">Тестирование производительности Firefox OS</a> для подробностей.</p> </div> @@ -81,7 +81,7 @@ original_slug: Web/Performance/Основы <p>Движок Gecko JavaScript поддерживает just-in-time (JIT) компиляцию. Благодаря этому, логика приложения выполняется примерно так же, как это происходит в других приложениях на виртуальных машинах - например, Java Virtual Machines - а в некоторых случаях эффективность этих приложений близка к "нативному коду".</p> -<p>Инструменты, необходимые для работы с HTML, CSS и Canvas оптимизированы несколькими путями. Например, композиция (этап, известный как Layout) в HTML/CSS и код, отвечающий за графику в Gecko, сделаны таким образом, чтобы уменьшить количество операций ревалидации и перерисовки для общих случаев (например, скроллинг); эти оптимизации включены "по умолчанию", поэтому разработчики пользуются ими бесплатно. Буферы пикселей, отрисованных как для Gecko "автоматически", так и для <code>canvas</code> "вручную", минимизируют количество копий, которые передаются в буфер кадров дисплея. Чтобы достичь этого, Gecko старается избегать создания промежуточных слоев (например, во многих других операционных системах создаются пиксельные фоновые буферы для каждого отдельного приложения), но взамен Gecko использует специальные участки памяти для хранения графических буферов. К этой памяти имеет прямой доступ железо, которое ответственно за формирование картинки. Сложные сцены рендерятся с использованием графического адаптера (видеокарты). А простые сцены, для экономии энергии, рендерятся специальным выделенным железом для композиции, в то время, как графический адаптер находится в режиме ожидания или выключен.</p> +<p>Инструменты, необходимые для работы с HTML, CSS и Canvas оптимизированы несколькими путями. Например, композиция (этап, известный как Layout) в HTML/CSS и код, отвечающий за графику в Gecko, сделаны таким образом, чтобы уменьшить количество операций ревалидации и перерисовки для общих случаев (например, скроллинг); эти оптимизации включены "по умолчанию", поэтому разработчики пользуются ими бесплатно. Буферы пикселей, отрисованных как для Gecko "автоматически", так и для <code>canvas</code> "вручную", минимизируют количество копий, которые передаются в буфер кадров дисплея. Чтобы достичь этого, Gecko старается избегать создания промежуточных слоёв (например, во многих других операционных системах создаются пиксельные фоновые буферы для каждого отдельного приложения), но взамен Gecko использует специальные участки памяти для хранения графических буферов. К этой памяти имеет прямой доступ железо, которое ответственно за формирование картинки. Сложные сцены рендерятся с использованием графического адаптера (видеокарты). А простые сцены, для экономии энергии, рендерятся специальным выделенным железом для композиции, в то время, как графический адаптер находится в режиме ожидания или выключен.</p> <p>Для продвинутых приложений полностью статичный контент скорее является исключением, чем правилом. Такие приложения используют динамический контент, анимируемый с помощью {{ cssxref("animation") }} и {{ cssxref ("transition") }}. Переходы и анимации особенно важны для приложений: разработчики могут использовать CSS для объявления сложного поведения с помощью простого высокоуровнего синтаксиса. С другой стороны, движок Gecko хорошо оптимизирован для того, чтобы рендерить такую анимацию эффективно. В целом, общепринятые анимации передаются к обработке системному компоновщику, который может отрендерить их в эффективном, энергосберегающем режиме. </p> @@ -123,7 +123,7 @@ original_slug: Web/Performance/Основы <p>Web-платформа очень динамична. JavaScript - это динамически типизированный язык, а Web разрешает загружать код, HTML, CSS, изображения и другие ресурсы динамически. Эти функции могут быть использованы для того, чтобы отложить загрузку ресурсов; чтобы сократить критический путь, подвинув загрузку лишнего контента на несколько моментов позже. Такой подход называется "ленивой загрузкой".</p> -<p>Другая проблема, которая может привести к ненужному простою - это ожидание ответа на запросы (например, запрос к базе данных). Чтобы избегать этой проблемы, приложение должно запрашивать данные как можно раньше, еще во время запуска программы. Тогда к моменту, когда данные понадобятся - они уже будут в системе и приложению не придется ждать.</p> +<p>Другая проблема, которая может привести к ненужному простою - это ожидание ответа на запросы (например, запрос к базе данных). Чтобы избегать этой проблемы, приложение должно запрашивать данные как можно раньше, ещё во время запуска программы. Тогда к моменту, когда данные понадобятся - они уже будут в системе и приложению не придётся ждать.</p> <div class="note"> <p><strong>Заметка: </strong>Для дополнительной информации об ускорении запуска ознакомьтесь с <a href="/en-US/Apps/Developing/Performance/Optimizing_startup_performance">Optimizing startup performance</a>.</p> @@ -133,7 +133,7 @@ original_slug: Web/Performance/Основы <h3 id="Частота_кадров_2">Частота кадров</h3> -<p>Первая важная вещь для высокой частоты кадров - это выбор правильного инструмента. Используйте HTML и CSS для создания контента, который будет в основном статическим, прокручиваемым и редко анимируемым. Используйте Canvas для создания высокодинамичного контента, например, игр, которые требуют серьезного контроля рендеринга и не нуждаются в темах.</p> +<p>Первая важная вещь для высокой частоты кадров - это выбор правильного инструмента. Используйте HTML и CSS для создания контента, который будет в основном статическим, прокручиваемым и редко анимируемым. Используйте Canvas для создания высокодинамичного контента, например, игр, которые требуют серьёзного контроля рендеринга и не нуждаются в темах.</p> <p>При отрисовывании контента в Canvas, разработчик должен сам позаботиться о достижении целей по частоте кадров, ведь он получает полный контроль над всем, что отрисовывается.</p> @@ -168,7 +168,7 @@ original_slug: Web/Performance/Основы <p>Вместо использования функции <code>animate()</code> какой-нибудь библиотеки, которая, вероятно, использует много плохих решений (например ({{domxref("window.setTimeout()")}} или анимирование top / left), используйте <a href="/en-US/docs/Web/Guide/CSS/Using_CSS_animations">CSS анимации</a>. Во многих случаях, вы можете использовать <a href="/en-US/docs/Web/Guide/CSS/Using_CSS_transitions">CSS Transitions</a>. Использование этих свойств поможет, так как браузер спроектирован так, чтобы оптимизировать эти эффекты и переносить часть вычислений на GPU, чтобы они работали плавно и с минимальным влиянием на процессор. Другое преимущество - вы можете определить эти анимации в CSS декларативным образом, а не в бизнес-логике приложения.</p> -<p>CSS анимации дают вам очень точный контроль эффектов, если вы используете <a href="/en-US/docs/Web/CSS/@keyframes">keyframes</a>. Более того, вы сможете отслеживать события, которые происходят во время анимации, так как основной поток обработки не блокируется. Вы можете с легкостью запускать анимации с помощью {{cssxref(":hover")}}, {{cssxref(":focus")}} или {{cssxref(":target")}}. Или динамически добавляя или удаляя классы элемента.</p> +<p>CSS анимации дают вам очень точный контроль эффектов, если вы используете <a href="/en-US/docs/Web/CSS/@keyframes">keyframes</a>. Более того, вы сможете отслеживать события, которые происходят во время анимации, так как основной поток обработки не блокируется. Вы можете с лёгкостью запускать анимации с помощью {{cssxref(":hover")}}, {{cssxref(":focus")}} или {{cssxref(":target")}}. Или динамически добавляя или удаляя классы элемента.</p> <p>Если вы хотите создавать анимации "на лету" или изменять их с помощью JavaScript, Джеймс Лонг написал простую библиотеку для этого - <a href="https://github.com/jlongster/css-animations.js/">CSS-animations.js</a>.</p> @@ -176,7 +176,7 @@ original_slug: Web/Performance/Основы <p>Вместо того, чтобы изменять абсолютное позиционирование и возиться с этой математикой вручную, используйте свойство {{cssxref("transform")}}, чтобы изменить позицию, масштаб и некоторые другие аспекты вашего контента. Именно так вы используете аппаратное ускорение. Браузер умеет передавать такие задачи графическому процессору, давая возможность ЦПУ заняться другими важными вещами.</p> -<p>К тому же, трансформация даёт возможности, которых в ином случае у вас не было бы. Вы не только можете манипулировать элементом в двумерном пространстве, но можете трансформировать его в 3D, изменять его наклон (скашивать, skew), поворачивать и др. Пол Айриш опубликовал статью <a href="https://paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/">in-depth analysis of the benefits of <code>translate()</code></a>, в которой проанализировал работу translate с точки зрения производительности. Используя translate/transform вы используете правильный декларативный инструмент и возлагаете ответственность за его оптимизацию на браузер. Вы так же получаете возможность с легкостью позиционировать элементы. Если вы будете использовать только <code>top</code> и <code>left</code>, вам придется написать некоторый дополнительный код, чтобы предусмотреть некоторые особенности такого позиционирования. И последний бонус - с Transform / Translate вы будете работать примерно так же, как работали бы с элементом <code>canvas</code>.</p> +<p>К тому же, трансформация даёт возможности, которых в ином случае у вас не было бы. Вы не только можете манипулировать элементом в двумерном пространстве, но можете трансформировать его в 3D, изменять его наклон (скашивать, skew), поворачивать и др. Пол Айриш опубликовал статью <a href="https://paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/">in-depth analysis of the benefits of <code>translate()</code></a>, в которой проанализировал работу translate с точки зрения производительности. Используя translate/transform вы используете правильный декларативный инструмент и возлагаете ответственность за его оптимизацию на браузер. Вы так же получаете возможность с лёгкостью позиционировать элементы. Если вы будете использовать только <code>top</code> и <code>left</code>, вам придётся написать некоторый дополнительный код, чтобы предусмотреть некоторые особенности такого позиционирования. И последний бонус - с Transform / Translate вы будете работать примерно так же, как работали бы с элементом <code>canvas</code>.</p> <div class="note"> <p><strong>Заметка:</strong> В некоторых случаях (в зависимости от платформы) вам может понадобиться добавить свойство <code>translateZ(0.1)</code>, если вы хотите заставить клиента перенести вычисление анимаций на графический адаптер. Как было упомянуто выше, это может улучшить производительность, но увеличит потребление памяти. Какое из зол - меньшее - решать вам. Протестируйте оба варианта и выясните, что лучше подходит для вашего приложения.</p> @@ -184,9 +184,9 @@ original_slug: Web/Performance/Основы <h4 id="Используйте_requestAnimationFrame_вместо_setInterval">Используйте <code>requestAnimationFrame()</code> вместо <code>setInterval()</code></h4> -<p>Вызовы {{domxref("window.setInterval()")}} запускают код с учётом предполагаемой частоты кадров. Однако, эта ожидаемая частота и фактическая не всегда совпадают. SetInternal говорит браузеру "нарисуй результаты", даже если браузер не занимается сейчас отрисовкой - такое случается, когда графический адаптер ещё не дошел до следующего цикла обновления экрана. Такое несовпадение таймингов - чрезмерная растрата процессорного времени и даже может приводить к снижению срока службы аккумуляторов пользовательского устройств.</p> +<p>Вызовы {{domxref("window.setInterval()")}} запускают код с учётом предполагаемой частоты кадров. Однако, эта ожидаемая частота и фактическая не всегда совпадают. SetInternal говорит браузеру "нарисуй результаты", даже если браузер не занимается сейчас отрисовкой - такое случается, когда графический адаптер ещё не дошёл до следующего цикла обновления экрана. Такое несовпадение таймингов - чрезмерная растрата процессорного времени и даже может приводить к снижению срока службы аккумуляторов пользовательского устройств.</p> -<p>Вместо этого, вам необходимо использовать {{domxref("window.requestAnimationFrame()")}}. Эта функция ждет, пока клиент не будет готов к формированию следующего кадра анимации и не будет досаждать своими запросами аппаратную часть устройства, если устройство не занимается в данный момент рендерингом. Другое преимущество этого API в том, что такие анимации не будут запускаться, пока ваше приложение не видно на экране (например, если оно выполняется в фоне или занимается другими операциями). Это сохранит батарею и защитит вас от проклятий, которые пользователи будут выкрикивать в небо.</p> +<p>Вместо этого, вам необходимо использовать {{domxref("window.requestAnimationFrame()")}}. Эта функция ждёт, пока клиент не будет готов к формированию следующего кадра анимации и не будет досаждать своими запросами аппаратную часть устройства, если устройство не занимается в данный момент рендерингом. Другое преимущество этого API в том, что такие анимации не будут запускаться, пока ваше приложение не видно на экране (например, если оно выполняется в фоне или занимается другими операциями). Это сохранит батарею и защитит вас от проклятий, которые пользователи будут выкрикивать в небо.</p> <h4 id="Делайте_события_мгновенными">Делайте события мгновенными</h4> @@ -200,7 +200,7 @@ original_slug: Web/Performance/Основы <h2 id="Общий_анализ_производительности">Общий анализ производительности</h2> -<p>Firefox, Chrome и другие браузеры предоставляют встроенные инструменты, которые могут помочь вам диагностировать медленный рендеринг. В частности, <a href="/en-US/docs/Tools/Network_Monitor">Firefox's Network Monitor</a> покажет точное время, когда произошел каждый сетевой запрос, насколько большим он был и как долго обрабатывался.</p> +<p>Firefox, Chrome и другие браузеры предоставляют встроенные инструменты, которые могут помочь вам диагностировать медленный рендеринг. В частности, <a href="/en-US/docs/Tools/Network_Monitor">Firefox's Network Monitor</a> покажет точное время, когда произошёл каждый сетевой запрос, насколько большим он был и как долго обрабатывался.</p> <p><img alt="The Firefox network monitor showing get requests, multiple files, and different times taken to load each resource on a graph." src="https://mdn.mozillademos.org/files/6845/network-monitor.jpg" style="display: block; height: 713px; margin: 0px auto; width: 700px;"></p> @@ -222,4 +222,4 @@ original_slug: Web/Performance/Основы <p>Если инструменты разработчика в Firefox или Chrome не помогают вам выяснить проблему или выглядит так, что браузеры сами по себе создают проблему, попробуйте сформировать тестовое окружение, которое максимально изолирует проблему. Это очень часто помогать диагностировать проблему.</p> -<p>Убедитесь, что вы можете воспроизвести проблему, просто сохраняя и загружая статическую копию HTML-страницы (включая изображения/стили/скрипты). Если так - удалите из HTML файла всю личную информацию и обратитесь к за помощью (отправьте отчет в <a href="https://bugzilla.mozilla.org/">Bugzilla</a> или, например, сохраните файл на своем сервере и поделитесь ссылкой). Вам также понадобится поделиться информацией профилировщика, которую вы собрали с помощью инструментов отладки.</p> +<p>Убедитесь, что вы можете воспроизвести проблему, просто сохраняя и загружая статическую копию HTML-страницы (включая изображения/стили/скрипты). Если так - удалите из HTML файла всю личную информацию и обратитесь к за помощью (отправьте отчёт в <a href="https://bugzilla.mozilla.org/">Bugzilla</a> или, например, сохраните файл на своём сервере и поделитесь ссылкой). Вам также понадобится поделиться информацией профилировщика, которую вы собрали с помощью инструментов отладки.</p> 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> diff --git a/files/ru/web/performance/how_long_is_too_long/index.html b/files/ru/web/performance/how_long_is_too_long/index.html index 37a17d18e9..e53c2f96a4 100644 --- a/files/ru/web/performance/how_long_is_too_long/index.html +++ b/files/ru/web/performance/how_long_is_too_long/index.html @@ -13,7 +13,7 @@ translation_of: Web/Performance/How_long_is_too_long <h3 id="Загрузка_контента">Загрузка контента</h3> -<p>Понятие "до секунды" часто считается оптимальным для загрузки. Но что это означает? Правило секунды должно рассматриваться как правило максимального времени, за которое пользователь поймет, что запрос был отправлен и будет загружен. Например, когда браузер принимает заголовок страницы или фоновый цвет и показывает её пользователю.</p> +<p>Понятие "до секунды" часто считается оптимальным для загрузки. Но что это означает? Правило секунды должно рассматриваться как правило максимального времени, за которое пользователь поймёт, что запрос был отправлен и будет загружен. Например, когда браузер принимает заголовок страницы или фоновый цвет и показывает её пользователю.</p> <p>Как правило, первый ресурс, который получает клиент - это HTML документ, который затем делает запрос на загрузку остальных ресурсов. Как было подмечено в <a href="/ru/docs/Web/Performance/Critical_rendering_path">статье о критическом пути рендеринга</a> - как только браузер получает данные, он сразу начинает их обработку, вместо того, чтобы дожидаться загрузки всех ресурсов.</p> @@ -27,7 +27,7 @@ translation_of: Web/Performance/How_long_is_too_long <h3 id="Анимация">Анимация</h3> -<p>Для того, чтобы прокрутка и другие анимации выглядели плавно, контент страницы должен обновляться с частотой 60 кадров в секунду (60 fps), то есть один кадр раз в 16.7мс. В эти 16.7мс. должны входить выполнение скриптов, компоновка и отрисовка. Делайте приложение таким, чтобы приложение могло использовать 6мс на отрисовку контента, а в остальные 10мс могло заниматься оставшимися вычислениями. Любая другая частота кадров, особенно если она отрывистая и непостоянная, создает впечатление зависающего приложения.</p> +<p>Для того, чтобы прокрутка и другие анимации выглядели плавно, контент страницы должен обновляться с частотой 60 кадров в секунду (60 fps), то есть один кадр раз в 16.7мс. В эти 16.7мс. должны входить выполнение скриптов, компоновка и отрисовка. Делайте приложение таким, чтобы приложение могло использовать 6мс на отрисовку контента, а в остальные 10мс могло заниматься оставшимися вычислениями. Любая другая частота кадров, особенно если она отрывистая и непостоянная, создаёт впечатление зависающего приложения.</p> <h3 id="Отзывчивость">Отзывчивость</h3> diff --git a/files/ru/web/performance/index.html b/files/ru/web/performance/index.html index 82f34d4d7a..5eb18aa302 100644 --- a/files/ru/web/performance/index.html +++ b/files/ru/web/performance/index.html @@ -19,9 +19,9 @@ tags: - Web Performance translation_of: Web/Performance --- -<p>Производительность в web - это объективные измерения и пользовательские ощущения, связанные с загрузкой и работой приложения. Производительность - это о том, как долго сайт грузится, становится интерактивным и отзывчивым, о том, как плавно происходит взаимодействие с контентом. Плавный ли скролл страницы? Все ли кнопки кликабельны? Всплывающие окна загружаются и показываются быстро? А анимируются? Хорошая производительность требует учета всех аспектов: как объективных, например, фактическое время загрузки страницы или частота смены кадров; так и субъективных - в буквальном смысле "как пользователь воспринимает систему".</p> +<p>Производительность в web - это объективные измерения и пользовательские ощущения, связанные с загрузкой и работой приложения. Производительность - это о том, как долго сайт грузится, становится интерактивным и отзывчивым, о том, как плавно происходит взаимодействие с контентом. Плавный ли скролл страницы? Все ли кнопки кликабельны? Всплывающие окна загружаются и показываются быстро? А анимируются? Хорошая производительность требует учёта всех аспектов: как объективных, например, фактическое время загрузки страницы или частота смены кадров; так и субъективных - в буквальном смысле "как пользователь воспринимает систему".</p> -<p>Чем дольше загружается ваше приложение, тем больше пользователей решаются избавиться от него. Очень важно уменьшать время загрузки приложения, а так же промежутка времени, за которое оно становится интерактивным. Но в то же время, важно добавлять в приложение новые возможности, которые уменьшают время отклика и делают приложение интерактивным за счет неочевидных хитростей, например, за счет асинхронной загрузки данных, которые не понадобятся пользователю "здесь и сейчас". </p> +<p>Чем дольше загружается ваше приложение, тем больше пользователей решаются избавиться от него. Очень важно уменьшать время загрузки приложения, а так же промежутка времени, за которое оно становится интерактивным. Но в то же время, важно добавлять в приложение новые возможности, которые уменьшают время отклика и делают приложение интерактивным за счёт неочевидных хитростей, например, за счёт асинхронной загрузки данных, которые не понадобятся пользователю "здесь и сейчас". </p> <p>Существуют инструменты измерения производительности, API и лучшие практики, которые помогут нам измерять и улучшать производительность. Мы постараемся раскрыть их в следующей секции:</p> diff --git a/files/ru/web/performance/navigation_and_resource_timings/index.html b/files/ru/web/performance/navigation_and_resource_timings/index.html index 2fc612aca0..3dbae7164f 100644 --- a/files/ru/web/performance/navigation_and_resource_timings/index.html +++ b/files/ru/web/performance/navigation_and_resource_timings/index.html @@ -76,12 +76,12 @@ translation_of: Web/Performance/Navigation_and_resource_timings <tr> <td>{{domxref("PerformanceTiming.domainLookupEnd","domainLookupEnd")}}</td> <td> - <p>Поиск домена завершён. Если используется постоянное соединение, или используются данные, сохраненные в локальном кэше, то значение показателя будет таким же, как и <code>PerformanceTiming.fetchStart</code>.</p> + <p>Поиск домена завершён. Если используется постоянное соединение, или используются данные, сохранённые в локальном кэше, то значение показателя будет таким же, как и <code>PerformanceTiming.fetchStart</code>.</p> </td> </tr> <tr> <td>{{domxref("PerformanceTiming.domainLookupStart","domainLookupStart")}}</td> - <td>Начался поиск домена. Если используется постоянное соединение, или используются данные, сохраненные в локальном кэше, то значение показателя будет таким же, как и <code>PerformanceTiming.fetchStart</code>.</td> + <td>Начался поиск домена. Если используется постоянное соединение, или используются данные, сохранённые в локальном кэше, то значение показателя будет таким же, как и <code>PerformanceTiming.fetchStart</code>.</td> </tr> <tr> <td>{{domxref("PerformanceTiming.fetchStart","fetchStart")}}</td> @@ -236,7 +236,7 @@ performance.getEntriesByType('frame').forEach((frame) => { <h2 id="Navigation">Navigation</h2> -<p>Когда пользователь запрашивает веб-приложение,<a href="/en-US/docs/Learn/Performance/Populating_the_page:_how_browsers_work"> браузер должен получить некоторые мета-данные</a>, чтобы начать загрузку. Для этого пользовательский агент проходит серию шагов, такие как поиск записи DNS ({{glossary('DNS')}} lookup), TCP рукопожатие {{glossary('TCP handshake')}}, и установку безопасного соединения (SSL negotiation). Как только браузер установил соединение, происходит первый полезный запрос данных на сервера. Как только начинают поступать данные от сервера, браузер начинает парсить полученные данные, строит DOM, CSSOM, создает деревья рендера (render trees), чтобы в конце концов отрендерить страницу. В тот момент, когда браузер перестает парсить входящие данные, документ переходит в интерактивную стадию. Если в документе существуют отложенные к загрузке ресурсы (deferred scripts), которые должны быть обработаны, браузер парсит их. После этого запускается событие <a href="/en-US/docs/">DOMContentLoaded</a>, после которого готовность страницы завершена. Теперь документ может обрабатывать пост-загрузочные задачи. После этого документ маркируется, как полностью загруженный.</p> +<p>Когда пользователь запрашивает веб-приложение,<a href="/en-US/docs/Learn/Performance/Populating_the_page:_how_browsers_work"> браузер должен получить некоторые мета-данные</a>, чтобы начать загрузку. Для этого пользовательский агент проходит серию шагов, такие как поиск записи DNS ({{glossary('DNS')}} lookup), TCP рукопожатие {{glossary('TCP handshake')}}, и установку безопасного соединения (SSL negotiation). Как только браузер установил соединение, происходит первый полезный запрос данных на сервера. Как только начинают поступать данные от сервера, браузер начинает парсить полученные данные, строит DOM, CSSOM, создаёт деревья рендера (render trees), чтобы в конце концов отрендерить страницу. В тот момент, когда браузер перестаёт парсить входящие данные, документ переходит в интерактивную стадию. Если в документе существуют отложенные к загрузке ресурсы (deferred scripts), которые должны быть обработаны, браузер парсит их. После этого запускается событие <a href="/en-US/docs/">DOMContentLoaded</a>, после которого готовность страницы завершена. Теперь документ может обрабатывать пост-загрузочные задачи. После этого документ маркируется, как полностью загруженный.</p> <pre>let navigationTimings = performance.getEntriesByType('navigation');</pre> @@ -274,7 +274,7 @@ performance.getEntriesByType('frame').forEach((frame) => { <p><span class="message-body-wrapper"><span class="message-flex-body"><span class="devtools-monospace message-body">Если мы проверим вычисления, то результат получится схожим: </span></span></span><code>1 - (22.04 / 87.24) = 0.747</code>. Тайминги навигации позволяют нам получить такие данные программно.</p> -<p>Обратите внимание, что это данные для одного единственно документа, а не для всех ресурсов вместе взятых. В то же время, длительность загрузки, события-обработчики и тайминги построения DOM / CSSOM влияют на продолжительность загрузки всего приложения, не только одного конкретного ресурса. Клиентские приложения, выполняющиеся в браузере, могут выглядеть быстрее, если данные объемом 300КБ вы передаете сжатыми до 100КБ, но это все не значит, что JavaScript, CSS или другие медиа-ресурсы не раздувают приложение и не делают его медленнее. Проверка уровня сжатия - это очень важно, но не менее важно проверять длительность парсинга ресурсов и время между тем, как завершен DOMContentLoaded и DOM готов к работе. Может случиться так, что время парсинга скриптов и обработка скриптами результатов в основном потоке (main thread) приведет к зависанию интерфейса.</p> +<p>Обратите внимание, что это данные для одного единственно документа, а не для всех ресурсов вместе взятых. В то же время, длительность загрузки, события-обработчики и тайминги построения DOM / CSSOM влияют на продолжительность загрузки всего приложения, не только одного конкретного ресурса. Клиентские приложения, выполняющиеся в браузере, могут выглядеть быстрее, если данные объёмом 300КБ вы передаёте сжатыми до 100КБ, но это все не значит, что JavaScript, CSS или другие медиа-ресурсы не раздувают приложение и не делают его медленнее. Проверка уровня сжатия - это очень важно, но не менее важно проверять длительность парсинга ресурсов и время между тем, как завершён DOMContentLoaded и DOM готов к работе. Может случиться так, что время парсинга скриптов и обработка скриптами результатов в основном потоке (main thread) приведёт к зависанию интерфейса.</p> <h3 id="Время_запроса">Время запроса</h3> @@ -298,7 +298,7 @@ performance.getEntriesByType('frame').forEach((frame) => { <p>В объекте данных есть поле Длительность (<code>Duration</code>). Длительность - это разница между <a href="/en-US/docs/Web/API/PerformanceNavigationTiming/loadEventEnd">PerformanceNavigationTiming.loadEventEnd</a> и <a href="/en-US/docs/Web/API/PerformanceEntry/startTime">PerformanceEntry.startTime</a> properties.</p> -<p>Интерфейс PerformanceNavigationTiming, кроме того, дает информацию о том, какой тип навигации вы измеряете, возвращая <code>navigate</code>, <code>reload</code>, <code>back_forward</code> или <code>prerender</code>.</p> +<p>Интерфейс PerformanceNavigationTiming, кроме того, даёт информацию о том, какой тип навигации вы измеряете, возвращая <code>navigate</code>, <code>reload</code>, <code>back_forward</code> или <code>prerender</code>.</p> <h2 id="Resource">Resource</h2> diff --git a/files/ru/web/performance/optimizing_startup_performance/index.html b/files/ru/web/performance/optimizing_startup_performance/index.html index 6da93e1660..3358f1b8f4 100644 --- a/files/ru/web/performance/optimizing_startup_performance/index.html +++ b/files/ru/web/performance/optimizing_startup_performance/index.html @@ -4,7 +4,7 @@ slug: Web/Performance/Optimizing_startup_performance translation_of: Web/Performance/Optimizing_startup_performance --- <div class="summary"> -<p>Часто упускаемый из вида аспект разработки приложений - это скорость запуска приложения. Даже если вы прикладываете много усилий к оптимизации работы приложений, именно этот этап может быть пропущен. Как долго запускается ваше приложение? Создается ли впечатление, что устройство зависает, пока приложение запускается? Все эти симптомы заставляют пользователя считать, что приложение сломано или что-то идет не так. Всегда будет не лишним убедиться, что ваше приложение запускается плавно. В этой статье мы поделимся некоторыми подсказками, которые помогут вам оптимизировать запуск приложения, вне зависимости от того, пишете ли вы его с нуля или работаете над уже существующим.</p> +<p>Часто упускаемый из вида аспект разработки приложений - это скорость запуска приложения. Даже если вы прикладываете много усилий к оптимизации работы приложений, именно этот этап может быть пропущен. Как долго запускается ваше приложение? Создаётся ли впечатление, что устройство зависает, пока приложение запускается? Все эти симптомы заставляют пользователя считать, что приложение сломано или что-то идёт не так. Всегда будет не лишним убедиться, что ваше приложение запускается плавно. В этой статье мы поделимся некоторыми подсказками, которые помогут вам оптимизировать запуск приложения, вне зависимости от того, пишете ли вы его с нуля или работаете над уже существующим.</p> </div> <h2 id="Приятный_запуск">Приятный запуск</h2> @@ -13,7 +13,7 @@ translation_of: Web/Performance/Optimizing_startup_performance <p>Вместо этого, вы можете разбить ваш код так, чтобы часть его обрабатывалась в <a href="/en-US/docs/DOM/Using_web_workers" title="/en-US/docs/DOM/Using_web_workers">Web worker</a>, что выделит его в отдельные фоновые неблокирующие треды (например, запросы данных и их обработка). Затем, все, что должно быть выполнено в основном потоке (например, пользовательские события или рендеринг интерфейса) должно быть разбито на небольшие кусочки так, чтобы обработчик браузера выполнял небольшие куски кода итеративно, а не за один подход. Это позволит ваше приложению выглядеть отзывчивым даже во время первоначальной загрузки.</p> -<p>Почему так важно делать все это асинхронно? Помимо причин, перечисленных выше, подумайте о влиянии, которые оказывают зависшие приложения: пользователь не может отменить запуск, даже если он запустил приложение по ошибке. Если приложение запускается в браузере, пользователь даже не сможет закрыть вкладку. В конечно счете это может привести даже к системным предупреждениям о "медленных скриптах" или "исчерпании памяти". А ведь было время, когда каждая вкладка не работала в отдельном процессе, как сейчас, а потому повисшая вкладка приводила к зависанию всего браузера! Вы должны не просто делать загрузку приложения "мягкой", но и давать пользователю знать о процессе загрузки: показывайте ему прогресс-бары или этапы, которые проходит приложение. Это позволит пользователю убедиться, что приложение не зависло.</p> +<p>Почему так важно делать все это асинхронно? Помимо причин, перечисленных выше, подумайте о влиянии, которые оказывают зависшие приложения: пользователь не может отменить запуск, даже если он запустил приложение по ошибке. Если приложение запускается в браузере, пользователь даже не сможет закрыть вкладку. В конечно счёте это может привести даже к системным предупреждениям о "медленных скриптах" или "исчерпании памяти". А ведь было время, когда каждая вкладка не работала в отдельном процессе, как сейчас, а потому повисшая вкладка приводила к зависанию всего браузера! Вы должны не просто делать загрузку приложения "мягкой", но и давать пользователю знать о процессе загрузки: показывайте ему прогресс-бары или этапы, которые проходит приложение. Это позволит пользователю убедиться, что приложение не зависло.</p> <h3 id="Было_бы_желание...">Было бы желание...</h3> @@ -21,7 +21,7 @@ translation_of: Web/Performance/Optimizing_startup_performance <p>С другой стороны, потребуются некоторые ухищрения, если вы пытаетесь портировать существующее десктопное приложение в Web или привыкли писать такие. Десктопные приложения обычно не нуждаются в написании кода в асинхронной манере, потому что операционная система берет заботу об этом на себя. В исходниках такого приложения может быть лишь один поток обработки кода, но даже он может быть легко разбит на асинхронные этапы (запуском каждой новой итерации потока по отдельности). В таких приложениях запуск часто представляет собой последовательную монолитную процедуру, которая время от времени обращается к метрикам прогресса и обновляет их.</p> -<p>И хотя вы можете использовать <a href="/en-US/docs/DOM/Using_web_workers" title="/en-US/docs/DOM/Using_web_workers">Web workers</a>, чтобы обработать очень большие и "тяжелые" скрипты асинхронно, вы должны учитывать некоторые ограничения. Web Worker-ы не имеют доступа к некоторым API браузера: DOM, <a href="/en-US/docs/WebGL" title="/en-US/docs/WebGL">WebGL</a> или audio, они не могут посылать синхронные сообщения в основной поток, вы даже не можете проксировать некоторые из этих API в основной поток. Это всё означает, что вы можете поместить в Web Worker-ы только "чистые функции", но вам все равно придется вычислять огромную часть данных в основном потоке. Поэтому очень полезно разрабатывать систему так, чтобы в ней было как можно больше чистых функций - так их будет проще делегировать последствии.</p> +<p>И хотя вы можете использовать <a href="/en-US/docs/DOM/Using_web_workers" title="/en-US/docs/DOM/Using_web_workers">Web workers</a>, чтобы обработать очень большие и "тяжёлые" скрипты асинхронно, вы должны учитывать некоторые ограничения. Web Worker-ы не имеют доступа к некоторым API браузера: DOM, <a href="/en-US/docs/WebGL" title="/en-US/docs/WebGL">WebGL</a> или audio, они не могут посылать синхронные сообщения в основной поток, вы даже не можете проксировать некоторые из этих API в основной поток. Это всё означает, что вы можете поместить в Web Worker-ы только "чистые функции", но вам все равно придётся вычислять огромную часть данных в основном потоке. Поэтому очень полезно разрабатывать систему так, чтобы в ней было как можно больше чистых функций - так их будет проще делегировать последствии.</p> <p>Тем не менее, даже код в основном потоке можно сделать асинхронным, приложив лишь небольшие усилия.</p> @@ -45,9 +45,9 @@ translation_of: Web/Performance/Optimizing_startup_performance <p>Когда первоначальная загрузка завершена и начинается обработка приложения в основном потоке, вполне возможно, что ваше приложение обязано быть однопоточным, особенно если это портированная версия. Очень важно попытаться помочь процессу запуска приложения, порефакторив код, сделав его композитным, состоящим из маленьких кусочков, каждый из которых может быть обработан последовательно основным потоком. В этом случае, в промежутке между выполнением этих кусочков кода браузер сможет выделить время на обработку ввода (например, клик) или на обработку микро-задач.</p> -<p>В случае, если вы портируете ваше приложение, вы наверняка знаете о <a href="/en-US/docs/Mozilla/Projects/Emscripten">Emscripten. </a>Это решение предоставляет API, которое поможет с подобным рефакторингом. Например, вы можете использовать <code>emscripten_push_main_loop_blocker()</code>, чтобы определить функцию, как выполняемую после того, как основной поток разрешит продолжить работу. Создавая такие функции, создавая очередь, которая должна выполниться в определенном порядке, вы можете с легкостью разгрузить основной поток.</p> +<p>В случае, если вы портируете ваше приложение, вы наверняка знаете о <a href="/en-US/docs/Mozilla/Projects/Emscripten">Emscripten. </a>Это решение предоставляет API, которое поможет с подобным рефакторингом. Например, вы можете использовать <code>emscripten_push_main_loop_blocker()</code>, чтобы определить функцию, как выполняемую после того, как основной поток разрешит продолжить работу. Создавая такие функции, создавая очередь, которая должна выполниться в определённом порядке, вы можете с лёгкостью разгрузить основной поток.</p> -<p>Конечно, все это не отменяет необходимости рефакторинга кода так, чтобы он работал лучше и это займет время. Но для старта этого может оказаться достаточно.</p> +<p>Конечно, все это не отменяет необходимости рефакторинга кода так, чтобы он работал лучше и это займёт время. Но для старта этого может оказаться достаточно.</p> <h3 id="Насколько_далеко_я_должен_зайти">Насколько далеко я должен зайти?</h3> diff --git a/files/ru/web/performance/performance_budgets/index.html b/files/ru/web/performance/performance_budgets/index.html index ff86f4b139..8cb841d20d 100644 --- a/files/ru/web/performance/performance_budgets/index.html +++ b/files/ru/web/performance/performance_budgets/index.html @@ -3,7 +3,7 @@ title: Бюджет производительности slug: Web/Performance/Performance_budgets translation_of: Web/Performance/Performance_budgets --- -<p><span class="seoSummary">Бюджет производительности - это лимит для предотвращения регрессий. Этот бюджет может быть применен к файлам, типам файлов, всем ресурсам приложения, определенным общим показателям (например, <a href="/en-US/docs/Glossary/Time_to_interactive">Время до интерактивности</a>) пользовательским показателям (например, Время до главного элемента) или к пороговым значениям к определенным точкам во времени. </span></p> +<p><span class="seoSummary">Бюджет производительности - это лимит для предотвращения регрессий. Этот бюджет может быть применён к файлам, типам файлов, всем ресурсам приложения, определённым общим показателям (например, <a href="/en-US/docs/Glossary/Time_to_interactive">Время до интерактивности</a>) пользовательским показателям (например, Время до главного элемента) или к пороговым значениям к определённым точкам во времени. </span></p> <h2 id="Зачем_нужен_бюджет">Зачем нужен бюджет?</h2> @@ -14,12 +14,12 @@ translation_of: Web/Performance/Performance_budgets <ul> <li>Временные (например, <a href="/en-US/docs/Glossary/Time_to_interactive">Время до интерактивности,</a> <a href="/en-US/docs/Glossary/First_contentful_paint">Первая отрисовка контента</a>).</li> <li>Количественный (например, размер загруженных JS файлов, количество изображений).</li> - <li>Определенные правилами (например. индекс <a href="https://developers.google.com/speed/pagespeed/insights/">Pagespeed</a>, баллы Lighthouse).</li> + <li>Определённые правилами (например. индекс <a href="https://developers.google.com/speed/pagespeed/insights/">Pagespeed</a>, баллы Lighthouse).</li> </ul> <p>Главная цель такого подхода - сокращение регрессии. Но этот подход может помочь предсказать поведение приложения в будущем. Например, в Сентябре 50% месячного бюджета было использовано за неделю - значит, нужно ждать увеличения потребления контента, нагрузки на сервера и т.д.</p> -<p>Кроме того, подход может раскрыть некоторые нужды разработчиков (например, может оказаться, что в финальном коде вашего приложения половину объема занимает огромная библиотека, из которой вы используете только мизерную часть функционала).</p> +<p>Кроме того, подход может раскрыть некоторые нужды разработчиков (например, может оказаться, что в финальном коде вашего приложения половину объёма занимает огромная библиотека, из которой вы используете только мизерную часть функционала).</p> <h2 id="Как_определить_бюджет">Как определить бюджет?</h2> @@ -38,7 +38,7 @@ translation_of: Web/Performance/Performance_budgets <p>Базовая цель - достигнуть показателя <a href="https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/">"Время до интерактивности" до 5 секунд при 3G/4G, и до 2 секунд для последующих загрузок</a>. Однако, вы можете придумать свои цели, основанные на контенте приложения, географии пользователей и технологиях.</p> -<p>Например, для приложения с большим количеством текста (блоги, новостные сайты), показатель <a href="/en-US/docs/Glossary/First_contentful_paint">Первая отрисовка контента (First Contentful Paint)</a> будет гораздо лучше показывать, с чем сталкивается пользователь. Иными словами, этот показатель покажет, как быстро пользователь начинает читать. И этот показатель должен быть включен в специфичные бюджеты, например, бюджет шрифтов, где вы можете применять разные техники для оптимизации. Например, <a href="/en-US/docs/Web/CSS/@font-face/font-display">font-display</a>, чтобы улучшить <a href="/en-US/docs/Learn/Performance/perceived_performance">Субъективно Ощущаемую производительность</a>).</p> +<p>Например, для приложения с большим количеством текста (блоги, новостные сайты), показатель <a href="/en-US/docs/Glossary/First_contentful_paint">Первая отрисовка контента (First Contentful Paint)</a> будет гораздо лучше показывать, с чем сталкивается пользователь. Иными словами, этот показатель покажет, как быстро пользователь начинает читать. И этот показатель должен быть включён в специфичные бюджеты, например, бюджет шрифтов, где вы можете применять разные техники для оптимизации. Например, <a href="/en-US/docs/Web/CSS/@font-face/font-display">font-display</a>, чтобы улучшить <a href="/en-US/docs/Learn/Performance/perceived_performance">Субъективно Ощущаемую производительность</a>).</p> <p>Но самая главная цель таких бюджетов - это возможность корреляции Производительности и Бизнес-целей. Когда вы определяете какие-то показатели, вы должны сфокусироваться на пользовательском опыте. Только он может диктовать, как мы должны изменять приложение таким образом, чтобы не просто улучшить конверсию, но и предсказать вероятность того, что пользователь вернётся.</p> @@ -53,7 +53,7 @@ translation_of: Web/Performance/Performance_budgets <p>Проверка размеров файлов - это лишь первый рубеж защиты от регрессий. Преобразование этих показателей во временные может быть сложным, потому что во время разработки окружение разработчика может не включать в себя сторонние библиотеки или оптимизации, которые обычно присутствуют в Production сборках.</p> -<p>Поэтому, рекомендуется определить базовые линии для каждой метрики бюджета с учетом разницы между окружением разработчика и боевым окружением.</p> +<p>Поэтому, рекомендуется определить базовые линии для каждой метрики бюджета с учётом разницы между окружением разработчика и боевым окружением.</p> <p>С этим может помочь, например, <a href="https://github.com/GoogleChromeLabs/lighthousebot">Lighthouse Bot</a>, который можно встроить в <a href="https://travis-ci.org/">Travis CI</a> и использовать для получения аналитики <a href="https://developers.google.com/web/tools/lighthouse/">Lighthouse</a> и <a href="https://webpagetest.org">Webpage Test</a>. Этот бот будет сообщать об ошибке или успешном прохождении тестов на основе определённых минимальных оценок.</p> @@ -61,7 +61,7 @@ translation_of: Web/Performance/Performance_budgets <p>Чем раньше вы сможете определить новую трату к бюджету, тем лучше вы сможете оценить текущее состояние приложения и указать на необходимые оптимизации.</p> -<p>Кроме того, лучше иметь несколько бюджетов и быть проактивным. Бюджеты должны отражать ваши текущие цели, но не должны мешать экспериментам. Например, вы можете привнести функционал, который увеличит общее время загрузки приложения, но попытается увеличить пользовательскую вовлечённость (например, как долго пользователь остается на странице).</p> +<p>Кроме того, лучше иметь несколько бюджетов и быть проактивным. Бюджеты должны отражать ваши текущие цели, но не должны мешать экспериментам. Например, вы можете привнести функционал, который увеличит общее время загрузки приложения, но попытается увеличить пользовательскую вовлечённость (например, как долго пользователь остаётся на странице).</p> <p>Бюджет помогает вам сохранить оптимальное поведение ваших текущих пользователей, когда вы пытаетесь выйти на новые рынки или привнести что-то новое в ваше приложение.</p> diff --git a/files/ru/web/performance/rum-vs-synthetic/index.html b/files/ru/web/performance/rum-vs-synthetic/index.html index a2d0a17bec..6692991729 100644 --- a/files/ru/web/performance/rum-vs-synthetic/index.html +++ b/files/ru/web/performance/rum-vs-synthetic/index.html @@ -12,7 +12,7 @@ translation_of: Web/Performance/Rum-vs-Synthetic <h2 id="Синтетический_мониторинг"><strong>Синтетический мониторинг</strong></h2> -<p>Синтетический мониторинг включает в себя мониторинг производительности в "лабораторных" условиях, обычно с помощью автоматизированных инструментов в цельном окружении. Такой подход включает в себя создание скриптов, симулирующих путь, который может пройти пользователь, пользуясь приложением. Таким образом тестируются не настоящие пользователи, но заранее определенный набор инструкций, который выполняется в предопределенном окружении.</p> +<p>Синтетический мониторинг включает в себя мониторинг производительности в "лабораторных" условиях, обычно с помощью автоматизированных инструментов в цельном окружении. Такой подход включает в себя создание скриптов, симулирующих путь, который может пройти пользователь, пользуясь приложением. Таким образом тестируются не настоящие пользователи, но заранее определённый набор инструкций, который выполняется в предопределённом окружении.</p> <p>Пример такого мониторинга - <a href="https://WebPageTest.org">WebPageTest.org</a>. Ресурс предоставляет контролируемое окружение, где вы определяете географию, сеть, устройства, браузеры и кешированные данные. Сервис предоставляет Waterfall график для каждого ресурса, который используется в вашем приложении и грузится сторонними библиотеками (например, рекламными или аналитическими инструментами).</p> @@ -22,7 +22,7 @@ translation_of: Web/Performance/Rum-vs-Synthetic <h2 id="Мониторинг_реальных_пользователей_RUM">Мониторинг реальных пользователей (RUM)</h2> -<p id="Real_User_Monitoring_(RUM)"><strong>Мониторинг реальных пользователей (Real User Monitoring, RUM) </strong>измеряет производительность приложения на устройствах конечных пользователей. В основе подхода - сторонний скрипт, который вставляет другие скрипты на каждую страницу. Эти дополнительные скрипты измеряют производительность и предоставляют отчеты о ней. Этот подход помогает не только узнать, насколько производительно приложение, но и дает информацию об использовании приложения, например, о географии, распределении пользователей или влиянии такого распределения на пользовательский опыт.</p> +<p id="Real_User_Monitoring_(RUM)"><strong>Мониторинг реальных пользователей (Real User Monitoring, RUM) </strong>измеряет производительность приложения на устройствах конечных пользователей. В основе подхода - сторонний скрипт, который вставляет другие скрипты на каждую страницу. Эти дополнительные скрипты измеряют производительность и предоставляют отчёты о ней. Этот подход помогает не только узнать, насколько производительно приложение, но и даёт информацию об использовании приложения, например, о географии, распределении пользователей или влиянии такого распределения на пользовательский опыт.</p> <p>В отличие от синтетического мониторинга, RUM собирает данные от настоящих пользователей, вне зависимости от их устройств, браузеров, сети или геолокации. Пока пользователь взаимодействует с приложением, тайминги такого взаимодействия записываются, вне зависимости от того, какое действие выполняется в конкретный момент. Такой мониторинг собирает данные о реальном использовании приложения, а не о том поведении, которое ожидают разработчики или, скажем, отдел маркетинга. Это особенно важно для больших веб-сайтов или сложных приложений, где функционал или содержимое постоянно меняются, а количество пользователей может очень сильно расти, создавая новые нагрузки и требования.</p> @@ -32,7 +32,7 @@ translation_of: Web/Performance/Rum-vs-Synthetic <p>Синтетический мониторинг хорошо подходит для отлавливания регрессий в ходе разработки приложения. Особенно полезным может оказаться занижение скорости сети ({{glossary('network throttling')}}). Такой подход довольно прост, недорог и великолепно подходит для тестирования определённых точек приложения по мере того, как вы вносите изменения в код. Но он даёт лишь узкий обзор производительности и не говорит о том, что испытывает пользователь.</p> -<p>Тестирование на реальных пользователях, в свою очередь, дает информацию о настоящих пользователях, которые используют приложение или веб-сайт. И хотя получение и обработка таких данных обходится дороже и не так проста, такой подход дает жизненно важные данные о пользовательском опыте.</p> +<p>Тестирование на реальных пользователях, в свою очередь, даёт информацию о настоящих пользователях, которые используют приложение или веб-сайт. И хотя получение и обработка таких данных обходится дороже и не так проста, такой подход даёт жизненно важные данные о пользовательском опыте.</p> <h2 id="API_для_измерения_производительности">API для измерения производительности</h2> |