Проверить сайт

Скорость загрузки сайта и SEO

Почему скорость сайта влияет на SEO и продажи

Скорость загрузки — это не просто «техническая деталь». Это фактор, который напрямую влияет на:

  1. Позиции в поиске — Google использует скорость как фактор ранжирования
  2. Конверсию — чем дольше грузится страница, тем больше посетителей уходят до того, как увидят предложение
  3. Отказы — медленная загрузка заметно повышает долю уходов, особенно на мобильном интернете
  4. Краульный бюджет — медленные сайты краулятся медленнее, новые страницы индексируются позже

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

Как проверить скорость сайта

Ниже — проверки seoquest.ru по одному URL. Это не лабораторный Lighthouse/CWV целиком: смотрите конкретные узкие места (TTFB, вес, блокирующий JS, сжатие, кэш), а полный снимок — через бесплатный аудит.

1. Скорость и производительность

Сводная проверка скорости страницы: что тормозит ответ и отдачу ресурсов.

Что показывает:

  • Сигналы по производительности URL
  • Связанные проблемы (вес, сжатие, блокировки)
  • Короткий «что сделать» по находкам

2. TTFB и размер страницы

Отдельно: время до первого байта и вес HTML/ресурсов — две самые частые причины «долго грузится».

3. Блокирующие ресурсы, GZIP/Brotli, минификация, кэш

Точечные проверки: что мешает первой отрисовке, включено ли сжатие, минифицированы ли JS/CSS, отдаются ли заголовки кэша.

4. Бесплатный SEO-аудит

Краул и Health Score со блоком performance — удобно, когда нужно не один URL-инструмент, а список квестов по сайту.

5. Chrome DevTools

F12 → Network → перезагрузите страницу → время каждого ресурса и Waiting (TTFB). Для локальной лабораторной оценки — вкладка Lighthouse в том же DevTools.

Что влияет на скорость

1. Размер страницы

Чем больше страница, тем дольше она загружается. Средний вес страницы в 2026 году — около 2-3 МБ. Но лучшие сайты укладываются в 500-800 КБ.

Что увеличивает вес:

  • Несжатые изображения (каждое фото по 1-3 МБ)
  • Не минифицированный CSS и JavaScript
  • Подключённые шрифты (каждый шрифт +50-100 КБ)
  • Виджеты и скрипты аналитики

2. Время серверного отклика (TTFB)

TTFB (Time To First Byte) — время от запроса до получения первого байта от сервера. Нормальный TTFB — до 200 мс. Если больше 600 мс — сервер медленный.

Что влияет на TTFB:

  • Расстояние до сервера (география)
  • Нагрузка на сервер
  • Время обработки PHP/Python/Node.js
  • Запросы к базе данных

3. Количество запросов

Каждый файл на странице (CSS, JS, шрифт, изображение) — это отдельный HTTP-запрос. Чем больше запросов, тем дольше загрузка.

Оптимизация:

  • Объединяйте CSS и JS файлы
  • Используйте sprite-изображения
  • Внедряйте критический CSS inline

4. Блокирующий JavaScript

JavaScript, который загружается в <head> и блокирует рендеринг страницы. Пока скрипт не загрузится и не выполнится — пользователь видит белый экран.

Оптимизация:

  • Используйте defer или async для не критичного JS
  • Перенесите JS в <body>
  • Минифицируйте JavaScript

5. Несжатые ресурсы

Если сервер не сжимает HTML, CSS и JavaScript — страница весит на 60-80% больше, чем нужно.

Оптимизация: включите gzip или Brotli сжатие на сервере.

Как ускорить сайт: пошаговый план

Шаг 1: Оптимизируйте изображения

1.1 Сожмите изображения

  • Используйте WebP вместо JPG/PNG (сжатие на 25-35% лучше)
  • Используйте инструменты: TinyPNG, Squoosh, ImageOptim
  • Автоматическая конвертация в WebP через nginx или CMS-плагин

1.2 Укажите размеры

<img src="photo.webp" width="800" height="600" alt="Фото" />

Без размеров браузер не зарезервирует место — контент сдвигается при загрузке (CLS).

1.3 Используйте responsive images

<img srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1200.webp 1200w"
     sizes="(max-width: 600px) 400px, 800px"
     src="photo-800.webp" alt="Фото" />

1.4 Используйте lazy loading

<img src="photo.webp" loading="lazy" alt="Фото" />

Изображения ниже первого экрана загружаются только когда пользователь до них доскроллит.

Шаг 2: Включите сжатие (gzip / Brotli)

gzip — стандарт сжатия для большинства браузеров.

Brotli — более эффективный алгоритм (на 15-20% лучше gzip), поддерживается современными браузерами.

nginx

# Gzip
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml;
gzip_min_length 1000;
gzip_comp_level 6;

# Brotli (если собран с модулем)
brotli on;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml;
brotli_comp_level 6;

Apache (.htaccess)

# Gzip
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/css application/json application/javascript
</IfModule>

Шаг 3: Настройте кэширование

Cache-Control — заголовок, который говорит браузеру кэшировать ресурсы.

nginx

# Статика кэшируется на год
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2|woff|ttf|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

# HTML кэшируется на 1 час
location ~ \.php$ {
    expires 1h;
    add_header Cache-Control "public, must-revalidate";
}

Почему это важно: без кэширования каждый визит пользователя — полная загрузка всех ресурсов. С кэшированием — загружается только обновлённый контент.

Шаг 4: Уменьшите JavaScript

4.1 Удалите неиспользуемый код

  • Проверьте через блокирующие ресурсы и минификацию — лишний JS часто видно по весу и списку скриптов
  • Удалите библиотеки, которые не используете
  • Замените jQuery на vanilla JS, если нужно

4.2 Минифицируйте JS

  • Используйте terser, uglify-js или встроенные минификаторы сборщиков
  • Минификация уменьшает размер на 60-80%

4.3 Отложите загрузку не критичного JS

<script defer src="analytics.js"></script>
<script async src="ads.js"></script>
  • defer — загружается параллельно, выполняется после парсинга HTML
  • async — загружается параллельно, выполняется сразу после загрузки

Шаг 5: Оптимизируйте CSS

5.1 Удалите неиспользуемый CSS

  • Используйте проверку минификации и локальный Lighthouse в DevTools / PurgeCSS
  • Удалите стили, которые не используются на странице

5.2 Инлайн критический CSS
Критический CSS — стили, необходимые для отображения верхней части страницы. Встройте их прямо в HTML:

<style>
    /* критические стили для above-the-fold контента */
</style>

5.3 Отложите не критичный CSS

<link rel="preload" href="styles.css" as="style"
<noscript><link rel="stylesheet" href="styles.css"></noscript>

Шаг 6: Используйте CDN

CDN (Content Delivery Network) — сеть серверов по всему миру. Статические файлы (изображения, CSS, JS) раздаются с ближайшего к пользователю сервера.

Популярные CDN:

  • Cloudflare (бесплатный тариф)
  • BunnyCDN (дешёвый)
  • Yandex CDN (для России)

Эффект: ускорение загрузки на 30-50% для пользователей из других регионов.

Шаг 7: Оптимизируйте сервер

7.1 Используйте PHP 8.x
PHP 8 в 2-3 раза быстрее PHP 7.4.

7.2 Настройте OPcache
OPcache кэширует скомпилированный PHP-код. Без него PHP перекомпилирует каждый файл при каждом запросе.

; php.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0

7.3 Используйте кэширование базы данных
Redis или Memcached для кэширования запросов к БД.

7.4 Используйте HTTP/2 или HTTP/3
HTTP/2 поддерживает multiplexing — несколько файлов загружаются параллельно по одному соединению.

Чеклист скорости сайта

  • [ ] Скорость / TTFB без критичных замечаний
  • [ ] LCP ≤ 2.5 с (полевые данные — Search Console)
  • [ ] Изображения в WebP
  • [ ] Изображения имеют width и height
  • [ ] Lazy loading включён
  • [ ] Gzip или Brotli включён
  • [ ] Cache-Control настроен
  • [ ] JavaScript минифицирован
  • [ ] CSS минифицирован
  • [ ] CDN подключён
  • [ ] HTTP/2 включён
  • [ ] TTFB ≤ 200 мс

Итог

Скорость загрузки сайта — это совокупность многих факторов. Начните с проверки скорости и TTFB — они покажут самые проблемные места на URL. Оптимизируйте изображения, включите сжатие и кэширование, уменьшите JavaScript — и ваш сайт будет грузиться быстрее. Быстрый сайт = больше пользователей = больше конверсий = лучше позиции в поиске.

Проверить сайт по техническим и контентным пунктам можно в бесплатной проверке.

Core Web Vitals (LCP, INP, CLS)

Углубление по метрикам — на этом же URL статьи про скорость (отдельной страницы нет).

Core Web Vitals — три метрики, которые влияют на ранжирование

Core Web Vitals (CWV) — это набор метрик производительности, которые Google использует как фактор ранжирования с июня 2021 года. Они измеряют три аспекта пользовательского опыта:

  1. LCP — как быстро загружается контент
  2. INP — как быстро страница реагирует на действия пользователя
  3. CLS — насколько стабильна страница при загрузке (нет ли сдвигов)

Если хотя бы одна метрика в «плохой» зоне — страница получает низкий Page Experience Score. Это влияет на позиции в поиске, особенно на мобильных.

LCP — Largest Contentful Paint

Что измеряет

LCP — время, за которое загружается самый большой элемент контента на экране. Это может быть изображение, видео, блок текста или заголовок.

Пример: Если пользователь открывает страницу, и главное фото товара загружается за 2.5 секунды — LCP = 2.5 с.

Пороги

Оценка LCP
Хороший ≤ 2.5 с
Нуждается в улучшении 2.5–4.0 с
Плохой > 4.0 с

Что влияет на LCP

  1. Размер изображения — большое фото = долгое загрузка
  2. Серверное время отклика (TTFB) — медленный сервер = долгая загрузка
  3. Клиентская обработка — JavaScript, который блокирует рендеринг
  4. CSS-блокирующие ресурсы — стили, которые нужно загрузить перед рендерингом

Как улучшить LCP

1. Оптимизируйте изображения

  • Сжимайте изображения (WebP вместо JPG/PNG)
  • Используйте responsive images (srcset)
  • Не загружайте изображения больше, чем нужно для экрана

2. Ускорьте сервер

  • Включите кэширование (Cache-Control)
  • Используйте CDN для раздачи статики
  • Оптимизируйте базу данных

3. Уберите блокирующий JavaScript

  • Отложите загрузку не критичного JS (defer или async)
  • Минифицируйте JavaScript
  • Удалите неиспользуемый код

4. Оптимизируйте CSS

  • Удалите неиспользуемый CSS
  • Загружайте критический CSS inline
  • Отложите загрузку не критичного CSS

INP — Interaction to Next Paint

Что измеряет

INP — время между действием пользователя (клик, нажатие клавиши, касание) и следующей перерисовкой страницы. Заменяет FPS (First Input Delay) с марта 2024 года.

Пример: Пользователь кликает по кнопке «Купить» — и ждёт 0.5 секунды, пока страница отреагирует. INP = 0.5 с.

Пороги

Оценка INP
Хороший ≤ 200 мс
Нуждается в улучшении 200–500 мс
Плохой > 500 мс

Что влияет на INP

  1. Длинный JavaScript — если скрипт обрабатывается долго, пользователь ждёт
  2. Сложные вычисления — тяжёлые операции на main thread
  3. Отрисовка DOM — изменение большого количества DOM-элементов
  4. Обработчики событий — слишком много или слишком тяжёлых обработчиков

Как улучшить INP

1. Разбейте длинную задачу

  • Используйте requestAnimationFrame для тяжёлых операций
  • Разбейте большие данные на чанки
  • Используйте Web Workers для фоновых вычислений

2. Минифицируйте JavaScript

  • Удалите неиспользуемый код
  • Используйте tree-shaking
  • Загружайте только необходимый JS

3. Оптимизируйте обработчики событий

  • Дебаунс и throttle для событий скролла и resize
  • Удаляйте неиспользуемые обработчики
  • Используйте делегирование событий

4. Используйте lazy loading

  • Откладывайте загрузку компонентов, которые не нужны сразу
  • Используйте Intersection Observer для lazy loading

CLS — Cumulative Layout Shift

Что измеряет

CLS — сумма всех сдвигов макета страницы во время её загрузки. Измеряет визуальную стабильность.

Пример: Пользователь читает статью, и внезапно реклама появляется сверху, текст сдвигается вниз, и пользователь кликает не туда. CLS = 0.3.

Пороги

Оценка CLS
Хороший ≤ 0.1
Нуждается в улучшении 0.1–0.25
Плохой > 0.25

Что влияет на CLS

  1. Изображения без размеров — браузер не знает размер картинки до загрузки, и она сдвигает контент
  2. Реклама и виджеты — вставляются после загрузки и сдвигают контент
  3. Web Fonts — шрифт загружается позже, и текст перерисовывается с другим размером
  4. Динамический контент — контент, который добавляется после загрузки (например, комментарии)

Как улучшить CLS

1. Всегда указывайте width и height для изображений

<img src="photo.jpg" width="800" height="600" alt="Фото" />

Или через CSS:

img {
    width: 100%;
    height: auto;
    aspect-ratio: 4/3;
}

2. Резервируйте место для рекламы и виджетов

.ad-container {
    height: 250px;
    min-height: 250px;
}

3. Используйте font-display: swap

@font-face {
    font-family: 'MyFont';
    src: url('font.woff2') format('woff2');
    font-display: swap;
}

4. Не вставляйте динамический контент над существующим

  • Добавляйте новый контент в конец страницы
  • Используйте анимации для плавного появления
  • Резервируйте место для динамического контента

Как измерить Core Web Vitals

Полевые CWV (LCP/INP/CLS у реальных пользователей) и лабораторный Lighthouse — разные вещи. В seoquest.ru смотрите технические причины медленной страницы; сами цифры CWV из поля — в Search Console.

1. Инструменты seoquest.ru

Скорость, TTFB, размер страницы, блокирующие ресурсы — что чинить на URL. Полный снимок: бесплатный аудит.

2. Google Search Console — «Удобство страниц» / Page Experience

Доля URL с хорошими/плохими полевыми CWV по вашему свойству.

3. Chrome User Experience Report (CrUX)

Агрегированные данные реальных пользователей Chrome; удобно сверять с Search Console.

4. Lighthouse в Chrome DevTools

F12 → Lighthouse → Analyze page load — локальная лабораторная оценка (не подмена полевых CWV).

Core Web Vitals и Health Score

В Health Score seoquest.ru CWV — один из ключевых параметров:

  • LCP — если > 4.0 с, это критично
  • INP — если > 500 мс, это важно
  • CLS — если > 0.25, это критично

Чеклист Core Web Vitals

  • [ ] LCP ≤ 2.5 с
  • [ ] INP ≤ 200 мс
  • [ ] CLS ≤ 0.1
  • [ ] Изображения сжаты (WebP)
  • [ ] Изображения имеют width и height
  • [ ] CSS минифицирован
  • [ ] JavaScript минифицирован
  • [ ] Кэширование включено
  • [ ] CDN используется
  • [ ] Font-display: swap
  • [ ] Lazy loading включён

Итог

Core Web Vitals — это не просто «метрики скорости». Это измеримые показатели пользовательского опыта, которые напрямую влияют на ранжирование в Google. LCP, INP и CLS — три метрики, которые нужно оптимизировать. Начните с узких мест на URL через проверку скорости и аудит, а полевые CWV отслеживайте в Search Console.

TTFB — время отклика сервера

TTFB — сколько времени ждёт пользователь

TTFB (Time To First Byte) — время от момента, когда браузер отправляет запрос, до момента, когда он получает первый байт ответа от сервера.

Простыми словами: это время, которое пользователь ждёт перед тем, как увидеть хотя бы одну пиксель на экране.

Пороги TTFB

Оценка TTFB
Отличный ≤ 200 мс
Хороший 200–600 мс
Нуждается в улучшении 600–1200 мс
Плохой > 1200 мс

Почему это важно: TTFB — первая метрика скорости. Если TTFB = 2 секунды, пользователь видит белый экран 2 секунды. Даже если остальная страница загрузится мгновенно — эти 2 секунды уже потеряны.

Что входит в TTFB

TTFB складывается из трёх компонентов:

  1. Время сети — время доставки запроса до сервера и обратно (зависит от расстояния)
  2. Время обработки на сервере — время, которое сервер тратит на обработку запроса (PHP, база данных)
  3. Время ожидания — очередь запросов, если сервер перегружен

Пример:

  • Запрос идёт до сервера: 50 мс (сеть)
  • PHP обрабатывает запрос: 300 мс
  • Запрос к базе данных: 150 мс
  • Формирование ответа: 20 мс
  • TTFB = 520 мс

Как измерить TTFB

1. Инструмент TTFB на seoquest.ru

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

2. Через curl

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s
Total: %{time_total}s
" 'https://example.ru/'

3. Chrome DevTools

F12 → Network → Time column → «Waiting (TTFB)».

Почему TTFB высокий

1. Медленный PHP

PHP обрабатывает каждый запрос заново. Без кэширования — каждый визит = полная обработка PHP.

Решение:

  • Включите OPcache
  • Обновите PHP до 8.x (в 2-3 раза быстрее 7.x)
  • Используйте PHP-FPM

2. Медленная база данных

Каждый запрос к базе данных добавляет к TTFB. Неоптимизированные запросы — главная причина медленного PHP.

Решение:

  • Добавьте индексы в базу данных
  • Используйте кэширование (Redis, Memcached)
  • Оптимизируйте запросы

3. Расстояние до сервера

Если сервер в Москве, а пользователь во Владивостоке — время доставки запроса = 80-120 мс.

Решение: используйте CDN или хостинг ближе к аудитории.

4. Перегруженный сервер

Если на сервере много сайтов или недостаточно ресурсов — запросы стоят в очереди.

Решение: увеличьте ресурсы или перенесите на выделенный сервер.

5. Отсутствие кэширования

Без кэширования каждый запрос обрабатывается PHP заново. С кэшированием — nginx отдаёт сохранённый HTML.

Решение: включите серверное кэширование (proxy_cache в nginx).

Как ускорить TTFB

1. Включите OPcache

OPcache кэширует скомпилированный PHP-код. Без него PHP перекомпилирует каждый файл при каждом запросе.

; php.ini
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0

2. Обновите PHP до 8.x

PHP 8 в 2-3 раза быстрее PHP 7.4. Это самый простой способ ускорить PHP-сайт.

3. Включите серверное кэширование

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=php_cache:10m max_size=1g inactive=60m;

location ~ \.php$ {
    proxy_cache php_cache;
    proxy_cache_valid 200 30m;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_pass http://127.0.0.1:9000;
}

4. Оптимизируйте базу данных

  • Добавьте индексы для часто используемых запросов
  • Используйте EXPLAIN для анализа медленных запросов
  • Кэшируйте результаты в Redis

5. Используйте CDN

CDN разгружает origin-сервер, раздавая статику. Это уменьшает нагрузку и ускоряет TTFB для динамического контента.

6. Выберите правильный хостинг

Общий хостинг = медленный TTFB. VPS или выделенный сервер = быстрый TTFB. Для высоконагруженных сайтов — выделенный сервер.

TTFB и Health Score

В Health Score seoquest.ru TTFB — один из ключевых параметров:

  • TTFB > 1200 мс — критично
  • TTFB 600-1200 мс — важно
  • TTFB ≤ 600 мс — хорошо

Итог

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

Вопросы и ответы

Какая скорость считается нормальной?

Ориентир: страница ощутимо отвечает за 1–2 с, TTFB желательно ≤ 600 мс (лучше ≤ 200 мс). Смотрите TTFB и размер страницы, а не одну «оценку из чужого отчёта».

Нужно ли сжимать изображения на стороне сервера или можно через CMS?

Лучше на стороне сервера (nginx + WebP). Но многие CMS (WordPress с плагинами) справляются хорошо. Главное — чтобы изображения отдавались в WebP.

Gzip или Brotli — что лучше?

Brotli на 15-20% эффективнее gzip. Но gzip поддерживается всеми браузерами, Brotli — только современными. Настройте оба: браузер сам выберет.

CDN стоит денег?

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

Как часто нужно проверять скорость?

После каждого изменения контента или дизайна. И регулярно — хотя бы раз в квартал. Скорость может деградировать со временем (новые изображения, виджеты, скрипты).