Vlas Zubenko
АвторVlas ZubenkoВеб-разработчик, руковожу командой · 9+ лет · 260+ проектов
Подробнее об авторе

Сначала измерьте. Гадать дорого.

Прежде чем что-то менять, прогоните самую медленную страницу через тест скорости в мобильном режиме — и сделайте это три раза. Один замер не говорит почти ни о чём; три показывают, стабильная это проблема или сервер иногда подвисает. Смотреть надо, какая именно из трёх метрик плохая: каждая указывает на свою причину и своё лечение. Платить за «оптимизацию сайта» без этого шага — верный способ потратить деньги и выиграть полсекунды.

Три метрики, которые важны

  • LCP — сколько ждать до появления основного контента. Норма — меньше 2,5 секунды. Плохой LCP обычно означает картинки или медленный сервер
  • INP — как быстро страница отвечает на нажатие. Норма — меньше 200 миллисекунд. Плохой INP означает избыток JavaScript
  • CLS — насколько вёрстка прыгает при загрузке. Норма — меньше 0,1. Плохой CLS означает картинки и баннеры без зарезервированного места
  • Тестируйте на мобильном и на обычном соединении. Ваш офисный вайфай и десктопный браузер — это не там, где ваши клиенты
  • Тестируйте страницу товара или услуги, а не только главную. Главная обычно единственная, которую кто-то уже оптимизировал

Пять причин по частоте встречаемости

  • Картинки. Фото прямо с камеры телефона весит четыре мегабайта и показывается шириной 600 пикселей. Причина номер один и самая дешёвая в исправлении
  • Плагины. Каждый плагин грузит свои скрипты и стили на каждой странице, включая те, где он не используется. Двадцать плагинов — это не двадцать возможностей, а двадцать сборщиков налога
  • Хостинг. Дешёвый шаред-хостинг означает, что ваш сайт стоит в очереди за сотнями других. Если сервер отвечает дольше 600 мс до того, как вообще что-то начнётся, никакая работа с фронтендом не спасёт
  • Сторонние скрипты. Чаты, аналитика, пиксели, виджеты отзывов, шрифты с внешних сервисов. Каждый — это запрос к чужому серверу, который вы не контролируете
  • Сама сборка. Блокирующий рендер CSS, отсутствие кеша и сжатия, неконтролируемые шрифты. Это та часть, где нужен разработчик, а не галочка в настройках
Большинство медленных сайтов сделаны нормально. Просто в них потом загрузили четыре мегабайта фотографий и девять плагинов, которые никто не убрал.

Что окупается в первую очередь

По порядку — результат на час работы. Первые три обычно вытаскивают страницу из невыносимой в приемлемую, и ни одна из них не требует что-либо переделывать.

  • Переведите картинки в WebP и отдавайте их в том размере, в котором они реально показываются. Часто это само по себе минус 60–70% веса страницы
  • Включите ленивую загрузку всего ниже первого экрана и задайте явные ширину и высоту, чтобы ничего не прыгало
  • Проведите ревизию плагинов. Отключить, замерить, повторить. Всё, что вы не можете обосновать вслух, снимается
  • Нормально включите кеширование и сжатие. На приличном хостинге это настройка, а не разработка
  • Разместите шрифты у себя и грузите только используемые начертания. Два, а не девять
  • Отложите сторонние скрипты и грузите виджет чата после того, как страница стала интерактивной, а не до
  • Переезжайте на хостинг получше, если время ответа сервера всё ещё узкое место. Делайте это последним: с этого начинают, а причиной само по себе оно бывает редко

Во что медленный сайт реально обходится

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

Когда дело не в скорости

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

Вывод

Просите замеры до и после, по одним и тем же страницам, в мобильном режиме. Любая честная работа над скоростью идёт с этими цифрами, а предложение без них продаёт вам ощущение. Большинство бизнес-сайтов переходят из «плохо» в «хорошо» за день-два сосредоточенной работы, потому что причины скучные и повторяющиеся. Переделки требуют те, что собраны из тяжёлой темы и где бюджета на производительность не было изначально, — но это уже другой разговор и другая цена.

Vlas Zubenko
АвторVlas ZubenkoВеб-разработчик, руковожу командой · 9+ лет · 260+ проектов
Подробнее об авторе

Частые вопросы

Пять причин по частоте: картинки, плагины, хостинг, сторонние скрипты и сама сборка. Сначала измерьте на мобильном три раза, потом чините.

Перевод картинок в WebP и отдача в том размере, в котором они показываются. Часто это само по себе минус 60–70% веса страницы.

LCP до 2,5 секунды, INP до 200 миллисекунд, CLS до 0,1. Каждая плохая метрика указывает на свою причину.

Да, опыт взаимодействия — сигнал ранжирования. Но сильнее бьёт другое: медленный сайт удорожает каждый ваш канал трафика.

Только если время ответа сервера больше 600 мс после остальных правок. С этого начинают чаще всего, а причиной само по себе оно бывает редко.

Есть похожая задача?

Расскажите, что должен делать сайт, — честный диапазон получите в тот же день.

Обсудить проект