path: root/files/ru/web/performance/fundamentals/index.html

---
title: Основы производительности
slug: Web/Performance/Fundamentals
tags:
  - Apps
  - Firefox
  - Gecko
  - Guide
  - Performance
  - Производительность
translation_of: Web/Performance/Fundamentals
original_slug: Web/Performance/Основы
---
<div class="summary">
<p><span class="seoSummary">Английское слово Performance, которое используется в статьях о производительности приложений, также можно перевести, как "эффективность". Этот документ объясняет основы производительности, того как браузеры помогают улучшить её и какие инструменты и процессы вы можете использовать, чтобы её улучшить. </span></p>
</div>

<h2 id="Что_такое_производительность">Что такое производительность?</h2>

<p>Ощущаемая пользователем "производительность" - это единственная производительность, которая имеет значение. Пользователи взаимодействуют с системой с помощью ввода каких-то данных: прикосновений, движения и речи. В ответ, они получают реакцию, основанную на зрительном, тактильном или слуховом аппаратах. Производительность - это качество того, как система реагирует на действия пользователя.</p>

<p>При прочих равных, код, оптимизированный для каких-то иных целей, кроме ощущаемой пользователем производительности (здесь и дальше UPP, user-perceived performance) всегда проигрывает коду, который оптимизирован для UPP. Упрощённо говоря, пользователи предпочитают отзывчивое и плавное приложение, которое обрабатывает 1,000 транзакций к базе данных в секунду грубому неотзывчивому приложению, которое обрабатывает 100,000,000 запросов в секунду. Конечно, это не означает, что другие метрики становятся ненужным, но первой вашей целью должна быть UPP.</p>

<p>Следующие разделы укажут и объяснят некоторые метрики производительности:</p>

<h3 id="Отзывчивость">Отзывчивость</h3>

<p>Отзывчивость - это то, как быстро система предлагает ответ (или множество ответов) на запрос пользователя. Например, когда пользователь нажимает на экран, он ожидает, что пиксели под пальцем изменятся каким-то образом. Для этого случая взаимодействия хорошей метрикой будет время, которое прошло между моментом нажатия и изменением пикселей.</p>

<p>Отзывчивость иногда включает в себя несколько этапов. Запуск приложения - один из важнейших этапов. Мы обсудим его ниже.</p>

<p>Отзывчивость важна просто потому, что пользователи теряются и злятся, когда их игнорируют. Ваше приложение игнорирует пользователя каждую секунду, когда оно не отвечает на пользовательский ввод.</p>

<h3 id="Частота_кадров">Частота кадров</h3>

<p>Частота кадров - это частота, с которой система перерисовывает пиксели, отображаемые пользователю. Это знакомая концепция: каждый предпочитает, скажем, игры, которые работают в режиме 60 кадров в секунду играм, которые работают с частотой 10 кадров в секунду. Даже если они не смогут объяснить причины этого.</p>

<p>Частота кадров важна примерно так же, как "качество обслуживания". Дисплеи устройств спроектированы так, чтобы обманывать глаза пользователей, доставляя фотоны света так, чтобы изображение было похожим на реальное. Например, бумага, покрытая напечатанными буквами, отражает фотоны определённым образом. Манипулируя рендерингом, приложения-читалки пытаются отправить фотоны похожим образом, обманывая глаза.</p>

<p>Ваш мозг знает, что движение - это не отрывчатый или дискретный процесс, а плавный и последовательный. Дисплей устройств с высокой частотой кадров сделаны просто для того, чтобы сделать эту иллюзию более реальной. (Интересно, что стробоскопы переворачивают эту концепцию, заставляя наш мозг создавать иллюзию дискретной реальности).</p>

<div class="note">
<p><strong>Заметка</strong>: люди обычно не могут почувствовать разницу между частотами кадров выше 60Hz. По этой причин большая часть современных электронных дисплеев спроектированы для обновления картинки с такой частотой.  Однако, для некоторых живых существ такая частота кадров будет казаться замедленной. Например, для колибри.</p>
</div>

<h3 id="Использование_памяти">Использование памяти</h3>

<p>Использование памяти - это отдельная ключевая метрика. В отличии от отзывчивости и частоты кадров, пользователи не могут напрямую почувствовать использование памяти, но её использование влияет на "состояние пользователя". Идеальная система будет поддерживать 100% состояния всех приложений всё время: все приложения будут запускаться одновременно, а каждое приложение будет возвращаться к состоянию, которое было в последний раз, когда пользователь с ним взаимодействовал (состояние приложения хранится в компьютерной памяти - поэтому это сравнение его с user state довольно точное).</p>

<p>Отсюда следует одно неочевидное заключение: <u>хорошо спроектированная система не заботится об увеличении свободной памяти.</u> <strong>Память - это ресурс,</strong> а свободная память - неиспользуемый ресурс. Наоборот, хорошо спроектированная система использует достаточно много памяти, чтобы обеспечить такое состояние, когда пользователь не чувствует изменений в производительности.</p>

<p>Это не означает, что система должна тратить память. Когда система использует больше памяти, чем это необходимо для поддержания состояния приложения - она тратит память. В этом случае, другое приложение (или даже другое состояние), которые могли бы использовать эту память - не могут её использовать. На практике, ни одна система не может поддерживать в памяти все состояния одновременно. Разумное распределение памяти, достаточное для поддержки состояния приложения - это важная проблема, которую мы рассмотрим позже.</p>

<h3 id="Использование_энергии">Использование энергии</h3>

<p>Последний показатель, который нужно упомянуть - это потребление энергии. Подобно использованию памяти, пользователь чувствует потребление памяти опосредованно, отмечая время, через которое устройство начинает изменять воспринимаемую пользователем производительность (UPP). Для минимизации отрицательных эффектов использования энергии, мы должны делать систему экономной.</p>

<p>Для примера, вспомните, как работают мобильные устройства: вы можете включить режим энергосбережения, когда отключаются другие системы. Но есть и более жёсткий режим, который включается автоматически, когда заряд уменьшается до 5% - система включает троттлинг процессора, замедляя выполнение всех инструкций.</p>

<p>Всю оставшуюся часть статьи мы будем обсуждать производительность в свете этих показателей.</p>

<h2 id="Оптимизация_платформы">Оптимизация платформы</h2>

<p>В этой секции приводится краткий обзор того, как Firefox/Gecko вкладывается в производительность в целом, не заостряя внимание на конкретных приложениях. Для разработчиков и пользователей это будет вопрос на ответ "Как платформа помогает мне?".</p>

<h3 id="Web_технологии">Web технологии</h3>

<p>Web платформа предоставляет много инструментов, некоторые из которых лучше подходят для конкретных задач, а некоторые - хуже. Логика приложений пишется на JavaScript. Для отображения графики разработчики могут использовать HTML или CSS (т.е. используются высокоуровневые декларативные языки); разработчики также могут использовать низкоуровневые интерфейсы, доступные в {{ htmlelement("canvas") }} (включая <a href="/en-US/docs/Web/WebGL">WebGL</a>). Где-то между HTML/CSS и Canvas лежит <a href="/en-US/docs/Web/SVG">SVG</a>, который предлагает некоторые преимущества обеих систем.</p>

<p>HTML и CSS значительно увеличивают производительность, иногда снижая частоту кадров и не давая контролировать каждый пиксель при рендере. Текст и изображения перерисовываются автоматически, UI-элементы автоматически получают системную тему, а система предоставляет некоторую "встроенную" поддержку для некоторых случаев, о которых разработчик может и не задумываться изначально. Например, отображение контента при разных разрешениях.</p>

<p>Элемент Холст (<code>canvas</code>) предоставляет прямой доступ к пиксельному буферу, где разработчик может рисовать.Это даёт разработчику возможность контролировать каждый пиксель во время рендеринга, точно контролировать частоту кадров; но тогда разработчик должен иметь в виду работу с большим количеством разрешений экранов и ориентаций; RTL языками и т.д. Разработчики, работающие напрямую с холстами, используют либо знакомое 2D API, либо API WebGL, достаточно "близкий к железу" и по большей части придерживающийся OpenGL ES 2.0.</p>

<div class="note">
<p><strong>Заметка: </strong>Firefox OS оптимизирована для работы с приложениями, основанными на Web технологиях: <a href="/en-US/docs/Web/HTML">HTML</a>, <a href="/en-US/docs/Web/CSS">CSS</a>, <a href="/en-US/docs/Web/JavaScript">JavaScript</a> и т.д. За исключением некоторых базовых служб операционной системы, весь код Firefox OS пришёл из Web приложений и движка Gecko. Даже оконный менеджер операционной системы написан на HTML, CSS и JavaScript. В связи с тем, что ядро операционной системы написано  на этих технологиях, было критически важно соблюсти производительность этих технологий. В Firefox OS не может быть какого-то "запасного выхода". И это очень полезно для разработчиков, потому что теперь сторонние приложения могут использовать все преимущества оптимизации операционной системы. Не существует какого-то "магического зелья производительности", доступного только для предустановленных приложений.</p>

<p>См. <a href="/en-US/docs/Archive/B2G_OS/Firefox_OS_apps/Performance/Firefox_OS_performance_testing">Тестирование производительности Firefox OS</a> для подробностей.</p>
</div>

<h3 id="Как_рендерит_Gecko">Как рендерит Gecko</h3>

<p>Движок Gecko JavaScript поддерживает just-in-time (JIT) компиляцию. Благодаря этому, логика приложения выполняется примерно так же, как это происходит в других приложениях на виртуальных машинах - например, Java Virtual Machines - а в некоторых случаях эффективность этих приложений близка к "нативному коду".</p>

<p>Инструменты, необходимые для работы с HTML, CSS и Canvas оптимизированы несколькими путями. Например, композиция (этап, известный как Layout) в HTML/CSS и код, отвечающий за графику в Gecko, сделаны таким образом, чтобы уменьшить количество операций ревалидации и перерисовки для общих случаев (например, скроллинг); эти оптимизации включены "по умолчанию", поэтому разработчики пользуются ими бесплатно. Буферы пикселей, отрисованных как для Gecko "автоматически", так и для <code>canvas</code> "вручную", минимизируют количество копий, которые передаются в буфер кадров дисплея. Чтобы достичь этого, Gecko старается избегать создания промежуточных слоёв (например, во многих других операционных системах создаются пиксельные фоновые буферы для каждого отдельного приложения), но взамен Gecko использует специальные участки памяти для хранения графических буферов. К этой памяти имеет прямой доступ железо, которое ответственно за формирование картинки. Сложные сцены рендерятся с использованием графического адаптера (видеокарты). А простые сцены, для экономии энергии, рендерятся специальным выделенным железом для композиции, в то время, как графический адаптер находится в режиме ожидания или выключен.</p>

<p>Для продвинутых приложений полностью статичный контент скорее является исключением, чем правилом. Такие приложения используют динамический контент, анимируемый с помощью {{ cssxref("animation") }} и {{ cssxref ("transition") }}. Переходы и анимации особенно важны для приложений: разработчики могут использовать CSS для объявления сложного поведения с помощью простого высокоуровнего синтаксиса. С другой стороны, движок Gecko хорошо оптимизирован для того, чтобы рендерить такую анимацию эффективно. В целом, общепринятые анимации передаются к обработке системному компоновщику, который может отрендерить их в эффективном, энергосберегающем режиме. </p>

<p>Производительность запуска приложения так же важна, как и её текущая производительность. Gecko оптимизирован для того, чтобы загружать разнообразный контент эффективно: ведь Gecko впитал в себя опыт всего Web-а! Много лет Web улучшался, а разработчики улучшали его контент. Параллельный парсинг HTML, разумное выстраивание очереди перерисовки и декодирования изображений, умные алгоритмы компоновки и т.д.. Все эти оптимизации, конечно, улучшают и производительность Firefox OS.</p>

<div class="note">
<p><strong>Заметка:</strong> смотрите <a href="/en-US/docs/Archive/B2G_OS/Firefox_OS_apps/Performance/Firefox_OS_performance_testing">Тестирование производительности Firefox OS</a> для дополнительной информации о Firefox OS спецификациях, которые помогают оптимизировать производительность запуска.</p>
</div>

<h2 id="Производительность_приложений">Производительность приложений</h2>

<p>Эта секция попытается ответить на вопрос "как сделать приложение быстрее?".</p>

<h3 id="Скорость_загрузки">Скорость загрузки</h3>

<p>Загрузка приложения может быть поделена на три этапа, которые влияют на UPP:</p>

<ul>
 <li>Первая отрисовка. Момент, когда приложение загрузило достаточно данных и ресурсов, чтобы отрисовать первый - начальный - кадр</li>
 <li>Начало интерактивности - например, когда пользователю становится доступна возможность нажать кнопку, а приложение может ему ответить</li>
 <li>Полная загрузка - например, когда все пользовательские альбомы перечислены в музыкальном плеере</li>
</ul>

<p>Секрет быстрой загрузки требует двух вещей: UPP (ощущаемая пользователем скорость) - это единственное, что имеет значение; эта скорость зависит от критического пути рендеринга (Critical Rendering Path). Критический путь - это единственный и необходимый код, который должен запускать перечисленные выше события.</p>

<p>Например, отрисовка первого кадра, который содержит в себе необходимый HTML и CSS включает:</p>

<ol>
 <li>Браузер должен спарсить HTML</li>
 <li>DOM должен быть построен для этого HTML</li>
 <li>Ресурсы (изображения, видео и др.) для этой модели DOM должны быть загружены и декодированы</li>
 <li>CSS стили должны быть применены к DOM и должен быть сформирован CSSOM</li>
 <li>Стилизованный компонент должен быть подготовлен к рендеру</li>
</ol>

<p>В этом списке вы не увидите "загрузить JS файл, который нужен для второстепенного меню", "забрать и декодировать изображения для списка достижений" и т.п. Эта работа не должна выполняться при запуске приложения.</p>

<p>Звучит очевидно, но для достижения лучшей воспринимаемой скорости загрузки нужно запускать только тот код, который необходим и критичен для запуска приложения. Короткий путь увеличивает скорость.</p>

<p>Web-платформа очень динамична. JavaScript - это динамически типизированный язык, а Web разрешает загружать код, HTML, CSS, изображения и другие ресурсы динамически. Эти функции могут быть использованы для того, чтобы отложить загрузку ресурсов; чтобы сократить критический путь, подвинув загрузку лишнего контента на несколько моментов позже. Такой подход называется "ленивой загрузкой".</p>

<p>Другая проблема, которая может привести к ненужному простою - это ожидание ответа на запросы (например, запрос к базе данных). Чтобы избегать этой проблемы, приложение должно запрашивать данные как можно раньше, ещё во время запуска программы. Тогда к моменту, когда данные понадобятся - они уже будут в системе и приложению не придётся ждать.</p>

<div class="note">
<p><strong>Заметка: </strong>Для дополнительной информации об ускорении запуска ознакомьтесь с <a href="/en-US/Apps/Developing/Performance/Optimizing_startup_performance">Optimizing startup performance</a>.</p>
</div>

<p>Следует также отметить, что ресурсы, закешированные локально, могут быть загружены гораздо быстрее, чем динамические данные, загруженные через мобильную сеть с её задержками или узким каналом. Локальное кеширование и работа в оффлайне могут быть достигнуты с помощью <a href="/en-US/docs/">Service Workers</a>. См. <a href="/en-US/docs/Web/Progressive_web_apps/Offline_Service_workers">Making PWAs work offline with Service workers</a> для подробностей.</p>

<h3 id="Частота_кадров_2">Частота кадров</h3>

<p>Первая важная вещь для высокой частоты кадров - это выбор правильного инструмента. Используйте HTML и CSS для создания контента, который будет в основном статическим, прокручиваемым и редко анимируемым. Используйте Canvas для создания высокодинамичного контента, например, игр, которые требуют серьёзного контроля рендеринга и не нуждаются в темах.</p>

<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>Множество приложений используют Transitions и Animations для перехода между страницами или панелями. Например, когда пользователь нажимает кнопку "Настройки", чтобы перейти на другой экран; или для вызова поп-апа. Firefox оптимизирован для выполнения переходов и анимаций для сцен, которые:</p>

<ul>
 <li>Используют страницы/панели равные по размеру дисплею или меньше</li>
 <li>Используют для переходов/анимаций свойства <code>Transform</code> и <code>Opacity</code></li>
</ul>

<p>Переходы и анимации, которые придерживаются этих правил, будут выгружены в системный компоновщик и выполнены максимально эффективно.</p>

<h3 id="Использование_памяти_и_энергии">Использование памяти и энергии</h3>

<p>Проблема улучшения использования памяти и энергии так же важна для ускорения запуска: не делайте ненужную работу и не загружайте ненужные ресурсы. Используйте эффективные структуры данных и уделяйте внимание оптимизации ресурсов.</p>

<p>Современные ЦПУ могут работать в режиме энергосбережения, когда они не задействованы. Приложения, которые постоянно запускают таймеры или продолжают ненужные анимации, мешают процессору перейти в режим энергосбережения. Эффективные приложения не должны так делать.</p>

<p>Когда приложение переходит в фоновый режим, срабатывает событие  {{event("visibilitychange")}}. Это событие - друг разработчика. Приложения должны слушать его и реагировать на него. Например, в Firefox OS, приложения, которые умеют ограничивать использование ресурсов и экономят память, когда переходят в фоновый режим, с меньшей долей вероятности будут отключены (см. заметку ниже). Это, если посмотреть с другой стороны, означает, что раз приложение не было выгружено - оно будет быстрее загружено.</p>

<div class="note">
<p><strong>Заметка:</strong> Как было упомянуто выше, Firefox OS пытается сохранить как можно больше приложений, но иногда вынуждена приостанавливать некоторые из них. Обычно это происходит, когда у устройства заканчивается память. Чтобы узнать больше о том, как Firefox OS управляет памятью и избавляется от приложений, когда начинаются проблемы с памятью, читайте <a href="/en-US/docs/Archive/B2G_OS/Debugging/Debugging_OOMs">Debugging out of memory errors on Firefox OS</a>.</p>
</div>

<h3 id="Советы_к_применению_в_коде">Советы к применению в коде</h3>

<p>Следующие советы помогут вам улучшить один или несколько факторов производительности, которые мы обсуждали ранее.</p>

<h4 id="Используйте_CSS_animation_и_transition">Используйте CSS animation и transition</h4>

<p>Вместо использования функции  <code>animate()</code> какой-нибудь библиотеки, которая, вероятно, использует много плохих решений (например ({{domxref("window.setTimeout()")}} или анимирование top / left), используйте <a href="/en-US/docs/Web/Guide/CSS/Using_CSS_animations">CSS анимации</a>. Во многих случаях, вы можете использовать <a href="/en-US/docs/Web/Guide/CSS/Using_CSS_transitions">CSS Transitions</a>. Использование этих свойств поможет, так как браузер спроектирован так, чтобы оптимизировать эти эффекты и переносить часть вычислений на GPU, чтобы они работали плавно и с минимальным влиянием на процессор. Другое преимущество - вы можете определить эти анимации в CSS декларативным образом, а не в бизнес-логике приложения.</p>

<p>CSS анимации дают вам очень точный контроль эффектов, если вы используете <a href="/en-US/docs/Web/CSS/@keyframes">keyframes</a>. Более того, вы сможете отслеживать события, которые происходят во время анимации, так как основной поток обработки не блокируется. Вы можете с лёгкостью запускать анимации с помощью {{cssxref(":hover")}}, {{cssxref(":focus")}} или {{cssxref(":target")}}. Или динамически добавляя или удаляя классы элемента.</p>

<p>Если вы хотите создавать анимации "на лету" или изменять их с помощью JavaScript, Джеймс Лонг написал простую библиотеку для этого - <a href="https://github.com/jlongster/css-animations.js/">CSS-animations.js</a>.</p>

<h4 id="Используйте_CSS_трансформацию">Используйте CSS трансформацию</h4>

<p>Вместо того, чтобы изменять абсолютное позиционирование и возиться с этой математикой вручную, используйте свойство {{cssxref("transform")}}, чтобы изменить позицию, масштаб и некоторые другие аспекты вашего контента. Именно так вы используете аппаратное ускорение. Браузер умеет передавать такие задачи графическому процессору, давая возможность ЦПУ заняться другими важными вещами.</p>

<p>К тому же, трансформация даёт возможности, которых в ином случае у вас не было бы. Вы не только можете манипулировать элементом в двумерном пространстве, но можете трансформировать его в 3D, изменять его наклон (скашивать, skew), поворачивать и др. Пол Айриш опубликовал статью <a href="https://paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/">in-depth analysis of the benefits of <code>translate()</code></a>, в которой проанализировал работу translate с точки зрения производительности. Используя translate/transform вы используете правильный декларативный инструмент и возлагаете ответственность за его оптимизацию на браузер. Вы так же получаете возможность с лёгкостью позиционировать элементы. Если вы будете использовать только <code>top</code> и <code>left</code>, вам придётся написать некоторый дополнительный код, чтобы предусмотреть некоторые особенности такого позиционирования. И последний бонус - с Transform / Translate вы будете работать примерно так же, как работали бы с элементом <code>canvas</code>.</p>

<div class="note">
<p><strong>Заметка:</strong> В некоторых случаях (в зависимости от платформы) вам может понадобиться добавить свойство <code>translateZ(0.1)</code>, если вы хотите заставить клиента перенести вычисление анимаций на графический адаптер. Как было упомянуто выше, это может улучшить производительность, но увеличит потребление памяти. Какое из зол - меньшее - решать вам. Протестируйте оба варианта и выясните, что лучше подходит для вашего приложения.</p>
</div>

<h4 id="Используйте_requestAnimationFrame_вместо_setInterval">Используйте <code>requestAnimationFrame()</code> вместо <code>setInterval()</code></h4>

<p>Вызовы {{domxref("window.setInterval()")}} запускают код с учётом предполагаемой частоты кадров. Однако, эта ожидаемая частота и фактическая не всегда совпадают. SetInternal говорит браузеру "нарисуй результаты", даже если браузер не занимается сейчас отрисовкой - такое случается, когда графический адаптер ещё не дошёл до следующего цикла обновления экрана. Такое несовпадение таймингов - чрезмерная растрата процессорного времени и даже может приводить к снижению срока службы аккумуляторов пользовательского устройств.</p>

<p>Вместо этого, вам необходимо использовать {{domxref("window.requestAnimationFrame()")}}. Эта функция ждёт, пока клиент не будет готов к формированию следующего кадра анимации и не будет досаждать своими запросами аппаратную часть устройства, если устройство не занимается в данный момент рендерингом. Другое преимущество этого API в том, что такие анимации не будут запускаться, пока ваше приложение не видно на экране (например, если оно выполняется в фоне или занимается другими операциями). Это сохранит батарею и защитит вас от проклятий, которые пользователи будут выкрикивать в небо.</p>

<h4 id="Делайте_события_мгновенными">Делайте события мгновенными</h4>

<p>Как старомодные, заботящиеся о доступности веб-разработчики, мы любим событие нажатия, так как оно также срабатывает и для ввода с клавиатуры. На мобильных устройствах это работает иначе. Вы должны использовать {{event("touchstart")}} и {{event("touchend")}}, а не click. Причина этому - в мобильных устройствах срабатывает задержка в несколько сотен миллисекунд между касанием экрана и запуском обработчика click. Из-за этого приложение может ощущаться медленным. Если вы будете тестировать ваше приложение на предмет работы с касаниями, вы не пожертвуете доступностью. Кроме того, существуют библиотеки, которые ускорят разработку. Например, Financial Times использует библиотеку <a href="https://github.com/ftlabs/fastclick">fastclick</a> для обработки.</p>

<h4 id="Держите_интерфейс_простым">Держите интерфейс простым</h4>

<p>Одна из самых больших проблем, которую мы нашли в HTML5 приложениях, заключается в том, что перенос большого количества <a href="/en-US/docs/DOM">DOM</a> элементов делает приложение медленным - особенно, если в этих элементах много градиентов и теней. Упрощайте то, как выглядит ваше приложение и передвигайте проксирующий элемент, когда выполняете Drag And Drop - это сильно ускорит работу.</p>

<p>Когда, например, у вас есть большой список элементов (скажем, твитов), не перемещайте их все. Вместо этого, держите в вашем DOM-дереве только те элементы, которые видимы и несколько за областью видимости, чтобы при скролле не было заметно моргание. Остальные - прячьте. Сохраняйте данные в JavaScript объектах, вместо хранения данных и доступа к ним в DOM. Думайте об экране, как об устройстве представления необходимых данных, а не всех. Это не означает, что вы не можете использовать HTML, как источник данных; просто читайте его один раз, а затем продвигайтесь на 10 элементов, изменяя содержимое первого и последнего элемента, согласно их позициям в списке, вместо того, чтобы двигать 100 элементов, которые уже невидимы. Подобный трюк сработает и в играх со спрайтами: если они не видны на экране, нет необходимости запрашивать их. Вместо этого переиспользуйте элементы, которые выходят за пределы экрана, в то время как новые входят.</p>

<h2 id="Общий_анализ_производительности">Общий анализ производительности</h2>

<p>Firefox, Chrome и другие браузеры предоставляют встроенные инструменты, которые могут помочь вам диагностировать медленный рендеринг. В частности, <a href="/en-US/docs/Tools/Network_Monitor">Firefox's Network Monitor</a> покажет точное время, когда произошёл каждый сетевой запрос, насколько большим он был и как долго обрабатывался.</p>

<p><img alt="The Firefox network monitor showing get requests, multiple files, and different times taken to load each resource on a graph." src="https://mdn.mozillademos.org/files/6845/network-monitor.jpg" style="display: block; height: 713px; margin: 0px auto; width: 700px;"></p>

<p>Если на вашей странице есть JavaScript, который выполняется очень долго, <a href="/en-US/docs/Tools/Profiler">JavaScript profiler</a>  укажет на наиболее медленные строки кода.</p>

<p><img alt="The Firefox JavaScript profiler showing a completed profile 1." src="https://mdn.mozillademos.org/files/6839/javascript-profiler.png" style="display: block; height: 433px; margin: 0px auto; width: 896px;"></p>

<p>Встроенный<a href="/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler"> Gecko Profiler</a> - очень полезный инструмент, который позволяет вам получить ещё более подробную информацию о том, какие части кода работают медленно. Это довольно сложный инструмент, но он предоставляет множество деталей.</p>

<p><img alt="A built-in Gecko profiler windows showing a lot of network information." src="https://mdn.mozillademos.org/files/6837/gecko-profiler.png" style="display: block; height: 514px; margin: 0px auto; width: 896px;"></p>

<div class="note">
<p><strong>Заметка:</strong> Вы можете использовать эти инструменты и в Android браузере, запустив Firefox и включив <a href="/en-US/docs/Tools/Remote_Debugging">remote debugging</a>.</p>
</div>

<p>Например, множественные сетевые запросы в мобильной сети занимают больше времени. Рендеринг больших изображений и CSS градиентов может происходить дольше. Простое скачивание больших изображений может занять большее время, даже через быструю сеть, так как аппаратная часть мобильных устройств зачастую слишком медленна, чтобы использовать все возможности быстрых каналов данных. Для получения полезных подсказок о производительности на мобильных устройствах, ознакомьтесь с докладом Максимилиано Фёртмана <a href="http://www.slideshare.net/firt/mobile-web-high-performance">Mobile Web High Performance</a>.</p>

<h3 id="Тестовые_кейсы_и_сообщения_об_ошибках">Тестовые кейсы и сообщения об ошибках</h3>

<p>Если инструменты разработчика в Firefox или Chrome не помогают вам выяснить проблему или выглядит так, что браузеры сами по себе создают проблему, попробуйте сформировать тестовое окружение, которое максимально изолирует проблему. Это очень часто помогать диагностировать проблему.</p>

<p>Убедитесь, что вы можете воспроизвести проблему, просто сохраняя и загружая статическую копию HTML-страницы (включая изображения/стили/скрипты). Если так - удалите из HTML файла всю личную информацию и обратитесь к за помощью (отправьте отчёт в <a href="https://bugzilla.mozilla.org/">Bugzilla</a> или, например, сохраните файл на своём сервере и поделитесь ссылкой). Вам также понадобится поделиться информацией профилировщика, которую вы собрали с помощью инструментов отладки.</p>