Почему сайт медленный? Что чинить первым для Core Web Vitals

Сайт кажется медленным, круг в PageSpeed красный, и у каждого в комнате свой виновник. Вот порядок, в котором работаем мы: сначала то, что видят реальные посетители, затем картинки, шрифты, сторонние скрипты, сдвиги макета и время ответа сервера. Заодно разберём, что значит оценка, сколько занимает каждое исправление и что мы поменяли на собственном сайте.

КОРОТКО

Что чинить первым

Начните с того, что реальные посетители видят на телефонах: откройте отчёт Core Web Vitals в Search Console и посмотрите, какая из трёх метрик не проходит. На большинстве страниц загрузку определяет картинка, поэтому первая задача это самое крупное изображение на первом экране, затем шрифты, сторонние скрипты и сдвиги макета. Сервер в этом списке идёт последним, если только он сам не съедает большую часть ожидания; тогда он становится первым.

Этот порядок следует из данных. В Web Almanac от HTTP Archive (данные июля 2025 года) все три Core Web Vitals были в зелёной зоне у 48% мобильных сайтов и 56% десктопных. Слабее всего на телефонах загрузка: хороший Largest Contentful Paint (LCP) у 62% мобильных сайтов, против 77% по Interaction to Next Paint (INP) и 81% по Cumulative Layout Shift (CLS). А на 76% мобильных страниц элемент, который измеряет LCP, это изображение.

Чините то, что чувствуют посетители, а не то, что печатает тест.

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

РЕАЛЬНЫЕ ВИЗИТЫ

Сначала полевые данные

Полевые данные это то, что реальные пользователи Chrome получили за предыдущие 28 дней; они собраны в Chrome UX Report (CrUX). Из него читают и отчёт Core Web Vitals в Search Console, и верхний блок PageSpeed Insights. Чем это отличается от лабораторного теста, рассказано в статье 3D на живом сайте: наш эксперимент с three.js и что увидел Google. Чтобы решить, что чинить, важнее всего три детали.

Отчёт судит группы, и по худшей метрике. Search Console объединяет адреса с похожим опытом в группу, и группа получает статус своей самой слабой метрики: хороший INP при плохом CLS читается как плохо. Это указывает на шаблон: когда 4 000 карточек товара не проходят вместе, одно исправление чинит их все.

Цифра описывает более медленных посетителей. Google показывает 75-й процентиль, отдельно для телефонов и компьютеров: три визита из четырёх были как минимум настолько быстрыми. Ускорение страницы для людей с новыми телефонами на офисном Wi-Fi может его и не сдвинуть.

У данных есть слепые зоны. CrUX собирает данные из Chrome на компьютерах и на Android. Chrome на iOS, приложения Android с WebView и другие браузеры на Chromium, например Edge, исключены (Chrome for Developers, проверено в ноябре 2026 года), а Safari вообще отдельный браузер. В октябре 2026 года в ОАЭ на Android приходилось около 81% мобильного рынка, на iOS около 19% (StatCounter). Это средняя цифра по стране, а у вашей аудитории доля iPhone может быть совсем другой, поэтому сверьте её со своей аналитикой: все эти посетители в отчёт не попадают. Сайты ниже нераскрытого порога популярности не имеют данных CrUX вообще.

Лекарство от обоих пробелов одно: измерять собственных посетителей. С версии Safari 26.2 (декабрь 2025 года) Safari отдаёт API для LCP и INP (WebKit). Открытая библиотека Google web-vitals, около 3 КБ, может отправлять эти цифры из реальных сессий в вашу аналитику; CLS остаётся только в Chromium.

Затем сопоставьте увиденное с подозреваемыми:

Пороги взяты с web.dev (проверено в ноябре 2026 года). Одно решение за вас не примет ни один инструмент: какие шаблоны идут первыми. Для магазина это товар, категория и оформление заказа; для бизнеса, который продаёт через заявки, страница услуги и форма. Мы читаем бизнес раньше отчёта: медленная страница без заказов может подождать, а чуть более быстрая, на которой держится выручка, ждать не может.

ОЦЕНКА

Что значит оценка

Число в круге это оценка Lighthouse по одной симулированной загрузке на телефоне среднего уровня с фиксированной сетью. Её текущие веса, как их описывает Chrome: Total Blocking Time 30%, LCP 25%, CLS 25%, First Contentful Paint 10% и Speed Index 10%. INP в ней нет, потому что во время лабораторного прогона никто не нажимает на экран. Его заменяет Total Blocking Time, и web.dev прямо пишет: это разумная замена для лаборатории, но не равноценная.

Оценка даёт повторяемый список проблем одной страницы в жёстких условиях и честное сравнение «до и после». Многое она оставляет за кадром:

• Опыт посетителей. Лабораторный прогон начинается с холодного кеша, обычно пропускает сдвиги при прокрутке и не видит настоящего нажатия (web.dev).
• Ранжирование. Google рекомендует хорошие Core Web Vitals для успеха в поиске, пишет, что они не гарантируют верхних позиций, и что единого сигнала page experience не существует.
• Стабильность. Документация Chrome называет A/B-тесты, меняющуюся рекламу и сетевые маршруты среди причин, по которым оценка гуляет от прогона к прогону.

Низкая оценка при хороших полевых данных это меньшая проблема, хотя будущие клиенты и партнёры тоже открывают PageSpeed. Зелёная оценка при плохих полевых данных опаснее: неполадка сидит там, куда лаборатория не смотрит.

В октябре 2026 года наша главная получила 32 на мобильном, потому что у тестовой машины нет видеочипа и она рисует нашу 3D-сцену программно; после изменений, описанных в статье о 3D на живом сайте, стало 78. Тестовый браузер может даже создать проблему, которой нет ни у одного посетителя: Lighthouse растягивает окно на всю высоту страницы ради полного скриншота, и холст, привязанный к высоте окна, вырос до 16 000 пикселей, пока мы не ограничили его. Страницы наших статей получили 75 на мобильном 25 октября 2026 года. Это оранжевая зона, и мы пишем об этом, потому что оценка для нас рабочий инструмент.

КАРТИНКИ

Начните с картинок

С изображениями две отдельные задачи.

Задача первая: та единственная картинка, которую измеряет LCP. web.dev делит LCP на четыре части: время до первого байта, задержка начала загрузки ресурса, длительность его загрузки и задержка отрисовки элемента, с ориентиром примерно 40%, меньше 10%, примерно 40% и меньше 10%. Обе задержки должны стремиться к нулю, а LCP breakdown в инструментах Chrome покажет ваши. На многих страницах картинка просто начинает загружаться слишком поздно, по одной из трёх причин:

• Она загружается лениво. Примерно от 16% до 17% страниц делают так со своим изображением LCP (Web Almanac, 2025), а web.dev просит не делать этого никогда.
• Браузер находит её поздно, потому что она лежит в фоне CSS или в скрипте слайдера. Тогда нужен preload с высоким приоритетом.
• Браузеру никто не сказал, что она важна. Только 17,3% мобильных страниц ставят на неё fetchpriority="high".

Исправление может занять одну строку: <img src="cover.jpg" alt="..." width="1802" height="873" fetchpriority="high">. Именно так выводится обложка на страницах наших статей. Высокий приоритет давайте одной-двум картинкам, не больше: как отмечает web.dev, дальше он перестаёт помогать.

Первая задача это одна картинка, а не все сразу.

Задача вторая: всё остальное. Средняя (медиана) мобильная главная несёт 911 КБ изображений, это её самый крупный тип содержимого (Web Almanac, июль 2025 года). О каждой картинке спросите, нужна ли она этому посетителю сейчас и в таком размере.

Наш блог научил нас обеим половинам этого вопроса. В его строках есть превью при наведении: картинка, которая появляется рядом со ссылкой, когда на неё навели мышь. Раньше они скачивались вместе со страницей. 17 октября 2026 года мы это изменили: картинка запрашивается, только когда указатель дошёл до ссылки, телефоны её не просят вовсе, а изображения внутри текста статей получили ленивую загрузку. Вес картинок при первом показе упал с 2,9 МБ до 0,4 МБ на блоге и примерно с 5 МБ до 0,25 МБ на одной длинной статье.

Потом исправление показало свою цену: превью приходили с опозданием, и блог подтормаживал под мышью. Это были оригиналы от 230 до 250 КБ для маленького окошка. Теперь это копии шириной 720 пикселей, около 50 КБ (два примера, проверено 2 ноября 2026 года: 233 КБ против 54 КБ, 249 КБ против 47 КБ), и на широких экранах с мышью каждая загружается, когда её строка приближается.

Сами картинки на нашем сайте никогда не пережимаются: таково наше правило для работ студии. Меньшие копии для меньших окон дали экономию около 80% и не тронули оригиналы. Более сильное сжатие и новые форматы вполне законные инструменты, и для большого каталога они могут быть верным выбором; решать должен тот, кому важен внешний вид.

ШРИФТЫ

Шрифты: дёшево и забыто

87% мобильных страниц используют веб-шрифт (Web Almanac, 2025), и вредят шрифты двумя способами. Примерно на 24% мобильных страниц элемент LCP это текст, так что поздний шрифт может задержать главную метрику. А пришедший шрифт способен сдвинуть макет: даже невидимый текст сначала верстается запасным шрифтом, и подмена двигает содержимое (web.dev).

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

• Отдавайте только WOFF2.
• Делайте preload одного-двух начертаний, которые нужны первому экрану, и не больше: preload отнимает канал у других ресурсов.
• Выбирайте font-display осознанно: swap показывает текст сразу и рискует прыжком, optional избегает прыжка и может пропустить шрифт, если он опоздал.
• Подгоняйте запасной шрифт через size-adjust, чтобы подмена двигала меньше.
• На сайте с латиницей и кириллицей разбейте большие гарнитуры на наборы и подключайте через unicode-range, если лицензия это разрешает: браузер скачает только нужный алфавит.

Мы делаем preload двух начертаний на каждой странице, SF Pro Regular и Semibold, в WOFF2 с font-display: swap. Лучшая находка оказалась мельче. Всплывающее окно «Поделиться» использовало начертание Black для подписей, и только из-за этого браузер скачивал файл шрифта Black на каждой странице. Подписи перевели на Semibold, и загрузка исчезла. Посмотрите, какие файлы шрифтов страница скачивает на самом деле.

СТОРОННИЕ СКРИПТЫ

Скрипты и медленные нажатия

Как минимум 90% страниц используют сторонние сервисы, и медианная страница на мобильном делает 79 сторонних запросов (Web Almanac, 2025). В 2025 году медианный Total Blocking Time на мобильных вырос на 58%, с 1 209 до 1 916 миллисекунд, тогда как web.dev просит меньше 200. Не всё это приходит от сторонних сервисов, но мы смотрим туда первым делом: чтобы убрать тег, не надо переписывать продукт.

Механизм такой: браузер обрабатывает нажатие в основном потоке, и взаимодействие состоит из трёх частей: задержка ввода, обработка и задержка отрисовки. Задача дольше 50 миллисекунд считается длинной, а нажатие, попавшее на неё, ждёт в очереди. Тег аналитики, виджет чата и тепловая карта по отдельности кажутся мелочью; вместе они заполняют эту очередь.

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

1. Перечислите все теги с тремя ответами: кто его просил, какое решение он питает и когда кто-либо в последний раз смотрел его данные. Теги без ответов идут к руководителю маркетинга.
2. Ставьте на паузу или удаляйте, но не блокируйте. По рекомендации Google приостановленный или удалённый тег уходит из контейнера, а тег, заблокированный исключением в триггере, остаётся в коде.
3. Запускайте необязательное после Window Loaded. Момент загрузки самого менеджера тегов может значить не меньше.
4. Присмотритесь к тегам Custom HTML. Большинство инструментов приписывает их работу менеджеру тегов. web.dev сообщает о связи между размером контейнера и худшим INP; медианный контейнер весит около 50 КБ.
5. Запускайте виджеты по требованию. Окно чата может загружаться при первом нажатии на его кнопку.

То же относится к вашему собственному коду. Аудиограф для фонового звука на нашей главной стоил около 0,3 секунды при загрузке; теперь он строится при первом касании, клике или нажатии клавиши.

СДВИГИ МАКЕТА

Чтобы страница не прыгала

CLS единственная метрика, где компьютеры хуже телефонов: в зелёной зоне 72% десктопных сайтов против 81% мобильных (Web Almanac, 2025). Лаборатория видит её хуже всего: сдвиги в пределах 500 миллисекунд после нажатия прощаются, а прокрутке и наведению такого прощения нет, так что блок, который прыгает при прокрутке, идёт вам в минус и может вообще не появиться в тесте загрузки.

Большинство причин вполне обычные. На 62% мобильных страниц есть хотя бы одна картинка без размеров, поэтому браузер выделяет ей нулевую высоту и двигает всё, когда она приходит; лечится атрибутами width и height или свойством aspect-ratio в CSS. Рекламе, встраиваемым блокам и iframe нужно зарезервированное место через min-height или aspect-ratio. Анимации лучше строить на transform: движение через top или left считается сдвигом, а translate нет (web.dev).

Легко упустить блок, который скрипт строит уже после первой отрисовки. У нас таких было два. На телефонах скрипт собирал оглавление каждой статьи из заголовков и толкал текст вниз: CLS 0,19 на страницах статей. Панель разделов блога уже после отрисовки решала, поместятся ли ссылки в одну строку или нужны две колонки: CLS 0,5.

Оба исправления перенесли решение на более раннее время. Теперь оглавление сразу рисует сервер в HTML, а скрипт его только подхватывает: с 0,19 до 0. Несколько строк встроенного скрипта сразу после панели решают её вид до первой отрисовки: с 0,5 до 0. У первого исправления есть постоянная цена: правила сборки оглавления теперь живут в двух местах, на сервере и в скрипте, и менять их надо вместе.

Решайте вид блока до первой отрисовки, а не после неё.

Честная проверка: загрузите страницу на медленном соединении и смотрите. Всё, что появляется и толкает соседей, нуждается в зарезервированном месте или в отрисовке на сервере.

СЕРВЕР

Когда сервер идёт первым

Time to First Byte (TTFB) это время, которое браузер ждёт первый байт HTML. web.dev предлагает ориентир 0,8 секунды и считает плохим всё выше 1,8; в 2025 году в зелёной зоне были 44% мобильных и 55% десктопных сайтов (Web Almanac). Это не Core Web Vital, но он тратит тот же бюджет: при TTFB 1,8 секунды на всё остальное в пределах LCP 2,5 секунды остаётся 0,7. Вот тогда сервер и становится первым в списке.

Первый замер своего сайта сделайте из терминала, несколько раз подряд, откуда-нибудь рядом с вашими клиентами:

curl -s -o /dev/null -w "%{time_starttransfer}\n" https://your-site.example/page

В эту цифру входят соединение и шифрование. Проверяйте страницу, которую люди действительно открывают, например категорию или товар.

Сначала дешёвое, и настройка часто лучше железа. На одном из наших проектов тариф хостинга уже предлагал OPcache, кеш скомпилированного кода PHP, но его никто не включил; включение сократило ответ сервера примерно с 55 до примерно 21 миллисекунды. Редиректы внутри своего домена вы можете убрать сами. Заголовок Server-Timing показывает, какой шаг на сервере занимает время. CDN заслуживает высокого приоритета, если его нет, пишет web.dev, как и кеширование страниц.

Любая настройка скорости может что-то сломать. Прежде чем включить кеш конфигурации Laravel, нам пришлось переписать код, который читал настройки окружения напрямую, иначе эти значения стали бы пустыми. На закрытой тестовой копии одного из наших проектов кеширование маршрутов превратило каждую страницу в 404, потому что языковые префиксы берутся из базы. Поэтому такие изменения проходят регрессию на копии, подробнее в статье Сколько тестирования нужно сайту или приложению перед запуском?

Повторные визиты дают отдельный выигрыш, и PageSpeed его не покажет. Наши CSS и JavaScript кешируются на год (Cache-Control: max-age=31536000), а адрес каждого файла несёт время его изменения, ?v=<время>, так что правка доходит до всех сразу. Лабораторный тест начинается с холодного кеша, поэтому оценка этого никогда не видит; читатель на второй странице видит.

Расстояние это физика. В документации AWS сказано, что регион рядом с большинством ваших пользователей снижает задержку, и в её списке есть регионы в ОАЭ и Бахрейне. Сервер в Европе отвечает клиенту в Дубае заметно дольше, чем сервер в регионе, поэтому бизнесу, который продаёт в Персидском заливе, стоит проверить, где стоит сайт и есть ли CDN с узлами рядом.

Дорогое лечение находится в коде: медленные запросы к базе, десятки плагинов, старый фреймворк на старом PHP. Если причина в этом, прочитайте статью Скрытый технический долг, из-за которого редизайн сайта стоит дороже плана, прежде чем считать бюджет.

СТОИМОСТЬ

Сколько стоит работа

В таблице наша приблизительная оценка объёма инженерной работы на бизнес-сайте с несколькими шаблонами: ориентир для планирования, а не смета.

Когда причина в последней строке, модернизация сайта начинается с аудита, от $300 для небольшого сайта и от $1 000 для крупного, а работы оцениваются после него. Если вы не уверены, что проблема вообще в скорости, юзабилити аудит, от $1 500, проверяет ключевые сценарии, включая скорость. Работа только с сервером это DevOps и облачная инфраструктура, от $50 до $70 в час. Удерживать цифры от сползания назад помогает поддержка и обслуживание сайтов, от $1 000 в месяц, потому что один новый тег или баннер может за день отменить всю работу. Новый сайт это крайняя мера и другой бюджет: в услуге Разработка сайтов под ключ в ОАЭ корпоративный сайт стоит от $20 000 до $40 000, интернет-магазин от $25 000. Все цены на странице цен.

Оправдано ли это? Чистый публичный тест провёл Vodafone, опубликован на web.dev в 2021 году: A/B-тест на платном трафике с двумя внешне одинаковыми страницами, где LCP на 31% лучше совпал с ростом продаж на 8%. Это одна компания и одна страница: повод провести собственное сравнение, но не прогноз. Мы не обещаем позиций или выручки от работ над скоростью. Запишите конверсию шаблона до исправления и сравните после, с поправкой на кампании и сезон, в Персидском заливе особенно с поправкой на Рамадан и распродажи.

Заложите время на доказательство. Полевые данные охватывают 28 дней, поэтому исправление видно полностью примерно через месяц, и проверка в Search Console тоже следит за 28-дневным окном. Собственный скрипт с web-vitals даст сигнал за считаные дни.

FAQ

Источники

• web.dev: Web Vitals
• HTTP Archive, Web Almanac 2025: Performance
• HTTP Archive, Web Almanac 2025: Third Parties
• Google Search Central: Understanding page experience
• web.dev: Optimize LCP