Кривая с насыщением, а не шкала
Скорость обсуждают так, будто улучшение всегда пропорционально усилию. На практике зависимость другая: у неё есть участок резкого выигрыша и длинный участок, где почти ничего не меняется.
Между сайтом, где первый экран собирается мучительно долго, и сайтом, где он появляется без ожидания, разница очевидна любому человеку без секундомера. Между вторым и третьим, вылизанным до максимального балла, разницы человек не замечает — она есть в цифрах измерителя и отсутствует в опыте.
Отсюда практический вывод, который экономит недели: задача не «сделать максимально быстро», а «выйти из зоны, где ожидание заметно». Первая формулировка не имеет конца, вторая достижима и проверяема.
Проверяема буквально: откройте свою страницу на телефоне с обычной мобильной связью и посмотрите, успеваете ли вы заметить ожидание. Если успеваете — вы в первой зоне, и работа окупится. Если нет — дальнейшие улучшения будут менять цифры в отчётах, а не поведение людей.
Что происходит между кликом и первым экраном
Ожидание складывается из четырёх этапов, и знать их нужно, чтобы понимать, куда бьёт конкретная правка.
Установление соединения. Браузер находит сервер и договаривается о защищённом канале. Здесь помогает физическая близость сервера к пользователю — на этом построена сеть доставки содержимого.
Ответ сервера. Время до первого байта. Если сайт собирает страницу из базы при каждом запросе, этап растягивается. Кеширование готового HTML сокращает его радикально.
Загрузка ресурсов. Стили, скрипты, шрифты, изображения. Самый ёмкий этап и место, где обычно теряется больше всего.
Отрисовка и готовность к взаимодействию. Браузер собирает страницу и передаёт управление скриптам. Если скриптов много, страница выглядит готовой, но не реагирует на нажатия.
Последний разрыв объясняет частую жалобу: «визуально загрузилось, а кнопка не работает». Это не иллюзия, это два разных момента.
Три источника, которые дают основной эффект
Изображения
Обычно самая тяжёлая часть страницы. Арифметика простая: восемь фотографий по два мегабайта — это шестнадцать мегабайт на одну страницу, и никакая оптимизация кода этого не компенсирует.
Три действия закрывают большую часть проблемы. Отдавать изображение в том размере, в котором оно показывается, а не масштабировать средствами браузера. Использовать современные форматы сжатия. Откладывать загрузку картинок, которые находятся ниже первого экрана.
Последнее с оговоркой: откладывать изображение первого экрана вредно — вы отложите ровно то, чего человек ждёт.
Шрифты
Незаметный источник задержки. Пока нестандартный шрифт не загрузился, текст либо не показывается, либо показывается системным и потом прыгает.
Что помогает: сократить число начертаний до реально используемых, подключать шрифты со своего домена, разрешать браузеру показывать текст системным шрифтом до подмены. Четыре начертания вместо десяти — это разница, которую видно на слабой связи.
Сторонние скрипты
Счётчики, чаты, виджеты соцсетей, рекламные пиксели. Каждый добавляет обращение к чужому серверу, скорость которого вы не контролируете.
Проверка занимает минуту: отключите скрипты по одному в панели разработчика и посмотрите, что изменится. Регулярный результат — часть подключённых виджетов не используется никем, а поставлены они были когда-то под задачу, которой давно нет.
Здесь же лежит самая неприятная особенность: чужой скрипт может подгружать другие скрипты. Вы подключили один тег, а на странице оказалось пять обращений к разным доменам. Увидеть это можно только в списке сетевых запросов — в исходном коде страницы этого нет.
Что почти не даёт эффекта
| Действие | Что реально сокращает | Заметно ли человеку | Стоимость работы |
|---|---|---|---|
| Сжатие изображений и правильные размеры | Объём передаваемых данных | Да, особенно на мобильной связи | Низкая |
| Сокращение числа начертаний шрифта | Задержку до появления текста | Да | Низкая |
| Удаление неиспользуемых виджетов | Время до готовности к взаимодействию | Да | Низкая |
| Кеширование готового HTML | Время ответа сервера | Да, если сервер отвечал долго | Средняя |
| Сеть доставки содержимого | Время соединения для дальней аудитории | Только для удалённых регионов | Средняя |
| Минификация стилей и скриптов | Несколько десятков килобайт | Практически нет | Низкая |
| Объединение файлов в один | Число запросов | Почти нет на современных протоколах | Средняя |
| Перевод сайта на другой фреймворк | Спорно | Непредсказуемо | Высокая |
Нижняя часть таблицы — это работы, которые честно выполняются и честно не дают ощутимого результата. Их не стоит запрещать, стоит перестать ставить первыми.
Лаборатория против поля
Два типа измерений отвечают на разные вопросы, и путаница между ними — источник большинства бессмысленных споров.
Лабораторный замер — синтетический прогон на условном устройстве с условной связью. Воспроизводим, удобен для поиска причины, показывает список конкретных ресурсов. Но описывает одну сессию на одном железе.
Полевые данные собираются с реальных посетителей: их устройства, их сети, их маршруты по сайту. Отвечают на вопрос «как быстро у моей аудитории», но не показывают, что именно тормозит.
Порядок работы из этого следует однозначный: полевые данные говорят, есть ли проблема и на каких шаблонах страниц, лабораторный прогон — в чём она. Обратный порядок приводит к оптимизации страниц, которые и так работают нормально.
Числовые границы «хорошо / требует улучшения / плохо» у метрик Core Web Vitals заданы в документации и периодически пересматриваются, поэтому запоминать их наизусть бессмысленно — сверяться нужно с первоисточником.
Почему на вашем компьютере всё быстро
Разработчик и заказчик смотрят сайт на мощной машине с проводным интернетом, сидя рядом с сервером. В таких условиях медленный сайт выглядит нормальным, и обсуждать нечего.
У посетителя условия другие по трём параметрам сразу. Связь нестабильна, и время передачи данных зависит от того, где он находится. Процессор слабее, а разбор и исполнение скриптов — задача процессорная: те же скрипты на телефоне обрабатываются заметно дольше. Экран уже, поэтому изображение, которое на десктопе занимает треть ширины, на телефоне показывается во весь экран — и часто в том же исходном размере.
Из последнего следует неочевидное. Мобильная версия нередко тяжелее десктопной, хотя выглядит проще: тот же набор ресурсов грузится на устройство, которому он даётся тяжелее.
Практическое следствие для приёмки работ: смотреть результат нужно с эмуляцией слабого устройства и медленной сети либо на реальном телефоне из другого города. Иначе вы принимаете работу в условиях, в которых проблемы не воспроизводятся.
Как проверить это на своём сайте
Три проверки, каждая занимает несколько минут и не требует платных инструментов.
- Откройте панель разработчика, вкладку с сетевыми запросами, перезагрузите страницу и отсортируйте по размеру. Первые пять строк — ваш реальный список приоритетов. Если там изображения, работа с кодом подождёт.
- Включите эмуляцию медленной сети и слабого процессора. На быстром компьютере с проводным интернетом проблем не видно вообще, и это главная причина, по которой их не замечают.
- Сравните шаблоны, а не отдельные страницы. Главная, карточка, статья, категория ведут себя по-разному. Оптимизация главной при медленных карточках не даёт ничего, потому что трафик приходит на карточки.
Страница не в индексе. Вопрос к доступности и разрешениям, а не к скорости. Проверяется в разборе индексации, а порядок проверок — в техническом аудите.
Высокий процент отказов при быстрой загрузке. Ускорять нечего. Смотрите, соответствует ли содержание запросу, по которому пришли.
Позиции упали, скорость не менялась. Совпадение по времени с работами по ускорению не означает причины. Ищите изменения в выдаче и в самом сайте через панель вебмастера.
Балл вырос, поведение не изменилось. Нормальный исход при старте из зоны «нормально». Значит, ограничение было не в скорости.
Спорное место
Утверждение «разница между нормально и идеально почти незаметна» верно для человека и неудобно для отчётности. Балл измерителя — красивая цифра, её приятно показывать, и она растёт от работ, которых человек не почувствует.
Есть и обратный аргумент, который стоит признать. На сайтах с большим потоком и длинной воронкой малые улучшения могут давать эффект, невидимый в отдельном визите, но заметный в сумме. Проверить это можно только собственным экспериментом с контрольной группой, а не ссылкой на общее правило.
Поэтому честная формулировка звучит так: пока сайт в зоне «медленно», ускорение — приоритет с очевидной отдачей. После выхода из неё дальнейшая работа переходит в разряд гипотез, которые нужно проверять на своих данных, а не принимать на веру.
Частые вопросы
Влияет ли скорость на позиции в поиске?
Стоит ли добиваться максимального балла в инструменте измерения?
Что делать в первую очередь, если сайт медленный?
Помогает ли CDN?
Как понять, что дальше ускорять бессмысленно?