Как создать в команде культуру производительности

Как создать в команде культуру производительности

Оригинал: How to create a web performance culture inside your team

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

Разберемся, почему это так важно и о каких рисках идет речь.

Производительность имеет значение

Всегда помните, что главная цель разработчиков – это хороший пользовательский опыт.

Производительность — это юзабилити

Сделано множество исследований ([1][2][3]), которые демонстрируют прямую зависимость между выполнением бизнес-целей в вебе и юзабилити. Быстрый сайт может существенно сдвинуть границу между успехом и неудачей в ваших отношениях с пользователями.

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

Кроме того, производительность является важным показателем в рейтинге мобильных страниц Google.

Производительность — это доступность

Сколько платит пользователь за посещение вашего сайта? Узнать это вы можете здесь. А теперь спросите себя, готовы ли вы заплатить столько за посещение вашего сайта? Возможно, вы будете удивлены своим ответом.

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

Производительность — это понимание

Очень часто мы видим свою работу только своими глазами. Это приводит к поверхностному пониманию потребностей наших пользователей.

Мы постоянно стремимся работать с крутыми вещами (новыми технологиями, фреймворками и т. д.) и игнорируем скучную и утомительную работу.

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

План на худшее

Возьмем для примера веб-сайт домашнего декора, который использует некоторую CMS для управления данными. Кто-то загрузил это изображение:

Оно весит 9,3 мегабайта данных и грузится примерно 7 секунд при сверхбыстром Wi-Fi-соединении на MacBookPro. Представляете, сколько времени это займет на мобильном устройстве? Правильный ответ – бесконечно много! Мобильный браузер просто перестает отвечать на запросы при открытии сайта.

Вот этот веб-сайт, если вам интересно, но, пожалуйста, будьте осторожны, потому что он может заблокировать ваш браузер!

Мы не должны винить пользователя, он просто хотел показать сборку во всех деталях.

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

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

Оптимизация

Существует два подхода к оптимизации производительности. Бен Шварц резюмирует их в своей презентации Критический запрос.

С одной стороны, у нас есть традиционный «Хьюстон, у нас проблема!” подход. Это реактивный путь решения проблем. Его также можно называть: «о, черт! Вызовите консультанта!”.

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

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

Если вам нужны аргументы в пользу второго подхода, ознакомьтесь со статистикой WPO. Это отличный ресурс с тематическими исследованиями, которые показывают преимущества оптимизации производительности.

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

Однако осознание производительности не происходит за одну ночь. Вы должны создать правильный контекст для вашей команды.

Оценка и действия

Вы знаете, сколько пользователей заходят на ваш сайт с мобильных устройств? Как часто вы проводите тесты в условиях плохого соединения? Как часто вы берете устройство среднего класса, например Moto G4, и начинаете играть с вашим приложением?

С этими сценариями ваши пользователи могут сталкиваться каждый день!

Если вы хотите реализовать культуру производительности, нужно знать своих пользователей, их устройства и браузеры.

После этого нужно установить бюджеты производительности.

Наконец, время действовать! Вот некоторые инструменты и практики, которые вы можете внедрить в свою обычную рабочую среду:

Шаг 1: Измерение показателей производительности

  • Lighthouse – это удивительный проект, доступный в Chrome Dev Tools. Он позволит вам понять, как улучшить производительность и даст хорошоие рекомендации по СЕО и доступности.
  • Webpagetest отлично подходит для отслеживания метрик и сравнения каскадных диаграмм до и после развертывания.
  • Есть еще gtmetrix, менее известный инструмент, с очень простым в использовании интерфейсом.

Шаг 2: Автоматизация

  • Добавить измерение производительность в ваш рабочий процесс. bundlesize поможет вам установить жесткие ограничения по размеру для пакетов.
  • Напишите автоматические тесты, которые не будут выполняться, если время загрузки или другие соответствующие метрики превышают определенные пороговые значения.  Вы можете использовать Puppeteer, который имеет прямой доступ к API Chrome.

Шаг 3: Визуализация

  • Каждый член команды должен знать, что происходит в его коде. Webpack bundle analyzer позволяет визуально анализировать, что находится внутри выходных пакетов. Разработчик подумает дважды, прежде чем использовать библиотеку, которая увеличивает размер бандла на 10%.
  • import cost для VSCode покажет, сколько кода вы добавляете в проект с различными зависимостями. Важно убедиться, что все члены команды полностью осознают влияние своих действий на производительность.

Шаг 4: Соблюдение и расширение

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

Построение культуры, ориентированной на производительность, – это пошаговый процесс понимания проблем и их решения.

Есть один постоянный момент: в течение всего этого процесса нужно воспитывать и обучать вашу команду.

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

Построение на прочной основе может помочь вашей команде понять даже самые передовые методы ускорения вашего приложения.

Производительность – составляющая качества ПО

В конце концов, работа над производительностью – это то же самое, что и работа над UX, безопасностью или доступностью. Все это – составляющие качества программного обеспечения, которое вы предлагаете.

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

Если резюмировать путь к культуре производительности, то ключевые выводы будут следующими:

  • Повышение осведомленности, понимание пользователя;
  • Проактивный подход и заблаговременное решение проблем;
  • Измерение показателей и действия в непрерывном цикле;
  • Распространение знаний и вовлечение всей команды;
  • Конечная цель – повышение качества продукта.

Ссылки на литературу

Вот несколько мест, с которых вы можете начать свой путь к высокой производительности:

Другие статьи

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *