Сайт медленно загружается по двум независимым причинам, и лечатся они разными способами. Первая — сервер долго готовит ответ: запрос ушёл, а первый байт возвращается через 800–2000 мс вместо нормальных 200 мс. Вторая — ответ пришёл быстро, но дальше браузер минуту выкачивает четыре десятка картинок и два десятка скриптов. Переезд на площадку из раздела VPS для сайтов чинит только первую половину задержки. Там собрано 15 провайдеров со стартовой ценой от 139 ₽/мес, но ни один из них не сожмёт ваши фотографии за вас.
Материал для владельца сайта на WordPress, Bitrix, OpenCart или самописном PHP, у которого страница открывается 5–10 секунд и неясно, куда смотреть первым делом. Разберём, как разделить серверную и страничную часть задержки, какой TTFB (время до первого байта ответа) считается нормой, сколько добавляет SQL-запрос без индекса, во сколько раз кэш сокращает время ответа и что реально исправляет смена хостинга.
Время загрузки складывается из трёх отрезков, и тормозит обычно один
Когда посетитель жмёт на ссылку, происходят три вещи подряд. Сначала браузер находит IP вашего домена через DNS — это 20–120 мс, и на эту цифру вы почти не влияете. Потом сервер принимает запрос, запускает PHP, ходит в базу данных и отдаёт первый байт HTML — это и есть TTFB, Time To First Byte, «время до первого байта». Затем браузер разбирает полученный HTML и докачивает всё, на что тот ссылается: стили, шрифты, картинки, скрипты аналитики и виджетов.
Общее время загрузки страницы — сумма этих трёх отрезков. Ошибка новичка в том, что он видит «сайт грузится 8 секунд» и идёт менять хостинг. Но если TTFB равен 180 мс, а остальные 7,8 секунды уходят на 3,5 МБ несжатых фотографий, новый сервер не даст и полсекунды выигрыша.
Поэтому первый шаг всегда один: измерить TTFB отдельно от всего остального. Дальше вы уже точно знаете, чинить сервер или чинить страницу. TTFB — зона ответственности хостинга и кода, всё после него — зона вёрстки и контента.
Какой TTFB считается нормой, а какой — поводом менять площадку
TTFB измеряется одной командой в терминале и не требует ни плагинов, ни регистраций. Наберите curl -o /dev/null -s -w "%{time_starttransfer}n" https://вашсайт.ru/ — команда скачивает страницу в никуда и печатает единственное число: секунды до первого байта. Запустите её пять раз и смотрите на средний результат: первый запуск часто попадает мимо кэша и завышен.
Ориентиры по цифрам ниже. Важная деталь: измерять надо не главную страницу, а тяжёлую — карточку товара, страницу поиска, категорию с фильтрами. Главная почти всегда закэширована и врёт в вашу пользу.
| TTFB | Что это значит | Что делать |
|---|---|---|
| до 200 мс | Норма, сервер не узкое место | Работать с картинками и скриптами |
| 200–600 мс | Терпимо, но запас есть | Включить кэш страниц и OPcache |
| 600–1500 мс | Проблема на сервере или в базе | Искать медленные SQL-запросы, проверять соседей по тарифу |
| больше 1500 мс | Сервер не справляется | Менять тариф или площадку |
Если тяжёлая страница отдаёт первый байт за 250 мс, а лёгкая — за 1,2 секунды, дело не в мощности железа, а в конкретном куске кода: где-то в шаблоне висит запрос, который выполняется по 900 мс.
Что тормозит на стороне сервера: соседи, лимиты и диск
На виртуальном хостинге ваш сайт живёт на одной машине с сотней-двумя чужих сайтов. Процессор делится между всеми, и когда сосед запускает выгрузку каталога на 200 тысяч товаров, ваши страницы начинают отвечать за 3 секунды вместо 400 мс. Диагностировать это изнутри почти невозможно — вы видите лишь, что скорость плавает по часам суток. Разбор различий между двумя моделями есть в сравнении виртуальный хостинг или VPS.
На виртуальном сервере та же беда называется CPU steal time — это доля времени, которую гипервизор отобрал у вашей машины в пользу другой виртуалки на том же физическом узле. Проверить это можно командой top — она показывает текущую нагрузку сервера и обновляется каждые пару секунд. В строке загрузки процессора есть поле st: это и есть steal time в процентах. Ноль или доли процента — нормально. Устойчивые 5–15 % означают, что провайдер продал на одном узле больше ресурсов, чем там есть, и лечится это только переездом.
Третья серверная причина — диск. Медленный HDD выдаёт 80–180 операций ввода-вывода в секунду, SSD — десятки тысяч, NVMe — сотни тысяч. Этот показатель называется IOPS, и он критичен именно для баз данных, которые дёргают диск мелкими кусочками. Стартовый тариф RuVDS за 139 ₽/мес идёт с 10 ГБ HDD, и для WordPress с сотней товаров этого хватит впритык; сайт с активной базой уже требует VPS на SSD.
База данных: один запрос без индекса добавляет 300–2000 мс
Средняя страница WordPress выполняет 30–80 запросов к базе, страница каталога в интернет-магазине — от 150 до 400. Пока в таблицах несколько тысяч строк, разницы не видно. Когда товаров становится 50 тысяч, а заказов 200 тысяч, один запрос без нужного индекса начинает перебирать таблицу целиком и добавляет к ответу от 300 до 2000 мс. Индекс — это служебная структура, которая позволяет базе найти строку сразу, не читая все остальные.
Найти виновника проще, чем кажется. В конфиг MySQL добавьте две строки: slow_query_log = 1 включает журнал медленных запросов, а long_query_time = 0.5 задаёт порог в секундах (точка, а не запятая — конфиг понимает только её). После перезапуска базы она сама запишет все запросы дольше половины секунды. Через сутки в логе видно, какие 3–5 запросов повторяются чаще всего.
Вторая частая история — раздувшиеся служебные таблицы. У WordPress это wp_options с автозагружаемыми записями: плагины годами пишут туда мусор, и таблица на 40 МБ читается при каждом обращении к любой странице. Чистка автозагрузки нередко снимает 200–400 мс с TTFB, и это бесплатно.
Кэш страниц сокращает время ответа в 5–20 раз
Без кэша сайт собирает каждую страницу заново для каждого посетителя: запускает PHP, читает базу, склеивает шаблон. С кэшем готовый HTML сохраняется в файл и следующие 100 человек получают его почти мгновенно. Включённый кэш страниц сокращает время ответа в 5–20 раз — это самая дешёвая оптимизация из всех существующих, потому что делается галочкой в плагине.
Второй слой — OPcache, встроенный в PHP механизм, который хранит уже скомпилированный байт-код скриптов в памяти. Без него интерпретатор перечитывает и разбирает все файлы CMS при каждом запросе. Включается одной строкой opcache.enable=1 в конфиге PHP и даёт на типовой CMS выигрыш в 30–50 % по времени генерации страницы.
Оба слоя работают только там, где вы управляете конфигурацией. На дешёвом виртуальном хостинге OPcache бывает выключен или урезан по памяти до 32 МБ, и его нельзя поднять. Это одна из немногих причин, по которым переезд действительно даёт мгновенный выигрыш.
Картинки дают 60–70 % веса страницы
Откройте инструменты разработчика браузера клавишей F12, перейдите на вкладку «Сеть» и отсортируйте запросы по размеру — картинки займут первые двадцать строк. На типовом сайте они дают 60–70 % от общего веса страницы, и это самая недооценённая статья расходов. Фотография с телефона весит 4–6 МБ, а в блоке на сайте показывается на ширину 800 пикселей — то есть 95 % скачанных байт выбрасываются.
Перевод изображений в формат WebP снимает 25–50 % объёма при том же визуальном качестве. Второй приём — атрибут loading="lazy" у тега картинки: он говорит браузеру не грузить изображение, пока пользователь до него не долистал. На длинной странице с 40 картинками это экономит 2–3 МБ трафика при первом открытии.
Третий приём — задать ширину и высоту каждой картинки прямо в разметке. Без них вёрстка прыгает по мере загрузки, и метрика LCP, показывающая, когда отрисовался самый крупный элемент экрана, портится даже на быстром сервере. Порог «хорошего» LCP — 2,5 секунды.
Скрипты, шрифты и чужие виджеты
Каждый внешний скрипт — это отдельное соединение с чужим сервером, и вы не управляете его скоростью. Счётчик аналитики, чат поддержки, карта проезда, пиксель рекламной сети — вместе они добавляют 1,5–3 секунды к отрисовке, потому что браузер приостанавливает разбор HTML, пока грузит синхронный скрипт.
Лечится двумя атрибутами. defer велит браузеру скачать скрипт параллельно и выполнить после разбора страницы, async — выполнить сразу по готовности. Для счётчиков и чатов подходит defer, и одна эта правка нередко снимает секунду с момента, когда страница становится кликабельной.
Три начертания одного шрифта в формате WOFF2 весят 250–350 КБ и грузятся до отрисовки текста, если не указан font-display: swap. Свойство разрешает показать текст системным шрифтом сразу и подменить его, когда файл догрузится. Статику имеет смысл раздавать через CDN, если посетители у вас по всей стране.
Что чинится переездом на VPS, а что нет
Смена площадки — сильный инструмент, но узкий. Он влияет на TTFB и почти не влияет на всё, что происходит в браузере после получения HTML. Ниже честная разбивка причин по тому, поможет ли переезд.
Если ваши проблемы из нижней половины таблицы, деньги на новый сервер уйдут впустую: те же два дня правильнее потратить на картинки и скрипты.
| Причина медленной загрузки | Помогает ли переезд | Что делать |
|---|---|---|
| Соседи по хостингу съедают процессор | Да, полностью | VPS с выделенными ядрами |
| Диск HDD, база упирается в IOPS | Да, полностью | Тариф с NVMe или SSD |
| OPcache выключен, память PHP урезана | Да | Свой сервер с доступом к конфигам |
| Мало оперативной памяти, сайт уходит в своп | Да | Тариф от 2 ГБ RAM |
| SQL-запрос без индекса на 1,5 с | Частично, 20–30 % | Индексы и лог медленных запросов |
| Картинки по 4 МБ без сжатия | Нет | WebP и lazy loading |
| Двадцать внешних скриптов | Нет | defer, удаление лишних виджетов |
| Тема с пятью слайдерами на главной | Нет | Переработка шаблона |
Сколько стоит сервер, на котором сайт отвечает быстро
Для сайта-визитки или блога с посещаемостью до 1000 человек в сутки хватает 1 ядра и 1–2 ГБ памяти. Магазину на 5–10 тысяч товаров нужно уже 2 ядра и 4 ГБ: база при поиске по фильтрам держит индексы в памяти. Ниже стартовые цены по разделу.
| Провайдер | Стартовая цена | Конфигурация входа | Тарифов в каталоге |
|---|---|---|---|
| RuVDS | от 139 ₽/мес | 1 ядро, 0,5 ГБ, 10 ГБ HDD | 440 |
| SprintHost | от 139 ₽/мес | 1 ГБ, 8 ГБ SSD | 55 |
| IHC | от 144 ₽/мес | 1 ядро, 0,6 ГБ, 8 ГБ SSD | 86 |
| SmartApe | от 145 ₽/мес | 2 ядра, 2 ГБ, 100 ГБ NVMe | 23 |
| FASTVPS | от 165 ₽/мес | 1 ядро, 1 ГБ, 10 ГБ SSD | 36 |
| JustHost.ru | от 289 ₽/мес | 1 ядро, 1 ГБ, 20 ГБ NVMe | 27 |
| AdminVPS | от 299 ₽/мес | 1 ядро, 1 ГБ, 15 ГБ NVMe | 149 |
Данные проверены 03.09.2026.
По всему разделу стартовые цены укладываются в вилку от 139 до 330 ₽/мес; в таблице выше — семь самых доступных провайдеров. Если сомневаетесь в конфигурации, берите тариф на ступень выше входного. Два гигабайта памяти вместо одного стоят 100–200 ₽ сверху и снимают риск ухода в своп — так называют ситуацию, когда памяти не хватает и система начинает использовать вместо неё диск, отчего сайт замедляется в разы. Готовые сборки с преднастроенным веб-сервером есть в подборке VPS с Nginx.
Порядок действий, если сайт открывается 8 секунд
Диагностика занимает вечер и не требует ничего, кроме браузера и терминала. Идти надо сверху вниз: каждый следующий шаг имеет смысл, только если предыдущий не дал ответа. Начинать с покупки нового сервера — самая дорогая из ошибок.
Перед началом снимите бэкап базы и файлов: часть шагов меняет конфигурацию.
- Замерьте TTFB командой
curlна трёх страницах: главной, карточке товара и странице поиска. Запишите три числа. - Откройте вкладку «Сеть» в инструментах разработчика, обновите страницу мимо кэша браузера сочетанием Ctrl+F5 и посмотрите общий вес и число запросов. Ориентир — до 1,5 МБ и до 60 запросов.
- Отсортируйте запросы по размеру. Если сверху картинки — задача в них, и сервер ни при чём.
- Включите кэш страниц в CMS и замерьте TTFB заново. Падение в 5 раз и больше означает, что кэша не было.
- Проверьте
stв выводеtop. Устойчивые 5–15 % — переподписка узла, повод менять площадку. - Включите лог медленных запросов с порогом 0,5 с и вернитесь к нему через сутки.
- Только после этого принимайте решение о переезде — с цифрами на руках, а не по ощущениям.
Замеры делайте в одно и то же время суток: нагрузка на общий хостинг скачет, и утренние 300 мс превращаются в вечерние 1400 мс без единой правки с вашей стороны.
Частые ошибки
Большинство неудачных попыток ускорить сайт повторяют один и тот же набор решений. Они выглядят логично, но либо не касаются реальной причины, либо создают новую проблему поверх старой.
Каждый пункт ниже встречается в письмах читателей не по одному разу, и почти всегда он обходится в потраченные впустую деньги или испорченную вёрстку.
- Покупать сервер мощнее, не измерив TTFB: если он и так 180 мс, удвоение ядер не изменит ничего.
- Ставить три плагина кэширования сразу — они конфликтуют и отдают посетителям чужие корзины.
- Сжимать картинки до 40 % качества и получать заметные артефакты вместо экономии 25–50 % через WebP.
- Оставлять на сайте счётчики и пиксели, которыми никто не пользуется два года.
- Переезжать на новую площадку, не перенеся настройки PHP: тот же сайт на дефолтном конфиге может стать медленнее.
Частые вопросы
Почему сайт медленно загружается только у меня, а у других открывается быстро? Скорее всего, дело в кэше браузера и маршруте до дата-центра. Проверьте страницу с телефона по мобильному интернету и в режиме инкогнито: если там быстро, проблема локальная и сайт ни при чём.
Сайт долго грузится по вечерам, а утром нормально — что это? Классический признак переподписанного узла: соседи по железу активны в пиковые часы. Посмотрите поле st в top вечером; устойчивые 5–15 % подтверждают догадку, и тогда помогает только смена площадки.
Насколько ускорит сайт переход с виртуального хостинга на VPS? Выигрыш идёт целиком за счёт TTFB и составляет обычно от 2 до 5 раз, если раньше вы упирались в чужую нагрузку и урезанный OPcache. Общее время загрузки при этом сократится ровно на ту долю, которую занимал TTFB, — если он был 200 мс из 8 секунд, разницы не заметит никто.
Сколько памяти нужно, чтобы сайт не тормозил? Блогу и визитке хватает 1–2 ГБ, магазину на 5–10 тысяч товаров нужно 4 ГБ, потому что MySQL держит индексы в оперативной памяти. Признак нехватки — сайт нормально работает первые часы после перезагрузки, а потом постепенно замедляется.
Помогает ли CDN, если сервер и так в Москве, а посетители по всей России? Да, но только для статики: картинки, стили и шрифты начнут отдаваться с ближайшего узла, и это снимает 100–300 мс на дальних регионах. На TTFB динамических страниц CDN не влияет — HTML всё равно генерирует ваш сервер.
Можно ли ускорить сайт без программиста? Большую часть — да. Кэш страниц, WebP, lazy loading, удаление лишних плагинов и виджетов делаются в панели CMS. Программист нужен там, где надо добавлять индексы в базу и переписывать запросы в теме.
Как понять, что виновата тема, а не хостинг? Временно переключитесь на стандартную тему CMS и замерьте TTFB и вес страницы заново. Если после переключения страница похудела с 4 МБ до 900 КБ, а число запросов упало вдвое — проблема была в шаблоне.
Итог
Медленная загрузка почти никогда не имеет одной причины: обычно это 600 мс лишнего TTFB из-за общего хостинга плюс 3 МБ несжатых картинок плюс полсекунды на чужие скрипты. Разделите задержку на серверную и страничную части, прежде чем что-то покупать. Это займёт вечер и сэкономит месяцы платы за мощности, которые вам не нужны. Кэш страниц и WebP дают самый быстрый результат при нулевом бюджете.
Если замеры показали, что упираетесь именно в сервер, подобрать тариф под нагрузку можно в разделе VPS для сайтов — там 15 провайдеров, стартовые цены от 139 ₽/мес и фильтры по памяти, типу диска и расположению дата-центра. А что делать с сервером после покупки, разобрано в руководстве как оптимизировать VPS.
