Restore "ё" letter in Russian translation (#239)

* docs(ru): restore ё letter

* docs(ru): resolve conflicts

* refactor(idea): remove ide folder

1 files changed, 5 insertions, 5 deletions

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>