[RU] Fix some typos (#2357)

1 files changed, 3 insertions, 3 deletions

diff --git a/files/ru/web/performance/critical_rendering_path/index.html b/files/ru/web/performance/critical_rendering_path/index.html
index 2153463b89..dd20f81e0d 100644
--- a/files/ru/web/performance/critical_rendering_path/index.html
+++ b/files/ru/web/performance/critical_rendering_path/index.html
@@ -19,7 +19,7 @@ translation_of: Web/Performance/Critical_rendering_path
 
 <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>Построение 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>
 
@@ -27,7 +27,7 @@ translation_of: Web/Performance/Critical_rendering_path
 
 <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>
 
@@ -35,7 +35,7 @@ translation_of: Web/Performance/Critical_rendering_path
 
 <h3 id="Дерево_рендера_Render_Tree">Дерево рендера (Render Tree)</h3>
 
-<p>Дерево рендера охватывает сразу и содержимое страницы, и стили: это место, где DOM и CSSOM деревья комбинируются в одно дерево. Для построения дерева рендера браузер проверяет каждый узел (node) DOM, начиная от корневого (root) и определяет, какие CSS правила нужно присоединить к этому узлу. </p>
+<p>Дерево рендера охватывает сразу и содержимое страницы, и стили: это место, где DOM и CSSOM деревья комбинируются в одно дерево. Для построения дерева рендера браузер проверяет каждый узел (node) DOM, начиная от корневого (root) и определяет, какие CSS-правила нужно присоединить к этому узлу. </p>
 
 <p>Дерево рендера охватывает только видимое содержимое. Например, секция head (в основном) не содержит никакой видимой информации, а потому может не включаться в дерево. Кроме того, если у какого-то узла стоит свойство <code>display: none</code>,  оно так же не включается в дерево (как и потомки этого узла).</p>