[{"data":1,"prerenderedAt":29},["ShallowReactive",2],{"$fAh-ory4ucq71p6oP8Z4N8hQip4ce3LrjYPDS1ymiYsQ":3},{"slug":4,"title":5,"description":6,"date":7,"created_at":8,"updated_at":8,"h1":5,"content":9,"views":10,"next_articles":11},"skorost-zagruzki-sajta-seo","Скорость загрузки сайта и SEO","Скорость загрузки — это не просто «техническая деталь». Это фактор, который напрямую влияет на:","2026-08-09","2026-09-07","\u003Ch2>Почему скорость сайта влияет на SEO и продажи\u003C\u002Fh2>\n\u003Cp>Скорость загрузки — это не просто «техническая деталь». Это фактор, который напрямую влияет на:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Позиции в поиске\u003C\u002Fstrong> — Google использует скорость как фактор ранжирования\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Конверсию\u003C\u002Fstrong> — чем дольше грузится страница, тем больше посетителей уходят до того, как увидят предложение\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Отказы\u003C\u002Fstrong> — медленная загрузка заметно повышает долю уходов, особенно на мобильном интернете\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Краульный бюджет\u003C\u002Fstrong> — медленные сайты краулятся медленнее, новые страницы индексируются позже\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Если сайт заметно тормозит — вы теряете и пользователей, и, вероятно, позиции. Точных универсальных процентов тут не бывает: эффект зависит от ниши, устройства и того, откуда пришёл посетитель.\u003C\u002Fp>\n\u003Ch2>Как проверить скорость сайта\u003C\u002Fh2>\n\u003Cp>Ниже — проверки seoquest.ru по одному URL. Это не лабораторный Lighthouse\u002FCWV целиком: смотрите конкретные узкие места (TTFB, вес, блокирующий JS, сжатие, кэш), а полный снимок — через бесплатный аудит.\u003C\u002Fp>\n\u003Ch3>1. \u003Ca href=\"\u002Ftools\u002Fperformance\">Скорость и производительность\u003C\u002Fa>\u003C\u002Fh3>\n\u003Cp>Сводная проверка скорости страницы: что тормозит ответ и отдачу ресурсов.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Что показывает:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Сигналы по производительности URL\u003C\u002Fli>\u003Cli>Связанные проблемы (вес, сжатие, блокировки)\u003C\u002Fli>\u003Cli>Короткий «что сделать» по находкам\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch3>2. \u003Ca href=\"\u002Ftools\u002Fttfb\">TTFB\u003C\u002Fa> и \u003Ca href=\"\u002Ftools\u002Fpage-size\">размер страницы\u003C\u002Fa>\u003C\u002Fh3>\n\u003Cp>Отдельно: время до первого байта и вес HTML\u002Fресурсов — две самые частые причины «долго грузится».\u003C\u002Fp>\n\u003Ch3>3. \u003Ca href=\"\u002Ftools\u002Frender-blocking\">Блокирующие ресурсы\u003C\u002Fa>, \u003Ca href=\"\u002Ftools\u002Fgzip\">GZIP\u002FBrotli\u003C\u002Fa>, \u003Ca href=\"\u002Ftools\u002Fminification-check\">минификация\u003C\u002Fa>, \u003Ca href=\"\u002Ftools\u002Fcaching-headers\">кэш\u003C\u002Fa>\u003C\u002Fh3>\n\u003Cp>Точечные проверки: что мешает первой отрисовке, включено ли сжатие, минифицированы ли JS\u002FCSS, отдаются ли заголовки кэша.\u003C\u002Fp>\n\u003Ch3>4. \u003Ca href=\"\u002Fcheck\u002Ffree\">Бесплатный SEO-аудит\u003C\u002Fa>\u003C\u002Fh3>\n\u003Cp>Краул и Health Score со блоком performance — удобно, когда нужно не один URL-инструмент, а список квестов по сайту.\u003C\u002Fp>\n\u003Ch3>5. Chrome DevTools\u003C\u002Fh3>\n\u003Cp>F12 → Network → перезагрузите страницу → время каждого ресурса и Waiting (TTFB). Для локальной лабораторной оценки — вкладка Lighthouse в том же DevTools.\u003C\u002Fp>\n\u003Ch2>Что влияет на скорость\u003C\u002Fh2>\n\u003Ch3>1. Размер страницы\u003C\u002Fh3>\n\u003Cp>Чем больше страница, тем дольше она загружается. Средний вес страницы в 2026 году — около 2-3 МБ. Но лучшие сайты укладываются в 500-800 КБ.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Что увеличивает вес:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Несжатые изображения (каждое фото по 1-3 МБ)\u003C\u002Fli>\u003Cli>Не минифицированный CSS и JavaScript\u003C\u002Fli>\u003Cli>Подключённые шрифты (каждый шрифт +50-100 КБ)\u003C\u002Fli>\u003Cli>Виджеты и скрипты аналитики\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch3>2. Время серверного отклика (TTFB)\u003C\u002Fh3>\n\u003Cp>TTFB (Time To First Byte) — время от запроса до получения первого байта от сервера. Нормальный TTFB — до 200 мс. Если больше 600 мс — сервер медленный.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Что влияет на TTFB:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Расстояние до сервера (география)\u003C\u002Fli>\u003Cli>Нагрузка на сервер\u003C\u002Fli>\u003Cli>Время обработки PHP\u002FPython\u002FNode.js\u003C\u002Fli>\u003Cli>Запросы к базе данных\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch3>3. Количество запросов\u003C\u002Fh3>\n\u003Cp>Каждый файл на странице (CSS, JS, шрифт, изображение) — это отдельный HTTP-запрос. Чем больше запросов, тем дольше загрузка.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Оптимизация:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Объединяйте CSS и JS файлы\u003C\u002Fli>\u003Cli>Используйте sprite-изображения\u003C\u002Fli>\u003Cli>Внедряйте критический CSS inline\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch3>4. Блокирующий JavaScript\u003C\u002Fh3>\n\u003Cp>JavaScript, который загружается в \u003Ccode>&lt;head&gt;\u003C\u002Fcode> и блокирует рендеринг страницы. Пока скрипт не загрузится и не выполнится — пользователь видит белый экран.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Оптимизация:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Используйте \u003Ccode>defer\u003C\u002Fcode> или \u003Ccode>async\u003C\u002Fcode> для не критичного JS\u003C\u002Fli>\u003Cli>Перенесите JS в \u003Ccode>&lt;body&gt;\u003C\u002Fcode>\u003C\u002Fli>\u003Cli>Минифицируйте JavaScript\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch3>5. Несжатые ресурсы\u003C\u002Fh3>\n\u003Cp>Если сервер не сжимает HTML, CSS и JavaScript — страница весит на 60-80% больше, чем нужно.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Оптимизация:\u003C\u002Fstrong> включите gzip или Brotli сжатие на сервере.\u003C\u002Fp>\n\u003Ch2>Как ускорить сайт: пошаговый план\u003C\u002Fh2>\n\u003Ch3>Шаг 1: Оптимизируйте изображения\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>1.1 Сожмите изображения\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Используйте WebP вместо JPG\u002FPNG (сжатие на 25-35% лучше)\u003C\u002Fli>\u003Cli>Используйте инструменты: TinyPNG, Squoosh, ImageOptim\u003C\u002Fli>\u003Cli>Автоматическая конвертация в WebP через nginx или CMS-плагин\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>\u003Cstrong>1.2 Укажите размеры\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-html\">&lt;img src=&quot;photo.webp&quot; width=&quot;800&quot; height=&quot;600&quot; alt=&quot;Фото&quot; \u002F&gt;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Без размеров браузер не зарезервирует место — контент сдвигается при загрузке (CLS).\u003C\u002Fp>\n\u003Cp>\u003Cstrong>1.3 Используйте responsive images\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-html\">&lt;img srcset=&quot;photo-400.webp 400w, photo-800.webp 800w, photo-1200.webp 1200w&quot;\n     sizes=&quot;(max-width: 600px) 400px, 800px&quot;\n     src=&quot;photo-800.webp&quot; alt=&quot;Фото&quot; \u002F&gt;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>1.4 Используйте lazy loading\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-html\">&lt;img src=&quot;photo.webp&quot; loading=&quot;lazy&quot; alt=&quot;Фото&quot; \u002F&gt;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Изображения ниже первого экрана загружаются только когда пользователь до них доскроллит.\u003C\u002Fp>\n\u003Ch3>Шаг 2: Включите сжатие (gzip \u002F Brotli)\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>gzip\u003C\u002Fstrong> — стандарт сжатия для большинства браузеров.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Brotli\u003C\u002Fstrong> — более эффективный алгоритм (на 15-20% лучше gzip), поддерживается современными браузерами.\u003C\u002Fp>\n\u003Ch4>nginx\u003C\u002Fh4>\n\u003Cpre>\u003Ccode class=\"language-nginx\"># Gzip\ngzip on;\ngzip_types text\u002Fplain text\u002Fcss application\u002Fjson application\u002Fjavascript text\u002Fxml application\u002Fxml;\ngzip_min_length 1000;\ngzip_comp_level 6;\n\n# Brotli (если собран с модулем)\nbrotli on;\nbrotli_types text\u002Fplain text\u002Fcss application\u002Fjson application\u002Fjavascript text\u002Fxml application\u002Fxml;\nbrotli_comp_level 6;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch4>Apache (.htaccess)\u003C\u002Fh4>\n\u003Cpre>\u003Ccode class=\"language-apache\"># Gzip\n&lt;IfModule mod_deflate.c&gt;\n    AddOutputFilterByType DEFLATE text\u002Fhtml text\u002Fcss application\u002Fjson application\u002Fjavascript\n&lt;\u002FIfModule&gt;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Шаг 3: Настройте кэширование\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Cache-Control\u003C\u002Fstrong> — заголовок, который говорит браузеру кэшировать ресурсы.\u003C\u002Fp>\n\u003Ch4>nginx\u003C\u002Fh4>\n\u003Cpre>\u003Ccode class=\"language-nginx\"># Статика кэшируется на год\nlocation ~* \\.(jpg|jpeg|png|gif|ico|css|js|woff2|woff|ttf|svg)$ {\n    expires 1y;\n    add_header Cache-Control &quot;public, immutable&quot;;\n}\n\n# HTML кэшируется на 1 час\nlocation ~ \\.php$ {\n    expires 1h;\n    add_header Cache-Control &quot;public, must-revalidate&quot;;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>Почему это важно:\u003C\u002Fstrong> без кэширования каждый визит пользователя — полная загрузка всех ресурсов. С кэшированием — загружается только обновлённый контент.\u003C\u002Fp>\n\u003Ch3>Шаг 4: Уменьшите JavaScript\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>4.1 Удалите неиспользуемый код\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Проверьте через \u003Ca href=\"\u002Ftools\u002Frender-blocking\">блокирующие ресурсы\u003C\u002Fa> и \u003Ca href=\"\u002Ftools\u002Fminification-check\">минификацию\u003C\u002Fa> — лишний JS часто видно по весу и списку скриптов\u003C\u002Fli>\u003Cli>Удалите библиотеки, которые не используете\u003C\u002Fli>\u003Cli>Замените jQuery на vanilla JS, если нужно\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>\u003Cstrong>4.2 Минифицируйте JS\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Используйте terser, uglify-js или встроенные минификаторы сборщиков\u003C\u002Fli>\u003Cli>Минификация уменьшает размер на 60-80%\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>\u003Cstrong>4.3 Отложите загрузку не критичного JS\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-html\">&lt;script defer src=&quot;analytics.js&quot;&gt;&lt;\u002Fscript&gt;\n&lt;script async src=&quot;ads.js&quot;&gt;&lt;\u002Fscript&gt;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cul>\n\u003Cli>\u003Ccode>defer\u003C\u002Fcode> — загружается параллельно, выполняется после парсинга HTML\u003C\u002Fli>\n\u003Cli>\u003Ccode>async\u003C\u002Fcode> — загружается параллельно, выполняется сразу после загрузки\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Шаг 5: Оптимизируйте CSS\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>5.1 Удалите неиспользуемый CSS\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Используйте \u003Ca href=\"\u002Ftools\u002Fminification-check\">проверку минификации\u003C\u002Fa> и локальный Lighthouse в DevTools \u002F PurgeCSS\u003C\u002Fli>\u003Cli>Удалите стили, которые не используются на странице\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>\u003Cstrong>5.2 Инлайн критический CSS\u003C\u002Fstrong>\u003Cbr>\nКритический CSS — стили, необходимые для отображения верхней части страницы. Встройте их прямо в HTML:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-html\">&lt;style&gt;\n    \u002F* критические стили для above-the-fold контента *\u002F\n&lt;\u002Fstyle&gt;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>5.3 Отложите не критичный CSS\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-html\">&lt;link rel=&quot;preload&quot; href=&quot;styles.css&quot; as=&quot;style&quot;\n&lt;noscript&gt;&lt;link rel=&quot;stylesheet&quot; href=&quot;styles.css&quot;&gt;&lt;\u002Fnoscript&gt;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Шаг 6: Используйте CDN\u003C\u002Fh3>\n\u003Cp>CDN (Content Delivery Network) — сеть серверов по всему миру. Статические файлы (изображения, CSS, JS) раздаются с ближайшего к пользователю сервера.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Популярные CDN:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Cloudflare (бесплатный тариф)\u003C\u002Fli>\u003Cli>BunnyCDN (дешёвый)\u003C\u002Fli>\u003Cli>Yandex CDN (для России)\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Эффект:\u003C\u002Fstrong> ускорение загрузки на 30-50% для пользователей из других регионов.\u003C\u002Fp>\n\u003Ch3>Шаг 7: Оптимизируйте сервер\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>7.1 Используйте PHP 8.x\u003C\u002Fstrong>\u003Cbr>\nPHP 8 в 2-3 раза быстрее PHP 7.4.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>7.2 Настройте OPcache\u003C\u002Fstrong>\u003Cbr>\nOPcache кэширует скомпилированный PHP-код. Без него PHP перекомпилирует каждый файл при каждом запросе.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-ini\">; php.ini\nopcache.enable=1\nopcache.memory_consumption=256\nopcache.max_accelerated_files=20000\nopcache.validate_timestamps=0\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>7.3 Используйте кэширование базы данных\u003C\u002Fstrong>\u003Cbr>\nRedis или Memcached для кэширования запросов к БД.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>7.4 Используйте HTTP\u002F2 или HTTP\u002F3\u003C\u002Fstrong>\u003Cbr>\nHTTP\u002F2 поддерживает multiplexing — несколько файлов загружаются параллельно по одному соединению.\u003C\u002Fp>\n\u003Ch2>Чеклист скорости сайта\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>[ ] \u003Ca href=\"\u002Ftools\u002Fperformance\">Скорость\u003C\u002Fa> \u002F \u003Ca href=\"\u002Ftools\u002Fttfb\">TTFB\u003C\u002Fa> без критичных замечаний\u003C\u002Fli>\n\u003Cli>[ ] LCP ≤ 2.5 с (полевые данные — Search Console)\u003C\u002Fli>\n\u003Cli>[ ] Изображения в WebP\u003C\u002Fli>\n\u003Cli>[ ] Изображения имеют width и height\u003C\u002Fli>\n\u003Cli>[ ] Lazy loading включён\u003C\u002Fli>\n\u003Cli>[ ] Gzip или Brotli включён\u003C\u002Fli>\n\u003Cli>[ ] Cache-Control настроен\u003C\u002Fli>\n\u003Cli>[ ] JavaScript минифицирован\u003C\u002Fli>\n\u003Cli>[ ] CSS минифицирован\u003C\u002Fli>\n\u003Cli>[ ] CDN подключён\u003C\u002Fli>\n\u003Cli>[ ] HTTP\u002F2 включён\u003C\u002Fli>\n\u003Cli>[ ] TTFB ≤ 200 мс\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Итог\u003C\u002Fh2>\n\u003Cp>Скорость загрузки сайта — это совокупность многих факторов. Начните с \u003Ca href=\"\u002Ftools\u002Fperformance\">проверки скорости\u003C\u002Fa> и \u003Ca href=\"\u002Ftools\u002Fttfb\">TTFB\u003C\u002Fa> — они покажут самые проблемные места на URL. Оптимизируйте изображения, включите сжатие и кэширование, уменьшите JavaScript — и ваш сайт будет грузиться быстрее. Быстрый сайт = больше пользователей = больше конверсий = лучше позиции в поиске.\u003C\u002Fp>\n\u003Cp>Проверить сайт по техническим и контентным пунктам можно в \u003Ca href=\"\u002Fcheck\u002Ffree\">бесплатной проверке\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Core Web Vitals (LCP, INP, CLS)\u003C\u002Fh2>\n\u003Cp>Углубление по метрикам — на этом же URL статьи про скорость (отдельной страницы нет).\u003C\u002Fp>\n\u003Ch2>Core Web Vitals — три метрики, которые влияют на ранжирование\u003C\u002Fh2>\n\u003Cp>Core Web Vitals (CWV) — это набор метрик производительности, которые Google использует как фактор ранжирования с июня 2021 года. Они измеряют три аспекта пользовательского опыта:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>LCP\u003C\u002Fstrong> — как быстро загружается контент\u003C\u002Fli>\n\u003Cli>\u003Cstrong>INP\u003C\u002Fstrong> — как быстро страница реагирует на действия пользователя\u003C\u002Fli>\n\u003Cli>\u003Cstrong>CLS\u003C\u002Fstrong> — насколько стабильна страница при загрузке (нет ли сдвигов)\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Если хотя бы одна метрика в «плохой» зоне — страница получает низкий Page Experience Score. Это влияет на позиции в поиске, особенно на мобильных.\u003C\u002Fp>\n\u003Ch2>LCP — Largest Contentful Paint\u003C\u002Fh2>\n\u003Ch3>Что измеряет\u003C\u002Fh3>\n\u003Cp>LCP — время, за которое загружается самый большой элемент контента на экране. Это может быть изображение, видео, блок текста или заголовок.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Пример:\u003C\u002Fstrong> Если пользователь открывает страницу, и главное фото товара загружается за 2.5 секунды — LCP = 2.5 с.\u003C\u002Fp>\n\u003Ch3>Пороги\u003C\u002Fh3>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Оценка\u003C\u002Fth>\n\u003Cth>LCP\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Хороший\u003C\u002Ftd>\n\u003Ctd>≤ 2.5 с\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Нуждается в улучшении\u003C\u002Ftd>\n\u003Ctd>2.5–4.0 с\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Плохой\u003C\u002Ftd>\n\u003Ctd>&gt; 4.0 с\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Ch3>Что влияет на LCP\u003C\u002Fh3>\n\u003Col>\n\u003Cli>\u003Cstrong>Размер изображения\u003C\u002Fstrong> — большое фото = долгое загрузка\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Серверное время отклика (TTFB)\u003C\u002Fstrong> — медленный сервер = долгая загрузка\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Клиентская обработка\u003C\u002Fstrong> — JavaScript, который блокирует рендеринг\u003C\u002Fli>\n\u003Cli>\u003Cstrong>CSS-блокирующие ресурсы\u003C\u002Fstrong> — стили, которые нужно загрузить перед рендерингом\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>Как улучшить LCP\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>1. Оптимизируйте изображения\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Сжимайте изображения (WebP вместо JPG\u002FPNG)\u003C\u002Fli>\u003Cli>Используйте responsive images (\u003Ccode>srcset\u003C\u002Fcode>)\u003C\u002Fli>\u003Cli>Не загружайте изображения больше, чем нужно для экрана\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>\u003Cstrong>2. Ускорьте сервер\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Включите кэширование (Cache-Control)\u003C\u002Fli>\u003Cli>Используйте CDN для раздачи статики\u003C\u002Fli>\u003Cli>Оптимизируйте базу данных\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>\u003Cstrong>3. Уберите блокирующий JavaScript\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Отложите загрузку не критичного JS (\u003Ccode>defer\u003C\u002Fcode> или \u003Ccode>async\u003C\u002Fcode>)\u003C\u002Fli>\u003Cli>Минифицируйте JavaScript\u003C\u002Fli>\u003Cli>Удалите неиспользуемый код\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>\u003Cstrong>4. Оптимизируйте CSS\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Удалите неиспользуемый CSS\u003C\u002Fli>\u003Cli>Загружайте критический CSS inline\u003C\u002Fli>\u003Cli>Отложите загрузку не критичного CSS\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch2>INP — Interaction to Next Paint\u003C\u002Fh2>\n\u003Ch3>Что измеряет\u003C\u002Fh3>\n\u003Cp>INP — время между действием пользователя (клик, нажатие клавиши, касание) и следующей перерисовкой страницы. Заменяет FPS (First Input Delay) с марта 2024 года.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Пример:\u003C\u002Fstrong> Пользователь кликает по кнопке «Купить» — и ждёт 0.5 секунды, пока страница отреагирует. INP = 0.5 с.\u003C\u002Fp>\n\u003Ch3>Пороги\u003C\u002Fh3>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Оценка\u003C\u002Fth>\n\u003Cth>INP\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Хороший\u003C\u002Ftd>\n\u003Ctd>≤ 200 мс\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Нуждается в улучшении\u003C\u002Ftd>\n\u003Ctd>200–500 мс\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Плохой\u003C\u002Ftd>\n\u003Ctd>&gt; 500 мс\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Ch3>Что влияет на INP\u003C\u002Fh3>\n\u003Col>\n\u003Cli>\u003Cstrong>Длинный JavaScript\u003C\u002Fstrong> — если скрипт обрабатывается долго, пользователь ждёт\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Сложные вычисления\u003C\u002Fstrong> — тяжёлые операции на main thread\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Отрисовка DOM\u003C\u002Fstrong> — изменение большого количества DOM-элементов\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Обработчики событий\u003C\u002Fstrong> — слишком много или слишком тяжёлых обработчиков\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>Как улучшить INP\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>1. Разбейте длинную задачу\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Используйте \u003Ccode>requestAnimationFrame\u003C\u002Fcode> для тяжёлых операций\u003C\u002Fli>\u003Cli>Разбейте большие данные на чанки\u003C\u002Fli>\u003Cli>Используйте Web Workers для фоновых вычислений\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>\u003Cstrong>2. Минифицируйте JavaScript\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Удалите неиспользуемый код\u003C\u002Fli>\u003Cli>Используйте tree-shaking\u003C\u002Fli>\u003Cli>Загружайте только необходимый JS\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>\u003Cstrong>3. Оптимизируйте обработчики событий\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Дебаунс и throttle для событий скролла и resize\u003C\u002Fli>\u003Cli>Удаляйте неиспользуемые обработчики\u003C\u002Fli>\u003Cli>Используйте делегирование событий\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>\u003Cstrong>4. Используйте lazy loading\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Откладывайте загрузку компонентов, которые не нужны сразу\u003C\u002Fli>\u003Cli>Используйте Intersection Observer для lazy loading\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch2>CLS — Cumulative Layout Shift\u003C\u002Fh2>\n\u003Ch3>Что измеряет\u003C\u002Fh3>\n\u003Cp>CLS — сумма всех сдвигов макета страницы во время её загрузки. Измеряет визуальную стабильность.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Пример:\u003C\u002Fstrong> Пользователь читает статью, и внезапно реклама появляется сверху, текст сдвигается вниз, и пользователь кликает не туда. CLS = 0.3.\u003C\u002Fp>\n\u003Ch3>Пороги\u003C\u002Fh3>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Оценка\u003C\u002Fth>\n\u003Cth>CLS\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Хороший\u003C\u002Ftd>\n\u003Ctd>≤ 0.1\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Нуждается в улучшении\u003C\u002Ftd>\n\u003Ctd>0.1–0.25\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Плохой\u003C\u002Ftd>\n\u003Ctd>&gt; 0.25\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Ch3>Что влияет на CLS\u003C\u002Fh3>\n\u003Col>\n\u003Cli>\u003Cstrong>Изображения без размеров\u003C\u002Fstrong> — браузер не знает размер картинки до загрузки, и она сдвигает контент\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Реклама и виджеты\u003C\u002Fstrong> — вставляются после загрузки и сдвигают контент\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Web Fonts\u003C\u002Fstrong> — шрифт загружается позже, и текст перерисовывается с другим размером\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Динамический контент\u003C\u002Fstrong> — контент, который добавляется после загрузки (например, комментарии)\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>Как улучшить CLS\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>1. Всегда указывайте width и height для изображений\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-html\">&lt;img src=&quot;photo.jpg&quot; width=&quot;800&quot; height=&quot;600&quot; alt=&quot;Фото&quot; \u002F&gt;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Или через CSS:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-css\">img {\n    width: 100%;\n    height: auto;\n    aspect-ratio: 4\u002F3;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>2. Резервируйте место для рекламы и виджетов\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-css\">.ad-container {\n    height: 250px;\n    min-height: 250px;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>3. Используйте font-display: swap\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-css\">@font-face {\n    font-family: 'MyFont';\n    src: url('font.woff2') format('woff2');\n    font-display: swap;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>4. Не вставляйте динамический контент над существующим\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Добавляйте новый контент в конец страницы\u003C\u002Fli>\u003Cli>Используйте анимации для плавного появления\u003C\u002Fli>\u003Cli>Резервируйте место для динамического контента\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch2>Как измерить Core Web Vitals\u003C\u002Fh2>\n\u003Cp>Полевые CWV (LCP\u002FINP\u002FCLS у реальных пользователей) и лабораторный Lighthouse — разные вещи. В seoquest.ru смотрите технические причины медленной страницы; сами цифры CWV из поля — в Search Console.\u003C\u002Fp>\n\u003Ch3>1. Инструменты seoquest.ru\u003C\u002Fh3>\n\u003Cp>\u003Ca href=\"\u002Ftools\u002Fperformance\">Скорость\u003C\u002Fa>, \u003Ca href=\"\u002Ftools\u002Fttfb\">TTFB\u003C\u002Fa>, \u003Ca href=\"\u002Ftools\u002Fpage-size\">размер страницы\u003C\u002Fa>, \u003Ca href=\"\u002Ftools\u002Frender-blocking\">блокирующие ресурсы\u003C\u002Fa> — что чинить на URL. Полный снимок: \u003Ca href=\"\u002Fcheck\u002Ffree\">бесплатный аудит\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch3>2. Google Search Console — «Удобство страниц» \u002F Page Experience\u003C\u002Fh3>\n\u003Cp>Доля URL с хорошими\u002Fплохими полевыми CWV по вашему свойству.\u003C\u002Fp>\n\u003Ch3>3. Chrome User Experience Report (CrUX)\u003C\u002Fh3>\n\u003Cp>Агрегированные данные реальных пользователей Chrome; удобно сверять с Search Console.\u003C\u002Fp>\n\u003Ch3>4. Lighthouse в Chrome DevTools\u003C\u002Fh3>\n\u003Cp>F12 → Lighthouse → Analyze page load — локальная лабораторная оценка (не подмена полевых CWV).\u003C\u002Fp>\n\u003Ch2>Core Web Vitals и Health Score\u003C\u002Fh2>\n\u003Cp>В Health Score seoquest.ru CWV — один из ключевых параметров:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>LCP\u003C\u002Fstrong> — если &gt; 4.0 с, это критично\u003C\u002Fli>\n\u003Cli>\u003Cstrong>INP\u003C\u002Fstrong> — если &gt; 500 мс, это важно\u003C\u002Fli>\n\u003Cli>\u003Cstrong>CLS\u003C\u002Fstrong> — если &gt; 0.25, это критично\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Чеклист Core Web Vitals\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>[ ] LCP ≤ 2.5 с\u003C\u002Fli>\n\u003Cli>[ ] INP ≤ 200 мс\u003C\u002Fli>\n\u003Cli>[ ] CLS ≤ 0.1\u003C\u002Fli>\n\u003Cli>[ ] Изображения сжаты (WebP)\u003C\u002Fli>\n\u003Cli>[ ] Изображения имеют width и height\u003C\u002Fli>\n\u003Cli>[ ] CSS минифицирован\u003C\u002Fli>\n\u003Cli>[ ] JavaScript минифицирован\u003C\u002Fli>\n\u003Cli>[ ] Кэширование включено\u003C\u002Fli>\n\u003Cli>[ ] CDN используется\u003C\u002Fli>\n\u003Cli>[ ] Font-display: swap\u003C\u002Fli>\n\u003Cli>[ ] Lazy loading включён\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Итог\u003C\u002Fh2>\n\u003Cp>Core Web Vitals — это не просто «метрики скорости». Это измеримые показатели пользовательского опыта, которые напрямую влияют на ранжирование в Google. LCP, INP и CLS — три метрики, которые нужно оптимизировать. Начните с узких мест на URL через \u003Ca href=\"\u002Ftools\u002Fperformance\">проверку скорости\u003C\u002Fa> и \u003Ca href=\"\u002Fcheck\u002Ffree\">аудит\u003C\u002Fa>, а полевые CWV отслеживайте в Search Console.\u003C\u002Fp>\n\u003Ch2>TTFB — время отклика сервера\u003C\u002Fh2>\n\u003Ch2>TTFB — сколько времени ждёт пользователь\u003C\u002Fh2>\n\u003Cp>TTFB (Time To First Byte) — время от момента, когда браузер отправляет запрос, до момента, когда он получает первый байт ответа от сервера.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Простыми словами:\u003C\u002Fstrong> это время, которое пользователь ждёт перед тем, как увидеть хотя бы одну пиксель на экране.\u003C\u002Fp>\n\u003Ch3>Пороги TTFB\u003C\u002Fh3>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Оценка\u003C\u002Fth>\n\u003Cth>TTFB\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Отличный\u003C\u002Ftd>\n\u003Ctd>≤ 200 мс\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Хороший\u003C\u002Ftd>\n\u003Ctd>200–600 мс\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Нуждается в улучшении\u003C\u002Ftd>\n\u003Ctd>600–1200 мс\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Плохой\u003C\u002Ftd>\n\u003Ctd>&gt; 1200 мс\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>\u003Cstrong>Почему это важно:\u003C\u002Fstrong> TTFB — первая метрика скорости. Если TTFB = 2 секунды, пользователь видит белый экран 2 секунды. Даже если остальная страница загрузится мгновенно — эти 2 секунды уже потеряны.\u003C\u002Fp>\n\u003Ch2>Что входит в TTFB\u003C\u002Fh2>\n\u003Cp>TTFB складывается из трёх компонентов:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Время сети\u003C\u002Fstrong> — время доставки запроса до сервера и обратно (зависит от расстояния)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Время обработки на сервере\u003C\u002Fstrong> — время, которое сервер тратит на обработку запроса (PHP, база данных)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Время ожидания\u003C\u002Fstrong> — очередь запросов, если сервер перегружен\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>\u003Cstrong>Пример:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Запрос идёт до сервера: 50 мс (сеть)\u003C\u002Fli>\u003Cli>PHP обрабатывает запрос: 300 мс\u003C\u002Fli>\u003Cli>Запрос к базе данных: 150 мс\u003C\u002Fli>\u003Cli>Формирование ответа: 20 мс\u003C\u002Fli>\u003Cli>\u003Cstrong>TTFB = 520 мс\u003C\u002Fstrong>\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch2>Как измерить TTFB\u003C\u002Fh2>\n\u003Ch3>1. \u003Ca href=\"\u002Ftools\u002Fttfb\">Инструмент TTFB на seoquest.ru\u003C\u002Fa>\u003C\u002Fh3>\n\u003Cp>Вставьте URL — получите время до первого байта и понятный вердикт без сторонних сервисов.\u003C\u002Fp>\n\u003Ch3>2. Через curl\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-bash\">curl -o \u002Fdev\u002Fnull -s -w &quot;TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n&quot; 'https:\u002F\u002Fexample.ru\u002F'\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>3. Chrome DevTools\u003C\u002Fh3>\n\u003Cp>F12 → Network → Time column → «Waiting (TTFB)».\u003C\u002Fp>\n\u003Ch2>Почему TTFB высокий\u003C\u002Fh2>\n\u003Ch3>1. Медленный PHP\u003C\u002Fh3>\n\u003Cp>PHP обрабатывает каждый запрос заново. Без кэширования — каждый визит = полная обработка PHP.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Решение:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Включите OPcache\u003C\u002Fli>\u003Cli>Обновите PHP до 8.x (в 2-3 раза быстрее 7.x)\u003C\u002Fli>\u003Cli>Используйте PHP-FPM\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch3>2. Медленная база данных\u003C\u002Fh3>\n\u003Cp>Каждый запрос к базе данных добавляет к TTFB. Неоптимизированные запросы — главная причина медленного PHP.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Решение:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Добавьте индексы в базу данных\u003C\u002Fli>\u003Cli>Используйте кэширование (Redis, Memcached)\u003C\u002Fli>\u003Cli>Оптимизируйте запросы\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch3>3. Расстояние до сервера\u003C\u002Fh3>\n\u003Cp>Если сервер в Москве, а пользователь во Владивостоке — время доставки запроса = 80-120 мс.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Решение:\u003C\u002Fstrong> используйте CDN или хостинг ближе к аудитории.\u003C\u002Fp>\n\u003Ch3>4. Перегруженный сервер\u003C\u002Fh3>\n\u003Cp>Если на сервере много сайтов или недостаточно ресурсов — запросы стоят в очереди.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Решение:\u003C\u002Fstrong> увеличьте ресурсы или перенесите на выделенный сервер.\u003C\u002Fp>\n\u003Ch3>5. Отсутствие кэширования\u003C\u002Fh3>\n\u003Cp>Без кэширования каждый запрос обрабатывается PHP заново. С кэшированием — nginx отдаёт сохранённый HTML.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Решение:\u003C\u002Fstrong> включите серверное кэширование (proxy_cache в nginx).\u003C\u002Fp>\n\u003Ch2>Как ускорить TTFB\u003C\u002Fh2>\n\u003Ch3>1. Включите OPcache\u003C\u002Fh3>\n\u003Cp>OPcache кэширует скомпилированный PHP-код. Без него PHP перекомпилирует каждый файл при каждом запросе.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-ini\">; php.ini\nopcache.enable=1\nopcache.memory_consumption=256\nopcache.max_accelerated_files=20000\nopcache.validate_timestamps=0\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>2. Обновите PHP до 8.x\u003C\u002Fh3>\n\u003Cp>PHP 8 в 2-3 раза быстрее PHP 7.4. Это самый простой способ ускорить PHP-сайт.\u003C\u002Fp>\n\u003Ch3>3. Включите серверное кэширование\u003C\u002Fh3>\n\u003Cpre>\u003Ccode class=\"language-nginx\">proxy_cache_path \u002Fvar\u002Fcache\u002Fnginx levels=1:2 keys_zone=php_cache:10m max_size=1g inactive=60m;\n\nlocation ~ \\.php$ {\n    proxy_cache php_cache;\n    proxy_cache_valid 200 30m;\n    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;\n    proxy_pass http:\u002F\u002F127.0.0.1:9000;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>4. Оптимизируйте базу данных\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Добавьте индексы для часто используемых запросов\u003C\u002Fli>\n\u003Cli>Используйте EXPLAIN для анализа медленных запросов\u003C\u002Fli>\n\u003Cli>Кэшируйте результаты в Redis\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>5. Используйте CDN\u003C\u002Fh3>\n\u003Cp>CDN разгружает origin-сервер, раздавая статику. Это уменьшает нагрузку и ускоряет TTFB для динамического контента.\u003C\u002Fp>\n\u003Ch3>6. Выберите правильный хостинг\u003C\u002Fh3>\n\u003Cp>Общий хостинг = медленный TTFB. VPS или выделенный сервер = быстрый TTFB. Для высоконагруженных сайтов — выделенный сервер.\u003C\u002Fp>\n\u003Ch2>TTFB и Health Score\u003C\u002Fh2>\n\u003Cp>В Health Score seoquest.ru TTFB — один из ключевых параметров:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>TTFB &gt; 1200 мс\u003C\u002Fstrong> — критично\u003C\u002Fli>\n\u003Cli>\u003Cstrong>TTFB 600-1200 мс\u003C\u002Fstrong> — важно\u003C\u002Fli>\n\u003Cli>\u003Cstrong>TTFB ≤ 600 мс\u003C\u002Fstrong> — хорошо\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Итог\u003C\u002Fh2>\n\u003Cp>TTFB — первая и самая важная метрика скорости. Если TTFB высокий, пользователь ждёт белый экран долго, независимо от того, как быстро загрузится остальная страница. Оптимизируйте PHP, базу данных и включите кэширование — и TTFB станет быстрее.\u003C\u002Fp>\n\u003Csection class=\"blog-faq\">\n\u003Ch2>Вопросы и ответы\u003C\u002Fh2>\n\u003Cdetails>\u003Csummary>Какая скорость считается нормальной?\u003C\u002Fsummary>\u003Cp>Ориентир: страница ощутимо отвечает за 1–2 с, TTFB желательно ≤ 600 мс (лучше ≤ 200 мс). Смотрите \u003Ca href=\"\u002Ftools\u002Fttfb\">TTFB\u003C\u002Fa> и \u003Ca href=\"\u002Ftools\u002Fpage-size\">размер страницы\u003C\u002Fa>, а не одну «оценку из чужого отчёта».\u003C\u002Fp>\u003C\u002Fdetails>\n\u003Cdetails>\u003Csummary>Нужно ли сжимать изображения на стороне сервера или можно через CMS?\u003C\u002Fsummary>\u003Cp>Лучше на стороне сервера (nginx + WebP). Но многие CMS (WordPress с плагинами) справляются хорошо. Главное — чтобы изображения отдавались в WebP.\u003C\u002Fp>\u003C\u002Fdetails>\n\u003Cdetails>\u003Csummary>Gzip или Brotli — что лучше?\u003C\u002Fsummary>\u003Cp>Brotli на 15-20% эффективнее gzip. Но gzip поддерживается всеми браузерами, Brotli — только современными. Настройте оба: браузер сам выберет.\u003C\u002Fp>\u003C\u002Fdetails>\n\u003Cdetails>\u003Csummary>CDN стоит денег?\u003C\u002Fsummary>\u003Cp>Cloudflare имеет бесплатный тариф, который покрывает большинство сайтов. Платные тарифы дают больше функций, но для начала бесплатный достаточно.\u003C\u002Fp>\u003C\u002Fdetails>\n\u003Cdetails>\u003Csummary>Как часто нужно проверять скорость?\u003C\u002Fsummary>\u003Cp>После каждого изменения контента или дизайна. И регулярно — хотя бы раз в квартал. Скорость может деградировать со временем (новые изображения, виджеты, скрипты).\u003C\u002Fp>\u003C\u002Fdetails>\n\u003C\u002Fsection>",0,[12,15,19,23,26],{"slug":13,"title":14,"date":7,"views":10},"mobilnaya-versiya-sajta","Мобильная версия сайта для поиска",{"slug":16,"title":17,"date":18,"views":10},"sitemap-xml-proverka-i-nastrojka","Sitemap.xml: проверка и настройка","2026-08-16",{"slug":20,"title":21,"date":22,"views":10},"perespam-i-skrytyj-tekst","Переспам и скрытый текст: риски для сайта","2026-08-15",{"slug":24,"title":25,"date":7,"views":10},"favicon-i-ikonki","Favicon и иконки сайта",{"slug":27,"title":28,"date":7,"views":10},"blog-dlya-seo","Блог для SEO: как вести и что писать",1789381424947]