← Speed / speed / troubleshooting

Устранение неполадок медленного сайта

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

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

Каждый ответ, передаваемый через Cloudflare, содержит cf-ray заголовок. Проверьте наличие этого заголовка:

curl -s -D- -o /dev/null https://www.example.com | grep -i cf-ray

(Invoke-WebRequest -Uri "https://www.example.com" -Method Head).Headers["cf-ray"]

Если вы видите cf-ray заголовок (например, cf-ray: 8a1b2c3d4e5f6g7h-SJC), ваш трафик проходит через Cloudflare. Если нет, проверьте настройки DNS.

Чтобы трафик проксировался, домен должен резолвиться в IP-адреса Cloudflare:

dig +short www.example.com

Resolve-DnsName -Name www.example.com | Select-Object -ExpandProperty IPAddress

Возвращаемые IP-адреса должны быть IP-адреса Cloudflare ↗. Если они указывают напрямую на ваш исходный сервер, ваши записи DNS не проксируются.

Чтобы это исправить:

1. Перейдите в Панель управления Cloudflare ↗.
2. Найдите DNS-запись для медленного хоста.
3. Убедитесь, что Статус прокси имеет значение Proxied (значок оранжевого облака).

Проблемы производительности проще решить, если точно определить, что именно работает медленно. Для начала соберите следующую информацию:

1. Выявление конкретных медленных запросов - Определите, какие URL-адреса, ресурсы или конечные точки API работают медленно.
2. Измерьте степень замедления - Укажите величину задержки (например, «это изображение загружается 5 секунд»).
3. Воспроизведите проблему - Убедитесь, что снижение скорости повторяется, а не является единичным случаем.

Observatory предоставляет синтетические тесты и данные мониторинга реальных пользователей (RUM) для оценки производительности вашего сайта.

RUM особенно важен, поскольку эти показатели собираются непосредственно из браузеров ваших реальных посетителей и поэтому объективно отражают, как они воспринимают ваш сайт, а не лабораторные данные, которые обычно детальнее (что полезно для отладки), но не всегда соответствуют устройствам и качеству соединения, доступным реальным людям.

1. Перейдите в панель управления Cloudflare.

   Перейдите в Observatory ↗

2. Выберите Observatory.

3. Введите URL-адрес, который нужно проверить, и выберите Запустить тест.

Observatory показывает ключевые метрики:

Real User Monitoring показывает похожие метрики, но вместо Total Blocking Time (TBT) вы увидите Interaction to Next Paint (INP).

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

На основе результатов Observatory включите соответствующие Оптимизация скорости:

• Сжатие Brotli - Сжимайте ответы для более быстрой передачи
• Early Hints - Предзагружайте критически важные ресурсы
• HTTP/2 и HTTP/3 - Используйте современные протоколы с мультиплексированием, которые позволяют отправлять несколько запросов через одно соединение вместо открытия отдельного соединения для каждого ресурса
• Оптимизация изображений - Автоматически оптимизируйте и изменяйте размер изображений
• Rocket Loader - Откладывайте загрузку JavaScript, чтобы ускорить отрисовку страницы

Если данные Observatory и RUM указывают на конкретные проблемы, используйте инструменты разработчика браузера для анализа отдельных ресурсов.

1. Откройте инструменты разработчика в браузере.
2. Перейдите в Сеть на вкладке.
3. Перезагрузите страницу и посмотрите, какие запросы выполняются дольше всего.
4. Сортировать по Время или Длительность , чтобы определить самые медленные ресурсы.
5. Отметьте точные URL-адреса медленных ресурсов.

Обратите внимание на:

• Большие изображения или видео
• Медленные вызовы API
• Скрипты сторонних сервисов
• Ресурсы, блокирующие рендеринг

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

В панели управления Cloudflare:

1. Перейдите в Speed > Origin Analytics.

   Перейдите в Origin Analytics ↗

2. Просмотрите Время ответа источника метрик.

3. Ищите закономерности в медленных ответах (конкретные пути, время суток или географические регионы).

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

• Переход на более высокий тарифный план хостинга
• Оптимизация запросов к базе данных
• Реализация кэширования на стороне сервера

Полное руководство по доступным метрикам, процессам диагностики и интерпретации кодов состояния источника см. в Origin Analytics.

Если в вашей зоне есть Cloudflare Workers развернуты, они выполняются при каждом подходящем запросе и увеличивают общее время отклика. Медленный Worker часто становится причиной высокого TTFB.

Чтобы проверить, влияют ли Workers на производительность:

1. Перейдите в Workers & Pages в Cloudflare dashboard.
2. Проверьте, какие Workers развёрнуты в вашей зоне.
3. Проверьте Аналитика для каждого Worker, чтобы увидеть время выполнения.
4. Временно отключите Workers, чтобы проверить, не они ли вызывают замедление.

Если Worker работает медленно, проверьте его код на наличие:

• Медленные внешние вызовы API или fetch() запросы
• Неэффективные циклы или обработка данных
• Отсутствует await операторы, вызывающие последовательное выполнение вместо параллельного

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

curl -w "\n\nDNS Lookup: %{time_namelookup}s\nTCP Connect: %{time_connect}s\nTLS Handshake: %{time_appconnect}s\nTime to First Byte: %{time_starttransfer}s\nTotal Time: %{time_total}s\n" -o /dev/null -s https://www.example.com/slow-asset.jpg

$url = "https://www.example.com/slow-asset.jpg"
try {
    $timing = Measure-Command { 
        $response = Invoke-WebRequest -Uri $url -ErrorAction Stop
    }
    Write-Host "Total Time: $($timing.TotalSeconds)s"
    Write-Host "Status: $($response.StatusCode)"
} catch {
    if ($_.Exception.Response) {
        $statusCode = $_.Exception.Response.StatusCode.value__
        Write-Host "Error Status: $statusCode"
    }
    Write-Host "Error: $($_.Exception.Message)"
}

Пример вывода (bash):

DNS Lookup: 0.025s
TCP Connect: 0.045s
TLS Handshake: 0.120s
Time to First Byte: 0.350s
Total Time: 1.250s

Разбивка времени curl показывает следующее:

Чтобы протестировать из разных географических точек, используйте такие онлайн-инструменты, как:

• KeyCDN Tools ↗
• Uptrends ↗
• Dotcom-Tools ↗

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

Некэшированный контент должен пройти путь от посетителя до Cloudflare, затем до вашего origin-сервера и обратно. Используйте Cache Analytics , чтобы оценить эффективность кэша и найти возможности для кэширования большего объема контента.

Проверьте статус кэша конкретного ресурса:

curl -s -D- -o /dev/null https://www.example.com/asset.jpg | grep -i "cf-cache-status"

(Invoke-WebRequest -Uri "https://www.example.com/asset.jpg" -Method Head).Headers["cf-cache-status"]

Возможные значения:

Полный список см. в Кеширование ответов Cloudflare.

1. Перейдите в панель управления Cloudflare.

   Перейдите в Обзор ↗

2. Просмотрите Производительность кеша раздел.

3. Фильтр по Статус кэша равен MISS или DYNAMIC , чтобы выявить некэшируемый контент.

Если статические ресурсы (изображения, CSS, JavaScript) имеют статус кэша DYNAMIC, BYPASS, или MISS, выясните причину:

По умолчанию Cloudflare кэширует только определённые расширения файлов. Чтобы кэшировать дополнительный статический контент:

1. Перейдите в Кеширование > Cache Rules.
2. Создайте правило, чтобы кешировать определённый контент.
3. Установите подходящие Edge TTL.

Если правила кэширования применяются не так, как ожидается, используйте Cloudflare Trace , чтобы смоделировать запрос и увидеть, какие именно правила сработают. Trace показывает, как настройки Cloudflare (включая правила кэширования, правила страниц и другие параметры) повлияют на конкретный URL.

Это особенно полезно в следующих случаях:

• Правило кеширования должно кешировать контент, но в ответе указано DYNAMIC или BYPASS
• Вы не уверены, какое правило имеет приоритет
• Вы хотите проверить сценарий «что если» перед внесением изменений

Если curl показывает высокое время TCP Connect или TLS Handshake, проблема может быть связана с сетью, а не с приложением.

Перейдите на speed.cloudflare.com ↗ для проверки:

• Скорость скачивания и отправки данных
• Задержка (ping)
• Джиттер
• Потеря пакетов

Низкие результаты указывают на проблемы с локальной сетью или интернет-провайдером.

MTR объединяет traceroute и ping, показывая задержку и потери пакетов на каждом сетевом узле.

mtr -rw www.example.com

Обратите внимание на:

• Высокая задержка на отдельных участках маршрута (указывает на медленные сегменты сети)
• Потеря пакетов (указывает на перегрузку сети или проблемы)
• Тайм-ауты (может указывать на проблемы с брандмауэром или маршрутизацией)

Подробнее см. в Как читать MTR ↗.

Если у вас есть доступ к исходному серверу, запустите MTR от источника до IP-адрес Cloudflare ↗ , чтобы проверить сетевой путь между вашим источником и Cloudflare.

mtr -rw 104.16.132.229

Высокая задержка или потеря пакетов на этом пути влияет на все запросы, которые не попадают в кеш.

То, как запросы маршрутизируются к дата-центрам Cloudflare, может существенно влиять на производительность.

Добавить /cdn-cgi/trace для вашего домена, чтобы узнать, какой дата-центр Cloudflare обрабатывает ваши запросы:

curl https://www.example.com/cdn-cgi/trace

Invoke-RestMethod -Uri "https://www.example.com/cdn-cgi/trace"

colo поле показывает трехбуквенный код аэропорта обслуживающего дата-центра (например, colo=SJC для Сан-Хосе). Полный список дата-центров Cloudflare и их кодов можно найти на страница статуса Cloudflare ↗.

Когда запрос доходит до Cloudflare:

1. Запрос направляется в ближайший дата-центр Cloudflare на основе anycast маршрутизация ↗.
2. Если содержимое кэшировано, оно выдаётся немедленно.
3. Если содержимое не кэшировано, Cloudflare запрашивает его с исходного сервера.

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

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

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

Подробнее см. в Трафик Cloudflare не направляется в географически ближайший дата-центр.

Распространённые причины непредвиденной маршрутизации:

Рассмотрите следующие решения с учётом ваших потребностей:

Argo Smart Routing анализирует состояние сети в реальном времени и направляет трафик по самым быстрым маршрутам, снижая задержку в среднем на 30%.

Argo Smart Routing является частью Smart Shield, который объединяет несколько функций Cloudflare для производительности и надежности.

Чтобы включить Argo Smart Routing:

1. Перейдите в Панель управления Cloudflare ↗.
2. Следуйте Руководство по настройке Smart Shield , чтобы включить эту функцию.

Argo особенно эффективен в следующих случаях:

• Источник расположен далеко от пользователей
• Перегрузка сети затрагивает отдельные маршруты
• Вам нужна стабильная производительность по всему миру

Подробные сведения о принципе работы Argo Smart Routing см. в документация Argo Smart Routing.

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

При обращении в службу поддержки предоставьте как можно больше данных, чтобы упростить диагностику проблемы:

• HAR-файл - Создание файла HAR который фиксирует медленные запросы. Это предоставляет подробную информацию о времени для каждого запроса.
• Результаты Observatory - Поделитесь снимками экрана или ссылками на результаты тестов Observatory.
• Данные RUM - Если у вас включена Web Analytics, поделитесь соответствующими метриками, отражающими проблему с производительностью.
• вывод команды curl - Приложите разбивку по времени из curl --write-out для медленных ресурсов.
• Результаты MTR - Если вы подозреваете проблемы с сетью, приложите вывод MTR от вашего местоположения до проблемного домена.
• Определённые URL-адреса - Перечислите точные URL-адреса, которые работают медленно, а также ожидаемое и фактическое время отклика.

Чем больше свидетельств замедления вы предоставите, тем быстрее служба поддержки сможет выявить и устранить проблему.

• Observatory - Тестируйте и отслеживайте производительность сайта
• Cache Analytics - Анализируйте коэффициент попадания в кеш
• Cache Rules - Управляйте тем, что кешируется
• Argo Smart Routing - Оптимизируйте маршрутизацию сети
• Сбор сведений для устранения неполадок - Собирайте диагностические данные