Deeper yofication of Russian translation (#251)

4 files changed, 6 insertions, 6 deletions

diff --git a/files/ru/web/performance/critical_rendering_path/index.html b/files/ru/web/performance/critical_rendering_path/index.html
index ee91e0e4c8..995d8f81c8 100644
--- a/files/ru/web/performance/critical_rendering_path/index.html
+++ b/files/ru/web/performance/critical_rendering_path/index.html
@@ -47,7 +47,7 @@ translation_of: Web/Performance/Critical_rendering_path
 
 <p>Мета тэг viewport, который вы можете указать в Head страницы, определяет ширину видимой области и влияет на компоновку. Без этого тэга браузеры используют ширину "по умолчанию", которая обычно составляет 960px. В браузерах, открывающихся по умолчанию в полноэкранном режиме, например, в браузере телефона, установка тега <code>&lt;meta name="viewport" content="width=device-width"&gt;</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>
 
diff --git a/files/ru/web/performance/fundamentals/index.html b/files/ru/web/performance/fundamentals/index.html
index 704ebee8a2..a809d421f9 100644
--- a/files/ru/web/performance/fundamentals/index.html
+++ b/files/ru/web/performance/fundamentals/index.html
@@ -137,7 +137,7 @@ original_slug: Web/Performance/Основы
 
 <p>При отрисовывании контента в Canvas, разработчик должен сам позаботиться о достижении целей по частоте кадров, ведь он получает полный контроль над всем, что отрисовывается.</p>
 
-<p>При использовании HTML и CSS разработчику необходимо использовать правильные примитивы. Firefox очень хорошо оптимизирован для скролла любого контента. Обычно это не является проблемой. Но очень часто, разменивая качество и стабильность на скорость, мы идём на ухищрения, которые могут "переоптимизировать" страницу так, что частота кадров будет выше нужной нам. Так как глаз все равно слабо различает FPS больше 60, нет необходимости в таких оптимизациях. Одна из таких оптимизаций - использование статического рендера вместо CSS-градиента. В некоторых случаях это излишне. Чтобы не применять оптимизацию, вы можете воспользоваться CSS <a href="/en-US/docs/Web/Guide/CSS/Media_queries">media queries</a>, которые позволят использовать подобные решения только для конкретных устройств.</p>
+<p>При использовании HTML и CSS разработчику необходимо использовать правильные примитивы. Firefox очень хорошо оптимизирован для скролла любого контента. Обычно это не является проблемой. Но очень часто, разменивая качество и стабильность на скорость, мы идём на ухищрения, которые могут "переоптимизировать" страницу так, что частота кадров будет выше нужной нам. Так как глаз всё равно слабо различает FPS больше 60, нет необходимости в таких оптимизациях. Одна из таких оптимизаций - использование статического рендера вместо CSS-градиента. В некоторых случаях это излишне. Чтобы не применять оптимизацию, вы можете воспользоваться CSS <a href="/en-US/docs/Web/Guide/CSS/Media_queries">media queries</a>, которые позволят использовать подобные решения только для конкретных устройств.</p>
 
 <p>Множество приложений используют Transitions и Animations для перехода между страницами или панелями. Например, когда пользователь нажимает кнопку "Настройки", чтобы перейти на другой экран; или для вызова поп-апа. Firefox оптимизирован для выполнения переходов и анимаций для сцен, которые:</p>
 
diff --git a/files/ru/web/performance/how_browsers_work/index.html b/files/ru/web/performance/how_browsers_work/index.html
index 97c05dfae7..5915c27700 100644
--- a/files/ru/web/performance/how_browsers_work/index.html
+++ b/files/ru/web/performance/how_browsers_work/index.html
@@ -109,7 +109,7 @@ translation_of: Web/Performance/How_browsers_work
 
 <p>DOM (Объектная модель документа) - это внутреннее представление разметки HTML. Браузер предоставляет доступ к манипуляции объектами этой модели через разные JavaScript API.</p>
 
-<p>Даже если ответ на запрос больше 14КБ, браузер все равно начинает парсинг данных и пытается отрисовать страницу с теми данными, которые уже доступны. Именно поэтому при оптимизации производительности очень важно включать в инициирующий 14КБ ответ все необходимые для рендера данные - так браузер сможет быстрее начать формирование страницы. Однако, прежде чем что-либо появится на экране, HTML, CSS и JavaScript должны быть обработаны.</p>
+<p>Даже если ответ на запрос больше 14КБ, браузер всё равно начинает парсинг данных и пытается отрисовать страницу с теми данными, которые уже доступны. Именно поэтому при оптимизации производительности очень важно включать в инициирующий 14КБ ответ все необходимые для рендера данные - так браузер сможет быстрее начать формирование страницы. Однако, прежде чем что-либо появится на экране, HTML, CSS и JavaScript должны быть обработаны.</p>
 
 <h3 id="Построение_дерева_объектной_модели_документа">Построение дерева объектной модели документа</h3>
 
@@ -169,7 +169,7 @@ translation_of: Web/Performance/How_browsers_work
 
 <p>Третий шаг в критическом пути рендеринга - это комбинирование DOM и CSSOM в дерево рендеринга. Конструирование этого дерева начинается с прохода всего DOM-дерева от корня, с выявлением каждого видимого узла.</p>
 
-<p>Элементы, которые не должны быть показаны, например, <code>&lt;head&gt;</code>, а так же их дети или любые элементы с <code>display:none</code>, такие как <code>script { display: none; }</code>, не будут включены в дерево рендера, так как они не должны быть отрисованы. Узлы с правилом <code>visibility: hidden</code> включены в дерево рендера, так как они все равно занимают своё место. Так как мы не указали никаких специальных правил для перезаписи стилей агента по умолчанию, узел <code>script</code> в примере выше также не будет включён в дерево рендера.</p>
+<p>Элементы, которые не должны быть показаны, например, <code>&lt;head&gt;</code>, а так же их дети или любые элементы с <code>display:none</code>, такие как <code>script { display: none; }</code>, не будут включены в дерево рендера, так как они не должны быть отрисованы. Узлы с правилом <code>visibility: hidden</code> включены в дерево рендера, так как они всё равно занимают своё место. Так как мы не указали никаких специальных правил для перезаписи стилей агента по умолчанию, узел <code>script</code> в примере выше также не будет включён в дерево рендера.</p>
 
 <p>Каждый видимый узел имеет свои правила из CSSOM. Дерево рендера содержит все видимые узлы с их содержимым и вычисленными стилями. Стили определяются путём применения всех подходящих правил с использованием <a href="/en-US/docs/Web/CSS/Cascade">CSS каскада.</a></p>
 
diff --git a/files/ru/web/performance/optimizing_startup_performance/index.html b/files/ru/web/performance/optimizing_startup_performance/index.html
index 3358f1b8f4..bbec4006e4 100644
--- a/files/ru/web/performance/optimizing_startup_performance/index.html
+++ b/files/ru/web/performance/optimizing_startup_performance/index.html
@@ -19,9 +19,9 @@ translation_of: Web/Performance/Optimizing_startup_performance
 
 <p>Если вы начинаете ваш проект с нуля, обычно очень легко начать писать код "правильно", делая все изначально асинхронным. Все вычисления при запуски должны выполняться в фоновых потоках, в то время как основной поток должен держаться максимально очищенным от лишних функций. Включайте индикатор прогресса для того, чтобы пользователь знал, что сейчас происходит и не думал, что приложение сломано. В теории, если вы только начинаете разработку приложения - это все должно быть очень просто.</p>
 
-<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 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>