Почемусайтмедленнозагружаетсяикакегоускорить

Сайт медленно загружается почти всегда по одной из четырёх причин: сервер долго думает, картинки слишком тяжёлые, чужой скрипт держит страницу или база делает лишнюю работу. Поэтому ускорение начинается с замера, а не с плагина. На магазине L’TERRIAS оформление заказа открывалось 11,9 секунды из-за одного чужого скрипта. Сняли его, и стало 1,06 с. Дорогой тариф хостинга тут бы не помог.

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

Откройте PageSpeed Insights, вставьте адрес страницы и смотрите вкладку для мобильных. В отчёте два разных блока, и их часто путают.

Верхний блок показывает реальных посетителей Chrome за последние 28 дней. Нижний, с баллом от 0 до 100, это разовый тест на симуляции среднего телефона. Решения принимайте по верхнему. У маленького сайта его может не быть, потому что посетителей мало, и тогда остаётся только тест.

Показатель	Что значит простыми словами	Хорошо	Терпимо	Плохо
LCP	когда появился главный блок страницы	до 2,5 с	до 4 с	больше 4 с
INP	как быстро страница реагирует на нажатие	до 200 мс	до 500 мс	больше 500 мс
CLS	насколько прыгает вёрстка при загрузке	до 0,1	до 0,25	больше 0,25
TTFB	сколько сервер думает до первого байта	до 0,8 с	до 1,8 с	больше 1,8 с

Первые три строки это Core Web Vitals. Пороги и способ оценки описаны в документации PageSpeed: считается 75-й перцентиль, то есть три посетителя из четырёх должны уложиться в норму. TTFB в этот набор не входит, но он сразу показывает, виноват ли сервер.

Три вещи, на которых обычно спотыкаются:

• Тест идёт из дата-центров Google в Северной Америке, Европе или Азии. Для сервера в России время ответа в нём может выйти хуже, чем у ваших покупателей.
• Главная ничего не говорит про каталог. Мерьте отдельно главную, каталог, карточку товара и страницу услуги.
• Корзину и личный кабинет сервис не откроет. Откройте их сами: F12, вкладка Network, обновите страницу и отсортируйте запросы по времени.

Время ответа сервера можно снять из командной строки, со своего компьютера и своего города:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}\nTotal: %{time_total}\n" https://site.ru/catalog/

В PowerShell вместо curl пишите curl.exe, /dev/null замените на NUL. Запустите три раза подряд. Если первый раз вышло 5 секунд, а потом 0,3, кэш работает. Если каждый раз 5 секунд, кэша нет или страница его обходит.

В Яндексе смотрите индекс скорости в Вебмастере, раздел «Качество сайта». По описанию Яндекса он считается по реальным переходам из мобильной выдачи и пересчитывается примерно раз в месяц. Если данных мало, блока просто нет, и это не значит, что сайт медленный. Метрика тоже показывает время загрузки страниц.

Влияет ли скорость сайта на позиции в поиске

Google рекомендует добиваться хороших Core Web Vitals для успеха в поиске, но веса этого сигнала не раскрывает. Яндекс в справке пишет про другое: посетитель может не дождаться страницы и уйти, а доверие и посещаемость падают.

Я считаю скорость в заявках, а не в позициях. Человек с телефона, который не дождался оформления заказа, это потерянная покупка при любом месте в выдаче.

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

Что вы видите	Где причина	Что делать первым
Белый экран, TTFB больше 1,8 с	Сервер, кэш, PHP, база	Проверить кэш и тяжёлые запросы
Текст уже есть, большая картинка приезжает последней	Вес и формат картинок	Сжать, задать размеры, снять lazy с первого экрана
Страница пустая, потом появляется разом	Синхронный скрипт или стили	Найти его во вкладке Network
Кнопки нажимаются с задержкой	Тяжёлый JavaScript, плохой INP	Снимать виджеты по одному и мерить
Блоки прыгают при загрузке	Нет размеров у картинок и баннеров, шрифты	Задать width и height, оставить место под баннер
Главная быстрая, каталог и кабинет тормозят	База и запросы	Смотреть запросы именно на этой странице

Сервер: что делать, если TTFB большой

Пока сервер думает, браузер ещё не начал грузить картинки, поэтому при большом TTFB их можно отложить.

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

Дальше по порядку:

1. Кэш страниц. Без него каждый посетитель заново запускает PHP и базу. На L’TERRIAS поставили WP Super Cache, а корзину, оформление, кабинет и страницы вошедших покупателей из кэша исключили. Сброс привязан к изменениям товаров, в том числе из обмена с 1С, иначе покупатель увидит старую цену.
2. Версия PHP и OPcache. Документация WordPress прямо говорит, что новые версии PHP обычно быстрее. Обновляйте только на копии: старые плагины могут упасть.
3. Тариф хостинга. Его меняют последним, когда кэш и запросы уже в порядке, а замер всё равно упирается в процессор или диск. Если решите переезжать, порядок действий есть в статье про перенос сайта на другой хостинг.

Если сайт отдаёт ошибки, начните со статьи про ошибки 502 и 504: там другой порядок проверки.

Как уменьшить вес картинок на сайте

Страница каталога L’TERRIAS весила 13,7 МБ, после правок стала 1,2 МБ. Это замер на боевом сайте. Судя по цифрам, почти весь лишний вес давал один файл: фоновый PNG на 12,5 МБ. Его заменили на JPG в 201 КБ.

На копии того же сайта главная ужалась с 22,6 до 2,2 МБ. В теме лежал PNG на 13,7 МБ, а рядом JPG той же картинки на 916 КБ, который просто не подключили.

Потом всю медиатеку, 1188 файлов, перевели в WebP. Фото товара стало легче почти вдвое: 207 → 116 КБ. Новые картинки конвертируются сами при загрузке, иначе через полгода всё вернулось бы обратно.

И цифра, которую легко понять неверно. Папка картинок темы ужалась с 701 до 30 МБ, когда убрали 83 неиспользуемых файла. Это место на диске, а не вес страницы: такая чистка облегчает копии и выкладку, но посетитель её напрямую не заметит.

Правила для картинок:

• Фото в WebP. Размер файла подбирайте под размер блока: карточке шириной 400 пикселей не нужен оригинал в 4000.
• Главная картинка первого экрана грузится сразу и с высоким приоритетом. Руководство web.dev по LCP прямо запрещает ставить ей ленивую загрузку.
• Остальные картинки грузятся лениво.
• У каждой картинки есть width и height, иначе вёрстка прыгает и портится CLS.

<!-- Первый экран -->
<img src="/hero.webp" width="1200" height="700" fetchpriority="high" alt="Часы на ремешке">

<!-- Всё, что ниже -->
<img src="/item.webp" width="400" height="400" loading="lazy" alt="Карточка товара">

Чужие скрипты: как один виджет вешает страницу на 11 секунд

3 сентября 2026 оформление заказа на L’TERRIAS 11 секунд стояло пустым. Плагин одной из служб доставки ставил в начало страницы синхронный скрипт с адреса, который уже не отвечал. Браузер ждал его и не рисовал ничего дальше. К этому моменту доставку вёл свой модуль, поэтому плагин просто сняли, и открытие упало с 11,9 до 1,06 с. Замер на боевом сайте.

Синхронный скрипт останавливает страницу, пока не скачается и не выполнится. Если его сервер лежит, ваша страница ждёт вместе с ним.

<!-- Страница ждёт скрипт -->
<script src="https://vidget.example/loader.js"></script>

<!-- Страница рисуется, скрипт выполнится потом -->
<script src="https://vidget.example/loader.js" defer></script>

Как найти такой скрипт: F12, вкладка Network, сортировка по времени, смотрите адреса не с вашего домена. В Chrome нужный адрес можно заблокировать прямо в инструментах разработчика и посмотреть, как страница живёт без него. defer к чужому виджету добавляйте на копии: часть скриптов рассчитана на загрузку в начале и после этого ломается.

На L’TERRIAS Bootstrap и шрифты Google тоже перенесли на свой сервер, чтобы магазин не зависел от чужих адресов.

Заведите простой список: какие счётчики, чаты, карты, капчи и пиксели стоят на сайте, кто их поставил и зачем. Часть обычно можно снять. С плохим INP работают так же: убирают или откладывают тяжёлый JavaScript. Отдельного замера именно по INP у меня пока нет, здесь опираюсь на документацию web.dev.

База данных: почему тормозит каталог, корзина или кабинет

Если главная быстрая, а каталог или кабинет нет, смотрите, что страница просит у базы.

На копии L’TERRIAS страница каталога делала 1059 запросов к базе, после правок 292. Карточка товара 726, стало 168. Ответ каталога упал с 11,4 до 3,1 с, когда вместо всего списка стали отдавать 24 карточки и кнопку «Показать ещё». Все три замера сняты на стенде в Docker под Windows, поэтому важна разница, а не сами секунды.

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

Самый наглядный случай был на gptml. Сервис принимал около 3 000 заявок в день, а база лежала одним JSON-файлом. Он копился с апреля без очистки и к сентябрю вырос до 108 МБ и 61 237 записей. Каждое сохранение переписывало файл целиком, и сервер замирал на секунды. За один день накопилась 121 заявка с пустой ошибкой. Снаружи казалось, что сломались обработчики очереди, хотя причина лежала ниже. Записи получили срок хранения и регулярную чистку.

Что проверить на своём сайте:

• Есть ли постраничный вывод в каталоге, заказах и личном кабинете.
• Сколько запросов делает страница. На WordPress это покажет плагин Query Monitor, на Битриксе Монитор производительности.
• Что растёт без срока хранения: логи, сессии, ревизии, история, временные записи.
• Что делается в момент открытия страницы, хотя можно сделать заранее или в фоне.

Как ускорить сайт на WordPress и WooCommerce

1. Снимите замер главной, каталога, карточки и оформления.
2. Включите кэш страниц, исключите корзину, оформление и кабинет.
3. Обновите PHP на копии, проверьте OPcache.
4. Если хостинг даёт Redis или Memcached, подключите постоянный кэш объектов: меньше походов в базу.
5. Откройте Query Monitor и посмотрите, какие плагины дают больше всего запросов. Неиспользуемые отключите и удалите.
6. Переведите картинки в WebP и настройте конвертацию новых.
7. Почистите базу: ревизии, просроченные временные записи, остатки удалённых плагинов. Перед этим снимите копию.

Плагин-комбайн для ускорения ставьте после этих шагов. Поверх фона на 12 МБ он мало что изменит.

Битрикс медленно работает: что смотреть

Здесь пишу по документации Битрикса, своего замера до и после в этой статье нет.

Панель производительности лежит в разделе «Настройки → Производительность». Монитор производительности включается на короткое время и собирает статистику по страницам, компонентам и SQL-запросам, после чего видно, что именно тяжёлое. Композитный сайт ускоряет отдачу готовых страниц, но требует настройки nginx и не отменяет работу с кодом и запросами.

Что не ускоряет сайт, хотя обещает

• Погоня за баллом 100. Балл считается на симуляции. Важнее зелёные показатели реальных посетителей.
• Ленивая загрузка всего подряд. Если отложить главную картинку, LCP станет хуже.
• Дорогой тариф вместо поиска причины. Один тяжёлый файл или мёртвый скрипт тариф не вылечит.
• Разовая чистка. Новый виджет и новые картинки возвращают всё обратно. Проверяйте скорость после каждого крупного изменения.

Когда звать специалиста

Сами вы можете снять замер, сжать картинки, убрать лишние виджеты и включить кэш на простом сайте.

Разработчик нужен, если TTFB больше 1,8 с на страницах с кэшем, тормозит оформление заказа или кабинет, есть обмен с 1С или кэш ломает корзину. В таких местах ошибка стоит дороже работы.

Разбор стоит 3 000 ₽: смотрю логи и код, называю причину и цену исправления, сумма идёт в зачёт. Дальше от 2 500 ₽ в час, а для постоянного присмотра есть абонентка от 10 000 ₽ в месяц. Подробнее на странице доработки и поддержки, пример полной пересборки магазина в кейсе L’TERRIAS. Если нужен первый взгляд, пришлите адрес и симптомы на бесплатный разбор.