Почему сайт тормозит и как его ускорить

• Сначала разберитесь, что значит «медленно»
• В девяти случаях из десяти виноваты картинки
• Каждый заход собирает страницу заново
• Слишком много всего
• Старый PHP — медленный PHP
• Есть задержки, которые кэшем не убрать
• За что тогда платить хостингу
• Проверка на пять минут

Вам пишут: «у тебя сайт на телефоне грузится целую вечность». Или вы из любопытства прогоняете его через PageSpeed Insights и получаете 34 балла в красной зоне, а рядом — экран предупреждений, половину из которых видите впервые. Ощущение одно: сайт медленный, а почему — непонятно.

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

Сначала разберитесь, что значит «медленно»#

За словом «медленно» прячутся две разные проблемы. Первая — сколько сервер думает, прежде чем вообще начать отвечать (время до первого байта). Вторая — всё, что браузер делает потом: скачивает картинки, скрипты и шрифты и собирает из них страницу. Бывает, что сервер отвечает мгновенно, а страница всё равно ощущается тяжёлой, потому что вместе с ней приезжают четыре мегабайта фотографий. Обратный случай тоже встречается: сама страница лёгкая, но первые пару секунд на экране ничего не происходит — сервер занят.

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

В девяти случаях из десяти виноваты картинки#

Ставлю на картинки, даже не открывая ваш сайт.

Схема везде одна и та же: фотографию заливают прямо с телефона или из фотостока — четыре тысячи пикселей в ширину, три-четыре мегабайта — и вставляют в блок, который на экране занимает от силы 600 пикселей. Браузер скачивает файл целиком и лишь потом ужимает его до нужного размера. Теперь представьте галерею из двадцати таких файлов: вот и весь ваш «медленный сайт».

Лечится это обычной рутиной:

• Уменьшите картинки до того размера, в котором они выводятся на странице. Ширины 1600 пикселей хватает почти под любой макет.
• Сожмите их: Squoosh или TinyPNG срезают вес вдвое и больше, а на глаз разницы никакой.
• Отдавайте WebP или AVIF. Они заметно легче старых JPEG и PNG, и их понимают все актуальные браузеры.
• Включите отложенную загрузку (lazy load), чтобы картинки ниже первого экрана подгружались, только когда до них долистали.

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

Каждый заход собирает страницу заново#

Большинство динамических сайтов, и WordPress в их числе, собирают страницу с нуля на каждый запрос: выполняют PHP, ходят в базу, склеивают HTML. Пока посетитель один, этого никто не замечает. Но когда одну и ту же неизменившуюся страницу пересобирают для тысячи человек подряд, сервер занят работой впустую.

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

Вот здесь хостинг важен. Наши серверы работают на LiteSpeed, а для WordPress есть бесплатный плагин LiteSpeed Cache: он цепляется прямо к серверу и кэширует страницы на уровне самого сервера, минуя PHP, где это медленнее. Настроили один раз — и большинство посетителей получают готовую страницу за считаные миллисекунды.

Слишком много всего#

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

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

Старый PHP — медленный PHP#

А вот про версию PHP забывают с завидным постоянством, хотя приём почти бесплатный: каждая крупная версия ощутимо быстрее предыдущей. Сайт, который до сих пор крутится на PHP 7.4, заметно прибавит от одного только перехода на 8.2 или 8.3, зачастую без единой другой правки. В cPanel версия переключается самостоятельно, в разделе «Select PHP Version»: сначала проверьте на копии, потом переключайте боевой сайт. Пять минут — и тот же код работает быстрее.

Есть задержки, которые кэшем не убрать#

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

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

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

За что тогда платить хостингу#

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

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

У нас каждый аккаунт работает под CloudLinux: сайту выделены гарантированные процессор, память и скорость диска, и всплеск нагрузки на соседнем аккаунте их не отъедает. Под сайтами стоят корпоративные SSD в RAID-массиве, а не изношенные диски, на которых до сих пор сидит немало дешёвых хостингов. Экзотики в этом никакой, обычный минимум — просто обеспечивают его далеко не все.

Проверка на пять минут#

Сначала замер, из региона ваших посетителей: оптимизировать вслепую бессмысленно. Дальше картинки, потом кэш (на WordPress — LiteSpeed Cache), потом ревизия плагинов и скриптов, потом версия PHP. После каждого шага смотрите на цифры и останавливайтесь, как только сайт стал достаточно быстрым. А если он и после этого медленный, а сервер далеко или перегружен, — вот теперь пора менять хостинг.

Большинство этих правок ничего не стоят и делаются за вечер. За хостингом остаются гарантированные ресурсы и сервер поближе к вашим читателям.

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