Сначала измерьте, а потом оптимизируйте

Ощущение «у меня вроде быстро» зависит от устройства, кеша и сети. Перед изменениями откройте сайт в приватном окне, проверьте его на телефоне и воспользуйтесь инструментами производительности браузера. Важно понять, где проходит время: сервер долго отвечает, браузер качает слишком много данных или страница блокируется тяжёлым JavaScript.

1. Изображения — самый частый быстрый выигрыш

Фотография с камеры может весить несколько мегабайт, хотя на карточке отображается размером 500×300 пикселей. Пользователь всё равно скачивает исходный файл, если вы не подготовили подходящую версию.

  • не отдавайте изображение в 4000 px для блока шириной 600 px;
  • используйте современные форматы, если они подходят вашему пайплайну;
  • для изображений ниже первого экрана включайте ленивую загрузку;
  • задавайте размеры изображения, чтобы страница не прыгала при загрузке.

2. Не заставляйте браузер выполнять код, который не нужен

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

Перед установкой новой библиотеки задайте простой вопрос: «Могу ли я сделать этот эффект 20 строками CSS или небольшим модулем JavaScript?» Иногда ответ — да, иногда нет, но вопрос полезен всегда.

3. Шрифты тоже загружаются

Пять начертаний двух семейств могут превратиться в заметный объём. Оставляйте только те веса, которые реально используются. Для первого отображения страницы важен и способ загрузки шрифта: текст не должен оставаться невидимым только потому, что кастомный файл ещё едет по сети.

4. Проверьте время ответа сервера

Если HTML начинает приходить через несколько секунд, оптимизация картинок не решит основную проблему. Причины могут быть разные: «засыпающий» бесплатный инстанс, медленный запрос к базе, внешний API, который вызывается синхронно, или отсутствие кеша там, где данные почти не меняются.

Смотрите логи и измеряйте конкретные операции. Фраза «сервер тормозит» слишком общая, чтобы из неё родилось исправление.

5. Сторонние виджеты иногда дороже вашего кода

Чаты, карты, аналитические скрипты, A/B-системы, пиксели рекламы и виджеты соцсетей добавляют сетевые запросы и JavaScript. Не обязательно отказываться от них, но стоит понимать их стоимость и загружать только там, где они действительно нужны.

Порядок действий, который обычно экономит время

Запишите исходное состояние

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

Исправьте крупные изображения

Это часто даёт заметный результат без изменения архитектуры.

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

Особенно старые библиотеки, подключённые «на всякий случай».

Проверьте backend и базу

Если документ приходит медленно, ищите причину на серверной стороне.

Снова измерьте

Оптимизация без повторной проверки быстро превращается в набор предположений.

Что не нужно делать сразу

Не начинайте с микроскопической минификации каждого байта, если главная фотография весит 8 МБ. Не переписывайте весь frontend на другой фреймворк только потому, что тест показал плохую оценку. Сначала найдите самые дорогие операции и исправляйте их по убыванию эффекта.

6. Кеширование полезно, когда данные действительно можно повторно использовать

Логотип, CSS, JavaScript и неизменяемые изображения не обязательно загружать заново при каждом переходе. Правильно настроенные cache headers позволяют браузеру повторно использовать уже скачанные ресурсы. На сервере можно кешировать и некоторые вычисляемые ответы, если данные не обязаны обновляться каждую секунду.

Но кеш — не кнопка «ускорить всё». Если закешировать персональные данные неправильным образом, можно получить серьёзную ошибку. Сначала определите, что является публичным и одинаковым для всех, а что зависит от пользователя.

Научитесь читать сетевой waterfall хотя бы на базовом уровне

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

Не обязательно быть специалистом по производительности, чтобы увидеть очевидные проблемы. Один waterfall часто объясняет больше, чем десять попыток случайно менять CSS.

Тестируйте на слабом устройстве

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

Нужен сайт, который не заканчивается на красивом макете?

KAMERTON занимается дизайном и разработкой: от структуры и интерфейса до production-запуска.

Посмотреть проекты →
Читайте дальше
Как защитить сайт: практический минимум для малого бизнеса →Чеклист перед запуском сайта: 37 проверок без паники →

KAMERTON: Подробнее об услуге — Разработка веб-сервиса →