Unify Russian translation of "functionality" (#289)

* Unify Russian translation of "functionality"

* Apply suggestions from code review

Co-authored-by: Sasha Sushko <sushko@outlook.com>

* Update files/ru/learn/server-side/django/forms/index.html

Co-authored-by: Sasha Sushko <sushko@outlook.com>

Co-authored-by: Sasha Sushko <sushko@outlook.com>

3 files changed, 5 insertions, 5 deletions

diff --git a/files/ru/web/performance/dns-prefetch/index.html b/files/ru/web/performance/dns-prefetch/index.html
index 2db1d62980..67dcafa684 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>&lt;link&gt;</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>&lt;link&gt;</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>
 
diff --git a/files/ru/web/performance/performance_budgets/index.html b/files/ru/web/performance/performance_budgets/index.html
index 3c976ccf91..9e773f51a3 100644
--- a/files/ru/web/performance/performance_budgets/index.html
+++ b/files/ru/web/performance/performance_budgets/index.html
@@ -19,7 +19,7 @@ translation_of: Web/Performance/Performance_budgets
 
 <p>Главная цель такого подхода - сокращение регрессии. Но этот подход может помочь предсказать поведение приложения в будущем. Например, в Сентябре 50% месячного бюджета было использовано за неделю - значит, нужно ждать увеличения потребления контента, нагрузки на сервера и т.д.</p>
 
-<p>Кроме того, подход может раскрыть некоторые нужды разработчиков (например, может оказаться, что в финальном коде вашего приложения половину объёма занимает огромная библиотека, из которой вы используете только мизерную часть функционала).</p>
+<p>Кроме того, подход может раскрыть некоторые нужды разработчиков (например, может оказаться, что в финальном коде вашего приложения половину объёма занимает огромная библиотека, из которой вы используете только мизерную часть функциональности).</p>
 
 <h2 id="Как_определить_бюджет">Как определить бюджет?</h2>
 
@@ -30,7 +30,7 @@ translation_of: Web/Performance/Performance_budgets
  <li>Ошибка</li>
 </ul>
 
-<p>Уровень предупреждения позволяет вам быть проактивным и заниматься техническим долгом, не блокируя разработку нового функционала</p>
+<p>Уровень предупреждения позволяет вам быть проактивным и заниматься техническим долгом, не блокируя разработку нового функциональности</p>
 
 <p>Уровень ошибки - это граница, по достижении которой приложение воспринимается негативно.</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 6692991729..07bec3a889 100644
--- a/files/ru/web/performance/rum-vs-synthetic/index.html
+++ b/files/ru/web/performance/rum-vs-synthetic/index.html
@@ -24,7 +24,7 @@ translation_of: Web/Performance/Rum-vs-Synthetic
 
 <p id="Real_User_Monitoring_(RUM)"><strong>Мониторинг реальных пользователей (Real User Monitoring, RUM) </strong>измеряет производительность приложения на устройствах конечных пользователей. В основе подхода - сторонний скрипт, который вставляет другие скрипты на каждую страницу. Эти дополнительные скрипты измеряют производительность и предоставляют отчёты о ней. Этот подход помогает не только узнать, насколько производительно приложение, но и даёт информацию об использовании приложения, например, о географии, распределении пользователей или влиянии такого распределения на пользовательский опыт.</p>
 
-<p>В отличие от синтетического мониторинга, RUM собирает данные от настоящих пользователей, вне зависимости от их устройств, браузеров, сети или геолокации. Пока пользователь взаимодействует с приложением, тайминги такого взаимодействия записываются, вне зависимости от того, какое действие выполняется в конкретный момент. Такой мониторинг собирает данные о реальном использовании приложения, а не о том поведении, которое ожидают разработчики или, скажем, отдел маркетинга. Это особенно важно для больших веб-сайтов или сложных приложений, где функционал или содержимое постоянно меняются, а количество пользователей может очень сильно расти, создавая новые нагрузки и требования.</p>
+<p>В отличие от синтетического мониторинга, RUM собирает данные от настоящих пользователей, вне зависимости от их устройств, браузеров, сети или геолокации. Пока пользователь взаимодействует с приложением, тайминги такого взаимодействия записываются, вне зависимости от того, какое действие выполняется в конкретный момент. Такой мониторинг собирает данные о реальном использовании приложения, а не о том поведении, которое ожидают разработчики или, скажем, отдел маркетинга. Это особенно важно для больших веб-сайтов или сложных приложений, где функциональность или содержимое постоянно меняются, а количество пользователей может очень сильно расти, создавая новые нагрузки и требования.</p>
 
 <p>Используя RUM, бизнес может лучше понять своих клиентов и определить зоны сайта, которые требуют большего внимания. Более того, RUM может помочь понять географию или канал распространения приложения. Знание своих пользователей и трендов поможет вам выстроить бизнес-планы и думать наперёд, позволяя вам определить приоритетные зоны, которые требует оптимизации и улучшения производительности.</p>