Значение производительности в веб-приложении. Работаем с производительностью на ранних стадиях проекта

Что такое производительность

Давным-давно производительность была чем-то таким, о чем вспоминали уже на стадии завершения проекта. Здесь минифицируем, там объединим несколько элементов, здесь оптимизируем и, может быть, поднастроим config-файл сервера… Если вы всё ещё действуете по такой схеме, у нас плохие новости — многие ваши клиенты убегут к более шустрому конкуренту, несмотря на всё богатство функционала и крутость вашего сервиса.

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

Как сделать производительность частью проекта?

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

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

Проводим исследование

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

Затем запустите несколько экспериментов, влияющих на производительность и оцените результаты (например, через Google Analytics). Используйте данные из тематических исследований и экспериментов (например, WPO Stats).

Пример case study с использованием Performance API

Армэл Пинголт (Armel Pingault) в своей статье «How to convince your client to focus on Web Performance: a case study» предлагает получить картинку «до и после», на которой будет ясно видно, что предложенная вами концепция улучшит некоторые бизнес-KPI.

Чтобы получить необходимые данные Армэл использовал Perfomance API вместо традиционного подхода — использования вкладки «preformance» в инструментах разработчика. В своей статье Армэл даёт пример исследования, которое заняло не более 2 часов.

Что сделал Армэл за эти два часа? Он проверил главную страницу сайта одного из клиентов и выяснил, что именно мешает быстрой загрузке страницы. Армэл сымитировал медленную загрузку страницы и воспользовался Performance API чтобы получить конкретные цифры.

Отчёт выдал, что парсинг блока <head> занял 4,40 секунды (CSS 1.85 + JS 2.55) для примерно 50 строк, тогда как парсинг блока <body> занимал всего 0,97 секунды для ~1300 строк. Тогда Армэл воспользовался инструментом «coverage» в <body>, и отчёт показал, что 92% CSS в этом блоке не используется.

Армэл оптимизировал код в блоке, добавив атрибут «defer» и почистил CSS. В результате страница стала загружаться за 0,63 секунды. То есть страница стала загружаться на 85% быстрее.

4,40 секунды до оптимизации и 0,63 секунды на загрузку после оптимизации — это понятные цифры, с которыми можно идти к бизнесу, продактам и маркетологам.