Почему сайт медленно грузится: замеры до и после на моём сайте

Сайт медленно открывается, когда браузеру приходится скачивать слишком много данных или слишком тяжелые файлы, а сервер отдаёт это без сжатия, без кэша и по старому протоколу. Я проверил это на собственном сайте 30 октября 2026 года: до правок страница кейса на телефоне показывала самый большой элемент за 4,82 секунды, после правок за 2,27. Главная страница с 3,08 секунды ускорилась до 2,13.

Ниже цифры, что именно тормозило, чего я не смог исправить и как проверить свой сайт без программиста.

Что я измерил и как

Я использовал Lighthouse версии 12.8.2 в браузере Chrome на Mac, по три прогона на страницу и устройство, в таблице медиана. Режим телефона: Lighthouse моделирует медленный мобильный интернет 4G и процессор в четыре раза медленнее обычного. Показатель LCP это время, за которое на экране появляется самый крупный элемент страницы: большая картинка или блок текста. У Google есть пороги: до 2,5 секунды хорошо, от 2,5 до 4 секунд нужно улучшать, больше 4 секунд плохо. По правилу Google, оценивать нужно 75-й процентиль реальных загрузок страницы.

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

Что получилось

Страница	Телефон до, с	Телефон после, с	Балл до	Балл после
Главная	3,08	2,13	90	98
Страница услуги	2,74	2,00	96	98
Страница кейса	4,82	2,27	82	98

В столбцах время LCP в секундах и итоговый балл Lighthouse из 100. До правок страница кейса стояла в красной зоне порогов Google, главная и услуга в жёлтой. После правок все три в зелёной. На компьютере всё и так было быстро: главная с 0,69 секунды ускорилась до 0,52.

Что тормозило и что я сделал

На сервере включил протокол HTTP/2 и более сильное сжатие. Файлам поставил срок хранения в кэше на год, чтобы повторный посетитель не скачивал их заново. Картинки отдаю по размеру места на экране: маленькому снимку на экране телефона не нужен файл для ноутбука. Скрытая тема оформления больше не загружается, пока посетитель её не включил.

В числах вес страниц изменился так:

Страница	Вес до, КБ	Вес после, КБ
Главная	297	241
Страница услуги	213	184
Страница кейса	721	457

Больше всего выиграла страница кейса: на ней много снимков, и лишние пиксели стоили около 260 КБ.

Сколько дали картинки и код, а сколько сервер

Чтобы разделить эффекты, я собрал старую и новую версии сайта на одном и том же локальном сервере с одинаковым сжатием и кэшем, без HTTP/2 и без сети. Тогда разница показывает только изменения в самих страницах. На странице кейса LCP на телефоне получился 4,35 секунды против 2,92 после правок в страницах, вес 693 против 457 КБ. На главной разница меньше: 2,68 против 2,53 секунды. На живом сайте страница кейса дала 4,82 против 2,27. Разницу между 2,92 и 2,27 я отношу к настройкам сервера, но отдельно её не измерял.

Что не удалось исправить и где замер не радует

Я проверил цифры вторым способом: не расчётным замедлением, а настоящим замедлением в браузере. Там главная ускорилась скромнее: LCP с 2,99 до 2,68 секунды. Показатель TBT, время, пока страница занята и не отвечает на нажатия, у главной вырос со 158 до 184 миллисекунд. Страница кейса: LCP с 3,27 до 2,47 секунды, TBT с 33 до 46 миллисекунд.

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

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

Как проверить свой сайт без программиста

Откройте страницу в Chrome, нажмите F12, вкладка Lighthouse, режим «Мобильное устройство», нажмите «Начать». Запустите замер три раза и возьмите среднее: один прогон врёт. Смотрите на LCP и на список подсказок внизу.

Самые частые находки, которые я видел у себя: картинки тяжелее, чем нужно; сервер не сжимает файлы; файлы не кэшируются; посетитель получает то, чего ещё не просил. Проверить сжатие и протокол можно в той же панели F12, вкладка «Сеть»: у запроса главной страницы в колонке протокола (её можно включить правой кнопкой по заголовку таблицы) должно стоять h2, а в заголовках ответа должна быть строка content-encoding. Расшифрую: h2 это HTTP/2, content-encoding показывает, что файл сжат.

Сторонние скрипты (счётчики, виджеты, чаты) тоже тормозят страницу. На моём сайте счётчик Яндекс Метрики не загружается, пока посетитель не согласился в окне про cookie, поэтому первый заход он не замедляет. Про это подробнее в статье «Cookie-баннер и Яндекс Метрика».

Нужна ли вам помощь

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

Скорость не единственная причина, по которой сайт теряет посетителей, и она не гарантирует позиций в поиске: быстрая страница с плохим текстом всё равно не найдётся. Но медленный сайт не поможет ни рекламе, ни SEO. Такие проверки входят в мою поддержку сайта: я на этом зарабатываю. Хотите разобрать свой сайт, пришлите адрес, я пришлю замер и объясню, что из него следует.

Источники

• web.dev: Largest Contentful Paint (LCP): пороги 2,5 и 4 секунды, 75-й процентиль, какие элементы считаются.
• Собственный замер сайта esaweb.ru, 30 октября 2026 года, Lighthouse 12.8.2: до и после правок, подробные таблицы лежат в рабочих записях сайта.