А потом заходите на сайт с телефона в метро - и три секунды белого экрана.
Или обратная ситуация: конкурент на «кривом» WordPress с тяжёлой темой и двадцатью плагинами. PageSpeed показывает 52. Жёлтая зона, почти красная. Но сайт открывается за секунду. Пользователи не жалуются. Конверсия растёт.
Вопрос, который неудобно задавать на SEO-конференциях: если PageSpeed не отражает реальную скорость, зачем мы тратим на него сотни часов?
Ответ простой и неприятный: потому что Google сказал. А Google, как выясняется, оптимизирует не ваш сайт. Он оптимизирует интернет в Лагосе и Джакарте.
Что на самом деле измеряет Google PageSpeed Insights
Давайте разберём, что происходит, когда вы нажимаете «Analyze».
PageSpeed Insights запускает Lighthouse - автоматический аудит в строго контролируемых условиях:
- Устройство: эмуляция Moto G4 (бюджетный смартфон 2016 года, $100)
- CPU: throttling 4x (искусственное замедление процессора)
- Сеть: 1.6 Mbps download, 750 Kbps upload, 150 мс RTT
- Кэш: полностью очищен, холодный старт
- Геолокация: один сервер Google, обычно в США
- Прогон: один-единственный запрос
На выходе - набор метрик: LCP, FCP, TBT, CLS, TTFB, INP. Красивые цифры, цветовая шкала, список «рекомендаций».
Но это не скорость вашего сайта. Это скорость рендеринга HTML-документа в вакууме, на эмулированном бюджетном телефоне, через artificially throttled канал, без кэша, без CDN-попадания, без реального пользователя. Это лабораторный анализ крови, а не самочувствие пациента.
Лаборатория vs. реальность: почему цифры врут
Существует два типа данных о скорости:
Lab data (то, что показывает PSI): один запрос, чистый кэш, фиксированная точка, эмуляция. Воспроизводимо, стабильно, оторвано от жизни.
Field data / RUM (то, что видят пользователи): DNS-кэш браузера, TCP warm-up, попадание в CDN-ноду, реальный Wi-Fi или LTE, фоновые процессы на устройстве, рекламные скрипты, расширения.
Расхождение между ними - 20–40 баллов - норма. Google сам публикует CrUX (Chrome User Experience Report), и эти данные часто противоречат Lighthouse.
Простой пример: PSI тестирует ваш сайт из дата-центра в Айове. Ваша аудитория - в Берлине. TTFB из Айовы: 220 мс. TTFB из Берлина при сервере во Франкфурте: 12 мс. Разница - 208 мс. Но PSI этого не видит. Он ставит вам «красный» TTFB и советует «уменьшить время ответа сервера». Сервер отвечает за 40 мс. Проблема не в сервере. Проблема в том, что Google меряет из-за океана.
Для кого написаны рекомендации Google (спойлер: не для вас)
Вот ключевой момент, который упускают 90% статей про «оптимизацию скорости».
Google проектирует свои рекомендации под emerging markets: Индия, Нигерия, Индонезия, Бразилия. Страны, где:
- Средний мобильный канал: 3G, 1–4 Mbps
- Эталонное устройство: Android за $80–120
- Пользователи экономят трафик, отключают картинки
- Оптоволокно - роскошь, не норма
Именно поэтому Lighthouse эмулирует Moto G4 на 1.6 Mbps. Это не «средний пользователь». Это пользователь в Мумбаи с prepaid-симкой.
А теперь посмотрите на вашу аудиторию. Европа, США, Россия:
- Средний фиксированный канал: 100–300 Mbps
- Мобильный LTE/5G: 30–150 Mbps
- Устройства: iPhone 15, Samsung S24, MacBook с M3
- Оптоволокно в каждую квартиру
Оптимизировать сайт под 1.6 Mbps для аудитории на 200 Mbps - это как ставить спортивный выхлоп на велосипед. Технически правильно. Практически бессмысленно.
Микрооптимизации, которые экономят 20 миллисекунд
Разберём конкретные «рекомендации» PageSpeed и их реальный эффект на канале 100 Mbps:
| Рекомендация PSI | Реальная экономия | Примечание |
|---|---|---|
| Defer non-critical CSS (50 КБ) | ~15 мс | На 100 Mbps 50 КБ летят за 4 мс |
| Minify JavaScript (500 КБ → 470 КБ) | ~10 мс | 6% объёма, незаметно |
| Lazy-load below-fold изображений | 0 мс для LCP | Не влияет на первый экран |
| Remove unused CSS (30 КБ) | ~8 мс парсинг | Браузер парсит CSS за микросекунды |
| Preconnect к стороннему домену | ~50 мс (холодный DNS) | При тёплом DNS - 0 мс |
| Serve images in WebP vs JPEG | ~40 мс на 200 КБ | На 100 Mbps разница 16 мс |
Суммарный выигрыш всех «критических» рекомендаций: 50–120 мс.
Порог восприятия задержки человеком: 100 мс (исследования Nielsen Norman Group). На быстром канале с тёплым кэшем пользователь физически не способен заметить разницу между сайтом с PageSpeed 60 и PageSpeed 95.
Это шум. Погрешность. Флуктуация RTT между двумя пакетами.
Что реально определяет скорость загрузки сайта
Вот настоящая иерархия факторов скорости - от критических к пренебрежимым:
1. TTFB - время ответа сервера (200–2000 мс)
Хостинг, версия PHP/Node, количество запросов к БД, отсутствие серверного кэша. WordPress без object cache генерирует страницу за 400–800 мс. С Redis-кэшем - за 20 мс. Это разница в 40 раз. Никакой minify CSS такого не даст.
2. География сервера и CDN (50–300 мс RTT)
Сервер в Орегоне, пользователь в Мюнхене: RTT ~140 мс. Сервер во Франкфурте: RTT ~8 мс. Один переезд сервера экономит больше, чем все рекомендации PSI вместе взятые.
3. Объём критического пути (HTML + above-fold ресурсы)
HTML на 500 КБ с inline-стилями и 12 блокирующими скриптами vs. HTML на 60 КБ с async-загрузкой. Это секунды, а не миллисекунды.
4. Количество блокирующих запросов
15 синхронных JS-файлов в <head> vs. 2 критических + остальные async. Реальный эффект: 300–800 мс.
5. Всё остальное (minify, defer, lazy-load, WebP, preconnect)
Суммарно: 50–120 мс. В пределах погрешности. Шум.
Переезд сервера из США в Европу: −130 мс. Defer CSS: −15 мс. Почувствуйте разницу в приоритетах.
Кейс: PageSpeed 45 против PageSpeed 95 - кто быстрее?
Сайт А: WordPress, тяжёлая тема Divi, 18 плагинов, PageSpeed Insights: 45/100. Но: сервер во Франкфурте (Hetzner), PHP 8.3 + OPcache, Redis object cache, TTFB: 180 мс, HTML: 82 КБ, critical CSS inline. Результат для пользователя в Берлине: LCP = 1.1 сек.
Сайт Б: React SPA, Next.js, PageSpeed Insights: 95/100. Но: сервер в Орегоне (Vercel default), TTFB: 650 мс для европейца, JS-бандл: 1.8 МБ, hydration на клиенте. Результат для пользователя в Берлине: LCP = 3.4 сек.
«Неоптимизированный» сайт с оценкой 45 в три раза быстрее для реального пользователя, чем «идеальный» сайт с оценкой 95.
PageSpeed не предсказывает UX. Он предсказывает, как Lighthouse на Moto G4 в Айове отрендерит ваш HTML. Это разные вселенные.
Что делать вместо погони за зелёной зоной
Практический чек-лист реальной оптимизации:
- Измерьте реальный TTFB из целевых регионов. WebPageTest (выберите локацию),
curl -wиз VPS в нужной стране. Не PSI. - Перенесите сервер ближе к аудитории. Или настройте CDN с нодами в целевых регионах. Cloudflare, BunnyCDN, AWS CloudFront - что угодно, но нода должна быть в 20 мс от пользователя.
- Сократите серверное время. Включите OPcache, Redis/Memcached, оптимизируйте SQL-запросы, обновите PHP до 8.3+ или Node до 22+. Цель: TTFB < 200 мс.
- Уменьшите критический путь. Inline critical CSS (above-fold), async/defer для остального. Не 14 чанков - 2 критических + ленивая загрузка.
- Следите за CrUX и RUM-данными. Real User Monitoring (Sentry, SpeedCurve, web-vitals.js) покажет, что видят люди. Не Lighthouse.
- PageSpeed - чек-лист гигиены, не KPI. Прошли по списку раз в квартал - хорошо. Не нужно делать из 72 → 95 релизную цель на спринт.
Вывод: перестаньте молиться на Lighthouse
Google PageSpeed Insights - полезный диагностический инструмент. Он подсвечивает грубые ошибки: блокирующие скрипты в head, изображения без width/height, отсутствующий кэш. Как чек-лист гигиены - работает.
Но 100/100 не делает сайт быстрым. 50/100 не делает его медленным.
Реальная скорость - это инфраструктура. Сервер, CDN, база данных, критический путь. Не minify. Не defer. Не lazy-load картинки в футере.
Google использует Core Web Vitals как tiebreaker в ранжировании - при прочих равных. Это 0.1% фактора. Контент, ссылки, E-E-A-T решают. А скорость решает хостинг и архитектура.
Перестаньте тратить 40 часов на удаление unused CSS ради 12 миллисекунд, которые никто не заметит. Потратьте эти 40 часов на переезд сервера, настройку Redis или переписание тяжёлого SQL-запроса.
Ваш пользователь в Берлине на iPhone 15 с оптоволокном скажет спасибо. А Lighthouse в Айове на Moto G4 - нет. Но это его проблемы.
Статья основана на технической документации Lighthouse, данных CrUX, исследованиях Nielsen Norman Group по восприятию задержек и практическом опыте оптимизации production-проектов.