[Перевод] Годовой отчет по оптимизации производительности внешнего интерфейса за 2019 г. — Часть 1

внешний интерфейс JavaScript Программа перевода самородков

Пусть 2019 год наступит быстрее~ Вы читаете ежегодный отчет по оптимизации производительности внешнего интерфейса за 2019 год, который начался в 2016 году.

О чем мы говорим, когда говорим о производительности переднего плана?узкое место производительностив конце концовГде?是昂贵的 JavaScript 开销，耗时的网络字体下载，超大的图片还是迟钝的页面渲染？摇树（tree-shaking）、作用域提升（scope hoisting）、代码分割（code-splitting），以及各种酷炫的加载模式，包括交叉观察者模式（intersection observer）、服务端推送（server push）、客户端提示（clients hints）、HTTP/2、service worker 以及 edge worker，研究这些真的有用吗？还有，最重要的，当我们着手处理前端性能的时候，с чего мы начнем, как установить долгосрочную систему оптимизации производительности?

Раньше производительность была вся так называемая"волноваться". К концу проекта все сводилось бы к минимизации кода, конкатенации, оптимизации статических активов и нескольким настройкам конфигурации сервера. Оглядываясь назад, кажется, что это совсем другая история.

Проблемы с производительностью — это не только технические соображения, их также необходимо учитывать при принятии проектных решений при интеграции в рабочие процессы.Производительность должна постоянно обнаруживаться, контролироваться и оптимизироваться. В то же время сеть становится все более сложной, что создает новые проблемы, и простое отслеживание метрик уже невозможно, потому что разные устройства, браузеры, протоколы, типы сетей и задержки могут значительно различаться по метрикам. (CDN, интернет-провайдеры, кэши, прокси, брандмауэры, балансировщики нагрузки и серверы — все это необходимо учитывать.)

Итак, если мы хотим охватить все пункты по улучшению производительности — от самого начала до финального запуска сайта, то каким должен быть окончательный список? Вот копия (надеюсь непредвзятая и объективная)Годовой отчет по оптимизации производительности интерфейса пользователя за 2019 г., «Новая версия корабля, которого вы еще не видели», он включает в себя почти все моменты, которые необходимо учитывать, чтобы убедиться, что время отклика вашего веб-сайта достаточно короткое, пользовательский интерфейс достаточно плавный и в то же время не истощать полосу пропускания пользователя.

содержание

Начало работы: планы и показатели

Для последовательного отслеживания производительности «микрооптимизация» — хорошая идея, но также необходимо иметь в виду четкую цель —квантованныйЦели влияют на все решения, принимаемые в процессе. Есть много разных моделей, на которые вы можете ссылаться, следующее обсуждение основано на моих личных субъективных предпочтениях, пожалуйста, отрегулируйте его в соответствии с вашей личной ситуацией.

1. Установите спецификации оценки эффективности

Во многих организациях разработчики интерфейса точно знают, как возникают наиболее вероятные проблемы и какой режим следует использовать для их устранения. Однако из-за отсутствия культуры оценки эффективности каждое решение станет полем битвы между отделами, организация раскололась на бункеры. Чтобы получить поддержку заинтересованных сторон бизнеса, вам нужно проиллюстрировать конкретный случай: как страница повлияет на скорость и бизнес-показатели, которые их волнуют.KPI.

Без полного сотрудничества команд разработки, дизайна, бизнеса и маркетинга оптимизация производительности не продвинется далеко. Изучите распространенные проблемы, на которые жалуются пользователи, и узнайте, как оптимизация производительности может помочь их решить.

Запускайте тесты производительности как на мобильных, так и на настольных устройствах, чтобы получить индивидуальные тематические исследования на основе реальных данных компании. Кроме того, вы также можете обратиться кWPO StatsИспользуйте тематические исследования оптимизации производительности и экспериментальные данные, представленные выше, чтобы повысить свою чувствительность к оптимизации производительности, понять, почему производительность так важна и как она влияет на взаимодействие с пользователем и бизнес-показатели. Недостаточно понимать, что производительность имеет значение, вы должны ставить измеримые, отслеживаемые цели и следить за их выполнением.

Так как именно? Назван в Эллисон МакнайтBuilding Performance for the Long TermВ своей презентации она подробно рассказала, как она построила культуру оценки эффективности на Etsy.кейс.

Brad Frost and Jonathan Fielding’s Performance Budget Calculator

Брэд ФростPerformance budget builderс Джонатаном ФилдингомPerformance Budget CalculatorПомогает устанавливать и визуализировать бюджеты производительности. (предварительный просмотр)

2. Цель: быть как минимум на 20% быстрее своего самого быстрого конкурента.

согласно спсихологическое исследование, если вы хотите, чтобы ваши пользователи чувствовали, что ваш сайт быстрее ваших конкурентов, то вам нужно быть быстрее ихПо меньшей мере20%. Изучите своих основных конкурентов, соберите показатели производительности их сайтов на мобильных устройствах и компьютерах и определите минимальные требования, которые выходят за их пределы. Чтобы получить точные результаты и цели, сначала изучите поведение пользователей вашего продукта, а затем протестируйте его, имитируя поведение 90% пользователей.

Чтобы лучше понять производительность вашего оппонента, вы можете использоватьChrome UX Report(CrUX, набор готовых наборов данных RUM,Видео-вступление Ильи Григорика),Speed Scorecard(Вы также можете оценить, как оптимизация производительности повлияет на доход),Сравнение тестов реального взаимодействия с пользователемилиSiteSpeed CI(на основе интеграционных тестов).

Уведомление: если вы используетеPage Speed Insights(да, это еще не заброшено), вы можете получить подробные данные о производительности CrUX для конкретных страниц, а не только какие-то грубые сводные данные. Эти данные могут быть полезны при настройке целей производительности для определенных страниц, таких как «Главная», «Страницы со списком товаров». Кроме того, если вы используете CI для мониторинга бюджетов производительности, при использовании CrUX для установления целей вам необходимо убедиться, что тестовая среда соответствует CrUX. (Спасибо, Патрик Минан!)

собирать данные, строитьлист, сократите 20%, чтобы установить свою цельбюджет производительности. Итак, теперь у вас есть количественный контрольный образец. Постепенно дела идут в правильном направлении, если вы всегда помните об этом бюджете и каждый раз предоставляете как можно меньше кода, чтобы сократить время взаимодействия.

Нужна информация, чтобы начать?

После того, как вы установили соответствующий бюджет производительности, вы можете использоватьWebpack Performance Hints and Bundlesize,Lightouse CI, PWMetrics,Sitespeed CIИнтегрируйте их в процесс упаковки, применяйте бюджеты производительности при запросе на слияние и отмечайте оценку в комментариях PR. Если вам нужна персонализация, вы можете использоватьwebpagetest-charts-api, который предоставляет ряд API-интерфейсов, которые могут генерировать графики на основе результатов WebPagetest.

Например, какPinterestНапример, вы можете создать пользовательскийeslintПравила, запрещающие импорт файлов и каталогов с большим количеством зависимостей, чтобы избежать раздувания файлов пакетов. Устанавливает список «безопасных» зависимостей, совместно используемых в команде.

В дополнение к бюджетам производительности тщательно продумайте те ключевые действия пользователей, которые имеют наибольшую ценность для вашего бизнеса. определить и обсудить приемлемыеПороговое значение времени отклика на критические операции, и достичь консенсуса внутри команды в отношении покадровой оценки, «готовой к UX». В большинстве случаев операционный процесс пользователя включает в себя работу многих различных отделов компании, поэтому согласование «временного порога» может способствовать дальнейшему обмену информацией о производительности и избежать ненужных дискуссий. Убедитесь, что вы понимаете накладные расходы на новые ресурсы и функции.

Кроме того, как предложил Патрик Минан, в процессе проектированияПланируйте порядок загрузки и компромиссовабсолютно стоит. Если вы заранее спланируете, какие части важнее, и определите порядок появления каждой части, вы также будете знать, какие части можно загружать отложенно. В идеале этот порядок также должен отражать порядок импорта файлов CSS и JavaScript, чтобы с ними было проще работать на этапе упаковки. В дополнение к этому учитывайте визуальные эффекты промежуточных состояний при загрузке страницы (например, когда веб-шрифты загружены не полностью).

планирование, планирование, планирование. Хотя может показаться заманчивым инвестировать в оптимизацию, которая дает немедленные результаты на раннем этапе, это может быть хорошей стратегией для проектов, требующих быстрых результатов, но производительность трудно гарантировать без прагматичного планирования и локализованных показателей производительности.Расстановка приоритетов всегда ценилась.

Разница между первой отрисовкой, первой отрисовкой с содержанием, первой осмысленной отрисовкой, визуальным завершением и временем до интерактивности.полная документация. Авторские права:@denar90

3. Выберите правильные показатели

Не все показатели одинаково важны. Узнайте, какая метрика наиболее важна для вашего приложения, обычно она должна быть такой же, как при запуске рендеринга.Самые важные пиксели в вашем продуктескорость и время, необходимое для предоставления входного ответа. Этот пункт укажет вам на лучшие цели оптимизации и направит ваши усилия.

В любом случае, не всегда смотрите на время, необходимое для полной загрузки страницы (скажем,onloadа такжеDOMContentLoaded), чтобы посмотреть на загрузку страницы с точки зрения пользователя. Тем не менее, есть немного другой набор показателей, на которых следует сосредоточиться. На самом деле не существует абсолютно идеального решения «выбрать правильную метрику».

Согласно исследованию Тима Кадлека и Маркоса Иглесиаса вего речьКак упоминалось в , традиционные индикаторы можно разделить на несколько типов. Обычно нам нужны все метрики для построения полного профиля производительности, но в некоторых сценариях одни метрики могут быть более важными, чем другие.

  • По количеству показателейИзмеряйте количество запросов, веса, показатели производительности и многое другое. Полезно для оповещения и мониторинга долгосрочных изменений, но не для понимания взаимодействия с пользователем.

  • ВехиИспользуйте различные состояния процесса загрузки для отметки, например:Время до первого байтаа такжеВремя интерактива. Полезно для описания пользовательского опыта и метрик, но не для понимания того, что происходит во время загрузки.

  • показатели рендерингаМожно оценить время рендеринга контента, например.Время начала рендера (Start Render)а такжеИндекс скорости. Полезно для тестирования и настройки производительности рендеринга, но для тестированияважныйКогда контент появляется и когда он интерактивен, мало что помогает.

  • пользовательский индикаторИзмеряйте конкретное персонализированное событие пользователя, напримерВремя для первого твита, ПинтерестЛюбимое время ожидания (PinnerWaitTime). Полезно для точного описания пользовательского опыта, но неудобно для масштабирования и сравнения с конкурирующими продуктами.

Чтобы сделать производительность более полной картины, мы обычно выбираем некоторые полезные показатели всех типов. В общем, самое главное:

  • Первая значимая краска (FMP)

    Отражает время, необходимое для появления основного контента на странице, а также отражает вывод сервера сбоку.Любыескорость данных. Длительное время FMP обычно означает, что JavaScript блокирует основной поток, или это может быть проблема с бэкэндом/сервером.

  • Время до интерактивности (TTI)

    На данный момент макет страницы стабилизировался, основные веб-шрифты видны, а основной поток готов реагировать на пользовательский ввод — в основном это означает, что только пользователь может взаимодействовать с пользовательским интерфейсом. Он описывает, «что нужно пользователям, прежде чем веб-сайт можно будет использовать в обычном режиме.ждатьвремя» является ключевым фактором.

  • Задержка первого ввода (FID или реакция ввода)

    Время с момента, когда пользователь впервые взаимодействует со страницей, до момента, когда веб-сайт может ответить на это взаимодействие. Дополняя TTI, он заполняет недостающую часть картины: что происходит после фактического взаимодействия пользователя с сайтом. Стандартная метрика RUM. есть одинJavaScript-библиотекаПрошедшее время FID можно измерить в браузере.

  • Индекс скорости

    Мера того, как быстро страница визуально заполняется контентом, тем ниже. Индекс скорости рассчитывается из визуальной скорости загрузки и является просто рассчитанным значением. Он также чувствителен к размеру просмотра в области просмотра, поэтому вам нужно обладать проверкой тестовой конфигурации в соответствии с целевым пользователем. (благодарныйBoris! )

  • процессорное время

    Метрика, которая описывает, насколько занят основной поток при обработке полезной нагрузки, показывая, как часто и как долго основной поток блокируется при рисовании, рендеринге, выполнении скриптов и загрузке. Высокое время процессора, очевидно, означает, чтоКатонаПользовательский опыт. С помощью WebPageTest вы можетеВыберите параметр «Capture Dev Tools Timeline» на вкладке «Chrome».чтобы выявить возможные сбои основного потока (поскольку WebPageTest может работать на любом устройстве).

  • Пользовательские показатели

    Пользовательские показатели могут быть специально установлены для конкретных потребностей бизнеса и взаимодействия с пользователем. вам нужноважныйпиксель,Жизненноважныйсценарий,необходимоCSS-стили иСвязанныйСтатические активы имеют четкую концепцию и могут измерять, сколько времени требуется пользователям для их загрузки. Для этого вы можете использоватьHero Rendering TimesилиPerformance API, чтобы создавать временные метки для важных деловых событий. Кроме того, вы можете запустить собственный сценарий после завершения теста WebPageTest.Собирайте пользовательские метрики.

Стив Содерс написалстатьяКаждый индикатор подробно описан. Следует отметить, что время первого взаимодействиялабораторная средаполученный в результате автоматизированного обзора в соответствии среальностьЧто пользователи чувствуют при использованиидействительныйЗадерживать. В общем, было бы неплохо всегда наблюдать и отслеживать эти две метрики.

Разные приложения могут иметь разные предпочтительные индикаторы. Например, для пользовательского интерфейса Netflix TV:Ответ на нажатие клавиш, использование памяти и время до первой интерактивностибыло бы важнее, а для ВикипедииПервые и последние визуальные изменения и показатели процессорного временипокажется более важным.

Уведомление: Ни FID, ни TTI не заботятся о производительности прокрутки. Событие прокрутки может произойти независимо, потому что оно находится вне основного потока. Поэтому для многих сайтов с большим количеством контента эти показатели могут быть не очень важны. (Спасибо, Патрик!).

Ориентированные на пользователя показатели производительности могут помочь лучше понять реальный пользовательский опыт.Задержка первого ввода (FID)是一个尝试去实现这一目标的新指标。 (Нажмите здесь, чтобы узнать подробности)

4. Соберите данные о типичных устройствах целевых пользователей

Для того, чтобы получить точные данные, нам необходимо выбрать соответствующее испытательное оборудование.Moto G4Будет хорошим выбором либо устройство среднего класса от Samsung, либо посредственное устройство, такое как Nexus 5X, и бюджетное устройство, такое как Alcatel 1X. ты сможешьopen device labнайди это. Если вы хотите протестировать на более медленном устройстве, вы можете приобрести Nexus 2 примерно за 100 долларов.

Если у вас нет нужного оборудования, вы можете увеличить скорость передачи по сети (например: 150 мс RTT, 1,5 Мбит/с входящего канала, восходящего канала 0,7 Мбит/с), аналогового мобильного клиента на ПК и скорости процессора (в пять раз медленнее). Затем переключитесь на обычное тестирование сетей 3G, 4G и WIFI. Чтобы сделать влияние на производительность более очевидным, вы можете даже ввести2G вторникили для более удобного тестирования в офисеОграничение сетей 3G.

Всегда имейте в виду: на мобильных устройствах он должен работать в 4-5 раз медленнее, чем на настольных компьютерах. Мобильные устройства имеют разные характеристики GPU, CPU, памяти, батареи. Если медленная сеть ограничивает время загрузки, то более медленный процессор мобильного телефона ограничивает время анализа. На самом деле время парсинга на мобильных устройствах обычно больше, чем на десктопных.на 36% дольше. Поэтому обязательноПроверено на среднем уровне оборудования— Устройство, наиболее точно представляющее ваших пользователей.

Introducing the slowest day of the week

Выберите день недели, чтобы замедлить интернет. у фейсбука есть2G вторникповысить осведомленность о низкоскоростных сетях. (Источник изображения)

К счастью, существует множество инструментов, которые могут помочь вам автоматизировать сбор данных и оценивать тенденции этих показателей производительности с течением времени. Помните, что хороший профиль производительности должен включать в себя полный набор показателей производительности,Экспериментальные данные и фактические данные.

  • инструмент для интеграционного тестированияМожет быть собран в воспроизводимой среде с предварительно заданными конфигурациями устройств и сетей.Экспериментальные данные. Например:Lighthouse,WebPageTest
  • Мониторинг реальных пользователей (RUM)Инструменты могут постоянно оценивать действия пользователей и собирать фактические данные. Например,SpeedCurve,New Relic, оба также предоставляют инструменты для интеграционного тестирования.

бывший встадия разработкиможет быть очень полезным, чтобы помочь вам найти, изолировать и устранить проблемы с производительностью во время разработки. последний вфаза обслуживаниябыло бы полезно помочь вам понять, где находятся узкие места в производительности, поскольку все это реальные данные, созданные пользователями.

Изучив встроенный в браузер RUM API, напримерNavigation Timing,Resource Timing,Paint Timing,Long TasksИ т. д., интеграционные тесты и RUM работают вместе, чтобы создать полную картину производительности. вы можете использоватьPWMetrics,Calibre, SpeedCurve,mPulseа такжеBoomerang,Sitespeed.ioДля мониторинга производительности все они являются хорошим выбором. Кроме того, используйтеServer Timing header, вы даже можете одновременно отслеживать производительность серверной части и интерфейса.

Уведомление: рекомендуется использовать внешний браузерСетевой ограничитель, потому что в DevTools браузера могут быть некоторые проблемы, например: HTTP/2 push может иметь проблемы из-за метода реализации. (Спасибо Йоаву и Патрику!) Для Mac OS мы можем использоватьNetwork Link Conditioner; для Windows вы можете использоватьWindows Traffic Shaper; для Linux вы можете использоватьnetem; для FreeBSD вы можете использоватьdummynet.

Lighthouse

Lighthouse— Инструмент проверки производительности, входящий в состав DevTools.

5. Для тестирования "Чистый", "ПРОФИЛЬНЫЙ"

Обычной практикой при тестировании с помощью инструментов пассивного мониторинга является отключение антивирусного программного обеспечения и фоновых задач ЦП, отключение фоновых сетевых подключений и использование «чистой» конфигурации браузера без установленных плагинов, чтобы избежать искажения результатов. (Firefox,Chrome).

Тем не менее, также полезно знать, какие плагины обычно используют ваши пользователи, а затем использовать хорошо продуманный "рядом с реальными пользователями"проверить конфигурацию браузера. На самом деле, некоторые плагины могут принестиЗначительное влияние на производительность. Если у вас много пользователей, использующих эти плагины, вы можете рассмотреть эти эффекты. Конфигурация браузера «чистого» пользователя может быть слишком идеалистичной и может сильно отличаться от реальности.

6. Поделитесь списком с остальной командой

Убедитесь, что каждый из ваших коллег полностью ознакомлен с этим списком, чтобы впоследствии избежать недоразумений. Каждое решение влияет на производительность, и весь проект в значительной степени выигрывает от того, что фронтенд-разработчики правильно решают проблемы с производительностью, обеспечивая ответственность всех в команде, а не только фронтенда. Принимайте проектные решения на основе бюджета производительности и приоритетов, определенных в контрольном списке.

Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из ИнтернетаНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,товар,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории