Есть простой способ заставить владельца сайта задуматься о смене хостинга. Нужно несколько раз открыть собственную страницу и дождаться, пока вместо привычного мгновенного появления контента браузер секунды три показывает пустой экран. После пятой такой попытки обычно открывается сайт другого хостера и начинается изучение VPS, NVMe, количества ядер и обещаний «молниеносной скорости».
Проблема в том, что переезд помогает далеко не всегда.
Сайт может тормозить из-за сервера, но с таким же успехом причиной окажется неудачный плагин WordPress, огромная фотография на главной, медленный запрос к базе данных, внешний счетчик, неправильно настроенный кэш или скрипт, который браузер загружает с чужого сервера. Иногда хостинг действительно нужно менять. Иногда достаточно удалить одно расширение. А бывает и так, что владелец покупает VPS в четыре раза дороже, переносит туда проект и с удивлением обнаруживает те же самые три секунды ожидания.
Поэтому начинать стоит не с вопроса «какой хостинг купить вместо этого?», а с другого: где именно сайт теряет время?
Ответ можно найти даже без глубоких знаний системного администрирования, если проверять причины последовательно.
Сначала определите, что именно означает «сайт тормозит»
Фраза «медленно работает сайт» слишком расплывчата для диагностики. Два человека могут описывать ею совершенно разные проблемы.
В первом случае пользователь нажимает ссылку и несколько секунд вообще ничего не происходит, после чего страница появляется довольно быстро. Во втором сервер отвечает практически сразу, но затем браузер еще долго загружает фотографии, шрифты и JavaScript. В третьем обычные страницы открываются нормально, зато поиск по сайту работает пять секунд. В четвертом тормозит только административная панель WordPress.
Есть и более неприятный вариант: днем все летает, а вечером сайт начинает задумываться. Или проблема появляется только иногда — десять страниц открываются мгновенно, одиннадцатая внезапно загружается четыре секунды.
Все эти случаи требуют разных решений.
Поэтому первое, что нужно сделать — перестать оценивать скорость только ощущениями. Необходимо понять, медленно отвечает сам сервер или задержка возникает уже после того, как браузер начал получать страницу.
Проверьте TTFB — сколько времени сервер думает перед ответом
TTFB расшифровывается как Time to First Byte — время до получения первого байта ответа от сервера. Этот показатель не рассказывает о скорости сайта абсолютно все, но хорошо помогает понять, где искать проблему.
Представим ресторан. Вы сделали заказ и ждете. Через двадцать минут официант приносит блюдо за пять секунд. Скорость движения официанта отличная, но обед быстрее от этого не стал.
Примерно так выглядит высокий TTFB. Браузер уже запросил страницу, но сервер долго готовит ответ.
Причины могут находиться в PHP, базе данных, самой CMS, недостатке процессорных ресурсов, отсутствии кэширования или перегруженном сервере.
Если же первый ответ приходит быстро, а страница после этого еще долго собирается на экране, искать проблему только в хостинге преждевременно. Вероятнее всего, значительная часть задержки находится на стороне самой страницы: изображения, CSS, JavaScript, шрифты или сторонние сервисы.
На Hostingi.org уже есть отдельный материал о проверке и оптимизации скорости сервера, поэтому здесь важнее сам принцип диагностики: высокий TTFB направляет внимание к серверной части, низкий TTFB при долгой полной загрузке — к содержимому страницы и браузеру.
Но делать вывод по одному измерению тоже нельзя. Проверьте несколько страниц и повторите тест в разное время.
Почему главная страница может работать быстро, а остальные медленно
Очень распространенная ошибка — проверить только главную страницу.
Именно она чаще всего лучше всего кэшируется. Ее регулярно посещают пользователи и поисковые роботы, она может заранее находиться в серверном или CDN-кэше. В результате главная открывается мгновенно, хотя отдельные разделы испытывают серьезные проблемы.
Для проверки нужны разные типы страниц.
На интернет-магазине стоит открыть главную, категорию, карточку товара, результаты поиска и страницу с фильтрами. На WordPress-блоге — главную, статью, рубрику, поиск и административную панель. На форуме — список тем и конкретную большую тему.
Если медленными оказываются только определенные страницы, вероятность общей проблемы хостинга уменьшается.
Например, каталог открывается быстро, а фильтр товаров занимает пять секунд. Это уже похоже на тяжелый запрос к базе данных. Перенос на более мощный сервер способен временно улучшить ситуацию, но правильнее сначала разобраться с самим запросом.
Проверьте сайт без кэша
Кэш способен одновременно быть лучшим другом владельца сайта и прекрасным способом спрятать проблему.
Представим WordPress, которому для генерации страницы требуется две секунды. После первого запроса плагин кэширования сохраняет готовый HTML. Следующие посетители получают его за доли секунды.
Кажется, все отлично.
Но пользователь входит в личный кабинет, добавляет товар в корзину или открывает страницу, которую нельзя кэшировать. Сервер снова вынужден собирать ее динамически, и старые две секунды возвращаются.
Поэтому при диагностике важно проверить и кэшированные, и некэшированные страницы.
Если без кэша сайт становится катастрофически медленным, проблема не обязательно требует немедленного отказа от кэширования. Кэш как раз и существует для ускорения работы. Но разница показывает, насколько тяжело приложение работает само по себе.
На информационном сайте хороший полноэкранный кэш способен обслуживать огромную долю посетителей. В интернет-магазине динамических запросов значительно больше, поэтому скрыть все проблемы за кэшем уже не получится.
Один плагин WordPress может замедлить весь сайт
У WordPress есть замечательная особенность: почти любую функцию можно добавить плагином. И есть обратная сторона этой особенности: почти любой плагин получает возможность выполнять код при открытии страниц.
Количество расширений само по себе еще не определяет скорость. Хорошо написанные двадцать плагинов могут работать быстрее трех тяжелых.
Гораздо важнее, что именно они делают.
Одно расширение добавляет небольшой блок HTML. Другое при каждом открытии страницы выполняет несколько десятков запросов к базе, обращается к внешнему API и запускает дополнительную обработку данных.
На странице WordPress оба выглядят одинаково: одна строка в списке установленных плагинов.
Если сайт неожиданно стал тормозить после установки или обновления расширения, первое подозрение очевидно.
Но даже если проблема появилась давно, плагины стоит проверить. На тестовой копии сайта их можно временно отключать по одному или группами и смотреть, как меняется время генерации страницы.
На рабочем интернет-магазине проводить подобные эксперименты в разгар дня, конечно, не стоит.
Иногда виновник обнаруживается почти комично: отключается плагин, которым никто не пользовался два года, и время ответа уменьшается с 1,8 секунды до 300 миллисекунд.
Медленная база данных способна сделать быстрый сервер бесполезным
WordPress, Joomla, OpenCart, 1С-Битрикс и большинство современных CMS постоянно работают с базой данных.
Когда пользователь открывает страницу, приложение может запрашивать настройки, информацию о пользователе, товары, категории, комментарии, метаданные и десятки других вещей.
Нормальный запрос выполняется быстро. Проблемы начинаются, когда запросов становится слишком много или один из них вынужден перебирать огромный объем данных.
Допустим, интернет-магазин хранит 100 000 товаров. Пользователь включает сразу несколько фильтров. Если база организована неудачно, построение результата может потребовать значительных ресурсов.
Увеличение RAM или переход на более быстрый процессор иногда помогает, но это похоже на покупку более мощного двигателя для автомобиля с постоянно зажатым ручным тормозом.
Сначала нужно понять, можно ли оптимизировать сам запрос, структуру таблиц или индексы.
Характерный признак проблем с базой — неравномерная скорость. Простая статическая страница работает быстро, а поиск, фильтры, каталог или административные списки тормозят.
База WordPress со временем действительно может разрастаться
Небольшой сайт после нескольких лет работы способен накопить удивительное количество данных, которые уже почти никому не нужны.
Ревизии записей, временные данные, старые сессии, журналы плагинов, удаленные метаданные, транзиенты и статистика постепенно увеличивают таблицы.
Сам размер базы не является проблемой автоматически. MySQL спокойно работает с гораздо большими объемами данных.
Проблема появляется, когда приложение постоянно обращается к плохо организованным большим таблицам или плагин хранит в них данные не самым удачным способом.
Поэтому идея «раз база стала 500 МБ, нужно срочно ее чистить» слишком примитивна.
Сначала полезнее выяснить, какие таблицы занимают место и какие запросы выполняются медленно.
Удалять данные только ради красивой цифры в панели phpMyAdmin не нужно.
Огромные изображения остаются одной из самых банальных причин медленного сайта
Можно потратить вечер на настройку PHP-FPM, Redis и базы данных, а затем обнаружить на главной странице фотографию размером 8 МБ.
С современными камерами это происходит постоянно. Фотография с телефона может иметь разрешение 4000-8000 пикселей по ширине. На сайте она показывается в блоке шириной 900 пикселей, но браузер все равно скачивает исходный огромный файл.
Особенно болезненно это ощущается на мобильном интернете.
Если на странице десять таких фотографий, никакой NVMe на сервере не заставит пользователя скачать 50 МБ мгновенно.
Изображения нужно заранее уменьшать до разумных размеров, сжимать и использовать современные форматы вроде WebP или AVIF там, где это уместно.
Для разных размеров экрана полезны адаптивные изображения, чтобы смартфон не загружал файл, подготовленный для огромного монитора.
И здесь хорошо видно различие между серверной и клиентской скоростью. Сервер способен отдать HTML за 100 миллисекунд, но страница все равно будет ощущаться тяжелой.
Проверьте lazy loading изображений
Lazy loading откладывает загрузку изображений, которые пока находятся за пределами экрана.
Если длинная статья содержит двадцать фотографий, нет необходимости загружать все двадцать в ту секунду, когда посетитель только открыл верх страницы.
Браузер может сначала получить изображения, которые пользователь видит сейчас, а остальные загрузить по мере прокрутки.
Это уменьшает первоначальный объем данных и особенно полезно для мобильных устройств.
Но применять lazy loading бездумно тоже не стоит.
Главное изображение первого экрана, которое должно появиться сразу, наоборот, не нужно специально задерживать. Если браузер узнает о нем слишком поздно, можно ухудшить визуальную скорость загрузки.
Оптимизация сайта часто состоит именно из таких деталей. Не существует кнопки «ускорить все». Один и тот же механизм полезен в одном месте и вреден в другом.
JavaScript может тормозить сайт даже при идеальном хостинге
Современная веб-страница нередко загружает удивительное количество JavaScript.
Меню, слайдер, форма, аналитика, чат, обратный звонок, реклама, виджет социальной сети, карта, система рекомендаций — каждый компонент добавляет собственные скрипты.
Часть из них выполняется на устройстве посетителя.
Сервер в этот момент уже может быть совершенно свободен. Тормозит браузер.
Особенно заметно это на недорогих смартфонах. Страница, которая мгновенно работает на мощном настольном компьютере владельца сайта, способна ощутимо задерживаться на обычном телефоне посетителя.
Поэтому проверять производительность только на своем рабочем компьютере неправильно.
Если сайт ориентирован на массовую аудиторию, тестировать его нужно хотя бы с имитацией более слабого мобильного устройства и ограниченной скорости сети.
Сторонние сервисы иногда тормозят сильнее самого сайта
Одна из самых неприятных проблем возникает, когда медленный элемент вообще находится не на вашем сервере.
Сайт загружает внешний чат. Чат обращается к серверу своего разработчика. Тот отвечает медленно.
Или на страницу вставлен виджет отзывов, карта, рекламный код, система аналитики, шрифт с внешнего CDN.
Основной хостинг может работать идеально, но браузер все равно ждет сторонние ресурсы.
Это хорошо видно в инструментах разработчика браузера, где можно посмотреть каждый сетевой запрос и время его выполнения.
Если один внешний домен регулярно задерживает загрузку, появляется конкретный виновник.
Дальше можно решить, действительно ли этот сервис настолько нужен, чтобы пользователь платил за него скоростью.
На коммерческих сайтах годами остаются старые счетчики, виджеты и рекламные скрипты, назначение которых уже никто не помнит.
Удаление такого наследства иногда дает больший эффект, чем переход на более дорогой тариф хостинга.
Шрифты тоже весят и тоже требуют времени
Красивый нестандартный шрифт способен заметно изменить внешний вид сайта, поэтому полностью отказываться от веб-шрифтов не нужно.
Но одна гарнитура может содержать множество начертаний: Light, Regular, Medium, SemiBold, Bold, ExtraBold и так далее.
Если сайт реально использует два, а загружает шесть, посетитель скачивает лишние данные при каждом первом посещении.
Особенно неудачно подключать несколько больших семейств шрифтов ради пары заголовков.
Стоит проверить, какие файлы действительно используются, применять современные форматы и по возможности не загружать ненужные начертания.
В некоторых проектах системный стек шрифтов вообще оказывается отличным решением: браузеру ничего дополнительно скачивать не требуется.
Почему сайт тормозит только вечером
Вот здесь подозрение на хостинг становится значительно серьезнее.
Если одна и та же страница утром стабильно отвечает быстро, а каждый вечер без каких-либо изменений на сайте начинает работать заметно медленнее, возможна нехватка ресурсов.
На виртуальном хостинге физический сервер используется несколькими клиентами. Хороший провайдер изолирует их и устанавливает ограничения, но общая инфраструктура все равно имеет конечную производительность.
Однако вечерняя проблема может быть и вашей собственной.
В это время приходит основная аудитория. Увеличивается количество PHP-процессов, запросов к базе и операций с корзиной. То есть сервер тормозит не потому, что «соседи плохие», а потому, что именно ваш проект достигает лимитов тарифа.
Различить эти случаи помогают статистика ресурсов и поддержка хостинга.
Нужно посмотреть CPU, память, количество процессов и ошибки именно в проблемный период.
Если тариф постоянно упирается в установленный лимит, дальнейшая оптимизация или переход на более мощный вариант действительно имеют смысл.
Почему сайт тормозит только в админке WordPress
Очень полезный диагностический признак.
Если обычные посетители получают страницы быстро, а /wp-admin/ работает медленно, переносить сайт на другой хостинг сразу не стоит.
Фронтенд может активно кэшироваться, а административная панель обычно остается динамической. Каждый переход требует полноценной работы PHP и базы данных.
В админке также работают плагины, которые добавляют собственные панели, уведомления, статистику и проверки обновлений.
Некоторые расширения обращаются к внешним серверам прямо во время открытия административной страницы.
В результате публичная часть летает, а редактор ждет несколько секунд после каждого клика.
Диагностику здесь стоит начинать с плагинов, запросов базы и внешних HTTP-запросов WordPress.
Почему сайт тормозит после обновления
Если вчера все работало быстро, а сегодня стало медленно, это даже хорошая новость.
Круг подозреваемых сильно уменьшается.
Нужно вспомнить, что изменилось: версия CMS, тема, плагин, PHP, настройки сервера или база данных.
Автоматические обновления WordPress иногда происходят незаметно для владельца, поэтому стоит проверить журнал и даты версий.
Не нужно сразу откатывать весь сайт на месячную резервную копию.
Сначала определите изменение, совпавшее по времени с появлением проблемы.
Именно для таких ситуаций особенно полезна тестовая копия сайта. На ней можно отключать плагины, менять версию PHP и проводить другие эксперименты без риска сломать рабочий проект.
Может ли старая версия PHP тормозить WordPress
Версия PHP действительно влияет на производительность, но обновление нельзя рассматривать как волшебный ускоритель.
Современные версии PHP в целом эффективнее старых поколений, а поддерживаемая версия важна еще и с точки зрения безопасности.
Но переход должен выполняться только после проверки совместимости CMS, темы и плагинов.
Если сайт много лет работает на устаревшем PHP, сначала создается резервная копия и тестируется новая версия на копии проекта.
Сломать интернет-магазин ради нескольких процентов производительности — сомнительная оптимизация.
Кроме того, если главная проблема заключается в тяжелом запросе к базе или огромных фотографиях, обновление PHP ее не устранит.
Проверьте, включен ли OPcache
PHP-приложение состоит из программного кода, который сервер должен выполнять.
OPcache сохраняет скомпилированный байт-код PHP в памяти, чтобы не выполнять одну и ту же подготовительную работу при каждом запросе.
Для современного PHP-хостинга это практически базовый механизм ускорения.
На хорошем виртуальном хостинге OPcache обычно уже настроен провайдером. На самостоятельно установленном VPS его состояние стоит проверить.
Но здесь снова важно не искать одну кнопку, которая решит все проблемы.
OPcache ускоряет выполнение PHP, но не уменьшит фотографию 12 МБ, не исправит медленный SQL-запрос и не заставит сторонний виджет отвечать быстрее.
Redis полезен не каждому сайту
Redis часто упоминается в советах по ускорению WordPress настолько регулярно, что возникает впечатление: без него сайт просто не способен работать быстро.
На самом деле Redis решает конкретную задачу.
Он может использоваться как объектный кэш, сохраняя в памяти результаты операций, которые иначе пришлось бы снова получать из базы данных.
Для динамического WordPress или WooCommerce это бывает очень полезно.
Для маленького блога, где почти все страницы отдаются из полноэкранного кэша, эффект может оказаться намного скромнее.
Кроме того, Redis сам использует оперативную память.
Поэтому устанавливать его на VPS с минимальным объемом RAM только потому, что «так делают быстрые сайты», не всегда разумно.
Сначала определяется проблема, затем выбирается инструмент.
Не наоборот.
CDN не исправит медленный PHP
CDN хранит копии статических ресурсов на распределенных узлах и отдает их пользователю с подходящей точки присутствия. Это уменьшает расстояние до файлов и снижает нагрузку на основной сервер. На Hostingi.org уже есть отдельный материал о принципах работы CDN и его связи с хостингом.
Но CDN часто приписывают возможности, которых у него нет.
Если WordPress пять секунд формирует динамическую страницу из-за медленной базы, подключение CDN для изображений не заставит PHP внезапно работать за 200 миллисекунд.
Зато если посетители находятся далеко от основного сервера и страница содержит много статических файлов, CDN способен дать заметный эффект.
Некоторые системы умеют кэшировать и HTML, но тогда появляются дополнительные вопросы с персонализированным содержимым, корзиной, авторизацией и обновлением кэша.
CDN — хороший инструмент, но не универсальное лекарство от любого медленного сайта.
Проверьте сжатие Gzip или Brotli
HTML, CSS и JavaScript хорошо сжимаются.
Если сервер передает их в сжатом виде, браузеру приходится скачать меньше данных.
Сегодня для этого широко используются Gzip и Brotli.
Настройка обычно выполняется на уровне веб-сервера или CDN. На виртуальном хостинге часть оптимизации может быть включена провайдером автоматически.
Выигрыш особенно заметен на текстовых ресурсах.
JPEG-фотографию, которая уже сильно сжата, повторное Gzip-сжатие чудесным образом маленькой не сделает. А вот HTML или CSS способен уменьшиться весьма существенно.
Проверить наличие сжатия можно обычными инструментами анализа страницы.
HTTP/2 и HTTP/3 полезны, но не отменяют оптимизацию
Современные протоколы улучшают передачу данных между браузером и сервером.
HTTP/2 позволяет эффективнее обслуживать множество запросов в одном соединении. HTTP/3 использует QUIC и способен улучшать работу в сетях с потерями и меняющимися условиями.
Поддержка современных протоколов — плюс для хостинга.
Но наличие HTTP/3 не спасет страницу, которая загружает 15 МБ ненужных изображений.
Иногда владельцы сайтов слишком увлекаются технологическими галочками. HTTP/3 есть, NVMe есть, PHP последней версии есть, а главная страница весит 9 МБ и выполняет сотню запросов.
Начинать оптимизацию всегда лучше с самого большого узкого места.
Проверьте размер страницы целиком
Это один из самых простых показателей, который часто сразу объясняет многое.
Если главная страница весит 15 МБ, не нужно удивляться ее медленной загрузке на мобильном интернете.
Нужно посмотреть, из чего складывается этот объем.
Обычно большую часть занимают изображения. Иногда неожиданно много весят видео, шрифты или JavaScript.
При этом не существует универсального идеального размера страницы. Фотографический сайт неизбежно тяжелее текстового блога.
Цель не в том, чтобы любой ценой получить минимальную цифру, а в том, чтобы не передавать пользователю данные, которые ему не нужны.
Фотография, визуально занимающая половину экрана, может быть качественной и при разумном размере файла. Для этого не обязательно отправлять оригинал прямо с камеры.
Посчитайте количество запросов, но не превращайте его в религию
Когда-то популярным советом было максимально уменьшать количество HTTP-запросов и объединять все CSS и JavaScript в огромные файлы.
С HTTP/2 ситуация стала сложнее. Большое количество небольших ресурсов уже не создает ту же проблему, что в эпоху старого HTTP/1.1.
Тем не менее сотни запросов остаются поводом посмотреть, что именно загружает страница.
Особенно подозрительны многочисленные обращения к сторонним доменам.
Поэтому сама цифра «127 запросов» ничего не доказывает. Нужно смотреть структуру.
Десять необходимых ресурсов могут быть хуже пятидесяти хорошо кэшируемых маленьких файлов, если один из этих десяти блокирует отображение страницы на две секунды.
Проверьте сайт с телефона, а не только через эмулятор
Инструменты разработчика прекрасно имитируют мобильный экран и ограниченную сеть, но настоящий смартфон все равно полезен.
Откройте сайт через мобильный интернет, а не домашний Wi-Fi.
Пройдите путь обычного посетителя: главная, меню, каталог, поиск, форма, корзина.
Именно здесь иногда обнаруживаются вещи, которые не видны в синтетическом тесте. Меню реагирует с задержкой. Огромный слайдер дергается. Кнопка появляется только после загрузки стороннего скрипта. Форма подвисает при отправке.
Сайт существует не ради красивого балла в сервисе проверки производительности.
Он существует ради человека, который им пользуется.
Высокий балл PageSpeed не означает быстрый сайт
PageSpeed Insights и Lighthouse очень полезны, но их результаты легко неправильно интерпретировать.
Получить 100 баллов становится отдельной спортивной дисциплиной. Владелец удаляет нужные элементы, меняет шрифты, усложняет загрузку скриптов и радуется зеленому кружку.
При этом реальному пользователю сайт может стать не удобнее.
И наоборот, проект с результатом 85 способен ощущаться очень быстрым и стабильно работать на реальных устройствах.
Использовать PageSpeed лучше как диагностический инструмент. Он показывает конкретные проблемы и метрики, которые можно изучить.
Гнаться за цифрой ради цифры не нужно.
Особенно если ради последних нескольких баллов приходится ломать функциональность или усложнять поддержку сайта.
Когда виноват именно хостинг
После всех предыдущих пунктов может показаться, что хостинг вообще никогда ни при чем. Конечно, это не так.
Слабый или перегруженный сервер способен быть главным ограничением.
На проблему хостинга указывают несколько признаков. Даже простые динамические страницы имеют высокий TTFB. Сайт становится медленным при относительно небольшой нагрузке. В панели регулярно фиксируется достижение CPU или RAM лимитов. Появляются ошибки 502, 503 или сообщения о нехватке ресурсов. Производительность заметно меняется в разное время суток без соответствующего изменения посещаемости.
В такой ситуации стоит написать в поддержку и предоставить конкретные данные: время возникновения проблемы, адрес страницы, показатели нагрузки и ошибки.
Фраза «у меня тормозит сайт, сделайте быстрее» дает специалисту мало информации.
А сообщение «с 20:00 до 22:00 TTFB динамических страниц увеличивается с 300 мс до 2 секунд, посещаемость в это время не меняется, лимиты аккаунта не превышены» уже позволяет начать предметный разговор.
Когда пора переходить на более мощный тариф
Если сайт оптимизирован, но регулярно достигает ограничений CPU, памяти или количества процессов, увеличение ресурсов становится логичным.
Здесь важно слово «регулярно».
Однократный пик во время резервного копирования еще не означает, что нужно удваивать стоимость хостинга.
Если же проект каждый вечер находится у границы тарифа, запас действительно нужен.
При этом следующий шаг не обязательно VPS. Многие провайдеры предлагают более производительный виртуальный хостинг с увеличенными лимитами.
Для владельца, который не хочет заниматься Linux, такой вариант может оказаться удобнее собственного сервера.
VPS становится особенно интересен, когда требуется больше контроля над окружением, индивидуальная конфигурация или ресурсы, которые shared-хостинг уже не способен предоставить.
Когда переезд на другой хостинг действительно поможет
Переезд имеет смысл, если текущий провайдер не обеспечивает нужные ресурсы, производительность нестабильна, отсутствует подходящий тариф для роста или технические ограничения мешают работе проекта.
Еще одна причина — поддержка. Если сервер регулярно испытывает проблемы, а получить внятную диагностику невозможно, технические характеристики перестают быть единственным критерием.
Но переносить сайт только потому, что PageSpeed показывает 62 балла, не нужно.
Сначала нужно определить, какие именно рекомендации снижают результат.
Если это огромные изображения и тяжелый JavaScript, они благополучно переедут вместе с сайтом на новый сервер.
На Hostingi.org уже подробно разобран процесс переноса сайта и особенности DNS при смене площадки. Переезд лучше использовать как решение подтвержденной проблемы, а не как первый эксперимент.
Как найти причину медленной работы сайта за один вечер
Начать можно с простой последовательности. Сначала открыть несколько разных страниц и проверить TTFB. Затем посмотреть общий размер страницы и самые тяжелые ресурсы. После этого проверить изображения, JavaScript, внешние запросы и шрифты.
Если медленной оказывается именно серверная генерация, внимание переносится на PHP, плагины, базу данных, кэш и доступные ресурсы хостинга.
На WordPress полезно сделать тестовую копию и проверить влияние плагинов. Для интернет-магазина отдельно тестируются поиск, фильтры, корзина и административная часть.
Далее стоит посмотреть статистику CPU и памяти в панели хостинга и сравнить ее с временем возникновения задержек.
Уже после этого становится понятно, куда двигаться.
Вместо абстрактного «сайт тормозит» появляется конкретный диагноз: тяжелые изображения, медленная база, плагин, внешний сервис, нехватка CPU или перегруженная площадка.
А конкретную проблему исправлять значительно проще.
Что делать, если сайт стал медленно работать
Главное правило — не менять сразу десять вещей.
Если одновременно установить Redis, заменить PHP, включить CDN, поставить новый плагин кэширования и перейти на другой тариф, сайт вполне может ускориться. Но вы так и не узнаете почему.
А если через месяц проблема вернется, диагностику придется начинать заново.
Лучше изменять систему последовательно и измерять результат каждого шага.
Сжали изображения — проверили.
Отключили подозрительный плагин — проверили.
Настроили кэш — проверили.
Оптимизировали запрос — проверили.
Так постепенно находится реальное узкое место.
Именно измерение отличает оптимизацию от шаманства.
Как сделать сайт быстрее без смены хостинга
Во многих случаях значительное ускорение действительно возможно без переезда.
Оптимизируются изображения, удаляются ненужные плагины и внешние скрипты, включается кэширование, проверяется база данных, обновляется PHP, настраивается OPcache, включается сжатие и убираются ресурсы, которые блокируют первоначальное отображение страницы.
Для географически распределенной аудитории подключается CDN. Если динамический сайт постоянно обращается к одним и тем же данным, может помочь объектный кэш.
Но набор действий должен зависеть от диагностики.
Информационному сайту с огромными фотографиями Redis почти ничего не даст. Интернет-магазину с тяжелыми запросами к базе уменьшение логотипа на 20 КБ тоже не изменит ситуацию.
Хорошая оптимизация начинается не со списка модных технологий, а с ответа на вопрос: где теряется больше всего времени?
Почему быстрый сайт иногда важнее более мощного хостинга
Производительность сайта — это результат работы всей цепочки.
DNS находит сервер. Сеть доставляет запрос. Веб-сервер принимает его. PHP выполняет приложение. База возвращает данные. Сервер формирует ответ. Браузер загружает HTML, CSS, JavaScript, изображения и шрифты. Затем процессор устройства должен все это обработать и нарисовать страницу.
Хостинг отвечает только за часть этой цепочки.
Очень важную, но все-таки часть.
Поэтому дорогой сервер не гарантирует быстрый сайт точно так же, как мощный компьютер не гарантирует хорошо написанную программу.
Иногда переход с тарифа за 300 рублей на VPS за 3000 рублей действительно решает проблему. А иногда практически тот же результат дает вечер работы с изображениями и одним неудачным плагином.
Разница заключается в диагностике.
Если сайт стал медленным, не нужно первым делом искать новый хостинг. Сначала найдите секунду, которая потерялась. Посмотрите, что происходило в эту секунду: сервер выполнял PHP, база искала данные, браузер скачивал фотографию или внешний виджет ждал ответа.
Когда найдено место задержки, становится понятно и решение.
А если после проверки выяснится, что сайт оптимизирован, ресурсы постоянно упираются в ограничения и сервер действительно не справляется, тогда переход на более мощный тариф или другой хостинг будет уже не попыткой угадать, а нормальным техническим решением.
