Чтобы ускорить загрузку сайта, начните с read-only диагностики: измерьте TTFB, LCP/FCP и найдите блокирующие ресурсы в DevTools и Lighthouse. Чаще всего тормозят медленный серверный ответ, тяжёлые изображения/шрифты и синхронный JavaScript. Затем исправляйте по приоритету: сначала быстрые и безопасные правки, потом - изменения кеширования, CDN и инфраструктуры.

Краткая карта симптомов и приоритеты устранения

Долгое ожидание до начала загрузки → фокус на TTFB: сервер/БД/кеш/сеть; сначала измерить в DevTools, потом оптимизировать.
Контент появляется поздно → бьём по LCP: изображения героя, критический CSS, приоритет загрузки.
Белый экран/рывки до первого текста → FCP: блокирующие CSS/JS, шрифты, порядок загрузки.
Интерфейс "прыгает" → CLS: размеры медиа, место под баннеры/виджеты, поведение шрифтов.
Долго грузится только у части аудитории → география/провайдеры: CDN, маршрутизация, TLS/HTTP2/HTTP3.
После правок стало хуже → откат и повторная проверка скорости загрузки сайта на тех же страницах/условиях; исключить кэш-иллюзии.

Медленные первые байты (TTFB): где смотреть и как ускорить

Что видит пользователь:

долгая пауза до появления любого контента (страница "думает");
спиннер крутится, но загрузка не начинается;
первый переход на страницу особенно медленный, а повторный заметно быстрее;
в админке/каталоге всё медленно, даже без тяжёлых картинок.

Где смотреть (read-only):

Chrome DevTools → Network: откройте документ (HTML) и проверьте Waiting (TTFB). Если TTFB доминирует - проблема до фронтенда.
DevTools → Performance: убедитесь, что задержка именно до получения ответа, а не в рендере.
Server Timing (если есть заголовок Server-Timing): помогает понять, где время - PHP/БД/кеш.

Приоритетные действия:

Сначала исключите "ложные" тормоза: отключите DevTools cache, проверьте в инкогнито, выполните 2-3 прогона и сравните первый/повторный запрос (кеш).
Быстрое ускорение: включите серверный кеш для HTML (если уместно) и проверьте, что ответы отдаются с корректными заголовками Cache-Control/ETag для статических ресурсов.

Контрольные метрики: TTFB (в Network), косвенно улучшит FCP/LCP, если фронтенд не блокирует рендер.

Тяжёлые ресурсы - изображения, видео и веб-шрифты

Короткий чек-лист быстрой диагностики (read-only), чтобы понять, где нужна оптимизация скорости сайта именно на уровне ресурсов:

В DevTools → Network отсортируйте по Size и Time: есть ли один "гигант", который тянет LCP.
Откройте вкладку Media (если доступна) или фильтр по типу: не скачивается ли видео сразу вместо постера.
Проверьте, что изображения отдаются в современных форматах (где возможно) и не грузятся "в оригинале" без ресайза.
Убедитесь, что у всех <img> заданы width/height или корректные CSS-ограничения (влияние на CLS).
Проверьте loading="lazy" для изображений ниже первого экрана; исключите lazy для LCP-изображения (герой).
Проверьте srcset/sizes: не скачивает ли мобильный устройство десктопную картинку.
Шрифты: сколько начертаний грузится и не тянутся ли они с разных доменов без preconnect.
Посмотрите Waterfall: есть ли последовательные загрузки шрифтов из-за CSS, который приходит поздно.
Проверьте, не подключены ли одновременно несколько семейств шрифтов "на всякий случай".
Проверьте, что изображения и шрифты отдаются со сжатием и корректными кеш-заголовками (для статики).

Контрольные метрики: LCP (главное изображение/блок), CLS (размеры медиа/шрифтов), FCP (ранний CSS/шрифты).

Блокирующие JavaScript и порядок загрузки контента

Типовые причины: синхронные скрипты в <head>, тяжёлые бандлы без code splitting, ранний запуск виджетов/аналитики, критический CSS грузится поздно, лишние полифиллы. Это часто проявляется как "пусто, потом всё сразу", при том что сеть уже что-то скачала - плохой FCP/LCP и задержка интерактива.

Что сделать в первую очередь (read-only проверки):

DevTools → Network: включите фильтр JS, посмотрите, какие файлы грузятся до первого рендера, и есть ли длинные "паузы" из-за последовательности.
DevTools → Performance: найдите длинные Long tasks на main thread сразу после загрузки.

Симптом	Возможные причины	Как проверить	Как исправить
Белый экран до появления текста (плохой FCP)	CSS/JS в `<head>` блокируют рендер; шрифты блокируют отображение	DevTools → Network: ранние CSS/JS; Performance: рендер начинается поздно	Вынести некритичный JS с `defer`; критический CSS - раньше; шрифты - ограничить и настроить поведение загрузки
LCP сильно позже загрузки HTML	LCP-ресурс грузится поздно из-за приоритетов; герой в фоне через CSS	Lighthouse/DevTools: identify LCP element; Waterfall - когда стартует его запрос	Сделать LCP-изображение явным `<img>` где уместно; поднять приоритет загрузки; убрать lazy для LCP
"Подвисания" сразу после загрузки	Тяжёлые бандлы, инициализация виджетов, лишние библиотеки	Performance: Long tasks; Coverage: много неиспользуемого JS	Code splitting; отложенная инициализация; удаление лишних зависимостей; перенос части логики на сервер
CLS растёт при догрузке скриптов/виджетов	Виджеты вставляют блоки без заранее выделенного места	Performance/Experience: Layout shifts; визуально "прыжки"	Зарезервировать размеры контейнеров; отложить вставку ниже первого экрана; стабилизировать размеры баннеров/плашек

Контрольные метрики: FCP (ранний рендер), LCP (приоритет героя), CLS (стабильность), косвенно TTFB не меняется.

Сервер, хостинг и кеширование: настройки, которые реально влияют

Ниже - последовательность "от безопасных к рискованным", чтобы ускорить загрузку сайта, не ломая прод и сохраняя возможность отката. Сначала делайте read-only замеры до/после на одинаковых URL.

Снимите базовую точку: для 2-3 ключевых страниц зафиксируйте TTFB/FCP/LCP/CLS (DevTools + Lighthouse) и сохраните HAR.
Проверьте кеширование статики (CSS/JS/изображения/шрифты): корректные Cache-Control, отсутствие случайной инвалидции из-за разных query string без нужды.
Включите/проверьте сжатие (gzip/brotli на уровне веб-сервера или CDN) для HTML/CSS/JS - это обычно низкорисковая настройка.
Стабилизируйте генерацию HTML: найдите "медленные" маршруты (логирование, профилирование, APM) и уберите лишние запросы к БД на первом экране.
Добавьте серверный кеш HTML там, где уместно: для страниц без персонализации или с вариациями по небольшому числу ключей (язык/город).
Оптимизируйте БД: индексы, устранение N+1, кеш запросов на уровне приложения; это часто даёт сильный эффект на TTFB, но требует аккуратности.
Пересмотрите PHP-FPM/Node/worker-пул и лимиты: очереди запросов и нехватка воркеров создают "ступеньки" задержек.
Вынесите тяжёлые операции из критического пути: генерацию превью, обращения к внешним API, сложную персонализацию - в фоновые задачи.
Инфраструктурные изменения: смена тарифа/хостинга, выделенные ресурсы, балансировка - делайте после подтверждения, что узкое место именно CPU/RAM/IO.

Контрольные метрики: прежде всего TTFB; затем FCP/LCP улучшатся, если фронтенд не блокирует рендер.

Сетевые задержки, CDN и географическое распределение трафика

Эскалируйте в поддержку хостинга или привлекайте специалистов, если наблюдается один из признаков ниже - это часто выходит за рамки "подкрутить фронтенд" и требует сетевой/серверной экспертизы. В такой ситуации нередко разумнее купить услуги по ускорению сайта, чем пытаться угадать причину.

TTFB скачет волнами по времени суток при одинаковых страницах: вероятна конкуренция за ресурсы, очередь воркеров, лимиты на стороне провайдера.
Проблема геозависима: в одном регионе быстро, в другом медленно - нужна CDN, корректная маршрутизация, близкие PoP.
Долго устанавливается соединение (DNS/TLS/Connect заметны в Waterfall): требуется настройка DNS, TLS, HTTP/2/HTTP/3, preconnect, иногда - смена провайдера.
Много статики с разных доменов (шрифты, аналитика, виджеты): нужен аудит третьих сторон и политика загрузки (отложенная/условная).
Нет возможности безопасно внедрять изменения (нет staging, нет отката, нет наблюдаемости): сначала построить процесс, потом оптимизация PageSpeed сайта.

Что подготовить для эскалации: HAR-файлы, время и регион теста, список URL, заголовки ответа (кеш/сжатие), трассировку (если доступна), сравнение "первый/повторный" запрос.

Диагностика в действии: инструменты, метрики и план исправлений

Скорость загрузки сайта: главные причины тормозов и как их исправить - иллюстрация

Ниже - практичный план, который сочетает проверку скорости загрузки сайта и последовательное исправление по принципу "самое вероятное и быстро проверяемое - первым".

Выберите контрольные страницы: главная, категория/листинг, карточка, статья - и фиксируйте изменения только на них.
Разделите лабораторные и полевые данные: DevTools/Lighthouse для воспроизводимости; реальные метрики - через ваш RUM (если есть) для проверки эффекта на аудитории.
Снимайте одинаковые прогоны: один браузер, чистый профиль, одинаковая сеть, 2-3 повторения; иначе легко "оптимизировать" кэш.
Работайте от метрики к причине: плохой TTFB - сервер/сеть; плохой LCP - герой/критический путь; CLS - размеры/вставки; FCP - блокировки рендера.
Делайте изменения малыми партиями: один тип правок за раз (например, только шрифты), затем повторный замер и запись результатов.
Контролируйте третьи стороны: аналитика/чаты/виджеты - отдельный список, отдельные решения (отложенная загрузка, после согласия, по условиям).
Удерживайте бюджет: зафиксируйте допустимые границы по весу и количеству запросов для критического пути и проверяйте на CI/релизе.
Повторяйте цикл: измерение → гипотеза → правка → измерение → документирование (что изменили и что это дало).

Матрица "симптом → приоритет → ориентир по времени"

Симптом	Что чаще всего виновато	Приоритет	Ориентир по времени на исправление
Долгая пауза до старта загрузки	Высокий TTFB: сервер/БД/очереди/кеш	Высокий	Часы-дни (после замеров)
Поздний главный контент (LCP)	Герой-картинка, приоритеты, критический CSS	Высокий	Часы
Белый экран до первого текста (FCP)	Блокирующие CSS/JS, шрифты	Высокий	Часы
Прыжки макета (CLS)	Нет размеров медиа, виджеты, баннеры	Средний	Минуты-часы
Медленно только в отдельных регионах	Сеть/маршрутизация/CDN	Средний-высокий	Дни (включая согласования)
Много скачиваний, но пользы мало	Лишний JS/виджеты, нет code splitting	Средний	Дни

Если вы делаете оптимизация PageSpeed сайта как проект, не начинайте с "всё минифицировать": сначала устраните блокировки рендера, приведите в порядок LCP-элемент и проверьте, что TTFB не является главным ограничением. Это быстрее даёт заметный результат и снижает риск регрессий.

Типичные симптомы - краткие решения

TTFB большой, но страница лёгкая. Что делать в первую очередь?

Сначала подтвердите TTFB на HTML-документе в DevTools (Waiting). Затем проверьте кеширование HTML/статических ресурсов и исключите медленные маршруты (профилирование/логи), прежде чем трогать фронтенд.

LCP плохой из-за "героя" на главной. Как быстро улучшить?

Найдите LCP-элемент в Lighthouse/DevTools и убедитесь, что он запрашивается рано. Уберите lazy для LCP-изображения, задайте правильные размеры и не прячьте герой в тяжёлом фоне CSS без необходимости.

FCP медленный: сначала пусто, потом появляется всё сразу. Куда смотреть?

Проверьте блокирующие CSS/JS в <head> и длинные задачи в Performance. Часто помогает перевод некритичного JS на defer и упорядочивание критического CSS.

CLS высокий: элементы прыгают при загрузке. Как стабилизировать?

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

После "ускорения" стало хуже. Как безопасно откатиться и проверить?

Откатите изменения по одному и повторите замеры на тех же страницах и условиях. Сравнивайте HAR и метрики FCP/LCP/CLS, не полагаясь на субъективные ощущения из-за кеша.

Как понять, что нужны услуги по ускорению сайта, а не точечные правки?

Если деградация зависит от региона/времени суток, а также если без APM/логов невозможно объяснить TTFB, подключайте специалистов. Это быстрее, чем гадать, где узкое место: сеть, очередь воркеров или БД.

Какая оптимизация скорости сайта обычно даёт эффект быстрее всего?

Чаще всего - исправление блокирующих ресурсов, оптимизация LCP-элемента и строгий контроль третьих сторон. Но если TTFB доминирует, эффект даст только серверная часть и кеширование.