Производительность — скорость работы приложения.
- Как быстро открывается главная страница?
- Сколько времени будет работать REST-запрос на создание карточки?
- Как долго будет загружаться отчет с максимальным количеством настроек?
Нужно помнить, что один и тот же отчет может грузиться разное время. В одном случае грузим данные за последнюю неделю, а в другом за последние 10 лет — время загрузки получится разное.
Один и тот же поисковый запрос «Иванов Иван» на разных базах отработает по-разному. Одно дело — поискать по тестовой базе в 100 записей, совершенно другое — на реальной нагруженной системе на 100 млн данных.
Поэтому проводим тестирование производительности:
- С разными параметрами
- С разными настройками
- В разных условиях
Важно понимать, что разные параметры — это:
- Минимум
- Максимум
А то бывает как — тестировщик думает: «Раз производительность, значит, надо тестировать сложные случаи, большие объемы итд. Ведь именно это может тормозить». Но не менее важно проверить, как ведет себя система в ненагруженном состоянии. Как быстро отработает поиск на небольшой базе? Ведь если система в этом случае тормозит, то тестировать на большой базе просто бессмысленно.
В 21 веке от производительности сильно зависит настроение пользователя. Точнее, от плохой производительности. Это «гигиенический фактор» . Если страницы грузятся быстро — я этого даже не замечу, ведь так и надо! А вот если мне приходится ждать по 2 минуты, чтобы увидеть расписание сеансов в кино, я лучше поищу другой сайт.
Поэтому важный вопрос — а как у конкурентов? Если у вас есть новостной сайт, который грузится 2 минуты, тогда как полно сайтов, отображающихся моментально, кого выберет пользователь? Используйте отсылку на конкурентов как обоснование бага. Это поможет избежать ситуации «быстрее нельзя, кучу новостей потеряем».
А может быть можно? Может, у нас неэффективный дизайн, слишком много напихано на главную. Изучили конкурентов — а как у тех, у кого работает быстрее? Может, нужно выводить меньше новостей на первую страницу. Или картинки уменьшить у каждой.
Картинки — это вообще боль. Они могут грузиться очень долго. Особенно если разработчик поленился сделать нормально. Вот смотрите, допустим, у вас есть большая картинка платьюшка из новой коллекции. Весит картинка 5Мб. На страничке мы видим уменьшенную версию (превью): щелкаешь по мелкой картинке и тогда уже грузится большая.
Сделать превью можно разными путями. Правильный путь — подготовить 2 картинки, полновесную и для превью на 50кб . Ленивый путь — сделать одну картинку, просто в коде HTML для мини-версии указать отображаемые размеры. Результат будет одинаковый! Отображаться страница будет в обоих случаях одинаково. Вот только грузиться будет разное время. Одно дело — подсосать файл на 50кб, совершенно другое — 5мб.
См также:
А если у нас страница с новостями и у каждой превью? Или на главной странице интернет-магазина показано сразу 10 новых моделей платьев? Тогда уже получаем 10 картинок по 5мб каждая, время ожидания нарастает.
А если человек смотрит товары с телефона на улице с плохим интернетом? А если при этом на улице холодно и руки из варежек он достал только ради выбора новой шапки? Плюнет ведь и уйдет без покупки...
В наши дни мобильный интернет очень распространен. Поэтому все сайты стараются делать как веб-версию, так и мобильную. Иначе они просто потеряют аудиторию. Мобильная версия оптимизирована по скорости (работать будет по плохому интернету наверняка) + адаптирована по верстке. И производительность в данном случае очень важна!
Инструменты
Раньше были специальные плагины для замеров производительности. Но увы, они все устарели (на момент написания этой главы). Сейчас самое актуальное, что есть — Lighthouse. Она входит в состав devtools в Chrome.
Запускаем процесс, ждем и потом получаем результаты:
Ну а дальше уже анализируем, что будет исправляться, а что нет.
Обожаю Ваши пояснения на платюшках: сразу доходчиво и понятно)
ОтветитьУдалитьСпасибо))
Удалить