aboutsummaryrefslogtreecommitdiff
path: root/files/ru/web/performance/optimizing_startup_performance/index.html
diff options
context:
space:
mode:
Diffstat (limited to 'files/ru/web/performance/optimizing_startup_performance/index.html')
-rw-r--r--files/ru/web/performance/optimizing_startup_performance/index.html8
1 files changed, 4 insertions, 4 deletions
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>