+7 (925) 507-98-19
к.э.н. Лавлинский Николай Евгеньевич, технический директор ООО «Метод Лаб»
Мы все любим скорость: требуем быстрый интернет, быстрые компьютеры, смартфоны и приложения. Встретив тормозной сайт мы можем рассказать много «интересного» про его разработчиков и их проект. Однако, иногда мы сами отвечаем за скорость — например, когда разрабатываем сайты. В конце концов, все сайты кто-то разрабатывал и за их тормоза отвечаем мы с вами — разработчики.
Как заботиться о скорости своего веб-проекта и не попадать в разряд «тормозов» — поговорим в этой статье.
Во-первых, чтобы сделать «мир лучше». Действительно, несмотря на развитие технологий сайты постепенно становятся только медленнее. Чтобы повернуть эту тенденцию вспять, нужно активно заниматься скоростью.
Во-вторых, пользователи любого проекта любят скорость. В конечном итоге это значит больше успеха: довольные клиенты и больше денег. Если вам как разработчику получится показать, что вы делаете значимый вклад в общий успех — ваша ценность резко возрастёт.
Ну и наконец, если скоростью не заниматься целенаправленно, со временем любой проект превращается в телегу. Быстрый по умолчанию — это не про веб.
Для начала нужно разделить сайт на две части: серверную и клиентскую. Соответственно и все вопросы по скорости у нас будут двух видов: серверные и клиентские. Такая классификация полезна при диагностике и определения областей ответственности.
Также проблемы скорости можно разделить на два класса: этап загрузки (сеть) и этап исполнения. Такое разделение помогает при тестировании скорости с ограниченными ресурсами. Например, мы можем тестировать сайт в условиях медленной сети для выявления проблем этапа загрузки и ограничивать возможности CPU для выявления проблем этапа исполнения.
При этом хороший разработчик должен иметь представление о всех аспектах, даже, если часть из них выходит за зону его ответственности. Как минимум для того, чтобы общаться с коллегами. Как максимум, чтобы иметь возможность провести объективный анализ скорости сайта.
Самое главное для разработчика — уметь объективно оценить скорость собственной разработки. Казалось бы, нет проблем, ведь любой разработчик пользуется продуктом в процессе и должен заметить проблемы со скоростью. Однако, это не так.
Основная сложность состоит в том, что часто разработчик пользуется сайтом в синтетических, нереальных условиях. Как мы указывали выше, на скорость сайта влияют различные факторы: скорость сети, ресурсы СPU и оперативной памяти и даже наполнение сайта.
Таким образом, нам требуется инструмент тестирования скорости, который будет накладывать ограничения на ресурсы и давать стабильные результаты. Этим критериям соответствуют несколько инструментов.
Прежде всего, можно воспользоваться возможностями инструментов разработчика (Developer tools) браузера Chrome (или других на движке Blink). Для контроля параметров сети есть настройка по профилям мобильной связи, можно вообще отключить сеть. Кроме того, нужно поставить опцию «Disable cache» для тестирования времени загрузки первой страницы сайта. Для более подробного анализа можно воспользоваться закладкой «Audits», где сайт будет протестирован сразу по нескольким ключевым метрикам. Чтобы оценить производительность работы после загрузки сайта (скорость анимаций, нагрузка на CPU) стоит воспользоваться закладкой Performance. Она позволяет в реальном времени наблюдать за работой браузера с очень высокой детализацией.
Оценка скорости загрузки для мобильных устройств возможна в двух вариантах: в режиме эмуляции (Device mode) и при подключении реального устройства к DevTools. Второй вариант более трудоёмок, но значительно точнее.
Второй инструмент для оценки скорости сайта — сервис Webpagest.org. Это открытое решение для тестирования скорости сайтов с помощью географически распределённой сети агентов. Каждая точка тестирования представляет из себя компьютер или мобильное устройство (иногда сразу несколько), которая получает задачи с сервера, выполняет тесты в реальном браузере и отправляет результаты на сервер. При этом формируются удобные отчеты, содержащие множество важных метрик скорости. Более того, это решение можно установить на собственную инфраструктуру и автоматизировать процесс тестирования.
Итак, у нас есть несколько мощных инструментов тестирования скорости. Но на какие метрики стоит обращать внимание в первую очередь?
При использовании профессиональных инструментов (например, рекомендованных выше) может возникать ощущение перегрузки данными. Поэтому очень важно концентрироваться на главном.
Первое, что нужно контролировать: метрика TTFB (time to first byte), время до первого байта. Эта метрика будет показывать серверную производительности и накладные расходы на установление соединения. Если этот показатель превышает 500-1000 мс, стоит серьёзно разобраться с причинами.
Второй параметр: время начала рендеринга (start render, first paint). Эта метрика определяет решение пользователя закрыть вкладку браузера при длительном отсутствии результата.
Третий параметр: время загрузки (load time). Этот показатель даст понятие об общем времени загрузки основных элементов сайта (кроме отложенных).
Однако, никакие метрики не заменят субъективную оценку процесса загрузки сайта с использованием сложных сетевых условий. Как правило, это процесс визуализируется в виде ленты скриншотов (поддерживается как в DevTools, так и в Webpagetest). По этой ленте можно определить момент, когда пользователь может начать пользоваться контентом сайта, увидит главную картинку и т.д.
В этой небольшой статье мы рассмотрели лишь основы темы скорости сайтов: диагностику. Для решения проблем скорости существует большое количество технологий и решений, которые можно рассмотреть в будущих материалах.
