diff options
Diffstat (limited to 'files/ru/web/performance')
10 files changed, 28 insertions, 28 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 ef73122adf..9b9121b742 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 @@ -32,7 +32,7 @@ original_slug: Web/Performance/Производительность_анимац <p><br> Однако, стоимость изменения разных 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> +<p>Стоит заметить, что 60 кадров в секунду - это стандартная частота обновления экрана. Существуют экраны с гораздо большим FPS. Например, экраны игровых ноутбуков или iPad Pro 2018 имеют частоту смены кадров, равную 120 fps и выше. Для таких устройств производители браузеров ограничивают частоту 60-ю кадрами в секунду, но с помощью некоторых опций этот лимит можно убрать. И в этом случае, на формирование каждого кадра устройство будет отводить лишь 8.6 миллисекунд.</p> <h2 id="Этапы_рендеринга">Этапы рендеринга</h2> @@ -46,7 +46,7 @@ original_slug: Web/Performance/Производительность_анимац <li><strong>Paint</strong>: наконец, браузер должен перерисовать элементы на экране. Но этот этап не обязательно должен быть простым, как на изображении. Страница может быть разделена на слои, каждый из которых перерисовывается независимо, а только после этого они комбинируются в процессе, который называется композицией "Composition".</li> </ol> -<p>Процессы, которые браузер использует для отрисовывания изменений на элементе <canvas> отличаются. В случае <canvas>, Layout не присходит. Скорее, страница будет перерисована с помощью JavaScript canvas API. </p> +<p>Процессы, которые браузер использует для отрисовывания изменений на элементе <canvas> отличаются. В случае <canvas>, Layout не происходит. Скорее, страница будет перерисована с помощью JavaScript canvas API. </p> <p>В любом случае, вычисление каждого следующего кадра должно происходить достаточно быстро, чтобы успеть попасть в частоту обновления экрана, чтобы не было зависаний.</p> @@ -122,7 +122,7 @@ original_slug: Web/Performance/Производительность_анимац <p><img alt="" src="https://mdn.mozillademos.org/files/10853/margin-recording.png" style="display: block; height: 237px; margin-left: auto; margin-right: auto; width: 800px;"></p> -<p>На экране показаны три отдельных секции: (a) обзор этапов рендеринга (Waterfall), (b) частота кадров, и (c) детали на временной шкали.</p> +<p>На экране показаны три отдельных секции: (a) обзор этапов рендеринга (Waterfall), (b) частота кадров, и (c) детали на временной шкалы.</p> <h4 id="Обзор_этапов_рендеринга_на_временной_шкале_Waterfall">Обзор этапов рендеринга на временной шкале (Waterfall)</h4> diff --git a/files/ru/web/performance/critical_rendering_path/index.html b/files/ru/web/performance/critical_rendering_path/index.html index ae8a15756d..e486781c97 100644 --- a/files/ru/web/performance/critical_rendering_path/index.html +++ b/files/ru/web/performance/critical_rendering_path/index.html @@ -9,7 +9,7 @@ translation_of: Web/Performance/Critical_rendering_path <p>Объектная модель документа DOM создается в тот момент, когда браузер парсит HTML. Этот HTML может запрашивать JavaScript, который может модифицировать DOM. HTML может запросить стили, которые участвуют в создании СSS Object Model. Движок браузера комбинирует эти две объектные модели, чтобы создать дерево рендера (render tree). Компоновка (layout) определяет размеры и позицию каждого элемента на странице. Как только компоновка определена - пиксели отрисовываются на экране.</p> -<p>Оптимизация критичеческих этапов рендеринга улучшает время до первого рендера. Понимание и оптимизация этих этапов чрезвычайно важны для того, чтобы рендерить приложение с нужной частотой кадров (60 кадров в секунду, fps) и предоставить пользователю удобный, плавный интерфейс.</p> +<p>Оптимизация критических этапов рендеринга улучшает время до первого рендера. Понимание и оптимизация этих этапов чрезвычайно важны для того, чтобы рендерить приложение с нужной частотой кадров (60 кадров в секунду, fps) и предоставить пользователю удобный, плавный интерфейс.</p> <h2 id="Понимание_этапов_CRP">Понимание этапов (CRP)</h2> @@ -31,7 +31,7 @@ translation_of: Web/Performance/Critical_rendering_path <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> +<p>Если вы измерите время, требуемое на парсинг CSS, вы будете удивлены тем, как быстро работают браузеры. Более специфичные правила более затратны, потому что требуют обхода большего числа узлов в DOM дереве, но эта дороговизна обходится довольно дёшево, особенно в сравнении с другими узкими местами производительности. <u>Сначала измеряйте. Потом оптимизируйте, если это действительно необходимо.</u> Вероятно, специфичность селекторов не то, что действительно затормаживает ваше приложение. Когда дело доходит до оптимизации CSS, улучшение производительность селекторов ускоряет рендеринг лишь на микросекунды. Существуют другие <a href="/en-US/docs/Learn/Performance/CSS_performance">пути оптимизации CSS</a>, такие как унификация, разделение CSS-файлов на разные файлы на основе media-queries.</p> <h3 id="Дерево_рендера_Render_Tree">Дерево рендера (Render Tree)</h3> @@ -57,7 +57,7 @@ translation_of: Web/Performance/Critical_rendering_path <h2 id="Оптимизация_CRP">Оптимизация CRP</h2> -<p>Улучшайте загрузку страницы с помощью приоритезации ресурсов, с помощью контролирования порядка, в котором они грузятся и с помощью уменьшения размеров файлов. Главные подсказки здесь:</p> +<p>Улучшайте загрузку страницы с помощью приоритизации ресурсов, с помощью контролирования порядка, в котором они грузятся и с помощью уменьшения размеров файлов. Главные подсказки здесь:</p> <ol> <li>Уменьшайте количество критических ресурсов, откладывая их загрузку, помечая их как async и/или группируя их;</li> 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 264fc1ea9b..b6dbb2bedf 100644 --- a/files/ru/web/performance/css_javascript_animation_performance/index.html +++ b/files/ru/web/performance/css_javascript_animation_performance/index.html @@ -10,7 +10,7 @@ tags: - Производительность translation_of: Web/Performance/CSS_JavaScript_animation_performance --- -<p class="summary">Анимация является критичным инструментов для улучшения пользовательнского опыта во многих приложениях. Существует много путей создания анимации в web, например, основанные на CSS-свойствах {{cssxref("transition","transitions")}}/{{cssxref("animation","animations")}} или на JavaScript (using {{domxref("Window.requestAnimationFrame","requestAnimationFrame()")}}). В этой статье мы проанализируем производительность CSS и JavaScript анимаций и сравним их.</p> +<p class="summary">Анимация является критичным инструментов для улучшения пользовательского опыта во многих приложениях. Существует много путей создания анимации в web, например, основанные на CSS-свойствах {{cssxref("transition","transitions")}}/{{cssxref("animation","animations")}} или на JavaScript (using {{domxref("Window.requestAnimationFrame","requestAnimationFrame()")}}). В этой статье мы проанализируем производительность CSS и JavaScript анимаций и сравним их.</p> <h2 id="CSS_transition_и_animation">CSS transition и animation</h2> @@ -55,7 +55,7 @@ translation_of: Web/Performance/CSS_JavaScript_animation_performance <h3 id="Запуск_теста">Запуск теста</h3> -<p>Для начала, в нашем тесте мы будем анимаировать 1000 элементов {{htmlelement("div")}} с помощью CSS.</p> +<p>Для начала, в нашем тесте мы будем анимировать 1000 элементов {{htmlelement("div")}} с помощью CSS.</p> <p><span style="line-height: 16.7999992370605px;">{{JSFiddleEmbed("https://jsfiddle.net/zt94oew2/1/","","480")}}</span></p> diff --git a/files/ru/web/performance/fundamentals/index.html b/files/ru/web/performance/fundamentals/index.html index c4d8b93895..b7e7d891c0 100644 --- a/files/ru/web/performance/fundamentals/index.html +++ b/files/ru/web/performance/fundamentals/index.html @@ -65,7 +65,7 @@ original_slug: Web/Performance/Основы <h3 id="Web_технологии">Web технологии</h3> -<p>Web платформа предоставляет много инструментов, некоторые из которых лучше подходят для конкретных задач, а некоторые - хуже. Логика приложений пишется на JavaScript. Для отображения графики разработчики могут использовать HTML или CSS (т.е. используются высокоуровневные декларативные языки); разработчики также могут использовать низкоуровневые интерфейсы, доступные в {{ htmlelement("canvas") }} (включая <a href="/en-US/docs/Web/WebGL">WebGL</a>). Где-то между HTML/CSS и Canvas лежит <a href="/en-US/docs/Web/SVG">SVG</a>, который предлагает некоторые преимущества обеих систем.</p> +<p>Web платформа предоставляет много инструментов, некоторые из которых лучше подходят для конкретных задач, а некоторые - хуже. Логика приложений пишется на JavaScript. Для отображения графики разработчики могут использовать HTML или CSS (т.е. используются высокоуровневые декларативные языки); разработчики также могут использовать низкоуровневые интерфейсы, доступные в {{ htmlelement("canvas") }} (включая <a href="/en-US/docs/Web/WebGL">WebGL</a>). Где-то между HTML/CSS и Canvas лежит <a href="/en-US/docs/Web/SVG">SVG</a>, который предлагает некоторые преимущества обеих систем.</p> <p>HTML и CSS значительно увеличивают производительность, иногда снижая частоту кадров и не давая контролировать каждый пиксель при рендере. Текст и изображения перерисовываются автоматически, UI-элементы автоматически получают системную тему, а система предоставляет некоторую "встроенную" поддержку для некоторых случаев, о которых разработчик может и не задумываться изначально. Например, отображение контента при разных разрешениях.</p> @@ -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> @@ -154,7 +154,7 @@ original_slug: Web/Performance/Основы <p>Современные ЦПУ могут работать в режиме энергосбережения, когда они не задействованы. Приложения, которые постоянно запускают таймеры или продолжают ненужные анимации, мешают процессору перейти в режим энергосбережения. Эффективные приложения не должны так делать.</p> -<p>Когда приложение переходит в фоновый режим, срабатывает событие {{event("visibilitychange")}}. Это событие - друг разработчика. Приложения должы слушать его и реагировать на него. Например, в Firefox OS, приложения, которые умеют ограничивать использование ресурсов и экономят память, когда переходят в фоновый режим, с меньшей долей вероятности будут отключены (см. заметку ниже). Это, если посмотреть с другой стороны, означает, что раз приложение не было выгружено - оно будет быстрее загружено.</p> +<p>Когда приложение переходит в фоновый режим, срабатывает событие {{event("visibilitychange")}}. Это событие - друг разработчика. Приложения должны слушать его и реагировать на него. Например, в Firefox OS, приложения, которые умеют ограничивать использование ресурсов и экономят память, когда переходят в фоновый режим, с меньшей долей вероятности будут отключены (см. заметку ниже). Это, если посмотреть с другой стороны, означает, что раз приложение не было выгружено - оно будет быстрее загружено.</p> <div class="note"> <p><strong>Заметка:</strong> Как было упомянуто выше, Firefox OS пытается сохранить как можно больше приложений, но иногда вынуждена приостанавливать некоторые из них. Обычно это происходит, когда у устройства заканчивается память. Чтобы узнать больше о том, как Firefox OS управляет памятью и избавляется от приложений, когда начинаются проблемы с памятью, читайте <a href="/en-US/docs/Archive/B2G_OS/Debugging/Debugging_OOMs">Debugging out of memory errors on Firefox OS</a>.</p> @@ -176,10 +176,10 @@ 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> +<p><strong>Заметка:</strong> В некоторых случаях (в зависимости от платформы) вам может понадобиться добавить свойство <code>translateZ(0.1)</code>, если вы хотите заставить клиента перенести вычисление анимаций на графический адаптер. Как было упомянуто выше, это может улучшить производительность, но увеличит потребление памяти. Какое из зол - меньшее - решать вам. Протестируйте оба варианта и выясните, что лучше подходит для вашего приложения.</p> </div> <h4 id="Используйте_requestAnimationFrame_вместо_setInterval">Используйте <code>requestAnimationFrame()</code> вместо <code>setInterval()</code></h4> diff --git a/files/ru/web/performance/how_browsers_work/index.html b/files/ru/web/performance/how_browsers_work/index.html index a2e16dd970..cda110effb 100644 --- a/files/ru/web/performance/how_browsers_work/index.html +++ b/files/ru/web/performance/how_browsers_work/index.html @@ -59,7 +59,7 @@ translation_of: Web/Performance/How_browsers_work <p><img alt="The DNS lookup, the TCP handshake, and 5 steps of the TLS handshake including clienthello, serverhello and certificate, clientkey and finished for both server and client." src="https://mdn.mozillademos.org/files/16746/ssl.jpg" style="height: 412px; width: 729px;"></p> -<p>И хотя обеспечение безопасности соединения снижает скорость загруки приложения, безопасное соединение стоит затрат на него, так как в этом случае данные не могут быть дешифрованы третьим лицом.</p> +<p>И хотя обеспечение безопасности соединения снижает скорость загрузки приложения, безопасное соединение стоит затрат на него, так как в этом случае данные не могут быть дешифрованы третьим лицом.</p> <p>После обмена восемью сообщениями, браузер, наконец, достигает всех условий, чтобы сделать запрос.</p> @@ -153,7 +153,7 @@ translation_of: Web/Performance/How_browsers_work <h4 id="Компиляция_JavaScript">Компиляция JavaScript</h4> -<p>Как CSS обработан и CSSOM создан, другие ресурсы, например, JavaScript-файлы, продолжают загружаться (спасибо сканеру предзагрузки). JavaScript по окончании загрузки должен быть интерпретирован, скомпилирован, обработан и исполнен. Скрипты преобразовываются в абстрактное синтаксическое дерево (AST). Некоторые браузеры берут {{glossary('Abstract Syntax Tree')}} и передают его в интерпретатор, который преобразует дерево в байт-код. Байткод исполняется в основном потоке. Весь этот процесс называется компиляцией.</p> +<p>Как CSS обработан и CSSOM создан, другие ресурсы, например, JavaScript-файлы, продолжают загружаться (спасибо сканеру предзагрузки). JavaScript по окончании загрузки должен быть интерпретирован, скомпилирован, обработан и исполнен. Скрипты преобразовываются в абстрактное синтаксическое дерево (AST). Некоторые браузеры берут {{glossary('Abstract Syntax Tree')}} и передают его в интерпретатор, который преобразует дерево в байт-код. Байт-код исполняется в основном потоке. Весь этот процесс называется компиляцией.</p> <h4 id="Построение_дерева_доступности">Построение дерева доступности</h4> 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 1812385647..37a17d18e9 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 @@ -17,7 +17,7 @@ translation_of: Web/Performance/How_long_is_too_long <p>Как правило, первый ресурс, который получает клиент - это HTML документ, который затем делает запрос на загрузку остальных ресурсов. Как было подмечено в <a href="/ru/docs/Web/Performance/Critical_rendering_path">статье о критическом пути рендеринга</a> - как только браузер получает данные, он сразу начинает их обработку, вместо того, чтобы дожидаться загрузки всех ресурсов.</p> -<p>Да, одна секунда на загрузку - это хорошая цель. Но лишь немногие приложения достигают этой скорости. Всё зависит от ожиданий. Например, от приложения "Hello World", работающего в корпоративной (локальной) сети, будет ожидаться загрузка за милисекунды. Пользователь из северной Сибири, пользующийся Edge-мобильной сетью и устройством 5-летней давности, вероятно, посчитает даже 20-секундную загрузку быстрой. Однако, в среднем, если вы позволяете приложению не отвечать на запрос 3 или 4 секунды, вы, вероятно, потеряете пользователя. И, что ещё хуже, этот пользователь вряд ли вернётся к вам в ближайшее время.</p> +<p>Да, одна секунда на загрузку - это хорошая цель. Но лишь немногие приложения достигают этой скорости. Всё зависит от ожиданий. Например, от приложения "Hello World", работающего в корпоративной (локальной) сети, будет ожидаться загрузка за миллисекунды. Пользователь из северной Сибири, пользующийся Edge-мобильной сетью и устройством 5-летней давности, вероятно, посчитает даже 20-секундную загрузку быстрой. Однако, в среднем, если вы позволяете приложению не отвечать на запрос 3 или 4 секунды, вы, вероятно, потеряете пользователя. И, что ещё хуже, этот пользователь вряд ли вернётся к вам в ближайшее время.</p> <p>В деле оптимизации производительности рекомендуется обозначить амбициозные задачи по первичной загрузке контента. Например, 5 секунд для 3G сетей и 1.5 секунды для офисного Т1 канала. Для навигации внутри приложения цели должны быть ещё строже. К счастью, для оптимизации можно использовать Service Workers и кэширование.</p> diff --git a/files/ru/web/performance/index.html b/files/ru/web/performance/index.html index 51b68b881a..82f34d4d7a 100644 --- a/files/ru/web/performance/index.html +++ b/files/ru/web/performance/index.html @@ -23,7 +23,7 @@ translation_of: Web/Performance <p>Чем дольше загружается ваше приложение, тем больше пользователей решаются избавиться от него. Очень важно уменьшать время загрузки приложения, а так же промежутка времени, за которое оно становится интерактивным. Но в то же время, важно добавлять в приложение новые возможности, которые уменьшают время отклика и делают приложение интерактивным за счет неочевидных хитростей, например, за счет асинхронной загрузки данных, которые не понадобятся пользователю "здесь и сейчас". </p> -<p>Существуют инструменты измерения производительности, API и лучшие практики, которые помогут нам измерять и улучшать производительноть. Мы постараемся раскрыть их в следующей секции:</p> +<p>Существуют инструменты измерения производительности, API и лучшие практики, которые помогут нам измерять и улучшать производительность. Мы постараемся раскрыть их в следующей секции:</p> <h2 id="Ключевые_статьи_о_производительности">Ключевые статьи о производительности</h2> 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 91cf4781b9..bd6c3327d3 100644 --- a/files/ru/web/performance/navigation_and_resource_timings/index.html +++ b/files/ru/web/performance/navigation_and_resource_timings/index.html @@ -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> @@ -302,7 +302,7 @@ performance.getEntriesByType('frame').forEach((frame) => { <h2 id="Resource">Resource</h2> -<p>В то время, как тайминги навигации измеряют произодительность загрузки и парсинга основного файла HTML, этот файл служит лишь точкой входа для загрузки других ресурсов. Поэтому нам так же важно знать, как быстро загружаются дополнительные ресурсы. Для измерения этих данных нужно использовать Resource Timing. Большая часть измерений в этом объекте похожи: здесь и поиск домена в DNS, и TCP установка соединения и т.д.</p> +<p>В то время, как тайминги навигации измеряют производительность загрузки и парсинга основного файла HTML, этот файл служит лишь точкой входа для загрузки других ресурсов. Поэтому нам так же важно знать, как быстро загружаются дополнительные ресурсы. Для измерения этих данных нужно использовать Resource Timing. Большая часть измерений в этом объекте похожи: здесь и поиск домена в DNS, и TCP установка соединения и т.д.</p> <p><img alt="Graphic of Resource Timing timestamps" src="https://mdn.mozillademos.org/files/12093/ResourceTiming-TimeStamps.jpg"></p> diff --git a/files/ru/web/performance/optimizing_startup_performance/index.html b/files/ru/web/performance/optimizing_startup_performance/index.html index 941c5894a9..6da93e1660 100644 --- a/files/ru/web/performance/optimizing_startup_performance/index.html +++ b/files/ru/web/performance/optimizing_startup_performance/index.html @@ -9,7 +9,7 @@ translation_of: Web/Performance/Optimizing_startup_performance <h2 id="Приятный_запуск">Приятный запуск</h2> -<p>Не имеет значения, какую платформу вы используете, всегда будет правильным обеспечить как можно более быструю загрузку приложения. Так как это наиболее общая проблема, мы не будем заострять на ней внимание здесь. Однако, мы обратим внимание на наибольшую проблему Web-приложений: синхронная загрузка ресурсов. Решением этой проблемы был бы максимальный переход на асинхронную загрузку ресурсов. Это означает, что инициализриующий код не должен запускаться в одно единственном обработчике событий в главном потоке процесса.</p> +<p>Не имеет значения, какую платформу вы используете, всегда будет правильным обеспечить как можно более быструю загрузку приложения. Так как это наиболее общая проблема, мы не будем заострять на ней внимание здесь. Однако, мы обратим внимание на наибольшую проблему Web-приложений: синхронная загрузка ресурсов. Решением этой проблемы был бы максимальный переход на асинхронную загрузку ресурсов. Это означает, что инициализирующий код не должен запускаться в одно единственном обработчике событий в главном потоке процесса.</p> <p>Вместо этого, вы можете разбить ваш код так, чтобы часть его обрабатывалась в <a href="/en-US/docs/DOM/Using_web_workers" title="/en-US/docs/DOM/Using_web_workers">Web worker</a>, что выделит его в отдельные фоновые неблокирующие треды (например, запросы данных и их обработка). Затем, все, что должно быть выполнено в основном потоке (например, пользовательские события или рендеринг интерфейса) должно быть разбито на небольшие кусочки так, чтобы обработчик браузера выполнял небольшие куски кода итеративно, а не за один подход. Это позволит ваше приложению выглядеть отзывчивым даже во время первоначальной загрузки.</p> @@ -45,17 +45,17 @@ 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> <h3 id="Насколько_далеко_я_должен_зайти">Насколько далеко я должен зайти?</h3> -<p>Стоит держать в голове, что браузер начинает беспокоиться о вашем скрипте в том случае, если он блокирует основной поток больше, чем на 10 секунд. В идеале, вы не должны блокировать работу страницы так долго. И пока вы держите показатели загрузки приложения ниже этих значение - все должно быть ок. Но не забывайте, что если кто-то имеет не такой мощный компьютер или мобильное устройство, как у вас, то код, выполняющийся у вас за 2 секунды, у этого пользователя может занять 10 секунд. Для этого полезно использовать CPU Throttling, который предоставляется средствами разработчиков в некоорых браузерах.</p> +<p>Стоит держать в голове, что браузер начинает беспокоиться о вашем скрипте в том случае, если он блокирует основной поток больше, чем на 10 секунд. В идеале, вы не должны блокировать работу страницы так долго. И пока вы держите показатели загрузки приложения ниже этих значение - все должно быть ок. Но не забывайте, что если кто-то имеет не такой мощный компьютер или мобильное устройство, как у вас, то код, выполняющийся у вас за 2 секунды, у этого пользователя может занять 10 секунд. Для этого полезно использовать CPU Throttling, который предоставляется средствами разработчиков в некоторых браузерах.</p> <h2 id="Другие_предложения">Другие предложения</h2> -<p>Существуют другие вещи, которые могут влиять на скорость запуска приложения, и одна лишь асинхонность не спасёт от всего. Вот несколько из них:</p> +<p>Существуют другие вещи, которые могут влиять на скорость запуска приложения, и одна лишь асинхронность не спасёт от всего. Вот несколько из них:</p> <dl> <dt>Время загрузки</dt> diff --git a/files/ru/web/performance/performance_budgets/index.html b/files/ru/web/performance/performance_budgets/index.html index db42819c7d..ff86f4b139 100644 --- a/files/ru/web/performance/performance_budgets/index.html +++ b/files/ru/web/performance/performance_budgets/index.html @@ -7,7 +7,7 @@ translation_of: Web/Performance/Performance_budgets <h2 id="Зачем_нужен_бюджет">Зачем нужен бюджет?</h2> -<p>Бюджет существует для отражения желаемых вами целей. С бюджетом вы сможете осознанно выстраивать компромисы между пользовательским опытом и объективным индикаторами эффективности приложения (например, конверсией)</p> +<p>Бюджет существует для отражения желаемых вами целей. С бюджетом вы сможете осознанно выстраивать компромиссы между пользовательским опытом и объективным индикаторами эффективности приложения (например, конверсией)</p> <p>Эти цели можно разбить на категории:</p> @@ -40,18 +40,18 @@ translation_of: Web/Performance/Performance_budgets <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> +<p>Но самая главная цель таких бюджетов - это возможность корреляции Производительности и Бизнес-целей. Когда вы определяете какие-то показатели, вы должны сфокусироваться на пользовательском опыте. Только он может диктовать, как мы должны изменять приложение таким образом, чтобы не просто улучшить конверсию, но и предсказать вероятность того, что пользователь вернётся.</p> <h2 id="Как_создать_бюджет">Как создать бюджет?</h2> -<p>Во время разработки вы можете использовать несколько инстурментов, чтобы проверять некоторые показатели:</p> +<p>Во время разработки вы можете использовать несколько инструментов, чтобы проверять некоторые показатели:</p> <ul> - <li>Сборщики (наприме, <a href="https://webpack.js.org/">webpack</a>), из коробки содержат<a href="https://webpack.js.org/configuration/performance/"> инструменты оценки производительности</a>, которые сообщат вам, если какой-то из файлов превысил допустимые размеры.</li> + <li>Сборщики (например, <a href="https://webpack.js.org/">webpack</a>), из коробки содержат<a href="https://webpack.js.org/configuration/performance/"> инструменты оценки производительности</a>, которые сообщат вам, если какой-то из файлов превысил допустимые размеры.</li> <li><a href="https://github.com/siddharthkp/bundlesize">Bundlesize</a>, позволяет вам определить и проверять размеры файлов каждый раз при интеграции вашего кода с помощью <a href="/en-US/docs/Mozilla/Continuous_integration">CI</a>.</li> </ul> -<p>Проверка размеров файлов - это лишь первый рубеж защиты от регрессий. Преобразование этих показателей во временные может быть сложным, потому что во время разработки окружение разработчика может не включать в себя сторонние библиотеки или оптимизации, которые обычно присутствют в Production сборках.</p> +<p>Проверка размеров файлов - это лишь первый рубеж защиты от регрессий. Преобразование этих показателей во временные может быть сложным, потому что во время разработки окружение разработчика может не включать в себя сторонние библиотеки или оптимизации, которые обычно присутствуют в Production сборках.</p> <p>Поэтому, рекомендуется определить базовые линии для каждой метрики бюджета с учетом разницы между окружением разработчика и боевым окружением.</p> |