Диагностика реального сайта: пошаговый разбор

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

Шаг 1: Первый взгляд в браузере

Открываем сайт example.com. Первые наблюдения без инструментов:

Открылся по HTTPS? Замок в адресной строке — да.
Страница показалась быстро или была задержка?
Есть ли явные ошибки в консоли? (F12 → Console)

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

Шаг 2: Проверка security-заголовков

Открываем DevTools → Network → кликаем главный запрос (document, первый в списке) → Headers → Response Headers. Ищем:

strict-transport-security     ← HSTS (должен быть)
content-security-policy       ← CSP (опционально, но желателен)
x-content-type-options        ← nosniff (должен быть)
x-frame-options               ← deny (должен быть)
referrer-policy               ← strict-origin-when-cross-origin (желателен)

Если каких-то нет — записываем в «рекомендации». Для быстрой проверки используем curl:

curl -sI https://example.com | grep -iE 'strict-transport|content-security|x-frame|x-content|referrer'

Шаг 3: Анализ производительности загрузки

На той же вкладке Network смотрим waterfall главного HTML и критических ресурсов (CSS, JS в <head>):

Есть ли чередование цветов DNS/TCP/TLS? Если они повторяются для каждого запроса — нет Keep-Alive (плохо в HTTP/1.1, нормально в HTTP/2 на разных доменах).
Большой TTFB (зелёный)? > 500 мс — сервер медленно генерирует страницу. Возможные причины: тяжёлый запрос к базе, не кэшируется, geographical задержка.
Ресурсы загружаются последовательно? Если CSS грузится → потом JS → потом картинки, а не параллельно — проблема с критическим путём рендеринга.
Сжатие? Проверить Content-Encoding: br или gzip у текстовых ресурсов. Без сжатия HTML/CSS/JS/JSON весят в 3–5 раз больше.

Шаг 4: Проверка кэширования

В Response Headers ищем:

Cache-Control: max-age=...      ← есть ли срок кэширования
ETag: "..."                     ← есть ли ETag для условных запросов

Повторный заход на сайт (обновить страницу) — смотрим в waterfall. Запросы к статике должны показать 304 Not Modified или вовсе (disk cache) без сетевых запросов. Если статика каждый раз грузится заново — кэширование не настроено.

Шаг 5: Анализ конкретного API-запроса (если есть)

Находим XHR/Fetch-запросы в Network. Выбираем один и смотрим:

Метод и URL — RESTful или /api?action=getUser&id=5?
Статус-код — правильный? 201 для создания, 204 для удаления, 200 для чтения?
Content-Type — application/json?
Время ответа — TTFB > 300 мс для API — медленно.
Размер ответа — может, сервер отдаёт лишние поля?

Копируем запрос как curl и повторяем в консоли:

curl -v 'https://api.example.com/products?category=5' 2>&1 | grep -E 'HTTP/|content-type|content-length|cache'

Шаг 6: Проверка DNS

Быстрая проверка DNS через консоль:

nslookup example.com
# или
dig example.com

# Проверить, что www.example.com тоже резолвится
dig www.example.com

Смотрим:

Есть ли A-запись (IPv4)?
Есть ли AAAA-запись (IPv6)? Отсутствие не критично, но современно.
Не истёк ли домен? (whois или в ответе DNS).

Шаг 7: Проверка сертификата

Через браузер: клик по замку → Certificate. Смотрим:

Кем выдан (Issuer) — Let's Encrypt, DigiCert, etc.
Срок действия (Validity) — не истёк ли?
SAN — покрывает ли www.example.com, api.example.com?

Через curl:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer -subject -ext subjectAltName

Шаг 8: Итоги диагностики

Собираем отчёт. Пример для условного shop.example.com:

1. Безопасность: HSTS — есть, CSP — нет (рекомендуется), X-Frame-Options — DENY ✓
2. Производительность: TTFB главной страницы 180 мс ✓, статика без gzip ✗ (экономия 60%)
3. Кэширование: статика без Cache-Control ✗ — каждый раз грузится заново
4. DNS: A-запись ✓, AAAA отсутствует
5. Сертификат: Let's Encrypt, действителен до 2026-07-15 ✓, wildcard *.example.com ✓
6. HTTP/2: да ✓ (видно в Protocol-колонке DevTools)

Проверь себя

О чём говорит большой зелёный сегмент в waterfall?
Как быстро проверить security-заголовки сайта?
Зачем смотреть на колонку Protocol в DevTools Network?

<details> <summary>Ответы</summary>

О медленной обработке запроса сервером (TTFB). Возможные причины: долгий запрос к базе данных, отсутствие кэширования, большое расстояние до сервера.
curl -sI https://... | grep -iE 'strict-transport|content-security|x-frame|x-content|referrer' или вкладка Network → Response Headers.
Чтобы узнать, какой протокол используется: h2 = HTTP/2, h3 = HTTP/3, http/1.1 = устаревший. HTTP/2 и HTTP/3 дают мультиплексирование и лучшую производительность.

</details>

Что унести с урока

Полная диагностика сайта: HTTPS → security-заголовки → производительность → кэширование → DNS → сертификат.
Waterfall мгновенно показывает узкие места: TTFB, отсутствие Keep-Alive, последовательную загрузку.
curl + DevTools дополняют друг друга: DevTools для визуального анализа, curl для скриптов и деталей.
Результат диагностики — конкретный список рекомендаций.

В следующем уроке напишем health-check скрипт — автоматизируем проверку сайта через bash и curl.

Диагностика реального сайта: пошаговый разбор