Как ускорить сайт: план без хаотичных правок
Медленный сайт редко лечится одной волшебной настройкой. Чаще он постепенно становится тяжелее: добавилась большая фотография, новый виджет, ещё одно начертание шрифта. Чтобы улучшения не превратились в хаотичные эксперименты, полезно двигаться от измерения к конкретной причине. Ниже — рабочий порядок, который помогает сохранить смысл задачи: сделать сайт удобнее, а не просто получить красивый скриншот отчёта.
Евгений Порывкин
Веб-разработчик
Зафиксируйте исходную точку
Выберите несколько характерных страниц: главную, каталог, карточку и форму обращения. Запишите условия проверки: устройство, размер экрана, состояние кеша и ограничение сети. Сделайте несколько запусков, а не опирайтесь на единственный удачный результат. Так последующее сравнение будет содержательным.
Помимо отчёта, самостоятельно пройдите основной сценарий. Что появляется первым? Можно ли начать читать, пока загружаются остальные элементы? Не двигается ли кнопка под пальцем? Наблюдения часто помогают сформулировать конкретную гипотезу лучше, чем общий балл.
Найдите ресурс, который задерживает первый экран
Посмотрите последовательность загрузки. Иногда HTML приходит быстро, но важная фотография обнаруживается слишком поздно. В другом случае основное время уходит на ожидание ответа сервера. Это разные причины, и исправления у них тоже будут разными.
В документации по оптимизации LCP отдельно рассматриваются обнаружение главного ресурса, его загрузка и момент отрисовки. Поэтому не стоит без измерений объявлять виновником только размер картинки. Сначала установите, на каком участке появляется задержка. Подробнее о диагностике LCP.
Приведите изображения в соответствие с задачей
Сравните реальный размер изображения в интерфейсе с размером исходного файла. Для небольшой карточки редко нужен тот же ресурс, что для полноэкранной галереи. Подготовьте подходящие варианты, проверьте качество и используйте размеры, которые соответствуют месту на странице.
Для изображений ниже первого экрана можно применить нативную отложенную загрузку. Основной визуал, который нужен сразу, откладывать не следует. Указывайте ширину и высоту, чтобы браузер мог заранее зарезервировать пропорции. В примере показана именно карточка ниже первого экрана. Рекомендации по lazy loading.
<img
src="/images/chair-640.webp"
alt="Светлое кресло с деревянными ножками"
width="640"
height="480"
loading="lazy"
decoding="async"
>Проверьте цену дополнительных возможностей
Составьте список внешних скриптов: чат, карта, аналитика, виджеты отзывов. Напротив каждого запишите владельца и задачу. Если команда не может объяснить, зачем ресурс нужен сейчас, это повод обсудить его отключение, а не бессрочно переносить в следующую версию.
Не удаляйте всё одновременно. Меняйте один фактор, проверяйте результат и основной сценарий. Например, карта может быть полезна на странице контактов, но не обязана загружаться на каждом экране сайта. Подход «там, где нужно» обычно яснее, чем набор исключений задним числом.
Закрепите результат в рабочем процессе
После исправлений повторите исходную проверку в тех же условиях. Сохраните не только цифры, но и перечень сделанных изменений. Если результат оказался слабее ожидаемого, вернитесь к гипотезе: возможно, вы оптимизировали заметный, но не определяющий ресурс.
Согласуйте простые правила публикации: допустимые размеры изображений, порядок подключения новых виджетов и обязательную проверку ключевых страниц. Важнее небольшой понятный регламент, которым пользуются, чем большой документ, про который вспоминают после очередного замедления.
Что считать хорошим завершением
Заканчивайте работу не обещанием «сайт теперь быстрый», а описанием результата: какие страницы проверены, какие ограничения остались и как заметить ухудшение. Скорость зависит от условий посетителя, поэтому один тест не даёт права говорить за всех.
Практический следующий шаг прост: выберите самый важный сценарий, зафиксируйте исходную точку и исправьте одну подтверждённую причину. Такой подход даёт не только улучшение, но и понимание того, почему оно появилось. Это понимание останется полезным после следующего обновления.
Предположим, команда заметила, что после обновления главной страницы посетитель несколько секунд видит только меню. Вместо задачи «ускорить весь сайт» сформулируйте более узкую: определить, почему основной блок появляется с задержкой именно после этого изменения. Сохраните предыдущую версию для сравнения, запишите состав новых ресурсов и проверьте их по одному. Даже если причина окажется неожиданной, такой разбор даст воспроизводимый результат. В следующем релизе команда уже будет понимать, какую часть страницы проверить особенно внимательно и почему это важно для посетителя.