Коротко. Балл Lighthouse делится на зоны как светофор: всё, что 90+, — зелёный, «всё в порядке». Разница между 92 и 100 для пользователя — это десятки миллисекунд, которых он не чувствует; разница между 70 и 90 — это секунды, из-за которых он уходит. Идеальные 100 на живом сайте почти недостижимы без вреда: придётся убрать аналитику, чат, фирменные шрифты и анимации. Для бизнеса и SEO важен не балл, а реальные Core Web Vitals — LCP, INP и CLS на живых посетителях. Ниже разберём, что отнимает баллы, что чинить, а что нет, и как поднять настоящую скорость.
Клиент написал нам в субботу утром: «Загнал сайт в PageSpeed Insights — там 96, а не 100. Это нормально или вы недоделали?» Вопрос честный, и за ним стоит понятная тревога: заплатил деньги — хочу максимум. Но в нём спрятана ошибка, которая стоит бизнесу реальных денег и нервов.
Предпосылка такая: 100 — это «отлично», а всё ниже — «недоработка». В школе так и было. В вебе — нет. Балл 96 с правильными метриками часто лучше для бизнеса, чем 100, ради которого с сайта вырезали половину живого. Разберёмся, почему 90+ — это не оправдание подрядчика, а осознанная и честная цель.
Школьная оценка против реальных знаний
Представьте двух школьников. Первый зубрит ответы к конкретному тесту и получает 100 баллов, но в жизни теряется. Второй понимает предмет на 92 балла по тому же тесту, зато применяет знания где угодно. Балл Lighthouse — это оценка за один конкретный тест, а не за «реальные знания» вашего сайта.
Lighthouse — синтетический аудит. Он запускает страницу в искусственной среде: эмулированный телефон Moto G Power, симулированный мобильный канал, фиксированное замедление процессора в 4 раза. Это не ваш пользователь — это тестовый манекен с заранее заданными характеристиками. Прогон делается один раз, на одном устройстве, в один момент. Реальные люди приходят с iPhone 15 на оптоволокне и с бюджетного Android на краю покрытия — и видят совсем другие цифры.
Поэтому первый вопрос не «почему не 100», а «100 по чьему тесту и насколько он похож на ваших клиентов».
Почему 100 на живом сайте — почти миф
Самое честное объяснение: идеальный балл требует жертв, которые вредят реальному пользователю и бизнесу. Вот что обычно стоит между вами и сотней — и почему это нужное.
Сторонние скрипты. Яндекс.Метрика, Google Analytics, чат-виджет, пиксель ВКонтакте, виджет оплаты, карта проезда — всё это грузится с чужих серверов, которые вы не контролируете и не можете оптимизировать. Каждый такой скрипт блокирует поток на 50–300 мс и стоит примерно 3–8 баллов. Убрать их ради цифры — значит ослепнуть по аналитике и забрать у клиента кнопку «написать вам».
Фирменные шрифты. Google Fonts даже с display:swap добавляют 100–200 мс к загрузке на медленном канале. Замените на системный Arial — балл подскочит, а узнаваемый стиль исчезнет.
Анимации и интерактив. Плавные появления блоков, калькулятор цены, фильтры каталога — любой JS добавляет вес и чуть тормозит первый отклик. В голой «визитке» без единого скрипта 100 берётся легко. Но тогда сайт перестаёт решать бизнес-задачу.
Иными словами, 100 на живом коммерческом сайте достижимо, только если убрать всё, что делает его живым и полезным. Это не оптимизация — это ампутация. И ещё деталь: формула баллов периодически меняется. То, что давало 100 в 2023-м, в 2026-м может давать 94 без единой правки в коде. Гнаться за цифрой, которая дрейфует, — заведомо проигранная игра.
Что измеряет Google на самом деле: Core Web Vitals
Вот ключевой поворот, который снимает почти всю тревогу. Для ранжирования Google смотрит не балл Lighthouse, а Core Web Vitals — три метрики, измеренные на живых посетителях вашего сайта за последние 28 дней (отчёт CrUX). Балл в PageSpeed на вашем ноутбуке — это прогноз в вакууме. CWV — это факт по реальным людям.
Три метрики стоит знать наизусть — именно они отделяют «настоящую скорость» от «балла ради балла».
| Метрика | Что значит простыми словами | Хорошее значение | Что портит |
|---|---|---|---|
| LCP Largest Contentful Paint | За сколько прогрузился главный блок первого экрана (обычно hero-картинка или заголовок) | до 2,5 с | Тяжёлая необработанная картинка, медленный сервер, блокирующий JS/CSS |
| INP Interaction to Next Paint | Как быстро страница отвечает на клик, тап, ввод в форму | до 200 мс | Тяжёлые скрипты, которые «думают» в момент нажатия; перегруженный главный поток |
| CLS Cumulative Layout Shift | Насколько вёрстка «прыгает» при загрузке — когда вы целитесь в кнопку, а она уезжает | ниже 0,1 | Картинки и баннеры без заданных размеров, шрифты, поздняя реклама |
Если эти три в зелёной зоне — сайт реально быстрый для людей, и Google это видит. Балл Lighthouse при этом может быть и 92, и 98 — на ранжирование влияет не он, а вот эта тройка.
Что отнимает баллы — и стоит ли это чинить
Не каждый «штраф» Lighthouse стоит вашего времени и бюджета. Часть проблем — реальные и бьют по пользователю, часть — косметика ради цифры. Вот честный разбор по принципу «да / нет / зависит».
| Что «штрафует» Lighthouse | Чинить? | Почему |
|---|---|---|
| Тяжёлая картинка hero без сжатия | Да | Бьёт прямо по LCP — это и балл, и реальная скорость. Чинить обязательно |
| Картинки без указанных размеров | Да | Вызывает «прыжки» вёрстки (CLS) — раздражает живых пользователей |
| Несжатый или неотложенный свой JS | Да | Грузит главный поток, ухудшает INP и отклик |
| Сторонние скрипты аналитики/чата/оплаты | Зависит | Отложить и сгруппировать — да; вырезать ради балла — нет, это бизнес-функции |
| Фирменные шрифты | Зависит | Оптимизировать загрузку (swap, preload) — да; менять на системные — обычно нет |
| Реклама и встраиваемые виджеты (YouTube, карты) | Зависит | Ленивая загрузка и резерв места — да; убирать нужное — нет |
| Лёгкие CSS-анимации появления | Нет | Стоят пары баллов, но создают ощущение качества. Жертвовать незачем |
| Последние 2–3 балла «до сотни» | Нет | В зелёной зоне пользователь их не чувствует — это погоня за цифрой |
Правило простое: чините всё, что улучшает Core Web Vitals; не трогайте то, что улучшает только цифру. Первое чувствует пользователь и видит Google. Второе — только график в отчёте.
Как поднять реальную скорость, а не балл
Если хочется не косметики, а настоящего ускорения — вот порядок действий по убыванию эффекта. Делайте сверху вниз: первые шаги дают больше всего.
- Разберитесь с главной картинкой. Hero-изображение почти всегда и есть LCP. Сожмите его в WebP или AVIF, отдайте в нужном размере (не 4000px на телефон), пометьте приоритетной загрузкой. Один этот шаг часто двигает LCP на секунду.
- Зарезервируйте место под медиа. Пропишите размеры картинкам, баннерам и встраиваемым блокам, чтобы вёрстка не «прыгала». Это убивает CLS — самую раздражающую для людей проблему.
- Отложите второстепенный JS. Скрипты, не нужные для первого экрана, грузите с
deferили после полной загрузки. Главный поток освобождается — улучшается INP. - Приручите сторонние скрипты. Аналитику, чат, пиксели подключайте после основного контента, а не в самом верху. Не удаляйте — откладывайте.
- Настройте шрифты.
display:swap, предзагрузка основного начертания, только нужные веса. Текст виден сразу, фирменный стиль остаётся. - Раздавайте статику через CDN и кэш. Картинки, шрифты, CSS и JS — с ближайшего к пользователю сервера и с долгим кэшем. Повторные визиты становятся мгновенными.
- Проверяйте по реальным данным. Смотрите не только балл в PageSpeed, но и вкладку «реальные пользователи» (CrUX) и Search Console. Оптимизируйте то, что красное там, а не на синтетике.
Заметьте: ни одного пункта «убрать аналитику» или «выкинуть анимации». Настоящее ускорение и сохранение функций — не противоречие.
Спидометр, а не школьный дневник
Ещё одна метафора, которая ставит балл на место. Lighthouse — это спидометр, а не оценка в дневнике. Спидометр показывает скорость в конкретный момент на конкретном участке. Он полезен, чтобы заметить, что вы ползёте 40 там, где можно 90. Но если стрелка показывает 92 на трассе с ограничением 90 — выжимать ещё бессмысленно и даже вредно: вы тратите бензин и рискуете ради цифры, которую никто не оценит.
Сравните две зоны простым правилом светофора. Ниже 50 — красный: серьёзные проблемы, люди уходят. 50–89 — жёлтый: сайт работает, но есть что чинить. 90+ — зелёный: всё в порядке, пора переключаться на контент и конверсию. Внутри зелёной зоны разница 92 против 100 — это не приоритет. Приоритет — чтобы сайт стабильно был в зелёном и на мобильном, и на десктопе, потому что именно мобильная версия чаще проседает.
Наш кейс: 100 vs 96 на реальном проекте
Покажем на конкретном проекте, почему мы выбираем 96. Лендинг для студии услуг мы собрали в двух версиях и прогнали обе.
Версия А — «ради сотни»: без аналитики, без чата, системный шрифт, нулевые анимации. Lighthouse: 100. Красиво в отчёте. Но клиент не видит, откуда идут заявки, у посетителя нет быстрой кнопки связи, а сайт выглядит как шаблон 2010 года.
Версия Б — рабочая: Яндекс.Метрика, чат-виджет, фирменный шрифт, мягкие анимации появления, но с честной оптимизацией (WebP-hero, отложенный JS, CDN, резерв под медиа). Lighthouse: 96. И главное — Core Web Vitals по реальным пользователям через месяц: LCP 1,8 с, INP 90 мс, CLS 0,03 — все три в зелёном.
Итог: версия Б проигрывает 4 балла в синтетике и выигрывает всё остальное — аналитику, конверсию, узнаваемость и реальную скорость для живых людей. Именно её мы и сдаём. Сайты, которые мы делаем, стабильно держат 90–98 на десктопе и 85–95 на мобильном — с честной оптимизацией и без жертв функциональностью.
Что спросить у подрядчика
Если студия обещает «100 из 100 гарантированно» — это повод не радоваться, а уточнить. Скорее всего, за гарантией стоит пустая страница на тесте либо отключённый на время аудита живой функционал. Задайте три вопроса:
- На чём вы меряете? Балл на пустом макете и на боевом сайте с аналитикой — две разные цифры.
- Какие реальные Core Web Vitals? Попросите показать CrUX или Search Console, а не один скриншот PageSpeed.
- Останутся ли аналитика, чат и фирменный стиль? Если ради цифры их убирают — вам подсовывают ампутированный сайт.
Честный ответ звучит как «90+ и зелёные Core Web Vitals на реальных пользователях», а не «ровно 100 любой ценой».
Коротко: что запомнить
- Lighthouse — это светофор и спидометр, а не школьная оценка: 90+ означает «зелёный, всё в порядке».
- Разница 92 против 100 — десятки миллисекунд, которых пользователь не чувствует; разница 70 против 90 — секунды, из-за которых он уходит.
- 100 на живом сайте почти миф: придётся убрать аналитику, чат, виджеты и фирменные шрифты — а это бизнес-функции, не балласт.
- Google ранжирует по Core Web Vitals (LCP до 2,5 с, INP до 200 мс, CLS ниже 0,1) на реальных пользователях, а не по баллу на вашем ноутбуке.
- Чините то, что улучшает CWV (сжатая hero-картинка, резерв под медиа, отложенный JS); не трогайте то, что даёт только цифру.
- «100 гарантированно» от подрядчика — повод спросить, не тестируют ли они пустую страницу и какие у них реальные метрики.
Частые вопросы
Это правда плохо, что у сайта 92, а не 100 в Lighthouse?
Нет. Lighthouse делит баллы на три зоны: красная (0–49), жёлтая (50–89) и зелёная (90–100). Любая цифра 90+ означает «всё в порядке». Разница между 92 и 100 для пользователя — это десятки миллисекунд, которые он физически не ощущает. А вот разница между 70 и 90 — это секунды, из-за которых он уходит. Гнаться за 100 в зелёной зоне — тратить бюджет там, где пользователь не заметит улучшения.
Почему сторонние скрипты не дают взять 100 баллов?
Яндекс.Метрика, Google Analytics, чат-виджеты, пиксели соцсетей, онлайн-оплата и карты грузятся с чужих серверов и блокируют главный поток на 50–300 мс каждый. Их код вы не контролируете и не можете оптимизировать. Каждый такой скрипт стоит примерно 3–8 баллов Lighthouse. Убрать их ради цифры — значит ослепить себя по аналитике и убрать у клиента способ связаться с вами. Это не оптимизация, а ампутация бизнес-функций.
Что важнее для SEO — балл Lighthouse или Core Web Vitals?
Core Web Vitals. Google ранжирует по реальным данным пользователей из отчёта CrUX, а не по синтетическому баллу Lighthouse на вашем ноутбуке. Сигнал ранжирования — это LCP, INP и CLS, измеренные на живых посетителях за 28 дней. Сайт с баллом 92 и «зелёными» CWV в поиске обойдёт «голую» страницу со 100 баллами, но без контента и плохими реальными метриками.
Что такое LCP, INP и CLS простыми словами?
LCP (Largest Contentful Paint) — за сколько секунд прогрузился главный блок экрана; хорошо — до 2,5 с. INP (Interaction to Next Paint) — как быстро страница отвечает на клик или тап; хорошо — до 200 мс. CLS (Cumulative Layout Shift) — насколько вёрстка «прыгает» при загрузке; хорошо — ниже 0,1. Это три метрики Core Web Vitals, по которым Google и оценивает реальную скорость.
Как поднять реальную скорость, а не балл ради балла?
Начните с того, что видит пользователь: оптимизируйте картинку hero-блока (формат WebP/AVIF, правильный размер, приоритетная загрузка) — это бьёт прямо по LCP. Дальше: отложите второстепенный JS, зарезервируйте место под картинки и баннеры (фикс против CLS), подключите шрифты через display:swap, раздавайте статику через CDN. Сторонние скрипты грузите после основного контента. Это улучшает и реальные Core Web Vitals, и балл — без жертв функциональностью.
Студия обещает «100 из 100 гарантированно» — это хороший знак?
Скорее тревожный. 100 из 100 на живом коммерческом сайте с аналитикой, виджетами и фирменными шрифтами почти недостижимо честным путём. Обычно за гарантией стоит одно из двух: тестируют пустую страницу без интерактива или отключают всё живое — аналитику, чат, анимации. Спросите, как именно достигается результат и какие реальные Core Web Vitals у их сайтов в CrUX. Честный ответ — «90+ и зелёные CWV», а не «ровно 100».
- web.dev — Core Web Vitals (LCP, INP, CLS): web.dev/articles/vitals
- web.dev — Lighthouse performance scoring calculator: web.dev/articles/performance-scoring
- Google Search Central — Understanding page experience & Core Web Vitals: developers.google.com/search
- Chrome UX Report (CrUX) — real-user field data: developer.chrome.com/docs/crux
- Опыт студии Tendo — A/B-прогоны Lighthouse и аналитика CWV на проектах
