Шаг 1. Постановка цели
Основное на этом шаге - определиться, зачем вам оптимизировать скорость загрузки. К примеру, у вас сайт-визитка, продаёте вы бани под ключ. Продажи происходят в той же бане, за столом или по телефону.
Вполне возможно, что очередная секунда времени загрузки не влияет на продажи и вложенные затраты не окупятся.
Стоит сфокусироваться на тех сайтах или страницах, которые влияют на ваши целевые показатели.
Шаг 2. Сбор статистики и выбор узкого места для оптимизации
Во-первых, обратимся к событиям, вызываевым на разных стадиях загрузки страницы:
Современные браузеры поддерживают Navigation Timing API, который предоставляет информацию, когда произошло конкретное событие в течение загрузки страницы.
Метрики можно смотреть на локальном компьютере либо собирать их с клиента на сервер и затем делать выводы. У обоих подходов есть плюсы и минусы, давайте их рассмотрим.
| Фактор сравнения | Отслеживание на локальном компьютере | Развёртывание сервера и выводы в дальшейнем |
|---|---|---|
| Порог входа | Не требует установки дополнительного ПО | Требует сервера приёма метрик и их анализа |
| Реальность значений | Только модель, нет конкретных значений | Данные собраны с реальных пользователей |
| Точность результатов | Результаты меняются от измерения к измерению | Чем больше посещений страниц, тем точнее результат |
Возможно применение сервисов, которые позволят собрать реальные данные,
не тратя время на равёртывание сервиса сбора метрик.
Например, google analytics и её отчёт по скорости.
Субьективно все инструменты делятся на 4 типа:
- встроенные в браузер (debug панель FireFox, Chrome);
- одноразовые сервисы - одно измерение, не отражающее действительность в силу их статической незначимости;
- скрипты сбора статистики, встроенные в счётики (Яндекс Метрика, Google Analytics);
- управляемый сбор статистики путём имитации клиента sitespeed.io.
Например, google analytics по умолчанию собираются метрики по времени загрузки с 1% пользователей.
При большом количестве просмотров страниц метрики начинают показывать стабильные результаты.
Но как их улучшить?
Шаг 3. Выявление узкого места
В оптимизации важно применить усилие в нужное место.
Вариант “за дёшево”
Заходим в Chromium, запускаем вкладку Audits
Через несколько секунд получаем результат
Lighthouse, встроенный в инструменты разработчика Chromium, отсортировал для нас факторы оптимизации в порядке приносимых эффектов.
В данном примере рекомендуют минимизировать работу в главном потоке путём минимизации выполнения JS.
Вариант “по статистическим данным”
В google analytics находим отчёт по скорости загрузки страниц.
Для наглядности на основе данных я построил диаграмму
Видно, что узкое место - время ответа сервера. На втором месте - переадресация.
В таком же порядке стоит начать оптимизировать. Сначала время ответа сервера, затем - уменьшение переадресаций.
Шаг 4. Сама оптимизация
В зависимости от узкого места оптимизировать его ;)
Общие рекомендации для бек-енда:
- Cчитать данные заранее, клиенту в момент запроса отдавать сразу поготовленные данные;
- Быть гибким для клиента и выдавать только запрошенные поля / выдавать подготовленные данные, подходящие именно для конкретной страницы;
- Стремиться отдавать 90% ответов клиенту за 100ms;
- Исходя из требований времени ответа не допускать запросов при формировании ответов, находящихся на расстоянии больше чем 40-50ms.
Общие рекомендации для фронт-енда:
- Не пишите JavaScript, который заставляет браузер пересчитывать макет страницы.
- Не усложняйте свой CSS. Используйте меньше CSS и делайте ваши CSS-селекторы простыми.
- Исключайте перерисовку где только возможно. Выбирайте CSS, которые не вызывают пересчёт макета страницы целиком.
- Отрисовка страницы может занять больше времени, чем любая другая активность при рендеринге. Следите за узкими местами отрисовки.