Время ответа сервера: почему оно важнее скорости загрузки

Клиент жалуется: сайт медленный. Смотрим — картинки ужаты, скриптов немного, кеш браузера настроен. По всем признакам страница должна открываться мгновенно. А она открывается за пять секунд, и первые три из них экран просто белый: браузер уже отправил запрос, но ещё ничего не получил.

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

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

Что происходит в эти секунды

Когда посетитель открывает страницу, последовательность примерно такая.

Браузер узнаёт, по какому адресу находится сервер. Это обращение к службе доменных имён, обычно быстрое, но при неудачных настройках может занимать заметное время.

Браузер устанавливает соединение с сервером и договаривается о защищённом обмене. Тут добавляется ещё немного времени, зависящее от расстояния и настроек.

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

И только после этого начинает отдавать результат браузеру.

Длиннее всего обычно третий шаг — работа системы управления. Именно в нём кроется большинство проблем.

Какие значения нормальные

Ориентиры примерно такие.

До 200 миллисекунд — отлично. Так работает хорошо настроенный сайт на нормальном сервере с включённым кешированием.

От 200 до 500 миллисекунд — нормально. Посетитель не чувствует задержки.

От 500 миллисекунд до секунды — заметно. Ощущается как «подтормаживает».

От секунды до двух — плохо. Часть посетителей уходит, особенно пришедших по рекламе.

Больше двух секунд — критично. Белый экран такой длины воспринимается как неработающий сайт.

Проверить своё значение просто: в браузере есть инструменты разработчика, во вкладке с сетевыми запросами видно время до первого байта для основного документа. Второй способ — посмотреть в Яндекс.Метрике отчёт по времени загрузки: там есть данные о реальных посетителях, а не об идеальных условиях.

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

Основные причины медленного ответа

Отсутствие кеширования. Самая частая причина. Если система управления при каждом обращении заново собирает страницу, обращаясь к базе данных десятки раз, ничего быстрого не получится. При включённом кешировании готовая страница отдаётся из подготовленного вида, и время ответа падает в разы. В ХостСМС механизмы кеширования есть — и страниц, и отдельных блоков; их надо включить и настроить под структуру сайта.

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

Разросшаяся база данных. Логи, история изменений, статистика посещений, корзины брошенных заказов, устаревшие сессии — всё это копится годами. База в несколько гигабайт, из которых полезных данных десять процентов, работает медленно вся целиком.

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

Устаревшая версия языка программирования. Переход на более свежую версию иногда ускоряет работу сайта заметно, без единой правки в коде.

Обращения к внешним сервисам при сборке страницы. Если сайт при каждом открытии страницы ходит за курсом валют, остатками на складе из системы учёта или погодой, и делает это синхронно, то скорость сайта равна скорости самого медленного из этих сервисов. Когда внешний сервис недоступен, сайт встаёт полностью. Такие обращения нужно кешировать и выполнять с ограничением по времени ожидания.

Фоновые задачи в неудачное время. Ночная выгрузка каталога, пересчёт цен, формирование отчётов, резервное копирование. Если они запускаются днём, время ответа для посетителей растёт.

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

Раздутые шаблоны. Иногда страница собирается медленно просто потому, что в шаблоне двести лишних операций, накопившихся за годы доработок разными руками.

Как искать причину

Диагностику стоит вести по порядку, а не менять всё сразу.

Первое — сравните время ответа на разных страницах. Если главная быстрая, а каталог медленный, проблема в обработке каталога. Если медленно везде одинаково — скорее всего, сервер или отсутствие кеширования.

Второе — проверьте, меняется ли время в течение суток. Если утром хорошо, а вечером плохо, это нагрузка. Если скачет случайным образом — соседи по хостингу или фоновые задачи.

Третье — посмотрите логи сервера. Там видно, какие обращения приходят, сколько их, откуда. Часто выясняется, что половина запросов — от автоматических систем, а не от людей.

Четвёртое — включите в системе управления режим отладки или профилирования, если он есть. Он покажет, сколько запросов к базе делает страница и какие из них самые долгие. Обычно находится один-два запроса, которые занимают почти всё время.

Пятое — проверьте размер базы данных и давно ли делалась её очистка от служебных накоплений.

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

Что даёт наибольший эффект

По опыту, порядок по соотношению «результат к затратам» такой.

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

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

Найти и переписать самые тяжёлые запросы. Обычно это один-два места, и правка локальная.

Обновить версию языка программирования и системы управления. С обязательной проверкой совместимости модулей и с предварительным резервным копированием.

Перенести фоновые задачи на ночь и ограничить их ресурсы.

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

И только потом — менять тариф или переезжать на более мощный сервер. Это помогает, но это самое дорогое решение, и применять его стоит, когда остальное уже сделано.

Кеширование: что важно понимать заказчику

Кеширование — главный инструмент в этой теме, и вокруг него больше всего недопонимания. Разберём без технических подробностей.

Смысл простой: вместо того чтобы собирать страницу заново при каждом обращении, система сохраняет готовый результат и следующему посетителю отдаёт его. Сборка занимала секунду, отдача готового — миллисекунды.

Главный вопрос, который надо решить с подрядчиком: что кешировать нельзя. Ошибки здесь дороже, чем медленный сайт.

Корзина и личный кабинет — никогда. Иначе человек увидит чужие данные.

Страницы с индивидуальными ценами для конкретных клиентов — никогда.

Формы с защитными кодами — аккуратно, иначе заявки перестанут отправляться.

Страницы с наличием товара — с коротким временем жизни кеша, чтобы клиент не приехал за тем, чего нет.

Второй вопрос — на сколько кешировать. Слишком долго — клиенты видят старые цены. Слишком коротко — эффекта почти нет. Для страниц услуг и статей обычно ставят часы или сутки, для каталога — минуты или десятки минут.

Третий вопрос — как сбрасывать. Должна быть понятная кнопка или автоматический сброс при изменении содержимого. Иначе сотрудник поменял цену, не увидел изменений, поменял ещё раз, и так до звонка в поддержку.

Как понять, что дело именно в сервере, а не в вёрстке

Простой способ различить, не углубляясь в технику.

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

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

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

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

Особая ситуация: сайт быстрый, но не для всех

Бывает, что время ответа нормальное в среднем, а конкретные посетители жалуются. Причин несколько.

Расстояние до сервера. Для дальних регионов добавляется задержка на сам путь данных. Здесь помогает либо размещение сервера ближе к основной аудитории, либо раздача файлов через сеть доставки контента.

Мобильный интернет. На нестабильной связи каждое лишнее обращение к серверу дорого. Чем меньше файлов и чем они легче, тем лучше.

Корпоративные сети с фильтрацией. Иногда сайт медленно открывается именно в офисах клиентов из-за настроек их сети.

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

Поэтому смотреть надо не на средние цифры, а на распределение: в Яндекс.Метрике видно время загрузки по регионам, по типам устройств и по новым посетителям отдельно.

Почему это про заявки, а не про технику

Медленный сервер — это не абстрактная техническая характеристика. Это прямая потеря обращений, причём невидимая: человек, который не дождался загрузки, нигде не отражается как потерянный клиент. Он просто не пришёл.

Особенно дорого это обходится на платном трафике: за клик вы заплатили, а страница не открылась. И на мобильных: там терпение короче.

Есть простой способ увидеть масштаб. В Яндекс.Метрике сравните показатель отказов у посетителей, у которых страница открылась быстро, и у тех, у кого медленно. Разница обычно впечатляет. Дальше умножьте на количество посетителей и на вашу обычную долю обращений — получите оценку потерь в заявках.

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

Как это связано с продвижением 3 в 1

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

Поиск. Медленный сайт хуже обходится поисковыми роботами: при ограниченном времени на обход робот успевает посмотреть меньше страниц, и большой каталог может индексироваться месяцами. Для нейропоиска ситуация похожая — его роботы тоже ходят по сайту, и если сервер отвечает долго или отдаёт ошибки под нагрузкой, часть содержимого просто не попадает в их картину мира. Компания, чьи факты не собраны, не может быть процитирована в генеративном ответе. Плюс прямое влияние: человек, вернувшийся в выдачу из-за долгой загрузки, ушёл к конкуренту.

Яндекс.Справочник. Карточка в Яндекс Картах работает независимо от вашего сервера, и это её сильная сторона: даже когда сайт тормозит, звонки из карточки идут. Но переход из карточки на сайт — обычный сценарий, и белый экран на три секунды его обрывает. Поэтому карточку стоит вести полноценно: с услугами, ценами, фотографиями и телефоном, чтобы человек мог принять решение, даже не дойдя до сайта.

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

Обращения из трёх точек надо считать вместе. Бывает, что после ускорения сайта растёт количество заявок с форм, а количество звонков остаётся прежним — это нормально и означает, что часть аудитории просто перешла из карточек на сайт. Общая картина видна только при общем учёте.

Что сделать в ближайшее время

Измерьте время ответа на главной, на странице услуги и на странице каталога. Запишите цифры.

Посмотрите в Яндекс.Метрике время загрузки по регионам и устройствам.

Проверьте, включено ли кеширование, и если нет — включите с аккуратными исключениями.

Оцените размер базы данных и когда её последний раз чистили.

Посмотрите логи: сколько обращений приходит от роботов и в какое время суток пики.

Проверьте расписание фоновых задач.

Повторите измерения после изменений и сравните с исходными цифрами.

И через месяц посмотрите на количество обращений — это единственный показатель, который в итоге имеет значение.

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