Сначала измерьте реальную проблему
Нельзя исправить то, что не измерено, а «кажется, что медленно» — это не диагноз. Откройте PageSpeed Insights (pagespeed.web.dev), введите свой URL и посмотрите на две вещи: Core Web Vitals и лабораторные метрики. Сосредоточьтесь на мобильной вкладке, поскольку большинство посетителей заходят с телефонов. Затем измерьте TTFB (Time To First Byte) — сколько времени серверу требуется, чтобы отправить первый байт, — потому что это отделяет проблему сервера от проблемы доставки.
Здоровые ориентиры: LCP меньше 2,5 секунд, INP меньше 200 мс, CLS меньше 0,1 и TTFB примерно меньше 200 мс. Если TTFB высокий, узкое место на стороне сервера: хостинг, PHP или база данных. Если TTFB в порядке, а LCP высокий, узкое место — сама страница: обычно большие изображения и то, как далеко они путешествуют до посетителя. Это единственное измерение подскажет, с каких исправлений ниже начать.
Реальные причины медленного сайта
У большинства медленных сайтов есть несколько общих причин. Медленный сервер или перегруженный shared-хостинг поднимают TTFB ещё до загрузки хоть одного изображения. Дальше идут тяжёлые страницы — изображения избыточного размера (обычно самый большой элемент страницы), раздутые темы и конструкторы страниц, которые загружают десятки таблиц стилей и скриптов. Слишком много сторонних скриптов (чат-виджеты, тепловые карты, трекеры, дополнительные шрифты) — каждый добавляет запрос и блокирует рендеринг.
CSS и JavaScript, блокирующие рендеринг, задерживают первую отрисовку, даже если сервер быстрый. И расстояние тоже важно: один сервер, далёкий от многих ваших посетителей, добавляет задержку ко всему, а всплеск трафика может его перегрузить. Почти каждый медленный сайт — это та или иная смесь перечисленного: повторяющаяся работа сервера, тяжёлые ресурсы, блокирующие скрипты и физическое расстояние.
Разбираемся в Core Web Vitals
Google частично ранжирует по Core Web Vitals, поэтому полезно знать, что измеряет каждый показатель. LCP (Largest Contentful Paint) — это время появления основного контента, часто hero-изображения; больше всего на него влияют медленные серверы и тяжёлые, далёкие изображения. INP (Interaction to Next Paint) — это скорость отклика страницы на тап или клик посетителя; на него влияет тяжёлый JavaScript, блокирующий основной поток.
CLS (Cumulative Layout Shift) — это насколько сильно «прыгает» макет во время загрузки; на него влияют изображения и реклама без зарезервированного места, а также поздно загружающиеся шрифты. Исправление перечисленных выше причин — более быстрая доставка, более лёгкие изображения, меньше JavaScript и зарезервированное место для медиа — именно то, что улучшает эти три показателя.
Исправления, которые реально меняют показатели
Работайте в порядке влияния. Кеш: отдавайте готовую страницу вместо того, чтобы пересобирать её при каждом визите, — самый большой отдельный выигрыш для TTFB и нагрузки на сервер. Изображения: подгоните размер под то, в котором они показываются, и отдавайте современные форматы (WebP/AVIF), которые обычно доминируют в весе страницы. Скрипты: уберите сторонние скрипты, которые вам не нужны, и отложите остальные, чтобы они перестали блокировать первую отрисовку.
Зарезервируйте место для изображений и рекламы, чтобы макет не прыгал (лучше CLS), и загружайте шрифты, не блокируя рендеринг. Затем сократите расстояние, которое проходит ваш контент, с помощью CDN. Каждое исправление устраняет конкретную причину, а вместе они сразу улучшают LCP, INP и CLS.
CDN решает проблему расстояния и всплесков
Даже после настройки сервера и страниц один сервер может находиться только в одном месте. CDN копирует ваши статические файлы на edge-серверы по всему миру, так что каждый посетитель обслуживается из ближайшего — меньше задержка и ниже LCP для тех, кто далеко от вашего origin, плюс устойчивость при всплесках трафика, потому что нагрузку поглощает edge. Вместе с этим идут современная доставка (сжатие Brotli, HTTP/2) и автоматические SSL, WAF и защита от DDoS.
cdn.com.tr делает это без переделки: направьте домен через CDN, и edge начнёт кешировать и доставлять ваши ресурсы из точки, близкой к каждому посетителю. Динамические страницы продолжают работать как обычно, сертификаты продлеваются сами, а расстояние, которое вредило вашему LCP, исчезает.
Где скорость важнее всего
Читатели уходят с медленных статей; более быстрые страницы и edge-кеширование удерживают их и помогают популярному посту пережить всплеск трафика.
Каждая лишняя секунда на странице товара или оформления заказа снижает конверсию; кеширование и CDN сохраняют отзывчивость загруженного магазина.
Первое впечатление и показатель качества рекламы зависят от скорости; быстрая страница, близкая к посетителю, улучшает и то, и другое.
Вопросы и ответы о скорости сайта
Что такое Core Web Vitals?
Три метрики, которые Google использует для оценки реального пользовательского опыта: LCP (насколько быстро появляется основной контент), INP (насколько быстро страница реагирует на действия) и CLS (насколько стабилен макет). Их улучшение помогает и пользователям, и позициям в поиске.
Как снизить высокий TTFB?
Высокий TTFB — проблема на стороне сервера: используйте актуальную версию PHP, добавьте кеширование страниц, чтобы они не пересобирались при каждом визите, добавьте объектный кеш Redis для сайтов с большим числом запросов к базе и выберите более быстрый хостинг. Затем CDN отдаёт кешированные ответы ещё ближе к посетителям.
Сделает ли один только CDN мой сайт быстрым?
CDN устраняет проблему расстояния и поглощает всплески, а это значительная часть скорости. Но если высокий TTFB исходит от сервера или изображения слишком большие, исправьте и это тоже — CDN доставляет ваши страницы быстрее, но не переделывает за вас медленный origin.
Почему мой сайт медленнее на мобильных устройствах?
У телефонов более слабые процессоры и часто более медленные сети, поэтому тяжёлый JavaScript и большие изображения вредят сильнее. Более лёгкие изображения, меньше скриптов и кешированная доставка поближе — вот что меняет мобильные оценки, по которым ранжирует Google.